next topic »

[on:]

Affordable and easy wireless sensors for Arduino.

Some folks started sending wireless temperature using Xbee modules and Arduinos at each node, which is quite expensive and inefficient.  LadyAda pointed out that Xbee can digitize and transmit an analog temperature sensor without the need for another uP at each sensor node, but Xbee is still fairly costly.  AltairLabs further showed far simpler ways to transmit a sensor http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1293839127 using just quad NAND gate and timer which developed into Dirt Cheep Dumb Wireless http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1294511428 or DCDW for short.

As DCDW development progressed on the new forum http://arduino.cc/forum/index.php/topic,51225.0.html some folks argued bkoz of Moore's Law http://en.wikipedia.org/wiki/Moore%27s_law that small microcontrollers are about as cheeep as NAND gates and much more flexible.  This was dubbed Dirt Cheep Smart Wireless or DCSW and considered as a follow-on project.  CrossRoads found the fine folks over at Wicked Device were already doing this. http://wickeddevice.com/index.php?main_page=index&cPath=23

Both DCDW and DCSW are based on those cheeep simple little RF modules from SparkFun http://www.sparkfun.com/products/8946 and others.  They cost only $4 or $5 each but getting a reliable and error free sensor reading thru these turns out to be a non-trivial problem.

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.  We will also be sending some DCDW from the next batch to Wicked Device so they can play too.

This thread is for the DCDW vs DCSW Shootout, a comparison of pros and cons between two very different approaches using these wireless modules.  For continued development of DCDW approach, use the Dirt Cheap Dumb Wireless DCDW thread at http://arduino.cc/forum/index.php/topic,51225.0.html

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, this thread can stand as a guide for those considering their options. 

Before the Shootout begins, I'd like to say the guys at Wicked Devices have been just great to work with, and they have put a HUGE amount of development into making their sensor nodes cheeeep and their software library simple to use.

