search

jgaeddert / liquid-dsp

digital signal processing library for software-defined radios
http://liquidsdr.org
MIT License
1.82k stars 425 forks source link

Question about using with PlutoSDR and flexframe #355

Open kozliuk opened 3 months ago

kozliuk commented 3 months ago

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.

seonlee2013 commented 3 months ago

好啊，邮件收到啦！ Hi, your email is arrived safely

GkvJeep commented 3 months ago

What does the library and hardware have to do with it?

kozliuk commented 3 months ago

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?

GkvJeep commented 3 months ago

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)

GkvJeep commented 3 months ago

Козлику по русски отвечу. 5 МГц выборка, разрядность где ?

kozliuk commented 3 months ago

Is it possible at all? I mean use a real device with your library. My final goal is transmit a realtime video.

kozliuk commented 3 months ago

my setup is Pluto sdr as rx and tx (5MSPS), libiio to read/write data, liquid to generate/process frames (flexframe)

GkvJeep commented 3 months ago

Signs of Matlab, there are libraries there and compare.

kozliuk commented 3 months ago

@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.

jgaeddert commented 3 months ago

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 range

Obviously 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.