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.

So, assuming for the moment that I take the technically simpler route of asking everyone to buy two objects, a gateway and their desired device.

What will this gateway look like? Will it be a functional device too? Or just a black box? I would much prefer it to be a device. However, this would mean either that everyone is forced to own a single type of device (say an orb or similar) in addition to the device they actually wanted, or I have to offer every device in both gateway and plain form.

Erica suggests some sort of modular system, either internal, allowing all devices to be either gateways or end devices, or external, allowing the modular element to plug into the device.

In the latter scenario, one could, for example, have a little box which has a power connector, an ethernet jack, and one or more mini USB jacks. And all standard devices have a mini-USB connector. So they can either be connected to the PC directly, or to the gateway hub, or to a simple power supply with a mini USB connector, like a cell phone works.

I see that here too I have the same type of problem: how does a device know whether it is a router or a coordinator? How do multiple devices on the USB bus, for example, decide which should be the coordinator for any radio traffic? How does the main system find directly connected devices on the USB bus?

I think this is all far too expensive and complicated. I think that I can fairly easily support both local and global systems, if I simply design around a gateway.

OK. So next, what does this gateway look like? Is it pretty? One idea I had was a white plastic cartoon cloud, like a lamp in the kid’s dept. at Ikea. And it has a single high-brightness RGB LED in it. And it has a knob, which allows the user to configure it. Or it doesn’t have a knob, and the user must configure it from the internet or wherever their control system lives.

Lamp

If it has a knob, perhaps it has the features of the RGB lamp I designed some time ago: the knob is the sole input device to the system. The system can be used as either a simple lamp, or as a network feedback device. In lamp mode, the knob is used to set the rate at which colors cycle through the display. This allows the user to speed up the rate until the desired color comes around, then turn the rate down to zero to freeze that color. The knob might have a detent switch too, which allows the user to turn the lamp off. This is a nice system but it has the basic problem that it controls color, not intensity. Also, in my initial configurations I didn’t include white, which this lamp should somewhere in the spectrum.

Wall lamp

I imagine that this device could hang on the wall behind your desk, for best radio function, or could also sit on your desk. So I guess it is pretty 3D, and has a fairly small footprint. Or, it is shaped such that though flat, for good wall hanging, when on a desk it sits upright still. Some combo shape.

Prox sensitive

I could pull in my PSI lamp idea, and use the Sharp sensor(s) to create proximity control. I could use PIR. I could use simple reflective IR instead of the complex Sharp systems. I could use multiple points of IR reflection, so that the user controls the system by hand placement. Or, all this is too complicated. Maybe the system just gets configured through the network. But isn’t this against one of the basic principles of the aiosphere?

Multiple RGB points

Another idea I had was, instead of being a lamp, the cloud-shaped device has multiple (say ten) RGB LEDs. These could be controlled programmatically from the network. Such a system could be used to display a clock (by using one color for hours and one for minutes and optionally a third for five-second increments), but might also be used to display basic network information. If there were an RGB LED in the middle as well, then the system could use that LED to represent the gateway, and the others to represent wireless nodes. Colors could change to represent data passing through the system. But do people care about such a visualization? Not sure. But does it matter? It is possible that the system could simply present an array of LEDs, and the user could select a driver which makes it function as they desire.

But I think possibly this an aio, not a gateway. Maybe I will make the gateway much simpler. Maybe it has no UI features at all, save a single RGB LED which can be used to show network traffic, but can also be turned off by the user if they don’t want blinking. OK, then maybe the minimum gateway object is an orb? Or maybe the minimum object is nothing but a reasoably good-looking totemic object, like a green pyramid or something. Maybe it is just about shape, not light or interesting function.

I suppose that, instead of creating an Ethernet-Zigbee gateway device and a bunch of Zigbee devices, one could also just make WiFi devices, if the chipsets and firmware support infrastructures are developed out enough yet so the costs compare favorably. But a quick survey suggests that WiFi still isn’t there yet. Lantronix makes the WiPort, an embeddable module which is sort of easy to use, and Mouser distributes it for $120/1, $100/10. DataHunter makes a G device called the Radion, which is $80/1 Nanoradio, and similar vendors make chipsets and modules which come way down in volume, but these are hard to get, hard to find dat for, and I believe don’t provide the TCP/IP stack etc. So, from my perspective, that of a glorified hobbyist, WiFi is still far too complex and expensive.

So I can either have this device be a separate device, or I can build this capability into all devices, which would raise the cost of each considerably. I am trying to figure out the correct balance between maximum flexibility and ease of use for everyone, and hardware cost and simplicity.

On a most basic level, the gateway is different than the other devices. So it would make all the other devices vastly more complicated if they had to also perform gateway functions. And it would make the system itself much more complex, as each element of the system would need to dynamically figure out what its role is. For ex, with Zigbee, a device is a coordinator or a router or an end device. In my basic concept, all devices are routers. But if I build gateway functionality into all devices, then…

Scenarios

1. Single Ethernet device: when a device is the only device, it is connected to the network (local or global) through a router, and uses Ethernet only. Radio is unused? No, device probably thinks it is a Zigbee gateway and Zigbee coordinator, and passes data into the local radio space.
2. Two (or more) devices, one connected to Ethernet and one (or more) out in the aiosphere: I believe this is simple and straightforward, and the device which is connected via Ethernet assumes correctly that it is the sole bridge, gateway and coordinator. And the devices which receives connection via radio knows it is a router/end device.
3. Two devices, both connected via Ethernet: this is tricky, in that it asks the devices, or the controlling system, or the user, to tell them what is going on. As they would both default to Zigbee coordinator roles, there would be problems. Unless the Zigbee system I choose has some automatic negotiation for such a system. Somehow one of the devices must be both a gateway and a coordinator, and the other must be an end device (then does it get its data through Ethernet, or radio? Who decides, and how?)

Solution A

1. Make a fixed gateway device,
2. Require that only one of these devices be present in a system,
3. Make all other devices radio only.

Solution B

1. Make all devices have both Ethernet and radio links
2. Make all devices capable of gateway, coordinator and router/end device functions.
3. Come up with some arbitration scheme where all scenarios can easily be resolved into a single functioning network with one gateway, one coordinator, and the rest of the devices router/end devices.

Advantages of solution B

• User simply buys devices and plugs them in, not worrying about anything, and they just work.
• All devices are functional, there are no ugly black boxes that don’t provide aiosphere end device functionality.
• There are no network setup steps, no multiple types of devices, no rules abut what goes where for the user to follow.

Disadvantages of solution B

• All devices have gateway, coordinator and router functionality.
• All devices have both radio and Ethernet hardware.
• All devices have Ethernet and power jacks.
• All devices are much more complex and much more expensive.
• Small end-device devices, such as battery operated devices, don’t follow this model. So even with this model, the user still eventually needs to deal with the concept of different types of devices?