Question about using with PlutoSDR and flexframe
kozliuk opened this issue · 10 comments
Is it possible to use the library with PlutoSDR (libiio) at a sample rate of 5 MSPS? I am attempting to create a working example with flexframe-qpsk and have noticed that the performance of flexframesync is not sufficient to process this amount of data quickly enough.
What does the library and hardware have to do with it?
I understand; just curious how much time it can take for flexframe_sync.
I am attempting to transmit and receive a file (~10MB) at a 5MSPS sample rate using QPSK. It appears that the flexframe_sync cannot keep up with a 5MSPS sample rate. Could you possibly provide some hints on how to do it correctly?
Completely different things. From a file or a real device. To do this (from the file https://github.com/jgaeddert/liquid-dsp/tree/master/examples)
Козлику по русски отвечу. 5 МГц выборка, разрядность где ?
Is it possible at all? I mean use a real device with your library. My final goal is transmit a realtime video.
my setup is Pluto sdr as rx and tx (5MSPS), libiio to read/write data, liquid to generate/process frames (flexframe)
Signs of Matlab, there are libraries there and compare.
@jgaeddert, I managed to get the PlutoSDR + libiio + flexframe working at 2.5 MSPS. However, I can only receive 30% of my frames; the other frames in the buffer are lost during the flexframesync process the current buffer (it takes some time for it). I played with the resampler (2x on transmit, and 0.5x on rx side), but without any success; I'm still losing data. I did something similar to your USRP code at https://github.com/jgaeddert/liquid-usrp/blob/master/src/flexframe_rx.cc.
Could you please advise me on what I might be doing wrong? Thank you.
Some initial thoughts. I suspect that frame detection could consume most of the processing time. This uses a 2-dimensional search over time and frequency (qdetector_cccf) which, while necessary to account for hardware offsets, can be computationally expensive. The qdetector_cccf can be configured over which range of frequency offsets it should search. A larger range will take more time. By default, I believe it is set to be relatively wide open, so it takes quite a bit of processing. If you know your carrier frequency offset is fairly small, you can reduce this range.
Unfortunately I don't have an API for changing this in the flexframesync's search range. You can adjust this in the code, though with something like the following:
// create frame detector around line 178 in src/framing/src/flexframesync.c
q->detector = qdetector_cccf_create_linear(q->preamble_pn, 64, LIQUID_FIRFILT_ARKAISER, k, q->m, q->beta);
qdetector_cccf_set_threshold(q->detector, 0.5f);
qdetector_cccf_set_range(q->detector, 0.0001f); // new line: set a small frequency offset search rangeObviously the ideal solution would be to benchmark your program so you know exactly which pieces of code are taking the most computation, but this would be a good place to start.