(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".
The page is "semi-private" because the product... which DOES WORK... is still under development, and we don't want to have a bunch of variations confusing the picture until we have a good "let's start from here" starting point version. The page WILL become "public" in due course, we hope!! (Or else an awful lot of work will have been more or less pointless!)
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 about $6. (For development work, you don't need the RF modules.)
You do need to be careful in this internet age to order modules which are LEGAL in the region you intend to use them. There are rules about what frequencies you can have devices transmitting on, and they are different, for example, in the US and in Europe. Very similar modules. Different frequencies.
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
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 started 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. (Remember: That post PRE-DATES the "July 2014" attempt to regularize all references to components.)
Note the DCDW system in simple implementations is restricted to having just one remote transmitter feeding one receiver. Having several transmitters in a "network", feeding one receiver, or "data harvesting hub" possible... but only if you accept certain constraints. For instance, you could have a number of transmitters set up in the "button" version. (The transmitter sends a message when a button is pressed, by a human, or by electronics.) This would work... if you can accept that the receiver will not be able to understand either message if two (or more) transmitters try to transmit at the same time.
Sorry for the "bad news" in the previous paragraph. It isn't insurmountable. Remember that one of the one design constraints was "cheap". You know the rule? Cheap, powerful, well done. You can have any TWO. There is one way to "almost" get around this: You could have one DCDW module on one frequency (315 mHz), and another on the other frequency (434 mHz) that the simple tx/rx modules are made for.... but in this setup, you might have software problems, missed data packets. (Something for the future... maybe.)-->
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.