Category Archives: sensor networks

Database size, column types, and retention policies

Posted by KarlP on 30 November, 2010 None comments

So, earlier I mentioned that I had a 700meg database of samples, and wasn’t even looking at them.

I started trying to look at them, and quickly had to add some indexes, ballooning the db out to about 950meg. This was clearly going in the wrong direction.

I looked at the table schema, and quickly realised that keeping the sensor sample time (a unix timestamp) as a string instead of a number was pretty wasteful, and likewise for the sensor type and node id. Although both of those can be given meaningful names, all firmware on the nodes have those as numbers as well, because it has to go over the wire(less)

So, simply changing the database schema from some string columns to some integer columns, and my calculator tells me I’ve gone from 90 bytes per sample, down to 32 bytes per sample.

Much better. And now that the date sample is a proper number, searching the db for date windows is much faster, without even needing the index.

And for added deliciousness, the python consumer, that writes into this database didn’t have to change at all, is it a string, is it an integer? It’s both!

That’s all well and good, but it’s still going to just keep on growing forever and ever, and with samples every 5 seconds, and (currently) 3 nodes with 2-3 sensors on each one, this isn’t going to slow down.

Do I really really care about that resolution of data much longer than a few days/weeks/month in the past? Shouldn’t I really just be averaging the older data out to get some general trends? Perhaps :) And that’s exactly what RRDtool is for, I just find it a little obtuse to use at times. (Mostly, I have to decide, permanently and forever, right now, exactly how long I do want to keep things. I didn’t want to have to decide that)

Footnote: For the curious, the schemas for sqlite3 were

CREATE TABLE karlnet_sensor (sampleTime text, node text, sensorType text, sensorRaw real, sensorValue real);
CREATE TABLE karlnet_sensor2 (sampleTime integer, node integer, sensorType integer, sensorRaw real, sensorValue real);

And 32bytes per sample, with 4.7 million samples for the last three months, is still 150meg (I tossed some old data, when the node firmware was all in flux anyway)

Back in action… power meters and sensor probes.

Posted by KarlP on 13 November, 2010 None comments

So, after a six month break or so, and a 700meg database of sensor data I wasn’t actually looking at, I’m back in action!

I finally bit the bullet, bought a commercial power meter, and finished off my power meter project. It’s based on: Open Energy Monitor v3 but mine is in regular C, instead of arduinoC, because that fits in better with the common code for the rest of my nodes. (Not all my nodes are arduino compatible hardware) Calibrating was a bit of a pain, but it’s working! Now to get it boxed up and attached somewhere a bit more useful. It’s currently tying up my only spare AVR chip, so it’s not live.

What else? I bought some sexy radio boards from Dresden Elektronik that look pretty neat. Basically combining an AVR with an xbee, in a smaller package, for the same price. Why did I ever actually get into xbees? I should have done more research on the available radio options :) If I wanted just radios, I should have looked at these MRF24740 radios from Microchip I’ve got some on their way, but haven’t tried them out yet.

One problem with both the xbees and the dresden boards is that they’re on 2mm and 1.27mm pitch pin headers. This is nice and compact, but not very friendly for breadboards :)

Which brings me to customer service! Dresden actually phoned me up about 2 weeks after I bought the boards to check how I was going, and if there was any engineering help they could give me! Awesome! Pity Icelandic customs had only finally released the modules to me the day before, and I’d only just realised just how fine pitch 1.27mm really was :) Again, I should have read a bit more first.

Still on customer service, I ordered some pin headers from Samtec Seems 23pin female sockets, 1.27mm pitch are not something that mouser/farnell/RS stock, but Samtec is actually one of those lovely manufacturers who ship small quantities direct, worldwide, for reasonable prices! Excellent! So excellent in fact, that they shipped out the 1.27mm sockets as soon as they were ready, and the 2mm ones (for more xbee based boards) two days later. So I get two _enormous_ toblerone packages (triangle tube, about 13-14cm/side, 90-100cm long?) Delivered separately, with 20 rather teensy tiny little sockets all up. I’m sure if I was in a hurry this would have been excellent, but it felt a little excessive really :)

But socket headers are not going to help on a breadboard, it’s still fine pitch. So I’m also back into PCB design again, something I haven’t done since uni.

