New device for ASK?

[gcormier]

So I have a simple garage door opener I've got data for. It's basic, non rolling. ASK, 310MHz, 200MS on pulse, 50ms off pulse.

The question is less about the device itself, more about what you would prefer.. I figure there's maybe infinite devices like this. Some garage doors might have 10 bits.

I can submit a PR to the test repo with the information, but perhaps there's a different way you'd prefer to proceed... I guess I'm asking, is this too "basic" of a device to submit?

[zuckschwerdt]

Best way is to write a flex decoder spec. I'll merge the config file support shortly now and then you can have all those random devices neatly in a config file. (and publish them to our project please!). See e.g. https://github.com/zuckschwerdt/rtl_433/blob/feat-conf/rtl_433.example.conf#L266 ff. for examples.

[gcormier]

Each bit occupies 4200uSec.

A one is 2000uS high, 2200uS low. A zero is 500uS high, 3700uS low.

Using -A, the final line outputs the correct binary string.

I'm a bit stuck on -X.

The output indicates OOK_PWM_RAW, but that's invalid. There is OOK_PIWM_RAW, but I didn't have great success.

The output also outputs pulse_demod_pwm() then the correct values. So should I focus on OOK_PWM, or OOK_PIWM_RAW?

Detected OOK package    @ @7.864320s
Analyzing pulses...
Total count:    8,  width: 31.39 ms     ( 7848 S)
Pulse width distribution:
 [ 0] count:    5,  width:  528 us [524;540]    ( 132 S)
 [ 1] count:    3,  width: 2088 us [2084;2092]  ( 522 S)
Gap width distribution:
 [ 0] count:    5,  width: 3660 us [3652;3668]  ( 915 S)
 [ 1] count:    2,  width: 2088 us [2088;2088]  ( 522 S)
Pulse period distribution:
 [ 0] count:    7,  width: 4184 us [4172;4204]  (1046 S)
Level estimates [high, low]:   1724,     66
RSSI: -9.8 dB SNR: 14.1 dB Noise: -23.9 dB
Frequency offsets [F1, F2]:   13676,      0 (+52.2 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with fixed period
Attempting demodulation... short_limit: 1308, long_limit: 3672, reset_limit: 3672, sync_width: 0
Use a flex decoder with -X name:OOK_PWM_RAW:1308:3672:3672
pulse_demod_pwm(): Analyzer Device
bitbuffer:: Number of rows: 1 
[00] { 8} ae        : 10101110 

[zuckschwerdt]

Oops. OOK_PWM_RAW is the old demod where "short" is halfway between short and long pulses. Confusing to handle. The new OOK_PWM needs short and long as you have them. So this should work:

-X garage:OOK_PWM:528:2088:5000:4000

• 4000 here means "if there is more than 4ms gap begin a new row"
• 5000 here means "if there is more than 5ms gap end the buffer"

[gcormier]

Bingo!

Test mode active. Reading samples from file: garage-door.cu8 Input format: CU8 IQ (2ch uint8) @7.864320s : garage : 1 : 1 : [ : 8 : ae] : [{8}ae]

It would be nice to have an option in Flex to format the output. For this one, since it's a garage door opener that has 8 DIP switches to configure, I would suggest just the binary output, as in the pulse_demod_pwm() debug output. Others might prefer hex or decimal output.

I'll submit a PR, any thoughts to structures for all these config files? Will we be able to include multiple FLEX configs? Or should we pile into one config for now?

[zuckschwerdt]

I have updated the flex suggestions in the pulse analyzer now. Thanks for the hint ;)

The flex spec is thought to be easily adaptable for your specific setup. I see you have the code 0xae configured (DIPs: 10101110), say you also have 0x42, then:

decoder opener:OOK_PWM:528:2088:5000:4000,bits=8,get={8}:event:[174:garager 66:pool-cover]

[gcormier]

Okay. It would be neat to have the binary output instead of hex. Also, to me the output is not quite clear. Perhaps explanation could be put somewhere?

eg. @7.864320s : garage : 1 : 1 : [ : 8 : ae] : [{8}ae]

What do the two 1's refer to?

Sidenote/hijack.. thoughts on the LimeSDR Mini? It's quite a bit cheaper then the HackRF One. Has it matured enough now and is fairly supported for doing these kind of things? Would be great to get into transmitting as well (over the RTLSDR).

[zuckschwerdt]

The default KV output isn't too useful, try JSON (-F json) if possible.

Binary formatting is just to verbose for the outputs. You can get it with the printf-style debug functions. If you need it from the regular outputs (log or database mostly I guess) then use a convert script.

I do like the LimeSDR and it's supported by rtl_433. Can't do any real world tests though since my devices are pre-production samples with some odd quirks.