Incorrect data flex decoder (-X) and pulse analyzer (-A)

[habub]

Hi,
While analyzing a new device I noticed strange behavior of the flex decoder and pulse analyzer.

1. This is the pulse analyzer (-A) output: PDV
   Bits: {793} 8A AA AA 0F A6 6B 39 04 82 74 95 65 58 3E 66 93 2B FA FE 8B AA AA A8 3E 99 AC E4 12 09 D2 55.......

2. Applying the corresponding flex decoder (-X "n=Name,m=OOK_PCM,s=208,l=208,r=1500,g=0,t=0,y=0") provides a different output:
   len : 971 data : 85555507d3359c81204e92acab07ccd2657f5fd175555507d3359c81204e92acab07ccd2657f5fd175555507d3359c81204e.....
   Why? (assuming the PCM decoder is correct)

3. If I try to match the bits in the flex decoder to the pulse analysis (e.g. match={64}aaaaa0fa66b3904") the decoding fails, the bits don't match.
   BUT if I reduce the matching bits to 56 (match={56}aaaaa0fa66b3904") the signal is decoded successfuly, although it's still displayed incorrectly.
   Strange....

4. I tried the flex decoder in an older version of RTL_433 (from 2019) and got different results. The flex decoder data is now correct (!!), BUT it's different than the original pulse analyzer.
   len : 810 data : 8aaaaa0fa66b3902409d2559560f99a4cafebfa2eaaaaa0fa66b3902409d2559560f99a4cafebfa2eaaaaa0fa66b39024......
   Notice the 8th byte is different than the pulse analyzer: 8aaaaa0fa66b39024 vs 8aaaaa0fa66b3904
   Why?

5. Based on (4) I updated the flex decoder matching to the older RTL: match={64}aaaaa0fa66b39024 and it works!
   Although now it doesn't match the pulse analyzer or the flex decoder, it works great on both versions to decode the device and I can match the 64 bits intended.

Not sure I understand what's happening and what I'm doing wrong.
Any thoughts?

[zuckschwerdt]

The PDV links only have rounded timings. You should capture a sample (https://triq.org/rtl_433/ANALYZE.html) and convert to ook text (rtl_433 -w OOK:- filename.cu8) and inspect that (also upload here as zip).

The newer rtl_433 PCM slicer will analyze the timing in the preamble and adjust to that.

Note that both codes are mostly the same, but long gaps add a 0-bit that I'd say should not be there.
Data in a BitBench.

[habub]

Thanks for the quick reply.
Attached are the cu8 and ook files. Inspecting the files gives a different result.
What is the source of truth? The correct method?
sample files.zip

[zuckschwerdt]

If you put the cu8 or ook on https://triq.org/pdv/ and zoom into the pulse data: the pulses/gaps are not well balanced, i.e. 228+188 in the preamble, which averages to 208, you can see that with rtl_433 -vvv -R 0 -X "n=Name,m=OOK_PCM,s=208,l=208,r=1900" g007_418.05M_250k.cu8 as "Exact bit width (in us) is 207.56 vs 208.00, 18 bit preamble"
But the longer pulse/gap of 1056 are they 4 or 5 bits then? I would now say it's 5 bits -- the flex decoder is right.
By the way, the -A analyzer uses the flex decoder too, with the parameter then shown.

The flex decoder with PCM 208µs is right. Also note that the packet is repeat 6 times, there is just no gap between packets sadly.
The payload is 5555 507d 3359 c812 04e9 2aca b07c cd26 57f5 fd17

[habub]

Thanks for the detailed analysis and answer!