Hi Justin, sorry for the delayed response. So:
indeed, the uhd_packet_rx.grc flow graph has two different sync elements: 1. the FLL band-edge 2. PFB Clock Sync within the packet_rx hier block, as you've noticed. In your case, it's possible the FLL doesn't attack fast enough; you would verify that by comparing waterfalls / spectra of the signal before and after. Maybe you'd alternatively/additionally want to increase the bandwidth of the PFB Clock Sync. In a first attempt: increase the sps (from default 2 -> 3, for example); for that, increase the USRP source's sampling rate accordingly, adapt the FLL to that to still lock tightly onto you signal, and make sure the sps in the packet_rx reflects the new sps value. Best regards, Marcus On 03/28/2017 04:58 AM, Justin Hamilton wrote: > Hi everyone, > > I'm trying to develop a packet-based, single-carrier system (BPSK, > QPSK, QAM) with FEC (CC) similar to that implemented in packet_rx.grc > and packet_tx.grc. I am using two Ettus B205mini-i as my USRP devices, > connected for now, via a 50Ω, 30dB attenuator and SMA cable (antennas > also at hand). I am using 64-bit Ubuntu 14.04LTS, Xeon E3-1575M, 32gb ram. > > When testing uhd_packet_rx.grc with the default BPSK signal I find > that the receiver immediately locks up after I enable it using the > "on" checkbox. After taking a look into the packet_rx hierarchical > block, I found that the correlation estimator was indeed finding a > peak indicating the transmitted packet. The generated tags were then > used to trigger the Header/Payload Demux block to release the header > as expected. This block doesn't seem to be getting back a valid > decoded header however. This results in the payload never being > released and causes buffer back pressure which leads back to the USRP > source and ultimately locks up the system. > > I have noticed a frequency offset between my two radios due to the > receiver constellation spinning, but hand-tuning it proved quite > difficult. The difference might be outside the acceptable limits for > the synchronisation blocks used? > > Possibly related: I am able to run packet_loopback_hier.grc without > issue, except that if I add considerable noise to the system it often > never recovers, either returning the message "gr::log :INFO: > header_payload_demux0 - Parser returned #f" or flat out crashing. > Could it possibly be the case that the noise added by my > 'over-the-air' radio system is too much for the Polyphase Clock Sync > and Costas Loop blocks to compensate for? > > Has anyone experienced this issue before or figured out how to solve > it? If I can get these example flowgraphs working it'll be a great > help for my custom flowgraph. Surely sending OTA packets with > modulation and coding can't be this difficult :) > > Also if anyone has any tips on modifying the synchronisation (Costas > Loop) to support QAM constellations that be great! > > Thanks for your help! > Justin > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
