zuckschwerdt
commented
2 years ago Caveat for future readers: with FSK the data is in "mark" and "space", what we lazily call pulse and gap. Also short pulse for MC/DM coding is the half-bit width, long would be the (full-)bit width.
Yes, there should be an option to use DM coding. We also don't have that for regular decoders as there are problems with codings:
- You might have received a valid PCM stream, but it won't exactly decode as MC/DM: should the decoder just be skipped? No chance to log errors then. Should we just decode the valid part? The decoder would not see the rest, and thus not the full length then?
- There are often (de-)synch symbols in the PCM, the MC/DM code is prefixed with an "illegal" sequence to mark the start. Can we decode at all? How would we transport that info in a bitbuffer?
But I guess we can add a decode_dm flex option, similar to the decode_uart and in this case really ignore all bad data.
gustep12
I am trying to capture some 315MHz transmissions from TPMS sensors. The short pulse duration is 50 microseconds, the long duration 100 microseconds. Also, it is an FSK signal with 315MHz +/- 30 kHz modulation.
I can successfully detect and capture a transmission with the FSK_MC_ZEROBIT modulation option as follows:
sudo rtl_433 -f 315M -s 1024k -R 0 -X 'n=TPMS,m=FSK_MC_ZEROBIT,s=53,l=105,g=150,r=150,t=10' -S known
The problem is that rtl_433 will decode this as regular Manchester and give this result:
55 55 BA 03 5C 72 9F E4 01 7C 5D 24 8
But really it should be decoded as differential Manchester. How can I do this?
Proof:
When I then analyze the capture file with rtl_433 -A I get the following (correct) pulse data:
https://triq.org/pdv/#AAB00D0501000000670033009300088355+AAB0540501000000670033009300089191919191919192A192A2A191A2A2A2A2A2A292A19192A2A1A2A292A2A1A29191A292A2A2A2A2A2A2A1A291A2A2A2A2A2A2A2A29192A2A2A2A1A2A29192A2A191A291A291A292A455
To correctly interpret this pulse data, I need to select "DM", or differential Manchester, as the slicer on triq.org
That way I get the (correct) result string:
{120} / FF FE CE 05 E4 97 A0 2C 03 84 E7 6D 00 /
FF FE is the preamble, CE 05 E4 97 is the TPMS sensor serial number, and the rest I don't yet know. However typically there are three such transmissions in quick succession which only differ in the last few bytes, which probably separately encode pressure, temperature, and who knows what else.
Now my question is, how can I get this result string directly in rtl_433 - meaning, without going through triq.org?
I suspect to do this I would need a modulation option for the flex decoder that combines FSK and DM, but such an option does not currently seem to exist?
Any advice would be greatly appreciated.