discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Huge delay with Osmocom sink


From: Marcus Müller
Subject: Re: [Discuss-gnuradio] Huge delay with Osmocom sink
Date: Mon, 17 Apr 2017 13:04:10 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0

Hi Daniel,

I'm not overly happy with the splitting using Throttle: Sooner or later, it's going to turn out either your PC or your SDR device are a few ppm faster clocked, and then your throttle rate doesn't match your actual sample consumption rate, and then some buffers are going to over- or underflow.

The buffers are the reason you're seeing this: GNU Radio works on a buffer interface, which means every block is producing samples as fast as possible – that is, until the output buffer is full. Buffering is a wanted effect – it allows for higher computational efficiency, and is absolutely necessary when marrying a device with a fixed, deterministic timing (i.e. the DAC/ADC of an SDR device) with a variable-scheduling, non-deterministic computer (i.e. software running in a general-purpose operating system on a general-purpose CPU).

Now, 5s sounds like way too much. Maybe you're operating your SDR device at a very low sampling rate? Try to use a higher one (and drop the throttle and UDP sink/source split). That would make the buffers (which keep their size in samples) "shorter" in terms of time.

Best regards,
Marcus

On 17.04.2017 12:29, Daniel Estévez wrote:
Hi guys,

I'm using the Osmocom sink with a LimeSDR. I'm testing with a very
simple flowgraph (attached): a cosine source's amplitude is toggled
according to the state of a QT push button, thus getting a crude CW
transmitter.

The problem I'm seeing is that there is a huge delay (about 5 seconds)
between the moment I press the button to the moment that the RF goes out
on the air. I think that the cause is that the LimeSDR takes around 5
seconds to start working, so the cosine source is holding back 5 seconds
worth of samples until the Oscomocom sink starts consuming samples.

If I split this flowgraph into two as follows:

1st) cosine -> throttle -> udp sink
2nd) upd source -> osmocom sink

and I start the second flowgraph and then the first, then I get little
delay, but this is a very ugly hack.

Is there a good way to solve this issue?

Regards,

Dani.


_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


reply via email to

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