A few Arduino Forum members are undertaking development; you can track our progress at http://www.dcdwireless.com/. Please note there is currently no product for sale and no support. It is of course Open Source so you hardcore hackers feel free. Schematics and board prints are on the site, until www collaboration is fully up just contact us for actual design files.

If interested but not hardcore hacker, tell us and we will email you back "when soup's ready".

Circuit boards v0.1 and parts arrived, got 3 sensor nodes built except for the RF modules from SparkFun, which *finally* shipped. So right now the DCDW prototypes are hardwired to Arduino Uno to support code development.

The initial "frequency counter" code hooks interrupt 0 on digital pin 2 and sets a flag then returns. The freq measured by Arduino agrees pretty well with my scope.

This ISR "set flag and return" is due to attachInterrupt(interrupt, function, mode)

Quote

Inside the attached function, delay() won't work and the value returned by millis() will not increment. Serial data received while in the function may be lost. You should declare as volatile any variables that you modify within the attached function.

The easy ways to count frequency depend on pulseIn() with millis() or micros(), so I elected to have the interrupt to just set flag "dataComingIn" (and a LED) and return, this minimizes the disruption of timers and serial, and gives other code access to all the time functions.

Right now the demo idles in the main Loop() until some pulses trigger the ISR. The ISR sets the flag, turns on a LED (for development) and returns. Code in Loop() calls countFrequency() when the flag is set, then afterward clears the flag and turns off the LED. countFrequency() sets a start time-hack in millis(), loops thru 100 pulses with pulseIn(), and then hacks the stop time and returns kHz as a float(). Floating math is costly, so today I'm gonna change to return an int() in Hz.

Precision is about 10 Hz, or rather the inverse number of millis() in 100 pulses. More pulses would be better, right now accuracy and precision are plenty good to just "drive on" with development, we can sharpen our pencils later.

Also my prototype code does not gracefully turn loose and return control to void Loop() after the first activation, but thats gonna get ironed out today. Will also post some prototype code here and however our Dirt Cheap Dumb Webmaster deems fit.

There are many ways to "skin a cat" and we are open to alternative approaches. By polling in Loop() any digital pin could be used vs the hardware interrupt approach. We may include both a "lazy" approach and a "serious" approach.

The ultimate goal is code Newbies can use to get top level functionality like "Node 3 Sensor 2 is 64 degrees F" or "Node 4 Switch 1 just opened" without having to delve into ISR and such. If this is you, we have nothing ready for you yet, just let us know who you are and be patient.

Received OOK radio links from SparkFun. The interrupt driven software is pointless for OOK links, bkoz in absence of a TX signal the RX chases its detector right down into the thermal noise and the data out pin dithers randomly. Main Loop() ends up going off every time to countFrequency(), might as well code it that way instead of wasting an interrupt. Also we can now use any Arduino data pin.

The good newz is the code reads the identical TX pulse rate thru the OOK radio link as it does hardwired. This is bkoz the function countFrequency() measures time for 100 (or your number) of complete cycles instead of just measuring pulse width.

The function countFrequency() is now automatically immune to noise. It also autoscales the sample time to the incoming pulse frequency and desired precision. Code got fancier than planned but the use is simpler than before.

Heres a DCDW v0.1 set up as single channel temperature with identification:

Copied the Serial Monitor output to a spreadsheet.

Note in this TEST CODE the TIME IS NOT TO SCALE any valid samples are logged as they come in, when the SparkFun RX is just receiving noise, nothing is logged. Since function countFrequency() returns timely with error codes for noisy input you could plot whatever you want. Anyway this test code sampled between 1 and 3 seconds whenever valid data was present, no attempt *yet* to do real time, but thats where we are going. You can see sample time automatically "shift gears" when temperature rose afetr bringin DCDW back inside warm lab.

