Wireless Over-the-Air Testing using SDRs - MATLAB & Simulink
Video Player is loading.
Current Time 0:00
Duration 29:09
Loaded: 0.57%
Stream Type LIVE
Remaining Time 29:09
 
1x
  • descriptions off, selected
  • en (Main), selected
    Video length is 29:09

    Wireless Over-the-Air Testing using SDRs

    Overview

    In this webinar, you will learn about MATLAB’s radio hardware support capabilities that enable you to connect your algorithms to a wide range of supported software-defined radio (SDR) devices.  You can use these live radio signals to verify your designs with waveform generation and over-the-air testing.  You will also learn about taking those designs to hardware by generating and deploying HDL code on the FPGA fabric of your radios.

    We will showcase how Communications Toolbox SDR support can facilitate the entire over-the-air testing workflow.  This includes connecting your software-based transmitter and receiver algorithms to SDRs and transferring live I/Q data to/from MATLAB and Simulink.  We will show how to use received signals to analyze your device under test (DUT), characterize your channel, or assess performance of your end-to-end design by computing metrics such as EVM, ACLR, or BER.

    We will then show how you can perform hardware/software co-design to implement a receiver for a familiar communications waveform on a Zynq SDR.  Starting with a behavioral Simulink model, we will show how the design can be partitioned so that the lower rate operations can be deployed on an ARM, and the higher rate operations can be deployed on the Zynq’s FPGA.

    Highlights

    • Generate 5G NR, WLAN or generic OFDM waveforms using Wireless Waveform Generator App
    • With a few commands, connect MATLAB to SDRs such as Pluto SDR, USRP, RTL-SDR or Zynq Radio
    • Transmit signals over the air using SDR
    • Acquire streaming or burst IQ data over the air using the same or a different kind of SDR
    • Perform signal quality measurements such as EVM and ACLR in MATLAB and Simulink
    • Generate deployable C and HDL on a Zynq SDR from a behavioral Simulink model

    About the Presenter

    Mike McLernon is an advocate for communications and software-defined radio products at MathWorks.  Since joining MathWorks in 2001, he has overseen the development of numerous PHY layer capabilities in Communications Toolbox, and of connectivity to multiple SDR hardware platforms.  He has worked in the communications field for over 30 years, in both the satellite and wireless industries.  Mike received his BSEE from the University of Virginia and his MEEE from Rensselaer Polytechnic Institute.

    Recorded: 16 Feb 2022

    Well, hello. My name is Mike McLernon. I'm a technical marketing manager at MathWorks, and I'm here to talk to you about wireless over-the-air testing using SDRs. I've been with MathWorks since 2001. I was closely affiliated with wireless products in that time, and working with SDR, Software-Defined Radios, for about 10 years. So let's get right to it. What are we going to discuss today?

    Well, here's what we're going to cover. We're going to show you how you can generate generic and standards-based waveforms without writing a line of code. We'll show you how to obtain and use the SDR software packages that enable connectivity between MATLAB and Simulink and SDR hardware.

    We'll show you how to perform over-the-air testing via signal transmission and reception with several types of SDR hardware. We'll verify MATLAB-based transmit and receive the algorithms with SDRs. And we'll also show you how to get started on the path to designing and building your own radio on the SDR hardware that you own.

    So let's get started. But we'll start with motivations for SDR usage. Now, one clear motivation for using software-defined radios, or SDRs, is to teach and research communications at the University level. Many students shy away from learning digital communications in their undergraduate engineering curriculum because they think that it's mostly about heroic math. Well, the math is important, but sending and acquiring real-world signals in the classroom illustrates the practical usage of that math.

    Another use case for SDR usage, both for academic and commercial users, is to capture off-the-air data for later analysis. In these cases, real-time streaming is not very important, but a contiguous segment of data is. Such applications as spectrum monitoring, modulation classification, receiver verification, and signals intelligence can all benefit from this SDR data capture. In particular, artificial intelligence and deep learning applications can benefit from over-the-air data capture.

    Another use case is to prove out a radio design. Pure simulation can get you started down that road, but ultimately, a receiver has to work with over-the-air data to determine if it can do the job. The SDR will impose impairments on that signal, like carrier offset, IQ imbalance, phase noise, and DC offset that will shake out any design deficiencies in the radio receiver.

    Finally, an important use case of particular interest to the aerospace and defense community is the design, development, and prototyping of an actual radio. In this case, the radio algorithms are first designed in software on a host computer. Then the algorithms are partitioned into software and hardware implementations on the SDR's processor and FPGA respectively. We'll cover this use case in more detail later in the presentation.

    So let's talk a little bit about generating these wireless waveforms. So often, the first step in using an SDR is generating a waveform that you can then transmit. So what we're going to do now is break out of the slides and go into MATLAB where we can show you how this can be done.

    So here we are in MATLAB, and what we can do is go to the Apps tab in the Toolstrip and find the wireless waveform generator. So it's one of my favorites. I hope that it'll be one of your favorites sometime soon as well. So as it's coming up, I'd want to share with you that you can model generic waveforms and also numerous standards-based waveforms.

    So we'll go ahead and generate a couple of such waveforms. First we'll start with 5G. So we'll create a downlink FRC, or Fixed Reference Channel. And in this case, we'll just use the default as it's coming up. So here are all of our parameters, and we can just click on the Generate button and wait for a few moments.

    And so now, what can we see as a result of the signal generation? You see the signal in the frequency domain through spectral analysis. We see the resource grid, and we see a more detailed channel view. And this resource grid shows us individual 5G signals like the PDCCH, the PDSCH, and the SS Burst.

    This is very, very useful so that you don't have to write any code at all in which to do this. You can simply parameterize the signal that you want using the panels on the left. We can do much the same with, say, an 802.11 signal. So let's go ahead and generate an 802.11ax signal.

    So here, again, nothing but clicking on the Generate button as we generate this default signal. And we'll see much the same kind of information in the display once the waveform is generated. So we see the spectrum. We see much more of the bandwidth is occupied with a Wi-Fi signal. And also essentially the resource grid, except in this case, for 802.11, it's called the RU and subcarrier assignment.

    The point is, you don't have to write any code to do this. And now what we'll do is also generate a much simpler waveform which we will use later in the presentation, a humble sine wave. And in this case, go ahead and set the frequency to be 250 kilohertz. We'll generate a complex waveform. We'll set the sample rate to be 4 times the frequency, in other words, a megahertz. And we'll set the duration to be 1/100 of a second.

    So we can generate that waveform easily enough. So we see in the spectral domain, here is the tone at 250 kilohertz with numerous spectral artifacts extending very far down in level. And also the kind of time waveform where you see the I and the Q components right next to one another, as you would expect.

    Now, what can we do once we have a waveform? Well, we can do multiple things. We can export to numerous places, we can export to workspace. So I'm going to go ahead and do that. And so that just creates a workspace variable that we can use later.

    But we can also export a MATLAB script. Now, I'm not going to do that right now, but what that enables you to do is to take the waveform that you have parameterized and then generated, and then create the MATLAB code that generates that script. That can be very, very useful, particularly in looping situation when you want to parameterize your waveform in code and generate numerous kinds of such waveforms.

    So this is all very helpful and useful. And one other thing that you can do is generate impairments for the signals. Gaussian noise, phase offset, phase noise, numerous different signals. So if you want to test out a receiver design, you can impair your signal and see how your receiver does against these various impairments. Very useful capability.

    So now let's go back to our slides and continue moving on. Let's talk about how you can obtain and use the SDR software that's necessary to establish that connectivity. Now, before you obtain your SDR software, you need to be prepared with your SDR hardware.

    This chart shows the radios supported by MathWorks software. They range from a $25 RTL-SDR dongle that you can simply plug into your USB port to receive only-- but for $25, there's a fair amount of capability there to USRP X or N radios that cost multiple thousands of dollars. And there's several in-between.

    So between all of these radios, they cover the range of use cases and motivations that we discussed a moment ago. And if you want to learn more about MathWorks' support for each of these radios, you can search in your favorite browser on "SDR MATLAB."

    Now first, let's define a hardware support package, because that's what you interact with when you want to connect MATLAB to an SDR. So MathWorks hardware support packages enable MATLAB and Simulink to talk to all kinds of hardware. In our case, that hardware is an SDR. One important point to note is that you need a Communications Toolbox to obtain any of our SDR support packages.

    Now here's a picture of what MATLAB looks like when you go to obtain one of those hardware support packages. But I think it's going to be more instructive if we do it in MATLAB. So let's go ahead and go to MATLAB again. So in this case, we move from the Apps tab to the Home tab, and then we look for Add-Ons, and we find Get Hardware Support Packages.

    So we click on that, and then we'll be presented with another dialog called the Add-On Explorer. And in this explorer is the whole raft of hardware support packages that MathWorks and even the community offers. So what we can do here is search on "SDR," and then we find several support packages that I just alluded to earlier.

    So RTL-SDR, USRP Radio, Xilinx Zynq-Based Radio, which is useful for hardware targeting. We'll talk about that later. The ADALM-PLUTO, which we'll use in a subsequent example. And also USRP embedded series, which also enables targeting. So again, this is very, very helpful where you can get to the support package that you want immediately.

    Let's for a moment go to the PLUTO support package. Now, I've already installed this on my laptop, so this button on the right here says Manage. But if you were installing it for the first time, this button would just say Install. And so you would go ahead and click on that button, and be presented with an install GUI where you can download and install just in a matter of minutes.

    And then if you have a radio on hand, you can plug it in, and the installer will perform some more hardware configurations so that within minutes, you are ready to go with your radio and your software to provide the connectivity between MATLAB and the radio. So let's continue on, and let's talk about over-the-air testing.

    Now, here's the code that you need to use one PlutoSDR to transmit and receive an over-the-air sine wave. We create, transmit, and receive objects that communicate with the PlutoSDR radio, and a spectrum analyzer to view the received signal. Finally, we use the sine wave created by the wireless waveform generator app a few moments ago.

    The while loop is almost trivial. It simply runs the objects that were created in the previous section of code and uses the same sine wave variable over and over. Note that the receiver call to the receiver object doesn't have any input arguments because it acts as a signal source. This mode of operation is called streaming because each time the receiver object is called, it grabs a new frame of data from the radio's memory.

    Now, we don't need to run the code right now. But here's a little video showing the spectrum analyzer behavior on the received signal when you do run that code. The spectrum shows the largest tone at 250 kilohertz, which is the transmitted frequency which you'd expect.

    Now, it also shows the tone at 0 hertz, which indicates a DC offset, and at negative 250 kilohertz, which indicates an IQ imbalance. These are exactly the kind of hardware imperfections that need to be reckoned with in a real receiver design project.

    Now, streaming is a perfectly viable workflow. But when signals of interest have a high bandwidth, or the processing in the host is compute-intensive, streaming may not work so well. Why is that? Well, a smallish frame of data is sent over the wire, be it ethernet, USB, from the radio to the host computer.

    The host must make repeated calls to the radio to retrieve those frames. Those many calls to the radio require a fair amount of time. If the radio is ready to send a frame of data, and MATLAB is not ready to receive it, then that frame gets lost. But we have an alternative in that case. It's called burst mode.

    So how does burst mode work? First off, the radio sends a very large contiguous block of data from its memory to the host PC, and to MATLAB's memory. Then, once the data block is in MATLAB memory, it gets written out to the calling program in much smaller chunks. And the data is post-processed once it is parceled out in those smaller chunks. During that time, no data is transferred from the radio to the host PC.

    This approach saves a great deal of time because the PC needs to call out to the radio just once in a while. This approach also works well when the application doesn't demand continuous data. We'll talk about one such application now.

    The Automatic Dependent Surveillance-Broadcast, or ADS-B system, is a wireless technology that broadcasts position, velocity, and other information of the aircraft that transmits it. Air traffic control systems can use these signals because they require no querying from the ground. You see a few system parameters listed here. The important point is that the aircraft transmits a short message with a very low duty cycle.

    So to demodulate and decode the message, we don't need seconds of contiguous data. We can capture a second of data, process it, and allow a bit more data to pass by, then collect another second of data and process it. The signal is ideally suited to be captured with burst mode.

    Here's a picture of the hardware setup up that can be used to decode the ADS-B signal, just a $150 ADALM-PLUTO radio and a laptop. If the laptop has Communications Toolbox and the ADALM-PLUTO support package loaded on it, you are ready to go.

    Now, here's a GUI that runs in a Pluto-based example that ships with Communications Toolbox. It shows the important data of the decoded ADS-B signal, including the aircraft ID, the position given in latitude, longitude, and altitude, and the velocity given in heading or azimuth, and vertical rate or elevation change.

    The check marks you see on the left of the GUI indicate ADS-B signals that have been demodulated sufficiently to give all that position and velocity information in the table. You see that it is possible to partially decode the ADS-B signal to generate a subset of all the information that it contains.

    And if you have Mapping Toolbox, you can see the positions in headings of the airplanes in your area on a local map. When you click on a plane icon, you can see relevant data describing that aircraft. To find this example, just search on "airplane tracking using ADP signals MATLAB."

    Now, let's talk a little bit about algorithm validation. Now, in this use case, it's very important to perform measurements on a signal. So we'll be, in this case, talking about EVM, Error Vector Magnitude measurements, on a WLAN signal.

    So here, we're going to talk about an example that ships with the ADALM-PLUTO hardware support package and uses the functionality in the WLAN Toolbox. Our ultimate goal is to measure EVM, but we'll do a lot of processing to get there. So let's actually go once more to MATLAB, and we will do this from there.

    So first, we'll type "doc PLUTO radio" to get to the doc for the support package, and then we'll click on the examples. Always lots of wonderful content to look at there. So there's some getting started examples, radio I/O, diagnostics-- which are important to determine any problems in the hardware-- digital modulation, and then we get to application-specific or standards-based signals.

    So we want to find the WLAN example, and here it is, image transmission and reception using WLAN Toolbox and one PlutoSDR. So we'll walk through this example a little bit using the block diagrams that are contained in the write-up.

    So here in this hardware setup diagram-- which shows how you start with an image file, and then you convert the data to bits, and then you use the WLAN Toolbox to transmit a standard compliant waveform. The waveforms are then sent to the radio where repeat transmit functionality is used. Now, that is much like burst mode, except on the transmit end.

    With transmit repeat, the waveform is sent from MATLAB to the radio memory, and then that same radio memory is accessed over and over, removing MATLAB from the loop. This significantly speeds up the transmission operation. Then the same radio uses burst mode reception to capture enough data so that the entire image is received in one shot.

    Now if we move along to the PHY and MAC processing for the transmission block diagram, we note that in the transmitter, the MAC processing consists of just adding the proper framing bits to the data. The PHY processing includes scrambling, error-control coding, and QAM and OFDM modulation.

    Once all that modulation is done, the IQ samples are sent over the radio. Then when we go to the receiver processing, we can see that the receiver performs first a coarse carrier frequency offset compensation, followed by a fine timing synchronization, then a fine frequency offset sync. A lot of synchronization has to go on in that receiver.

    It then estimates the channel for the frequency-domain equalizer, and also estimates the noise for soft decision to modulation and subsequent Viterbi decoding. Once the bits are recovered, they go to the MAC frame decoder which reassembles the image bits in the right order. Then the recovered image is displayed in a MATLAB plot.

    Along the way, after OFDM demodulation, the receiver has a 64-QAM signal on its hands. We can calculate the EVM of that QAM signal and quantitatively assess how clean it is. So now, let's go ahead again to MATLAB and run the example.

    So here's the code. We won't walk through it. To run it, we simply go to the Editor tab on the Toolstrip, click on the Run button, and we'll see some graphics pop up very shortly.

    So it's establishing connectivity with the radio. There's an image of the transmit image, a basket of fruit, very commonly used in image processing applications. To the left, you see the signal spectrum, very clear OFDM spectrum. And then on the right, a constellation diagram; after synchronization, we see a very clean 64-QAM constellation.

    And then the image of fruit comes back up. We see that the reconstructed image matches the transmitted image very, very well. And then, if we look at the EVM on the right side of the constellation diagram, we see an RMS EVM of 3.9%, which is very, very clean. So all of the frames were detected and decoded without error, and we have a lovely image at the end of the processing process.

    So now, if we go back to our slides, let's move ahead. We'll talk a little bit about radio prototyping at this point. Now, this aspect of SDR development involves partitioning your algorithm into hardware and software components, and prototyping on different FPGA-- or system-on-chip, or SoC-- platforms.

    You start with a MATLAB or Simulink model to verify the behavior, then automatically generate HDL and C code from that model to deploy both hardware and software components to the same physical SDR device, so that a working radio results.

    Now, using model-based design, you can generate algorithmic code for both hardware and processor parts of the system, using HDL and embedded code respectively. This code is included into the reference designs either provided by MathWorks by hardware support packages or of your own for implementation on the hardware platform.

    Now, it's important to note that Simulink models don't represent certain hardware attributes like memory, interconnect, and external I/O. Another MathWorks product, the SoC Blockset, does model those attributes. We won't discuss that product in detail here, but the take-home point is that MathWorks tools can get you all the way to hardware.

    So let's dig a little bit deeper into a particular example that ships with the Xilinx SDR support package. And so what we can do is go to a browser and type "hardware software co-design QPSK transmit and receive MATLAB." And then we get this hit at the very top, so we'll go ahead and click on that link. So this is an example that ships currently, and you can access this write-up, this example, online immediately.

    So let's talk about what's going on in the example. First, as we show the Zynq board block diagram, we note that Simulink is the master, and it controls the data source. The software interface model also monitors and visualizes signal data. The Zynq board is partitioned into programming logic on an ARM core and FPGA fabric that contains HDL code for high-speed operations. An AXI interface handles both data and control signal transport.

    The board acts as a transceiver, both transmitting and receiving. So if we move on to the hardware generation model right here, we see that the high-speed hardware algorithms in the orange subsystem block handle the waveform level operations, like gain control and timing and frequency synchronization. That's where the high-speed action is, and so it needs to go on the hardware.

    The ARM subsystem on the right, which is in software, handles the bit level operations like descrambling. These occur at a lower rate so that they can be done in software. Also, rather than performing frame-based processing on vectors, the model performs sample-based processing on scalars. Both data and data valid signals are transmitted at the same rate.

    The AXI4 interface is used to control whether the source data comes from the ARM or the FPGA, and to ensure that the HDL receiver algorithm processes valid data while the transmitter is transmitting. You would use the Embedded Coder product to generate target-specific C code for the ARM, and the HDL Coder product to generate HDL for the FPGA.

    Now, if we go to the software interface model a little bit below, we note that the model does not have any explicit waveform level operations. That's because by this point in the example, HDL Coder has created a bitstream for those operations and loaded them onto the Zynq board.

    In this model, the AD936x Transmitter block acts as a signal sink, and the AD936x Receiver block acts as a signal source. Now, this particular model has no visualization capabilities, but it can communicate with a host Simulink model over UDP to send decoded messages that can be printed by the host computer.

    Let's go back to our slides, and let's summarize what we've learned. First, we've talked about waveform generation using the wireless waveform generator app, wherein you don't have to write a lick of code in order to get a waveform that you can transmit using an SDR. We've talked about how you can install hardware support packages that cover a range of very inexpensive to a little less inexpensive SDR hardware platforms.

    We talked about how you can use over-the-air testing by transmitting and receiving with one or more radios and your laptop. We've also discussed algorithm validation in the context of a WLAN signal, an image transmission, and an EVM measurement that assesses signal quality.

    And finally, we've talked about how to prototype a radio by partitioning a design between software and hardware, and also by using model-based design to get that behavioral model to the place where you want it first off, and then taking that to hardware. Very, very important step.

    Now, MathWorks' SDR examples span a wide range of applications, from getting started with transmit and receive, to diagnostics for the hardware, to correcting for hardware impairments, to many standards-based signals. These include AIS, which is the Maritime equivalent of ADS-B, humble broadcast FM, Bluetooth, WLAN, as you saw earlier, and LTE.

    But now, if you have a favorite standards-based waveform that you don't see represented here, let us know. We'd love to learn how we can better support our users working with the signals that you care about.

    So here, you see displayed some links and search phrases that you can use to learn more about MathWorks' overall SDR support, and the specific examples we talked about today. We hope to accelerate your SDR development and make it easy in the process. And with that, I thank you very much for your attention today. And now, we'll open the floor to take your questions.