Writting Manchester line coding

[ahmedragia21]

hi , im trying to write a manchester code/decode using Keil C with 8051 cuz my RF Tx,RX cant work with DC components like UART ... i read about it but still i need some more info ... ?

 

[Nigel Goodwin]

Check my PIC tutorial assembler routines, they describe how it works.

 

[ahmedragia21]

yea but do you think i can write it using C codes ?

 

[Brian Hoskins]

I recently wrote a C program that will receive an RC5 data stream so you could take a look at that for ideas if you want. I'm not a professional C programmer so there's undoubtedly ways you could improve on my technique, but my program works so that's a start. I'm still writing the transmitter side software.

Brian

 

[Blueteeth]

You can write using any code you desire.

If you have a hardware UART you could use that. As the start/stop bits are balanced anyway (0-1) you could encode each byte you wish to send as 2 manchester bytes. All you would need is a lookup table with 16 entries and you split your byte up into two 4-bit nibbles, encode each one seperately, then send each one.

That way you can also include preamble and sync bytes, as these violate the manchester coding and so cannot be mistaken as data.

Using the 'case' statement in C would probably be easiest.

0000 -> 01010101
0001 -> 01010110
...
0110 -> 01101001
1111 -> 10101010 etc..

Using the hardware UART means you do'nt have to bit-bang, plus it could work quite quickly. The only problem with it is, the statr and stop bits in the stream, once decoded prodcuce a '1' every 4 data bytes. But that could be used to synchronise the stream.

Blueteeth

 

[ahmedragia21]

Brian , would you please send it to xgameprogrammer@hotmail.com ?
thanks for the inputs , i've a problem .. when not sending
anything the RX just recieves noise signals dont know from where and outputs bits .. how to remove that ? i put a 10uF cap .. still didnt help

 

[Blueteeth]

Perhaps a squelch control? If your RX has a signal strength pin, you can use that to check whether or not the transmitter (or something on that frequency) is transmitting...and then use that to turn on a transistor to 'connect' the output of the RX to the input of your micro.

That is a bit of a dirty solution. What you should really be looking for is a 'sync byte' in your reciever. That is something like 00001111 sent twice. I do'nt think noise could trigger that too easily. Your micro in the reciever should constantly check what is being recieved and look for that pattern.

There is also a bit of analogue you could do. Because your Tx/Rx are AC coupled, I would use a schmitt trigger with an input bias of VCC/2 and a cap.
That is....Rx output -> 1uF cap -> centre of voltage divider -> schmitt trigger.

The schmitt trigger will curb the noise you are recieving, and will clean up the data signal. Effectively it is a data slicer with hysteresis...with no feedback or anything, its just basic, but it should help.

Blueteeth

 

[Nigel Goodwin]

As regards the noise, a correctly written Manchester routine over comes that problem as well - again, check the writeup of my tutorial, which explains the specific format used.

Bear in mind an FM receiver, with no signal, will output white noise.

 

[ahmedragia21]

thanks alot blueteeth

Nigel , its an ASK tx,rx

 

[ahmedragia21]

I wrote this code in Keil C 8051 and still have a problem , like synchronization between tx ,rx

