serial interface between RF modules and PIC18F452 mcu

[Munib]

sampling frequency in pic18f252

I am using RF modules operating at 418 MHz with modulation scheme as CPCA(carrier present carrier absent).RF transmitter have serial data input while RF receiver has serial data output.

I interfaced the RF modules to the USART of PIC18F452 mcu.Sent data from mcu#1(connected to RF transmitter) to mcu#2(connected to RF receiver).
I received data at mcu#2 but its corrupted data.
For debugging i wrote a code for mcu#1 which send a number to mcu#2 waits for some time increments that value and again send that value to mcu#2 again wait increment and send and so on
What i found on receiver end is that single 1s in the sent data are converted to 0s e.g if sent data is 00101010 or 10101010 or 10001000 or anything like this the output at receiver end is all 0s
but if there are more than one consective 1s then only first 1 is converted to 0 and all others are received correctlye.g
transmitted 11000111----------->received 10000110
transmitted 00011000----------->received 00010000
transmitted 01001011----------->received 00000010

How to solve this problem?
Someone told me that this is due to the wrong synchronization at receiver end due to wireless connectivity if i will use manchester coding this will be solved.
is it correct?if yes then how?
Any good resources for this coding scheme?
And how to implement this coding in PIC18F452 mcu?

I am using C18 compiler.

 

[traxonja]

module rf how to receive data synchronize

I don't know the answer for real, but it looks like the Manchester modulation could fix the problem. The trick is probably the synchronization at the receiver-side.

Why don't you try next: Put the transmitter to non-stop-transmit-state (logical 1). Check the receiver, to see what the PIC receives. It should receive one's non-stop.
Try it then with transmitter off (no carrier - logical 0). If the PIC receives some one's (1) then you probably have another transmitter transmitting on the same frequency and that could be the problem.

When using Manchester modulation or maybe FSK modulation (if possible with your present modules) i think you could solve the problem. FSK - definatelly, Manchester - probably.

Did you think about maybe replacing RF modules to maybe nRF2401 RF transciever chips? They fully take care of RF protocol...

Trax

 

[R00KIE]

preamble 00101010

I don't know much about coding schemes but if it is working correctly you should be able to transmit data without too much errors, try to set a slower USART speed and make sure the speed is set the same way in both PICs, pay atention to PIC clock speed/USART speed setting you may be missing something there, the next one is just a guess that can be completely wrong but those RF modules probably have an AGC (auto gain control) circuit and that may be the problem, try to put them closer or farther from each other.
another thing that could be happening is, if both modules are capable of receiving and transmitting the transmitter at the receiver can be interfering with the signal see below

     RF1        signal         RF2
receive/send  ==========>  receive/send
                    ^               |
                    |===============|

i hope this helps to explain

 

[Munib]

pic18f y rf

the data corrption is not due to interference from any other transmitter this is confirm.

I cant use any other RF module as i have already purchased these.

please give me some links to good resources for manchester encoding and its implementation in mcu

It was also suggested to use preamble bits to synchronize the data but as the preamble bits will be 10101010 or 01010101 and according to my problem whenever a single 1 occurs in my data byte it is recived as 0(refer to the examples quoted above)Can anyother combination for preamble be used?
what if that combination also occurs in my data?

 

[maui]

rf on off mcu

Munib,

Yes it sounds like a problem with the modulation or channel codeing.
I don't know weather you would be able to change either of theses things in your modules. Chech CAREFULLY that they are both initialised to opperate to the same modes (one transmit and one recieve of course).

If that doesn't help one thing you could do is implement your own channel codeing to fix this problem. It sounds like you could do this by transmitting a 1 before each bit.
This will effectivly halve your data rate, but will stop your data coruption problem (hopefully).
So if you want to send 01001101 you send instead 10111010 11111011
and when your recieve two bytes you remove every odd data bit (which is a 1) and end up with the original data byte.

Maui

 

[traxonja]

manchester modulation

Hello,

I was thinking a little, maybe the problem is that your UART speed is too low for your receiver to recognize logical ONE's. That's why you end up with only one logical ONE instead of two or three in a row. Maybe your transmitter doesn't have enough power to transmit whole three bits as ONE's end it pauses a while after transmitting one bit of ONE's. - could be!

"maui" has given you a nice sample of Manchester. In manchester, logical ONE is transmitted as 10, and logical ZERO as 01. That's all!

Check this link for manchester encoding **broken link removed**


Do you have any datasheet of your RF modules? How much did you pay for them? Where?


Best regards,

Trax
www.elektronika.ba

 

[AndrzejM]

why does data missing occurs in rf modules

"traxonja" sugessted that

"maui" has given you a nice sample of Manchester.

The detail analysis shows, that the code suggested by "maui" is not a Manchester one, you could rather call it "the maui code".
Furthermore, to get the correct pattern at the receiver side for ALL possible patterns, the "maui code" should also be worked out a bit. (Not all patterns are decoded correctly at present).

To say the true also "real Manchester code" probably will not correct the problem.
Example:
1 1 1 will be converted by "manchester" into 10 10 10 according to "corruption description" will be received as 00 00 00 and ???
I do not know what to do next ?
The string is too short of 1's to convert the string from "two bit manchester" to "single bit data" => death end!

"Munib" presented "coruption rules" as follow:
transmitted 11000111 ----------->received 10000110

and explain it as :
"if there are more than one consective 1s then only first 1 is converted to 0 and all others are received correctly"

I suspect that the physical transmission is carried out in "reverse" order.
In the presented string
the first "1" is marked red but the second "1" is marked blue.

On this base I came to conclusion that the software solution can use the following convertion (code):
1=> 11 and 0=> 00 on transmitter site
and
received 10 OR 11 are converted to 1 ; received 00 is converted to 0 (read all data from right to left!)
A few software checking mechanisms can be added:
1. 01 is not a valid bit pair
2. 11 MUST be proceeded by 10
3. bit PAIR sequence 10 11 is not allowed

 

[MicroCoder9]

rf modules serial

Munib wrote in original message:

What i found on receiver end is that single 1s in the sent data are converted to 0s e.g if sent data is 00101010 or 10101010 or 10001000 or anything like this the output at receiver end is all 0s
but if there are more than one consective 1s then only first 1 is converted to 0 and all others are received correctly

I believe the problem is being caused by the output device in transmitter or input device in receiver going into saturation when a 0 is sent ( transistor is switched on for a 0 ) and it takes time to come out of saturation when the first 1 is sent. Due to this, the first 1 is received as 0 but when more than one consecutive 1s are sent then it gets enough time to come out of saturation ( transistor switches off i.e. goes into cut-off for a 1 ).

So Munib you need to make sure that a device in the transmitter-receiver chain is not incorrectly biased or driven too hard due to which it may be taking longer time than desired to come out of ON state and you miss the first 1 after a 0.

If the biasing etc is correct, then you may be transmitting at a faster rate than your hardware can handle. You need to use faster devices in your circuit which can change from ON to OFF quickly enough to handle 1s after 0s properly.

I hope this helps.

 

[Mr_Programmer]

serial input using pic18f452

Hi Munib,

I've got the best results with the following procedure:
1. send out a preamble (1-3 Bytes this depends on your receiver), take 0xAA or 0x55
2. use a start sign, as example 0x33
3. detect the start sign via bit banging the port pin
4. after you have your start sign switch on the uart
5. if your message is short, use bit banging or even a interrupt

BTW: The modulation is called OOK (On-Off-Keying)...

Cheers...