Heres code. Function countFrequency() is much more advanced now. It returns quickly if no valid signal is received, and automatically stays gone just long enough to get ~3 digit precision. The main code has some vestiges of 2-button remote version, and some declarations need to be hidden inside countFrequency() but its working well.

I'm very interested in seeing just how small a sensor can be made (thermo).

The goal is to create a probe that can be used in a wireless meat thermometer, so ultra-high precision and fast cycling/updating is not necessary. Long battery life, small probe size and a 2-4m transmit distance are the objectives.

Would it be possible to have the code run on interrupts rather than a counting loop?

Here's the thing... As I understand it. AltairLabs may come in on this an correct me...

When no DCDW is transmitting, the receiver "listens" harder and harder, and before long starts "hearing things". At that point, the output of the receiver starts generating lots of spurious positive and negative edges... which would divert the Arduino excessively inside a fancier interrupt handler.

With the simple interrupt handler and more code (which taps into what the simple handler is picking up), selectively executed, a happy compromise can be had. The Arduino will do very little with the "noise", but will from time to time make a check to see if more than noise is coming in.

would it be possible to have the code run on interrupts rather than a counting loop? that would make this whole thing easier / practical.

Thats just what we thought too. Interrupts was my very first approach, and it *does* work. But there turned out to be less advantage than I had hoped, and some unexpected drawbacks.

(1) the RX noise of an empty channel on these cheeep OOK radio links will consume significant CPU time servicing the interrupt, even to return a result code of "nothing coherent received".

(2) interrupts are only available for certain I/O pins, the new approach is possible for any I/O pin

(3) interrupts corrupt other Arduino functions such as the millis() counter.

So after trying both techniques a while, the interrupts seemed much less attractive. You can still do interrupts if you wish, it would probably work best for a continuous transmit or a quiet link like "real" radios with squelch. Maybe cheeep walkie talkies?

If you would like to run with the interrupt approach, our second set of PC boards may be ordered soon. At this early stage we cant give much support to "appliance operators" but if you are proficient with schematic and soldering iron youre welcome to join the development.

I'm very interested in seeing just how small a sensor can be made (thermo).The goal is to create a probe that can be used in a wireless meat thermometer, so ultra-high precision and fast cycling/updating is not necessary. Long battery life, small probe size and a 2-4m transmit distance are the objectives.

The two approaches I see are(1) the single dedicated sensor. You dont need the quad NAND at all., just use Osc C to send temp. Updates as often as you care to read it. It runs all the time and uses the least components. You can even snap off and discard one half of the circuit board.

(2) use Osc C to switch on Osc B every N seconds for an updated reading. This uses the full circuit board with both chips and conserves battery life.

We are not prepared to support newbies, we still need good explanations, diagrams and other documentation for the various modes, and a better introduction to the possible modes and how to choose. But if you are proficient with schematics and designing simple circuits, you are welcome to use these ideas. After all, that what Open Source is all about:)

The DCDW circuit board is a bit bigger than a 9V battery. You could use one to prototype your circuit and test your code, when you are satisfied with the design you could make your own dedicated PC board out of surface mount components, I reckon the size could be reduced to about an inch square.

The antenna wants to be nearly 20 inches, working against a ground at leeast the same size. nobody really wants a 40 inch meat thermometer so the antenna will be a compromise. Probably enclose the thermistor in a thin stainless steel tube, make that "ground". Then have a plastic head to hold battery and PCB and maybe a power switch. The antenna can be a wire coiled up inside the head. The RF modules claim a range of hundres of feet with "proper" antenna so you should still get enough to reach a few meters.

If you can glean enough from this post to run with the idea on your own, thats great we can put you down for a beta test board. If the details still seem fuzzy to you , please be patient while we develop better documentation and code examples. Either way hit the website and give us an email, we'll keep ya posted.

OKAY here is a major annoyance. The CD4093 from Texas Instruments is purportedly a Quad 2-Input NAND with Schmitt trigger inputs. DCDW depends on the "gated oscillator" or "astable multivibrator" touted by National Semiconductor and Texas Instruments, respectively.

