Congrats on your perseverance. I was searching for a way to identify the protocol a 433 Mhz driveway alarm that is not supported by rtl-433. What you accomplished was way above my skill set, but I enjoyed the video. Well done.
Brilliant! I had the same idea a long a time ago, gave up in the decoding part. I didn't know at that time about the checksum...but you made it excellent!
Great video and great work... I want to study the Tx protocols for simple wall plate "switches"... but there are at least 3 different systems, maybe more. The only one I have found data for is "1527 Learing code" The Tx are usually a push button, or a toggle. and the receivers are "just" a relay or switch circuit. eg wall plug or module for lights etc. Some of the transmitter wall plates are "Kinetic" and dont use a battery. They have a magnet moving through a coil to generate a spike of voltage & current. it;s rectified and regulated and the Tx squirts out a data sequence or two or 3... My idea is to see if I can create a receiver decoder to pair with not just one but 2 or 3 Tx protocols.. So to start I'm going to try looking at the data stream for each of the Tx's I have samples for... And you suggestion about audacity and capturing the waveform seems a good place to start My challenge is that I'm an analogue engineer, and microcontrollers are a bit of a black art, but it's not Rocket science! If you are interested to stay in touch let me know! Typically the relay switches have a tiny analogue IC for the 433MHz RX and this squirts it's output to a tiny FMD 8 pin Microcontroller.. which looks at the preamble (Clock run in) the Tx serial number to "pair to" and maybe a data packet with 4 bits (1527 allows for that that I think) but for just a switch you don't need any data, just toggle each time you pick up the TX serial number that it's been paired with..
Hey Kimmo, it's actually simpler than you'd expect - The 433 recevier has a 5v, signal and gnd pin. Connect the 5v to a 5v power rail, connect the ground to the ground rail, then connect the signal line to the pin which corresponds with the tip of the 3.5mm jack. Connect the ping for the sleeve of the 3.5mm jack to the ground rail. I'm sure in the real world slipping some appropriate sized resistors /voltage divider in there would be wise to avoid blowing your sound card, but this wasn't a major concern of mine at the time, so I omitted it.
This was good work! For me, I just sniffed out all the codes in a remote and replayed them from Home Assistant. My wife would probably lose it if I spent that much time into our roller shades and asking why they weren't working yet. The solution doesn't scale for a large number of shade motors, but the remotes are very cheap and we have a limited number of windows. I also found better success with the BoardLink RM4 Pro's ability to sniff out remote codes. I believe the integration performs a channel scan and directly you to hold down the remote button. However, I think the code is only sent out one time by the remote when button is initially pressed. By accident, I found by repeatedly pressing the button instead, I was able to consistently capture the codes from the remote.
Great presentation! Thanks for taking the time to put it together. Was there a reason you had to do a full decode of the protocol? It seems like it was transmit only, with no responses back to the remote. In that case, could you have replayed the captures for each action, offset into the sub-channels for each blind? Also, it'd be great to have more details on your SDR hardware.
This was one of my early concerns in the project and I was suspicious it might be the case. It was one of the factors that pushed me toward decoding the protocol because I knew if it was rolling code, it would be the only option (as replaying codes wouldn't work). However once I was actually able to see visually the data being transmitted (in Audacity) I became aware it wasn't rolling code. If it happened to be rolling code, I expect I would have taken a similar approach. I would look at the raw bytes, and try to understand what part of the payload changes when the same action is repeated. Once figured out the pattern for rolling codes, I would apply the same techniques to figure out the different parts of the payload (i.e. action, channel, etc). However, having no experience in this, perhaps it might be more difficult that just that .
Funny small world, my son sent me your vid, being having intermittent problem with same remote & wanted to do the same with phone. Would obviously want to know more.
I wasn't really keeping track of specifically how many hours the project took, but from start (getting the first blind + idea to control with Home Assistant) through to implementation (building the initial prototype of the RF transmitter) somewhere around 4-6 months. I wasn't spending loads of time on it, and at one point put it down entirely, and had some time off for a holiday at another point (I ended up cracking the checksum on that holiday in the end). Beyond this, I've definitely continued to spend more time refining the transmission firmware through the evolutions outlined in the later part of the talk. At this stage I feel the project can be considered "completed". I am very happy with the firmware within ESPHome, but as it's a custom component, I can never be certain when a breakingAPI change will happen, requiring some refactoring to get it compiling again.
@@nickw444 Hey man, loved the video! Do you think this same process / a similar process would be viable for reverse engineering a 2.4GHz protocol for various different Guitar Hero and gaming controller connections? The dongles are in very limited supply as they do not make them anymore, and reverse engineering the firmware and hardware and communications protocol would be absolutely HUGE!
Absolutely impressive. Thank you for sharing your knowledge with us! I'm currently trying to capture signals from a transmitter of unknown frequency - opening the transmitter shows a quarz with "R433", so i assumed it is 433 - which brought no signal while listening to it with a regular arduino 433 receiver - which runs at 433.92 Mhz afaik - so i thought - maybe it's another frequency? I just ordered a CC1101, so i hopefully can capture 433.42 Mhz and maybe get some some kind of signal from my handsender. I'd very much love to just use it in smart home, too, without reyling on a physical sender device. Any help appreciated!
Amazing video. thank you. I am new to SDR and trying to adapt it to my captured 2-FSK data. I have few points I am struggling with using RTL-SDR/HackRF1/Yard Stcik1/GnuRadio/URH etc. 1. My device transmits once per day after midnight. I narrowed down the minutes but I have a large 40 seonds gap before transmission starts. = large file 2. I am not 100% sure now if this is an FSK signal. I followed tutorials online to display the modulated and demodulated signal in Gnu Radio and I cannot get the nice square waveform 3. I cannot determine the preamble, or any clock sync and or the data I would be grateful if you can point me in the right direction and help me with my challenging project to review the security of this device.
the carrier frequency is 433MHz, not the digital data it carries with whatever scheme it was modulated with. In RF data transmission, 433MHz carrier frequency is modulated with schemes such as ASK, PSK or FSK. This is just like the FM radio. Ex: You tune to 102.5MHz in your FM radio but the data it carries (analog audio) is in audio range ~18KHz
Congrats on your perseverance. I was searching for a way to identify the protocol a 433 Mhz driveway alarm that is not supported by rtl-433. What you accomplished was way above my skill set, but I enjoyed the video. Well done.
Very, VERY impressive! I wish I had the time and experience to do something similar. Thanks for showing this. Cheers
Brilliant! I had the same idea a long a time ago, gave up in the decoding part. I didn't know at that time about the checksum...but you made it excellent!
Excellent work. Thanks for sharing. 👍
Great video and great work... I want to study the Tx protocols for simple wall plate "switches"... but there are at least 3 different systems, maybe more. The only one I have found data for is "1527 Learing code" The Tx are usually a push button, or a toggle. and the receivers are "just" a relay or switch circuit. eg wall plug or module for lights etc. Some of the transmitter wall plates are "Kinetic" and dont use a battery. They have a magnet moving through a coil to generate a spike of voltage & current. it;s rectified and regulated and the Tx squirts out a data sequence or two or 3... My idea is to see if I can create a receiver decoder to pair with not just one but 2 or 3 Tx protocols.. So to start I'm going to try looking at the data stream for each of the Tx's I have samples for... And you suggestion about audacity and capturing the waveform seems a good place to start
My challenge is that I'm an analogue engineer, and microcontrollers are a bit of a black art, but it's not Rocket science!
If you are interested to stay in touch let me know! Typically the relay switches have a tiny analogue IC for the 433MHz RX and this squirts it's output to a tiny FMD 8 pin Microcontroller.. which looks at the preamble (Clock run in) the Tx serial number to "pair to" and maybe a data packet with 4 bits (1527 allows for that that I think) but for just a switch you don't need any data, just toggle each time you pick up the TX serial number that it's been paired with..
Brilliant Video!
Do you have schematics to your Poor man's SDR available?
Hey Kimmo, it's actually simpler than you'd expect -
The 433 recevier has a 5v, signal and gnd pin. Connect the 5v to a 5v power rail, connect the ground to the ground rail, then connect the signal line to the pin which corresponds with the tip of the 3.5mm jack. Connect the ping for the sleeve of the 3.5mm jack to the ground rail.
I'm sure in the real world slipping some appropriate sized resistors /voltage divider in there would be wise to avoid blowing your sound card, but this wasn't a major concern of mine at the time, so I omitted it.
Very nice. Would be nice to read more about it!
I gave up on trying to prank my boss and now I’m just enjoying my new RTL-SDR. 😅
This was good work! For me, I just sniffed out all the codes in a remote and replayed them from Home Assistant. My wife would probably lose it if I spent that much time into our roller shades and asking why they weren't working yet. The solution doesn't scale for a large number of shade motors, but the remotes are very cheap and we have a limited number of windows.
I also found better success with the BoardLink RM4 Pro's ability to sniff out remote codes. I believe the integration performs a channel scan and directly you to hold down the remote button. However, I think the code is only sent out one time by the remote when button is initially pressed. By accident, I found by repeatedly pressing the button instead, I was able to consistently capture the codes from the remote.
Is an oscilloscope needed?
Impressive ! Congratulations ! I’d like to control RF myself to automate my heaters
5:25 but Sound card only works in 20khz range not in even A Mhz range so how it's possible ?
Great presentation! Thanks for taking the time to put it together.
Was there a reason you had to do a full decode of the protocol? It seems like it was transmit only, with no responses back to the remote. In that case, could you have replayed the captures for each action, offset into the sub-channels for each blind?
Also, it'd be great to have more details on your SDR hardware.
Great video. What would happen if the remote used rolling codes?
This was one of my early concerns in the project and I was suspicious it might be the case. It was one of the factors that pushed me toward decoding the protocol because I knew if it was rolling code, it would be the only option (as replaying codes wouldn't work). However once I was actually able to see visually the data being transmitted (in Audacity) I became aware it wasn't rolling code.
If it happened to be rolling code, I expect I would have taken a similar approach. I would look at the raw bytes, and try to understand what part of the payload changes when the same action is repeated. Once figured out the pattern for rolling codes, I would apply the same techniques to figure out the different parts of the payload (i.e. action, channel, etc). However, having no experience in this, perhaps it might be more difficult that just that .
Funny small world, my son sent me your vid, being having intermittent problem with same remote & wanted to do the same with phone. Would obviously want to know more.
Very good job and thanks for the informations! I have 4 remotes for blinds and windows.. went the easy way and soldered cables to a d1mini 😂
Thank you! How much time does it take you to finish this project from the start to the end?
I wasn't really keeping track of specifically how many hours the project took, but from start (getting the first blind + idea to control with Home Assistant) through to implementation (building the initial prototype of the RF transmitter) somewhere around 4-6 months. I wasn't spending loads of time on it, and at one point put it down entirely, and had some time off for a holiday at another point (I ended up cracking the checksum on that holiday in the end). Beyond this, I've definitely continued to spend more time refining the transmission firmware through the evolutions outlined in the later part of the talk.
At this stage I feel the project can be considered "completed". I am very happy with the firmware within ESPHome, but as it's a custom component, I can never be certain when a breakingAPI change will happen, requiring some refactoring to get it compiling again.
@@nickw444 Hey man, loved the video! Do you think this same process / a similar process would be viable for reverse engineering a 2.4GHz protocol for various different Guitar Hero and gaming controller connections? The dongles are in very limited supply as they do not make them anymore, and reverse engineering the firmware and hardware and communications protocol would be absolutely HUGE!
Absolutely impressive. Thank you for sharing your knowledge with us!
I'm currently trying to capture signals from a transmitter of unknown frequency - opening the transmitter shows a quarz with "R433", so i assumed it is 433 - which brought no signal while listening to it with a regular arduino 433 receiver - which runs at 433.92 Mhz afaik -
so i thought - maybe it's another frequency?
I just ordered a CC1101, so i hopefully can capture 433.42 Mhz and maybe get some some kind of signal from my handsender.
I'd very much love to just use it in smart home, too, without reyling on a physical sender device. Any help appreciated!
bro! how to generate code from Arduino (or Wemos 8266) + Transmitter for Remote learing code ( It doesn't have code)? thansk a bunch!
Amazing video. thank you. I am new to SDR and trying to adapt it to my captured 2-FSK data. I have few points I am struggling with using RTL-SDR/HackRF1/Yard Stcik1/GnuRadio/URH etc.
1. My device transmits once per day after midnight. I narrowed down the minutes but I have a large 40 seonds gap before transmission starts. = large file
2. I am not 100% sure now if this is an FSK signal. I followed tutorials online to display the modulated and demodulated signal in Gnu Radio and I cannot get the nice square waveform
3. I cannot determine the preamble, or any clock sync and or the data
I would be grateful if you can point me in the right direction and help me with my challenging project to review the security of this device.
Very useful work. Thanks for sharing!
5:25 but Sound card only works in 20khz range not in even A Mhz range so how it's possible ?
the carrier frequency is 433MHz, not the digital data it carries with whatever scheme it was modulated with. In RF data transmission, 433MHz carrier frequency is modulated with schemes such as ASK, PSK or FSK. This is just like the FM radio. Ex: You tune to 102.5MHz in your FM radio but the data it carries (analog audio) is in audio range ~18KHz
@@Mr_ToR yah I know that modulation, like Frequency and amplitude modulation and sift keying etc