[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] A BERT Block with Offset Compensation

From: Jeff Long
Subject: Re: [Discuss-gnuradio] A BERT Block with Offset Compensation
Date: Sun, 12 Oct 2014 08:09:28 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1

Hi Dan,

On 10/12/2014 03:48 AM, Dan CaJacob wrote:
I am working on a GR block that will test two incoming bit streams (one
a reference and one a received result) for equality and return the
estimated BER.  Blocks already exist that do this, but they assume the
streams are aligned.  My block will allow and correct for offsets in the
bit streams.  The goal is to use this with existing physical comm
systems - i.e. Generate and transmit a PRBS with GR and USRP to a legacy
comm system, capture the RX's data and clock, bring them back into the
flowgraph and compare the reference data to the received data to get
estimated BER.

My block does work for streams that are aligned, but I am having
difficulty dealing with misalignment.  Somehow, the blocks needs to have
more of the reference signal (if not all of it) to compare against the
smaller segments of received data every time the work function is called.

I see several possible approaches and the purpose of this email is to
solicit advice from those with more experience than I.

1) Use set_history() and history() to good effect.
I've tried this, but haven't gotten the desired results.  This may be
misunderstanding of the feature on my part, but I think the fundamental
problem is comparing two streams of equal length when one is offset from
the other.

set_history() just makes sure that a block's work functions get enough data to work on.

Have you tried a delay block in the reference signal path?

2) Accumulate a specified window of reference signal before comparing to
received signal.
This approach would accumulate the reference signal in a buffer that
would be used for comparison.  Until the work function calls accumulated
some threshold of reference data in the buffer, the received signal
would be passed without comparison or BER calculation.  Once the
threshold is met, the small chunks of received data would be compared
against the much larger (and growing, but limited to repeat length)
reference buffer.

I have not implemented this approach yet, but I suspect it will work as
long as the window is picked reasonably - the safest bet being the
length of the PRBS used in the test.

The disadvantage of this method is that the PRBS may be very long, but
the sample rate may be slow and therefore there would be a long waiting
period as the reference buffer fills before the test even truly begins.

3) Variation on previous approach.
To alleviate the setup time of filling the reference buffer, perhaps we
could generate the whole PRBS in the block constructor.  The block would
then have a "menu" of standard PRBS's commonly used int BER testing.
We'd probably want to make a companion PRBS source block with the same
menu for the transmitting segment.

If anyone has any thoughts on this, I'd appreciate the input.  This is
one of those problems that's pretty simple in a standalone python
program, but gets a little more complicated when implemented in GR.  But
there's a lot of benefit in the implementation too.

To anticipate a few questions: For my testing, I have been using no
hardware, just a GLFSR source with skiphead to implement offset (delay
block adds zeros, which get interpreted as bit errors).  I use a
separate sequence to modify the stream with a known number of errors for
testing.  As I said, the block works perfectly with no offset.

Alignment is implemented by shifting the reference sequence relative to
the received sequence, calculating the residual between the two at each
step and using the minimum value of that residual as the current error
count.  This should be the point where the sequences are most ideally
aligned, which works as long as the error rate is relatively low.  The
reason alignment doesn't work in my current implementation is because
the reference and received sequences are the same length, so if there is
any offset, even when aligned, it looks like there are n errors where n
is the offset between the sequences.  So, the reference sequence needs
to be longer than the reference sequence, and ideally approaching the
length of the PRBS itself to correct for any offset.

Thanks for suffering through to the end.

Very Respectfully,

Dan CaJacob

Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]