R.I.P. electro stuff
Let me start with the good news. The electronics are in! The LEDs are looking exactly as the other one so that shouldn't be any problem.
What actually IS a problem is that I fried some of the parts... So some mysterious reason one of the Xbee modules just stopped working after a week of continuous action. I have no clue why but I sure do hope it won’t do it again.
The LED drivers are a different story. I tried them in a breadboard with the example code and it worked very well without any problems.
Connecting the prepared PCB to the PSU, arduino and LEDs made a big difference. The chip got 100+ degrees and didn’t do anything anymore afterwards. Obviously something was not right. Checking the wires made clear that the TIP48 were not insulated from the metal plate and made a short circuit. After insulating them I gave it another shot with the second LED driver. Didn’t get very warm now, looks good. Lady luck wasn’t on my side this time either. It overheated in just a minute and again chip 2 was dead. Rechecking the wires showed that the ground pin was not connected to anything. How stupid… I think we have to order new ones and make sure everything works fine on the breadboard before using this PCB. Otherwise just make a new one.
Till we meet again.
'KnightRider' test with 16 LEDs
X-Bee, the final chapter?
Here another update on the X-Bee’s. Last week I got a point to point communication. The API mode did not have much advantage over the AT mode for now if everything is broadcasted over the network with an identifier so that the destination node can pick it up by looking at its identifier. Maybe it’s not the full advantage of the X-Bee but it will suffice for now.
Last Thursday everything worked without any problems. I checked the range which indeed is about 20 meters without data loss from two different routers sent to one coordinator. So the next step was to let the two routers communicate and give an output from each other’s sensors. Here things got messy. I managed to change the CTS and RTS properties of the serial communication which led to mayhem. The X-Bee’s could not be found, unable to communicate with the computer and therefore ‘bricked’. I decided to let it rest in the weekend and put on my bravest boots and tried it again. This time with a little help of google which came up with some reset functionality which turned to also not work. After some ‘maybe try this’-help I finally got it. Keep pressing the reset switch and force the firmware from X-CTU which did the trick after 3 times. So now I am back to where I was two days ago.
In the meantime the breakout boards from sparkfun arrived and are soldered. If the modules I have now are working properly and respond to each other, I can try to make standalone (end) nodes. Fortunately this is the only electronics obstacle I encountered until now. I want to finish this X-Bee by making a demonstrator that is linked to exploring the indoor climate. How is going to be in the next post.
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