Decreasing FFT points to increase time resolution

[cedivad]

First off, this project is amazing. I think I might be in love with every single bit of it.

I was looking into what the changes to increase time resolution would be, I never implemented a FFT in hardware but I assume decreasing the number of points should take less resources, not more, so it should be feasible. However I don't think I can find the source project for the FPGA module in the LimeSDR-Mini_GW repository?

Thank you! :)

[gasparka]

Hi, glad you find it useful!

First thing to consider is the average-pooling applied to the time axis, which is currently set to 8. This could be reduced to 4/2/1. For example, changing this to 4 would increase your time resolution and output rate by 2. Change must be done in FPGA sources.

About the sources: Basically i generate them with an undocumented Python tool, so don't spend too much time on them: https://github.com/gasparka/LimeSDR-Mini_GW/tree/fpga_fft/LimeSDR-Mini_lms7_trx/src/fft

I plan to generate a matrix of FPGA sources with various configurations e.g. FFT=1024 AVG_POOL=8x8, but i don't know when i will make it that far. Let me know if you have a specific configuration in mind, i will surely generate it for you.

BTW, here is the formula to calculate the time duration of each FFT frame:

s = 1/(SAMPLE_RATE) * FFT_SIZE * AVG_POOLING
For current system:
1/80e6 * 8192 * 8 = 0.0008192 s = 0.8 ms

[cedivad]

Thank you for the speedy answer! Sorry I didn't reciprocate but I don't have a LimeSDR mini at the moment (I ordered one) and I wanted to get a feel of your software before asking for changes.

My ideal timing resolution is around 10 us, that would allow me to see the smallest exchange in detail. However if I understand what you are doing correctly that would also correspond to a 800/10 = 80x increase in USB bandwidth speeds, that is most likely not reasonable (especially given the lack of in-device buffer memory, aside from the FPGA's block ram). Possible solutions should be decreasing the bandwidth or loosening the timing requirement.

What do you believe are reasonable bandwidth numbers for a USB 3.0 and/or embedded host? In other words, for my use case, the highest the timing resolution, the better. I'm starting to believe my application would have been better suited for the bigger brother LimeSDR because of its embedded RAM.

[gasparka]

Yep, USB bandwidth is a problem. 380MB/s is about the maximum that you could hope for on a desktop computer, and yes this needs FPGA RAM - reducing the FFT size could provide it. Raspberry Pi3 has a USB2 port so performance will be dramatically lower, ODROID however has USB3 and they report speeds up to 250MB/s (https://www.hardkernel.com/shop/odroid-xu4/).

Another way to reduce the USB bandwidth is to increase the frequency-axis average pooling, it is already quite high at 16. This influences the FFT bin bandwidth:

rbw = SDR_BANDWIDTH / FFT_SIZE * FREQ_AVG_POOLING
For current system:
80e6 / 8192 * 16 = 156.25 kHz

Finally, i have a work in progress (#3), that on completion reduces the USB bandwidth by factor of 4.

[gasparka]

Closing inactive thread.