My first step was to figure out the transmitter's frequency. Using a spectrum analyzer, I saw that it sent a signal at 433.92 MHz once every 12 seconds, using what appeared to be on-off keying. I also searched FCC filings using the Maverick's FCC ID of N9ZMAV221 (http://transition.fcc.gov/oet/ea/fccid/, or just http://www.fcc.io/N9ZMAV221) which turned out to be extremely useful. In addition to verifying what I saw on the spectrum analyzer, I was able to download schematics and all sorts of other helpful information about the transmitter.

Now that I knew the frequency, I needed to capture some data. I had some spare 433.92 MHz transceiver modules made by Radiometrix at the office, so I hooked one up and captured the data coming out the module's /CD pin (Carrier Detect, low-true) with my Saleae logic analyzer.

The first thing I noticed is that the same message repeats 4 times, so it's got some redundancy built into the protocol.

Zooming in a bit, I saw that each message looks like 13 bytes of Manchester coded data at 2kbps, with an eight-pulse preamble (each pulse is about 230uS wide, with 5ms between pulses). This seemed like it would be reasonable to decode, so I got to work collecting some controlled data.

The Maverick thermometer has two probes and two buttons.One button controls whether the display is in Celsius or Fahrenheit, and the other is labeled RESYNC. To get all the data I needed, I would need to take some samples with each probe at a different temperature, some with each at the same temperature, and some with one or the other probe (or both) disconnected. I also would want to collect data with the display in both Fahrenheit and Celsius modes to see if the units are transmitted with the temperature. I assumed that the existence of a RESYNC button meant that there must be some kind of synchronization command at startup, so I also wanted to collect the first message sent upon startup and the first after pressing RESYNC.

After collecting all of this data and discarding the redundant messages, I converted the Manchester coded data into hexadecimal bytes (MSB first, falling edge is binary 1) and put all of it into a table.

Now that all the data was aggregated, I could start looking for patterns. The first thing I noticed was that the only digits (hex nibbles) used in any of the transmissions were 0x5, 0x6, 0x9, and 0xA.Interestingly, 0x5 and 0xA are complements (0101 and 1010), as are 0x6 and 0x9 (0110 and 1001). This gave me the idea that the information might be coded in nibbles rather than bytes, so I rearranged the table:

Next, I tried to figure out how the data was organized. The first 8 nibbles are common to all transmissions, with the exception of the data captured immediately at startup which has different values for #6 and #7. I assumed that the first 6 nibbles are a fixed header and that the next two have something to do with signaling a startup to the receiving unit.

To find the actual temperature data, I first examined the rows where the probes had identical temperature values (82F/82F and NC/NC) and looked for a repeating pattern. I found it in nibbles 8-12 and 13-17. To figure out which probe was which, I looked to see which set of nibbles matched across the two rows where Probe 1 was at 90F. Nibbles 8-12 were the same when the Probe 1 temperatures were the same, so I deduced that Probe 1 is represented in nibbles 8-12 and Probe 2 is represented in 13-17.I wasn't immediately able to see any patterns in the remaining data, so at this point I got stuck. However, I had found all the data that I needed for my project, so I decided to just ignore the last 8 nibbles for the time being. Better to be done than perfect. I assume that there is probably a checksum in there at the end, and maybe something related to the RESYNC button. There might be some kind of counter which increments with each transmission so the receiving unit can tell if it has missed data. In the future, I may revisit this by taking a long capture and seeing...