Freitag, 20. Januar 2012

A package for sensor data

As mentioned earlier, i thought on how to transport the sensor data my wireless nodes gather.

As i want the nodes to be able to run from battery power, they should consume as few energy for transmitting data as possible. While my former experiments with TCP/IP were pretty exciting (its awesome that you can run a website wirelessly off an 10€ battery driven uC!) its hard to get a node to become a low power device once you have to take care of all the TCP/IP protocol stack.

So i switched to a very basic network layer, based on the RFM12 lib. When there is data to transmit, it is packed to a simple protocol structure and transmitted over the air as bytestream. I wrote a little class to do all the packing and unpacking work named RadioNodePdu.

Each measurement is represented as the following datastructure:


So for each measurement reading, we have its type (as 8 Bit int) and its value (as 16 Bit int). As a header we then just add the ID of the sending node and pack all to a compact linear bytestream:


This bytestream then is transmitted to the accesspoint, which then decodes it and translates it back to the sensor data. As the length of each channel structure stays the same, we can very easily get the number of channels from the received bytestream:


The single channels then can be accessed very easily by their offsets:


After the data is received by the accesspoint, its receive is acknowledged and then it is converted to a JSON string and posted to my monitoring server via a HTTP POST request. Then a PHP skript jumps in and does the further processing of the data.

The nice thing about this is, that with the type of data transmitted, my monitoring system can automatically "learn" the new channels, once a new node goes online. It creates a new "datafeed" and automatically assigns the correct physical unit and scaling factors to the measurement data, so you just have to name the channel.

Next processing steps can follow!

Mittwoch, 18. Januar 2012

A portable wireless temperature sensor node

I recently wanted to compare the energy consumption in our house with the temperature inside the fridge. It is an old fridge we bought used together with our kitchen, so i expected it to consume quite a lot of energy.

This is what the actual power consumption of the AC phase, the fridge is connected to, looks like:

(I scaled the Y-Axis to 200W so the big peeks get cut off)

You can clearly see, that there is a regular pattern in that graph. There seem to be two different devices consuming power: One is active for about an hour consuming roughly 100W and then pauses for ca. 2 hours. The other device takes about 40 W and turns on for 40 minutes, 14 times a day. Both powers add up when both devices are running simultaneously, that explains the humps on the curve.

My guess was, that the 100 W device is the old fridge and the 40 W device the pretty up-to-date freezer. So - how to find out? One could simply plug out both devices  - but that would defrosts the groceries inside the freezer and would be much too simple :)

So i build a wireless sensor for embedding in the fridge :) This is what i came up with:



It is a small plastic box containing a Jeenode equipped with a 433 MHz RFM12 transceive, with the antenna folded inside the box. It is attached to a 3xAA battery box and to a DS1820 one-wire temperature sensor via a 3.5 mm audio jack.

Most of the time it is in deep power-down mode, but once every minutes it wakes up and transmits the temperature reading out of the fridge to the 433 MHz accesspoint. I found it quite impressive that it manages to establish a bidirectional communication out of what is basically a faraday cage! This is what the reading from inside the fridge looks like:



As you can see, it matches perfectly the power waveform above: whenever the 100 W device is running, temperature falls - until it reaches the lower point of the controllers hysteresis. Power then turns off and the fridge start to warm up, unitl it reaches the upper hysteresis temperature .. and so on.

So, that was fun - next!