Silent Gliss SG11490 blinds remote decode help

[hamchapman]

I've got an electric blinds remote that I'm trying to decode and I'm struggling to work out how to make progress.

Some links about the remote:

• https://www.sg-s.co.uk/spares-parts/electrical-curtain-track-system-parts/5600-system-parts/11490?srsltid=AfmBOopMpzI4QPV2duq-pkS7fTJx6W-xJeDVfEFnO7E0nQz_4kt-Z3mq&dsort=sort_order
• https://www.discountelectriccurtains.co.uk/accessories/5-channel-wireless-wall-switch-11490/?srsltid=AfmBOor6ifFjxo5H4jX31uemS4POdMaD2S4ITrwGdznX0UmyBXGqiDyZ

A PDF with some info:

I've captured some samples of pressing some different buttons and attached them as sg-samples.zip:

sg-samples.zip

I captured them using the following command:

rtl_433 -f 868M -S unknown

Hopefully the filenames explain what each sample is but the summary is that there are 5 different types of sample, with 3 instances of each. The different "types" are:

• Channel 1, pressing up button
• Channel 1, pressing down button
• Channel 2, pressing up button
• Channel 2, pressing down button
• Channel 1, pressing stop button

Please let me know if you can suggest some ways for me to progress with getting to a decoder 🙏

[zuckschwerdt]

