I have been reviewing the documentation for pretty much every Zigbee and Zigbee-like mesh networking hardware solution I can find. So far I have been unable to find a solution which meets my target requirements: simple to implement, self-healing mesh networking, low enough in cost for modestly profitable low volume designs, a migration path to a high volume lower cost design, and the ability to programmatically control the node type at run time.The last requirement is driven by my goal of making a single device platform with with a single hardware connector. A mini USB connector would provide power and data for the coordinator device (the one at the PC) and just power for all other devices, which would be routers.

Jennic looked pretty good right up to the last requirement. Unfortunately there is no way to build an application which can programmatically perform router OR coordinator functions depending on the USB status. Which is a real shame, as the whole system seems otherwise nicely thought through. An integrated micro/radio has a ton of RAM and ROM. The user application is loaded into RAM on startup. A high volume product can store the application in ROM. A low volume or development system can store the program in external serial flash. The micro/radio can be purchased inexpensively. A complete module can be constructed for about ten or twelve bucks in relatively small quantities. A readymade module can be purchased for about twenty-five bucks. All the tools, including the stack, C compiler and IDE, are free. The dev systems are reasonably affordable, and a recent press release suggests that they will soon be cheaper still. A very nice touch is the API programming model, where the hardware is completely insulated from the user app, accessed only by API calls. Very clean. and much more likely to work! This approach is also used by the Ember 260, but it is ridiculously expensive.

Sadly, I am not willing to sacrifice the ability to construct a single product which acts as coordinator or router depending on environmental context. So I will have to forgo Jennic for now, and continue to look at other systems.

The MaxStream modules look like they contain both router and coordinator functionality. Unfortunately they are expensive and offer no path to chip-level integration. I may end up using them for simplicity if nothing else.

The Meshnetics system has some compelling features. It is based on a standard platform, the Atmel radio and an Atmel micro. The prefab modules seem well thought out, and well designed, both hardware and software. The system implies that a high volume product could emulate the prefab modules, and run the same application, but it is not clear how that works financially. I can find no offering of their stack independently, and their applications info suggests that their development environment supports only their modules. And of course, the documentation, tools and support from Atmel is awful, as always. Finally, their dev kits are way too expensive.

Turns out a lot of different types of devices have taken advantage of this class to provide simple file-like cross-platform access to device internal memory. I think this is a very interesting idea, and worth a close look. Wikipedia has a good overview, and points to an article and book by Jan Axelson that covers basically everything. Added to my Amazon buy list! Here is a chip-based FAT16 file system. Now if it would only provide a USB client interface as well…

I wonder how applications typically find the removable drive. That, unfortunately, is still not cross-platform, so would require different code for each. This would be the advantage, from the browser end, of using http instead. Now if a USB device could somehow emulate an http socket…

Here are a couple of rough sketches of architectures for the Atmosphericon system:Test one:
I could prototype a flow of information between a web application (Firefox) and a device (an Atmosphericon object) usingfile system access, which is built into every browser.

I could use the FT232R serial-USB chip as my cross-platform PC interface, and connect the serial chip to the Zigbee chip.

I could create a couple of files which emulate TX and RX buffers. I could use RealBasic to create a set of drivers which fould support all three platforms (Linux, OSX, Vista). These drivers would write all data from the virtual serial port RX buffer to an RX file, and poll the TX file for new data, writing it to the virtual TX buffer.

This might be a bit awkward, but it would work without a custom XPCOM module for Firefox.
Test two:
I have not researched this, but it occurred to me this weekend that the removable drive profile for USB might be cross-platform? If so, I might be able to fool any OS into thinking my device was a flash drive.

I would possibly have two pre-created files in the drive, and not allow the creation of any new files. I would, however, allow the TX file to be written to, and the RX file to be read.

My device would poll the TX file, and send any new data. It would delete data as it is sent. It would append the RX file with any new data that comes through the Zigbee channel.

This approach could potentially eliminate theUSB-serial driver, a serial port handler, and a serial-HTTP handler.

Some research needed!

So how do I connect a Zigbee network to a PC and the internet? MaxStream sells Zigbee USB radio modems ($250), but they are way too expensive. New Micros makes a carrier board for MaxStream’s Xbee modules ($75), which more or less fits the bill if you don’t mind the bulk, or plan to stick with the MaxStream system.

A couple of key-style USB dongles out there from different vendors. Integration Associates makes a Zigbee compliant dongle ($75) that probably could be interfaced to a module network from many of the vendors I have looked at so far. They apparently wil provide drivers for Windows, Mac and Linux.

I am not sure how easy it is to seamlessly transition from the simple proprietary networking methods provided by the module vendors to a Zigbee standard network. To be safe, I will probably selecting one of the module vendors which offer simple networking APIs then building my own gateway using a USB-serial solution like FTDI’s FT232R, then roll a serial-TCP driver for each platform.