Category Archives: Z-Wave Slaves

Z-Wave Watchdog Timer Best Practices

WatchDogVirtually all embedded systems must run 24 x 7 x 365 x many many years without ever being rebooted. Since there is no one there to “press the reset button” if the device fails, the watchdog timer is there to do just that. The 500 series Z-Wave chips from Silicon Labs have a watchdog timer and the example code provides a very minimal use of the watchdog timer. However, the minimal use in the example code is not sufficient to provide a robust watchdog for embedded Z-Wave devices. This post explains some rules and methods to code a robust watchdog timer.

Long time embedded expert Jack Ganssle has a great article on Watchdog timers. He describes the use of a watchdog timer on the Clementine spacecraft where a fault in the system caused the spacecraft to dump virtually of its fuel resulting in the loss of the mission. The lead software engineer had wanted a watchdog but the designers decided not to include it. Jacks example shows how important it is to spend at least some time coding a robust watchdog for our IoT devices. While our devices aren’t controlling multi-million dollar spacecraft, we are coding light switches that are hardwired into the wall and cannot be easily rebooted. Try telling the customer to go into the basement and toggle the power to his entire house to reboot the light switches!

What is a Watchdog?

A watchdog timer is a timer that runs constantly. Typically a complex combination of events resets (or “kicks”) the watchdog timer every now and then, usually every few milliseconds. If the combination of events ever gets stuck, the timer will continue to run. If the watchdog timer “times out”, the system is reset – basically the reset button is pushed! Your embedded system reboots and keeps on running. Generally no one even realizes it has rebooted (I’ll discuss that problem in more detail shortly).

WatchdogTimerThis diagram shows the Watchdog timers value which is constantly counting up. Every time the Watchdog is “kicked”, the counter is reset to zero. Somewhere in your code the ZW_WatchDogKick() routine is called which resets the watchdog timer. Sometimes this reset condition happens on a nice regular basis, sometimes it happens at varying times as shown by the level of the timer. The key is the timeout threshold has to be longer than any normal operating condition. If a fault condition occurs, the timer keeps on counting up until the threshold is reached and then the system is reset. When the watchdog timer fires, the Z-Wave chip goes thru a full reset just as if power had been removed and reapplied. Your embedded system is back up and running as if nothing had happened.

SiLabs Sample Code = Bad Watchdog

The SiLabs sample code has the following implementation of the watchdog:

BYTE ApplicationInitSW(ZW_NVM_STATUS nvmStatus) {
...
#ifdef WATCHDOG_ENABLED
 ZW_WatchDogEnable();
#endif
} 

void ApplicationPoll(void){
#ifdef WATCHDOG_ENABLED
 ZW_WatchDogKick();
#endif
}

The sample code has the good implementation practice of putting the Watchdog code inside #defines so it can be easily enabled/disabled. Unfortunately it makes the very large mistake of blindly kicking the dog every ApplicationPoll without checking any other conditions. ApplicationPoll is called roughly every few hundred microseconds and a lot of fault conditions can exist and ApplicationPoll will still be called. With this implementation the only way the watchdog is going to fire is if there is a catastrophic failure and ApplicationPoll is no longer being called. While this implementation is better than nothing, it won’t reset the system in many cases where the device has become unresponsive.

Good Dog Example

Writing good watchdog code requires some significant thought and testing. The possible sources of failure need to be discussed with members of the team and with other Z-Wave developers who are fighting the same fight (thus the need for this blog). I can provide a few guidelines to include in your analysis but this is not a complete solution.

Mutex Gets Stuck

The most common failure I have seen is the fact that the SiLabs provided Application Framework (AF) code mutex can get stuck. When the mutex is stuck, it most often results in the device still able to receive Z-Wave traffic but often can’t respond. If the device is power cycled, then it returns to full operation. So often this failure goes unnoticed both in testing and in actual use.

