rtl_433

rtl_433 copied to clipboard

Support for Security+ 2.0 was originally added by @evilpete in #1480, based on my code in https://github.com/argilo/secplus. Since that time, I have learned more about the packet format:

1. While the off-brand transmitter I originally tested with transmits its packets in rapid succession, genuine transmitters space them 100ms apart, much like the older Security+ protocol. Because the data is split across two packets with a large time gap in between, it seems that rtl_433 cannot provide the required data in the rows of a single bitbuffer, regardless of the reset_limit value. As a result, I've adopted the caching approach used in the Security+ receiver (#1483). (If there's a better approach, please let me know.)
2. PIN pads transmit using a longer 64-bit packet format, which has "01" for the frame type bit, and includes a 32-bit "supplemental data" field.
3. The "button ID" field is 4 bits long, not 8.

I recently updated https://github.com/argilo/secplus to support Security+ 2.0 PIN pads, and I also added a unit-tested C implementation (https://github.com/argilo/secplus/tree/master/src). I've copied in the functions needed to decode Security+ 2.0 packets.

After these changes, the code is able to receive genuine and off-brand remotes, as well as PIN pads.

While the off-brand transmitter I originally tested with transmits its packets in rapid succession, genuine transmitters space them 100ms apart,

i had this problem wen I started working with "real" hardware also. I ended up using a local patch that cached part one

I rebased and resolved merge conflicts.

Thanks! This needs some deliberation as we don't want decoders to be stateful (and here also time dependent). Statefulness is sometimes requested (and needed really), along with e.g. AES routines and such complex processing.

We need to keep core rtl_433 focused on pulling bits of the air reliable and somehow add/enable robust post-processing -- it's not clear how we can best do that, but it shouldn't be done in decoders.

Sounds good. I'll be happy to revisit this once some facility for post-processing is available.

Statefulness is sometimes requested (and needed really), along with e.g. AES routines and such complex processing.

If I understand this format correctly we need to keep state somehow anything else will just not work. And there are other formats that needs this also.

I suggest we add sf (state full) as a command line parameter to also enable state full decoders. In r_device we add a .state context and a state_size. Then we can allocate the state context on decoder init. It might be good to also output this fact in the decoded output. Ie I would like the decoder output to emit a state tracker to indicate if we have enough previous data to output complete data. That way we output data as close to the low level rf signal and a consumer can choose to only process data when data is suitable.

We also have to make sure that we can do a complete playback of recorded signals. But I think that can work via the wildcard handling.

If I understand this format correctly we need to keep state somehow anything else will just not work.

As far as I understand, yes.

The information in this protocol (and also the original Security+ protocol) is distributed across two packets that are transmitted 100ms apart. Neither of the packets can be usefully decoded without having the other, because the data fields are split between the packets and bits from one packet are used to scramble the other. The time gap between the packets seems to be too large to capture them in "rows."

On Sat, Sep 16, 2023 at 1:41 PM Benjamin Larsson @.***> wrote:

Statefulness is sometimes requested (and needed really), along with e.g. AES routines and such complex processing.

If I understand this format correctly we need to keep state somehow anything else will just not work. And there are other formats that needs this also.

Yes the packet timing does not work with rtl_433, playing with openers I have also found a lot of variation in two part packet spacing.

I have also read, but been unable to verify personally, many openers require the spacing

Message ID: @.***>

This seems to be still live, still sort of blocked by the stateful big picture, and it needs a rebase (not a big deal).