Dan, The other thread on pulling data from vector_sinks and vector_probes has reminded me of a clever way to resolve this.
1) Write a simple function that accepts an array equal to your PN length, and determines alignment in the array. Maybe this function can take both the PN sequence, and a vector your trying to find alignment within. (np.xor, and np.sum are you friends for quickly finding alignment within an array). 2) Convert the stream of bits to a vector that matches the length of your PN sequence (could be problematic if your PN is larger than the allow buffer sizes in GR)' Sink the vector into a vector probe. Assuming you don't have bit slips, the alignment of this vector relative to your prototyping PN sequence should be constant. 3) Create a variable who's value is the function call from (1) the the data from the vector probe (prob convert to numpy.array somewhere along the way). 4) Apply the alignment to the argument of delay block that in front of into the BER anlyzer. This will align demod'd stream with the input stream. This probably sounds convoluted, but may actually be a little easier to implement than your own block. I've used a similar technique... -John On Sun, Oct 12, 2014 at 12:48 AM, Dan CaJacob <dan.caja...@gmail.com> 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. > > 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 > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
