Help decoding new device

[Richard Gedge]

I've just started to decode the output from a new sensor I have. I have capture the output to a cu8 file in a screened area so I'm 100% sure that the signal is only from the sensor.

The result of importing into Audacity is attached. The first block is FSK, the second block is OOK and the 3rd block is a repeat of the 2nd block.

My first thought was to cut the file up to remove the FSK block and then try and decode individually. So to get the FSK part I used the dd below.

dd if=g001_868.2M_1000k.cu8 of=g001_868.2M_1000k_FM.cu8 count=2300 

Loading into Audacity shows just the FM section but when I try and analyse using rtl_433 I get.

Input: Input format invalid "Unknown"

I'm obviously missing something but what? I carried analysing the whole file.

Putting the original uncut file through rtl_433 -A filename gives the following. Looking at the OOK blocks they appear to have a fixed gap but variable length pulse. See screen shots.

Detected OOK package @0.146859s
Analyzing pulses...
Total count: 773, width: 741.26 ms (741260 S)
Pulse width distribution:
[ 0] count: 1, width: 447622 us [447622;447622] (447622 S)
[ 1] count: 40, width: 467 us [465;492] ( 467 S)
[ 2] count: 62, width: 300 us [299;301] ( 300 S)
[ 3] count: 638, width: 133 us [132;135] ( 133 S)
[ 4] count: 12, width: 633 us [633;635] ( 633 S)
[ 5] count: 14, width: 848 us [799;968] ( 848 S)
[ 6] count: 6, width: 1244 us [1134;1300] (1244 S)
Gap width distribution:
[ 0] count: 2, width: 59320 us [58124;60516] (59320 S)
[ 1] count: 770, width: 33 us [32;35] ( 33 S)
Pulse period distribution:
[ 0] count: 1, width: 508138 us [508138;508138] (508138 S)
[ 1] count: 40, width: 501 us [498;525] ( 501 S)
[ 2] count: 62, width: 333 us [332;335] ( 333 S)
[ 3] count: 638, width: 166 us [165;169] ( 166 S)
[ 4] count: 18, width: 740 us [666;834] ( 740 S)
[ 5] count: 7, width: 976 us [834;1168] ( 976 S)
[ 6] count: 5, width: 1300 us [1167;1334] (1300 S)
[ 7] count: 1, width: 58758 us [58758;58758] (58758 S)
Pulse timing distribution:
[ 0] count: 1, width: 447622 us [447622;447622] (447622 S)
[ 1] count: 40, width: 467 us [465;492] ( 467 S)
[ 2] count: 62, width: 300 us [299;301] ( 300 S)
[ 3] count: 638, width: 133 us [132;135] ( 133 S)
[ 4] count: 12, width: 633 us [633;635] ( 633 S)
[ 5] count: 14, width: 848 us [799;968] ( 848 S)
[ 6] count: 6, width: 1244 us [1134;1300] (1244 S)
[ 7] count: 2, width: 59320 us [58124;60516] (59320 S)
[ 8] count: 770, width: 33 us [32;35] ( 33 S)
[ 9] count: 1, width: 100001 us [100001;100001] (100001 S)
Level estimates [high, low]: 15860, 11
RSSI: -0.1 dB SNR: 31.6 dB Noise: -31.7 dB
Frequency offsets [F1, F2]: 4468, 0 (+68.2 kHz, +0.0 kHz)
Guessing modulation: No clue...

I'm a bit stuck on the next steps, I tried to get pulseview but it no longer works on my Mac :( Any ideas on the modulation/encoding?

Thanks

Richard

Audacity Screen shots. Block1=FSK, Block2=OOK, Block3=Block2

OOK lead in with fixed gap and pulse width

First data after lead in showing variable pulse width but fixed gap.

[Christian Z.]

The result of importing into Audacity is attached. The first block is FSK, the second block is OOK and the 3rd block is a repeat of the 2nd block.

Are your sure about the FSK? It could be a long OOK warmup.

 

 cut the file up to remove the FSK block and then try and decode individually. So to get the FSK part I used the dd below.

That should work. In the future PDV will also support that. The demo is at https://triq.org/spectrogram-next/ (not Safari, see below)

 

Loading into Audacity shows just the FM section but when I try and analyse using rtl_433 I get. Input: Input format invalid "Unknown"

Maybe you mixed up the file extension?

