Dirt Cheap Dumb Wireless is a cheaper way to get simple sensor measurements.

Ladyada pointed out that Xbee nodes have enough brains that they do not need an Arduino etc to send an analog sensor reading, which cut the cost of a wireless sensor mote nearly in half. Here we use Old Skewl technique from the earliest days of space exploration to cut the cost much further, hence Dirt Cheap Dumb Wireless, using simple On-Off-Keyed RF modules such as $4 transmitter and $6 receiver from SparkFun et al. Add a 555 timer and a quad NAND gate and you get a simple node that can be configured to do several tricks: Send up to 3 sensor readings on a single channel -or- A swarm of motes that each identifies itself and then sends one sensor reading -or- ...other variations for remote control, security alarm, onboard battery monitor

PC boards v0.3 and parts are on order, development will resume when I return in a coupla weeks. In mean time here are some results before I left home.

A graph of outside and inside temperatures from two independent sensors of a "swarm".

This detail extracted from received data shows battery life:The reporting interval for blue and yellow motes (they share a 9v battery to save $$$) increases from about 900 sec to almost 1100 sec just before12 hours, before they have not enough battery power to operate. At about 36 hours installed a fresh battery and the motes start up at a reporting interval of around 600 sec. The heuristics to clean up data collisions do not yet work for reporting interval so its a noisy plot. Especially since two "gabby" motes were included to make the swarm as busy as a much larger swarm should be.

The new v0.3 PCBs have, without ugly hacks, all the possibilities of v0.1 and more, plus extended battery life and battery monitor in a swarm of motes configuration. We believe the new NAND gates will be *true* Schmitt triggers, avoiding the slow packet work-around needed by Texas Instruments chips, and making the swarm 2x to 5x more efficient.

Am on travel to Travis AFB and Edwards AFB for a coupla weeks, more when I return....

So does this really work out to be cheaper than using a small microcontroller with a real A-D to drive the same transmitter (adding some sort of low-speed serial data protocol to send real digital values.) The micro would be $2 vs $0.50 or so for your 555 + 40xx, but those aren't the major expenses anyway (dwarfed by the PCB and transmitter module.)

Yeah, I think I'd be tempted to just connect the sensors to an ardweeny or RBBB and that to the sparkfun transmitter.Need to develop your own data format that you'd be sending, maybe something as simple assensor1: datasensor2: data sendor3: datarepeatunless there is a lot more to these sensors.

But I must confess to having done no more so far than have a transmitter wake up on a keypress, send a single byte to a receiver so far via virtual wire, and then go back into sleep mode. Works very nice tho!

Here in Canada we have some interesting extremes of temperature. It is not unusual to have a temperature swing from around -40 to + 40C in temp. This is from our house near Lake Simcoe in "southern Ontario". One year we had a a few days in February of near -45, then we had a few days in August of +45C. Now normally it is a bit more moderate -- but in design you have to assume the extremes must be handled correctly as well. Anything placed outside must have mil spec or industrial spec components to survive -- it gets expensive. The simpler, the fewer and the cheaper the components the better.

The idea on the face of it is a good one --- particularly if the sensors RF portion can handle extremes of temperature and humidity.

I will probably try an XBEE or three regardless -- but this idea may be better.

Please excuse my sparse web and email access, I am currently reduced to a nomadic life and a finnicky space bar.

You guys are right, as was macegr, ya cant fight Moore'sLaw. You could do DCDW and more with a microcontroller, and those are gettin darn cheeeep. But the solutions proposed this far in Arduino community have been engulfed with "creeping features",they do not efficiently use resources or dollars. An xBee node is waaaay overkill, in both hardware and in dollars, just to get temperature.

DCDW is an "old skewl" solution that teaches basic electronic principles and economy of hardware design. There is certainly room for a "new skewl" solution using a reaaaalllly cheep microcontroller to dothis much and more, perhaps a DCSW = "Dirt Cheep Smart Wireless" as a follow on.

It would be wonderfulfor someoneto make a DCSW that beats or equals the cost of DCDW and provides the same or better functionality.

For WillR remember neither are the xBee nodes rated for extended temperature range so in any cae you willbe outside the component ratings. Fortunately the chips are the same in all grades and the packagesareconservatively rated. I have operated commercial grade to -78 C without functional failures, although the calibration was a bit off. You can try this with a slush of dry ice and alcohol or dry ice with acetone. So long as you ease the temperature down so there is no thermal shock (abrupt change in temperature) then commercial parts can survive some impressive extremes.

