Writting Manchester line coding

[Nigel Goodwin]

That's FAR, FAR too long - you would need DC coupling for that length of time. Try 100uS instead!.

 

[ahmedragia21]

So you think if i put 100uS delay it would work ?

 

[Nigel Goodwin]

So you think if i put 100uS delay it would work ?

I'll put it this way, it doesn't have any chance at all with 1 second delays.

But, like I said, unless you use somekind of NRZ coding (like Manchester) it's never going to work very well.

 

[ahmedragia21]

ok i wrote now a function which encodes the byte to be sent , can i send the decoded byte using the above scheme ? put delay between every bits ?

 

[Nigel Goodwin]

When you're sending the data, you use the same delay between every bit, in order to maintain a constant baud rate.

 

[notwist]

When the receiver device is waiting for the preamble, "sync byte", or whatever, does it use that signal to derive a clock to sample the signal being sent? or is that not necessary? I'm new to this and am curious exactly what goes on between the uC and receiver when the receiver has a message coming in.

I know that the manchester encoding and decoding can be performed in software by the uC but how is the uC able to receive (or send) the serial data from the transmitter (or receiver)?

 

[Nigel Goodwin]

My tutorial explains how Manchester coding works, it's trivial to transmit (where you would use specific delay times between the bits), but is much more complicated to receive, as the timing doesn't have to be the same, or indeed repeatable.

 

[Brian Hoskins]

When the receiver device is waiting for the preamble, "sync byte", or whatever, does it use that signal to derive a clock to sample the signal being sent? or is that not necessary? I'm new to this and am curious exactly what goes on between the uC and receiver when the receiver has a message coming in.

I know that the manchester encoding and decoding can be performed in software by the uC but how is the uC able to receive (or send) the serial data from the transmitter (or receiver)?

When I wrote the code for my RC5 Receiver, I basically waited for an input pin on the Micro to go low (it's normally high because the IR Receiver inverts the signal) and then I time how long it stays low for. Once the I/O pin has returned high again the Timer value is compared to a set of limits that I made up (basically 20% either side of the time an RC5 pulse "should" be). If the Timer value is within the limits I have defined then I call a processing function which attempts to retrieve all of the data. It synchronises with the data stream and then uses the Timer value to determine when a sample should be taken. In this way the program adapts to signals which might not be timed entirely as the protocol says it should be.

Again, I can't promise you my solution is the best one because like you I'm pretty new to it all as well!!! I attach the code for you to take a look at. You may have to clean up the text formatting. It looks fine in my compiler but won't look the same in notepad.

Brian