The Testing Blog

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.