Throttle

Throttle flow of samples such that the average rate does not exceed the specific rate (in samples per second).

A throttle block should be used if and only if your flowgraph includes no rate limiting block, which is typically hardware (e.g., an SDR, speaker, microphone). It is not intended nor effective at precisely controlling the rate of samples. That should be controlled by a source or sink tied to sample clock. E.g., a USRP or audio card.

The Throttle Block is typically attached directly to the output of a non-hardware source block (e.g. Signal Source), in order to limit the rate at which that source block creates samples.

Parameters

(R): Run-time adjustable

Type

Data type of the block can be complex, float, int, short or byte. Default value is complex.

Sample rate(R)

Maximum average sample rate desired.

Vector length

Default value = 1. Values > 1 allow for vectors of samples to be passed (for example, at the output of an FFT block)

Ignore rx_rate tag

If set to False, the block will set its sample rate to the value of recieved tags with the key rx_rate. It will ignore other tags.

Limit

"None", "Max Time (sec)", "Max items"

To avoid maximally large chunks to be copied at maximally large latency (which can lead to very undesirable "laggy" behaviour in visual sinks), the maximum time that the block waits per copy can be specified (and thus, inherently the maximum number of samples that get copied at once), or the maximum number of items (and hence inherently the maximum time to wait between chunks).

Maximum

Time (float) or number of items (int)

If the Limit Parameter was not set to "None", this sets the maximum for the limited latency or item chunk size.

Example Flowgraph

Demonstration

In the below flowgraph, the upper Signal Source is feeding into a Throttle block, which limits the rate at which it passes samples to 50,000 samples per second.

We use the "Limit" parameter to bound the maximum time that happens between a chunk of items being emitted by the Throttle block. We set that time to 1/50 of a second. (And that gives us 1/50 s · 50,000 Samples/s = 1000 Samples per chunk, at most.)

The lower Signal Source is not feeding into something that slows it down to a defined rate.

To test the rates at which samples pass through, we attach Probe Rate blocks, and give them distinct names. We use Message Debug to print these rates

We observe this:

• As we can see in the upper "Throttled" figure, the passing of samples of a defined rate leads to predictable displaying of the waveform. For the unthrottled data, not so much
• We observe the sample "passing through" rates before and after the Throttle: they are, on average, the same, and as expected, 50,000 per second.
• We observe the rate between the unthrottled Signal Source and the Sink: that is in the region of 288 million samples a second. It's purely random which part of the waveform we see.
• The upper Signal source consumes negligible amounts of CPU. The lower one fully consumes a CPU core, and hence leads to heat and noise from CPU coolers.

Source Files

C++ files

Here

Header files

Here

Public header files

Here

Block definition

Yaml