Thermopro TP07S decode attempt

[bennydiamond]

Hi,

I just bought a Thermopro TP07S wireless cooking thermometer.

I've already established the device transmits on 915MHz band.

Actually, by passing '-a 4' argument to rtl_433 I get a workable bitstream.

$rtl_433 -f 915M -a 4

...

*** signal_start = 11461854, signal_end = 11627975, signal_len = 166121, pulses_found = 101
Iteration 1. t: 472    min: 469 (83)    max: 476 (18)    delta 68
Iteration 2. t: 472    min: 469 (74)    max: 475 (27)    delta 1
Iteration 3. t: 472    min: 469 (74)    max: 475 (27)    delta 0
Distance coding: Pulse length 472

Short distance: 505, long distance: 1463, packet distance: 3429

p_limit: 472
bitbuffer:: Number of rows: 3
[00] {33} 15 81 bb 52 80 : 00010101 10000001 10111011 01010010 1
[01] {33} 15 81 bb 52 80 : 00010101 10000001 10111011 01010010 1
[02] {32} 15 81 bb 52    : 00010101 10000001 10111011 01010010
*** signal_start = 23462502, signal_end = 23628619, signal_len = 166117, pulses_found = 101
Iteration 1. t: 472    min: 469 (82)    max: 475 (19)    delta 53
Iteration 2. t: 472    min: 469 (76)    max: 475 (25)    delta 0
Distance coding: Pulse length 472

Short distance: 506, long distance: 1462, packet distance: 3433

p_limit: 472
bitbuffer:: Number of rows: 3
[00] {33} 15 81 bb 52 80 : 00010101 10000001 10111011 01010010 1
[01] {33} 15 81 bb 52 80 : 00010101 10000001 10111011 01010010 1
[02] {32} 15 81 bb 52    : 00010101 10000001 10111011 01010010
*** signal_start = 35463148, signal_end = 35629263, signal_len = 166115, pulses_found = 101
Iteration 1. t: 472    min: 469 (82)    max: 476 (19)    delta 58
Iteration 2. t: 472    min: 469 (78)    max: 475 (23)    delta 1
Iteration 3. t: 472    min: 469 (78)    max: 475 (23)    delta 0
Distance coding: Pulse length 472

Short distance: 506, long distance: 1463, packet distance: 3429

p_limit: 472
bitbuffer:: Number of rows: 3
[00] {33} 15 81 bb 52 80 : 00010101 10000001 10111011 01010010 1
[01] {33} 15 81 bb 52 80 : 00010101 10000001 10111011 01010010 1
[02] {32} 15 81 bb 52    : 00010101 10000001 10111011 01010010
*** signal_start = 47463788, signal_end = 47629908, signal_len = 166120, pulses_found = 101
Iteration 1. t: 472    min: 469 (83)    max: 476 (18)    delta 53
Iteration 2. t: 472    min: 469 (72)    max: 475 (29)    delta 1
Iteration 3. t: 472    min: 469 (72)    max: 475 (29)    delta 0
Distance coding: Pulse length 472

Short distance: 506, long distance: 1463, packet distance: 3430

p_limit: 472
bitbuffer:: Number of rows: 3
[00] {33} 15 81 bb 52 80 : 00010101 10000001 10111011 01010010 1
[01] {33} 15 81 bb 52 80 : 00010101 10000001 10111011 01010010 1
[02] {32} 15 81 bb 52    : 00010101 10000001 10111011 01010010

Manually decoding received bitstream using the logic contained in 'thermopro_tp11.c', I can successfully decode the stream. I do manage to calculate the temperature reported by the device.

Now, I'm trying to force rtl_433 to use the 'thermopro_tp11.c' decoder with it but it won't output anything.

Here is the command line:

$rtl_433 -F 915M -R 84

Granted I have not manually calculated the checksum to see if it matches but quite frankly I doubt this could be the issue.

Any idea why it won't decode? I have not confirmed if usage of a specific decoder is tied to a specific capture frequency, which I doubt is the case with rtl_433.

Thanks

[bennydiamond]

Sorry, typo in the device product name.

It's actually a Thermopro TP07B

[bennydiamond]

Following the contribution guideline, I generated a .cu8 file with my device captured (at 915MHz).

$ rtl_433 -f 915M -S unknown

Reading back the file with rtl_433 without specifying a capture frequency and surprise, the content of the .cu8 file is successfully decoded as a Thermopro-TP11 device!

