|
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). 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. |
[Prev in Thread] | Current Thread | [Next in Thread] |