X-Bee part II
As you could have read in the previous post I was wondering how to make more advantage of the ZigBee protocol. The first was to look at the difference between the AT and API mode.
API stands for application programming interface and is an alternative to default transparent mode (AT). The difference is that it allows the programmer to change parameters of the X-Bee without entering command mode as is necessary in AT mode. The main advantage is that data is being transmitted in packets instead of direct serial data. Every packet is checked upon delivery and a confirmation is returned.
I am not sure whether the AT mode also has the same functionality. AT mode is much easier because it can be sent directly as a string instead of being transformed in the API frame with a beginning, end, identifier and a checksum.
The breakout boards for the X-bee modules have been ordered to make it standalone motes instead of arduino operated. I think this will take about a week before the boards from sparkfun are here. In the meantime I am working on other things like finding a useful x-bee library for the arduino that can send signals to specific devices by an ID instead of an IM with a low and high value. I am going to dive in the arduino playground/forum for that.
There is another breakthrough in the sensor arduino-sensor readout area. I managed to get an FSR (or any other analogue resistor) working on the arduino and make it send its data when it is requested by another X-Bee module. Just like a STH71 temperature/humidity sensor which seemed quite complicated with a clock and data signal. In the end it was just finding the right arduino library. Open source makes my design life much much much easier.
Arduino with Xbee and Analogue Sensors (CO2, FSR, Temp/Humid)
X-Bee
What is X-Bee?
X-Bee or ZigBee is a wireless protocol based on small low-cost, low-power digital radios. The advantage is that the range of small radios can cover a large area by mesh networking instead of Wi-Fi or Bluetooth.
Information
An X-bee network consists of 3 types of devices: a coordinator, router and end devices that operate in Personal Area Network (PAN).
The coordinator is the initiator of the network. This part determines the channel and PAN ID of the network and allows routers and end devices to join the network. There can only be one per PAN. After the initiation it behaves just like a router.
The router is used to transfer data across the network. It can be from the end devices to the coordinator or the other way around. It is used to extent the range of the network because of the limited connections per coordinator.
The end device is can be hooked up directly to a few sensors and can get into sleep mode. The advantage is that the power consumption is a lot lower because the RF is only turned on if the initiative comes from its parent, the router or coordinator that let the end device on the network.
XBee Overview
First tests
ZigBee can be used in two different ways. The easiest way is a point to point communication. This is a direct connection from a coordinator to a router. The other one is a sensor network with different end devices which is the main advantage of ZigBee.
At the SPIRE center they work with arduino microcontrollers and have shields to enhance the arduino with ZigBee functionalities. The first thing to do is read different sensors that can measure parameters that are probably interesting for the indoor climate.
One of the sensors that is new to me is the CO2 sensor. It measures the amount of CO2 in the air and outputs a signal between 0.4 V (400 ppm) and 4 V (4000 ppm).
350-400 ppm is seen as clean outdoor air. The indoor CO2 level should be kept under 1000 ppm to make it comfortable for most people. In most places the CO2 level does not come to a hazardous level. The safety standard is an average of 10,000 ppm for 8 hours and 30,000 ppm for 15 minutes which highly unlikely in non-industrial workplaces.
(http://www.health.state.mn.us/divs/eh/indoorair/co2/index.html)
Xbee Point 2 Point
On the picture you see the coordinator (Xbee2), the router (Xbee1) on the breadboard with the CO2 sensor and in the background the values that are being sent.
The code worked flawless when used only with the sensor, but as can be seen with the X-Bee modules in between it brings new issues. The signal is sometimes dropped. This is probably because of the speed the arduino is reading the sensor and sending the data to the coordinator. The baudrate is 9600bps and the readout is every 100ms. This probably should be in sync to minimize these type of problems. I read something about a parity in sending, which I have to find out. If the message is not received correctly it will be send again until it returns the parity. When the end devices are used to send a value only when changed or asked by the parent, this is also better for the lifetime of the batteries and the amount of data that is transferred.
To do:
- End devices without a MPU
- Parity
- AT vs API mode
- Networking