ADD: rolling code transmitter decoder #1339
Conversation
…he 'fixing' of the fixed bits figured out.
Replaced prev_1_a_raw with rev_1_a_corrected so we don't have to re-correct it. Moved model to the front of the data.
| // This holds previous start width 1 fixed and rolling codes for | ||
| // counter decoding once we have a start width 3 packet. | ||
| static uint8_t prev_1_a_corrected[RAW_SIZE] = {NOT_SET}; | ||
| static uint8_t prev_1_r_raw[RAW_SIZE] = {NOT_SET}; |
There was a problem hiding this comment.
Decoders usually doesn't hold any state. And I don't understand the bit stream enough to say if it really is needed. Can you add some signal samples to the tests repository?
There was a problem hiding this comment.
To garner any useful data from the transmission it is unfortunately necessary to retain a small amount of state. I'd hoped that all of the data bursts could be captured in a single bitbuffer with several rows, but the delay between bursts runs afoul of the limits set forth in pulse_decode.c. Christian and I discussed this briefly in email - here's why, without changes in pulse_decode and other files, that state is needed:
- AFAIK RTL_433 ... can't handle trinary. That means I have to use the OOK_PCM_RZ format with the short and long widths set to 500 uS (the smallest common value). This is not a big deal, except for how to install? #2 and Different temp sensor: LaCrosse / TFA IT+ on 868Mhz #3.
- When I attempt to grab the data, the 60 mS gap between the packets triggers the End-Of-Packet processing on lines 349-ish in pulse_decode.c. It seems that I cannot ever get the packets either on one row or on their own row!
- Even if we fix how to install? #2, OOK_PCM_RZ code doesn't support the gap_limit, so I would get all of the values on a single row.
Note that I did provide for debugging output - if you use -vvvv, you get output that has the raw values in each of the packets received.
I will gladly provide sample data files once my new transmitters arrive tomorrow. I'm not inclined to post files with my actual data in them.
Below are examples of the trinary nature of the data and an example of the 60 mS gap between the '3' start-bit-width packet and the '1' start-bit-width packet.
There was a problem hiding this comment.
Ok, lets call for help. @zuckschwerdt I looked at the pulse_demod_pcm() code and it seemed feasible to add gap_limit support. Do you concur?
Somewhere around this line:
periods = MIN(periods, max_zeros);
there could be some logic to add rows.
There was a problem hiding this comment.
I didn't even realize that the PCM slicer is the problem here. Sure, I wanted to add that anyway.
There was a problem hiding this comment.
@zuckschwerdt in pulse_detect:371 this condition seems strange:
if (((s->pulse_length > (PD_MAX_GAP_RATIO * s->max_pulse)) // gap/pulse ratio exceeded
&& (s->pulse_length > (PD_MIN_GAP_MS * samples_per_ms))) // Minimum gap exceeded
|| (s->pulse_length > (PD_MAX_GAP_MS * samples_per_ms))) { // maximum gap exceeded
I think this also will hinder the merging of signals with long gaps. And raising the reset limit to >60ms will reduce the time resolution with regards to different signals. I am not sure what it is now but I think it is like 20ms.
It would be nice to know these metrics. For example FSK devices doesn't have this property but are still affected by it.
As always I'm not totally sure what to do :) it is becoming difficult to decode all signals.
There was a problem hiding this comment.
It's: below 10ms will never EOP above 100ms will always EOP, between that at longest pulse x10 will EOP. That way we currently can't have gaps longer than "longest pulse x 10" (if that's above 10ms). That's for the AM envelope, thus FM isn't limited by this?
src/devices/rolling_code.c
Outdated
| .modulation = OOK_PULSE_PCM_RZ, | ||
| .short_width = 500, // trits are multiples of 500 uS in size | ||
| .long_width = 500, // trits are multiples of 500 uS in size | ||
| .reset_limit = 2000, // this is short enough so we only get 1 row |
There was a problem hiding this comment.
- If this limit is high enough. Both a 1 and a 3 packet might be present in the message. Then a state should not be needed.
There was a problem hiding this comment.
|
Christian and Benjamin,
Thanks for the replies!
The PCM slicer gap support is only part of the issue.
This particular transmitter has very long delays between the two packet types - 60 mS or so. That also triggers the pulse/gap ratio check (PD_MAX_GAP_RATIO)in pulse_detect.c around line 371.
I will be uploading samples to my google drive shortly.
BTW, I have another completed decoder for Regency ceiling fan remotes and another one I've been looking at that's kicking my butt. I talked to Christian about it a bit - it's probably encrypted, but there are tantalizing patterns in the data. Benjamin, you might like to take a swipe at this one!
73
… On Mar 23, 2020, at 6:36 PM, Christian W. Zuckschwerdt ***@***.***> wrote:
@zuckschwerdt commented on this pull request.
In src/devices/rolling_code.c <#1339 (comment)>:
> + rotate_mirror_add(&counter, &mirror, 1);
+ rotate_mirror_add(&counter, &mirror, 3);
+ rotate_mirror_add(&counter, &mirror, 1);
+ rotate_mirror_add(&counter, &mirror, 1);
+
+ mirror_counter(&counter, &mirror);
+
+ return mirror;
+}
+
+static int rolling_code_decode(r_device *decoder, bitbuffer_t *bitbuffer)
+{
+ // This holds previous start width 1 fixed and rolling codes for
+ // counter decoding once we have a start width 3 packet.
+ static uint8_t prev_1_a_corrected[RAW_SIZE] = {NOT_SET};
+ static uint8_t prev_1_r_raw[RAW_SIZE] = {NOT_SET};
I didn't even realize that the PCM slicer is the problem here. Sure, I wanted to add that anyway.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#1339 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA5OEG3KAJLIDVGPDGELC33RI7P5TANCNFSM4LR723JA>.
|
|
Gentlemen,
Here are anonymous files from a new replacement transmitter that I just received from Amazon. The files are from the one I designated device_A, and each button was pressed several times. Button C was a little wonky, but they all decode properly.
FILES ARE HERE: https://drive.google.com/open?id=1KTHG9x5-pgaimcJHuDkwpm6xmihlDLNq
Example: device_A/button_a/g002_315M_250k.cu8 (it apparently starts at 6, and they all seem to increment by either 2 or 4):
./rtl_433 -R 151 -r new_remotes/device_A/button_a/g002_315M_250k.cu8
...
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : @0.201720s
model : Rolling Code Transmitter counter : 6 counter_hex: 00000006
button_pressed: 1 id_bits : 13 device_id : 38918274 device_id_hex: 0251d882
next press:
./rtl_433 -R 151 -r new_remotes/device_A/button_a/g003_315M_250k.cu8
...
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : @0.201728s
model : Rolling Code Transmitter counter : 8 counter_hex: 00000008
button_pressed: 1 id_bits : 13 device_id : 38918274 device_id_hex: 0251d882
… On Mar 23, 2020, at 6:36 PM, Christian W. Zuckschwerdt ***@***.***> wrote:
@zuckschwerdt commented on this pull request.
In src/devices/rolling_code.c <#1339 (comment)>:
> + rotate_mirror_add(&counter, &mirror, 1);
+ rotate_mirror_add(&counter, &mirror, 3);
+ rotate_mirror_add(&counter, &mirror, 1);
+ rotate_mirror_add(&counter, &mirror, 1);
+
+ mirror_counter(&counter, &mirror);
+
+ return mirror;
+}
+
+static int rolling_code_decode(r_device *decoder, bitbuffer_t *bitbuffer)
+{
+ // This holds previous start width 1 fixed and rolling codes for
+ // counter decoding once we have a start width 3 packet.
+ static uint8_t prev_1_a_corrected[RAW_SIZE] = {NOT_SET};
+ static uint8_t prev_1_r_raw[RAW_SIZE] = {NOT_SET};
I didn't even realize that the PCM slicer is the problem here. Sure, I wanted to add that anyway.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#1339 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA5OEG3KAJLIDVGPDGELC33RI7P5TANCNFSM4LR723JA>.
|
|
@dtiller there seems to be 2 signals in the files. Is one device sending something and another answering? |
|
Benjamin,
There is only 1 transmitter involved.
It sends a packet with a '1 length' (500uS) start bit and the first 20 trits of the fixed code and the first 20 trits of the rolling code, interleaved (R1, F1, R2, F2, etc). It then waits 60mS and sends the second 20 trits of the fixed code and the second 20 trits of the rolling code in the next packet that starts with a '3 length' (1500uS) start bit. These pairs are repeated identically a few times for each keypress. In order to recreate the data, both packets (all 40 trits of the fixed code and all 40 trits of the rolling code) need to be present.
… On Mar 24, 2020, at 5:43 AM, Benjamin Larsson ***@***.***> wrote:
@dtiller <https://github.com/dtiller> there seems to be 2 signals in the files. Is one device sending something and another answering?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#1339 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA5OEGYSMQ22VMWIC4HHPBDRJB6FXANCNFSM4LR723JA>.
|
|
Christian,
I'm not sure if this question was directed at me - if not, I apologize.
The longest pulses overall are the '3-length' start bit and the 'on' portion of the '2' symbol at 1500uS. Recall that due to the trinary nature of the data I am using the PCM decoder, so the bits are mapped directly to 500uS pulses, not any sort of PWM/PPM. The longest run of consecutive '1' bits (not trits) should be 3 for the 3-length start bit or the on portion of '2' trit. (ex: a '0' symbol shows up in the bitbuffer as 0001, a 1 as 0011, and a 2 as 0111).
If I understand your assertion, then this signal's ratio (1500uS x 10 = 15 mS) falls into the 'window of despair' between 10mS and 100mS. The gap between packets that I need in the same bitbuffer is 60 mS.
… On Mar 24, 2020, at 6:54 AM, Christian W. Zuckschwerdt ***@***.***> wrote:
@zuckschwerdt commented on this pull request.
In src/devices/rolling_code.c <#1339 (comment)>:
> + rotate_mirror_add(&counter, &mirror, 1);
+ rotate_mirror_add(&counter, &mirror, 3);
+ rotate_mirror_add(&counter, &mirror, 1);
+ rotate_mirror_add(&counter, &mirror, 1);
+
+ mirror_counter(&counter, &mirror);
+
+ return mirror;
+}
+
+static int rolling_code_decode(r_device *decoder, bitbuffer_t *bitbuffer)
+{
+ // This holds previous start width 1 fixed and rolling codes for
+ // counter decoding once we have a start width 3 packet.
+ static uint8_t prev_1_a_corrected[RAW_SIZE] = {NOT_SET};
+ static uint8_t prev_1_r_raw[RAW_SIZE] = {NOT_SET};
It's: below 10ms will never EOP above 100ms will always EOP, between that at longest pulse x10 will EOP. That way we currently can't have gaps longer than "longest pulse x 10" (if that's above 10ms). That's for the AM envelope, thus FM isn't limited by this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#1339 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA5OEG3HEOZDZRNTRFFKJNTRJCGOJANCNFSM4LR723JA>.
|
|
I.e. we'd need a ratio of at least x40. I guess we can somewhat safely raise that x10 ratio if we add gap limit support to the PCM slicer. I will test that in the next days. |
…g. This packet can't be confused with any other.
|
this sounds a lot like the Security+ rolling code protocol ( secplus_v2.c & secplus_v1.c, pull req #1483 & #1480 ) that was based on @argilo 's secplus same spit packets delay, both trinary data with the same 1.5ms / 0.5ms encoding timing |
|
Please split Security+ discussion into a separate issue, this PR is for general rolling code additions. |
|
Closing pull request. This decoder hasn't been accepted for many months and seems to be similar to Security+. Apparently the author of Security+ was able to get retained state approved in their decoder where I could not. |
@zuckschwerdt did this get implemented? Or should we just merge as is? I think we will loose time resolution if we increase the reset limit. And while I really don't like keeping state I don't see anyway to do without it. |
|
@dtiller the decoder is neither rejected or accepted, it is just stuck in limbo until I or someone else gets time to look at it. I was planning a PR/issues marathon but real life got in the way. |
|
I'll look into this again shortly. Sorry this dropped off my radar. I plan to rework state support with other things like per-decoder verbosity and logging and such. But yeah, if it works, merge and apply cleanup when time allows. |
|
I tried my transmitter against the security+ decoder and it _seemed_ to decode it properly, although one of us seems to have slightly different math. I’m not sure the security decoder works for all of the modes this one does, however.
Do you want me to investigate this further? I’d hate to have you guys merge my decoder when it’ll probably collide with security+ decodes.
… On Jan 21, 2022, at 14:07, Christian W. Zuckschwerdt ***@***.***> wrote:
I'll look into this again shortly. Sorry this dropped off my radar. I plan to rework state support with other things like per-decoder verbosity and logging and such. But yeah, if it works, merge and apply cleanup when time allows.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you were mentioned.
|
|
That would be great. Always happy to see decoders get more mature and support quirks the original author had no hardware to find. |
This decoder handles common rolling code transmissions. It extracts the corrected 'fixed' and 'rolling' portions of the transmission as well as the id bits and the button pressed.