[Reply #1 on:]

Battery Duration using a typical 9v alkaline of 550 mAh capacity:
WickedNode can be configured to transmit every 10 sec, 10 min, 1 hr, or on an external trigger.  The packets are just a couple of seconds long.  As supplied, the WickedNode draws about 300 uA when asleep, which should deplete a 9v in about 76 days.  Assuming 15 mA for 3 sec when transmitting, the battery could supply 44000 packets.  The projected life for a combination of sleep and transmit is:

Mode          Batt Life     sleep / xmit
10 sec    =  5 days        6.2% / 93.8%      << used for testing
1 min    =  22 days      28.6% / 71.4%      << not available as shipped, for comparison only
10 min   =  61 days     80.0% / 20.0%
1 hr       =  73 days     96.0% /  4.0%

DCDW is assumed to be jumpered for "swarm of motes" configuration, the one most similar to WickedNode.  DCDW transmit interval is set by a resistor/capacitor which can be any value, the 555 timer chip data sheet claims "from microseconds to hours" but in practice times longer than 10 minutes require special components.  DCDW draws 100 uA when sleeping, for 229 days of duration.  Transmit current is slightly lower at 12 mA, and the packet duration is set by another RC.  Assume 5 seconds, (which allows a greater precision of measurement) the current is slightly lower current but nearly twice as long, the maximum number of packets is only 33000.  In a combination of sleep and transmit the predicted battery life is:

Mode          Batt Life     sleep / xmit
10 sec    =  4 days        1.6% / 98.4%     
1 min     =  21 days      9.1% / 90.9%      << rate can be anything
10 min   = 115 days     50.0% / 50.0%
1 hr       = 196 days     85.7% / 14.3%     << difficult to achieve

Other factors:
DCDW has nearly 12 bits of resolution, it could probably achieve 8 bit resolution with a packet of 3 sec or less (resistor), which would extend its life to 33 days at 1 minute interval or 143 days at 10 minute interval.  WickedNode could be configured in firmware to provide a 1 minute interval.  WickedNode provides a 60 minute interval, but there is little advantage in using it, since by that time sleep current dominates battery life and changing from 10 min to 60 min only extends battery life by 20%.  In fact DCDW at 10 minute interval (its practical limit) lasts nearly 60% longer than WickedNode at 60 minutes. 

WickedNode uses a different voltage regulator, at AltairLabs we modified a WickedNode to use the MCP1702 regulator that DCDW uses, and Wicked node quiescent current dropped 33% to 200 uA.  This simple mod should boost WickedNode battery life to 83 days @ 10 min and 108 days @ 60 min.  Still not as long as DCDW, but every bit helps.

DCDW clearly has the advantage for projected battery life.  Lab tests are ongoing. 

AltairLabs may brag now but WickedNode has many advantages which will emerge in upcoming rounds of this smackdown, or shootout, or whatever.   We invite Wicked folks to comment, dissent, add to, or just generally acknowledge our awesomeness, as they secretly heft their brickbats for round 2.

[Reply #2 on:]

First a big thank you to Altair Labs for starting this shootout thread. It is a lot of fun, and can only result in better open source products. He has given us at Wicked Device some great suggestions on how to improve our radios, and has been generally all around great to work with. 

The first thing that sprung out from the June 7 post is the battery life for the 10 second interval. Each transmission is 0.83 of a second rather than 3 seconds. This should improve it to about 15 days. Still, the proof of the pudding is in the eating, so we did a test (hence the long time in replying). The results are below:

This is consistent with a lifetime of about 15 days. The improvements will be less on the longer interval transmissions, but should still be a couple of days even on the 1 hour interval.

The Node was designed with 2 primary goals: 
(1)   Under $25 for both sides of the radio link 
(2)   Overall ease of use.   

We also decided to go for a kit. Ease of use includes the whole effort to getting the Node up and running and generating data. Long battery life is a component of this– if your sensor is on your roof, changing the battery every couple of weeks is unusable. One 1 year with a 2200 mAh AA battery pack seemed reasonable.

Reliability of transmission is also important. These little On-Off Keyed radios receive data _all the time_, most of it is just garbage. We think the Node does some pretty nifty stuff, including an error correcting Hamming code and other tricks to generate good data.

Finally, it should just work, with low complexity. Given that this is a kit, which introduces a certain level of complexity, reports are that this solution seems to be pretty easy to use. The software and documentation are a good part of this, but so is being able to remember settings if a reset happens in the field, and the ability to program node ID's without writing code. This is done at startup by shorting ISP pins to ground / 5v. Up to 60 nodes, each with 4 sensors, can be reporting to one receiver, although my guess is that this would be an unlikely use case.  1 - 10 is more likely.

So the DCDW definitely wins on battery life, and on cost, by a whisker. A big congratulations to Altair Labs there, and I don't see any way for a digital/IC based solution to beat that. The Node wins on ease of use and reliability, and is FCC compliant.

How many sensors can the DCDW use, and how many can one receiver handle?

[Reply #3 on:]

Well, we are down to 2.7v and still receiving data on the Arduino, but looking at the shape of the graph I think it's close to the end of the experiment.

The node has continuously transmitted data for 21 days, and is still transmitting now (June 29th), which I think is a pretty good result.

Here is the graph of battery voltage over 21 days:


The next step is a long term test on the 1 hour mode, where the quiescent current will dominate the equation.

[Reply #4 on:]

Apologies for overestimating WickedNode packet duration, DCDW concedes your correction and still wins by far on battery life. 

DCDW enters a 3rd month with over 8v remaining.



Details: the graph actual battery terminal voltage (blue, volts, R axis) measured by DVM, the transmit interval (red, sec, L axis) in this config indicates battery health. Actual voltage varies with battery temp as this was in my truck most of the time, getting alternately roasted and cooled every day.

See on Jun 27 the batt was accidentally fat probed (shorted out) while measuring voltage.  The battery recovered with unknown loss of capacity.

Resolution: DCDW function returns an integer freq in Hz with a max freq of a few tens of khZ.  The resolution is 8 to 14 bits, depending on packet duration set by user.  The longer the packet, the more accurately the frequency can be counted.  This allows user to trade off battery life vs resolution desired, by selecting the value of a resistor.  In this test the resolution is about 12 bits.  WickedNode software only returns 8 bits of resolution, although ATtiny hardware should support 10 bits. 

Standby for actual graphs.  Note: resolution and accuracy are different matters.  For either WickedNode or DCDW, accuracy depends also on the sensor, components, and their calibration.

[Reply #5 on:]

Update on DCDW vs WickedNode:

The DCDW battery test is coming to an end, the DCDW node I started at end of April was down to 6v the last time I got home.  Will post graphs next time.

Here today is demonstration of the sensor resolution.  A 100k thermistor was used in both cases.  I prefer high resistance thermistors since they dissipate less power.  For WickedNode the 100k thermistor was put in a voltage divider with a 100k fixed resistor, chosen for best resolution.  For DCDW the 100k thermistor was combined with a 5000 pF capacitor to form the sensor oscillator in "swarm" mode which most closely matches the way WickedNode is usually employed.  For WickedNode this drains battery at 2.5 uA rate always, for DCDW thermistor dissipates power only during transmit.

OK the big difference we want to point out is temperature resolution.  An atrocious code hack was created to monitor both WickedNode and DCDW on a single receiver using RXD Arduino pin used by WickedNode.  No you dont wanna see the code its reeeaaaallllly nasty, but hey it works.

Here is the graph of room temperature where I stayed last night:


The DCDW curve (blue=upper=LH scale) shows clearly the room temperature during a night and day.  WickedNode curve (red=lower=RH scale) shows the same temperature changes from an identical sensor as coarse steps.  WickedNode is limited to its 8 bit resolution, whereas DCDW is counting a 3 kHz tone to a 1 Hz resolution, almost 12 bits.  Additional circuitry and software changes could help WickedNode at the cost of battery life and complexity, however DCDW achieves this naturally by design and simple component value selection.

[Reply #6 on:]

DCDW battery life test almost at an end...  after 5 months!


DCDW was started with a Kroger generic brand 9v alkaline battery on April 28 2011.  As of October 2 the battery is still at 5.3 volts.  This DCDW node is configured for the transmit interval to depend on battery voltage.  Over 5 months the voltage (blue=RH scale, volts) decays from 9.5 to 5.3 volts as reporting interval (red=LH scale, seconds) rises from 10 minutes to 25 minutes.

No additional components are needed to monitor battery voltage, just one jumper wire was moved.