Category Archives: avr

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 :)

avrdude: initialization failed, rc=-1 clocks, prescalars and fuses

Posted by KarlP on 23 February, 2010 None comments

So, if you’re trying to program your avr, and you get this message

$ avrdude -p attiny85 -c usbtiny -u   -U flash:w:tinytemp.hex 

avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.


avrdude done.  Thank you.

And it worked before. What on earth went wrong? So you check the wiring. But it’s good. Of course it’s good, you haven’t touched it, you just recompiled and hit program again. So you hop online and find people saying a few things like “check the wiring” and a few hints, that perhaps there’s something to do with -B and matching up clocks. Here was me thinking that the programmer put it into reset and then provided it’s own clock via SCK, so who the hell cared what the device clocking was configured at.

I’d just done some power trickery, slowing down the clocks and timer scalars and resetting them at runtime, brining my boards power consumption from ~70mA down to 1.5mA at idle, but now the damn thing wouldn’t program! I couldn’t believe that avrdude had wrecked the fuses or anything, I’d have no warnings or messages, it just stopped working.

Lady Ada suggested that -B 32 should enough for just about anything. It’s not. But after an hour of double checking wiring and even pulling the chip out and putting it on a dedicated ICSP board, and getting the same damn error over and over, I tried drastic measures. I had even tried a virgin chip, straight from the foil and tube. It worked just fine, my chip, nothing. But…

avrdude -B 100000 -p attiny85 -c usbtiny -U lfuse:r:-:b

-B 100000 worked magic! And now, for god knows reason, it works again normally now too. *grumble*grumble*

Update: It still happened fairly often, but I got away with it at -B 300, which is much faster for programming than -B 100000