Manchester decoding (BPSK), variable frequency

Hi all.  Need to figure out the best way to decode 1200bps Manchester data
words sent according to the DALI protocol (IEC 60929 or its newer
replacement) on a small micro.  One issue is that the bit rate can vary by
as much as +/- 10% (1091bps - 1391bps); I suspect that a PLL won't be able
to synchronize quickly enough to avoid data loss, especially since the
phase of the clock can change between data words.

Prior posts in this group talked about Costa's loop and using discrete
logic, but that doesn't seem feasible given the highly variable clock
rate.

I'm thinking about using a state machine to look at times between edges to
decode individual bits. 
http://www.atmel.com/dyn/resources/prod_documents/doc9164.pdf has a
sampling method that can be made to work, as long as I can distinguish T
and 2T.  I'll also need to handle the stop bits.

That being said, for noise immunity I feel that I should use some sort of
digital low pass filter before the input signal gets to the state machine.

Can I just convert the 1-bit signal received by the micro to n bits, use an
ordinary digital filter (for example single pole recursive or FIR or
whatever), then re-quantize the output back down to 1 bit?

jneudorf wrote:
> Hi all.  Need to figure out the best way to decode 1200bps Manchester data
> words sent according to the DALI protocol (IEC 60929 or its newer
> replacement) on a small micro.  One issue is that the bit rate can vary by
> as much as +/- 10% (1091bps - 1391bps); I suspect that a PLL won't be able
> to synchronize quickly enough to avoid data loss, especially since the
> phase of the clock can change between data words.
> 
> Prior posts in this group talked about Costa's loop and using discrete
> logic, but that doesn't seem feasible given the highly variable clock
> rate.
> 
> I'm thinking about using a state machine to look at times between edges to
> decode individual bits. 
> http://www.atmel.com/dyn/resources/prod_documents/doc9164.pdf has a
> sampling method that can be made to work, as long as I can distinguish T
> and 2T.  I'll also need to handle the stop bits.
> 
> That being said, for noise immunity I feel that I should use some sort of
> digital low pass filter before the input signal gets to the state machine.
> 
> Can I just convert the 1-bit signal received by the micro to n bits, use an
> ordinary digital filter (for example single pole recursive or FIR or
> whatever), then re-quantize the output back down to 1 bit?

What is your signal to noise ratio?  IIRC, clean Manchester can be 
decoded with just timers and logic -- essentially you're not looking out 
more than a bit period to reconstruct the clock.  I suspect that this is 
your "state machine to look at times between edges".

Toss some false edges in there and the job gets harder, though.  You 
could open up your PLL bandwidth sufficiently to track the anticipated 
variation in the clock rate.  This would let you effectively average the 
clock rate over five to ten bits or so, which would increase your noise 
margins.

Yes, you can convert that one-bit signal to several, digital filter, 
then re-quantize.  I can think of a couple of different ways that you 
could do this that would leverage the fact that the incoming data is one 
bit, and save yourself some clock cycles.

Should you use a regular digital filter, the optimal filter is probably 
very close to a boxcar that's 1/2 of a bit-period long -- that's the 
matched filter for the short pulses.  You could probably come pretty 
close with an IIR filter whose impulse response matches that 1/2 clock 
pulse as close as you can get.

You _are_ aware that if you really have noise you'll be throwing away 
valuable information by just bit slicing things into one bit, yes?

Note that Manchester coding is just minimum shift keying with a really 
low carrier frequency.  This doesn't help you in your case because the 
data clock varies so much, but it's a fun bit of trivia.

-- 
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

Tim, thanks for responding.

>jneudorf wrote:
>> Hi all.  Need to figure out the best way to decode 1200bps Manchester
data
>What is your signal to noise ratio?  IIRC, clean Manchester can be 
>decoded with just timers and logic -- essentially you're not looking out 
>more than a bit period to reconstruct the clock.  I suspect that this is 
>your "state machine to look at times between edges".

I don't know the SNR yet; I haven't even seen physical equipment.  That
being said, I'm sure that the engineers at work will make something with
non-zero noise, and some sort of filtering could come in handy.  DALI is
connected to switching power supplies, so it probably won't be perfect.

>Toss some false edges in there and the job gets harder, though.  You 
>could open up your PLL bandwidth sufficiently to track the anticipated 
>variation in the clock rate.  This would let you effectively average the 
>clock rate over five to ten bits or so, which would increase your noise 
>margins.

Individual data packets are only 19 bits long (16+1 start+2 stop), and
don't seem to necessarily be in phase with previous packets.  I'm not
deeply familiar with PLLs, but would it really be possible to synchronize
using one over that few bits?

I think that I need to receive even the very first packet transmitted, as
long as its bit times are close, so I'm tentatively putting aside the idea
of using a PLL.

>Yes, you can convert that one-bit signal to several, digital filter, 
>then re-quantize.  I can think of a couple of different ways that you 
>could do this that would leverage the fact that the incoming data is one 
>bit, and save yourself some clock cycles.

That sounds interesting.  In the past I've mostly just used cookbook code
for single pole filters, and one 5 pole elyptic filter.

