LTE MIB Recovery and Cell Scanner Using Analog Devices AD9361/AD9364

This example shows how to implement an LTE MIB recovery system on the Zynq radio platform that is partitioned across the ARM and the programmable logic (PL) fabric. The FPGA image generated is then used as the base for building an LTE cell scanner to detect LTE cell signals in the vicinity.

Required products:

  • Simulink

  • Communications Toolbox

  • LTE Toolbox

  • LTE HDL Toolbox

  • HDL Coder

  • HDL Coder Support Package for Xilinx Zynq Platform

  • Embedded Coder

  • Simulink Coder

  • Embedded Coder Support Package for Xilinx Zynq Platform

  • Communications Toolbox Support Package for Xilinx Zynq-Based Radio (this support package)

Limitations: Due to limited hardware resources, this example does not support ZedBoard and FMCOMMS2/3/4.


The LTE HDL MIB Recovery (LTE HDL Toolbox) model is a hardware friendly model. You can use this model to detect the MIB information from synthesized data generated by the LTE Toolbox or captured off-the-air LTE waveforms. This example shows how to adapt the model to software-defined radio (SDR) hardware, and how to to prototype it on the Zynq platform. Firstly a system will be developed to receive MIB information at a single center frequency. Then the software interface model will be modified to allow real-time tuning of the center frequency to implement a cell scanner.


If you have not already done so, ensure you follow the Installation for Hardware-Software Co-Design in the documentation.

Hardware Generation Model

The hardware generation model is used to develop the functionality that you wish to implement on the PL fabric. In this example, we implement a MIB recovery receiver based on the LTE HDL MIB Recovery (LTE HDL Toolbox) example. The following figure shows the hardware architecture diagram of the MIB Recovery example.

Open the model.

Hardware-software partitioning: In this example, the MIB recovery algorithm is implemented entirely in the PL, due to the high rate signal processing requirements of the design. The ARM is used to pull the information from the FPGA and send some useful information back to the host over a UDP link for display. The LTE_MIB_HDL subsystem contains the functionality to be implemented on the FPGA. Around this subsystem is the functionality that will eventually be implemented on the ARM processor on the Zynq hardware. The software provides two main functions: communication of the decoded MIB information back to the host for display, and start/reset control of the FPGA IP. In the hardware model, the communication back to the FPGA is replaced with a simple interface which displays the decoded information. The software can also control which input data to use: off-the-air or test data stored on the FPGA. To simulate software execution on hardware, the output data of the subsystem is downsampled by 1000.

The LTE MIB recovery subsystem is shown below.

In this subsystem, the HDL LTE MIB Recovery subsystem contains the cell search and MIB recovery algorithm as presented in the LTE HDL MIB Recovery (LTE HDL Toolbox) example.

In addition to the algorithm, the subsystem also provides functionality for integration with the Zynq hardware architecture.

At the input to the HDL LTE MIB Recovery subsystem, the StimulusSelector subsystem allows the input data to the MIB detection algorithm to switch between off-the-air or embedded test data. The embedded test waveform is pre-generated using LTE Toolbox and stored in a lookup table on the FPGA.

Next, some adjustments are made to the received data in the PrepInputs subsystem. The data from the AD9361 is a 12 bit number, sign extended to 16 bits. In order to use the full range the samples are scaled up to 16 bits. To take advantage of hardware resource sharing and simplify some of the architectures found in the receiver, the data rate into the system is configured to be higher than required. The input data rate is 61.44MHz, whereas the required maximum data rate is 30.72MHz. This difference translates to an overclocking factor of . Therefore, upon entering the detector, the data is immediately downsampled by a factor of 2. An FIR Decimation block is used to implement a lowpass decimation filter which captures the central part of the received LTE waveform and downsamples the data to 30.72MHz.

You can run this model to confirm its operation using the captured LTE waveforms in zynqRadioLTETransmitData.mat. The test waveforms used in the model are configured in the initialization script. As the model contains a large number of HDL-optimized blocks, requiring simulation using sample-based signals, the simulation runs very slowly. When a MIB is decoded, the MIB GUI will pop up with the decoded information.

You can set up the model with the following option:

  • externalDataSel: set to false to select internal test data, transmitted from a LUT. When false is selected, the start signal will also be driven internally, resetting the MIB recovery every 4s. Set to true to select the pre-captured off-the-air data stored in the test vectors.

