search

greatscottgadgets / hackrf

low cost software radio platform
https://greatscottgadgets.com/hackrf/
GNU General Public License v2.0
6.49k stars 1.52k forks source link

Raspberry Pi 4 USB write speed capped at 35 MB/s, could it be possible to get more? #1365

Closed VioletGiraffe closed 11 months ago

VioletGiraffe commented 11 months ago

What would you like to know?

Not an issue with HackRF, it's just that you have become experts on pushing USB 2.0 to its limits and maybe you could give some helpful advice. I can't get more than 35 MB/s (34.9-35.1), according to hackrf_transfer -t /dev/zero -s 20000000 . I get the same result in my application, 16 MHz sampling rate works and 18 doesn't. I tried different configurations of the async buffer size and the number of async transfers, and they all yield the same result (I was also monitoring the number and length of shortfalls with hackrf_debug -S). I built the latest libusb from repo and the number and length of shortfalls reduced slightly (beyond run-to-run variance), but in principle that didn't help me as I want a higher bandwidth.

So, do you have any ideas I could try, any tweaks? Thanks!

P. S. Have you considered switching to a USB 3.0 controller to avoid these transfer speed issues?

martinling commented 11 months ago

I'm not aware of any tricks to get more throughput on the RPi 4, sorry. If you've tried experimenting with the size and number of transfers then you've already tried the things that we could realistically tweak in libhackrf. As such I'm going to close this, because there isn't really anything we can do on the HackRF side to help.

USB 3.0 would require a completely different design, so it would be a whole new product really.

VioletGiraffe commented 11 months ago

I know there's nothing you can do on your end, I was thinking along the lines of your RAW_IO tweak for libusb on Windows - that one makes a big difference! And upgrading libusb to the current source version did make it better, but not enough.

martinling commented 11 months ago

I was thinking along the lines of your RAW_IO tweak for libusb on Windows - that one makes a big difference!

It does, but all that fix is doing is enabling the OS to queue up multiple URBs on the host controller when using the WinUSB backend. On every other libusb backend, including Linux, that happens by default.

VioletGiraffe commented 11 months ago

Does HackRF have spare CPU to run some kind of simple decompression on the data stream?

martinling commented 11 months ago

Other than handing USB interrupts, the M4 core is largely idle during TX, so if you want to try to implement something like that you could. But decompressing and generating output at 40MB/s may be a lot to ask of a M4 core at 204MHz with a general purpose compression algorithm.

There may be application-specific possibilities, though. At one end of the scale, a simple signal generator could be done by repeating some pre-generated samples from a buffer in memory. Extending that approach, simple modulations could be generated by having the firmware switch between different waveforms for different symbols, e.g. a fast and a slow sine wave for 2FSK. Then you would only need to transmit the symbol indices from the host. But only if this sort of approach is applicable to what you're wanting to transmit.

Note that our Discord server may be a better venue for open-ended discussions like this than GitHub issues.