Forums

Viterbi Synchronization

Started by jeffsimp August 30, 2007
This is a follow up question to the first posting by another member
regarding this issue.  I am having the same problem using a Viterbi
Decoder.  I am implementing the design in an FGPA using an IP core that is
provided by Altera. One of the proposed solutions referred me to the
following link:

http://tmo.jpl.nasa.gov/progress_report/42-128/128E.pdf

The paper discusses node synchronization and described the exact problem
that I am having, however after talking with Altera's Technical support
staff, they told me that I cannot use the BER or normalization rate, which
is generated by the their IP core, as a method to synchronize my data. 
Their core uses the common approach to decode the incoming data stream,
then re-encode it and compare it against a delayed version.  

The way I understand this concept is, when the Viterbi Decoder is
synchronized it should not have to normalize any of the branch metrics
therefore the normalization rate should be very low.  The same is true for
the BER.  So I figured that I can just determine an appropriate threshold
value and monitor when the BER and normalizations exceed the threshold and
auto adjust my incoming data accordingly to ensure that I'm always
synchronized.  Makes sense to me, but Altera says that these parameters
are only good for estimating channel quality and not synchronizing.

Xilinx has a comparable Viterbi IP core that claims I can use BER and
normalizations for my purpose. 

http://www.xilinx.com/ipcenter/catalog/logicore/docs/viterbi_synchronization.pdf

Am I missing something here?

Any input is greatly appreciated.
Jeff




On Aug 30, 7:00 am, "jeffsimp" <J...@Ulyssix.com> wrote:

> The way I understand this concept is, when the Viterbi Decoder is > synchronized it should not have to normalize any of the branch metrics > therefore the normalization rate should be very low. The same is true for > the BER. So I figured that I can just determine an appropriate threshold > value and monitor when the BER and normalizations exceed the threshold and > auto adjust my incoming data accordingly to ensure that I'm always > synchronized. Makes sense to me, but Altera says that these parameters > are only good for estimating channel quality and not synchronizing. > > Xilinx has a comparable Viterbi IP core that claims I can use BER and > normalizations for my purpose.
My experience has been that the Viterbi normalization rate has a fairly broad distribution and is very dependent on the signal environment, so a single threshold value is not adequate for determining node sync under all conditions. If your signal environment is well constrained however you may find that one value is OK. You may also find that a more complex evaluation of the normalization rate will work. I've used re-encode & compare measurements successfully in a wide range of applications though and it's fairly easy to implement. Eric
>On Aug 30, 7:00 am, "jeffsimp" <J...@Ulyssix.com> wrote: > >> The way I understand this concept is, when the Viterbi Decoder is >> synchronized it should not have to normalize any of the branch metrics >> therefore the normalization rate should be very low. The same is true
for
>> the BER. So I figured that I can just determine an appropriate
threshold
>> value and monitor when the BER and normalizations exceed the threshold
and
>> auto adjust my incoming data accordingly to ensure that I'm always >> synchronized. Makes sense to me, but Altera says that these
parameters
>> are only good for estimating channel quality and not synchronizing. >> >> Xilinx has a comparable Viterbi IP core that claims I can use BER and >> normalizations for my purpose. > >My experience has been that the Viterbi normalization rate has a >fairly broad distribution and is very dependent on the signal >environment, so a single threshold value is not adequate for >determining node sync under all conditions. If your signal environment >is well constrained however you may find that one value is OK. You may >also find that a more complex evaluation of the normalization rate >will work. I've used re-encode & compare measurements successfully in >a wide range of applications though and it's fairly easy to implement. > >Eric > >
--------------------------------------------------------------- Thanks Eric, My plan is to determine a BER threshold based on measured data. I use a Bit Error Rate Test(BERT) machine that allows me to inject 'x' dB of noise onto my encoded stream. My board is expected to perform in within 1 dB of theoretical with Eb/No ranging from 12 dB down to 2 dB. I plan to determine a threshold for BER and normalization based on taking an average of these metrics over 'x' amount of clock cycles when I'm running at Eb/No = 2dB. This should be my worst case scenario then I can compare it to measured thresholds at different noise levels. Does this sound similar to some of the approaches you have used in the past? Jeff
On Aug 30, 6:12 pm, "jeffsimp" <J...@Ulyssix.com> wrote:
> >On Aug 30, 7:00 am, "jeffsimp" <J...@Ulyssix.com> wrote: > > >> The way I understand this concept is, when the Viterbi Decoder is > >> synchronized it should not have to normalize any of the branch metrics > >> therefore the normalization rate should be very low. The same is true > for > >> the BER. So I figured that I can just determine an appropriate > threshold > >> value and monitor when the BER and normalizations exceed the threshold > and > >> auto adjust my incoming data accordingly to ensure that I'm always > >> synchronized. Makes sense to me, but Altera says that these > parameters > >> are only good for estimating channel quality and not synchronizing. > > >> Xilinx has a comparable Viterbi IP core that claims I can use BER and > >> normalizations for my purpose. > > >My experience has been that the Viterbi normalization rate has a > >fairly broad distribution and is very dependent on the signal > >environment, so a single threshold value is not adequate for > >determining node sync under all conditions. If your signal environment > >is well constrained however you may find that one value is OK. You may > >also find that a more complex evaluation of the normalization rate > >will work. I've used re-encode & compare measurements successfully in > >a wide range of applications though and it's fairly easy to implement. > > >Eric > > --------------------------------------------------------------- > Thanks Eric, > My plan is to determine a BER threshold based on measured data. I use a > Bit Error Rate Test(BERT) machine that allows me to inject 'x' dB of noise > onto my encoded stream. My board is expected to perform in within 1 dB of > theoretical with Eb/No ranging from 12 dB down to 2 dB. I plan to > determine a threshold for BER and normalization based on taking an average > of these metrics over 'x' amount of clock cycles when I'm running at Eb/No > = 2dB. This should be my worst case scenario then I can compare it to > measured thresholds at different noise levels. Does this sound similar > to some of the approaches you have used in the past? > > Jeff
Another idea to consider is the use of a saturating up/down counter followed by a threshold. This can be a useful way to detect a change in distribution. The increment and decrement values need not be the same. John
On Aug 30, 3:12 pm, "jeffsimp" <J...@Ulyssix.com> wrote:

> My plan is to determine a BER threshold based on measured data. I use a > Bit Error Rate Test(BERT) machine that allows me to inject 'x' dB of noise > onto my encoded stream. My board is expected to perform in within 1 dB of > theoretical with Eb/No ranging from 12 dB down to 2 dB. I plan to > determine a threshold for BER and normalization based on taking an average > of these metrics over 'x' amount of clock cycles when I'm running at Eb/No > = 2dB. This should be my worst case scenario then I can compare it to > measured thresholds at different noise levels. Does this sound similar > to some of the approaches you have used in the past?
That sounds like a good start and similar to the research we did. If your experience is anything like ours however, you'll find that the range of values you get from the normalization metric is quite wide, and the threshold you determine at Eb/N0 = 2dB will not work well stronger SNR. That's why we decided not to use the normalization + threshold approach. Eric