Lots of excitement. Oh yeah, and software too of course. I mentioned at the start that I wasn’t really looking at any of the data. Well, now, I am and also in other ways making more use of the fact that I was uploading all this data to pachube for so long!

It’s good to be back, but it has meant I’ve been spending far too much time in front of the computer again :)

Pachube exporting now in place

Posted by KarlP on 13 March, 2010 None comments

Pachube is an interesting looking site. They don’t really seem to have all that many users, but hey, if they’re going to graph all my data for me, cool. It’s not exactly top secret information. I still don’t have things like the (new!) humidity sensor calibrated, but hey, it’s uploading, and it’s graphing.
TinyTemp has the initial atTiny85 based temperature sensor, and FreqyTemp has the new mega328 based temperature and relative humidity sensor. (more on that still to come)

The max/min values are off from some errors I was getting while I was setting this up, but hey, the more data exports the better right?
Github has the code

stomp: more with less. Publishing for the masses, rather than doing everything yourself

Posted by KarlP on 8 March, 2010 None comments

The early prototype head end software for karlnet did all the decoding of the wireless frames, and also handled doing something with the data, in that case, sticking it all into RRD databases so that tools like Cacti could make me some pretty graphs of the temperature. Now, that sort of architecture doesn’t scale very well, and it was about to become quite a pig when I started adding more nodes.

I already had more things I wanted doing, I wanted webpages, I wanted to try out some different RRD graphing engines (cacti is a bit of a pig to configure, but it does make nice graphs)

What I really wanted was to put all the hard work of reliably slurping data off the xbee network into one place, and put all the user applications that use that data somewhere else. (Reliably reading off the xbees is the topic of another post)

I’d been very happy with python for the serial decoding so far, but I certainly didn’t want to restrict myself to just python. I also wanted to make sure that anyone who wanted to could write an application using the data, not just me. A message bus was exactly what I wanted, and although it’s a little bit of a “big enterprise buzzword” it really doesn’t have to be. Or at least, you don’t have to be scared by it.

Stomp is one of the simpler, lighter weight message bus protocols. With a suitable “broker” (the name of the magic blob of software that handles all the messages) you can quite easily publish a message, like, “node:1, sensorA: 19 degrees Celsius” and then _anyone_ else who had registered that they were interested in receiving temperature readings would be delivered a copy of the message. Whether there was one listener, or one hundred.

With the 5 second pub/sub overview out of the way, how did I do it?

ActiveMQ is a well established solid player in the message bus world, and although traditionally associated with JMS messaging, it also has built in stomp support. Surprisingly, there was no package for activemq for ubuntu 9.10, but the installation is straightforward (some new skills learnt will go in another post) and then the instructions for enabling stomp are very clear.

Now, trying it out! I use stompy for python support. I also tried stomp.py, but it did nasty things like swallowing keyboard interrupts, so you couldn’t kill your scripts with ^C. I don’t recommend it. I simply tried it first :(

Stompy was easy!

import random, time
from stompy.simple import Client
stomp = Client("hostname of activemq/stomp")
stomp.connect()
while True:
     stomp.put("fake sensor1: %d" % random.randint(0,50), destination="/topic/karlnet")
     time.sleep(5)

Tada! And likewise for any receiver…

....
stomp = Client("hostname")
stomp.connect()
stomp.subscribe("/topic/karlnet")
while True:
     message = stomp.get()
     print "hohoho, we got some sensor readings: " + message.body

Now that’s cool, but we’re only sending fixed strings there, we want real objects! We need to be careful not to use anything python specific here, because we can’t control (and don’t want to control) who’s listening at the other end. XML or JSON are probably the simplest choices here, though you could come up with your own custom scheme here, even just manual string parsing, if you were you were really masochistic.

I chose JSON, mostly because my day job has enough XML, and JSON seems like a perfectly reasonable alternative. The python standard library json might be enough for you, but my message format is an object, not a dictionary of key/values, so I had to use jsonpickle

So, the final shiny fake sender / receivers are in svn, and in the same consumers/producers directories, you can see the two real apps, the main producer, reading data from the base station Xbee, and a simple script that updates RRD databases. That code is beautifully simple now that it’s been extracted out of the nitty gritty of the sensor network code.

Finally, for an example of what can be done now that we live in the future, have a read of Stomp on WebSockets and perhaps even a look at consumers/simple_web in svn.

TinyTemp: karlnet sensor node 1.

Posted by KarlP on 7 March, 2010 None comments

Also known as, massively overpowering a tiny system. With 2 xbees, and 2 xbee adapter boards from adafruit, making it easy to try things out on some breadboards, it was time to get to work.

I had to get setup for embedded development again, and with orders from overseas taking a rather long time to get to Iceland, I made do with what I had on hand.

ATTiny85’s are cool little chips. Not every day you get happy little 8 pin PDIP packages that can do so much. Not many pins mind you, but still, it’s so TINY! and it’s not even surface mount!

So I got one of these set up on a board, after some basic blink testing, set about putting together “TinyTemp” probably the most outrageous wireless sensor mote ever made.
Schematic for TinyTemp

There’s lots that is “wrong” with this design. It’s ~$US35-40 in parts for starters. But, that isn’t it’s purpose. This is really just a development node. Any serious node would get done up on it’s own board, which would reduce the partcount, reduce the size, reduce the cost, improve the reliability, and certainly improve the professionalism :) (Also, [2])

