I bet you're right. The PC board that you are showing us is most likley an ASK or OOK (
Amplitude
Shift
Keying or
On/
Off-
Keying) receiver operating around 310Mhz (USA), or 433MHz (Europe). The Data pin dumps out a serial bitstream
corresponding to the data transmitted. The signal level will be at the logic levels used by the receiver's microprocessor.
To start, you will need some kind of packet sniffer (Bus Pirate?) or a storage-scope with a ring-buffer pre-trigger to capture the entire frame of 1's and 0's.
As opposed to something like an Xbee, these simple RF link devices are
relatively easy to hack, because the RF modules have no internal protocol. There are protocols, but they live inside of the microprocessors at both ends. The tricky thing is figuring out how symbolic data is represented by 1's and 0's, and how those 1's and 0's are
again encoded into the RF bit-stream. It is most likely not a 1-to-1 correlation. Let's assume that this system uses OOK modulation (What Ham operators call CW). Either the RF carrier is being transmitted, or it's not. How then, would you send all zeros? Not only that, but for synchronization purposes while the frame is being tranmitted, the carrier must switch on and off all the time, preferably as symmetrically as possible because of a few other magical RF considerations that I won't get into right now.
Again, to recap- let's say you want to transmit the number 0x85 which in Binary would be 10000101. The microprocessor on the transmit side has to first convert the 0x85 into something else before it is sent to the "Data In" pin of the RF transmit module- for instance, something that looks like this: "1101101010101". The bursts of RF carrier floating through the ether would correspond exactly to that pattern, where 1=Carrier On, and 0=Carrier Off. Naturally, the same exact pattern will come squirting out of the Data Out pin on the receiver module, but as easy to see digital logic pulses.
Wouldn't it be great if you could peek at the raw digital data so you can compare it to the encoded data? No can do. Sorry.
As ridiculous as it may seem, the easiest part of the data recovery task is figuring out what to do to the "1101101010101" in order to extract the original 10000101 (0x85).
Now, I didn't just pull that example out of the air. This is just ONE way data is transmitted via simple RF links, called "return-to-zero encoding". Fortunately, this is one of the best-known digital data encoding schemes (but there are others).
Here's how RTZ works:
The original data was: (MSB) 10000101 (LSB). The algorithm used to encode it is as follows:
1. Transmit the bits in reverse order (LSB First). (Actually, this is not a requirement for RTZ)
2. For every original "1" to be transferred, transmit a "1"
3. For every original "0" to be transferred, transmit a "10"
In addition, some kind of preamble might be transmitted before the data stream actually begins. It could be as simple as a single synchronization pulse, or it might contain frame ID data or state data or god knows what else.
My example is a simplified version of the scheme used by X10 Home Automation RF Modules (The Power-Line carrier modules use a very different scheme that is not germane to this discussion).
For more information, follow this link:
http://www.idobartana.com/hakb/index.htm, and in the sidebar labelled "Theory and Protocols, find the link to: "Wireless Protocol - Ed Cheung"
Dr. Cheung did a brilliant job of analyzing the RF protocol used by X10, and his methods are very nicely explained. This will give you some idea of what you are in for.
Now, keep in mind- the X10 Data Frames are way bigger and more complicated than your thermometer, because X10 devices are used in networks consisting of many, sometimes dozens, of modules, so there is a lot of addressing overhead. Your task will probably be easier, in some respects. The most useful part of his article for you is how the digital gets transmitted by RF, and decoded back. You can skip all the other stuff if it winds up giving you a migrane.
Now, your gadget may not use RTZ, and unless you are lucky enough to find someone who has successfully hacked one of these, you have a lot of data analysis work to do.
So, let's say you finally figure out what the RF encoding scheme is. Now comes the
hard part!
You still don't know how the temperature value (and possibly other symbolic data) have been represented, and there are really no standards for doing so. It's entirely up to the gadget designer.
The digital data that is actually transmitted (even
before RTZ encoding) most likely will not correspond 1:1 to the temperature. For example, if the temperature is 180.5 degrees F, the best you can hope for would be:
0x1805 (BCDx10) or 0x070D (Hex x 10), but don't get your hopes up.
More likely, it wil be a number between 0 and 1023, if the unit uses a 10 bit analog to digital converter. There may be an offset, or the full-scale value may be different than 1023, but who knows?
Also, there may be more symbolic data being sent than just the temperature. For example, my remote thermometer reports the battery condition of the transmitter, as well. Finally, there could also be extra data that is used by the receiver to check the integrity of the transmitted packet, like a checksum, CRC or the very clever way X10 does it (explained by Dr. Cheung).
No doubt, you have your work cut out for you, but just like someone preparing to scale K2, you may be raring to take on this challenge, and if you are successful, you will earn unending fame, fortune and glory! If you are not, you still will have learned a great deal.
Good luck, and please tell us how you make out!