What is the mutex you ask? The mutex is a simple flag in the AF that prevents the code from overwriting the Send Buffer while a message is currently being sent over the radio. When a GET command comes in, the AF will call a command class handler to handle the GET and build a REPORT frame in memory. When ready to send the frame, the AF will call pTxBuf=GetResponseBuffer() to get a buffer for the radio to send. There is only one buffer so if the buffer is already in use, you get a NULL pointer back and will have to wait and send the frame later.  This in general works fine as long as frames don’t come in too fast. But in a large network with lots of repeated and re-routed frames you will occasionally get a bunch of GETs quickly and it is possible for the REPORTs to get cross wired and end up locking up the mutex for a frame that will never be sent. If the code then doesn’t properly release the buffer, the mutex is stuck. The Application Framework code is known to lock the mutex occasionally so you must code around this problem. The easiest solution to this rare event is to ensure the watchdog is watching the mutex and simply reboot if it gets stuck for too long.

My solution is to have a counter that counts up once per second in ApplicationPoll anytime ActiveJobs() is true (in SDK 6.81.xx its now called ZAF_mutex_isActive()). ActiveJobs is true anytime a buffer is in use and false when all the buffers are free. There are actually two buffers, one for response frames (REPORTs sent as a result of a GET) and a second buffer for request frames (unsolicited notifications).

Application Specific Reasons

Beyond the mutex you must think long and hard about application specific failure conditions. The most obvious is that the device has not received or sent a frame in 25 hours. Most hubs will poll a device at least a couple of times per day to make sure it is still alive. So if there has been no traffic in a day, maybe something is stuck and a reboot is in order. Plus if nothing has happened in a day then probably no one will notice the reboot (which only takes 1.5 seconds). You do have to be careful that some other part of the application isn’t impacted as a result of the reboot. For example, if you are a light switch and by default you turn the light off on a reboot, then people will be really annoyed if the light randomly turns off because your hub hasn’t polled it in day. There are lots of potential checks you can make here but every application will have different requirements so you will have to think hard about all the possible conditions for your specific case.

Sample good watchdog:

