Overrun or Underrun due to two Blocks in a GNU Radio Flow Graph that are no 100 % in Sync

I have noticed a problem when there are several blocks in a flow graph that have a fixed rate. This is typically the case if a Software Defined Radio (SDR) is the source in the flow graph, and the audio device on the computer is the sink of the flow graph. If the clocks on the SDR and the audio device are not in 100% sync (which is nearly always the case), they will drift and eventually there will either be an underrun (not enough samples produced for the audio device) or an overrun (too many samples produced by the SDR). This then typically causes annoying sounds every now and then in the loud speakers.

In order to “work around” this problem, I started on a new block to analyze the situation. The idea is to have a fairly big FIFO in a block and then monitor the fill rate of this FIFO. The block can be found here: https://github.com/rubund/capture-tools/blob/master/gr-capture_tools/lib/xrun_monitor_ff_impl.cc

It will print out the fill rate of the FIFO. When starting up, it tries to fill it to about 50% before passing the real samples on to the output. It produces zeros until it reaches 50% fill rate. Then if the fill rate later drops below 30%, it halts and fills up to 50% again before starting to pass samples over.

The plan is to later automatically inject single samples here and there to make the problem almost invisble/inaudible.

Transmit Packet when Pushing a Button in a GNU Radio Flow Graph GUI

In the capture_tools out-of-tree module, one block called tag_on_set_one_f and one block called file_source_on_tag can be used together to send a stream of IQ samples from a file whenever a GUI button is pushed.

Download this sample flow graph here: https://www.funwithelectronics.com/wordpress/other_data/burst_msg_source_c.grc

 

So tag_on_set_one_f will produce samples as fast a possible, and therefore a throttle block is needed after file_source_on_tag to keep the sampling rate under control.

file_source_on_tag produces zeros between “bursts”.

If you have another block which for instance produced a packet whenever receiving a stream tag, it can also be used together with tag_on_set_one_f so that when a button is pushed, a packet is transmitted.

burst_msg_source_c together with blocks from gr-iridium

You will find the burst_msg_source_c in this out-of-tree module: https://github.com/rubund/capture-tools/tree/master/gr-capture_tools

gr-iridium is a module made for receiving packets from Iridium satellites. One clever idea by the gr-iridium guys is to use an FFT to monitor a whole band and then detect peaks. This makes it possible to receive packets at multiple frequencies at the same time, without having a huge number of baseband processors working in parallel.

Peaks in the FFT are discovered by the block fft_burst_tagger. The frequency and various other information is added as a stream tag to the stream. Then the block tagged_burst_to_pdu looks for these tags in the stream and whenever it finds one, it collects a number of IQ samples and stores them in a buffer which is then passed on as a GR message.

In gr-iridium, the downstream blocks then operate purely on messages. This means that only “custom” blocks can be used there. Since I like the idea of being able to use standard GR blocks, I implemented a new block, burst_msg_source_c, which then again converts the messages back to a normal stream. This has proven to be a quite useful “technique”. It allows receiving packets at multiple frequencies, even coming exactly at the same time, but having only a standard “one dimensional” baseband processor implemented in GNU Radio. Since the upstream blocks add tags to the stream, it is also possible to keep track of the exact time instant when the packets were being transmitted on air.

https://www.funwithelectronics.com/wordpress/other_data/burst_msg_source_c.grc

burst_msg_source_c does the frequency translation for every sample burst so that the baseband processor can stay tuned to the same frequency (baseband) all the time. Since the frequency detection mechanism in fft_burst_tagger is not always exact, burst_msg_source supports specifying specific frequency intervals for the channels if such information is a priori known (“Round factor” and “Round add“).

It can be seen that the output from burst_msg_source_c will not be at a regular sampling rate. It will come in bursts. Sometimes, if for instance the threshold has been set too low in fft_burst_tagger, the output from burst_msg_source_c  will be at a sampling rate much higher than the input! In that case, the handshaking mechanism between burst_msg_source_c and tagged_burst_to_pdu makes it possible to simply drop bursts instead of the whole flow graph hanging (“Drop Overflowing Bursts“).