It seems there is much noise and little of a sine waveform to clearly see the FSK. (try https://triq.org/spectrogram-next/ to load a cu8 and mouse-scroll zoom in to see no real sine waves.)

Try a higher sample rate (-s 2048k ?) and different placement or antenna and such. The first 20 or so bits in the decoding on https://triq.org/pdv/ should be a regular pattern like 101010101…

[hamchapman]

Thanks for the suggestions. I've tried using a higher sample rate but things look pretty much the same, same with different placement.

I'm using an RTL-SDR v4 with this antenna. Should that work as a combination to be able to get a good read on the signals? Any suggestions for other things I could try if not? Thanks!

[zuckschwerdt]

It should work. Maybe try without an antenna and 20cm – 1m distance? You can compare with some FSK signals in https://github.com/merbanan/rtl_433_tests to get a feeling what you are looking for.

[hamchapman]

I played around with the sample rate and some other flags and ran this:

rtl_433 -f 868.3M -s 2048k -g 28 -A -S all

and got what looks like a better signal capture.

Here's a zip of the capture: g003_868.3M_2048k.cu8.zip

Am I right and that is a better capture? Should it be even better to try and work with it?

If it is good enough, how should I go about trying to decode things? I loaded it up in urh but couldn't ever get it to detect what was going on.

These are the settings I was using to try and get sense out of it, but whenever I tried to Autodetect Parameters I'd get an error.

[hamchapman]

And here's what I hope is an even cleaner capture:

g014_868.3M_2048k.cu8.zip

I still can't seem to make any sense of it using urh though.

Has anyone got any ideas as to steps I could take to help decode this? Thanks!

[zuckschwerdt]

The signal is better but still awefully noisy. Visibly there is quite the aliasing and if you zoom in you can't make out a decent carrier sine.

Load your sample in https://triq.org/pdv3/ and compare to e.g. https://github.com/merbanan/rtl_433_tests/blob/master/tests/bresser_6in1/01/g002_868.3M_1000k.cu8

There should be (FSK) two pronounced carrier lines, maybe some weak aliasing but not massive like in your screenshot.

Click the spectrogram then mouse-scroll zoom in, the waveform display should show something vaguely like sines (two, fast and slow for FSK).

Do you get any other clean signals to rule out a broken setup (antenna or such)? If the sender is really the problem then you could try to tune close to the signal (-f 868.5M) and use a narrow filter (-Y filter 50000).

[hamchapman]

Do you get any other clean signals to rule out a broken setup (antenna or such)?

I've not got anything else "known" that I could try, if you know what I mean. Is there anything else common (other remotes?) that I could try to see if the setup is bad? I've got a Somfy Situo 5 RTS Pure II that I could try with tomorrow, although it looks like that operates at 433.42MHz.

I'm happy to throw a bit of money at this as it's a fun project so if you have any recommendations for stuff to buy to try and get a better signal then I'm all ears.

I tried to get a couple more signals using closer tuning and a narrow filter, which are shown below:

Tried with -f 868.5M:

g007_868.5M_2048k.cu8.zip

Tried with -f 869M:

g005_869M_2048k.cu8.zip

Neither seem like the example one you shared so I guess something's still not quite right.

[zuckschwerdt]

Both look better. g007 above mostly looks like a proper FSK signal, you can nearly read the data by eye. The filter is only used in the rtl_433 decoding and not visible here. Maybe I should add a filter option to PDV.

If you could get any FSK sender, preferably 868M, to compare that would be best. Maybe some (868M FSK) keyfob or a (868M FSK) temperature sensor.

Since the blinds come in 868M and 915M, maybe the antenna is not tuned or tuned to 915M and this noise is the result? Not sure. I'll try to visualize the filter option to see if we can reliably clean up a signal that way.

[hamchapman]

I've ordered a keyfob that should help me test at 868MHz.

In the meantime I've tested with that 434MHz Somfy remote I mentioned above and got this capture from it, which looks very clean (to my eyes at least!):

g006_433.4M_250k.cu8.zip

and zoomed in on parts of it:

Does that imply anything about my setup or the remote I'm actually trying to capture signals from (at 868MHz)?

[zuckschwerdt]

Looks good. The aliasing is just the signal being very strong (clipping, the yellow-orange-red parts in the waveform). Try to get more distance between sender and SDR and the signal should be perfect. It shows that the sender is likely the problem, not your setup.

Looking more closely at your -f 869M sample it seem's the frequency is actually at 869.5M and the noisy signals at other freqs would be "shadows" of that. Try more different freqs up and down to see where you get the strongest and cleanest signal.

[hamchapman]

Okay yeah, it looks like things are a bit clearer at 869.5MHz. Here's a capture having run:

rtl_433 -f 869.5M -Y filter=50000 -s 2048k -M time -R 0 -S all -g 8

with me holding the remote about 1m away from the antenna.

g008_869.5M_2048k.cu8.zip

This is what it looks like:

and a snippet zoomed in:

[zuckschwerdt]

Very nice. So the sender is just at an odd freq with confusing shadows then at 868M. For a good signal try to reduce the clipping, either remove the antenna when you are only ~1m from the SDR or use more distance or reduce the gain -- you don't want color in the waveform.

[hamchapman]

I tried without the antenna and couldn't seem to get any signal being recorded at all, even after cranking the gain up to 40.

I tried moving further away from the antenna (~2m and ~3m) and the signal then seemed to be too weak to even generate a "yellow"-y waveform when loaded up into the web UI.

So then I tried doing a test g017 at ~1.5m and a second test at about 15cm and the screenshot below shows both of them (g017 top, g018 bottom)... and they look basically identical to me. Is that expected?

I then tried with reduced gain (6dB instead of 8dB) but still at ~1m and got a capture (g022) that looks like this:

Here are the mentioned captures: 17_18_22.zip

Am I getting anywhere with them?

Maybe I've misunderstood what you mean by the clipping in terms of how it appears in the screenshots - do you mean that the waveform below the spectrogram isn't all one solid (yellow-y) colour?

[zuckschwerdt]

Clipping is any color, yellow for soft clipping the orange and red for worse clipping. Ideally you want an all gray waveform. You can also spot clipping by the "chopped of" waveform, it should be sines without flat tops or bottoms.

If you reduce the preselected gain in PDV from 6 dB to 0 dB then the amplitude bar (all red in your screenshots) also shows possible clipping, red means clipping at this level of (additional) gain.

The last screenshot seems to show nearly no clipping.

[hamchapman]

So I tried again with lower gain (-g 4 instead of -g 6) and I think I've managed to avoid all clipping and now have an all gray waveform.

Here's the capture.

g037_869.5M_2048k.cu8.zip

And this is what it looks like (with the preselected gain also set down to 0 dB):

Is that the sort of thing I want to be aiming for?

If yes, what are the next steps I should be trying? Should I be get more captures of different operations and then load all the captures into URH and use if I can use that to figure out the messages being sent?

Thanks again for all the help 🙏

[zuckschwerdt]

Yes, the capture looks great for analysis. Drop FFT N to e.g. 64 to see better. It's a very strange waveform though. Ideally we'd see a carrier of sine+cosine as I+Q, i.e. I and Q are the same sine only phase shifted by 90 degree. Then for OOK we'd see the carrier going on and off or for FSK we'd see a fast and a slow sine (two distinct freqs). But here we see a capped off sine, i.e. a sine overlaid with a nearly matching faster signal (in your picture the first 4 waves in the Q waveform) then I guess we see it going out of sync, looking like a heartbeat curve for 4 wave cycles and then back in sync. I think this is interference and not intentional. Could be an artifact of being too close to DC. Could you retry this capture with -f 868.4 and -f 868.3?

[hamchapman]

I managed to find a bit of time to play with this again. Below are the captures I managed to get using -f 868.4 and -f 868.3.

To my untrained eye they look like a step in the wrong direction, but I honestly don't really know 😅 Part of that guess is because of the nice new UI below which seems to think that it might be OOK rather than FSK.

-f 868.4:

zoomed in a bit:

and -f 868.3:

zoomed in a bit:

And this is compared to a capture I then took with -f 869.5 again:

zoomed in a bit:

Does anything stand out to you as something to investigate further or something to tweak?

Here are all of the captures shown above: captures.zip

[zuckschwerdt]

You are right, 868.4 has is too far to the edge of the band and aliasing is visible in the waveform, also 868.3 has multiple visible aliases. I guess I didn't register 869.5M and what we really want to see is -f 869.4 -- only a little shift in center frequency. The signal should not touch the center but be close to it.

[hamchapman]

Okay great, thanks. 869.4 does look like it might be the sweet spot 👀

g004_869.4M_2048k.cu8.zip

[zuckschwerdt]

Very nice, now we can see the waveform clearly as as sinesoid. Change the window to Flat-Top and FFT size to N=128 you can see the frequency as rtl_433 might see it. It's GFSK which is not well supported in rtl_433 but might work.

Looks like (quite fast) 13 µs PCM (75 kbps). After the preamble there seems to be a sync word of a723 a723. But we'd need to see multiple codes and locate a checksum to be sure of sync word and alignment of the bytes. If we align to that one trailing bit, i.e. shifting left 2 bits, we get a sync word of maybe 69c8 e9c8 which does not look as plausible.

[hamchapman]

I captured 60 captures.zip, 15 for each of channel 1, 2, 3, and the "all" channel (where the "all" channel is when all 5 channels are activated at the same time). I did 5 UP presses, then 5 STOP, then 5 DOWN for each channel, in sequence, consecutively. Then I got Claude Code to analyze the captures having provided it with some context about what I was trying to do and it produced this, which, to my uneducated eyes looks quite convincing, although the part about the rolling code (checksum) makes me think I might've hit a bit of a roadblock 🙃

Signal Parameters

• Frequency: 869.4 MHz
• Modulation: GFSK (Gaussian Frequency Shift Keying)
• Data Rate: 75 kbps (13 µs per bit)
• Encoding: PCM (Pulse Code Modulation)

Complete Packet Structure

[Preamble][Sync Word][Cmd Byte][Fixed Header][Variable Data][Rolling Code/Checksum]
aaaa...   b4e474e4   79XX      YZ22ba21XXYY0e4ad5ba8844e116d55XXb76   [varies per press]

Detailed Field Analysis

1. Preamble

• Fixed pattern: aaaaaaaaaaaaaaaaaa (18 bytes of alternating bits)
• Purpose: AGC settling and bit synchronization

2. Sync Word

• Fixed: b4e474e4 (likely a723 a723 with proper alignment)
• Marks the start of data payload

3. Command Byte Structure (2 bytes after sync)

The command bytes follow a clear pattern based on channel and action:

Channel	UP Commands	STOP Commands	DOWN Commands
1	7922-7923	7923-7924	7924-7925
2	7918-791a	791b-791c	791c-791e
3	791f-7910	7911-7912	7912-7914
ALL	7897-7888	7888-7889	788a-788b

Pattern observation:

• Each channel has a base value
• Commands increment through a range
• The increment appears to be a rolling counter (0-5 or 0-7)

4. Fixed Header Analysis

After the command byte, there's a semi-fixed header that varies by channel:

Channel	Fixed Header Pattern
1	[X]622ba2108a80e4ad5ba8844e116d55b0b76
2	[X]622ba2104680e4ad5ba8844e116d557cb76
3	[X]622ba210c280e4ad5ba8844e116d55f8b76
ALL	[X]622ba2133280e4ad5ba8844e116d5db03f6db4

Where [X] is a single hex digit that cycles through values (appears to be a sub-counter).

Key differences by channel:

• Byte 6-7: 08a8 (ch1), 0468 (ch2), 0c28 (ch3), 1332 (all)
• Byte 20: b0 (ch1), 7c (ch2), f8 (ch3), db (all)
• ALL channel has extended header: ...d5db03f6db4 instead of ...d55XXb76

5. Rolling Code Section

The variable section shows clear rolling code behavior:

• Changes with every button press
• Approximately 8-10 bytes of data
• No obvious sequential pattern (likely encrypted or hashed)
• Different for each press even with same command

Command Byte Decoding Logic

The command byte appears to encode:

1. Channel ID: Base value determines channel
2. Command Type: Range determines UP/STOP/DOWN
3. Sequence Counter: Increments with each press (wraps around)

Pseudo-decode:

Channel 1: 0x792X range (X = 2-5)
Channel 2: 0x791X range (X = 8-E)  
Channel 3: 0x791X/0x790X range (X = 0-4, F)
ALL:       0x788X/0x789X range (X = 8-B, 7)

Rolling Code Analysis

Each button press generates a unique rolling code:

• No repeated codes observed across 60 captures
• Code changes even for identical button/channel combinations
• Likely uses a cryptographic algorithm (KeeLoq, AES, or proprietary)
• Purpose: Prevent replay attacks

Example progression for Channel 1 UP:

Press 1: a991f7f73fb1efc48a0
Press 2: b6f5ed633739c8d1f0
Press 3: f1739b1564566358368
Press 4: e3dfa2dd4ae6770d60
Press 5: 940e651bcd1e3d4a918

[zuckschwerdt]

That's some semi-plausible guesses, but not too useful.

If you take the whole body of codes an put them in a BitBench, then you can shift them around and find:

• the preamble is aa..aa actually
• there is a well-known sync word of d391 d391
• there is a length or type indication byte (e4 for the shorter messages, e2 for the longer ones.
• then a mostly-fixed portion, maybe src/dst ID and command.
• the some encrypted portion or a MAC
• there should be something like a CRC-16 somewhere, not sure yet.
• there could be some data-whitening scheme, would explain the somewhat random looking first bytes

[zuckschwerdt]

If we pick just the codes with full 30 bytes (len 367) we get an CRC-16 poly 0x8005 init 0x41c6, which is somewhat plausible. If we pick the codes with full 32 bytes (len 383) we get poly 0x8005 init 0x8277, same generator but indicates that something is off with the init, or that we still need data-whitening.

And yes, the (somewhat expected) IBM Whitening Algorithm works to produce more plausible fields (e.g. len and repeat bytes) and a stable CRC-16 of poly 0x8005 init 0xffff (i.e. "CRC-16/CMS")

The good codes are in this BitBench. For the longer codes insert 8h8h before "MAC".

[hamchapman]

Amazing, thanks @zuckschwerdt!

Are there specific next steps I should take to try and get to the point where writing a decoder is possible? Ultimately I'd like to be able generate my own signals from my own transmitter, so it seems like figuring out what the deal is with the encrypted portion is the biggest unknown remaining.

Should I be collecting tons more samples and then eyeballing them for patterns, or something else?

Many thanks, as ever

[zuckschwerdt]

The encrypted portion secures the authenticity of a transmission. To stop replay attacks there has to be a counter, likely the seconds byte. But it won't be only 8 bits. You should be able (with ~50 presses) to see that counter rolling over to maybe the next byte. Is there a pairing sequence and is it possible to reset the sender? You could then pregenerate codes.