Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Manchester Code for a PIC ..request for help

Status
Not open for further replies.

Electrix

Member
I am in a total fix.... :?
I have made a project that transmits data to a PC & other PICs around it wirelessly. I am using RF Modules @ 433MHz. Now the data transfer is fantastic over the RS-232 lines. But when I switch to wireless ...all i get is garbage.. :( I am still doing the 232 thing and my PIC TX pin feeds the data in of transmitter. I understand that using RF calls for precautions such as using Manchester Coding. Can some one hellp me out by giving an insight as to how my data from the PIC can be encoded in Man. Format & how do I decode this to get my original format at the PC side.

Please suggest something ..thanks.
 
Electrix said:
I am in a total fix.... :?
I have made a project that transmits data to a PC & other PICs around it wirelessly. I am using RF Modules @ 433MHz. Now the data transfer is fantastic over the RS-232 lines. But when I switch to wireless ...all i get is garbage.. :( I am still doing the 232 thing and my PIC TX pin feeds the data in of transmitter. I understand that using RF calls for precautions such as using Manchester Coding. Can some one hellp me out by giving an insight as to how my data from the PIC can be encoded in Man. Format & how do I decode this to get my original format at the PC side.

Many threads on this site already tell you that plain RS232 can't be used over radio links, you can actually buy the radio modules with Manchester coding built-in, which cures the problem.

For a very easy simple cure, try inverting your RS232 (obviously at both TX and RX - if you're using software RS232 it's only a couple of instruction changes), it can help to overcome the problem, but doesn't give the other benefits of manchester coding.

There seems very little sample code available, but you might try https://jap.hu/electronic/codec-v4.0.html.
 
Nigel Goodwin said:
Electrix said:
I am in a total fix.... :?
I have made a project that transmits data to a PC & other PICs around it wirelessly. I am using RF Modules @ 433MHz. Now the data transfer is fantastic over the RS-232 lines. But when I switch to wireless ...all i get is garbage.. :( I am still doing the 232 thing and my PIC TX pin feeds the data in of transmitter. I understand that using RF calls for precautions such as using Manchester Coding. Can some one hellp me out by giving an insight as to how my data from the PIC can be encoded in Man. Format & how do I decode this to get my original format at the PC side.

Many threads on this site already tell you that plain RS232 can't be used over radio links, you can actually buy the radio modules with Manchester coding built-in, which cures the problem.

For a very easy simple cure, try inverting your RS232 (obviously at both TX and RX - if you're using software RS232 it's only a couple of instruction changes), it can help to overcome the problem, but doesn't give the other benefits of manchester coding.

There seems very little sample code available, but you might try https://jap.hu/electronic/codec-v4.0.html.

I'm sorry but what exactly do you mean by 'inverting your RS232' ? And I'm using the Hardware UART...so how do i go abt in this case...

ps: appreciate your quick response
 
I'm a bit confused now...Can Manchester Encoding be implemented in Hardware UART ? Nigel, I saw the codes on the site you mentioned..I think they are all for a Software UART...I need a solution for a H/W UART.. :(
 
Electrix said:
I'm a bit confused now...Can Manchester Encoding be implemented in Hardware UART ? Nigel, I saw the codes on the site you mentioned..I think they are all for a Software UART...I need a solution for a H/W UART.. :(

I have seen applications that use the hardware UART for Manchester coding, but it's rather clumsy and not 100% correct, so it's not usually used.

The inversion I mentioned can be done easily in software, but for the hardware UART you will have to do it in hardware instead. A simple transistor and two resistors is all that's required (on both TX and RX).

The reason it doesn't work is quite simple (I actually found out by using a scope on a receiver a number of years ago), the radio modules aren't DC coupled!. The rest state of the radio system is LOW, but the rest state of the RS232 is HIGH, if you try and hold the radio HIGH it will drop LOW again after a few milliseconds (rather noisely) - it's this that corrupts the RS232. If you invert the RS232 then it's resting state is LOW, and it only goes HIGH for a maximum of 9 bit times, this is short enough to pass through the AC coupling (at least on the modules I've used!).
 
Nigel Goodwin said:
Electrix said:
I'm a bit confused now...Can Manchester Encoding be implemented in Hardware UART ? Nigel, I saw the codes on the site you mentioned..I think they are all for a Software UART...I need a solution for a H/W UART.. :(

I have seen applications that use the hardware UART for Manchester coding, but it's rather clumsy and not 100% correct, so it's not usually used.

The inversion I mentioned can be done easily in software, but for the hardware UART you will have to do it in hardware instead. A simple transistor and two resistors is all that's required (on both TX and RX).

The reason it doesn't work is quite simple (I actually found out by using a scope on a receiver a number of years ago), the radio modules aren't DC coupled!. The rest state of the radio system is LOW, but the rest state of the RS232 is HIGH, if you try and hold the radio HIGH it will drop LOW again after a few milliseconds (rather noisely) - it's this that corrupts the RS232. If you invert the RS232 then it's resting state is LOW, and it only goes HIGH for a maximum of 9 bit times, this is short enough to pass through the AC coupling (at least on the modules I've used!).

Ok, I just tried the inversion scheme on my modules.. its all garbage again in my HyperTerminal window
My transmitter and receiver modules are similar to these
https://www.rentron.com/rf_remote_control.htm

Ok my test set up was like this: PIC 16F73 TX pin connected to pin1 of 7404 and its inverted o/p connected to the Transmitter Data In. I did not bother to connect the RS232 o/p to an inverter..i just gave to the PC serial port. ...ANything wrong abt all this ...
Please suggest something that will work with hardware UART...
 
Electrix said:
Ok my test set up was like this: PIC 16F73 TX pin connected to pin1 of 7404 and its inverted o/p connected to the Transmitter Data In. I did not bother to connect the RS232 o/p to an inverter..i just gave to the PC serial port. ...ANything wrong abt all this ...
Please suggest something that will work with hardware UART...

If you have access to an oscilloscope, I suggest you try comparing the signals at the various points, if you have a double beam scope you can directly compare the transmitter signal and receiver signal.
 
Nigel Goodwin said:
If you have access to an oscilloscope, I suggest you try comparing the signals at the various points, if you have a double beam scope you can directly compare the transmitter signal and receiver signal.

ok..i'll try that out i guess that should make things clear...will follow up later
 
The RF Testing is going to be put on hold now. I have the option of using IR. Now I have these Encoder/Decoder Chips: HT12E & HT12E.
Can I use the these chips to transfer data..(using Hardware UART)without having to write special code for determining the pulse ...as Nigel's tutorials mention..
 
Electrix said:
The RF Testing is going to be put on hold now. I have the option of using IR. Now I have these Encoder/Decoder Chips: HT12E & HT12E.
Can I use the these chips to transfer data..(using Hardware UART)without having to write special code for determining the pulse ...as Nigel's tutorials mention..

No, they transmit a code to turn an output ON or OFF, you can't feed them serial data.

You might try looking at for the kind of encoder/decoder devices you're looking for!.

You could also use the code from https://jap.hu/electronic/codec-v4.0.html that I mentioned earlier, to make your own versions of these chips.
 
Nigel Goodwin said:
Electrix said:
The RF Testing is going to be put on hold now. I have the option of using IR. Now I have these Encoder/Decoder Chips: HT12E & HT12E.
Can I use the these chips to transfer data..(using Hardware UART)without having to write special code for determining the pulse ...as Nigel's tutorials mention..

No, they transmit a code to turn an output ON or OFF, you can't feed them serial data.

You might try looking at for the kind of encoder/decoder devices you're looking for!.

You could also use the code from https://jap.hu/electronic/codec-v4.0.html that I mentioned earlier, to make your own versions of these chips.


The enc/dec chips I mentioned have a Valid TX pin at the receiver side. What I can do is set the address on both tx& rx same..except for one bit on both sides; at recr side this bit will be 1..while on TX side..this bit wil be connected to the TX out of the PIC. So whenever the PIC transmits a 0 Valid Data pin will be at 0 wile a 1 from the PIC TX pins..will make Valid Data Pin as 1. The only problem I expect is that will it support the high baud rate.. will this solution work...
 
Electrix said:
The enc/dec chips I mentioned have a Valid TX pin at the receiver side. What I can do is set the address on both tx& rx same..except for one bit on both sides; at recr side this bit will be 1..while on TX side..this bit wil be connected to the TX out of the PIC. So whenever the PIC transmits a 0 Valid Data pin will be at 0 wile a 1 from the PIC TX pins..will make Valid Data Pin as 1. The only problem I expect is that will it support the high baud rate.. will this solution work...

I don't know if it would work or not, but it's going to be INCREDIBLY slow, each bit you transmit will take an entire packet to send, in fact probably more than that, as I seem to recall the Holtek chips send the packet more than once for reliability.

So, if it's workable, expect to take a few seconds for every single byte!.
 
Status
Not open for further replies.

New Articles From Microcontroller Tips

Back
Top