[Bob] has his own smoker and loves to barbecue, but doesn’t like spending all day checking on his smoker’s temperature. He thought about building his own wireless thermometer setup, which would have been pretty awesome, but then he had a better idea: why not hack an existing wireless barbecue thermometer? [Bob] purchased an off-the-shelf wireless BBQ thermometer and reverse-engineered its wireless protocol to make his own wireless thermometer setup.
The first problem [Bob] encountered was figuring out the frequency of the transmitter. Thankfully [Bob] had access to a spectrum analyzer, where he discovered the transmitter was running at 433.92MHz (a cheap RTL-SDR dongle would also get the job done). Next, [Bob] started digging into the manufacturer’s FCC filings and found that it actually called out the transmit frequency, which matched the transmit frequency he measured. He also found a ton of other helpful information in the filing, like a block diagram and full transmitter schematic.
[Bob] used a Radiometrix RF module to receive the thermometer’s signal. He hooked up the output to his logic analyzer to start decoding the protocol. After a quick visual analysis, [Bob] found that the signal was a preamble followed 13 bytes of Manchester-encoded data being transmitted at 2kbps. He started collecting data with known temperatures, created a table of the data, and began looking for patterns. After quite a bit of searching [Bob] was successfully able to find and parse the temperature values out of the data stream. [Bob] did a great job of documenting his process and results, so check out his writeup if you want to try it out yourself.
On-off keying? How barbaric!
You’d be shocked how many telemetry equipment providers, whose revenues are in the billion-dollar range, still use OOK somewhere in their systems. Heck, I work for one of them.
I have an ET-732 (love it!), and for that reason I know [Bob Blake] isn’t the first to reverse engineer its protocol. [Michael Posavec] already did it:
http://wiki.openpicus.com/index.php?title=Wifi_bbq
Though [Michael] didn’t appear to document the protocol except in his source code, so [Bob]’s writeup is more accessible. Maybe if [Bob] sees this he can complete his analysis, it appears he didn’t realize the remaining data contains a third temperature – ambient, from a sensor within the transmitter itself rather than an external thermocouple.
Interesting! I actually did all of this work a few years ago but only just got around to documenting it, so I never saw [Michael Posavec]’s project. I have been wanting to add an ambient temperature sensor to my setup, and had no idea that the Maverick was sending that too. I’ll definitely be adding that to my project in the future!
Actually, looking a little more closely at [Michael]’s project – it seems as though the Maverick does NOT send ambient temperature data – he mentions using a DS18S20 1-wire temperature sensor connected to his Flyport board to do that. Too bad though; that would be great if it were built in.
Yep, you’re right, I missed that note about the DS18S20. Come to think of it, when ordering a replacement thermocouple from Maverick, I asked them about the possibility of using two ET-732 simultaneously. They said yes, so long as you completed sync between the first receive/transmit pair before turning on and syncing the second. So you may be right about the remaining data being a counter, or some other rolling code scheme; used so each receiver can distinguish transmissions from the transmitter it’s paired with.
Anyone looked in to the rest of the data sent? Is it a “checksum” as suggested?
I was (completely coincidentally) looking through an old forum thread at Adafruit last night where I had originally posted some of my findings – and it looks like someone over there seems to have figured out the rest of the data:
https://forums.adafruit.com/viewtopic.php?f=8&t=25414&sid=e1775df908194d56692c6ad9650fdfb2&start=15#p322178
I haven’t had a chance to give it a thorough look quite yet, but it seems reasonable at a glance. Basically, it’s an XOR checksum that also uses a unique code which allows for pairing between a particular receiver and transmitter. I’ll definitely update my project once I wrap my head around it.
That’s some outrageous dedication to BBQ temperatures, Bob. You’ve got my congratulations
Anyone know if it’s the same thing for the ET-733?
It would make an amazing cht data logger for aircraft engines