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

[Justin Hamilton]

Hi Marcus,

Thanks for your response!

So I spent the last week testing out the changes you recommended. First I had a look at the FLL block with the waterfall plots but couldn't immediately spot anything strange, except that during pure simulation with a perfect channel it did however shift things off centre and ruin synchronisation. Pretty unexpected. The same doesn't happen when using multipath channel taps or my real channel however. I also increased/decreased the sps, eb and loop bandwidths on the various sync blocks, leading to more packets being decoded and now the channel doesn't lock up as before. To tune them I was watching the receiver constellations and looking at how likely the system was to adapt vs. stick with the current synchronisation.

It appears that the faster I send packets, the easier synchronisation is, but if I send packets too often (< 1ms period) I get async buffer overflows and am more prone to crashes. I'm not experiencing any under or overruns. Ideally I'd be sending packets every 1-10ms, though since the end implementation is completely async (connected to a TUN/TAP), I could realistically get packets only every 1s, which would be horrendous for sync in its current state.

In general I'm still only getting very few packets getting through however. With the header_format_default I am able to receive quite a lot of packets, while header_format_counter successfully decodes far less and additionally crashes with a segfault while performing a CRC check. Are there any additional sync steps I could take advantage of to improve my performance?

Thanks for your help.

On Fri, Mar 31, 2017 at 12:15 AM, Marcus Müller <address@hidden> wrote:

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

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio