Michael that provides insight into the error, unfortunately it does not explain the behavior of the example. The example uses the tx_packet and rx_packet hierarchical blocks. The output of the tx is routed to the input of the rx. I bypassed the example channel model and I’m not using hardware at the moment, so I would expect the example would have little issue with poor SNR and would maintain sync.
Thanks, Alex. Get Outlook for iOS<https://aka.ms/o0ukef> On Tue, Mar 27, 2018 at 6:37 PM -0500, "Michael Dickens" <[email protected]<mailto:[email protected]>> wrote: Hi Alex - The OFDM "#f" printouts means that the header didn't decode correctly, which in turn means its Rx-computed CRC8 didn't equal the embedded CRC8 from the header generation. This in turn generally means that OFDM sync has been lost, which in turn generally means that the Rx "SNR" isn't high enough ("SNR" here being the average power in the OFDM band divided by the average power outside the OFDM band but still within the sampling frequency range). I can't say specifically for the example you cite what's going on, but maybe the above helps? - MLD On Tue, Mar 27, 2018, at 6:54 PM, Roberts, Alex S. wrote: > I'm playing around with some of the packet and ofdm examples with the > eventual goal of streaming udp packets generated by gsrteamer encoding a > webcamera. Unfortunately, I've been having some difficulty with the examples > that I can't understand. For example, running the packet_loopback_hier > example, it will run fine for some period of time (seems to be different > amount each run) then it stops printing message debugs and spams the console > with > > header_payload_demux0 - Parser returned #f > > Occasionally, the flowchart will crash and stop running. > > In the current run I have open, the correlation plot looks good, the transmit > Time Freq and Constellation Plots are active, and the receive plots are no > longer updated (probably because nothing is being decoded?) > > I've tried looking a the archives to see what causes this problem, but have > not found a good answer.
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