>Should you use a regular digital filter, the optimal filter is probably 
>very close to a boxcar that's 1/2 of a bit-period long -- that's the 
>matched filter for the short pulses.  You could probably come pretty 
>close with an IIR filter whose impulse response matches that 1/2 clock 
>pulse as close as you can get.

That sounds very useful.

>You _are_ aware that if you really have noise you'll be throwing away 
>valuable information by just bit slicing things into one bit, yes?

I suppose on a powerful enough system I could take an entire filtered
candidate packet and multiply (?) it by a reconstructed clock and from
there make a decision about the maximum likelyhood original packet, but my
original thought was that that would be too computationally intensive. 
That being said, in retrospect, given a histogram of times between edges,
it should be possible to calculate the clock period (with sub-sample
resolution) and likely phase.

The state machine idea was based on what other people have done.

What are you suggesting? (oh, and what is bit slicing in this context.. I
mostly found 1-bit processors during my net search)?

>Note that Manchester coding is just minimum shift keying with a really 
>low carrier frequency.  This doesn't help you in your case because the 
>data clock varies so much, but it's a fun bit of trivia.
>
>-- 
>Tim Wescott
>Control system and signal processing consulting
>www.wescottdesign.com
>

jneudorf wrote:
> Tim, thanks for responding.
> 
>> jneudorf wrote:
>>> Hi all.  Need to figure out the best way to decode 1200bps Manchester
> data
>> What is your signal to noise ratio?  IIRC, clean Manchester can be 
>> decoded with just timers and logic -- essentially you're not looking out 
>> more than a bit period to reconstruct the clock.  I suspect that this is 
>> your "state machine to look at times between edges".
> 
> I don't know the SNR yet; I haven't even seen physical equipment.  That
> being said, I'm sure that the engineers at work will make something with
> non-zero noise, and some sort of filtering could come in handy.  DALI is
> connected to switching power supplies, so it probably won't be perfect.
> 
>> Toss some false edges in there and the job gets harder, though.  You 
>> could open up your PLL bandwidth sufficiently to track the anticipated 
>> variation in the clock rate.  This would let you effectively average the 
>> clock rate over five to ten bits or so, which would increase your noise 
>> margins.
> 
> Individual data packets are only 19 bits long (16+1 start+2 stop), and
> don't seem to necessarily be in phase with previous packets.  I'm not
> deeply familiar with PLLs, but would it really be possible to synchronize
> using one over that few bits?
> 
> I think that I need to receive even the very first packet transmitted, as
> long as its bit times are close, so I'm tentatively putting aside the idea
> of using a PLL.

Not over that short of a packet, no.  If you only have the one start bit 
to help you get up to speed you can't do much with anything that 
remembers the phase & frequency over any span of time.

>> Yes, you can convert that one-bit signal to several, digital filter, 
>> then re-quantize.  I can think of a couple of different ways that you 
>> could do this that would leverage the fact that the incoming data is one 
>> bit, and save yourself some clock cycles.
> 
> That sounds interesting.  In the past I've mostly just used cookbook code
> for single pole filters, and one 5 pole elyptic filter.

One: treat the thing like a CIC, and increment a counter whenever you 
see a '1', and decrement it whenever you see a '0'.  Then compare the 
count values every bit period with a 2's compliment subtract _with 
rollover_ -- the resulting number will be an average of what happened 
that bit period.

Two: if you have spare code space, and if you're not oversampling by 
much shift the ones & zeros into a word, then use a lookup table to tell 
you what the count is (i.e. 8x oversampling would give you an 8-bit 
word, which you can us as an index into a 256-bit array of signed chars 
that'll give you a signed value equivalent to the first method).

There are certainly more, if you think hard.

>> Should you use a regular digital filter, the optimal filter is probably 
>> very close to a boxcar that's 1/2 of a bit-period long -- that's the 
>> matched filter for the short pulses.  You could probably come pretty 
>> close with an IIR filter whose impulse response matches that 1/2 clock 
>> pulse as close as you can get.
> 
> That sounds very useful.
> 
>> You _are_ aware that if you really have noise you'll be throwing away 
>> valuable information by just bit slicing things into one bit, yes?
> 
> I suppose on a powerful enough system I could take an entire filtered
> candidate packet and multiply (?) it by a reconstructed clock and from
> there make a decision about the maximum likelyhood original packet, but my
> original thought was that that would be too computationally intensive. 
> That being said, in retrospect, given a histogram of times between edges,
> it should be possible to calculate the clock period (with sub-sample
> resolution) and likely phase.
> 
> The state machine idea was based on what other people have done.
> 
> What are you suggesting? (oh, and what is bit slicing in this context.. I
> mostly found 1-bit processors during my net search)?

Argh.  Data slicing, bit slicing -- running the analog value into a 
comparator and getting a one or a zero out, when what went in was an 
analog voltage.

-- 
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

> Argh. =A0Data slicing, bit slicing -- running the analog value into a
> comparator and getting a one or a zero out, when what went in was an
> analog voltage.

Thank you.  Time to actually design a filter now :)

Jason

oh.  finally looked up boxcar filter.  Implementation is trivial :)