One thing that Ed pointed out was that I have yet to lock down the basic restrictions of the network. In other words, Zigbee supports up to 250kbps data rate, but what does this mean? Does it mean that any device may process data this fast? Or if one is, then others can do nothing? And is this a raw data rate or real-world throughput?

Here is Jennic’s nice Zigbee primer.

One idea I have been thinking about for some time now is the notion that other protocols support high data rates. Bluetooth, for example. Zigbee, on the other hand, is designed for command and control. So multimedia apps are better served by other networks. Which means that my device ideas should work with some practical range, which would be enforced by the whole system, the hardware and software alike.

I am thinking that I should design devices such that they do any complex data processing on the client (device) side or the master (network) side, but not rely on volumes of raw data to and fro. For example, a video display is not at all appropriate. Streaming audio is not. It may be that the system could support the transmission and display of images, or the playing of sounds, but as downloads and save, rather than streams.

It might also be that the network doesn’t try to even support those uses. That it strictly enforces command and control uses.

Let’s look at some examples to try and suss this out.

No-brainers acceptable uses:

• Push puppet whose attitude is determined by a value periodically sent to it.
• Display screen, fixed or scrolling, whose text content is periodically updated.
• LED whose color and/or intensity is periodically updated.

More problematic, possibly not acceptable:

• LED animation in real time (as opposed to stored and replayed scripts).
• Continuous text display updates.
• Streaming audio or video.

So how can I define the data bandwidth of the aiosphere? I could say one transmission per minute per device maximum. This would be a good starting point. But then, how much data can be in one transmission? Zigbee has a 200 byte packet limit I think. So if I said one packet per minute, then the systems are limited to whatever behavior they could wring out of 200 bytes per minute. Which precludes basically all except the most rudimentary scripting.

I could try something else, such as four packets per minute per device. This would mean that, assuming 250kbps is a real max network throughput, and realizing that all messaging in my system must go through the coordinator/gateway node, so the whole network is limited to that data rate.

So ten devices operating more or less continuously would each see an average max of 25kbps. This is about 2.5k bytes per sec. Packet overhead and negotiation must reduce this a lot. 2k bytes? Let’s try 1k bytes per sec. This is four packets 200byte packets per sec, which is plenty of data for most things I could see doing. Could even support audio, if there were not too many other devices on the net taking bandwidth.

Assuming I have a flexible bandwidth arrangement, so that a user could have one high-bandwidth device, or many low-bandwidth devices.  Would it be better to not restrict, but just let the network decide? This might, though, give erratic functioning on devices in different configs.  So be it.