// code for tx
void TX_Send(unsigned char a )
{
int i;
int j;

for (i = 0; i < 8; i++) {
 b[i] = a & 1; a = a >> 1;
 P2_0=b[i]; // b[8] , and P2.0 
DELAY_Second();
}


// code for RX

 for (i = 0; i < 8; i++) {
  b[i]=P1_0;   // read the bits and put them in an array
DELAY_Second();
     }

for (c = 0; c < 8; c++) {
  a|=b[i]<<c;  // decode bits into one byte

    }

 

[Blueteeth]

It looks to me as though you are doing 'bit level' decoding'. That is, you are getting your manchester 'chips' in (sub bits) and getting normal bits out.

The problem is you don't know where a byte begins and where a byte ends...thats where framing comes into its own. As I said before, its a great idea to have a sync byte that purposefully violates the manchester coding algorithm, whilst still being 'DC balanced'. The simplest would be 00001111. Note you can't decode that with your software, as it sin't strictly speaking man coding.

I would send a packet as follows:

<preamble><syncbyte><payload (your data)><end of transmittion byte>.

Preamble: A series of 0's and 1's. You're really just sending all 0's or all 1's through a manchester encoder, as 0 = 0-1, and 1 = 1-0. This is purely to wake up your RF reciever, and to get it nicely DC balancing before you start sending any real data. Your Rx micro can ignore this if you wish, but not only can it sort out the analogue side, it can also 'train' your reciever (micro) to get in sync. Note: because there is ALWAYS a bit transition in manchester coding...you could encode 0101 which would be 01100110. That way the only transistions in the bit stream are in the 'middle' on the coding. There will always be transistions there regardless of what data you send.

Sync byte:
As before 00001111 *after* manchester coding. This should be sent 'as is'. It is DC balanced, cannot be mistaken for data is all your data is properly coded, this isn't. It tells your reciever that not only is it properly syncronised, but also that the bits after this are data.

Payload: Your data, man encoded.

End of transmission: this is optional, but might be handy if you plan on sending varying lengths of packet. It tells your reciever that the data has ended, and it can go back to waiting for a sync again. Or power down the reciever.

Of course you can add otrher types of header bytes, but you'll want to keep the preamble and sync. Premable can be quite long, I would start off making it a good 10 bytes or so..to make sure everything is in sync. You can always shorten it later until you run into problems.

Good luck..soory for the long post...got pretty obsessed with RF comms in my uni projects years ago. My head is still full of various channel coding/line coding and error correction techniques. Most of which can applied from the humblest ASK 2.4kb/s system all the way up to 5.8Ghz.

Blueteeth

Sounds complicated, but once done, it proves to be pretty damn reliable (well, as far as RF comms goes anyway).

 

[ahmedragia21]

would you please clarify the problem with sending a byte like 10110100 thru the RF tx , rx module ? what happens and why its not working ?
i send it using delay between bits ...

 

[Nigel Goodwin]

would you please clarify the problem with sending a byte like 10110100 thru the RF tx , rx module ? what happens and why its not working ?
i send it using delay between bits ...

Like I've said already, my tutorial explains why, the modules aren't DC coupled.

Get a double beam scope, put one beam on the transmitter input, and one on the receiver output, see what happens!.

 

[ahmedragia21]

ok nigel, i wrote a function that encoded and decodes a byte , how do i transmit it then using which way ? bear in mind that i want to link PC -> uC --> Rf link ---> uC --> PC
i dont have many hardware uarts just one for every uC ...

 

[Nigel Goodwin]

You don't require hardware USART's for the links to the RF modules, in fact it would be a bad choice to try and use them. Obviously for the PC links you could use them (and it's probably a reasonable idea to).

Bear in mind the need to packet your data, you can't send a continuous stream, and your transmitting PC should either send in packets with decent gaps between them, or use handshaking with the Manchester encoder.

 

[ahmedragia21]

The pc will use hardware uart using hyperterminal to send the byte to be sent ... what's wrong with this ?

 

[Nigel Goodwin]

The pc will use hardware uart using hyperterminal to send the byte to be sent ... what's wrong with this ?

Nothing, it was UART's in the micro-controllers I was talking about.

 

[ahmedragia21]

i really cant understand this ! sorry please be patient
why when i send this sequence like 0 delay 1 delay 1 delay 0 delay 1 delay 0 delay 0 delay 1 the RF link doesnt send it ? i dont have a scope really ...
I think there's no DC while sending this sequence ...

 

[Nigel Goodwin]

How long is the delay you're sending?, if it's too long the AC coupling stops it working.

Borrowing a scope would really help you see what's going on.

 

[ahmedragia21]

The delay is 1 second