Help: Micro-controller + BBQ Thermometer
Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.

Help: Micro-controller + BBQ Thermometer

by jiggak on Sun Jan 08, 2012 6:26 pm

I got this fancy new remote BBQ thermometer over the holidays and naturally one of the first things I wanted to do with it is take it apart. It's a "Maverick Redi Check MAV222". It works great and all but I would love to add some means of interfacing with a PC or micro-controller. Possibly a teensy programmed to stream the temperature data over a virtual serial port?

Photos of the transmitter/receiver:
mav222-front-back.jpg (590.66 KiB) Viewed 7991 times

Inside the receiver:
mav222-inside.jpg (660.43 KiB) Viewed 7991 times

My guess is that the exposed PCB in the photo is dedicated to receiving the data from the transmitter. On the other side of the brown circuit board is what I think must be the smarts for buttons, LCD, and functions such as timers and alarms.

Close up of receiver board:
Receiver PCB
mav222-rcv-pcb.jpg (940.15 KiB) Viewed 7999 times

On the bottom right side of the above photo there are four pins marked VCC, PD, GND, and DATA.

This is where I need help. I have plenty of experience fabbing my own circuits from someones schematic, but zero experience with reverse engineering hardware. I was wondering if anyone here had any guesses as to what sort of signal would be going across this bus or possibly some reverse engineering tips?
Last edited by jiggak on Thu Jan 12, 2012 5:17 pm, edited 2 times in total.

Posts: 2
Joined: Sun Jan 08, 2012 5:21 pm

Re: Help: Micro-controller + BBQ Thermometer

by easternstargeek on Sun Jan 08, 2012 8:14 pm

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!
Last edited by easternstargeek on Sun Jan 08, 2012 9:18 pm, edited 1 time in total.

Posts: 346
Joined: Mon Dec 13, 2010 1:39 pm
Location: Upper Eastern Tennessee

Re: Help: Micro-controller + BBQ Thermometer

by jiggak on Sun Jan 08, 2012 9:16 pm

Wow, thank you so much! That is a very helpful reply.

I don't have a scope or any sort of packet sniffer but I've pined over the Bus Pirate in the past so I suppose now is as good of a time as any to add a new tool to the toolbox.

Thanks again, and I will report back when I have something to share.

Posts: 2
Joined: Sun Jan 08, 2012 5:21 pm

Re: Help: Micro-controller + BBQ Thermometer

by uoip on Mon Jan 09, 2012 4:45 pm

You've already had an excellent reply from EasternStarGreek. I'll just point you to another source of data which may shortcut your journey. Any time you see an FCC id, it's always worth looking it up on the fcc database to see what interesting things you'll uncover. At a minimum, you'll find out what frequency its radio transmitter uses, and often you'll find a lot more goodies.


The grantee code is N9Z, and the product code is MAV221, as shown on those photos you posted.

Look for the detailed display, and you'll get schematics. It's pretty much as EasternStarGreek guessed. It's transmitting on 433.92 kHz, using a basic on/off scheme for modulation, with the duration and timing of the "on" pulses encoding the info. Browse through all the detailed attachments, but the "test report" and "timing" attachments are particularly revealing. The "timing" attachment shows a plot of how its transmissions are switching on and off as a function of time, pretty close to what you'd see if you probed the output data pin with an oscilloscope or bus pirate. They don't say what data is being transmitted, so it's hard to figure out the details of the protocol, but this at least tells you the approximate timing of the pulses you should expect.

A scope or bus pirate would be ideal for reverse engineering, but you might be able to get by with less. What you need is some way of showing the timing of the pulses in detail as you change the temperature. You probably only care about the data output pin. In the distant past, I've hacked up hardware to toggle the CTS/RTS pin of a serial port, and then written software to time the transitions on that line. I don't really recommend that approach, but if you're going to get an Arduino to read the data anyway, you might be able to hook the Arduino up to the data wire, and program the arduino to time the pulses and report the timing in some way.

But this really is the problem that a bus pirate is designed to solve, so that's probably the easiest route, and it gets another tool in your toolchest.
Posts: 127
Joined: Wed Sep 23, 2009 5:48 pm

Re: Help: Micro-controller + BBQ Thermometer

