Return to 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.

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.

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).

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.

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 protection bytes to each of the frame you transmit. Also, it takes some time (of the order of ms) 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.

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).