Support Smartwares.eu switches

[uski]

Smartwares.eu manufactures and distributes various RF switches in Europe (example). I am trying to add support but I do not recognize the coding. It is very weird.

Here is what it looks like:

What I see is that the low period is always the same duration (1.27ms). But when it is up, it can be either 1, 2 or 3 periods of the clock.

Zoom with the timing:

Does anyone recognize this coding? Anyone understand how to decode it?

Thanks

[merbanan]

What does rtl_433 -A say? Could be PCM or PPM.

[zuckschwerdt]

Yes PCM or PPM with an underlying n-to-m coding to account for only short runs of zero or one symbols. Though we have seen codings before that are RZ (return to zero). I.e. one symbols are high-low and zero is low-low (with usually the second low very short).

The low period seems to exactly fit 5 "base" periods of 263 µs, i.e. with the preceeding high level it's 3 symbols like this: H-L L-L L-L, right? I'd slice it into 546 µs symbols and then look for groupings.

Can you provide a .ook file? (use e.g. rtl_433 -w file.ook file.cu8) We can then examine a full signal in https://triq.org/pdv/

[uski]

My RTL-SDR is broken and I will receive a new one in a few days. Meanwhile, I captured the signal using another mean, and I have attached the PulseView file. Hope this helps, waiting for my RTL-SDR to be able to use rtl_433 again

smartwares_SH5-TSW-A.zip

[zuckschwerdt]

Converted to OOK smartwares_SH5-TSW-A.txt

[zuckschwerdt]

When PCM slicing and breaking on longer gaps we get pretty consistent results, see this BitBench. Interestingly the gaps align even when the code changes could be a fixed grouping (might be bad reception though).

[uski]

For context:

Reception has been done using a SYN480R-based module connected to a generic USB FT2 logic analyzer (like this). The receiver was pretty close to the transmitter (1-2 feet away). I doubt there is a bad reception, this setup is pretty foolproof.

During the recording period of 5 seconds, I alternatively pressed the 2 buttons of the remote, which is why we see 2 different codes. I believe each code is sent by the remote 8 times, without preamble so the first one is a big mangled until the receiver adjusts its AGC.

What really confuses me is that the groups I see, between fixed-length spaces, are either 1, 2 or 3 pulses.

[zuckschwerdt]

Well if it's just "buttons" then all we get is an ID. We have seen base-3 codes before in "secure" remotes. (Sec+ secplus_v1.c secplus_v2.c)

We have two solid codes:

1000010011100100110011001110011001001110010011001100111001100100111001100110011001100110011001100110011001100110010011100110010011100100 1000010011100100110011001110011001001110010011001100111001100100111001100110011001100110011001100110011001100110011001100110010011100100 with 10000 -> X 11100 -> L 1100 -> M 100 -> S we get XSLSMMLMSLSMMLMSLMMMMMMMMMMMSLMSLS XSLSMMLMSLSMMLMSLMMMMMMMMMMMMMMSLS written as base-3 this is 020112102011210211111111111021020 020112102011210211111111111111020 which gives 4C782428245C2 4C78242824664

But all that is complicated, it might just be a ternary representation (encoder chips offer that to decrease pin-count, i.e. high, low, open) which in 2 bits will just leave one combination unused. E.g. take the symbols as base-4 gives

8592164955555248 8592164955555548 (using 0,1,2) or if you use (1,2,3) it's 1DAE76B9EAAAAA79D 1DAE76B9EAAAAAA9D

The best thing you can do is collect as many different codes as you can get and try to spot a pattern.

The codes look robust, but that's just what the 1-bit OOK module represents the signal as. The RF could be more intricate.

[uski]

Hi,

Good analysis! Thanks.

The receiver uses a very simple ASK/OOK receiver (SYN510R). So I doubt there is anything specific on the RF side. The transmitter uses a 8-pin SOIC microcontroller as its only chip, although its marking has been removed, I strongly suspect it is a custom programmed microcontroller. Same looking IC on the receiver, with what I suspect is a 24C02 I2C EEPROM to store the transmitter codes.

It would be interesting for me to dump the 24C02 EEPROM on the receiver. Maybe we could match some content in the EEPROM to whatever is transmitter on the air, which would help confirm the decoding scheme. I will try to do that with a CH341A reader.