OK fine, that exactly what we want, right down to those equations giving the transition times. The timing dont depend in ANY WAY on the voltage at the Control input, that just turns the oscillator on and off RIGHT? Thats the beauty of a Schmitt trigger input, RIGHT? Can I get an AMEN on that?

Well heres what REALLY happens when I use the Texas Instrument part and vary the control voltage.

The osc freq varies 10X as the control voltage drops, before it shuts off. WHERE is the Schmitt Trigger? I'll be in contact with TI about this, as well as ordering equivalent parts from the other 3 suppliers represented at Digi Key.

In the mean time we would greatly appreciate hearing from anyone about this.

We have 2 DCDW in "single sensor plus ident" and a simple data logger to demo them. Left it running to low inside and outside temperature for a day. Problem is Win7 keeps turning off the Acer Aspire netbook. Disabled WinDoze Update to prevent reboots, went to "power options" and set everything to "NEVER" (the netbook is on AC power adapter the whole time) but still I go down and find the DCDW happily chirping out temperature readins, the Arduino is receiving data (according to the LEDs) and trying to log to the stinkin' WinDoze that has turned itself off.

Its almost time for me to go to sleep and see if the laptop can stay awake. I created a new power profile called "AlwaysON" but didnt find any settings I havent used before. If this doesnt work tonight then your link is what I will try next night.

BTW the netbook was sitting on a shop rag, the heater in lab keeps us between 20 C and 25 C. Tonight before going upstairs I will be sure to elevate the netbook where all vents are free and clear. Thanks again.

Working on SSID (Single Sensor plus IDent, but thats easily confused with the WiFi term). We currently have 2 problems.(1) the CD 4093 Quad NAND with Schmitt Trigger Inputs produced by Texas Instruments is not acting like it has Schmitt trigger inputs. This makes the "gated oscillator" frequency chirp downward badly. Currently using slow packets of 10 sec every 3 minutes and the software can latch the data before the chirp becomes too bad.

Likely solution is avoiding this particular manufacturer for this chip

(2) when a collision of packets occurs, the software is sometimes does not recognize the error but rather mistakes the ID part of the second packet as the data part of the first one. Over night this happened about 10 times in 500 sensor readings, or in other terms about half the packet collisions were erroneously accepted as valid data. These are easily recognized as invalid readings but are still nuisances.

Solution is a more robust state machine, which is being tested overnight tonight.

Here is the master station[glow]When DCDW development is finished, only the l33t beta testers will have the genuine DCDW master station official mounting string. Compatible with all genuine Arduino boards. Cost is just one carton of Samuel Adams for the development team! Supplies are limited, Sign up today![/glow]Here is the indoor temperature sensor nodeHere is the outdoor temperature sensor nodePCB layout v0.01 requires the ugly hack to scab on a diode, resistor and capacitor to put the DCDW in SSID mode. This will be cleanly accommodated on all PCB versions going forward.

Here is a Open Office import of what the DCDW master received from its nodes

Long straight lines are missing data when WinDoze7 ( >:(DONT get me STARTED ) despite all power profile settings fell asleep and stopped listening to Arduino Uno.

Time is Arduino millis(), we have no Real Time Clock as you would use in a proper data logging project. We also have made no effort yet to convert frequency (Y axis) backto temperature. This is only a proof-of-concept for DCDW with one master node monitoring a swarm of sensors on a single channel.

The collisions are evident. Most falsely accepted collisions the outdoor node was sending its ID and was interrupted by (much stronger) indoor node ID which was erroneously accepted as the data for the outdoor temperature. Better spaghetti code software will fix this. You software mugs will get a laugh out of this:

Sorry some code got chopped off at post limit. Here is the workhorse of DCDW the function countFrequency() which is less spaghettified than the demo. Still a few of you could improve on it. To go with the last post, the remaining two functions are: