Bitbuffer vs cu8 parsing

[habub]

Hello,
I'm trying to decode a signal which doesn't look proper, but is very consistent.
When using -A or bitbuffer_print(), the full signal recorded in cu8 is broken into seperate parts. The analyzer creates 3 packages, which do make up the full signal, but the bitbuffer is really off. It misses half the signal.
Not sure why these partitions were selected. Are there any parameters I can tune (-y, -r, -g, etc.) to control and correct the bitbuffer parsing? or maybe I just have the wrong decoder?
Thanks in advance.

1. The signal cu8 file is attached (change the zip extension).

2. The raw bitbuffers:
   bitbuffer:: Number of rows: 1
   [00] {32} ff fe 80 00 : 11111111 11111110 10000000 00000000
   bitbuffer:: Number of rows: 1
   [00] {114} df 77 ea de fb f5 6d fb ef 7f 7e ff e0 00 00

3. The -A analyzer:
   Detected OOK package
   view at https://triq.org/pdv/#AAB1040600005C003C3C04829355
   Detected FSK package
   view at https://triq.org/pdv/#AAB104002C003800940050829090929090909090909092918090909090909355
   Detected OOK package
   view at https://triq.org/pdv/#AAB10700F801EC0164009003D4003C27148595A595A5B58595B585A5B5A595A5A5A595A595C655

4. The complete log:
   _Detected OOK package 2023-01-07 16:45:01
   bitbuffer:: Number of rows: 1
   [00] {32} ff fe 80 00 : 11111111 11111110 10000000 00000000
   Analyzing pulses...
   Total count: 2, width: 1.69 ms ( 422 S)
   Pulse width distribution:
   [ 0] count: 1, width: 1536 us [1536;1536] ( 384 S)
   [ 1] count: 1, width: 92 us [92;92] ( 23 S)
   Gap width distribution:
   [ 0] count: 1, width: 60 us [60;60] ( 15 S)
   Pulse period distribution:
   [ 0] count: 1, width: 1596 us [1596;1596] ( 399 S)
   Pulse timing distribution:
   [ 0] count: 1, width: 1536 us [1536;1536] ( 384 S)
   [ 1] count: 1, width: 92 us [92;92] ( 23 S)
   [ 2] count: 1, width: 60 us [60;60] ( 15 S)
   [ 3] count: 1, width: 15364 us [15364;15364] (3841 S)
   Level estimates [high, low]: 12991, 15
   RSSI: -1.0 dB SNR: 29.4 dB Noise: -30.4 dB
   Frequency offsets [F1, F2]: 10846, 0 (+41.4 kHz, +0.0 kHz)
   Guessing modulation: Pulse Width Modulation with fixed gap
   view at https://triq.org/pdv/#AAB1040600005C003C3C04829355
   Attempting demodulation... short_width: 92, long_width: 1536, reset_limit: 64, sync_width: 0
   Use a flex decoder with -X 'n=name,m=OOK_PWM,s=92,l=1536,r=64,g=0,t=578,y=0'
   pulse_slicer_pwm(): Analyzer Device
   bitbuffer:: Number of rows: 1
   [00] { 2} 40 : 01

Detected FSK package 2023-01-07 16:45:01
Analyzing pulses...
Total count: 20, width: 2.32 ms ( 581 S)
Pulse width distribution:
[ 0] count: 2, width: 44 us [40;48] ( 11 S)
[ 1] count: 18, width: 56 us [56;56] ( 14 S)
Gap width distribution:
[ 0] count: 3, width: 148 us [144;156] ( 37 S)
[ 1] count: 16, width: 48 us [48;56] ( 12 S)
Pulse period distribution:
[ 0] count: 3, width: 200 us [184;212] ( 50 S)
[ 1] count: 16, width: 104 us [96;112] ( 26 S)
Pulse timing distribution:
[ 0] count: 17, width: 44 us [40;48] ( 11 S)
[ 1] count: 19, width: 56 us [56;56] ( 14 S)
[ 2] count: 3, width: 148 us [144;156] ( 37 S)
[ 3] count: 1, width: 80 us [80;80] ( 20 S)
Level estimates [high, low]: 13237, 15
RSSI: -0.9 dB SNR: 29.5 dB Noise: -30.4 dB
Frequency offsets [F1, F2]: 26164, 922 (+99.8 kHz, +3.5 kHz)
Guessing modulation: No clue...
view at https://triq.org/pdv/#AAB104002C003800940050829090929090909090909092918090909090909355

