discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: USRP N210 growing latencies


From: Johannes Demel
Subject: Re: USRP N210 growing latencies
Date: Wed, 27 Oct 2021 14:47:52 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0

Hi Fabien,

unless this is a very specific issue and you know exactly that your OS is the component that causes an issue, I recommend to stick with your distros generic kernel image.

I'd need more information but my gut feeling tells me that your issue is somehow a 2-clock problem.

So let's start with a few questions about your system.
Which Linux distribution do you use? Which exact GNU Radio and UHD versions do you use? GR 3.9.3? UHD 4.1.0.x? How did you install GNU Radio. Do you run your flowgraph in a VM or smth similar?
UHD RX sample rate?
UHD TX sample rate?
Are both rates supported by your N210?
Does your flowgraph decimate by some integer value?

Which blocks are in between?
Just to get this out of the way, another hardware block such as an audio sink might get you into a 2-clock problem situation. Since you use hardware blocks, I assume you don't use a Throttle block, if so, remove the Throttle block.

Can you share the flowgraph? It might be easiest to just write down the exact blocks.

Are there any custom blocks?

Do you need continuous streaming?

How fast does the delay grow?

A lot of questions, I know. The answers to these questions might help to find your root issue.

Cheers
Johannes



On 26.10.21 21:41, Fabien PELLET wrote:
Hello,

Thanks for the answer Marcus.

OK I understand that. But is there any solution which permits to reset that growing propagation delay ? How to reset the flowgraph buffers without killing the application and restart it ? Is there any method that permits to purge and resync buffers of the flowgraph ?

Even if my application runs on a preempt_rt OS with a good calculation power, I'm not enough good in Linux tweaking to be sure that my application will not have a unusable delay after a long time. So I can accept to loose some time when I catch a PMT message of underflow to reset the sequencer and buffers. But how without killing apps ??

Best regards,
Fabien, F4CTZ

---- Marcus Müller a écrit ----

Hello!


On 26.10.21 16:12, Fabien PELLET wrote:
 >
 > Why that propagation delay is always growing ?
 >

Exactly *becuause* your underflowing.

Your Receive side produces N samples – but too slow at some point, leading to your transmitter needing to "invent" an amount P of samples, because it simply has a fixed
sample rate.

So, now, from the point of view of the transmitter's DAC, N+P sample periods have passed, whereas the receiver's ADC saw N sample periods. This repeats, and every P > 0. Therefore,
the delay is always only growing.

Best regards,
Marcus




reply via email to

[Prev in Thread] Current Thread [Next in Thread]