E_APPLICATION_STATE ApplicationPoll( E_PROTOCOL_STATE bProtocolState ) {
...
if (ActiveJobs()) {              // Mutex buffer is busy
    if (OneSecondTimer) ActiveJobsCounter++;  // Once/sec increment
} else {
    ActiveJobsCounter=0;         // When buffer is free clear counter
}
...
if ((ActiveJobsCounter<30) &&       // Mutex isn't stuck 
    (LastCommsHours<25) &&          // Got a frame in the last 24 hrs
    ApplicationSpecificReasons) {   // Other reasons
    ZW_WatchDogKick();              // Everything is OK so reset WDOG
}

In the example code above we do have a major issue in that if the counters stop counting for some reason, the watchdog will never fire! But that’s easy to check for in ApplicationPoll and if ApplicationPoll itself isn’t running then the WatchDog is no longer being kicked so it will reset.

Doesn’t Work If Not Tested

The old coding adage (proven totally true by me many many times) goes “If the code hasn’t been tested, it doesn’t work”. Same thing applies to your Watchdog code. So how do you test the watchdog? The first thing to do is to log the number of times the watchdog has triggered. This has to be stored in NVM since RAM will be lost when you reboot. Fortunately ApplicationInitHW is called with the bWakeupReason parameter which lets you know the watchdog fired when equal to ZW_WAKEUP_WATCHDOG. Note that usually ApplicationInitHW just stores the bWakeupReason and later in ApplicationInitSW we check it as the NVM isn’t available in InitHW.

ApplicationInitSW(...) {
...
if (wakeupReason==ZW_WAKEUP_WATCHDOG) { // Increment WDOG counter with max 255
    i=MemoryGetByte((WORD)&EEOFFSET_NumberWatchDogResets_far);
    if (i<255) MemoryPutByte((WORD)&EEOFFSET_NumberWatchDogResets_far, i+1);
}

Use a Configuration Command Class parameter to read or update this value for testing purposes. I also like to put in a small block of code wrapped in #ifdef WATCHDOG_TESTING_ENABLED that upon receiving a BASIC_SET with a value of 0xDE (not a valid value) calls GetResponseBuffer() which locks up the mutex and in 30 seconds the chip should reboot. If not, then you have a bug in the watchdog code! You can test all the branches in your watchdog code with various values of a BASIC_SET.

When to Enable Watchdog

Perhaps a better question is when NOT to enable the watchdog since ALL production builds absolutely must have the watchdog enabled! My recommendation is to disable the watchdog during development. You want the chip to lock up if you have a bug. The watchdog is really good at masking major bugs since things just keep on working. If the device locks up, then you know something is wrong and you need to chase it down. If you power cycle and the device is fine again, IT IS NOT FINE! You have a bug in your code! During production testing I usually turn the watchdog back on but I also have the testing scripts check the watchdog counter and if it increments then the test fails.

Watchdog Best Practices for Z-Wave Developers

  1. Disable Watchdog during development using #defines
  2. Only kick the watchdog when everything is idle
    1. Kicking every ApplicationPoll is INSUFFICIENT
    2. Check the ActiveJobs() being stuck (aka Mutex)
    3. Check other conditions within your product
  3. Check that the RF has received something every X minutes or hours
  4. Have a way to test the Watchdog during development
  5. Store the number of Watchdog resets in NVM and retrieve them via a configuration parameter

 

Z-Wave 700 Series Announcement

The long awaited 32-bit ARM based Z-Wave transceiver chip has finally been officially announced. The 700 series announcement is on the home page of the Silicon Labs web site so this is a big deal for SiLabs and Z-Wave. The companies joined forces just eight months ago and we already have a major advance in Z-Wave technology.

Z-Wave 700 Press Image

What’s New?

The 700 series is a major improvement to Z-Wave for both consumers and developers. For consumers, the lower power and longer radio range means more reliable communication and longer battery life. For developers the main advantage is we’ve finally moved beyond the 1980s 8051 8-bit CPU with very limited debug capability into a modern 32-bit ARM CPU with full serial wire debugging capabilities. We can FINALLY single step thru code instead of having to use PRINTF!

700 Series Features:

  • Longer RF range
    • 150% in the US and 200% in the EU due to improved RF sensitivity and increased transmit power in the EU
  • Lower Power = Longer Battery Life
    • Improved semiconductor technology and a faster CPU yields significant battery life improvement and 10 year coin cell operation
  • Lower Cost – Worldwide Support
    • Improved RF blocking means the country specific SAW filter is not needed saving cost and making a single SKU for worldwide operation
    • No external serial memory is required and OTA firmware update is now mandatory
  • Easier Product Development
    • Integrated Debug Environment (IDE) with full ARM debug, single step, trace, and energy profiler speeds product development
  • 100% Interoperable and Backwards Compatible
    • The 700 series is fully interoperable with all mesh-networked Z-Wave devices all the way back to the pre-100 series Z-Wave devices

When Can I Get One?

If you already signed up for a free Beta devkit, then one should be on its way in the next few weeks. Devkits have begun shipping but quantities are limited and will take until the end of January before all the Beta samples are shipped. The Beta signup closed back on October 1st so if you missed the deadline you’ll have to wait until later in Q1 to request one from your Silicon Labs salesperson. The official “general availability” (GA) release is the end of Q1 at which time the datasheets, chips, devkits and software will be released at the 7.xx full release version. Datasheets require an NDA until the GA release.

You can get started today using the Simplicity Studio IDE and begin developing code and explore the SDK. The software is free and can be downloaded from here.

My Initial Thoughts

I’ve had a 700 series Beta DevKit for a few weeks now working with our Alpha release partners to get some early feedback. We’ve had some hiccups and the firmware needs more work but the silicon is solid. I have joined my 700 series devkit to my home and it communicates fine with my very early pre-100 series Z-Wave light switches attesting to the ongoing commitment Z-Wave has to be fully interoperable and backwards compatible.

Z-Wave Summit Fall 2018 Philadelphia

The Z-Wave Summit is usually held only once each year in the USA and it is not to be missed. I’ll give a brief overview of what was discussed at the summit in the short post below. But if you didn’t attend in person, you missed the most valuable aspect of the summit which is the chance to meet and talk to other Z-Wave developers. This year the summit was hosted by Bulogics in the city of brotherly love,  Philadelphia PA. Bulogics is a Z-Wave certification house so they know everything about Z-Wave and how to have a good time!

2018ZWaveSummitMitch.jpg

Summit Notes

The 700 series was officially “revealed” at the summit with many presentations talking about the new ARM based Z-Wave transceiver. The summit has over 140 attendees from 70 companies not including all the Silicon Labs and Alliance employees. This is the largest attendance of a summit to date and reflects the rapidly growing world of Z-Wave.

Matt Johnson, IoT Sr. VP, described the roadmap for multiprotocol chips which include Z-Wave, zigbee, BLE and Wifi as well as proprietary protocols. For the immediate term though the focus is on getting the 700 series shipping. The real key for Z-Wave is the interoperability and certification ensuring every Z-Wave device can communicate with every other device.

Z-Wave product manager Johan Pedersen presented the important improvements in the 700 series over the 500 series:

  • ARM M4 32-bit CPU
  • 150% RF range improvement in the US and more in EU/Asia
  • Lower power and faster wakeup time making coin cell operation a reality
  • Lower cost due to elimination of the external NVM & SAW
  • Single HW build for all regions due to elimination of the SAW filter
  • Longer battery life with 1.8-3.6V operation
  • Serial debugging

By far my main interest as a developer is that we finally have a real CPU with an M4 and serial debugging so I can finally single step my code and figure out where I went wrong!

The next natural question of course is when will the 700 series be a reality? The answer is “soon”. Ugh. Developers kits are supposed to be available soon and the parts will be shipping in early 2019.

Technical Track

On the second day of the summit the groups are split between marketing and technical geeks like me. More presentations on things like the new Z-Wave Plus V2 requirements which will go into effect with the 700 series release. The V2 requirements significantly ups the bar for support for various command classes with the goal of making Z-Wave devices to fully inform the hub of their capabilities. There should be little or no custom coding to support most V2 devices – the device will tell you everything it can do.

The presentation by Alex Capecelatro, founder of Josh.ai, described the future of voice control which sounds amazing. Alex described just how hard voice control really is and has a long way to go before it really works the way we all want it to. I liked his quote from the New York Times: “We overestimate what technology can do in 3 years but underestimate what can be done in 10 years”. Z-Wave has come a long way in the dozen years it’s been around.

Configuration Command Class

2018summitERI gave a presentation on Configuration Command Class Version 4 and all the wonderful things it can do. The most notable point is that 2/3rds of the Z-Wave Plus certified devices have at least one Configuration Parameter. Yet many hubs have no way of modifying or displaying to the user the current value of parameters. Z-Wave Plus V2 mandates support for Configuration Command Class V4 for both hubs and devices so you need to get busy! My presentation title is: “The Chicken vs Egg is over: Moving Your Product to Configuration Version 4” which can be downloaded from this link: Z-WaveAlliance2018EricRyherd.

Interoperables Band

Once again the band The Interoperables played at the evening get together at a local brewery. These guys are really good for having only practiced a couple of times!

2018ZWaveSummitInteroperables

DrZWave joins Silicon Labs

That’s right, I have officially joined Silicon Labs as an FAE covering the Eastern US. I can be contacted at drzwave@Silabs.com.

 

 

 

 

8051 8-bit CPU Coding Tricks & Tips

The death of the 8-bit CPU has been prognosticated for over a decade but these old tiny workhorses keep going and going and going. Z-Wave is currently based on the venerable Intel 8051 CPU but we’re about to get an upgrade to a 32-bit ARM CPU via the 700 series which is due out later this year. In this posting I’ll give a few tips on coding in C for the 8051 to typically improve speed of execution.

I’ve been writing code for 8-bit CPUs since the 1980s and I designed a few in the 1990s. I also designed a couple of 32-bit RISC CPUs in the 1990s and early 2000s. I often had to squeeze the code just a little harder to get an operation to happen just fast enough to meet a system requirement. This meant that I either had to code in assembly or often just coding C in a slightly different way would convince the compiler to generate the most optimal assembly code for me.

8-bit CPU Architecture

I could go thru a long discussion of the block diagram of the 8051 CPU but instead I’ll just cut to the  chase – the 8051 is not at all “C friendly”. The 8051 was architected back in the bad ol’ days of assembly programming – especially for embedded systems where resources were in very short supply (think 1K ROM and 64 bytes of RAM). Thus the architecture has all sorts of funny things that a C compiler can’t take advantage of efficiently. The PSR flags, the D pointer, the single accumulator, memory mapped registers and the SFR registers are all parts of the 8051 that make it special but unfortunately are just not efficient in C. The folks at Keil have worked really hard to make their compiler as efficient as possible and to make access to these non-C hardware resources available without too much effort. But at the end of the day, a C compiler really wants a nice simple block of 32-bit registers to perform integer arithmetic on and a simple flat memory – in other words, a RISC CPU.

In the Z-Wave world, the 8051 in the 500 series chips is a 32 MHz 8051 with 128K bytes of FLASH and 16K bytes of RAM. “But wait” you say, “the 8051 is an 8-bit CPU with a 16-bit Program Counter, how can it address 128K bytes?”. The answer is Bank Switching which is just plain crazy but I won’t get onto that soapbox in this posting. The Z-Wave code from Silicon Labs is delivered as pre-compiled C libraries that the application developer links into their code. The application code is written in C and the Keil compiler does a fine job of squeezing a reasonable amount of code into the tiny 8051. Fortunately in IoT, the task to be performed is usually pretty simple – turn a light on or off by activating a relay connected to a GPIO so we don’t need a multi-Gigahertz CPU with gobs of RAM.

The Silicon Labs SDK comes with a number of sample applications and a bunch of “helper” routines all written in C. Thus, a Z-Wave application can generally be written completely in C, compiled using the Keil compiler and it’ll generally squeeze into the limited code space as long as you don’t try to do too much on this little CPU. But it seems there are always some little things that I just need to do a little faster. The following tips are just a few of the simple tricks I’ve learned from decades of embedded coding.

The Fastest 8051 Loop

What is the fastest 8051 loop you can execute in C?

The most common loop is a simple FOR loop:

for (iter=0;iter<16;iter++) {
...
}

Which is easy to read and does the job just fine – if we don’t need to do it very fast. Often the innermost loop is executed a lot and squeezing just a few instructions out of the code will significantly improve the performance of the routine.

The for loop above compiles into the following assembly code:

B02:0xA04D E4 CLR A
B02:0xA04E FF MOV R7,A
B02:0xA04F 0F INC R7                    ; TOP OF LOOP
B02:0xA050 EF MOV A,R7
B02:0xA051 B410FB CJNE A,#demodState(0x10),B02:A04F

Which as you can see is quite a few instructions and even longer when you consider that each instruction is at least 4 CPU clocks. The Compare and Jump if Not Equal (CJNE) is a 3 byte instruction which requires many clock cycles to execute. If we can squeeze a few instructions out of the loop then it will run much faster. Obviously we could code in assembly but this exercise is to show that HOW you code in C can make a big difference in the performance. An alternative coding of the for loop above is:

iter=16;
do {
...
} while (--iter);

With this slight change in the coding style the while loop turns into a single byte DJNZ opcode as shown below so this is the fastest and most efficient looping structure when targeting the 8051.

B02:0xA055 7F10 MOV R7,#demodState(0x10)
B02:0xA057 DFFE DJNZ R7,B02:A057         ; single instruction loop

The real trick to improving the performance of your code is to see what assembly instructions the code compiles into.

How to See What Your C Code Turns Into

You can’t improve the performance of your code unless you can measure what the performance is and where all the time is being spent. A classic method of measuring the performance is to set a GPIO pin high or low during specific routines. Then use an oscilloscope to observe how long the routine takes. Other options involve printing out markers out a UART or using a hardware timer to measure the duration of a routine.

KeilDebug1A simple method to observe the instructions our C code generates for our little 8051 CPU is to use the simulator built into the Keil C compiler. By default the Keil IDE does not have a simulator when using the Silicon Labs sample projects so you have to assign one. Right click on the project then select “options” then click on the “Debug” tab. Then enter “s8051” into the CPU DLL box as shown here. You can now click on Debug->Start/Stop Debug Session or press <CTL>F5. This will enter the Keil Simulator for the 8051. One thing to understand is that this simulator does NOT understand the bank switching of the Silicon Labs version of the 8051 used in the 500 series. Unfortunately you can’t debug code much using this simulator as any bank switching doesn’t work. But it will work well enough to debug small snippets of code and of course to see what you code turns into.

KeilDebug2Once the debugger opens in the IDE, click on the line of code you are interested in and the Disassembly window (use View->Disassembly if its not visible) will take you right to the line of code you are interested in as shown here. Note that the C source code is mixed in as comments in the assembly code. This helps guide you to match the C code to the assembly code which can be a little convoluted depending on the optimization the compiler has applied. You can see here that the Do-While has turned into our desired DJNZ single instruction loop.

Don’t rely strictly on the instruction count to guide your C coding style. One slow-down I often see in the Silicon Labs code is they call a subroutine, that calls a subroutine, that calls (several more) subroutines which finally just returns a value. While this may be structured C coding it is very slow in an 8051. Each subroutine call pushes and pops a number of registers and parameters on the stack and each of those takes several clock cycles to perform. Ideally a C macro is used to specify a value or a register which becomes just a single instruction fetch of the value from a register or memory instead of all this pushing and popping.

Unrolling Loops

Another easy speedup in C is to unroll short loops. A classic situation for unrolling loops is when emulating a serial protocol like I2C with a GPIO. Since the loop is typically only 8 passes you can often significantly improve performance by unrolling the loop – often taking the I2C bit rate from under 10Kbps to nearly 100Kbps.

for (bitnum=0x80; bitnum!=0;bitnum>>1) {
    I2C_SEND_BIT(data & bitnum);  // macro to set SDA then toggle SCL
}

When unrolled turns into:

    I2C_SEND_BIT(data & 0x80);
    I2C_SEND_BIT(data & 0x40);
    I2C_SEND_BIT(data & 0x20);
    I2C_SEND_BIT(data & 0x10);
    I2C_SEND_BIT(data & 0x08);
    I2C_SEND_BIT(data & 0x04);
    I2C_SEND_BIT(data & 0x02);
    I2C_SEND_BIT(data & 0x01);

Which works well for short fixed length loops but obviously won’t work in every case. The slow down with the FOR loop involves reloading the accumulator and the D pointer with various constants and the iteration value. The inline version doesn’t have any of these nor are there any delays from looping. This technique also works well on 32-bit RISC processors.

Conclusion

There are a lot more tricks when coding for small 8-bit CPUs. But I’m hoping I won’t have to bother with them for much longer and the dominance of the 32-bit CPU will finally crush the 8-bit out of existence. The price of silicon continues to drop and 32-bit CPUs are often as cheap or even cheaper than these ancient 8-bit boat anchors. The modern CPUs also come with advanced debuggers unlike the 8051 which has… wait for it… printf or worse yet simply toggling an IO. Ugh.

 

 

EU Z-Wave Summit 2018 – Amsterdam

2018EUSummit1IoT Device Testing Best Practices by Eric Ryherd

Click  HERE to see the entire presentation including my notes. If you are a Z-Wave Alliance member a video of the presentation is usually posted on the members only section of their web site. The main takeaways from my presentation are:

  • Have a written test plan
  • Use the Compliance Test Tool (CTT) as the START of your test plan
  • Vary the environmental conditions during testing
  • Test using real world applications
  • Test using complex Z-Wave networks with routing and marginal RF links
  • Test with other hubs and devices
  • Automate testing using tools like the ZWP500
  • Code firmware with failure in mind
  • Utilize the WatchDog timer built into the Z-Wave chip

The presentation goes into detail on each of these topics so I won’t duplicate the information here. I also go thru several failures of devices I’ve been working with. You learn more from failures than you do when everything just works. This is the same presentation that gave last fall in the US summit.

Z-Wave Summit Notes

2018EUSummit4There were nearly 200 attendees at the Summit – a significant increase over last year. One of the main purposes of the summit is to learn what’s new in Z-Wave and what Silicon Labs is planning for the future. The most important news at this year’s summit is the 700 series which was announced at CES in January. Unfortunately we will have to wait a bit longer to get our hands on the chips due to the purchase of Sigma Designs by Silicon Labs. The 700 series chip has been updated to match the other SiLabs microcontrollers so the silicon has been delayed a bit but they expect to ship parts before the end of 2018. Z-Wave will benefit tremendously from a real CPU instead of the very resource constrained 8051 in the 500 series. The feature I can’t wait for is the hardware debugger. We’ll finally be able to single step our C code and inspect variables and set breakpoints. No more PRINTF! Yeah!

Time for hubs to switch to Z/IP and ZWare

The very clear message of the summit is that Z/IP and ZWare are now mature and is THE gateway interface going forward. My initial brief trials with Z/IP were frustrating with poor documentation and the software really wasn’t quite ready. But with the recent release of 2.81 it would appear it is ready for prime time and I’ll have to give it another look. I was surprised by the number of gateway developers that were at the summit and most were already using at least Z/IP and many also using the ZWare abstraction layer. The SerialAPI is the interface most gateway developers have used in the past but this is a very low-level interface. There are many nuances of handling sleeping devices and the complexities of the encrypted security encapsulation when using such a low-level interface. This is where Z/IP comes in which handles nearly all of these lower level details for you. Z/IP is planned to be the only supported interface in the near future and certification costs will be significantly higher if it is not used. ZWare adds another layer on top of the Z/IP which provides much easier C++ objects relieving the developer from having to learn the details of each Z-Wave command class. See the Z-Wave Public web site for more details.

The internal Z-Wave Technical Site (ZTS) is now also available to everyone but you still have to click on “accept terms” to gain access. However the access is granted immediately so you don’t have to wait for “approval”. So anyone wanting to learn about the inner guts of Z-Wave can now do so without buying a DevKit.

Summit isn’t all work, work, work

Maker:L,Date:2017-8-26,Ver:5,Lens:Kan03,Act:Kan02,E-YThe Summit isn’t all work all day even though the days are long and filled with lots of technical information. This summit had an evening at the Rosarium park. The park has room for team building games like a maze run, archery, volleyball among other games and of course lots of food and drink. It was a nice ice breaker and a good way to get to know your fellow Z-Wave developers. The networking opportunities are a very large part of the value of attending the summit in person. The evening highlight was a performance by the “Interoperables” Z-Wave Rock and Roll band lead by Alliance chairman Mitch Klein.

CES 2018

The Consumer Electronics Show in Las Vegas is THE trade show for smart home technology and all things cool and new and geeky. It’s a massive show and I only spent one day there and never made it out of the Sands convention center which is one of the smaller venues. If you’ve never been to CES it is something to see. The crowds are enormous and the tech is brand new. So new, some of it will never actually make it to market as there is plenty of smoke and mirrors.

Eric Ryherd wireless IoT consultant expert

My purpose is obviously to seek out the latest news about Z-Wave and chat with my clients. The Z-Wave Alliance invited me to man the “Ask the Expert” desk at the show for a few hours which I was happy to do. My expert knowledge of Z-Wave answered simple questions like “what’s Z-Wave?” (It’s like wifi but low power) to complex questions about the rules around Security S2 and SmartStart.

The most common question is always what’s the difference between Z-Wave and Zigbee? My short answer is that Zigbee is like silos. If you can develop an app, gateway and all the devices you need, then Zigbee will work OK. Z-Wave however was a mesh network from day one and every Z-Wave device can talk to every other Z-Wave device regardless of the manufacturer. Z-Wave is built around standardized command classes so every hub knows precisely what format a temperature sensor is sending the data. Is it in celcius or Fahrenheit? Tenths of a degree or hundredths? With Z-Wave, the format is fully specified. The other protocols let you decide the format which is fine if you have the huge budget to do it all. But if your investors have you on a shoestring budget then Z-Wave is the way to go. I have much longer answers to the Z-Wave vs. Zigbee question but much too long to keep your interest in a quick blog post.

The big announcement for Sigma (other than the acquisition by Silicon Labs) is the announcement of the 700 series. Unfortunately details remain shrouded in secrecy but Sigma has put a stake in the ground of having developers kits by summer 2018. Finally having a real 32 bit ARM processor will be a huge productivity improvement for us IoT developers.

I had limited time to walk the floor but it does seem that smart home has finally taken off. There are so many companies making cool gizmos it’s overwhelming. From sun tracking solar powered umbrellas to cameras of every size and resolution to lots of new hubs there is no way one person can take it all in. You’ll just have to see for yourself.

The Z-Wave Alliance booth is even bigger this year filled with companies hawking the latest IoT thingamagiggy using Z-Wave. Every one of them able to talk to all the other Z-Wave doodads. The booth was busy all day long. I did wander past the tiny Zigbee booth buried in the back of the hotel with a few people in it but nothing like Z-Wave.

How to make a Z-Wave SUPER Sniffer

In this posting I’ll show how I made not just a Z-Wave packet sniffer but a SUPER Z-Wave packet sniffer that is able to receive many Z-Wave frames that a mere average sniffer cannot.

If you are a Z-Wave developer there is a packet sniffer tool available with the Z-Wave development kit called the “Zniffer” that is similar to the popular WireShark network sniffer. Unfortunately for the average Z-Wave user, the tool is only available to developers which requires the purchase of a DevKit and signing the applicable NDA documents. The Zniffer software is available on the Sigma Technical Support Site (ZTS) which requires an account approved by Sigma so you have to prove you are a developer. The Zniffer is invaluable for developing with Z-Wave because it decodes and can decrypt the encrypted frames traveling over the radio. The Zniffer is able to capture every routing attempt and every acknowledge as well as FLiRS beams and even collisions on the radio. This is way more information than you can get via the SerialAPI and is the only way to diagnose many problems you will encounter while developing a Z-Wave based product.

How to make a Super Zniffer

You can’t buy a Zniffer. UZBYou have to make one out of a UZB which is a simple USB stick that provides a COM port that talks to a PC over USB. The ZTS site explains how to convert a UZB into a Zniffer which isn’t easy to do and every time I do it I seem to have about a 1 in 5 chance that I permanently brick the UZB and have to just throw it away (fortunately they are only $25). Once you have the Zniffer firmware loaded into the UZB, use the Zniffer software and make sure it’s working. The UZB works well however it has a tiny helical antenna which means it is limited in its ability to capture all the traffic over the radio. The key to making a Super Zniffer is to tear out the little helical antenna and replace it with a full 1/4 wave antenna.

Solder on an SMA connector

ZnifferThe first step is to pry open the UZB enclosure. Use a small flat head screwdriver to pry it open along the USB connector. There are pins that hold the two halves together. Be careful not to break off the pins as we’ll use the enclosure with the Zuper Zniffer.

SuperZnifferNext unroll the helical antenna and cut it off so it just reaches the end of the PCB. Place the SMA connector on the end of the PCB and solder the antenna wire to the center pin of the SMA as shown above. You can solder the ground pin of the SMA to the PCB ground but it doesn’t seem to make much of a difference. Cut the enclosure to make room for the SMA connector to stick out the end and then snap it back on. Then screw on any SMA antenna and try it out. I typically get 3 to 5 more dB as reported in the Zniffer software RSSI column. This should be nearly 10X more range. There are so many antennas to choose from once you have an SMA connector so experiment and find one that works for you. You can even use a Yagi antenna which would then make the Zniffer highly directional.

Comparing the Zniffer to the Super Zniffer

A regular Zniffer and even the Super Zniffer won’t capture EVERYTHING traveling over the radio waves. That is just the nature of RF. When analyzing the trace in the Zniffer you have to remember that you might be missing frames that your target can see AND that even though you can see a frame it is possible the target didn’t see it. Thus, analyzing the Zniffer trace takes some getting used to.

Here is a typical Zniffer trace:

ZNif1

And this is the Super Zniffer trace of the same time when both Zniffers are right next to each other. Compare line 2084 above (the 2nd red CRC ERROR line) and line 2113 below.

SuperZnif2

Notice the yellow highlighted line on the Super Zniffer trace. If you compare this line with the one from the normal Zniffer you see the normal Zniffer only recorded this frame as a CRC error and was not able to capture it correctly. Also note that the RSSI is only 56 compared to 64 for the Zniffer indicating the antenna is providing about 8dB more signal strength than the tiny helical antenna of the normal Zniffer. The improved reception of the Super Zniffer makes debugging Z-Wave problems much easier as you aren’t having to sort thru as many questionable frames.