Re: [Discuss-gnuradio] Huge delay with Osmocom sink
El 17/04/17 a las 13:58, Daniel Estévez escribió: > I was running at 1Msps. I've tested the same flowgraph at 10Msps and the > delay is now around 1 second, which seems fine. > > Is it possible to tweak the buffer sizes in an easy manner so I could > get the same effect at 1Msps? I've found that by setting a low value for "Max Output Buffer" in the cosine source then I get very little delay, even if running at 1Msps. Regards, Daniel. signature.asc Description: OpenPGP digital signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Huge delay with Osmocom sink
El 17/04/17 a las 13:04, Marcus Müller escribió: > 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. Hi Marcus, Of course, that was just a quick test. The throttle was deemed to fail eventuall due to sample rate mismatch. > 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. I was running at 1Msps. I've tested the same flowgraph at 10Msps and the delay is now around 1 second, which seems fine. Is it possible to tweak the buffer sizes in an easy manner so I could get the same effect at 1Msps? Regards, Daniel. signature.asc Description: OpenPGP digital signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Huge delay with Osmocom sink
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 > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Huge delay with Osmocom sink
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. test.grc Description: application/gnuradio-grc signature.asc Description: OpenPGP digital signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
