GNUradio dropping Tx samples?

General Discussion
#1

So, this is a curious question, perhaps someone with some more experience could point me in the right direction, Also sorry if it’s in the wrong section, I’m new here.

I am working on a small RADAR project, so I need to transmit a chirp repeatedly. I am hoping to use about as much of the bandwidth the lime can give me (hoping for ~55MHz). But it looks like the Tx is dropping samples… A lot of samples:

GNUradioIntermittentChirp
GNUradioIntermittentChirp1538×860 16.8 KB

This should be 75% full (that’s the duty cycle I have for the chirp). The signal is dropping in and out mid-chirp. Just for fun this is a zoomed in view:

GNUradioIntermittentChirpZoomed
GNUradioIntermittentChirpZoomed1534×858 30.1 KB

Needless to say this is not great. On the plus side the parts of the chirp that are there are pretty good. I have never used GNUradio with such high data rates. Everything I’ve done has been Rx only at ~5 MSs. So perhaps I am just overestimating my hardware, I have:

Ubuntu 18.04 LTS (Via WSL2 windows 11)
GNUradio version 3.7 (if memory serves)
i7-10750H- boosts to 4.2+ GHz (checked during the run)
^(6 cores 12 logical processors, though i figure single thread is the bottleneck here)
16 Gb Ram
USB 3.0 connection (with 3ft extension)

Running the flow chart obviously spooled up, but it never maxed out, running maybe 60%utilization, and not 100% on any single core. Can I not support 60 MSs transmitting? Has anyone else run it this hard? I expected it to struggle a little, but not this bad. The samples seem to just drop randomly. USB 3.0 should support these data rates as far as I can tell. Even from a real world perspective. I do have a 3 ft USB extension (reasonably quality) I’ll pull that off and see if It helps any.

I was also wondering if there is a way to use the WFM player from the LimeSuite GUI in the FPGA tools inside GNUradio? The chirp from there has been working very well. Beautiful. I would prefer to use that, free up the USB traffic. I figure if there’s a way to access that from a python library (I’ve been looking at PyLMS2002 but I can’t find what I’m looking for). I figure if it can be done from python I could write a block or even just add a few commands to the top_block.py to set up the WFM player.

Here’s my GNUradio flowchart. It’s super basic but I figure if I’m dropping samples I should be keeping it slim.

GNUflowchart
GNUflowchart1209×596 46.2 KB

Anyways, I’m open to suggestions. I would love any tips hints, tricks, or anything of the sort. Thanks in advance.

#2

Have you tested that your hard disk/SSD can actually continuously write data at 1920 Mbit/second ? (60MSPS x 2 channels x 16 bit samples)
While simultaneously reading data at the same data rate (at a guess) ?

#3

I have not explicitly tested that. It is a NVME SSD, though it doesn’t appear to be the bottle neck according to the resource manager. I also checked, and in the “null-zones” there is still noise, so it looks like it is gathering and saving real samples.

Also I plugged the Tx output into a real specAn and I can see the difference in the spectrum between the gnuradio chirp and the FPGA wfm player chirp. And a several dB drop in the average power as well.

Good thought though.

I should probably also check the Rx with a sig gen I’m to make sure it’s not skipping samples either.

Thanks!

#4

My knowledge of this is very old and might be already obsolete, so don’t take it for granted, but here’s what I think.

  1. Most likely the issue here is not the lack of processing power, but the USB data transfers. 60MSps is a lot of data, best case of Tx or Rx single channel using 12bit I&Q samples would be 1.440 Gbit/s + packet headers. While the USB 3.0 spec says up to 5 Gbit/s, it is not a requirement for the actual hardware to guarantee support of that much bandwidth, so in reality the available bandwidth is going to be lower depending on chipsets being used (on both sides of the connection).
  2. The samples data transferring is using BULK usb endpoints. Bulk transfers are reliable with error detection, and can do several retries if there were problems with the data, so depending on the connection quality, the required bandwidth could be higher due to retries. Also for transfers to bulk endpoints, bandwidth is not reserved on the bus, so other devices that are active on the same bus can interfere with the timing of the data transfers.
  3. The Tx samples are being sent in packets with a timestamp of when they should be transmitted by the FPGA. If the packet arrives to FPGA later than it’s designated timestamp, then it is simply discarded and no transmission is performed.

So taking all of this into account, situation looks like this: you are producing 60MSps transfering and already operating close to the limit of available USB bandwidth, then either transfer retry or another device accessing the bus randomly congest the samples transfer, delaying all queued up packets delivery. Too late packets are being discarded by FPGA so no transmission. Eventually the delayed packets are cleared and USB transmission manages to catch up with the expected timestamps and so the transmission resumes until next such interruption.

#5

Yes, my knowledge of USB is very superficial, I tried to research some of the FX3 hardware, but it got to be too much of a rabbit hole. Although It’s worth noting that I found that using pyLMS7002Soapy I can pull the full 60MSPS till I fill my RAM up (almost a minute). So I don’t think it’s only a USB speed holdup. I think GNUradio might just have too much overhead.

If anyone else stumbles across this or a similar problem I found that If I start the chirp playing using the FPGAcontrols, and save an .ini file with the .wfm file playing, disconnect in software from the LimeSDR, Then move to GNUradio, have the Rx block read in that .initialization file, the chirp starts up again. This helped TONs. I can still only get roughly 10% of the samples through GNUradio (at 60MHz), but it’s much much better. If anyone is transmitting something extremely repetitive and wants to use GNUradio, I would recommend this.

#6

There is a difference between receiving and transmitting. Transmitting is time critical, if there is delay in data coming to RF hardware then it just does not have anything to transmit and you get gaps/discontinuities in the expected signal.
When receiving, RF hardware continuously captures the signal and stores samples in a buffer, so as long as you can process samples faster than they come in or have enough buffer space then you are guaranteed to get a continuos reception (you seem to be processing too slow, so the buffer is getting filled until there is no more RAM to store new samples). Even if there is USB holdup during reception and it delays data packet, it does not lose the data (while the on board buffer is not full), only the timing when you get to process it. The samples have timestamps when they were received by the RF hardware, so if you’re algorithm does not care about the latency from RF reception to data processing then there is no issue. And since the packets are timestamped software can inform you if there is any dropped samples (which would happen if USB bandwidth is not enough).