EEVblog Electronics Community Forum
General => General Technical Chat => Topic started by: flipper on November 04, 2024, 12:57:28 am
-
I found this nice little module inside an old Christmas laser projector. On the data sheet it says “315Mhz/433Mhz” but doesn’t mention how one discerns which frequency the module is set to.
Also, the data sheet says something about Manchester encoding, but barely ANYTHING; is this a requirement, or a “suggested” use?
I have the matching remote, and there’s data coming out of the “DATA” pin, but I’ve yet to decode it. Any help would be great.
Thanks. :)
Here’s the data sheet:
http://www.radiumcorp.com/edata/RX305D.pdf (http://www.radiumcorp.com/edata/RX305D.pdf)
-
data coming out of the “DATA” pin
when you acquire right test equipment this mystery to be solved. so welcome aboard.
-
13.2256 MHz xtal is used for 433.92 MHz
http://www.radiumcorp.com/data/SRX303LD.pdf (http://www.radiumcorp.com/data/SRX303LD.pdf)
-
Also, the data sheet says something about Manchester encoding, but barely ANYTHING; is this a requirement, or a “suggested” use?
I have the matching remote, and there’s data coming out of the “DATA” pin, but I’ve yet to decode it. Any help would be great.
Thanks. :)
Here’s the data sheet:
http://www.radiumcorp.com/edata/RX305D.pdf (http://www.radiumcorp.com/edata/RX305D.pdf)
Looks like oPossum nailed the first question.
As for the data, I believe that is a suggestion rather than a requirement - it could very well be manchester/biphase encoded data the micro is sending, or it could be a form of PWM - ppulse width modulation, where a digital '1' is sent as a pulse with a fixed on period, and a digital '0' is send as a pulse with a different on period - that way the reciever gets a pulse per bit, and can measure the high period to determine whether its a 1 or 0.
You can't send DC over RF links, so a form of "channel coding" is used. Of which, manchester coding (or biphase) is one, there are a few others, but its a method to allow the reciever to recover the clock - so long runs of 1's and 0's can be read - and to balance the signal so there is no DC component. It also makes it more robust to inevitable errors caused by noise, which for RF links, is substantial.
If you have an Arduino, I've heard that the Radiohead library ( https://docs.arduino.cc/libraries/radiohead/ (https://docs.arduino.cc/libraries/radiohead/) ) can be used to decode "most" datalinks like these (think garage remotes, simple stuff, not secure rolling code).
-
Manchester/biphase encoding is the normal "goto" scheme.
But if you're interested in higher data throughput, you could consider MFM/delay modulation:
[attachimg=2]
-
Okay this is all getting WAY too confusing and moving too fast for me. Too much info. I don’t know what “Manchester encoding” even is, never mind “bi phase”. I possibly have ADHD, please would you move slower and explain more?
Thanks.
-
Okay this is all getting WAY too confusing and moving too fast for me. Too much info. I don’t know what “Manchester encoding” even is, never mind “bi phase”. I possibly have ADHD, please would you move slower and explain more?
Thanks.
Radio signals sent through the air don't behave the same as voltage signals sent along a wire, hence usually needed to be encoded somehow.
By far the most common and easiest encoding to implement is Manchester encoding (biphase is a less common name for it).
So consider the ASCII code for the letter A which in binary is 01000001. One version of Manchester encoding converts 0 into 01, and 1 into 10. So now the letter A becomes 0110010101010110.
The reason for encoding like this is to keep the 1s and 0s balanced at roughly 50%, and it is this 50% balance that is preferable for radio signals.
-
One reason here is that the receiver only supports amplitude modulation (OOK/ASK). If you want to keep things simple enough, a typical data slicer requires a reasonably balanced signal, which Manchester (or similar) provides.
This article covers the basics: https://www.analog.com/en/resources/technical-articles/data-slicing-techniques-for-uhf-ask-receivers.html (https://www.analog.com/en/resources/technical-articles/data-slicing-techniques-for-uhf-ask-receivers.html)
-
Okay this is all getting WAY too confusing and moving too fast for me. Too much info. I don’t know what “Manchester encoding” even is, never mind “bi phase”. I possibly have ADHD, please would you move slower and explain more?
Thanks.
Radio signals sent through the air don't behave the same as voltage signals sent along a wire, hence usually needed to be encoded somehow.
By far the most common and easiest encoding to implement is Manchester encoding (biphase is a less common name for it).
So consider the ASCII code for the letter A which in binary is 01000001. One version of Manchester encoding converts 0 into 01, and 1 into 10. So now the letter A becomes 0110010101010110.
The reason for encoding like this is to keep the 1s and 0s balanced at roughly 50%, and it is this 50% balance that is preferable for radio signals.
Thank you. Which version of Manchester encoding are you referencing, since ChatGPT says this:
-
Thank you. Which version of Manchester encoding are you referencing, since ChatGPT says this:
Yep! ChatGPT's response is the other Manchester encoding scheme. You can use either version, performance-wise they both behave exactly the same as each other.
The ChatGPT version is used when the idle status or zero signal status, is a 0.
My version would be used when the idle status or zero signal status, is a 1.
-
I am still confused; does the user put "normal" serial data into the Tx module, and the module takes care of encoding it in "Manchester encoding", or does the user do the encoding?
-
I am still confused; does the user put "normal" serial data into the Tx module, and the module takes care of encoding it in "Manchester encoding", or does the user do the encoding?
For the RX305D module that you mentioned in your opening post, yes, the user does the encoding. In fact the majority of 433MHz modules on the market will require user encoding.
That being said, you can try and put normal serial data into it.... you may not get good range and/or reliability due to received signal errors.
Oh! and I don't think anyone's mentioned the preamble and sync yet!
As I mentioned before, radio signals are not like sending a signal through a wire. So there's a whole lot of stuff that needs to be done to format the data for transmission, and unfortunately these 433MHz modules are "dumb" and lack the smarts/intelligence to do the encoding.
-
Note that Manchester encoding is very easy, and given the low data rates here, you can easily bit-bang it even on a very modest MCU.
If you want to avoid bit-banging, you can otherwise use a conventional UART and encode your data itself so that the output of the UART will look like Manchester. Obviously it doubles the number of bytes you have to send, but that's an approach I've used on small MCUs.
-
For a more in-depth look at reverse engineering 433MHz transmitters, this might give you an overview of what's involved:
https://nickwhyte.com/post/2017/reversing-433mhz-raex-motorised-rf-blinds/
-
I really appreciate all your help guys. :) thank you.
Also, this guy is a really good teacher:
https://www.youtube.com/watch?v=b5C9SPVlU4U (https://www.youtube.com/watch?v=b5C9SPVlU4U)