$ rtl_433 -r g007_915M_1000k.cu8
rtl_433 version 21.12-39-g6e4f874a branch master at 202201241652 inputs file rtl_tcp RTL-SDR with TLS
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "/home/bennyboy/.config/rtl_433/rtl_433.conf"...
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...
Trying conf file at "/etc/rtl_433/rtl_433.conf"...
Registered 181 out of 212 device decoding protocols [ 1-4 8 11-12 15-17 19-23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119 121 124-128 130-149 151-161 163-168 170-175 177-197 199 201-212 ]
Test mode active. Reading samples from file: g007_915M_1000k.cu8
baseband_demod_FM: low pass filter for 1000000 Hz at cutoff 100000 Hz, 10.0 us
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : @0.034079s
model     : Thermopro-TP11                         Id        : 344
Temperature: 23.6 C      Integrity : CRC

So I being to question if a specific decoder is actually tied to a specific capture frequency, in rtl_433.

[H S]

Are you sure it transmits on the 915Mhz band? my Thermopro TP08 (almost identical unit) transmits on 433Mhz....

[Christian Z.]

Don't use "-a", rather use "-A", it's much nicer.

I guess the difference between live and playback is "-Y minmax" vs "-Y classic".

Not sure why minmax doesn't work. We need a sample that shows this behaviour.

[bennydiamond]

> Are you sure it transmits on the 915Mhz band? my Thermopro TP08 (almost identical unit) transmits on 433Mhz....

It's 915 MHz.

Says so on the FCC ID page : https://fccid.io/2AATPTP07B

Also, I need to run rtl_433 specifying a capture frequency of 915MHz.

> Don't use "-a", rather use "-A", it's much nicer.

Actually, using "-A", the flex decoder always tries to demod using FSK_PCM even with a specified flex decoder, which obvisouly does not generate a correct output for my needs. Even when I specify a flex decoder in command line, it will just use its own flex of 'n=name,m=FSK_PCM,s=1,l=1,r=1024'.

So actually running with "-A" just does not produce any good result but with "-a" I do get a properly demodulated bitstream.

Here's a pastebin of when running with "-A" switch: https://pastebin.com/zF7nw9DH

Here's when running with "-a 4" switch: https://pastebin.com/Dr0Aj3Cf

> I guess the difference between live and playback is "-Y minmax" vs "-Y classic".

Huzzah! That did it. Running with "-Y classic" switch fixes it. I get a decoded output.

$ rtl_433 -f 915M -Y classic

rtl_433 version 21.12-39-g6e4f874a branch master at 202201241652 inputs file rtl_tcp RTL-SDR with TLS
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "/home/bennyboy/.config/rtl_433/rtl_433.conf"...
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...
Trying conf file at "/etc/rtl_433/rtl_433.conf"...

New defaults active, use "-Y classic -s 250k" for the old defaults!

Registered 181 out of 212 device decoding protocols [ 1-4 8 11-12 15-17 19-23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119 121 124-128 130-149 151-161 163-168 170-175 177-197 199 201-212 ]

Detached kernel driver
Found Rafael Micro R820T tuner
Exact sample rate is: 1000000.026491 Hz
[R82XX] PLL not locked!
Sample rate set to 1000000 S/s.
Tuner gain set to Auto.
Tuned to 915.000MHz.
Allocating 15 zero-copy buffers

baseband_demod_FM: low pass filter for 1000000 Hz at cutoff 100000 Hz, 10.0 us
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

time      : 2022-02-02 14:39:25

model     : Thermopro-TP11                         Id        : 344
Temperature: 23.6 C      Integrity : CRC

Of course my device is identified as a Thermopro TP11 even if it's a TP07B but at that point I can live with that.

Is there an easy way to force a custom name over a specific decoder?

Would it be easy to implement a way to discriminate what type of device it is based on capture frequency range in the decoder source file itself?

> Not sure why minmax doesn't work. We need a sample that shows this behaviour.

I'll be making a couple of captures and will submit a PR to upload the captures. I'll try to cover as much combination of relevant command line switches as possible.

[Christian Z.]

The flex decoder from -A is just a suggestion. Instead of running -a to get a (maybe working) decode, you should always run -A, inspect and adjust the flex suggestion, then run with just -X

If rtl_433 sees FSK instead of OOK, that might be an artifact of a not optimal center frequency. Try adjusting the frequency a little, say 914.9M or 915.1M also try a sample rate of -s 250k

(and there is a possibility this new device is actually FSK, we have seen that in a few others with FSK/OOK option depending on country/frequency)

There is no option to rename built-in decoders, if it works like a TP11 it is a TP11 :)

[bennydiamond]

> The flex decoder from -A is just a suggestion. Instead of running -a to get a (maybe working) decode, you should always run -A, inspect and adjust the flex suggestion, then run with just -X

Gotcha, I understand. I am not an expert in this but I managed to luckily get much farther using "-a" over "-A" this time.

> If rtl_433 sees FSK instead of OOK, that might be an artifact of a not optimal center frequency. Try adjusting the frequency a little, say 914.9M or 915.1M also try a sample rate of -s 250k

> (and there is a possibility this new device is actually FSK, we have seen that in a few others with FSK/OOK option depending on country/frequency)

Shifting the center frequency does nothing good. In SDRSharp, the device pretty much emits at 915MHz sharp.

Increasing sample rate to what you suggested does produce somewhat a better result.

It does manage to decode using thermopro_tp11.c decoder sometimes but the rest of the output is just non-sense data to me at least:

https://pastebin.com/Ype5f8rx

Also, using "-Y classic" switch with the default sample rate of 100K works wonder (pretty much 100% detection rate). I get a positive output everytime the device emits. While using default requires increasing the sample rate to 250K and even so, it does not successfully decode all the time.

https://pastebin.com/d5Ja7bXP

My feeling is you're trying to steer users away from the "classic" FSK detector moving forward and I just thought it might be relevant to let you know. So I don't know if I should put more effort in making it work with the default FSK detector or just force "classic" and call it a day.

> There is no option to rename built-in decoders, if it works like a TP11 it is a TP11 :)

Fair enough, I just want to point out that TP11 operates at 433MHz while the TP07B is at 915MHz.

I'm using the addon in hassio which makes use of the config file. I'm already sampling some devices on 433MHz using default FSK decoder. Is there a way to set up the config file so the classic FSK detector gets used when capturing on 915MHz range only?

Thanks for taking the time with this. I know I must be a bother but I'm trying to learn as I go along!

[Christian Z.]

The default sample rate for above 433M is 1000k, the 250k at 915M reset that back to the default of 250k. It's known to work better for some cases, thanks for the feedback!

Note that hitting the carrier frequency exactly is not ideal. If the sensors is at 915.00M You should offset a little, e.g. 915.05M.

If it really is FSK and you hit one of the frequencies exactly it would look like OOK, maybe that's why it works?

[bennydiamond]

> The default sample rate for above 433M is 1000k, the 250k at 915M reset that back to the default of 250k. It's known to work better for some cases, thanks for the feedback!

In all cases I keep the default sample rate of 100K. Looking at the terminal output of rtl_433, it does not explicitely says it changes the sample rate when it hops between capture frequencies. So I would assume it stays at 100K all the time, as it states at beginning of program run.

The only thing that makes it better, is setting FSK detect to "classic" rather than auto.

> Note that hitting the carrier frequency exactly is not ideal. If the sensors is at 915.00M You should offset a little, e.g. 915.05M.

Gotcha. I played around a bit, going down to 2 decimal digits but quite frankly, it feels like 915M gives me the best results.

> If it really is FSK and you hit one of the frequencies exactly it would look like OOK, maybe that's why it works?

I don't think. Supplying a demod param of "OOK_PPM" in my flex decoder make it decode the stream correctly. It's also the demod param used in "thermopro_tp11.c" decoder. Also, FCC test report states modulation used is ASK.

I know I'm repeating myself but

"$ rtl_433 -f 915M -R 84 -Y classic" works perfect while

"$ rtl_433 -f 915M -R 84" does not produce an output.

Could it be the new FSK detect algo might be too aggressive in some case and produces some false positive in my case?

So should I keep banging my head to make it work with the "auto" FSK detect or should I just stick with "classic" and call it a day? I plan on hoping between 433.92M and 915M every 60 seconds to detect a couple of different device so all these guys would be affected by the use of the "-Y classic" switch, even though none of them use FSK modulation.

[Benjamin Larsson]

On 2022-02-03 05:27, bennydiamond wrote:
> Could it be the new FSK detect algo might be too aggressive in some case
> and produces some false positive in my case?

I'm to blame for this. Can you record a signal sample so I can
investigate the cause?

Use rtl_433 -f 915M -S all to record the signals and use -r to playback
them. When you have proper samples open a github ticket and I'll have a
look.

MvH
Benjamin Larsson