1
\$\begingroup\$

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!

\$\endgroup\$
  • \$\begingroup\$ Does the packet contain leading clock pulses before the data kicks in? \$\endgroup\$ – Andy aka Nov 13 '15 at 16:11
  • \$\begingroup\$ It sounds like you're saying you don't know what the bit rate is. Is that true? Autobauding is a different issue from just synchronizing. \$\endgroup\$ – Nick Johnson Nov 13 '15 at 16:22
  • \$\begingroup\$ Are you doing edge detection? \$\endgroup\$ – user59864 Nov 13 '15 at 17:48
  • \$\begingroup\$ @Andy, Yes I have a preamble but I would prefer not to make it longer (edited the question accordingly) \$\endgroup\$ – sebf Nov 13 '15 at 18:11
  • \$\begingroup\$ @Nick, Thats right. The clock will be in a relatively narrow range but I am decoding with asynchronous sampling at a relatively low rate, so I'd like to estimate the expected interval with as much accuracy as possible. \$\endgroup\$ – sebf Nov 13 '15 at 18:11
1
\$\begingroup\$

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: -

enter image description here

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: -

enter image description here

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.

|improve this answer|||||
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.