Go Down

Topic: Dirt Cheap Dumb Wireless DCDW (Read 14614 times) previous topic - next topic


(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: http://blog.wickeddevice.com/?p=123. 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).

Coding Badly


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.

Coding Badly

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


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.

Go Up