Dirt Cheap Dumb Wireless DCDW

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

DCDW on the old forum http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1294511428
DCDW provisional site http://www.dcdwireless.com/

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 as
sensor1: data
sensor2: data
sendor3: data
unless 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: 刘清清|西南交大刘清清|江西新余刘清清|华信通闹事员工刘清清|刘清清人品|刘清清简历

I just stumbled across this sensor transmitter & receiver shield that are pretty inexpensive

Two "development instances" of DCDWs are working...

Case A:

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

hey westfw thats a great idea.

74LV132 data sheets from Phillips HTTP 301 This page has been moved and from NXP http://www.nxp.com/documents/data_sheet/74LV132.pdf and even TI http://focus.ti.com/lit/ds/symlink/sn74lv132a.pdf show logic symbols with an independent Schmitt trigger for each input. DigiKey carries NXP and TI. Apparently TI does not supply these as DIPs but in the interest of science I'll spring for a SOIC adapter just to prove TI version of 74LV132 doesnt suffer the same problem as their 4093.

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. ]:smiley:

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.

PC boards v0.3 support all the modes, but they have a few problems.

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 ZZZTTTZZ*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.

Just a quick update, the DCDW boards v0.3 are being tried out for all the possible modes, so far so good.

One of the DCDW modes is similar to
Wicked Device Shop with
Wicked Device Shop
the main difference being hardware vs software, with wickeddevice being economically competitive since microcontrollers are getting cheaper than the gates that make them up :roll_eyes: Also DCDW is completely open source whereas wickeddevice is apparently not.

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.

(I'm half of WickedDevice)

A big thank you to CrossRoads for the mention and AltairLabs for followup. I should say right away that the node and receiver are both fully open source - Arduino code is available http://node.wickeddevice.com/?page_id=6. Our bad for not posting the node code sooner - it will be up soon on that page.

Battery life was a first order design consideration. I am guessing it won't be as good as the DCDW, but we have tested up to 10,000 transmissions, after which we got bored and stopped. It transmits once an hour by default, so that would be over a year of operation (the transmission interval is configurable). The act of transmitting uses most of the power - the microcontroller sleeps in between transmissions. Your battery tests will be very interesting.

The overall goal is to have a super cheap transmitter with sensible default behavior which allows you to plug in any 0-5v sensor circuit that you like, and a receiver which can collect data from multiple nodes (up to 64). It also needs to be reliable enough and long lived enough to be useful. The Node and Receiver Shield give you both ends of a one way radio link for under $25 total.

Here is a blog post about using one to monitor whether or not the mailman has delivered mail: Mail Monitor: Has my mail arrived? | Wicked Device Shop. It sends directly to an Arduino + 7-seg display, and does not use a computer. By default each node can have 3 analog sensors and 1 digital (switch) - this example just uses the switch.

MagicMike, thanks for stopping by !

AltairLabs has purchased some Wicked Device nodes and is setting up two wireless sensor networks;
DCDW on 315 MHz and DCSW from Wicked Device on 434 MHz. Will send some DCDW from the next batch to Wicked Device so you guys can play too.

Have started a new thread for DCDW vs DCSW Shootout http://arduino.cc/forum/index.php/topic,63138.0.html, a comparison of pros and cons between our two very different approaches using these wireless modules. Will keep using this thread for continued development of DCDW approach. The Shootout will compare things like battery life, cost, ease of programming, number of sensors, resolution and accuracy, and so on. Neither approach will be perfect for everybody.

You guys at Wicked Devices have been just great to work with, and you obviously have put a HUGE amount of development into making the sensor nodes cheeeep and the software library simple to use. Setting up a network of Wicked Device nodes is easy and fun, thanks for a great product!

Hi all - I'm (the other) half of Wicked Device... I just wanted to close the loop, so to speak, on the source code question with respect to the Wicked Node / Receiver. The code running on the transmitter microcontroller (ATTiny44A) has been posted at http://node.wickeddevice.com/?page_id=6, under the heading "Node Code". It's written for the avr-gcc compiler, and it's decently commented. That being said, I'm more than happy to answer questions about it, and to incorporate suggestions as made by the community, but this thread is probably not the best place for it...

I have got to say, DCDW is pretty darned cool peice of engineering. Kudos! I'm really looking forward to the DCDW vs DCSW Shootout http://arduino.cc/forum/index.php/topic,63138.0.html with AltairLabs. I think we'll both have our strengths and weaknesses, but in the end it's a really great opportunity to learn from each other! See ya there... at high noon (sorry couldn't help myself).

Would having two power supplies (e.g. 9V battery and some AA batteries) improve the power efficiency? Maybe eliminate the regulator?

I suspect that would work nicely for the Wicked Nodes. In my experience, the AVR processors work very well powered directly from batteries.

Not sure how you mean "two different batteries". Using AA batteries would last MUCH longer than a 9v due to the higher capacity. Eliminating the voltage regulator would reduce the quiescent current somewhat, and extend battery life. The regulator for DCDW v1.0 was chosen for its very low quiescent current, but you could easily bypass it and use unregulated battery for DCDW. Since DCDW does not use a microprocessor, it can run on a wide range of unregulated voltages.