Re: [Discuss-gnuradio] uhd_packet_rx example freezes - Header/Payload Demux not releasing payload

[Marcus Müller]

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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio