I know this is kind of a noob question. I am trying to establish a wireless communication between two 8051 microcontrollers using a 433 MHz RF module. But since 433 MHz is a quite noisy frequency, the receiver immediately starts collecting the garbage around. In this case, would implementing a software filter do the job to eliminate the garbage data or is my data getting completely disturbed on the way? Thanks in advance.
Electronic – 433 MHz RF noise problems
8051interferenceRF
Related Solutions
When I have a design problem like this, I first think "how would I decode this by hand" and then I try to implement my thought process through use of electronics.
So, when I look at your two diagrams I see only one thing that my brain can use to determine what is data and what is noise, that is the width of the pulse. The problem with passive components in a situation like this is that for one you have a square wave that will have harmonics much higher then the cut off point for your filter. This will result in a not so square wave.
The easiest way to do this will probably be in software. You can still use interrupts, but it will take a bit more work. Essentially what you will have to interrupt on an edge, and then count time until the next edge. If the length of time is long enough then you can call it a logic 1 otherwise you can consider it noise on top of a logic 0.
If you must go with passive components you might want to consider a low pass filter followed by a comparator. You would have to play with the low pass filter to get it just right, but essentially you would aim to have the capacitor charge just high enough to cause the comparator to switch its output when the bit has been on long enough. What makes this difficult is that your "glitches" are very similar to your data and it is difficult to tune your circuit just right to get your data with no glitches. Even if you are able to perfect it on paper your components wont be very precise either. It is because of this that you should seriously consider doing this digitally.
Firstly look how I've modified the power and ground leads below (in red): -
It's important to star-point different circuit blocks back to their respective batteries in order to minimize loop current emissions. The important one is the 12V local to the L293D chip. Talkingof which, be sure to use the version with a "D" on the end because that has internal flyback diodes and without these you'll be producing voltage spikes that could interfere with tesla coils (that was a joke that last bit).
Next are decoupling capacitors across each motor - If you are using PWM control you need to be a bit cautious with high values as these will suck energy from the pulse width modulation. Try 10nF across each motor and if necessary try a 10uH inductor in series with each motor with a bigger cap (like 100nF) still directly across the motor.
The problem could be also solved by making the whole of the 0V system a local earth plane - there may still be currents flowing in your current set-up that cause the HT12D to glitch and lose control.
Make sure you have all the major electronic components decoupled with caps too. Maybe 10uF and 10nF across the HT12 and L293D and receiver. HT12 and receiver should be close together and have as a minimum a shared local earth plane.
Best Answer
Are you using such type of modules?
If yes, then don't expect them to work without proper software noise filtering algorithms. This module will give out data at Rx output even if there is no other transmitter operating at 433MHz. This is because this device works on OOK(On-Off Keying) and AGC (automatic gain control). Thus if Rx does not detect any signal for some time it will automatically reduce the threshold, and once the threshold gets close to the noise level, then the noise will get interpreted as the bitstream of \$ 1\$'s and \$0\$'s.
To properly identify your packets, add 3-4 identification bytes to each of the frames you transmit. Adding more number of identification bytes will reduce the probability that the noise will get interpreted as your packet. Usually, 3-4 bytes are sufficient.
Also, it takes some time (few bit durations) to get the threshold adjusted with the transmitting signal level, so if you are not transmitting continuously then it is better to send 1 or 2 junk bytes before transmitting any frame (as initial bits have some chance of getting corrupted due to improper initial threshold level).
Hardware solution: A common chipset used in such receiver module is PT4317. If you check the datasheet then you can see that the data slicer inputs are available off-chip. Thus the slicing threshold can be manually adjusted by properly assigning threshold voltage to DSN pin. But this will compromise the sensitivity of the receiver and thus the longest range it can operate with. You will have to experiment with different values of this pin's voltage and the range it produces.