close-circle
Close
0%
0%

Reverse Engineering the Maverick ET-732

A detailed description of the process I used to decode the wireless signal broadcast by the Maverick ET-732 wireless BBQ thermometer.

Similar projects worth following
close
I like to barbeque, but don't often have all day to babysit my smoker for a long cooking session. I wanted to make a wireless thermometer that would send the current temperature of both the smoker and the food to a website that I could check from my phone. When I first came up with this idea, I thought I would design and build the whole thing myself. However, I soon decided that the fastest way to a working device would be to hack it together with parts I already had lying around.

I already owned a Maverick ET732 wireless BBQ thermometer, which wirelessly sends the temperature of two probes to a base unit with a range of a couple hundred feet. I figured that it would be pretty simple to build a device that would receive this data and decode it.

This project will describe how I captured and reverse engineered the Maverick’s wireless protocol. To see what I actually DID with it, check out my other project: http://hackaday.io/project/4538-internet-connected-bbq-thermometer

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.

Figure 1 - Full Transmission

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

Figure 2 - Single Message

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.

Figure 3 - Decoded Hexadecimal Bytes

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:

Figure 4 - Decoded Hexadecimal Nibbles

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.

Figure 5 - Header and Startup

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.Figure 6 - Probe 1 and Probe 2I 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...

Read more »

  • 1 × Radiometrix BiM-433-F 433.92 MHz Transceiver Module

View project log

Enjoy this project?

Share

Discussions

Sebastian Meier wrote 09/04/2015 at 12:05 point

Hello,

this is Sebastian (Nibbler). First of all, very nice work on reverse engineering the protocol :)

Regarding the checksum for the ET-732: I'm pretty sure that the findings, which I posted on the adafruit forums are sound, i.e. the checksum allows sender identification (as well as detetcting corrupted transmissions).

Still, there might be more to it :) Disclaimer: I know next to nothing about error correction. However, I have the feeling that because of the amount of redundancy, not only error detection, but even error correction might be possible (i.e. detection AND correction of up to X bit errors) by using the redundancy bits (aka checksum).

If you have the time and expertise, it might be fun looking into that.

Best Regards,

  Sebastian

  Are you sure? yes | no

James Cook wrote 04/01/2015 at 15:27 point

For what it's worth, I've also decoded the (even simpler) protocol used by the earlier ET73 model.  I don't have a nice write-up, but there are some notes and code at https://github.com/mokus0/et73 describing and implementing it.  The code isn't nearly as efficient as it could be (I know of a lot of optimizations I could implement, but in the form it's in now it collects a lot more information about the signal than it would with those optimizations), but the notes should be sufficient to understand the protocol without reference to the code.

  Are you sure? yes | no

Bob Blake wrote 04/01/2015 at 20:49 point

Nice, looks really good!

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates