(There's nothing to tie this device to an Arduino, but for now, all of the people working on it are Arduino-types, and until the basic device is sorted out, we don't want the distraction of different monitoring hardware.)
In addition, if you think it is as wonderful as we do, you are welcome to send an email, if the subject line says "Please put me on DCDW mailing list". (I won't always be able to answer such emails immediately, but within two weeks you should get an acknowledgement.) When the product DOES get released, you will get an email saying "ready now".
Right. Still reading? You are keen... good <^_^>
The DCDW is an inexpensive ($15-ish) battery powered circuit which reads one or two sensors, and periodically sends the readings, wirelessly, to a base station. You can have multiple DCDWs in the same area. You can... though it is hard to think why you would... have multiple base stations.
The base station we have been working with initially is an Arduino, although anything that can monitor a single digital I/O line could be used.
The radio link the DCDW is built around is a simple module, available from various sources. The price of the transmitter- one needed per DCDW sensor readings transmitter module- is included in the $15 guide above. The base station will need one receiver module, which costs abotut $6.
Further comments available at the DCDW Overview page.
Two "development instances" of DCDWs are working...
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.
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.w
The software to check for a pulse train IS available, however, and could be used in many other "see if there's a pulse train, and if so, what frequency" apps.
Subordinate pages... (They will open in new tabs or windows)
Overview- What it is, how it works.
User documentation for the boards, including configuration notes. Applications using DCDW modules (Don't get too excited... none released yet! But one that is working, but not yet released is described.)
Software Development notes.
(To come: Separate page for hardware development. For now, that is here on "index", along with overview)
Fundamental matters: Hardware (Casual readers and basic users if DCDW can ignore)
Fundamental matters: Software (Casual readers and basic users if DCDW can ignore)
Also to come: Separation of software development and software user's guides. Same for hardware.
Also on this page, at the bottom, "bulletin board"/"notice board" with latest thoughts, questions, etc... (There may be more of same in relevant place on some subordinate pages.)
As is so often the case, something that is actually remarkably simple and elegant is also remarkably difficult to describe simply and elegantly!
In January 2011, this project first starte building steam, having been "an idea" in the inventor's mind for some time. It all began with the discussion at the Arduino forum.
If what you see below interests you, also visit with another post at forum, with WORKING CODE for a DCDW module wired for an "Ident" signal over one channel and temperature over the other.
Code to measure the frequency using pulseIn(pin, value) is one way to use the DCDW. With one configuration of the DCDW, the pulse frequency is proportional to a thermistor resistance, and temperature can be determined in software from the thermistor curve by interpolating off a lookup table or by fitting a polynomial.
Calibration is not taken care of by the dumb transmitter so the smart receiver must take on this duty. A quick two point calibration in ice water, then boiling water, is sufficient for most needs.
Notice either R or C variable sensors can be used in the DCDW, but sensors generating an analog voltage are not easily accommodated in the current hardware. A DCDWa (for "analog")board could be produced which would be readable by the same software as the current DCDW hardware, which might have to be renamed something like DCDWrc (for "resistance/ capacitance").
One sensor which could be incorporated as the frequency-changing resistor in the circuit is the type 103AT thermistor. It has a 10k resistance at room temperature, rising to 330k at -50 deg and dropping to 974 ohms in boiling water. DigiKey carries these or just get RadioShack 271-0110. Same same. Temperature-resistance curve is in datasheet http://www.semitec.co.jp/english/products/pdf/AT_Thermistor.pdf. Capacitor is 0.1 uF for weather and habitable spaces, running around 1 kHz. To keep the pulse frequency in a convenient range, use a smaller capacitor to raise the frequency if monitoring a dry ice bath that never exceeds room temperature; or a larger capacitor to decrease the frequency to accurately monitor a steam boiler that never freezes.
Another example: a CdS photo-resistor could provide the varying resistance resulting in varying frequencies. There's one from DigiKey or pack of 5 for $3 as RadioShack 276-1657. The very wide range of CdS resistance presents a challenge. In full sunlight this resistance may be under 200 ohms, in total darkness it may go to few Meg, a ratio of 10,000 to one. Even a simple single-tone data link might not follow the highest and lowest tones. Check the data sheet, or else use a 555 or something to make a square wave and test the highest and lowest pulse frequencies your data link can pass. Must stay within these limits, narrower than the range of illumination you may encounter. Adding fixed resistors makes this possible.
To tell the difference between full sun and cloud cover, we can discard resolution on the "dark end" by adding a 2k resistor in parallel. The tone is now compressed into a 10:1 range near full sun, with good resolution, but the difference between moonlight and no moon might be only an LSB or two.
Conversely, 100k in series gives best resolution in candle light or star light, but only an LSB or two below max scale when clouds cover the sun.
NOTE this is not a limitation of the dumb wireless sensor, the "dynamic range" is also just too darn wide for a 10 bit analogRead or Xbee input. Either Smart or dumb sensors must discard ranges not of interest, or use a log amp to cover the full range while sacrificing resolution equally everywhere.
The techniques for compressing the CdS photo-resistor dynamic range show how the dumb sensor circuit can easily accommodate such sensors. Furthermore your dumb sensor can actually exceed the precision of a smart one. Measuring one cycle of a 1kHz tone with microsecond resolution gives about 10 bits of resolution, like an analogRead(). By measuring the period of 1000 cycles (1 second) of the same dumb sensor tone you could approach 20 bits of precision!
Remember that 20 bits of "precision" is a function of resolution and linearity. it allows you to see small changes in large parameters. To get 20 bits of "accuracy" your dumb sensor, same as a smart one, must have that precision PLUS ALSO be absolutely calibrated and be stable over the long term, requiring a voltage regulator, and maybe precision low temperature-coefficient components and such.