On 25/11/2024 20:57, dhpanch...@gmail.com wrote:
I’m receiving a wide bandwidth signal (~250 MHz sample rate using
DPDK) on X410 using GNURadio and I notice that the green LED light
turns ON and quickly turns back off whenever I have signal processing
blocks (e.g. filter block) connected to the UHD source block. You have
1-2 overflows at the beginning but the GUI seems to work fine showing
the signal with the time/freq sink plots. Whenever I just have the
time/freq sink blocks only connected to the uhd_source, the green
light stays on.
My question is would the green light turning quickly off be still an
issue? If so, any ideas how to resolve that one? I’m wondering because
I will need to re-transmit the signal again using UHD sink block and
am experiencing underflows (not been able to resolve this yet and the
red transmit light doesn’t turn on). I’m wondering if that’s partly
due to the green light turning back off.
Doing *ANY* signal-processing "stuff" at 250Msps within Gnu Radio is
very likely to result in significant numbers of
over-runs, and it may even be the case that no forward progress can
be made at all at those rates, with the interface
dropping sample buffers because there's nowhere to put them, because
the application (your Gnu Radio flow-graph)
simply cannot vacuum out the interface fast enough. The frequency
sink uses a heavily "stuttered" approach to
producing the spectral estimate. If the frame rate is (let's say)
10Hz, then nearly ALL of the incoming sample
frames are dropped on the floor, which is why it *appears* that it is
"keeping up" when you only have a frequency
sink in your flow.
What kind of computer are you using? What happens when you drop the
sample rate down by a factor of 4?
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
