Hello,
TLDR: If you are using hardware in your flowgraph, which I think you are, then you should not include a throttle block. Only use throttle blocks in flowgraphs with no hardware limitations (i.e. reading from files or generating synthetic data on the fly).
The throttle block is intended for software only scenarios, in which you want to limit the rate at which your CPU gets called to make computations. The throttle block simply invokes a call to sleep to artificially "throttle" the CPU usage. It is not related to the contextual sample rate of the underlying stream of data. Using a throttle block with hardware can cause unintended issues where you can't keep up with the rate of the hardware.
For example, I could record data to a file from a radio with a sample rate of 1 Msps. If I play back that file and plot it in GNU Radio, I could use a throttle with any rate I want to limit CPU usage, but the underlying sample rate of that data will always be 1 Msps. The rate of CPU usage and the underlying sample rate of data are not coupled.
Richard
On Thu, May 29, 2025 at 10:57 AM aardric via GNU Radio, the Free & Open-Source Toolkit for Software Radio <discuss-gnuradio@gnu.org> wrote:
Hi,
Could someone please confirm my understanding that the sample rate in
the attached flow graph will be determined by the active path of the
second (from left) selector block and NOT the throttle block (that is,
if throttle not selected)? This would be consistent with the block
documentation for the selector block on the wiki.
Rick
No comments:
Post a Comment