Dear All, There is a variant of this issue that I discovered and would like to point it out to the community.
Synopsis: After the first time the header CRC fails, *all* subsequent packets fail. Setup: - GRC examples of Tx/Rx OFDM - Noise source with a variable slider to control the amount of noise. The output of the Tx block is added with the output of the noise source. - The output of this adder is connected to the Rx block. Procedure: - Start the experiment with 0 noise. We see that the packets are successfully decoded. - Increase the noise, and we observe that the packet success rate begins to drop (payload CRC failures) - Further increase the noise to force a header CRC failure. - Decrease the noise back to 0. Notice that the packet success rate remains 0, even though the noise is 0. This is highly repeatable. Any help would be greatly appreciated. Best, Aditya On Wed, Jan 15, 2014 at 4:34 PM, Aditya Dhananjay <adi...@cs.nyu.edu> wrote: > > >> Hello Martin, >> >> I am still facing a problem here. (I have pulled the newest sources from >> GIT). First, let me describe the environment. I have connected the >> transmitter side to a channel model that introduces frequency and timing >> offsets (so that I have control over how dirty the channel is). From this >> channel model block, I feed it into the receiver blocks. I am not using any >> USRP or real hardware as of now. >> >> Issue A: I notice that when the header CRC check fails, the entire >> receive path soon freezes up. >> >> Issue B: Additionally, I notice that sometimes the header gets so >> corrupted that the CRC check passes (I suppose these false positives cannot >> be helped, unless we have a longer CRC for the header, but that's probably >> a waste). >> >> Issue A is the main problem for me. :) >> >> >> > Dear All, > > Please accept my sincere apologies. > > Regarding issue A: The *payload* path freezes up, and this is the expected > behavior since there are no valid headers that can be decoded. I had > erroneously stated that the *entire* receive path freezes up, which I just > realized, is not the case. > > Apologetically, > Aditya > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
