# Resampling and Throttling in GnuRadio

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 realised that I don't quite understand the GnuRadio basics. This will hopefully be one of many small articles explaining the GnuRadio basics.

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 controled by the throttle block. The second one is the DSP rate at which the samples are appearing one after another. It can be viewed as a discrete distance between the two consecutive samples. This rate can be interpolated (shortened) or decimated (made longer) by the rational resampler block.

# Throttling

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 pssible. It will not attempt to limit the data flow in any way unless it was programmed to do so, and will let the speed limits be limited by the actual hardware (sources like USRP, HackRf, RTL SDR and so on and sinks like sound card audio sink). This poses a problem when a program is made that does not reference actual hardware (like for instance using a signal source and fft sink). In this case we use the throttling block. Throttling will slow down the amount of data passed in the flow diagram, which will in turn result in less CPU time required to perform the signal operations.

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 block and the fft sink block. I imagine I'd have audio underruns (AuAuAu-s) if I had a signal source, a throttle block and a sound sink.

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).

# Resampling

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.

# Conclusion

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 the the data flow per se, it merely changes the rate at which the samples appear one after the other (the distance between samples). When performing resampling, first make sure you have correct and supported input and output sampling rates, otherwise any resampling calculations will still produce uderflow or overflow errors.