It’s something that I think JeeLabs are doing slightly backwards. While I love their boards and their designs, I kind of feel that their fixed base board with extension modules is not the best permanent solution. I’m not sure it provides the best development environment for working on something better either. Or maybe I’m just jealous that he has so many good bits working already :) (Also, they’re nice and cheap!)

I’m happier with some fairly ugly prototypes on breadboards, and then getting some boards made just for that node, and nothing more. I don’t need them to be physically expandable. If it’s just a tiny, compact node that does one thing well, it should just stay as one tiny compact that does one thing well. If you need more, you get a different node, or you put two nodes at the same location.

But back to the board. I had a few goals that I wanted to explore with the board.

TX through the xbee

I only wanted to send data, and I didn’t need to be doing anything else, so I needed to get the USI module to do ordinary old UART to talk to the xbee. A bit of an adventure in software, and app notes from atmel, and counting bits in microseconds by hand Wondering why there wasn’t a reliable software uart library. Finding out that most of my problems were a very flaky serial port on one of my computers, and it was simply mangling all the data. Primary mission accomplished. [1]

power consumption

With the radio turned on, and simply using busy waiting for the 5 second interval between sensor readings, and running on 5V, at the default 8MHz, the board was sucking down ~70mA. Wayyy to much to run on batteries!

Enabling pin sleep on the xbee’s, and using up one of the valuable io pins on the tiny85 to switch the radio on and off for only long enough to send the data burst was a massive reduction. Straight down to about 20mA.

Next was actually sleeping in the AVR, instead of busy waiting, which reduced it further, but not as far as I would have liked. Then, I cut the clock down as low as it would go, so that a single timer overflow would take the entire 5 seconds. That got me down to about 5mA, which, running at 5V with a venerable, but leaky 7805, was about as good as I could get.

Until, remembering that the xbee was 3.3V max, and the adapter boards had an onboard ultra low quiescent current regulator (good job lady ada) I rerouted the battery through the adapter board, and ran the whole thing off 3.3V instead of 5. Presto. Down to 550uA

There’s a few more tricks that could be pulled yet, but that’s enough for now. (For instance, it’s _possibly_ less power to use cycling sleep on the xbee to wakeup the AVR, instead of the other way round)

Full source for the node, as well as the kicad schematic files are available in the karlnet svn repository

Now, with one real node alive and sending data, it was time to get onto some server software.

[1] There’s something very very screwy with the USB-serial connection on one of my computers. It doesn’t happen on any of the other ones, but one one, (unfortunately the one best suited to being the always on base station) The serial port seems lose a LOT of packets. This was exceptionally tedious, until I ended up with a LOT more error handling in the xbee-api mode python receiver. It will still drop packets, but now it reliably recovers within 3 packet times, before it could get some bad data and block almost forever. I’m not sure, but I feel it’s a kernel problem related to some changes in lirc usb polling rate. Kinda hard to prove though.

