Add 8n2 decoding option in flex decoders

[bennesp]

Flex decoders can specify decode_uart to decode 8n1

Since some protocols also use 8n2 (start bit = 0, 8 data bits, no parity, two stop bits = 1) it would be great to have it already built in rtl_433

An example of protocol using 8n2 is RADIAN 0.

[zuckschwerdt]

Sure, sounds good.
Can you link to some details about that protocol / device so we have some reference? It's a smart meter protocol?
Since a flex decoder for a complex protocol would only be the first step, maybe we need 8n1/8n2 also in BitBench?

[bennesp]

Unfortunately I don't have any official detail on RADIAN protocol. Only unofficial ones, spread across internet.
The most useful to me was a website that is now down but I succeeded in recovering a PDF of the web page in mixed languages.

An example of successfully decoding is the following:

$ rtl_433 -s 250k -X "n=RADIAN,m=FSK_PCM,s=416,l=416,r=20000"

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : @1.272112s
model     : test-fsk     count     : 1             num_rows  : 1             rows      : 
len       : 2490         data      : fffaaaaaaaaaaaaaaaaaaaa8000000003fffffffffe8bd11acb3be28c019e342eb2cef92358655dd180368616d3ba770b610c0193b446aad238633beb2c118431e600c01803206bfdd181300640d7fbc31b600c41adb046acc19b7360676c01803006a0cef9bb6ce3bde580b2069ad21b83206a6d0d98360e08d7fa3300600c0190704636d01a032469ad59a4321637cfd9ff4c6c2ced99b00600c93a034d6fed91b0740676ccd803006c3d019db00600c01b0720676c01803006c3c819db33600c01b0760676ccd803006c3d819db33600c01b0710676ccd803006c3c419db33600c01b0750676ccd803006c3d419db33600c01b0730676c4d803006c3cc19db1e600c01b0770676c01803006c3dc19db00600c01b0708676c01803006c3c219db60600c01b0748676d81803006f0d9f9a344ed0c00000
codes     : {2490}fffaaaaaaaaaaaaaaaaaaaa8000000003fffffffffe8bd11acb3be28c019e342eb2cef92358655dd180368616d3ba770b610c0193b446aad238633beb2c118431e600c01803206bfdd181300640d7fbc31b600c41adb046acc19b7360676c01803006a0cef9bb6ce3bde580b2069ad21b83206a6d0d98360e08d7fa3300600c0190704636d01a032469ad59a4321637cfd9ff4c6c2ced99b00600c93a034d6fed91b0740676ccd803006c3d019db00600c01b0720676c01803006c3c819db33600c01b0760676ccd803006c3d819db33600c01b0710676ccd803006c3c419db33600c01b0750676ccd803006c3d419db33600c01b0730676c4d803006c3cc19db1e600c01b0770676c01803006c3dc19db00600c01b0708676c01803006c3c219db60600c01b0748676d81803006f0d9f9a344ed0c00000

So with the above payload I expect to obtain the following (ignore the initial part of 01010101 followed by many 0s and many 1s, which is the RADIAN preamble):

D1114DEE14001EA14DEE120DAA17000B68B9B96808007211558918EE4D10083C00000002FD17200002FD0F6C00046D1035303B036E00000005EE769BDC4F4002590907026561068310FD3100000082106C01011259350942EC7EFE19436E6600009201597F1383016E660000C3016E00000083026E000000C3026E66000083036E660000C3036E66000083046E660000C3046E66000083056E660000C3056E66000083066E640000C3066E3C000083076E000000C3076E00000083086E000000C3086E03000083096E0300000FF316910B

that can be verified (on crccalc) to be correct just by computing the CRC-16/KERMIT of everything except the last two bytes, which are the expected CRC in little endian

[gdt]

I think this is awaiting a PR from the original submitter.

[zuckschwerdt]

@bennesp can you test PR #3422?
The aligned code from above for D1114DEE… should start with 45e88d659df1… you need a preamble to sync that way. But that might be difficult as the end of the preamble is all 0xff. It might work with preamble=000001ffffffffff

Test with e.g. rtl_433 -R 0 -X 'name=test,m=OOK_PCM,s=100,l=100,r=300,decode_uart=8n2' -y 45e88d659df1

Should we ignore runs of not-the-start-bit (1 in this case) when running the UART decode? One could then sync on e.g. 0000ffff

[bennesp]

Will do during the next week, thank you