PR 16 Sending data through RF

[anonymous_k87]

Hi...I'm new here.....
I am currently working on a project that required sending data through wireless. So I bought the DIY project module to try it out.
FYI I have modified the code n circuit to send until 255 and displaying it in 2 7-segment LEDs. The modification works out well. The transmission were successful.
However, there are times where it got a lot of noise throughout the transmission. The receiver side keep on receiving random stuffs (e.g. tx 0x00 -> rx 0xff /0xde / 0x00 / 0x11....and so on ).
I have tried stabilizing the voltage input and separating rx module away from crystal yet not helping much.
Now I'm trying to use CRC method to solve the noise issue but I have one doubt. CRC method only check whether the packet received correctly or not, it just cannot confirm the transmission. What if the environment is so bad and my circuit keep on receiving random stuffs, isn't it pointless to use CRC method?
Is there any other way to improve more on the performance?
Thx in advance~~;)

[A380]

Ya, this is because of the interference from the environment. May be you can write a digital filter to reduce it with your own protocol. For example, you send some specified data like '0xAB','0xCD' and '0xEF' before your desired data sent. So you receiver there will filter it and it only receive the data if '0xAB','0xCD' and '0xEF' is received, otherwise reject it. You can add more specified data for better filtering but it will slow your transfer speed.

[anonymous_k87]

Will a better antenna plus RF module improve the circuit performance?
Cytron has these better module? If yes I would like to buy it...

[A380]

I think better antenna only can improve the transmission range but not the noise.

[yonghui]

hello,

like what suggested by A380, sending data as packet is a way. create packets to be something like this,
1st byte: start delimiter
2nd byte: length of packet ( if you are sending different packet length every time, else no need)
3rd-n: data bytes
n+1: checksum

make the host ignores all signal prior to receiving the start delimiter.
the host will only start receive after it receive the start delimiter.
calculate the checksum and if the packet fails checksum discard the packet.

if the environment is still really very noisy after make the protocol above. u may consider to escape/ flag data bytes that happen to be same as the start delimiter to avoid confusion of whether its data byte or start delimiter. write escape function to escape the needed byte. escape means change the byte to another form, but can be recognized by the host.
with this, the host can ignore all bytes and consider its a new packet every time it receive a start delimiter.

yh

[anonymous_k87]

Hi yh,

FYI my project is telemetry system which required transmitting data (8bits) in wide range. So environment noise immunity is very crucial to the system.
I'm using USART to send the signal via rf module. I have tried using different baud rates and also using the CRC method you suggested, it appears that the receiver just keep on receiving random numbers (a lot of noise that overwhelm the sending signal). When I tried jumping the TX and RX pin, it works pretty well.
So I come up with a hypothesis that the rf module (-100dBm) I bought are very poor in environment noise immunity. I bought another pair of low cost rf module and it turns out having the same issue. It cannot even operate a basic program of PR16(sending 4 bits data through RF).
Do you or anyone know how to solve this issue? Maybe suggesting me some better RF modules that have high environment noise immunity (besides xbee as it is expensive)?
Please~~~*frustrated*

Thanks in advance...

[aurora]

By right, CRC method should have work.

How critical is your transmission speed? How far you intend to transmit? If it's not critical, try sending with very low baud rate, limit to several bytes/second. It's not the smartest solution, but it is fool-prove method.

Erm, how about 2.4ghz RF module? Very good transmission and noise immunity. As good as xbee, except that it is one-way communication.