Hi everyone, After spending a lot of time trying to make a packet based radio for bit error rate testing, making a lot of posts about it on the mailing list, and ultimately not succeeding, I wanted to share some of the things I've learned. While the radio worked over the air for short periods of time, it was never able to reliably receive without dropping packets over an extended amount of time. This made bit error rate testing with the radio impossible.
1) General Receiver Structure: USRP->FIR Low Pass->Power Squelch->AGC2->FLL Band Edge->Correlation Estimator->PFB Clock Sync->Costas Loop->LMS DD Equalizer->HPD Demux->Constellatoin Decoder->Bit level stuff 2) My radio completely relied on tags to detect packets. The Correlation Estimator block was responsible for tagging the start of a packet. Because of this, I needed to be very meticulous about tracking tags as they went through the receiver chain. The debug for this was difficult for me, but forced me to learn a lot of things about GNU Radio. 3) The correlation estimator block will double tag peaks from time to time. This is due to block boundaries that are imposed by the GNU Radio scheduler. If a peak happens to coincide with the end of a scheduler block, it will probably get tagged by the correlation estimator block at the end of the current block and at the beginning of the next block. I wrote an OOT block to remove the double tag when this happened. Important to keep in mind with it's current implementation. 4) I built up the radio using a loopback simulation block by block, simulating and confirming input file matched output file along the way, so that I could be sure of which block caused an error to creep in. At one point, I noticed a plot-only block causing errors in the data stream. This block was not a part of the data stream, but somehow interacted with it. Someone on the mailing list pointed out that timing sync blocks might be able to cause something like this due to rate changes. This was the area that happened to be in. I simply deleted the plotting block in that area and the issue went away. This leads me to my next point. 5) When I added the PFB Clock Sync block into the loopback simulation, it would go from working over night for hours, to failing relatively quickly, a few minutes. Inspecting the output file it looked like what I had been seeing for a while, packet drops. This tells me the PFB Clock Sync block must be consuming my correlators tags, which would then cause the packet to drop when it reached the HPD Demux block. I don't have a fix for this. It's been mentioned by a few developers that this is a known issue through rate change blocks. I hope this is useful information for people starting up on something like this. Though I failed with the packet based approach, I was able to make a streaming based approach work. I detect the start of a stream one time and then from there on out assume everthing I receive is data. This makes tag drops a non-issue, so long as I detect the first, which doesn't seem to be an issue. v/r, Rich
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
