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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to