rf communication between two transistors

Status
Not open for further replies.

chandan28

New Member
rf communication between two microcontrollers

hi all
i'm doing a project on controlling vehicle movement(simple car module) using touch screen
i'm sending states like whether the vehicle is moving forward, backward, left or right...depending upon the touch screen movement

it has got two parts... transmitter and receiver i'm using atmega32 controller both sides

transmitting and receiving parts are working fine when connected by wire
when i use rf module (standard 433MHz transmitter datasheet can be downloaded from www.sunrom.com) for transmitting data(state) serially i could not receive the states(1byte) properly may be because of noise.

i tried diff baud rate (4800,2400,1200,300 according to datasheet) but wen i see the output i'm getting junk values+transmitted states

rf module works fine(recieved data with almost 0 error) when the code contains only sending some data nothing else...in all the above mentioned baud rates

can some one help me how could i get the proper bytes using rf transmission so that it can be recieved with much less noise

it will be helpful if you post the diagrams,schematics...
 
Last edited:
You can't sent plain serial via radio links, you need to encode it using Manchester coding or similar - either in your software for simple modules, or use modules with encoding/decoding built in.

RF Solutions sell encoder/decoder chips that convert serial to Manchester as well, and are presumably the chips used in their complete modules.
 
why rs232?? i think its not required...its just serial communication between two controllers...

RS232 is the standard serial type, it's only the voltage levels that's different - it's just easier to type RS232 than "serial communication".
 
i think we r deviating from the original topic...i need rf communication the module is working without any encoding when the program contains only data....i want to use it for some application which has lot of calculation ...pls tel me how could i send data after calculation
i want some methods like
1.some extra circuit so that the noise will be reduced
2.or using some protocol like sending the synchronization bytes before sending data
 

Data is data - if it works fine on data, then it will work fine on the data you calculate.

But I suspect what you mean is it works 'fine' only on some values of data, and this will vary as timings change.

i want some methods like
1.some extra circuit so that the noise will be reduced
2.or using some protocol like sending the synchronization bytes before sending data

Neither would work reliably, you need some kind of coding.

If you invert the data, then you can sometimes 'get away with it' as long as you only use a low baud rate. This means either using a software UART, or a hardware inverter.
 
I think you have not understood actual problem...
there is no problem with rf module...
what ever you told about encoding and other aspects are taken care by the module i have....
it will transmit what ever is given to transmitting terminal does not care which type of communication(UART,USART etc)
the problem is i could not transmit a byte which is obtained after some calculation which takes around 100ms(approximated not exact)...
that is junk values will be printing due to that 100ms delay in transmission..
1200 baud rate means 1200 bits per second that is 150 bytes per second
around 6.6 ms per byte i.e.. 0.83 ms per bit
if it not transmitted in that period then it will be lost... that is whole byte is error so i want to avoid it somehow so that one byte data can be transmitted properly
 

The reason for your problem, as I've repeatedly explained (and is explained on the link I provided), is that you need to use Manchester coding - as you have found, plain serial doesn't work. You could add hardware inverters, which may help a little, but it still leaves a very unreliable system. Your modules DO NOT have their own coding, or you wouldn't have the problem.
 
Status
Not open for further replies.
Cookies are required to use this site. You must accept them to continue using the site. Learn more…