Zigbee Kit Documentation and Procedures
My deconstruction of the MaxStream Kit.
Some of the key documents from the kit.
1) Basic 4 page Zigbee Overview.
2) Basic Physical Layer and Dimension spec for Xbee and XbeePro modules.
Xbee 100ft urban, 300ft outdoor 45mA TX Current.
Xpro 300ft urban, 1mi. outdoor 215mA TX Current.
Remember Power decreases by the square of distance so increase is exponential as you move farther away. Can use 1 Power Hungry node to relay distances of up to 40mi for enough power.
Item 16529 from silicon solar will generate 100mA continuous in sunlight, and we should be able to operate in bursts.
3) Quickstart. Loopback Range checking example. Allows you to use a USB module connected to your PC to send and recieve back the same data (using a physical connection from TX to RX). You can walk around or put it in a microwave or fridge or something and see it cut out.
4) Xbee API documentation. Here are some excerpts, but basically this is still a serial port physically. I BOLD things I think are most important.
2.1.3. API Operation
API (Application Programming Interface) Operation is an alternative to the default Transparent
Operation. The frame-based API extends the level to which a host application can interact with the
networking capabilities of the module. When in API mode, all data entering and leaving the module is contained in frames that define operations or events within the module.
The API operation option facilitates many operations such as the examples cited below:
-> Transmitting data to multiple destinations without entering Command Mode
-> Receive success/failure status of each transmitted RF packet
-> Identify the source address of each received packet
2.1.4 Data In/Data Out buffers. This device supports CTS/RTS signals which allow the HW to signal when it's full in both directions. this feature can be enabled on the AT91SAM7S serial port.
2.2. ADC and Digital I/O Line Support. There is also support for digital counters. etc like the windspeed/direction or the little quantized rain sensor etc.
2.2.3. Sleep Support. Support variable sleep cycles, or pin activation. Can be used to save power for leaf modules.
2.2.4. DIO Pin Change Detect. Can break out of sleep on an IO pin (like that rain clicker or wind) and send a packet.
I will skip some, but there are many features like this that allow dumbed down sensors to be transmitted. For sensors or data inputs that are just a digital line (wind/water) or ADC (I'm not sure maybe we'll have some) then we can omit the microcontroller board and just configure them as a digital extension. This will not work for things like CO2 (need to talk on another serial port), or other embedded busses because of timing so we'll need a uC board like the AT91 to coordinate. However these boards have LOTS of IOs so they could read 8 other phsyical devices using the above methods as an extension and then send messages back using a different segment of the network.
2.3.1 - 2.3.3 These sections discuss how to configure the devices. This will play prominently in some scenarios but the details are contained in the document. This will again specifically pertain to using the physical layer features, while we will have some form of serial protocol overlay to transmit our messages between groups of sensor networks.
Then comes some meat. 2.3.3 Describes association. This differentiates between networks types. We can have a coordinator controlling some nodes which are local sensors which still relaying messages between other coordinators to a supernode we create that logs the info in a HD, sends it via cell, or long range Zigbee.
2.4. XBee/XBee-PRO Addressing. Here we cover info on addresses. This will be important as we will associate groups of sensors by having them send their messages through a local master if needed allowing dumber cheaper sensors. In the end all data will arrive to a few master nodes which we will provide a way to log the data or transmit it out.
At this point I realized that we could implement some level of data storage. A 4gig memory stick is $25 so I'm sure 1G is peanuts. This could allow low power nodes to keep sampling and store data, or for localized data storage nodes with longer ranges that can store data when power is low due to low sunlight or other causes. This could literally allow sensors to "come back from the dead" with a burst of data when the sun comes out!
2.4.1. Unicast Mode: This mode supports retries. We could use status pings to verify connectivity between some nodes.
2.4.2. Broadcast Mode: Mostly for discovering devices and coordination (i.e. assess the network).
2.5.3. Sleep Mode. Cyclic and two modes of manual sleep allow you to trade power cost for startup time but save power.
2.5.4. Command Mode
To modify or read RF Module parameters, the module must first enter into Command Mode - a
state in which incoming characters are interpreted as commands. Two Command Mode options are
supported: AT Command Mode [refer to section below] and API Command Mode [p54].
Basically this is the way you configure a module to behave as you want on startup. Basically this is the code that will have to be writte per device to define the behavior. This can also be done using a PC for dumb terminals utilizing aformentioned physical communications methods.
3.1.1 Has programming examples.
Basically you configure the modules as you desire, but they will still all relay messages unless you specifically make them leaf nodes. We can also layer our own protocol over the top and use it to associate clusters of sensors with a master that relays messages and logs data. Just about anything is possible and some of the nifty physical line features would make it easy to have wireless extensions as needed for say a high up wind speed sensor etc.
This is where all the meat is and based on our operational requriements we can define a network as we want. Creating nodes to bridge communications medium is trivial as well.