IP Core Generation Workflow

Once you are satisfied with the simulation behavior of the hardware subsystem, you can start the process of generating the HDL IP Core, integrating it with the SDR reference design, and generating software for the ARM processor.

In preparation for targeting, you must set up the Xilinx tool chain by invoking hdlsetuptoolpath. For example:

>> hdlsetuptoolpath('ToolName','Xilinx Vivado','ToolPath','C:\Xilinx\Vivado\2018.2\bin\vivado.bat');

Start the targeting workflow by right-clicking the LTE_MIB_HDL subsystem and selecting HDL Code / HDL Workflow Advisor.

  • In Step 1.1, select IP Core Generation workflow and the appropriate Zynq radio platform from the choices: ADI RF SOM, ZC706 and FMCOMMS2/3/4, ZedBoard and FMCOMMS2/3/4, ZCU102 and FMCOMMS2/3/4, ZC706 and FMCOMMS5. Due to limited hardware resources, this example does not support ZedBoard and FMCOMMS2/3/4.

  • In Step 1.2, select Receive path reference design. You can leave the reference design parameters as the defaults.

  • In Step 1.3, the interface table can be used to map the DUT signals to the interface signals available in the reference design. In this example, we only use a single channel, so the channel 1 connections and AXI register interfaces should be configured as shown in the two images below.

  • In Step 1.4, ensure that the Target Frequency is set to a reasonable number given the baseband sampling rate of the system. In this example, the sample rate is 61.44 MHz, so the maximum synthesis frequency of 61.44 MHz is required.

  • Step 2 prepares the design for code generation by doing some design checks.

  • Step 3 performs the actual HDL code generation for the IP core.

  • Step 4 integrates the newly generated IP core into the larger Zynq SDR reference design, generates the bitstream, and helps you load it onto the board.

Execute each step in sequence to experience the full workflow. Alternatively, if you are already familiar with the workflow, right click Step 4.1 in the table of contents on the left hand side and select Run to selected task. You can use the default settings in Steps 2 and 3.

Software Generation Model and Block Library

  • In Step 4.2, the workflow generates a Zynq software generation interface model and a block library. Click the Run this task button with the default settings.

Software Interface Library

The library contains the AXI Interface block generated from the LTE_MIB_HDL subsystem. The data ports present on the Receiver block represent the streaming data interface between the FPGA user logic and the ARM. If you use the library blocks in your downstream models, any updates to your HDL subsystem are automatically propagated to this library and to your software generation models. In this example, the hardware generation model did not contain SDR transmit or receive blocks, so the parameters on these blocks are populated with default values. When using the library blocks, you must configure the parameters correctly for your application.

Software Interface Model

You can use the generated software interface model as a starting point for full SW targeting to the Zynq: external mode simulation, processor-in-the-loop, and full deployment. Note that the generated model is overwritten each time you run Step 4.2. To further develop your software algorithm, save the model under a unique name. For a software interface model that shows how you can structure this model, see section Running the Software and Hardware on the Zynq board.

Bitstream Generation and Loading

Use the rest of the workflow to generate a bitstream for the FPGA fabric and to download the bitstream to the board.

  • In Step 4.3, the Workflow Advisor generates a bitstream for the FPGA fabric. You can choose to execute this step in an external shell by ticking the selection Run build process externally. This selection allows you to continue using MATLAB while the FPGA image is being built. The step requires a couple of minutes to complete after some basic project checks. When a green checkmark indicates that the step is complete, you must still wait until the external shell shows a successful bitstream build before moving on to the next step.

  • Step 4.4 downloads the bitstream onto the device. Before continuing with this step, call the zynq function with the following syntax to make sure that MATLAB is set up with the correct physical IP address of the radio hardware.

>> devzynq = zynq('linux','','root','root','/tmp');

By default, the physical IP address of the radio hardware is If you alter the radio hardware IP address during the hardware setup process, you must supply that address instead.

Alternatively, if you want to load the bitstream outside Workflow Advisor, create an SDR radio object and call the downloadImage function on the object.

If in step 1.1 you selected either the ADI RF SOM, the ZC706 and FMCOMMS2/3/4, the ZedBoard and FMCOMMS2/3/4, or the ZCU102 and FMCOMMS2/3/4 radio device, create an AD936x radio object.

