Closed PaulKierstead closed 2 years ago
zuckschwerdt
commented
2 years ago Demod to OOK: rtl_433 -w g002_915M_1000k-18c-18c.ook g002_915M_1000k-18c-18c.cs16 drop on https://triq.org/pdv/
Compare visually by also dropping the cs16 there. Not perfect, you are in the DC and also got a spike there (from the cs16 conversion likely).
Looks like PPM, short 200, long 1200. But he signal is not clean enough to pickup automatically.
PaulKierstead
commented
2 years ago Demod to OOK:
rtl_433 -w g002_915M_1000k-18c-18c.ook g002_915M_1000k-18c-18c.cs16drop on https://triq.org/pdv/Compare visually by also dropping the cs16 there. Not perfect, you are in the DC and also got a spike there (from the cs16 conversion likely).
Looks like PPM, short 200, long 1200. But he signal is not clean enough to pickup automatically.
Ah, that put me on the right track. I tried a couple of other capture devices (that one was with soapySDR/hackrf, I think the gain needed adjusted...) and it actually occasionally gets picked up by decoder 97 (with frequency forced to 915 MHz), but not very reliably, but a custom OOK_PPM will pick it up very reliably and the encoding is clearly identical to the TP-12/20 (#97). I have a way forward now, thank you very much!
zuckschwerdt
commented
2 years ago The "Thermopro TP08/TP12/TP20 thermometer" has PPM and short_width = 500, long_width = 1500, so that should work if you can get better reception (offset center frequency and less gain).
PaulKierstead
commented
2 years ago 500/1500 works, but is riiiiight on the line, a little lower would be more reliable. Not sure how that would affect the other ones (they could be on the line in the other direction for all I know...).
However, there is a bug in thermopro_tp12.c (or bitbuffer.c, not sure which to blame as not sure the intent), which combined with the behavior of the TP20B ends up missing a lot samples. From the TP20B, I get a lot like this:
time : 2022-03-30 13:09:35
model : name count : 3 num_rows : 3
rows :
len : 41 data : 0477116d660,
len : 41 data : 0477116d668,
len : 40 data : 0477116d66
codes : {41}0477116d660, {41}0477116d668, {40}0477116d66That last bit is always missing from the last row (like the other models), but also it is sometimes 0, and sometimes 1 in the previous 2 rows. Now if you look at line 60 in thermopro_tp12.c, you'd think (as was clearly the intent) that row 0 would match row 2, or even row 1. However, looking at bitbuffer.c in line 492 we will call bitbuffer_count_repeats with max_bits of 0. Because of that, looking at line 471-473, row 0/1 cannot match row 2 despite the intention, as they do not have the same number of bits, and row 0 will not match row 1 in our case because of the flipped last bit (and we passed max_bits == 0)
I'd put this bug on thermopro_tp12.c as the find repeated row says min_bits, not "compare this exact number" so I think it bitbuffer_find_repeated_row is working as intended, it is just not what was desired in this case. I can try to figure out how to fix thermopro_tp12.c to match rows while ignoring the last bit altogether without breaking anything else and do a PR if you like.
PaulKierstead
commented
2 years ago Put in a PR, will not affect anything else, tested it out and much more reliable now (truly only requires 2 rows to match, ignoring the last bit)
zuckschwerdt
commented
2 years ago Good analysis! Thanks. There might be overlap with bitbuffer_find_repeated_prefix() recently added. I guess this is a "prefix" of length 40 we want to match, right?
PaulKierstead
commented
2 years ago Lol, I should have scrolled down a bit in the file, indeed that will do the trick nicely. I'll update to use that.
So, I wanted a TP20 for my smoker, as it is supported, but amazon sent me a TP20B. Ah, well, lets have a look.
Its a 915 MHz device, using a CMT2119A radio, clearly in OOK mode. I've poked at it with URH, but ... it has too many ones :D I'm not new to protocol reveng, but am new to radio protocol reveng and don't really know where to go from here. I can run a lot of captures and the presumable preamble (12 or 16 bits) is very consistent, but things get less consistent after that. I've attached a sample, this one had both temperature sensors at 18 C. Where do I go from here? Any ideas on what encoding might be used here?
g002_915M_1000k-18c-18c.zip
-A output: