Difference between triq.org decoding and flex decoder in CLI

[md]

I have the following recording of an 868.350 MHz ESA2000WZ-LED energy monitor transmission. (file esa_perfect.cu8).

When I try an autodecode with rtl_433 I get:

Detected OOK package @6.135356s
Analyzing pulses...
Total count:  130,  width: 80.55 ms (20138 S)
Pulse width distribution:
 [ 0] count:  100,  width:  228 us [220;236] (  57 S)
 [ 1] count:   30,  width:  484 us [476;492] ( 121 S)
Gap width distribution:
 [ 0] count:   99,  width:  272 us [268;284] (  68 S)
 [ 1] count:   30,  width:  528 us [524;536] ( 132 S)
Pulse period distribution:
 [ 0] count:   80,  width:  500 us [492;512] ( 125 S)
 [ 1] count:   38,  width:  760 us [748;772] ( 190 S)
 [ 2] count:   11,  width: 1016 us [1008;1024] ( 254 S)
Pulse timing distribution:
 [ 0] count:  199,  width:  248 us [220;284] (  62 S)
 [ 1] count:   60,  width:  508 us [476;536] ( 127 S)
 [ 2] count:    1,  width: 10004 us [10004;10004] (2501 S)
Level estimates [high, low]:   1000,      7
RSSI: -12.1 dB SNR: 21.5 dB Noise: -33.7 dB
Frequency offsets [F1, F2]:  -15989,      0 (-61.0 kHz, +0.0 kHz)
Guessing modulation: Manchester coding
view at https://triq.org/pdv/#AAB10300F801FC27148080808080808080808080808080819191809180918080908080808080818080908180808080908180809081918080919081808080908190808080819180808090818080809080808191919080808180808080809080808180809081809081808080808090819180809080808080819180908180908080819080808080818090808255
Attempting demodulation... short_width: 228, long_width: 0, reset_limit: 540, sync_width: 0
Use a flex decoder with -X 'n=name,m=OOK_MC_ZEROBIT,s=228,l=0,r=540'
pulse_demod_manchester_zerobit(): Analyzer Device
bitbuffer:: Number of rows: 1
[00] {160} 00 00 a4 8f e3 06 34 58 6f a1 87 ab c0 f1 98 1a 3f 4c f7 e7

Opening the link above gives me immediately the perfect decode of this message

The expected message starts with 0xfffe as decoded here.

When I try to mimick the same parameters in the CLI (s=248,l=248,r=609) I just don´t get that exact result, no matter what I try:

rtl_433 -r ~/esa_perfect.cu8 -X 'n=test,m=OOK_MC_ZEROBIT,s=248,l=248,r=609,invert'
rtl_433 version 21.12 (2021-12-14) inputs file rtl_tcp RTL-SDR SoapySDR
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "/home/daubsi/.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 177 out of 207 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-207 ]
Test mode active. Reading samples from file: /home/daubsi/esa_perfect.cu8
baseband_demod_FM: low pass filter for 250000 Hz at cutoff 25000 Hz, 40.0 us
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : @5.622172s
model     : test         count     : 1             num_rows  : 1             rows      :
len       : 2            data      : 8
codes     : {2}8
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : @6.135356s
model     : test         count     : 1             num_rows  : 1             rows      :
len       : 160          data      : ffff5b701cf9cba7905e78543f0e67e5c0b30818
codes     : {160}ffff5b701cf9cba7905e78543f0e67e5c0b30818

As the web UI telle me it's actually 168 bits and here I have only 160 it seems rtl_433 is interpreting the input somewhat differently.

What would the perfect flex decoder look like which produces this output from the cu8 file please?

FF FE A4 8F E3 06 34 58 6F A1 87 AB C0 F1 98 1A 3F 4C F7 E7

Thanks!

[Christian Z.]

Leading short pulses in MC are ambiguous, depending on the first long pulse or gap those can be 1's or 0's. The rtl_433 decoder is not smart enough to "go back" and correct already decoded symbols. But it will smooth over slightly corrupted symbols.

It needs a rework someday, but the logic to accept slightly broken inputs is hard to adapt.

You might want to decode as PCM (~230 µs) and then later MC decode. The flex decoder however can't do two-stage decoding :/

[md]

So - in other words - it is not possible to properly decode this signal with rtl_433 (right now)? I cannot give it a hint or something? 
I am not sure what you mean with "going back to correct". Would the decoder somewhere in the middle be able to recognize the first symbol is wrong? Is this why the decoding is totally different? Because it's kind of "off-by-1"? 

[md]

Just looked at some existing decoders e.g. src/devices/nexa.c and see what you mean. It's initially OOK_PULSE_PWM decoded and later on there's an additional manchester decoding... Will try to write something which mimicks this and handles my signal. Thanks!

[Christian Z.]

Yes, off-by-one is kind of correct. Short pulse+gap sequences don't have a known alignment in MC -- edges could be data or clock. You always need a long pulse or gap to "anchor" the whole sequence (long pulse or gap is always data, never clock).

But the rtl_433 MC slicer will output a bit for every MC transition encountered as it walks through them. Encountering some "anchor" later on won't help to correct previous bits.

It's quite common in our decoders to first PCM (not PWM -- the gaps are significant) decode an then apply MC decoding with some bounds and checks.

A full decoder seems to heavy-weight for such a simple sender. Maybe just accept both decoding, with leading 0's and also 1's. Those are a likey only a preamble pattern?

[Christian Z.]

Ok, sure, if you need further steps like encryption decoding a full decoder sounds proper. I didn't parse that it's a energy monitor and wrongly assumed a doorbell-style button. My bad.

[md]

All fine! I just added the full code (in a dirty way) and it is looking good already!

First check
2nd check
Checks passed
data[0] = 0xa4 -> 0x2d
data[1] = 0x8f -> 0x47
data[2] = 0xe3 -> 0x50
data[3] = 0x06 -> 0x01
data[4] = 0x34 -> 0x1e
data[5] = 0x58 -> 0x00
data[6] = 0x6f -> 0x13
data[7] = 0xa1 -> 0x32
data[8] = 0x87 -> 0x42
data[9] = 0xab -> 0x00
data[10] = 0xc0 -> 0x0f
data[11] = 0xf1 -> 0x15
data[12] = 0x98 -> 0x8d
data[13] = 0x1a -> 0xa6
data[14] = 0x3f -> 0x01
Success!Got it_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-09-09 22:39:13.587723             Protocol  : 260
model     : ESA2000WZ-LED Preamble  : 65534
Modulation: ASK          Freq      : 433.9 MHz
RSSI      : -13.7 dB     SNR       : 27.3 dB       Noise     : -41.0 dB

I can eyeball the resulting values in data[X] are correct and also the CRC matches (Success!Got it)... Now it's just a small step to extract and display the proper data... and to make it all proper and readable code :-D

Thanks a lot, will work on it and let you know when I'm done!

[md]

Very satisfied with the evening spent :-D

daubsi@skywatch:~/rtl_433_dev/build $ ./src/rtl_433 -R 260 -r ~/esa_perfect.cu8
rtl_433 version -128-NOTFOUND branch master at 202408051231 inputs file rtl_tcp RTL-SDR with TLS
Reading conf from "/home/daubsi/.config/rtl_433/rtl_433.conf".
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-09-09 23:58:22.740053             Protocol  : 260
model     : ESA2000WZ-LED Sequence  : 173          Device    : 4750          Total ticks: 1258050      Actual ticks: 15          Ticks     : 500

Modulation: ASK          Freq      : 433.9 MHz

RSSI      : -17.6 dB     SNR       : 24.1 dB       Noise     : -41.7 dB
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-09-09 23:58:23.088992             Protocol  : 260
model     : ESA2000WZ-LED Sequence  : 45           Device    : 4750          Total ticks: 1258050      Actual ticks: 15          Ticks     : 500

Modulation: ASK          Freq      : 433.9 MHz
RSSI      : -13.7 dB     SNR       : 27.3 dB       Noise     : -41.0 dB