Open lychaxo opened 4 years ago
Here's the -S unknown output with the -X flex removed, for testing. This, by the way, is ch2=LLL/disconnected and ch1 reading around 72 to 73 degrees Fahrenheit. (And, yes, I did check -G 4 -- nothing) ch1_around_72-to-73F.tar.gz
Great analysis and writeup! Indeed the "checksum" looks strange, esp. in the last rows posted it doesn't "move" enough.
@lychaxo What's the status of this issue and next steps?
@gdt I'm not sure on next steps -- I moved to a new house and don't have an SDR setup here (yet). It's probably possible to implement some decoding as per my notes above but I'm not sure how battery/"checksum" stuff factors in, and I don't know when I can investigate further there.
Thanks; marked inactive.
This is a generic-brand device (manual gives "bbq@support20h.com") which is probably distributed by a number of vendors. The one I got had this on a sticker on the box:
I saw on FCC ID on the transmitter, but based on some googling and poking around the FCC database, I think it's 2APN2-EN2053. If that's correct, then: manufacturer is Fuzhou Esun Electronic Co., registration date 09/28/2018, frequency range 433.92-433.92.
I wasn't able to use -A to decode anything (all the bit rows are zeroes), but it did give me the timings by looking at the width buckets, using master from the 8/20 branch (97a3abd). -a 4 seems to not produce anything useful in master, but in version 20.02 it produced the bit stream, so I used that version (plus a 6kHz wide capture with AM decode from CubicSDR tuned to 433.92MHz, studied in audacity [433.927_2020-08-22_17-33-18_feelle_us_02_x0028wrohl.wav.gz]https://github.com/merbanan/rtl_433/files/5113367/433.927_2020-08-22_17-33-18_feelle_us_02_x0028wrohl.wav.gz) to look at the protocol. It's a PPM, and a typical output is 9 bursts of Y LLSS SSSS SSSS SLSL SLSS LLLL LLSL SLLS SSLL SSLS Y. The S is a short gap, the L is a long gap, and the Y is a longer bit-row-transition gap. Each Y/S/L in the above represents a pulse followed by a delay (the spaces are just to break it up into nibbles and the row-marker pulses). So that's nine repetitions of 40 bits. After each set of nine, it's common for there to be a delay and the whole thing to repeat; this can happen a few times. The transmitter seems to transmit regularly, plus when it detects a change in temperature for either attached probe. If a probe is disconnected, the channel reads as "LLL" on the probe, and it transmits the temperature 4,054 degrees Fahrenheit. Temperatures are transmitted in Fahrenheit (at least for my model, regardless of whether F or C is being displayed; there could be non-US models which transmit in Celsius perhaps?) as 12-bit numbers (so, if you treat it as a signed value, -42 degrees is the probe-disconnected value).
The first two nibbles appear to be a signature (never seen them change, but perhaps there could be a low-battery bit in there somewhere). The next three nibbles are channel 1, MSB first; the next three nibbles are channel 2, MSB first; the last two nibbles are probably some kind of checksum, but I can't decode the pattern at all.... so maybe they're something different.
To use a flex decoder for this: -X 'name=bbq2,modulation=OOK_PPM,short=960,long=1936,reset=7500,gap=3892,tolerance=50,repeats>=5,preamble={8}0xc0,unique'
You can use awk to parse the output if you output using -F json with something like
Here's a quick table of some data recorded, in case you want to try to figure out the last byte:
(I was only experimenting with one probe, just to keep things simple. Next time I am grilling/barbecueing with this, I'll try to monitor data to ensure it functions the same when both probes are operating. When the battery starts running low, I will try to grab data again as well.)