The Testing Blog

MoCA (Multimedia Over Coax Alliance) is a standard that utilizes existing coaxial cable at homes for creating a home network for sharing digital multimedia contents among different location inside the home. The MoCA Alliance has established the MoCA certification testing program to insure the proper functionality of MoCA devices and verify their conformance with the MoCA specification.

There are three parts to MoCA certification testing:

1. First, MoCA vendors run the self test on their own product and once they feel comfortable about their device’s performance, the vendor will submit their device to the MoCA test house for certification testing. If you’re a MoCA member you can download the MoCA Certification Test Plan from the Members Site.
2. Second, the test house will then conduct the designated CORE testing, as outlined in the MoCA Certification Test Plan (MoCA-DEVICE-CTP V10 or V08 depending on if version 1.0 or 1.1 is being tested).
3. Finally, upon the successful completion of testing, the results are sent to the MoCA Alliance for final verification and issuance of the actual certification.

In addition to the certification testing, the MoCA certification test house is also capable of providing the pre-cert (self test) testing. This works well for those vendors that are short on staff and resources, or those that aren’t familiar with the necessary self-test validation. The test house provides other MoCA related services (debugging, spot checking, etc.) to address any testing needs prior to the vendor submitting for certification to assist the vendors in getting their products to the market faster.

Many of you who are trying to get your ZigBee product (Platform, Smart Energy, MSP or other) ready for certification might be confused with all the documents to read – the specifications, the appendices, errata, etc. All you want is to run the tests and make sure the behavior is what it’s expected to be before you go to get your product certified. In ZigBee, like in many other standards, the easiest way to do that is to emulate the Golden Unit (GU) behavior. They are, after all, the reference and they are what the tests run against so why not just do as they do?

Unfortunately, the GU’s might be a little hard to obtain. The manufacturers rarely give them out, and when they do, it’s usually at a pretty hefty price. Fear not! The Alliance has made available, through authorized test labs, the logs for those GUs. What does this mean to you? Well, now you can get these logs and just compare them to what you are observing on your own devices. Since the tests for ZigBee are conducted over the air, if you ensure that the behaviors are similar, your chances of success in certification will be pretty high. From there on, all that will be left to do is correct a few small glitches, if any, once you start your official certification testing.

If you’re looking to get any platform, product, etc. ZigBee certified, you probably know that you need to check for 802.15.4 compliance before you move on to the higher layers. However did you know that ZigBee does not mandate the implementation of the full 802.15.4 MAC layer? Some functions of the 802.15.4 MAC are actually even prohibited in ZigBee and their use will cause your platform to be non-compliant. This not only reduces the testing you have to do, but also reduces code size and complexity that is not needed for your stack. Features such as GTS, MAC security, beacon networking, and PAN ID conflict on the MAC layer are just thrown out. In other words, ZigBee will only ask that you test a relatively small portion of the 802.15.4 MAC which should come as good news to all of you out there worrying about fitting all of this code in small memory chips to cut cost!

If you’ve developed several similar USB products, you might be able to get them all USB certified with only one test. Simple changes like product packaging, model numbers, connector vendors/model number, etc. can often be certified with only a few forms filled out. More extensive differences, such as changes to the microcontroller, PCB or RF hardware, may require a retest, but the ultimate decision comes from the USB Compliance Review Board (CRB). More information on what is and is not valid for Qualification by Similarity (QbS) for USB can be found at the USB-IF website.

Just a quick tip for anyone looking to have their Windows hardware WHQL’d (e.g., given a “Certified for Windows Vista” logo, etc.) – Microsoft has made 64-bit drivers MANDATORY. If you’ve designed a hardware product and you want to get it certified, you must also submit an x64 driver. The following text is from the Windows Logo Program Device Requirements Document (pages 86 and 365 as of today – search for “x64″):

All products and drivers (kernel mode or user mode) submitted for Microsoft signature or Logo must support the x64 version of that specific Windows operating system, with certain exceptions described below. This requirement is applicable for Windows Vista and later operating systems. It applies to all logo‘ed and unclassified drivers. x86 driver submissions are optional in all cases. When submitting an x86 driver or device, vendors must also make an x64 bit driver submission.

Just a warning before you get far along the process to get your product tested for WHQL/DTM.

However, Microsoft has been giving a 60 day grace period in which you can submit your x64 bit drivers.