Detected OOK package 2023-01-07 16:45:01
bitbuffer:: Number of rows: 1
[00] {121} df 7b ef 6e fa ef 5e fd ef 7b f7 be ff c0 00 00
Analyzing pulses...
Total count: 21, width: 9.21 ms ( 2302 S)
Pulse width distribution:
[ 0] count: 3, width: 248 us [248;252] ( 62 S)
[ 1] count: 6, width: 492 us [452;568] ( 123 S)
[ 2] count: 8, width: 356 us [352;360] ( 89 S)
[ 3] count: 3, width: 144 us [140;152] ( 36 S)
[ 4] count: 1, width: 980 us [980;980] ( 245 S)
Gap width distribution:
[ 0] count: 20, width: 60 us [56;68] ( 15 S)
Pulse period distribution:
[ 0] count: 3, width: 312 us [312;312] ( 78 S)
[ 1] count: 12, width: 448 us [416;520] ( 112 S)
[ 2] count: 3, width: 208 us [204;212] ( 52 S)
[ 3] count: 2, width: 624 us [624;624] ( 156 S)
Pulse timing distribution:
[ 0] count: 3, width: 248 us [248;252] ( 62 S)
[ 1] count: 6, width: 492 us [452;568] ( 123 S)
[ 2] count: 8, width: 356 us [352;360] ( 89 S)
[ 3] count: 3, width: 144 us [140;152] ( 36 S)
[ 4] count: 1, width: 980 us [980;980] ( 245 S)
[ 5] count: 20, width: 60 us [56;68] ( 15 S)
[ 6] count: 1, width: 10004 us [10004;10004] (2501 S)
Level estimates [high, low]: 13630, 33
RSSI: -0.8 dB SNR: 26.2 dB Noise: -27.0 dB
Frequency offsets [F1, F2]: 10719, 0 (+40.9 kHz, +0.0 kHz)
Guessing modulation: No clue...
view at https://triq.org/pdv/#AAB10700F801EC0164009003D4003C27148595A595A5B58595B585A5B5A595A5A5A595A595C655
*** Saving signal to file g055_434.47M_250k.cu8 (54313 samples, 131072 bytes)_

g055_434.47M_250k.zip

[zuckschwerdt]

What the -A analyzer does is just guesses. You need to conclude something from the output, maybe a plausible looking -X spec and then use that.
If you view the spectrogram of g055_434.47M_250k.cu8 (drop on pdv) you'll see it is in fact three different signals :)

Just looking at the numbers above I'd say it is 50 µs PCM. The second signal is probably too faint to be decoded correctly.

The first and third signal are likely OOK, but there is strange noise, like it's 2-ASK of not off/on but 20%/100% carrier or such.
It should be Manchester code, but our demod will not pick this up cleanly.

[habub]

Thanks Christian.
Of course your analysis is correct. I guess I just assumed the bitbuffer and the cu8 or -A would be similar.
It does seem the 2nd signal is not strong enough to be decoded. I think the noise is coming from my SDR/Antenna setup grounding. It started picking up and decoding noise all of a sudden.
I went for 100us PCM, but 50us could be. How do you view the spectogram and analog signals in this way? I don't see it like that on PDV.

[zuckschwerdt]

That's the unreleased next version of PDV: https://triq.org/spectrogram-next/
You could grab a sample with higher sample rate (-s 1000k) to get a better view.

[habub]

Thanks. Cool next version....