Recovering clock from manchester

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am wondering if anyone knows how to recover the clock from a stream of manchester encoded data. I have a AT90S8515 micro and am able to find all edges but am unsure of how to get the clock back out.

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm just guessing on this myself since I am not a manchester expert, but I believe the system idles at a low state.

look for the first rising edge, that is the start of the start bit, look for the falling edge, and that is the 50% point of the first bit.

I'm not sure what you mean by recover a clock - do you just want to decode the transmission or do you want to find the clocking speed for some purpose, or do you want to sync up another actual pulse train with the manchester stream ?

if you just want to measure it, that initial half bit is all you need - time it, and do some calcs to get the frequency.

if you want to recover the transmission, see the appnote on i/r remote control - that has algorithm, it is just sampling using that initial time period as the basis to find the rest of the bits.

if you want to generate another clock, I wouldn't use the avr at all, I would build a circuit to generate a narrow pulse on either edge of the manchester, use that to toggle a flipflop so you have the same frequency as the manchester clock, and then use that in a pll circuit to maintain the clock when the manchester is not actually being transmitted.

alternatively, just measure the start bit, as above, then use that delay to set the timer into toggle mode and output an approximation of the clock.

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Toby!

About manchester coding:
Both (high and low) idle states are possible.
The coded signal consists of two frequencies: a row of '1' (or '0') generates f, changing the state ('1' -> '0' or '0' -> '1') generates f/2.
BIts are strobed out with f/2.

So to get syncronized you have to wait until you get a pulse (or pause) with f/2. The rising edge of this pulse is a '1' in the decoded signal, the falling edge is '0'. The following bits are strobed out with the expected f/2 from this edges. Wether you find a rising or falling edge at the expected time your decoded signal is '1' or '0'.
I hope that was what your question was about.

Best regards,
Klaus

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Toby,

I've played around with decoding SPDIF digital audio data, which if I'm not mistaken, is similar to Manchester. ie f and f/2 as Klaus pointed out. I did this with discrete ICs because the bit rate was too fast for my micros to handle.
My question is: If your data rate is easily handled by a micro, then why do you need to extract the clock at all.
This would normally only be a requirement if implementing your project with discrete ICs, where a clock signal would be required to clock data into a serial to parallel shift register.
If implementing the project with a single micro, your main task is to extract the data by firstly looking for the start bit, then analysing the data bits to determine whether they are f or f/2.
ie. if there is a transition in the middle of the data bit, then it's f/2. If there's no transition then it's f.
Remember, I'm assuming that Manchester is similar to SPDIF.
I'm sure someone will correct me here if I'm wrong.
So there's no real need to extract the embedded clock, if all you really want is the actual data.
You do, of course, need to know what the clock frequency/baud rate is, in order to determine exactly where in time you will sample your data.
eg. To determine if there has been a transition half way through your data bit, you would time your sample point to occur at the 3/4 position in the data bit.
SPDIF is polarity insensitive, so it's the change in state you're looking for, not a specific 0 or 1 level.
I figure the same applies to Manchester.
Anyway, I've written enough for a short story or paper weight even.

Cheers Jack