DCDW reminded me a lot of an old Sci Am Am Sci article (hmm: http://www.science-project.com/_members/science-projects/1968/03/1968-03-fs.html ) Good stuff, in general. But if you need to buy some sort of radio module anyway, it gets to be a more complicated question...

OTOH, I've also thought of hacking cheap bluetooth headsets to provide BT connectivity for arduino. If it has to send/decode some sort of modulation over the link (DTMF, even?), well, that's probably not all that difficult, and it might be worth the cost difference.

On the third hand, prices are highly variable depending on how many the "manufacturer" expects to sell, or something. Here's a serial BT module for $7: http://www.goodluckbuy.com/serial-bluetooth-rf-transceiver-module-rs232.html

I just stumbled across this sensor transmitter & receiver shield that are pretty inexpensivehttp://wickeddevice.com/index.php?main_page=product_info&cPath=23&products_id=96http://wickeddevice.com/index.php?main_page=product_info&cPath=23&products_id=97

The first has several DCDW temperature transmitters sending data to a single receiver, and a graph of the temperatures develops. The Arduino receiver is using a "read the DCDW" subroutine using Arduino interrupts, and passes temperature values onto a big computer for presentation. Remember... this is just "developer play"... not something yet generally available.

Case B:

The second has one DCDW transmitter fitted with two buttons, sending data to a single receiver. The Arduino connected to the receiver beeps one way when the first button is pressed, beeps a different way when the second button is pressed, and is silent when neither is pressed. This time, the software in the Arduino is done without interrupts. Remember... this is just "developer play"... not something yet generally available.

Howdy, home from the high desert ca Edwards AFB, from the Closed Source world, and trying to re-engage the Open Source world.

The only technical obstacle to DCDW was the misbehavior of "Schmitt Trigger NAND Gates" as "Gated Oscillators" which some manufacturers turned into "Voltage controlled oscillators". This made problems for the "swarm of motes" using "sensor plus ID" mode.

NAND gates that do NOT work are Texas Instruments and ST Semi. NAND gates that DO work include ON Semi and NXP.

As long as you buy NAND gates from ON or NXP it works fine. Let us set aside for the moment arguments by certain Gods that microcontrollers are becoming cheaper than NAND gates.

Here is the proof

OK these chips waiting on my doorstep were too much temptation, this was fun, but I got a car that wont start, travel expenses to submit, a tree that fell and damaged the house, laundry and much workto catch up on. Thanks all for your patience, More DCDW soon.

That's actually pretty cool. One thinks of this sort of chip as being a "jelly bean" that would be pretty much identical from any manufacturer, but that certainly appears not to be the case. Even the differences between the (working) ON and NXP parts are pretty dramatic...

Are you planning on trying an of the 74xx132 family chips? NXP apparently has a 74LV132 that operates down to 1V (and up to 5V)...

Then I can add the TI 74LV132 data to my graph and finally post a credible response to TI's snarky dismissal of my complaint on the their support site. ]

BTW The frequency depends also on the hysteresis, wider band = lower freq, thus the significant difference in the free running rate between manufacturers. But (for the chips that "work right") the graph is absolutely flat which is what DCDW needs for the "swarm of motes" using "sensor plus ID" mode.

The new low quiescent current regulator will greatly improve battery life in modes such as "swarm or motes" but the pins changed from the previous regulator, so ya gotta twist the leads around or it will **ZZZTTTZ**Z*Z poof the regulator. duh.

Should have removed the soldermask covering the cut-n-jumper pads for configuring the DCDW. duh. (the v0.3 pcb had no solder ma$$$k) Also the soldermask covering the "edge finger" type lands to solder on the RF transmitter module in case you want it mounted planar with the DCDW board.

One pad was incorrectly filled to ground.

Some capacitors did not fit well.

Cosmetic clean up.

Now to the good newz:

Using Schmitt trigger NAND gates that "work right" on each input makes the "swarm of motes" much more efficient, the "data" part of the packets can be 5x faster.

The battery life is up to 40x longer, in some modes DCDW battery could last a year or more.

We squoze in a minor mode or 2, like a "sentry mode" where it waits conserving its battery for months or years until triggered to send a message with its ID.

The checkout continues for all the modes this pcb supports. A version v0.4 is next to clean up the fixes but not add or change anything new.

The biggest need now is documentation, so everybody can play. DCDW is a whole Swiss Army Knife of modes. Most folks will be interested in just one mode so we should help them quickly find their favorite one without having to learn everything DCDW can do. OTOH some newbies could learn a college course worth of circuits, plus some old indian tricks and backwoods savvy, just by exploring the limits of what all can be done with one timer and a quad NAND gate.

Ideally one set of docs would be useful to the whole spectrum of users.

The only significant changes to DCDW are new volt regulator (for long battery life) has a different pinout, and some solder mask was missing some clear cutouts. We are ready to order v0.4 and take on interested beta testers who can work from schematic and code.

Update: DCDW in "swarm of motes" aka "single sensor plus ID" has been running for a month on a generic "kroger brand" 9v transistor battery.

Battery voltage is encoded in the transmit interval as a bonus. Last month the transmit interval was a bit faster than 10 minutes, it has slowed to a bit longer than 11 minutes and the battery is now 8.51 v during the quiescent time. This despite my accidentally shorting out the battery for several sec on Friday while trying to attach clips to wait for the transmit cycle and measure voltage droop. I didnt get the desired measurement, but the battery and mote are still chirping away.

Biggest difficulty is keeping the Arduino IDE alive for days and weeks to log the data. WinDoze and its hordes of crapware keep trying to reboot the netbook, and any jiggling of the USB causes WinDoze to dump and/or relocate the virtual COM port. Ideally a real logger mastering a swarm of motes would use an SD card etc.

Second biggest issue is 10 minutes is a very long RC time constant. With 100Meg and 22 uF the rate varies several percent maybe with humidity, light, whatever. Its not a precision voltage measurement, but its good enough for a rough estimate of battery life. I took no special effort to clean my greasy fingerprints off the PCB nor did I use any coating, either of which would probably improve the stability.

I'm gonna let this test run to completion. Meanwhile I have built a nice miniature Stevenson screen, and have hacked up a set of cheeeeep solar yard lights for a perpetually powered outdoor node.

Just ordered a few of the WickedDevice nodes for comparison. Victor has posted that he will release his source code soon, Huzzah !

WickedDevice is a completely different approach than DCDW, it is more like DCSW "Dirt Cheep SMART Wireless". It listens to the receiver noise as UART serial input and pulls out valid packets from the stream of garbage characters by using CRC and other validity checks. The code development is impressive.

It will be interesting to compare battery life and Arduino resources for our two different approaches. Compared to the "throw Xbee node$$$ at it" approach, either DCDW or WickedDevice should have far longer battery life as well as much lower cost. Maybe somebody using Xbee can post here how long an Xbee node will run on a 9v battery !

Will continue on with DCDW testing and development, v1.0 boards are ready to order, anyone interested in getting some let me know.