Remote Sensing with XBees, Hardware

The schematic below shows a battery-powered wireless remote temperature and humidity sensor. The wireless part is provided by an XBee Pro Series 2, the humidity sensor is an HIH-4030 and the temperature sensor is an LM335a.

The XBee is configured as an 'end-device' and periodically transmits three analog samples to its 'coordinator': humidity on AD0, temperature on AD1 and supply voltage on AD2.

The most important design decision was to run the XBee standalone, without the aid of a microcontroller, which had several consequences for the resulting circuit:

1. It constrained the choice of humidity sensor to the relatively-expensive Honeywell part, which outputs a voltage proportional to temperature. (Cheaper parts, such as this one, output digital data requiring a microcontroller to present it to the XBee.) 
2. The Honeywell part demands a 5v supply, and the XBee no more than 3.3v, entailing the further purchase of an Explorer Regulated to step-down the supply voltage for the XBee. (This is not shown in the diagram.)
3. The analog inputs on the XBee can only read up to 1.2v, so each sensor's output must be passed through a resistive divider to scale it down.
4. To conserve power, the XBee spends most of its time asleep, waking only to read the sensors. Its ON/SLEEP pin is asserted when it wakes but, of course, doesn't supply the correct voltage for the sensors, so a transistor is needed to switch the 5v supply.

Had the decision to use a microcontroller been taken instead (using an ATtiny85v, say) the entire circuit could have run from 3v, considerably reducing cost and hardware-complexity.

(The diagram was made with Eagle for which Sparkfun provides a library of circuit elements for most of the parts it supplies.)

The software side of this project will be described in a subsequent posting.

Open Source is Wonderful, part 94

A couple of years ago, I bought an ICE Tube clock kit from Adafruit Industries. Not having touched a soldering iron in twenty years meant that I found this quite a tricky build, wiring the tube in particular. (However the online instructions were excellent, and can only have improved since.)

At the time, I'd spotted that at its heart was a programmable chip of some sort but having no idea what an ATMega was: I was happy enough to have built the thing and bask in the reflected admiration of visitors.

Until last night, that is, when I noticed that it was out by five minutes, having only been adjusted six months earlier! Comparing this with my ancient (though also digital) radio alarm-clock whose time is only adjusted after a power-cut, I wondered if I didn't know enough about AVRs now to modify the firmware to implement some sort of drift adjustment.

So I googled "icetube firmware" to find the software it had come with, and discovered there are at least four different firmware versions available, two of which have a drift adjustment feature. I went with jsgf's one, which has a bunch of other cool features, such as day- and night- brightnesses, animated transitions and the ability to turn off the seconds' display altogether (this was a deal-breaker for me originally to use it as an alarm clock).

So I ripped out the chip, discovered it was an ATMega 168v, and threw together a programmer for it, based on the In-System Programming article below --- I've updated the table there with pins for the ATMega series. Total time to implement this feature thanks to OSS? 30 minutes, as determined by the amount I had to update the clock by when I powered it back on!