I have been learning the basics of GnuRadio recently to make use of my RTL SDR dongle. While I successfully recreated some of the flowgraphs found on Google, I have
There are actually two sample rate types present in the GnuRadio graphs. The first one is the hardware rate at which the samples flow through the flowgraph and is usually
Figure 1: Using a throttling blockGnuRadio has been made to deal with real-world data. That means it will attempt to deal with the handled data samples as fast as
What happens when you don't use the throttling block when you should? My flowgraphs usually freeze and I have a difficulty to turn them off.
What happens when you use the throttling block when you shouldn't? I usually observe the overflows. You can see the overflows as a bunch of OOOO's on the GnuRadio log window. Note that I've observed this when having RTL SDR block, the throttle
According to GnuRadio's FAQ, hrottling is used whenever the following conditions are met:
- There are no radio devices used
- There are no audio devices connected
- There are no head blocks in the flow
A single throtling blockcan be strategically placed in the graph to throttle the whole graph. As its timing is not perfect, using more than one throttle block might introduce some problems in synchronization (this has not been confirmed).
Figure 2: Using a resampling blockAs we saw in the previous example, having no data flow control can be harmful for the execution of our flow graph. What happens if we have more than one data flow control clock? Most of the time, each of the hardware interfacing controls works at different rates. These rates are usually defined by the "sample rate" block variables. If the input hardware operates on the different sample frequency from the output hardware, we get the sample rate mismatch. To deal with this, the rational resampler block can be used.
In the simpler flow graphs where there are no blocks that change sampling rates (other than our resampler) it is quite easy to properly resample the data. You should interpolate by the output sink sample rate and decimate by the input source sample rate. The block itself will deal with the mathematics behind it, but essentially, the input sample rate is increased or decreased by a rational factor to match the output sample rate.
It is very important to find the supported rates of your hardware. While audio sink blocks have a dropdown with several frequently used rates, it doesn't mean your hardware will support all (or any) of them. In my case I was getting underflow errors and playing with selecting the well-known frequencies. When I selected the 44.1kHz I got a message from ALSA:
audio_alsa_sink[default]: unable to support sampling rate 44100000 card requested 192000 instead.
Once I entered the correct card rate, all my resampling calculations started working immediately.
To conclude, here are my findings in short form. Throttling slows down the data flow when there is no other hardware-imposed clock. Resampling does not slow down