>> radio = sdrdev('AD936x');

If in step1.1 you selected the ZC706 and FMCOMMS5 radio device, create an FMCOMMS5 radio object.

>> radio = sdrdev('FMCOMMS5');

Download the bitstream using radio object interfacing the selected radio device.

>> downloadImage(radio,'FPGAImage', ...
     % Path to the generated bitstream

Running the Software and Hardware on the Zynq board

The following software interface model allows you to run the example system in Monitor & Tune mode or fully deployed.

Open the model.

  • The model has been configured to run using the Xilinx Zynq-7000 Based Board target for the following hardware: ADI RF SOM ZC706 and FMCOMMS2/3/4/5

  • If you are using the ZCU102 and FMCOMMS2/3/4, double click the Selected Hardware Board Target block to change the configuration to use the Xilinx Zynq UltraScale+ MPSoC ZCU102 IIO Radio board target.

The model is configured to run on a timer interrupt. This means that the code generated from the Simulink model is executed on the ARM processor at a rate corresponding to the maximum rate in the software interface model. In this case, the model is configured to run at a rate of 1kHz, thus the AXI registers on the FPGA are read 1000 times per second.

For more information on setting up the software interface model, refer to Hardware-Software Co-Design Workflow.

You can detect an LTE MIB by choosing one these options:

  • Use the waveform embedded on the FPGA by setting the externalDataSel input to 0.

  • Detect a live signal off-the-air by setting the externalDataSel input to 1. This option requires the transmission center frequency of an LTE cell tower in your area. The default center frequency for this example is 806 MHz.

Monitor & Tune mode allows you to control the configuration from the Simulink model. You can also fully deploy the design to run on the board, disconnected from Simulink. In the Simulink toolbar, click Build Deploy & Start.

The software algorithm is set up to reset the receiver on a timeout with default value 4000, which corresponds to 4 seconds. The same value is configured for the hardware start signal.

The ARM sends the decoded MIB information directly back to the host over the Ethernet link using the UDP send block. The UDP send block is configured using the default IP address of the host ''. If you alter the IP addresses during the hardware setup process, you must supply that address instead. The following UDP receive model illustrates how to receive the decoded data, and displays the result.

Open the model.

When running successfully, you should notice that the information updates on the user interface on the host. The data received from the test waveform on the FPGA should result in received data as shown below.

Building a Cell Scanner SW Interface Model

The FPGA image generated for the MIB detector example can be re-used to scan across center frequencies and search for LTE cell towers in the local vicinity. The HW generation model used in this example already contains everything you need to implement this system, you only need to modify the SW interface model to update the center frequency over time and check for valid MIB signals.

The following software interface model is configured to implement a cell scanner, and allows you to run in Monitor & Tune mode or fully deployed.

Open the model.

The basic architecture of this SW interface model is very similar to the previous MIB detector example. The AXI interface block is used to read and write registers on the MIB detector IP core, and the ARM-FPGA interface block is used to configure the RF parameters. In this model, the center frequency is tuned in real-time from the software algorithm configured in the LTE Scan Controller block. To select the band of interest over which to scan, double click the LTE Scan Controller block and configure the parameters.

The LTE Scan Control block is a simple MATLAB state machine that programs the center frequency, gives the RF card time to settle and waits for valid MIB signals. The numMIBRetries input allows you to choose how many times the MIB Detector algorithm will be restarted on each center frequency. The Concat and Send to Host block packages up the MIB information and associated data to be sent over UDP to the host. The current center frequency is also sent at regular intervals allowing the host display model to update its state periodically.

Open the LTE MIB Logger host model to view the decoded MIB information. This model implements a simple user interface to display the MIB information and currently scanning center frequency.


Some RF front-ends can have large frequency offsets which can make it hard to decode an LTE signal. The maximum offset that can be corrected is 7.5kHz. You can try the following techniques to identify a frequency offset.

  1. If you have LTE Toolbox, you can run the LTE MIB Receiver script to look for LTE signals at chosen center frequencies. Edit the center frequency in the script to attempt to receive an LTE signal. The script will output the detected frequency offset on the command prompt.

  2. You can add or subtract 3.75kHz from your chosen center frequency in the MIB Detector or Cell Scanner models. If your offset is greater than 7.5kHz, you can progressively try higher or lower frequencies.