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 > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
