Relative merits of synchronization techniques

GNU Radio
1

I’d like to hear your thoughts comparing “center of goodness” vs. “zero
crossing adjust” techniques for recovering bit timing and deframing in
an oversampled NRZ sample stream (I’m sure there are better names for
these algorithms!)

Take an incoming sample stream which represents an 8X oversampled NRZ
stream of 0s and 1s. This would mean there are 8 samples to each baud,
and you need to pick at which point 0-7 you make the decision. A known
sync code is sent first.

In gr_simple_correlator, you maintain eight “trial” shift registers,
each of which gets shifted into it a different bit in the sequence of
eight.

Then the shift register is compared to the sync code, and if it’s within
a certain hamming distance, you note it as the start of goodness. The
first shift register to not meet the hamming distance threshold is
considered the end of goodness. The “center of goodness” metric is then
the modulo average of these two points, and is used as the decision
point to convert the oversampled stream into a symbol stream. (Did I
get that right?)

The above both recovers clock/symbol timing and “start of frame” in the
same operation.

The alternative, simpler technique I’ve used in the past is to use zero
crossings of the oversampled stream to estimate the center of the baud
period, and slice there. This assumes the filtering ahead of the
sampling makes the center between the crossings the best place to slice,
and that there are sufficient zero crossings to keep clock skew from
causing the slice decision to move out too far from the center.

Once the bit timing is established the chosen bits are shifted into a
single shift register, and when the sync code is seen (within a certain
hamming distance), you are at the start of a frame.

The former technique appears more general, less reliant on prior
filtering, and immune to long strings of 1s or 0s. On the other hand,
the latter technique is simpler, requires fewer calculations and less
memory.

So if the sample stream is known to have sufficient zero crossings and
has been properly filtered, do you see any hazards to going with the
latter technique?

-Johnathan

2

Johnathan C., el 09/06/06 13:08:

So if the sample stream is known to have sufficient zero crossings and
has been properly filtered, do you see any hazards to going with the
latter technique?

If “sufficient” is really sufficient, then it should be safe. I have
implemented
circuits using this technique (we called it a “digital PLL”) without
problems
(using return-to-zero encodings, though).

–
Miguel Bazdresch Sierra

3

So if the sample stream is known to have sufficient zero crossings and
has been properly filtered, do you see any hazards to going with the
latter technique?

Looking for zero crossings doesn’t work as well when you have a low SNR,
or you have multipath. Multipath can make the bits non-symmetric,
resulting in an optimum sampling point which is not centered between
zero crossings.

I would suggest you look at the bit-timing we use in the ATSC code or in
the current gmsk code (which doesn’t use a correlator).

Matt

4

The former technique appears more general, less reliant on prior
filtering, and immune to long strings of 1s or 0s. On the other hand,
the latter technique is simpler, requires fewer calculations and less
memory.

So if the sample stream is known to have sufficient zero crossings and
has been properly filtered, do you see any hazards to going with the
latter technique?

Having both techniques available to GNU Radio users seems like a nice
thing. And a zero-crossing block would also be useful for receiving
“async” as opposed to “sync” serial transmissions (that have no frame
sync code, just a start bit on each byte).

But since we already have a block that does this function reliably for
synchronous communications, adding a second way seems like premature
optimization, unless you have a specific application on a specific PC
that is failing to keep up with realtime.

Right now I would put my effort into something else – like a block
that we don’t have a good implementation of, or a higher level
function like an easy to use and flexible “scanner-like” GUI.

John