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.




Attachment: signature.asc
Description: OpenPGP digital signature

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

Reply via email to