decoder optimizing : minimum bits count filtering

[evilpete]

Any interest in adding a minimum bits (& max) count into the decoder initial r_device structure declaration , is will allow for optimizing reducing unnecessary function calls to to protocol decoders. this can be implemented with a command line to disable the feature,

[zuckschwerdt]

We have been playing around with the idea to add some declarative checks to the decoders. It can be complicated by the need to describe how multiple rows look like (i.e. do we need all rows with minbits or just one?) The flex decoder will benefit the most from such options, and the decoders can be leaner. The reduced proccessing is on top ;)

[evilpete]

I'll take a swipe at it, i figure if does not have to be perfect. if 30% of the decoder calls get dropped it is a win.

as for complex / multiple rows protocols, they can have their min packet length set to 0 and get not filtered.

I am currently reading though the code trying to fine the best place to put it. the first pass will filter demodulated data when there is a bit count, later we can experiment with filtering based on sample size and bit rate although that can be tricky when 1's and 0's have different timings

I am not making on promises but I will give a casual effort until i get distracted by something else new and shiny

[zuckschwerdt]

To actually know what rows a protocol would see we'd need to slice the bits first. Then in https://github.com/merbanan/rtl_433/blob/master/src/pulse_demod.c#L23 you could apply per-protocol filters before calling the decoder. But that would not could down on processing really. It just moves the sanity check from the decoder to the call of the decoder. I would see this more as cleaning up decoders / putting more structure into decoders. We do have a statistics feature (-M stats) that should keep account of decoder calls vs successful decodes. Do you see significant overhead there?

[zuckschwerdt]

You are right for FSK the detection is twitchy, an early check for minbits could short-circuit the slicers. E.g. for PWM/PPM compare the pulse count, for PCM maybe check the overall length against long * minbits, but leave a little room for unprecise timings. Also I'll likely take a stab at adding a preamble match to cut down the boilerplate in e.g. TPMS. I.e. move this over to the slicers: https://github.com/merbanan/rtl_433/blob/master/src/devices/tpms_citroen.c#L102