[2] Xbee’s actually have onboard ADCs, there’s no particular reason to put another micro on the board. Or is there? In this case, probably not, I could just use cyclic sleep with a nice long delay to get it to sample the thermometer. But, maybe not always. Cyclic sleep is still more power consumption than pin hibernate. And in a lot of cases, you might want to actually control something locally, and that’s not something you can easily do with sending pin change packets to a solitary xbee.

karlnet – a wireless sensor network that hopefully doesn’t suck.

Posted by KarlP on 7 March, 2010 2 comments

I’ve been thinking about wireless sensor networks a lot, and for a while now. It’s something I’ve always been interested in, accumulating vast amounts of data and making pretty charts. But not just sensing, also control. I home brew beer, and also make cheese from time to time, both of which benefit from temperature control at the very least. Custom controllers for brewing or cheese making are quite common, and if you add the words “arduino” it even becomes ?cool?

So, why can’t these be the same devices? And why are all these controllers implemented completely locally? Things like HABS are cool and all, very neat bits of engineering, but why on earth do I want the times of my hop additions to be stored in EEPROM on device itself? And why are all these wireless sensors so expensive? I can get a nice weather station, max, min, humidity, indoor outdoor, but no data logging. The minute you add wireless datalogging the price jump is rather more than I feel it should. And heaven help you if you think “this has been done in industry, surely they don’t pay so much?” Well, seems they do.

So, enough rambling background, what am I going to do about it? Well, my basic idea was to have a bunch of nodes (I think “mote” is the word du jour) that are totally dumb. They can read some local sensor values, and if told to, turn on or off some outputs. But mostly, they just send raw unprocessed data back to base. And then instead of doing application programming for a brewery control system in embedded C and counting bytes and memory accesses, we can use any language we like, with any user interface we like, using nice tools that we like.

Seems simple right? Why isn’t it done? I’m not sure, and I really haven’t done as much research as I could have, but suffice to say, I can’t go down to the store and get 4-5 temperature/humidity monitoring units, a single base station, dumping data in any open format that I know of. At least, not cheap.

And, of course, certainly not as much fun as reinventing the wheel in the name of training. :)

Which brings us to the hardware. (The software can always be fixed and shipped later right?) I’ve gone with Xbee’s, or plain 802.15.4 for the wireless layer. These are pretty nice, reasonable throughput, low power, good enough range for reliable in home monitoring, security built in, and cheapish. At least, I thought they were a steal when I first found them. All this in a drop in module for only $US20 woot! Bluetooth or wifi cost double or triple that, and though you can get some FM modules, and 400MHz modules, you then have a lot more problems with interference, and you miss out on the built in addressing of 802.15.4.

I’ve since found things like Hope RF’s RFM12b and friends, which seem to be a pretty good compromise in between. Anyway, if the general hardware and system design is ok, it shouldn’t be a problem to have multiple radio types in the network right? As long as the base station can understand them all, you should be fine.

So, Xbee’s for now. For microcontrollers, AVRs win hands down. Being able to use plain old gcc, with plain old C, on plain old chips is a huge plus. Also, given how plentiful flash and ram is on even the tiniest little 8 bit microprocessor these days, you don’t even have to use ugly plain old C. The rise of physical computing, the trendy new thing for artists to be involved in, has brought about some very welcome changes in the world of the embedded hobbyist. The arduino platform, simplifying and hiding a lot of the ugly guts has done magnificent work, and has led to wonderfully low prices on high quality dev boards. Have a look at Modern Device or JeeLabs or pjrc’s Teensy for some good quality development and hobby boards. The dev boards I cut my teeth on in university cost nigh on $100, were 5 times the size, and had a fraction of the power and capability. Technology, plus a massive surge in demand, (I’ll even shout out to Make for some of it) has really brought out some great designs, at great prices.

There are some other great microprocessor options, looking strictly at a features/price point, but you need to be prepared for custom tool suites, or worse yet, paying for tools. No Fun.

And that’s the general idea. A bunch of dumb (yet very smart and overly powerful) AVR micros, hooked up to a bunch of simple, easy, cheap(ish) xbee radio modules, just sending sensor data back to a base station, and being told what to do. Put all the smarts up in an environment where it’s easy.

Over the next few articles/days/weeks I’ll be expanding on this, with what I’ve done so far, and where I’m at in my own personal implementation of this :)