Main Content

FRS/GMRS Walkie-Talkie Receiver with USRP® Hardware

This model shows how to use the Universal Software Radio Peripheral® (USRP®) device with Simulink® to build a walkie-talkie that can receive messages from a physical walkie-talkie. The specific radio standard that this example follows is FRS/GMRS (Family Radio Service / General Mobile Radio Service) with CTCSS (Continuous Tone-Coded Squelch System).

In order to run this model, you need a USRP® board with an appropriate receiver daughterboard that supports the UHF 462-467 MHz band (for example, WBX). Please refer to the Setup and Configuration section of Documentation for USRP® Radio for details on configuring your host computer to work with the SDRu Receiver block.

This example is designed to work with USA standards for FRS/GMRS operation. The technical specifications for these standards can be found at [1] and [2]. Operation in other countries may or may not work.


Please refer to the FRS/GMRS Walkie-Talkie Transmitter with USRP® Hardware example for general information and overview details. Note that all the information in that section applies to this example, except that this example is designed to receive signals instead of transmit them.

Structure of the Example

This is the top-level block diagram of the model:

Running the Example

Turn on your walkie-talkie, set the channel to be one of the 14 channels (numbered 1 to 14) and the private code to be either one of the 38 private codes (numbered 1 to 38) or 0, in which case no squelch system is used and all received messages are accepted. Note that the private codes above 38 are digital codes and are not implemented in this example.

Set the channel and private code in the Model Parameters GUI in the model so that they match the settings on the walkie-talkie. Run the model, speak into the walkie-talkie, and see if you can hear your voice come out of the computer speakers. If not, try adjusting the "Average signal threshold for squelch" parameter downward slightly. You can change the channel and private code without stopping and restarting the model.

If you hear some dropouts or delay in the sound, run the model in Accelerator mode. From the model menu, select Simulation->Accelerator, then click the run button. If you still experience dropouts or delay in Accelerator mode, try running the model in Rapid Accelerator mode.

You can also run this model alongside an additional USRP® device running the FRS/GMRS transmitter example, instead of with a physical walkie-talkie.

FRS/GMRS Receiver Subsystem

The SDRu Receiver block converts the RF waveform to complex baseband samples, which become the input to this subsystem.

This subsystem is an enabled subsystem, which means that it is only active when the driving 'length' output is greater than 0.

Below is the block diagram of the FRS-GMRS Receiver subsystem:

Automatic Gain Control

The Automatic Gain Control block is the first block that processes the received signal. It processes the signal to ensure that the average magnitude of the samples is about 1. In this case, the walkie-talkie transmitter is likely nearby the USRP® radio, which implies that the received signal should not suffer from fading, and the received noise should be low. However, in general this may not be the case.

Channel Selectivity and FM Demodulation

The channel selectivity filter is the next block. If the incoming signal is from an adjacent channel, a low pass channel separation filter will reduce its power significantly. The gap between adjacent channels is 25 kHz, which means the baseband bandwidth is at most 12.5 kHz. Thus, we choose the cutoff frequency to be 10 kHz.

Next, a channel selector computes the average power of the filtered signal, and if it is greater than a threshold (set to a default of 10%), the channel selector determines that the received signal is from the correct channel and it allows the signal to pass through. In the case of an out-of-band signal, although the channel separation filter reduces its magnitude, it is still FM modulated and the modulating signal will be present after FM demodulation. To reject such a signal completely, the channel selector outputs zero.

The FM Demodulator Baseband block, with a 2.5 kHz frequency deviation, processes the channel selector output.

After FM demodulation, the FIR Decimation block converts the sampling rate to 200 kHz / 25 = 8 kHz. This is one of the native sample rates of the audio device on your host computer.

Continuous Tone-Coded Squelch System (CTCSS) and Decision Block

The CTCSS [3] decoder computes the power at each CTCSS tone frequency using the Goertzel algorithm [4] and outputs the code with the largest power into the Decision block. The Goertzel algorithm is used because it provides an efficient method to compute the frequency components at predetermined frequencies (namely, the tone code frequencies used by FRS/GMRS).

The Decision block compares the decoded code with a preselected code and sends the signal to the audio device if the two codes match. When the preselected code is zero, it indicates no squelch system is used and the decision block passes the signal at the channel to the audio device no matter which code is used.

Audio Output

Before the audio device, a high pass filter with a cutoff frequency of 260 Hz is used to filter out the CTCSS tones (which have a maximum frequency of 250 Hz) so that they are not heard.

The Audio Device Writer block is set up by default to output to the current audio device in your system preferences.

Exploring the Example

The performance of the model may vary depending on the board that you use. If your model does not produce any sound, you can vary the Gain (dB) parameter in the mask of the SDRu Receiver block.

The CTCSS decoding computes the DTFT (Discrete-Time Fourier Transform) of the incoming signal using the Goertzel algorithm and computes the power at the tone frequencies. Since the tone frequencies are very close to each other (only 3-4 Hz apart) the block length of the DTFT should be large enough to provide enough resolution for the frequency analysis. However, long block lengths cause decoding delay; for example, a block length of 16000 will cause 2 seconds of delay, since the CTCSS decoder operates at an 8 kHz sampling rate. This creates a tradeoff between detection performance and processing latency. The optimal block length may depend on the quality of the transmitter and receiver, the distance between the transmitter and receiver, and other factors. You are encouraged to change the block length in the initialization function by navigating to the getParamsSdruFRSGMRSRxDemo function and changing the value of the FRSRxParams.DecodeBlockSize field. This will enable you to observe the tradeoff and find the optimal value for your transmitter/receiver pair.


Copyright Notice

USRP® is a trademark of National Instruments Corp.