The Final Touch
The provotype is nearing completion. It stayed here in the Netherlands with me for a week to get the final touch. Which was a lot more than I expected of course.
Let me start with the biggest frustration, the power supply. Back in the days when power supplies were plain simple and created with a power button that could turn it on and off, everything was quite easy. Push the button and the PSU (power supply unit) was turned on. Nowadays the ATX form factor is making it a little harder for us to hack the power supply to use it outside a computer. There is a little trick to make the PSU believe it is connected to a mainboard by connecting the green wire to any ground wire. Sounds easy, worked like a charm when it was connected to other peripherals like a dvd drive. Once removed and stripped, the PSU didn’t find any load on the power lines and decided to be smart and shut itself down for safety reasons (die by heat). Tricking it by connecting a 40mm fan would make it stay on all the time.
Everything seemed to work and I decided to remove all the unused wires to clear up the wire spaghetti. Here the weirdest thing happened. Connecting the green and black wire with a paperclip in the end of the molex connector worked perfect. But when I soldered the wires directly without using the molex connector it just wouldn’t start! So I reconnected the molex and tried again. Huh? Yes it worked?! Well if the PSU wants it this way I should kneel down and accept it (with frustration in my heart).
Another wise lesson that should always be taken into account is to connect all the ground wires of all devices used. Do not forget to connect the ground of the external device that is used to read the raw data of another arduino for example. Otherwise you end up with lots of bogus results.
Thanks for reading through my frustration which I promise you I won’t mention again in this post . Back to the fun part, building the casing. Due to the lack of results with the electronics I didn’t close/glue the casing. Last time I did it the PSU was fried and I had to cut open the glue lines again. This is in no way recommended for anyone. With the PSU up and running I took my chances, glued it down and the painting could begin.
Instead of a long probably not highly interesting story I just post the pictures.
So the challenge left is to program the lamp. The Xbee connection is still working. All the sensors are sending data which is received by the arduino inside the lamp. The LEDs are working with the TLC5940 LED driver. The servo is up and running. What is left is to combine the two and make it react to the indoor climate variables. This shouldn’t be too hard I guess.
Building the demonstrator
The time was there to build the indoor climate lamp. Now it comes down to what materials should be used. One thing that is for sure is that the arduino is used to receive the input from the Xbee modules. The logical thing to do is use the arduino to control the output.
For the output a light is chosen that can be seen during the daylight and would give a nice fluent glow when lit. Here at the spire institute they had a 3W RGB LED that meets the requirements. The only downside is the heat it produces, together with the transistors to drive the 350 mA current.
The material for the diffusion of the light was also a coincidence. In the research center was a piece of rest material they used for a projector screen which breaks the light in a fluent way. The only challenge left was to find the right material for the base.
Another electronic challenge was the power supply. The LEDs need approximately 3V per channel at 350mA. This comes down to roughly 1A per LED. In this case 5 of these are used so a 5A power supply was necessary to only drive the LEDs. Not alone 3V was needed, but also 9~12V for the powering of the sensor boxes. The best way to go is an old power supply from a computer. It has all these power levels and can deliver enough amps per line, plus at a university are enough old computers lying around that can be scavenged.
The sensor boxes are made out of foamcore which gives them a neutral look from a shape and color point of view. People should not reflect on the object but should use the object to talk about the indoor climate. The lamp should follow this neutral language.
The first try was to use 3mm foamcore to create the base. This turned out to be a precise job and was taking too much time to cut it neatly. The other downside is the durability of the material. It dents easily which makes it not the ideal material for transportation.
Foamcore mockup
During the ITD course I worked with a lasercutter to cut the materials from flat material and glued the whole thing together as a big puzzle. The material was changed to something more durable but still easy to finish, MDF.
Denmark, or at least Sønderborg, was not the best place to find a lasercutter that could cut MDF. The decision was made to do this at a company in the Netherlands.
Overview of the components
With all the loose parts together the big fun of building could start.
Inspiration
Because the plan is to build a lamp that responds to Indoor Climate factors, this seems useful for inspiration. Also controlled by an Arduino.
Hackea a lamp oriented Arduino workshop from AlluvioneMediatica on Vimeo.
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