by easternstargeek on Tue Jan 10, 2012 10:39 am


That's awesome! I had no idea it was that easy to get that kind of information about RF-enabled devices from the FCC. I had no idea, since I come from the industrial engineering world, where I use black boxes more than design my own.

That's what I love about these forums- the more you give, the more you get back- besides, it's fun.

Thank you for contributing!


Posts: 346
Joined: Mon Dec 13, 2010 1:39 pm
Location: Upper Eastern Tennessee

Re: Help: Micro-controller + BBQ Thermometer

by orangeshasta on Fri Aug 10, 2012 4:53 pm

Hi jiggak,

Did you ever get anywhere with this? I just picked up the same thermometer, and I've got similar intentions.

I hooked it up to a 433.92 MHz receiver I had laying around, and took a bunch of logic analyzer data for some different transmissions. I haven't had a chance to fully analyze it yet, but at a glance it looks like it could be 2000bps Manchester-coded data.

I'd be happy to share the data if you or anyone else is interested.

Last edited by orangeshasta on Tue Mar 31, 2015 9:23 pm, edited 2 times in total.

Posts: 4
Joined: Fri Aug 10, 2012 4:49 pm

Re: Help: Micro-controller + BBQ Thermometer

by orangeshasta on Sun Sep 02, 2012 2:03 pm

Okay, I've made some good progress here. I took a whole bunch of data and analyzed it, and I think I've got most of the good stuff out of the data.

Basically this thermometer sends 2000bps Manchester-coded data using On-Off keying at 433.92 MHz. A transmission is sent every 12 seconds. Each transmission starts with a burst of 8 short pulses about 250uS wide and spaced every 5ms. Once those are sent, 12 bytes of the Manchester-coded data are sent. That process repeats 4 times per transmission (all data is identical in each repeat).

What we're looking for, obviously, is in the 12 byte section. Here's an example of the data, with both probes at 82F:
Code: Select all | TOGGLE FULL SIZE
0xAA 0x99 0x95 0x59 0x95 0xA5 0x59 0x5A 0x55 0x5A 0x95 0x96 0x59

The first thing you might notice is that all digits are either 5,6,9, or A. This clued me in that we are probably dealing with some kind of quaternary-coded information. So I split the data up into nibbles instead of bytes, and tried coding the quaternary data with 0x5 = 0, 0x6 = 1, 0x9 = 2, and 0xA = 3. That seemed to be the key to decoding the data - so here's what I found:

Nibble 0 - 5: This is a header, sent as 0xAA9995 each time. I've never seen it change.
Nibble 6 - 7: This byte only seems to change during the first transmission after startup. Normally it is 0x59; upon startup it's 0x6A.
Nibble 8-12: These 5 nibbles contain the temperature of probe 1. To decode, first convert the hex to quaternary digits (as above). For example, 0x95A55 becomes 20300. Next, convert that number to decimal - in this case, we get 560. Now, to get probe 1 temperature in Celsius, simply subtract 532 (560 - 532 = 28C). I'm not sure what the lowest value is that it can send, but if probe 1 is disconnected the transmitter sends 0x55555 (all zeros).
Nibble 13-17: This is the data for probe 2. Coded exactly the same as probe 1.
Nibble 18-25: ??? TBD

So that's where I am. I'm assuming that nibbles 18 through 25 contain some kind of checksum or other error checking mechanism. For the life of me, I can't figure it out. If anyone has any ideas, I'm all ears.

If anybody wants to see my data, I've compiled it into an excel sheet and put it in my public Dropbox (forum doesn't like xlsx attachments): https://dl.dropbox.com/u/20644640/Therm ... 0Data.xlsx


Posts: 4
Joined: Fri Aug 10, 2012 4:49 pm

Re: Help: Micro-controller + BBQ Thermometer

by easternstargeek on Mon Sep 03, 2012 12:00 pm

The data on the tail-end could be related to the condition of the transmitter battery. My unit reports that along with the temperature. Get another battery, run it down some, then swap it out and see if the number changes.

In any case, Bob, that's pretty amazing sleuthing on your part. Bravo!
(I hope you will always endeavor to use your Super-powers for Good and never for Evil)

Posts: 346
Joined: Mon Dec 13, 2010 1:39 pm
Location: Upper Eastern Tennessee