There are 4 buttons on the transmitter, although only 2 are being used. The reason is that the remote I have is just one ON/OFF switch, but they have a model using the same hardware with two ON/OFF switches. PCB is the same, only the outer casing changed. I have captured the entire 4 buttons.

smartwares_sh5-tsw-a_all.zip

The sequence I pressed is :

• ON for the switch that is exposed to the user
• OFF for the switch that is exposed to the user
• ON for the switch that is not normally available to the user
• OFF for the switch that is not normally available to the user

I looked at the dumps and it seems we do have 4 different codes. I wish I had another remote, but unfortunately I have only one. Maybe someone will contribute.

[zuckschwerdt]

Again, converted to OOK: smartwares_sh5-tsw-a_all.txt

The four codes are clean readable, see this BitBench.

All four are different but the same length, the symbols are not likely to be variable length (11100,1100,100) but fixed length. You could try a format of e.g. "6b " in BitBench and then shift to get a minimum number of "symbols".

[uski]

I have read the EEPROM on the receiver paired with the remote mentioned above.

00000000: ff03 0155 aaff ffff ffff ffff ffff ffff  ...U............
00000010: 5060 01ff ffff ffff ffff ffff ffff ffff  P`..............
00000020: 9a96 6a59 5555 5059 ffff ffff ffff ffff  ..jYUUPY........
00000030: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000040: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000050: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000060: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000070: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000080: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000090: ffff ffff ffff ffff ffff ffff ffff ffff  ................
000000a0: ffff ffff ffff ffff ffff ffff ffff ffff  ................
000000b0: ffff ffff ffff ffff ffff ffff ffff ffff  ................
000000c0: ffff ffff ffff ffff ffff ffff ffff ffff  ................
000000d0: ffff ffff ffff ffff ffff ffff ffff ffff  ................
000000e0: ffff ffff ffff ffff ffff ffff ffff ffff  ................
000000f0: ffff ffff ffff ffff ffff ffff ffff ffff  ................

I think the interesting part is 9a96 6a59 5555 5059

In binary: 1001101010010110011010100101100101010101010101010101000001011001

We can see the 010101010... near the same position. 0x55 is 01010101

Maybe it is a coincidence, but maybe not. I have not been able to decode or fully understand the link, but it seems to correspond.

[uski]

About rtl_433 -A:

The sequence I pressed is :

• ON for the switch that is exposed to the user
• OFF for the switch that is exposed to the user
• ON for the switch that is not normally available to the user
• OFF for the switch that is not normally available to the user

ON for the switch that is exposed to the user:

Detected OOK package    2023-01-25 13:36:16
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2023-01-25 13:36:16
model     : Proove-Security                        House Code: 48613376
Channel   : 3            State     : ON            Unit      : 1             Group     : 0
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2023-01-25 13:36:16
model     : Nexa-Security House Code: 48613376
Channel   : 3            State     : ON            Unit      : 1             Group     : 0
Analyzing pulses...
Total count:   66,  width: 70.45 ms     (17613 S)
Pulse width distribution:
 [ 0] count:   66,  width:  300 us [292;316]    (  75 S)
Gap width distribution:
 [ 0] count:    1,  width: 2520 us [2520;2520]  ( 630 S)
 [ 1] count:   32,  width: 1248 us [1244;1256]  ( 312 S)
 [ 2] count:   32,  width:  244 us [240;256]    (  61 S)
Pulse period distribution:
 [ 0] count:    1,  width: 2836 us [2836;2836]  ( 709 S)
 [ 1] count:   32,  width: 1552 us [1540;1560]  ( 388 S)
 [ 2] count:   32,  width:  548 us [540;564]    ( 137 S)
Pulse timing distribution:
 [ 0] count:   98,  width:  284 us [240;316]    (  71 S)
 [ 1] count:    1,  width: 2520 us [2520;2520]  ( 630 S)
 [ 2] count:   32,  width: 1248 us [1244;1256]  ( 312 S)
 [ 3] count:    1,  width: 10004 us [10004;10004]   (2501 S)
Level estimates [high, low]:  15858,    218
RSSI: -0.1 dB SNR: 18.6 dB Noise: -18.8 dB
Frequency offsets [F1, F2]:   -8548,      0 (-32.6 kHz, +0.0 kHz)
Guessing modulation: Pulse Position Modulation with fixed pulse width
view at https://triq.org/pdv/#AAB00B0401011C09D804E027148155+AAB04B0401011C09D804E02714828080828280828082808082808282808082828082808280808280828280808280828082808280828082808280828082808280828082828080828082828080828355
Attempting demodulation... short_width: 244, long_width: 1248, reset_limit: 2524, sync_width: 0
Use a flex decoder with -X 'n=name,m=OOK_PPM,s=244,l=1248,g=1260,r=2524'
pulse_demod_ppm(): Analyzer Device
bitbuffer:: Number of rows: 2 
[00] { 0}                         : 
[01] {64} 9a 96 6a 59 55 55 56 59 

OFF for the switch that is exposed to the user:

Detected OOK package    2023-01-25 13:36:59
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2023-01-25 13:36:59
model     : Proove-Security                        House Code: 48613376
Channel   : 3            State     : OFF           Unit      : 1             Group     : 0
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2023-01-25 13:36:59
model     : Nexa-Security House Code: 48613376
Channel   : 3            State     : OFF           Unit      : 1             Group     : 0
Analyzing pulses...
Total count:   66,  width: 70.43 ms     (17608 S)
Pulse width distribution:
 [ 0] count:   66,  width:  280 us [268;304]    (  70 S)
Gap width distribution:
 [ 0] count:    1,  width: 2536 us [2536;2536]  ( 634 S)
 [ 1] count:   32,  width: 1268 us [1264;1284]  ( 317 S)
 [ 2] count:   32,  width:  264 us [260;276]    (  66 S)
Pulse period distribution:
 [ 0] count:    1,  width: 2840 us [2840;2840]  ( 710 S)
 [ 1] count:   32,  width: 1552 us [1548;1564]  ( 388 S)
 [ 2] count:   32,  width:  548 us [540;560]    ( 137 S)
Pulse timing distribution:
 [ 0] count:   98,  width:  276 us [260;304]    (  69 S)
 [ 1] count:    1,  width: 2536 us [2536;2536]  ( 634 S)
 [ 2] count:   32,  width: 1268 us [1264;1284]  ( 317 S)
 [ 3] count:    1,  width: 10004 us [10004;10004]   (2501 S)
Level estimates [high, low]:  15883,    303
RSSI: -0.1 dB SNR: 17.2 dB Noise: -17.3 dB
Frequency offsets [F1, F2]:  -12021,      0 (-45.9 kHz, +0.0 kHz)
Guessing modulation: Pulse Position Modulation with fixed pulse width
view at https://triq.org/pdv/#AAB00B0401011409E804F427148155+AAB04B0401011409E804F42714828080828280828082808082808282808082828082808280808280828280808280828082808280828082808280828082808280828082808280828082828080828355
Attempting demodulation... short_width: 264, long_width: 1268, reset_limit: 2540, sync_width: 0
Use a flex decoder with -X 'n=name,m=OOK_PPM,s=264,l=1268,g=1288,r=2540'
pulse_demod_ppm(): Analyzer Device
bitbuffer:: Number of rows: 2 
[00] { 0}                         : 
[01] {64} 9a 96 6a 59 55 55 55 59 

ON for the switch that is not normally available to the user:

Detected OOK package    2023-01-25 13:38:47
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2023-01-25 13:38:47
model     : Proove-Security                        House Code: 48613376
Channel   : 3            State     : ON            Unit      : 2             Group     : 0
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2023-01-25 13:38:47
model     : Nexa-Security House Code: 48613376
Channel   : 3            State     : ON            Unit      : 2             Group     : 0
Analyzing pulses...
Total count:   66,  width: 70.42 ms     (17606 S)
Pulse width distribution:
 [ 0] count:   66,  width:  280 us [276;304]    (  70 S)
Gap width distribution:
 [ 0] count:    1,  width: 2532 us [2532;2532]  ( 633 S)
 [ 1] count:   32,  width: 1268 us [1260;1276]  ( 317 S)
 [ 2] count:   32,  width:  264 us [256;276]    (  66 S)
Pulse period distribution:
 [ 0] count:    1,  width: 2836 us [2836;2836]  ( 709 S)
 [ 1] count:   32,  width: 1552 us [1544;1560]  ( 388 S)
 [ 2] count:   32,  width:  548 us [536;560]    ( 137 S)
Pulse timing distribution:
 [ 0] count:   98,  width:  276 us [256;304]    (  69 S)
 [ 1] count:    1,  width: 2532 us [2532;2532]  ( 633 S)
 [ 2] count:   32,  width: 1268 us [1260;1276]  ( 317 S)
 [ 3] count:    1,  width: 10004 us [10004;10004]   (2501 S)
Level estimates [high, low]:  15994,      8
RSSI: -0.1 dB SNR: 33.0 dB Noise: -33.1 dB
Frequency offsets [F1, F2]:   -8127,      0 (-31.0 kHz, +0.0 kHz)
Guessing modulation: Pulse Position Modulation with fixed pulse width
view at https://triq.org/pdv/#AAB00B0401011409E404F427148155+AAB04B0401011409E404F42714828080828280828082808082808282808082828082808280808280828280808280828082808280828082808280828082808280828082828080828082808282808355
Attempting demodulation... short_width: 264, long_width: 1268, reset_limit: 2536, sync_width: 0
Use a flex decoder with -X 'n=name,m=OOK_PPM,s=264,l=1268,g=1280,r=2536'
pulse_demod_ppm(): Analyzer Device
bitbuffer:: Number of rows: 2 
[00] { 0}                         : 
[01] {64} 9a 96 6a 59 55 55 56 56 

OFF for the switch that is not normally available to the user:

Detected OOK package    2023-01-25 13:39:23
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2023-01-25 13:39:23
model     : Proove-Security                        House Code: 48613376
Channel   : 3            State     : OFF           Unit      : 2             Group     : 0
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2023-01-25 13:39:23
model     : Nexa-Security House Code: 48613376
Channel   : 3            State     : OFF           Unit      : 2             Group     : 0
Analyzing pulses...
Total count:   66,  width: 70.48 ms     (17619 S)
Pulse width distribution:
 [ 0] count:   66,  width:  296 us [288;344]    (  74 S)
Gap width distribution:
 [ 0] count:    1,  width: 2528 us [2528;2528]  ( 632 S)
 [ 1] count:   32,  width: 1256 us [1248;1268]  ( 314 S)
 [ 2] count:   32,  width:  248 us [244;268]    (  62 S)
Pulse period distribution:
 [ 0] count:    1,  width: 2872 us [2872;2872]  ( 718 S)
 [ 1] count:   32,  width: 1552 us [1544;1560]  ( 388 S)
 [ 2] count:   32,  width:  548 us [540;560]    ( 137 S)
Pulse timing distribution:
 [ 0] count:   98,  width:  280 us [244;344]    (  70 S)
 [ 1] count:    1,  width: 2528 us [2528;2528]  ( 632 S)
 [ 2] count:   32,  width: 1256 us [1248;1268]  ( 314 S)
 [ 3] count:    1,  width: 10004 us [10004;10004]   (2501 S)
Level estimates [high, low]:  15937,    119
RSSI: -0.1 dB SNR: 21.3 dB Noise: -21.4 dB
Frequency offsets [F1, F2]:  -10021,      0 (-38.2 kHz, +0.0 kHz)
Guessing modulation: Pulse Position Modulation with fixed pulse width
view at https://triq.org/pdv/#AAB00B0401011809E004E827148155+AAB04B0401011809E004E82714828080828280828082808082808282808082828082808280808280828280808280828082808280828082808280828082808280828082808280828082808282808355
Attempting demodulation... short_width: 248, long_width: 1256, reset_limit: 2532, sync_width: 0
Use a flex decoder with -X 'n=name,m=OOK_PPM,s=248,l=1256,g=1272,r=2532'
pulse_demod_ppm(): Analyzer Device
bitbuffer:: Number of rows: 2 
[00] { 0}                         : 
[01] {64} 9a 96 6a 59 55 55 55 56 

[uski]

Looking at the source code of the "Proove" decoder, it seems to be the same protocol. Particularly, the proove.c file states that the decoder has been tested with Smartwares SH4-90152 which is compatible with my receiver. There is an Amazon listing with SH4-90150 which is a 2-channels remote and the SH4-90152 is the 4 channel remote so pretty certain it is the same protocol.

So I think we have found what the protocol is!

[uski]

The problem I am having is that while this proove.c decoder seems to work, the description of the physical layer does not match what I see (unless I am mistaken). Anyone knows why? Is it possible that it decodes seemingly reliably, but by accident?

The proove.c file says:

Physical layer:
Every bit in the packets structure is sent as two physical bits.
Where the second bit is the inverse of the first, i.e. 0 -> 01 and 1 -> 10.
Example: 10101110 is sent as 1001100110101001
The sent packet length is thus 64 bits.
A message is made up by a Sync bit followed by the Packet bits and ended by a Pause bit.
Every message is repeated about 5-15 times.
Packet gap is 10 ms.

But clearly, it does not correspond to what we have, as this description does not allow getting codes we are getting. It seems to me that this decodes by a happy accident, but it is not the actual protocol.

Attaching .cu8 and .ook file as received by rtl_433 for code "ON for the switch that is exposed to the user" (two different runs, but same code)

on_e.zip

[merbanan]

My guess is that we have 2 transmission symbols and a pre and post-amble.

0: HHLL 1: HLLH

The total symbol length is ca 2ms. With the H pulses being ca 270us long each.

When looking at the signal sample this symbol distribution works well. To decode this we need to use the pcm decoder so that we get a bit buffer in the H/L form (and hopefully the symbol transmission is well timed). Then we need to sync the bitstream som that each symbol starts on a nibble boundary. After that we should just get 2 different values that we can map to ones and zeroes and finally get our signal message.

The proove decoder is very forgiving so it is unrelated.

[zuckschwerdt]

Nah, the Proove/Nexa description is spot on. It's boring PPM (270/1300) after all. Looking at the symbols after the PPM decode we only ever get 01 or 10. That effects the 1,2,3 grouping we see. Here are the codes, grabbed as PPM in a BitBench showing that. Use bx to skip every second bit, and you get the true payload as see in this BitBench. Since Nexa is that format but with slightly different interpretation I guess that could be happening here too.

[merbanan]

Makes sense. Didn't think about PPM.

[zuckschwerdt]

Worse: I didn't recognize the 1,2,3 groups which I've clearly seen in Proove/Nexa/Kaku before…

And the protocol might not be true PPM. The symbols in PCM are very neatly 10000010 (0x82) and 10100000 (0xa0) -- but for decoding it's robust this way :)

There is one new trick in the flex decoder:

 -X 'n=name,m=OOK_PCM,s=260,l=260,g=1500,r=9000,symbol_zero={8}82,symbol_one={8}a0'

will directly decode those symbols from PCM :)

[uski]

That flex decoder sounds awesome. But the line above unfortunately is not robust. Sometimes it works, most of the time if doesn't.

Here is an example output:

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2023-01-26 05:35:37
model     : name         count     : 2             num_rows  : 2             rows      : 
len       : 0            data      : , 
len       : 32           data      : 468dfffd
codes     : {0}, {32}468dfffd
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2023-01-26 05:35:37
model     : name         count     : 2             num_rows  : 2             rows      : 
len       : 0            data      : , 
len       : 32           data      : 468dfffd
codes     : {0}, {32}468dfffd
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2023-01-26 05:35:37
model     : name         count     : 2             num_rows  : 2             rows      : 
len       : 0            data      : , 
len       : 0            data      : 
codes     : {0}, {0}
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2023-01-26 05:35:37
model     : name         count     : 2             num_rows  : 2             rows      : 
len       : 0            data      : , 
len       : 0            data      : 
codes     : {0}, {0}
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2023-01-26 05:35:37
model     : name         count     : 2             num_rows  : 2             rows      : 
len       : 0            data      : , 
len       : 0            data      : 
codes     : {0}, {0}
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2023-01-26 05:35:37
model     : name         count     : 2             num_rows  : 2             rows      : 
len       : 0            data      : , 
len       : 0            data      : 
codes     : {0}, {0}
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2023-01-26 05:35:37
model     : name         count     : 2             num_rows  : 2             rows      : 
len       : 0            data      : , 
len       : 0            data      : 
codes     : {0}, {0}
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2023-01-26 05:35:37
model     : name         count     : 2             num_rows  : 2             rows      : 
len       : 0            data      : , 
len       : 32           data      : 468dfffd
codes     : {0}, {32}468dfffd

There are a bunch of spurious "zero" decodes. Most of the time, I only get these, sometimes, I get the decoded signal (468dfffd)

[merbanan]

Each signal has 8 repeats. In this case the first 2 was successfully handled.

[gdt]

@uski Where are we on this? What has to happen to add support and close?

[gdt]

@uski Have you abandoned this?