Quick digital receiver for Manchester encoded data?

Question

I want to implement a digital Manchester encoded data receiver. The application is not dissimilar to the KeeLoq system. That is, there is no time for long link training - I want the receiver to recover the clock and parse the data from a single packet, without relying on anything before or after it. Since this is a digital receiver, the receiver has 100s of samples worth of history to re-process to allow it to do this.

I am finding clock recovery harder than expected. Averaging the number of samples between each transition and taking this as the half-bit period works in many cases, but simple simulations show that with certain payloads (i.e. those with lots of transitions) this average is pushed too high. In any case, skewing of the estimated half-bit period due to these, even when it still works, will surely mean the receiver is less robust than it could be. I have a preamble which facilitates clock recovery, but I can see (with simulation) in some cases it will not be long enough and the average is skewed too much by the full-bit periods in the payload. My application is unusual in that the underlying line rate is very low, so efficiency and latency is important.

There must be some way to take advantage of the bimodal nature of the period distribution to make a very reliable estimator, but I can't think how to do it efficiently.

What is a good approach to a digital Manchester receiver, with very low latency link establishment?

By efficiently, I mean computationally - I can probably do a brute-force search comparing the differences between normalised histograms, but I wondered if there was a better way.

EDIT: It occurred to me just now that I don't need to match a distribution to a histogram, because the Manchester encoding by nature applies another constraint: the distance between the peaks is related to the peak bin itself. So all I have to do is find the highest peak in the histogram, and then determine whether I have found the half or full width interval, by looking at the bin values x2 above or 1/2x below. I will prototype this and see if it works, but of course leave the question open for better ideas!

Answer 1

Sampling asynchronously is probably not the best way to deal with this because the sample rate is only a few times higher than the data clock rate. It's Manchester encoding and the main bonus is that you get the clock for free (well, almost) and it's dead easy to make an edge detection circuit from an exor gate and a small delay: -

Here you get a pulse for each edge present in the signal and, if you set a counter running that is maybe 16 times higher than the data clock rate you can position your sampling point at count number 8.

At that point carry on counting and if you don't receive a counter reset (due to lack of a clock pulse) you sample the data at count 24 for the next bit. Manchester encoding is more accurate than asynchronous UART data because clock is embedded into the data and you get far more transistions than can be expected with plain ordinary asynchronous data.

Here's what you are proposing and note the error you can get if your fast clock is only 4 or 8 times the data clock rate: -

I've drawn a red arrow where asynchronous data timing starts to hit a problem - UARTs will sync up their clock on every edge detection thus always minimizing this error.

I've implemented this type of system in FPGAs running non-manchester encoded signals (no embedded clock and thus far fewer clock edges) at speeds up to 50 odd Mbpsec. I've used data scrambling to enhance the number of clock edges but manchester decoding should be a breeze.