This is not yet a "product" that you can buy. This page is for the use of a small group of developers, working to make the board into something you can buy! See project's main page for mailing list information, but also further caveats, if you are not already familiar with them.
Sparkfun and others sell simple, inexpensive little radio frequency (RF) transmitter ($4+ p&p) and receiver modules ($6), with a range of about 500' in good conditions. These modules are legal, at least in the US (check your own locale... NOT legal everywhere.. but where the Sparkfun modules are not legal, there is often an alternative.)
The DCDW system uses these modules, unmodified. The DCDW circuit, the remote sensor transmitter, feeds the digital input of the transmitter (tx) module. There can be multiple transmitters in one area. In the same area, fitted with just one of the receiver (rx) modules, and some software, you have an Arduino or other computer to "harvest" the data seen by the sensors, and sent by the DCDW+tx module. So far, so simple?
In the Arduino community there are many folks trying to get temperature or other sensor data wirelessly. Some schemes used a microcontroller at the sensor to digitize it and send serial data back over a wireless link like XBee. LadyAda points out that an XBee node can digitize and report an analog input with no additional processor at the sensor. Even without the Arduino at the sensor, the cost of the XBee based wireless temperature sensor node is about $35: an XBee, a breakout board , and a sensor.
A much more basic approach... as used by the DCDW... can really slash the cost of sensor nodes.
"Old School" techniques, used on NASA's earliest space probes, can today (with just a few dollars in parts) transmit data from up to three sensors per transmitter. We are starting with temperature, humidity and light readings. Many other parameters can be sensed by these techniques. The sensor node is "dumb", just some simple hardware. It transmits a pulse train, suitable for onward transmission by RF. Code running on an Arduino or other microcontroller reads the received signal and calculates the sensor reading.
Dirt Cheap Dumb Wireless was born as an open source project to introduce low-cost simple wireless sensing to the Arduino community. There is nothing in the design to stop others working with DCDW. The units taking readings and transmitting them will be the same whatever you use at the data gathering end. At the present time, the only software available for the data gathering end is written for Arduinos. (The data gathering hardware is trivial.)
(Alternate introduction/ explanation...
Think back to the simple radio wave link illustrated above. If you connected a push button to the input of tx, and a computer or microprocessor, e.g. Arduino, to the output on rx, and if the computer had a suitable program in it, you could send Morse code, and have text appear on the computer screen, couldn't you?
Dirt Cheap Dump Wireless (DCDW) isn't going to do quite that... but the "Morse code" idea makes a useful starting point for talking about DCDW.
The DCDW is a replacement for the push button and finger in the "Morse code" scenario. It is a little bit of electronics to attach to the input of tx (the transmitting module).
When using a DCDW, you will STILL be using the tx and rx modules, unmodified, and will still be connecting a computer or microprocessor to the output of rx, and using a program to interpret what is coming from the output, interpreting what the DCDW created, and sent via the RF modules.
The DCDW is a module which can do something as simple as send a continuous stream of pulses of a pre-determined frequency. In other applications, it will be set up to send a stream of pulses which will have a frequency determined by a sensor on the DCDW module. Is, say, you used a temperature sensor, the frequency would change as the temperature around the module changed. The DCDW can also be set up to send streams of data packets each made up of two halves, one reporting one parameter, still by the frequency of pulses in that half, the other reporting a second parameter, via an independent frequency.
The first use envisioned for DCDW was to fit it with a simple circuit which would set the frequency of the pulses it fed to tx according to the temperature around the DCDW. Such a simple thing would create a way to have a remote temperature sensor "report" to a central computer. The DCDW project sort of "grew like topsy" from there.
But, at it's heart, the DCDW remains a unit which has an output intended to feed a simple "on/off" type radio frequency data link tx module.
Sadly, the RF link doesn't work QUITE as the Morse code analogy would lead you to believe. When the transmitter (tx) is sending a 1, the receiver (rx) is outputting a 1 to whatever is connected to it. If tx STOPS sending a 1, then for a short while, will output a zero... but it will not continue to do so indefinitely! Before very long, it will start sending random 1s and 0s. This behavior does not render the link useless... it just means that it isn't quite as useful or easy to use as a link that can continue to convey a 1 or a zero indefinitely. Over the RF link we have, with the inexpensive modules we have, the presence of a steady "on/off/on/off", i.e. a steady "101010..." can be taken as meaning something, and the "something" will be conveyed by the frequency. But at other times, the output from the receiver will not be a steady 101010, and will have be ignored. "Steady" is not meant to exclude a train of pulses with a slowly changing frequency. Only to distinguish such streams from one with erratic full cycle times, where each cycle' duration is significantly different from it's neighbors'.
At the heart of DCDW is a little PCB which can be configured for a number of tasks by your choice of what components (sensors, resistors, capacitors), and by cutting or making various tracks and links.
The very simplest "data stream" is just a series of on's and offs, at a fixed frequency, or at a relatively slowly changing frequency. Not much fancier than that is a stream of on's and offs made up of alternating periods of two fixed or changing frequencies. And the "fancy" basic data stream format calls for periods when the DCDW output is low, punctuated by occasional bursts of one or two "blocks" of one or two frequencies, I'll call those blocks "A" and "B". "A" and "B" may or may not be the same as one another, and may or may not remain the same as what they were in a previous transmission. (When the device is reporting sensor readings... up to two sensors (although we may extend that one day(!))... one via "A", the other via "B"... the frequency will indicate the reading from the sensor.)
One of the great virtues of the DCDW is that one circuit can be configured, by making or breaking links, and by choosing different components, to operate in a variety of modes.
The version 0.1 prototype (only a few produced, now deprecated) could be configured as a....
The version 0.2 prototype is expected to add....
A simple 9v battery is quite adequate to power the DCDW, with the tx module which the overall system requires. (DCDWs can be hard-wired to the monitoring PC or microprocessor, too, if the RF link is unnecessary. This configuration is also handy when working on software for the DCDW.) When the battery voltage sags at the end of the batteries life, the frequency may drift a few percent before dying. Fairchild cites a change of 4% when supply varies from 15V to 5V, so add a voltage regulator if this is not good enough for you.