Dirt Cheap Dumb Wireless DCDW

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
http://wickeddevice.com/index.php?main_page=product_info&cPath=23&products_id=96
http://wickeddevice.com/index.php?main_page=product_info&cPath=23&products_id=97

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.

I assume a 9 V battery was chosen to provide "high voltage" for the transmitter; that the 9 V is necessary for something.

By using two power supplies... the regulator can probably be eliminated (processor directly powered from battery), the processor can directly control power to the transmitter (via transistor), and the processor can be put fully to sleep. This should make it possible to reduce the idle power consumption to a very very tiny amount.

But that creates a practical problem: no one likes feeding two different kinds of batteries to their electronic gadgets.

DCDW could run on unregulated voltages up to whatever the transmitter can take. Sensor accuracy would degrade with unregulated voltage. I heard some versions of transmitter get hot if run above 5v, but in this case the duty cycle is very low. Wicked Node could run on unregulated from 2.5 to 5.5 volts, but the TX may not work.

A switching regulator would waste less power, but ones with low quiescent drain are rare, IIRC Seiko once made one for quartz wristwatches.

The easiest and cheeepest way to get long life is simply use a single battery pack of larger capacity. Alkaline AAs would last 6x longer, D cells would last 21x longer, would run a DCDW for 6.9 years. As if when 2018 rolls around I would remember where to find my DCDW nodes :wink:

DCDW battery life test enters a 3rd month with over 8v remaining in a 9v generic battery.

Details: actual battery terminal voltage (blue, volts, R axis) measured by DVM, transmit interval (red, sec, L axis) in this config indicates battery health. Note on Jun 27 the battery was accidentally fat probed (shorted out) while measuring voltage. The battery recovered but with unknown loss of capacity.

Actual voltage varies with battery temp as this was in my truck most of the time, getting alternately roasted and cooled every day. The reporting interval for a few days looks like this:

The thin line is the DCDW node reporting interval as seen and logged by Arduino. Sometimes packets are missed due to noise or collision, so this interval appears to jump to multiple times its actual value. Right now a spreadsheet formula in Open Office is correcting for this, which produces the thick line. This same processing might also be done in Arduino sketch before the data is uploaded.

Near 140 hours there is a gap where too many packets were missed for a correction to be applied.

The plot shows a definite daily cycle of about 5% due to wide temperature swings as the 9v battery roasting and cooling inside the truck. Other little wiggles are me driving somewhere or just idling the engine to recharge the truck battery. I run the air conditioner which cools and changes the terminal voltage of the 9v battery.

Aside from the minor variations, over the first 2 months the reporting interval has increased by about 30% while the battery voltage has dropped by about 20%. Plenty good enough to indicate battery health and allow adequate warning for replacement.

Since starting the test I have been on several trips, so far I have managed to lug everything with me on the road and keep it all running more or less continuously. The most difficult thing to keep running is WinDoze on a netbook using an inverter in my truck. Besides occasionally flattening the battery WinDoze sometimes crashes or loses the virtual COM port or the netbook otherwise needs to reboot. Eight spreadsheets of data like this have been recorded spanning the two months with a few small gaps. When the truck battery dies the Arduino does also, so it has been restarted a few times as well. The time column is the Arduino millis() counter, formatted as HH:MM:SS.SSS.

The DCDW node itself has no software and depends only on its 9v battery. It has run continuously without stopping since the end of April.