Putting the original uncut file through rtl_433 -A filename gives the following. Looking at the OOK blocks they appear to have a fixed gap but variable length pulse.

Just one gap size but multiple different pulse length is not something we have seen before, strange.

 

I'm a bit stuck on the next steps, I tried to get pulseview but it no longer works on my Mac :( Any ideas on the modulation/encoding?

That's createImageBitmap() which is not supported on Safari https://developer.mozilla.org/en-US/docs/Web/API/createImageBitmap#browser_compatibility

Best to use Firefox or Chrome with PDV.

To get the data I would try a coding of PCM. The length of 133/300/633/848/1244 µs don't clearly show the bit rate, maybe around 100 µs?

[Richard Gedge]

Thanks for the quick response.

Are your sure about the FSK? It could be a long OOK warmup.

No but I think you're right, it's just alternating tones, no information there. See picture.

Just one gap size but multiple different pulse length is not something we have seen before, strange.

Me neither, it's interesting that the pule widths are almost multiples of the narrowest pulse....

To get the data I would try a coding of PCM. The length of 133/300/633/848/1244 µs don't clearly show the bit rate, maybe around 100 µs?

I've attached a couple of the files but I'll have a try of a few decoder options to see what appears.

[Christian Z.]

In your screenshot: The exact frequencies and levels don't really match between FSK and OOK part. Could this be two different devices in conversation? Or are those two different radios?

In spectrogram-next: zoom in with the mouse wheel and it get's crazy, there are very short hops between the frequency changes (which diverge over time like a chirp) and the aliases(?) at 868.16M / 868.08M looks like there is actual FSK data.

[Richard Gedge]

I've just had a look inside the device, there's only one 868 antenna I can see but there is a radio time signal receiver with a small ferrite antenna, so I guess it could be something from the superhet mixing process but seems unlikely at that signal level. It could be two transmissions to maintain compatibility with older hardware? 

The transmission should only contain a temperature and humidity value so not much data.

[Christian Z.]

It might help to look at the raw OOK, use

rtl_433 -w g002_868.2M_1000k.ook g002_868.2M_1000k.cu8

then inspect that file or drop on pdv.

It kinda looks like RZ coding. And this scheme then might work:

a symbol ("0"/"1") is 133 us pulse plus either 33 us pulse ("1") or 33 us gap ("0). I.e. each bit is a fixed 166 µs long.

This encodes all 1's as straight pulse and 0's have those 33 us gaps:

- count: 32, width: 468+33 us -> 3x: "110"

- count: 66, width: 300+33 us -> 2x: "10"

- count: 654, width: 133+33 us -> 1x: "0"

- count: 14, width: 634+33 us -> 4x: "1110"

- count: 12, width: 828+33 us -> 5x: "11110"

- count: 6, width: 1301+33 us -> 8x: "11111110"

(a flex decoder shuld be

rtl_433 -R 0 -X 'n=name,m=OOK_PCM,s=33,l=33,g=50,r=1000,symbol_zero={5}f0,symbol_one={5}f8' g002_868.2M_1000k.cu8

but that's not working correctly).

[Richard Gedge]

That would explain the different pulse widths. 

I didn't even know the symbol options existed for the decoder, I'll have to have another look though the source code. 

Thanks for the insights.

[Christian Z.]

I didn't even know the symbol options existed for the decoder, I'll have to have another look though the source code. 

It was just recently added with https://github.com/merbanan/rtl_433/pull/2161

to support the use case from https://github.com/merbanan/rtl_433/pull/2066

It could work if we recover the sync. Something like

rtl_433 -R 0 -X 'n=name,m=OOK_PCM,s=33,l=33,g=50,r=1000,preamble=f7bdef7bde,symbol_zero={5}f0,symbol_one={5}f8' g002_868.2M_1000k.cu8

but there is drift and the symbols get out of sync.

[Richard Gedge]

I've spent several more hours on this and can't work out what's going on, I've grabbed a few more samples and one of them seems too have completely different timings. I think I'm going to have to admit defeat. Thanks for your help and suggestions though.

Richard

[Christian Z.]

That sample looks fine and the code should be (repeated twice)

a572 d23c fa11 ac4f 2ec0 0f61 d0a9 2356 0e68 a8bc be05 15f6 5d57 3173 feea 11d4 152a

Way to much data for a simple device though.