discuss-gnuradio
[Top][All Lists]
Advanced

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

[Discuss-gnuradio] A BERT Block with Offset Compensation


From: Dan CaJacob
Subject: [Discuss-gnuradio] A BERT Block with Offset Compensation
Date: Sun, 12 Oct 2014 03:48:40 -0400

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.

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

reply via email to

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