See project's main page for further caveats, if you are not already familiar with them.
When writing software for DCDW, you may want to use low level procedures already developed by the DCDW team. If writing your own, here are some suggestions...
It is best to measure full cycles (from, say, positive edge, through "on" time, past negative edge, and through "off" time to next positive edge. Due to the nature of the wireless link, the ratio of "on" to "off" cannot be guaranteed. And if, for debugging or other reasons, the DCDW is connected directly (with a wire, no RF link) to the input of the monitoring computer, the duty cycle may be different than what it will be with the RF link included.
(Comment from WE Payne, around 2011, tweaked...) Interrupt driven software is pointless if you are using the OOK brand RF links, because 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 (10Jan11) use any Arduino data pin.