Category Archives: xbee

Updated MRF24J40 arduino driver

Posted by KarlP on 17 December, 2011 3 comments

Thanks to pkarck my changes to improve the C library for Microchip’s MRF24J40 802.15.4 modules has been ported to the Arduino library. I’d written an Arduino library some time ago, but hadn’t been maintaining it as I don’t really deal with Arduino much these days. However, it’s gotten some love :) It’s now easier to use, and has support for the power amplifier on the MRF24J40MB modules, if you’re using those. It also makes some quirks I was dealing with in a mixed xbee/mrf24j40 module environment optional. In general, this collects up some of the various reported issues over the last year or so, and I didn’t have to do anything at all!

This is, “teh awesome”.

Downloads:

MRF24J40 with AVR SPI (atmega32u4) part3

Posted by KarlP on 28 February, 2011 2 comments

Update 2011 Oct 6 See Christopher’s comments below! Specifically, line 172 might need to be removed, if you’re using this with a pure mrf24j40 network, or a network that doesn’t contain xbee series 1 devices!
Update 2011 May 29 The sample code and library have been substantially upgraded. See my newer post for the details

And now I have TX working too. The microchip datasheet is _reallly_ sparse on details, and you have to go and get a copy of the actual IEEE 802.15.4 spec (either 2003, or 2006, we’re only concerned with the specification of the MAC header)

I had some problems trying to reconcile bit ordering between the IEEE spec (MSB rightmost, most of the time) and the Microhip docs (MSB leftmost, most of the time) but from there it pretty much just worked. I have yet to try out acknowledgements, I was trying to keep it pretty simple, but working code is working code.

Except… The microchip docs say that you write out one byte with the header length, one byte with the frame length, (header plus packet body) then the header, then the packet body. No gaps anywhere. Try as I might, I had to leave a two byte gap after the header, and before the packet data, when writing to the MRF24J40’s tx normal fifo. (And allow for this in the “length” fields)

I thought I had the addressing modes wrong, and my first two bytes of packet data were being used as some sort of header field I didn’t understand, but I tried out 4 different addressing modes, and in all cases, the data on the received side passed all checksums, and was only consistent with there being a _gap_ in the fifo.

Strange, but workable, as long as you know it’s there. It still makes me feel uncomfortable though.

For reference, I’m using 16 bit (short) addressing for both source and destination, PAN ID header compression (only destination PAN ID is sent) with no security.

The library code is over at github and allows sending packets to existing series one xbee listeners just like this…

mrf_reset();
mrf_init();
// set our PAN ID
mrf_pan_write(0xcafe);
// set our local source address
mrf_address16_write(0x6001);
// send something to a given node
mrf_send16(0x4202, 4, "abcd");

MRF24J40 with AVR SPI (atmega32u4) part2

Posted by KarlP on 20 February, 2011 3 comments

Update 2011 May 29 The sample code and library have been substantially upgraded. See my newer post for the details.

Good progress last night and today. I get an interrupt for each received packet, working in both promiscuous mode and normal mode.

A fair bit of code to get here, compared to using xbees, but SPI is much much faster, and you don’t need to dick around with baud rates and getting clock timing perfect. UARTs are terrible. From the datasheet, and the little bit of information you can find on the web, it seems that these modules have some rather odd silicon errata. It seems the original datasheet was completely wrong. This is the only thing that I can think of to explain why you need to set up so many registers just to get it to work. The defaults in the silicon are all worthless. Oh well :) It works :)

Note to self: be careful to use mrf_read_long() when you want to use a long address, the address spaces overlap, so using mrf_read_short works, just doesn’t return anything useful.

Working code to get this far, with an AVR host is over at github

MRF24J40 with AVR SPI (atmega32u4) part1

Posted by KarlP on 20 February, 2011 2 comments

Ouch, this took a lot longer to get started than I thought. SPI is meant to be easy right? All my SPI reads from the MRF24J were returning 0xff.

Turns out that, even with the /SS pin disconnected, if you don’t explicitly set it as an output pin in the DDR register, the AVR falls out of SPI mode if it ever goes low.

So, even though the pin is not connected, (I’m using a general IO pin to do chip select on the radio module) nothing worked until I explicitly made it an output.

And now, presto, I can read data from the MRF24J properly now! Now we can finally move on to the rest of this bring up.

(The MRF24J40 is an 802.15.4 module, with a SPI interface. It’s about 6€, vs about 20€ for xbees, and is on a standard 2.54mm pin spacing, instead of xbee’s 2mm spacing)

Contributing back to Open Source, trials and tribulations

Posted by KarlP on 29 December, 2010 None comments

So, back in March 2010, I started using xbee.py. It turned out not to do much of what I needed really, but it was a good base. The project seemed pretty dead in the water, but I fixed a bug or two, added some logging, and filed a bug with the diffs attached anyway. It wasn’t much, and it wasn’t pretty, but hey, if the project was alive, something would happen right?

And besides, it was now all working just fine for my needs.

Fast forward a few months, and the project has been resurrected by a third party. The code has been almost completely rewritten, and seems to have much fuller support for all the esoteric options I hadn’t needed. Oh, and the reply sent to my bug report never reached me, so I didn’t see any of this until just recently.

Of course, the released version _still_ didn’t have some rather important features I’d added, (it’s in trunk) and because of the rewrite, my diffs were now completely useless. And of course, the API has changed.

So where do I go now? Do I toss my local fork, resync with the “master” and try and get back on the train with the current open source base? Ignore it, and stay with my functional, working, battle tested, but feature limited version? (To be clear, my work mostly requires working with just escaped API mode, tx/rx only. The current xbee python project also supports transparent uart, remote AT commands, and remote IO transfer and ADC readings)

Seems like a bit of a loss all around really :( Should I have tried harder to get in contact with the original developer to get my patches in earlier? How much time should you really spend trying to patch open source software and how much time should you spend using it?

I’m well aware of the massive cost of maintaining local forks, if you actually do want the new features, but sometimes it just doesn’t seem worth it :(

FWIW, my version is still at github, and still very much in use here at home.

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