Re: Help: Micro-controller + BBQ Thermometer

by Lateralus on Sun Jan 27, 2013 10:12 am

Thank you vey much Bob for all your effort!

I tried to do the same thing with my Maverick ET-732, and all your findings are more than just a good starting point.
However I'm having troubles decoding the Manchester-Stream. Somehow it looks different on my side.
I don't get this AA 99 95 preamble.

The closest I can get to your data (and the only way I get quaternary-coded inforamtion) is to ignore the very 1st bit in the manchester stream
and than start with a high byte. So the first pulse in my screenshot is ignored and the 2nd pulse (the 1st low pulse) is interpreted as Logic 1.

Then the attached stream would be this (while both probes show 75°F = 24°C).
AA 66 55 66 56 69 65 66 95 .... (for the ease of reading I did not post the checksum bytes)

According to your calculation this would be:
probe1=56696 = 01121 = 49h = 73d
probe2=56695 = 01120 = 48h = 72d

so both probes show the same value on the LCD but are different in the stream...Clearly I'm doing something wrong...but what???

I would appreciate if you could share your thoughts or maybe a screenshot of your logic-analyzer output with me.
Maybe there are different firmware versions out on the market for this ET-732 and they encode the data different? But I doubt that.

Manchester_both75F.png (25.21 KiB) Viewed 6825 times
Posts: 4
Joined: Sun Jan 27, 2013 9:51 am

Re: Help: Micro-controller + BBQ Thermometer

by Lateralus on Tue Jan 29, 2013 5:52 am

my bad ;-)

the first bit in the trace is actually the 2nd bit
so the first bit is a logic 1 and the first pulse in the screenshot toggles this bit to logic 0

with this decoding I can confirm bob's finding 100%
Posts: 4
Joined: Sun Jan 27, 2013 9:51 am

Re: Help: Micro-controller + BBQ Thermometer

by pgregg on Mon Mar 04, 2013 7:51 pm

Hello. I'm trying to do the same project. I'm a little behind you guys on my learning curve.

It looks like a crew successfully completed this on the Flyport platform.

Their approach is to configure a 433 RX to bridge the temperature readings to WIFI and publish to the COSM.com site. Pretty slick.


They post documentation and source. You might be able to find the missing bits there.

Nothing like a little open source sharing. We live in fun time.


Posts: 1
Joined: Mon Mar 04, 2013 7:42 pm

Re: Help: Micro-controller + BBQ Thermometer

by Lateralus on Tue Mar 05, 2013 4:42 am

pgregg wrote:It looks like a crew successfully completed this on the Flyport platform.

Not a crew, that's my project :wink:
Posts: 4
Joined: Sun Jan 27, 2013 9:51 am

Re: Help: Micro-controller + BBQ Thermometer

by mmkk777 on Mon Jun 24, 2013 3:02 pm


Do you know any way to Increase range between Transmitter-Receiver?

I use the wireless thermometer to see the temperature of the solar water heater.

If I connect pin DATA with the antenna Receiver with cable will it have better performance?
Posts: 4
Joined: Mon Jun 24, 2013 2:40 pm

Re: Help: Micro-controller + BBQ Thermometer

by mmkk777 on Tue Jun 25, 2013 5:19 pm

Any help from the experts?
Posts: 4
Joined: Mon Jun 24, 2013 2:40 pm

Re: Help: Micro-controller + BBQ Thermometer

by adafruit_support_mike on Wed Jun 26, 2013 1:09 am

Hi - you're much better off starting a new topic and including a summary or link to a previous one than adding onto a discussion that closed more than a week ago.

There are two basic ways to increase the range of a radio link: use more power, or use a better antenna. Modifying an existing and FCC-approved device will probably be both difficult and a bad idea, so you're probably looking for an antenna.

Antenna design is a subject for the specialists, but you can get antennas specifically designed for 433MHz for a few dollars from distributors like Digikey and Mouser.
When you void a product warranty, you give up your right to sue the manufacturer if something goes wrong and accept full responsibility for whatever happens next. And then you truly own the product.

Posts: 64984
Joined: Thu Feb 11, 2010 2:51 pm

Please be positive and constructive with your questions and comments.