Recording DME with the LimeSDR

DME (distance measuring equipment) is an aircraft radio navigation system that is used to measure the distance between an aircraft and a DME station on ground. DME is often colocated with a VOR station, in which case the VOR provides the bearing information. DME works by measuring the two-way time of flight of pulse pairs, which are first transmitted by the aircraft, then retransmitted with a fixed delay by the ground station, which acts as a transponder, and finally received back by the aircraft. DME operates between 960 and 1215 MHz. It is channelized in steps of 1 MHz, and the air-to-ground and ground-to-air frequencies always differ by 63 MHz (here is a list of all the frequency channels).

I want to write a post explaining in detail how DME works by analysing a recording of DME that contains both the air-to-ground and the ground-to-air channels. Among other things, I want to show that the delay between the aircraft and ground station pulses matches the one calculated using the aircraft position (which I can get from ADS-B data on the internet), the ground station position, the position of the recorder, and the fixed delay applied by the ground station transponder.

Recording two channels 63 MHz apart is tricky with the kind of SDRs I have. Devices based on the AD9361 technically support a maximum sample rate of 61.44 Msps (although some people are running it at up to 122.88 Msps). The LMS7002M, which is used by the LimeSDR and other SDRs, is an interesting alternative, for two reasons. First, it supports more than 61.44 Msps. However, it isn’t clear what is the maximum sample rate supported by the LimeSDR. Some sources, including the LimeSDR webpage mention 61.44 MHz bandwidth, but the LMS7002M datasheet says that the maximum RF modulation bandwidth (whatever that means) through the digital interface in SISO mode is 96 MHz. In the case of the LimeSDR there is also the limitation of the USB3 data rate, but this should not be a problem if we use only 1 RX channel. I haven’t found clear information about the limitations of each of the components of the LMS7002M (ADC max sample rate, etc.).

The second interesting feature is that the LMS7002M has a DDC on the chip. The AD9361 has a series of decimating filters to reduce the ADC sample rate and deliver a lower sample rate through the digital interface. The LMS7002M, in addition to this, has an NCO and digital mixer that can be be used to apply a frequency shift to the ADC IQ signal before decimation.

I had two different ideas about how to use the LimeSDR to record the two DME channels. The first idea consisted in using a 70 Msps output sample rate. For this I used an ADC sample rate of 140 Msps, because I think it is necessary to have at least decimation by 2 after the ADC (the LMS7200M documentation does not explain this clearly, so figuring out how to use the chip often involves some trial and error using LimeSuiteGUI). This idea had two problems. The first problem is that some CGEN PLL occasionally failed to lock when using an ADC sample rate of 140 Msps. However the LimeSuite driver retried multiple times until the PLL locked, so in practice this wasn’t a problem. This approach worked well on my desktop PC, since in 70 Msps I had the two DME channels and then I could use GNU Radio to extract each of the two channels (for instance with the Frequency Xlating FIR Filter). However, the laptop I planned to use to record on the field couldn’t keep up with 70 Msps.

The second idea was to use the on-chip DDC in the LMS7200M to extract the DME channel and deliver a much lower sample rate over the digital interface. The figure below shows how the LMS7200M digital signal processing datapath works. This datapath is called RXTSP. The RXI and RXQ signals are the digital signals coming from the ADC (here and below, by ADC I mean a dual-channel ADC, since the LMS7002M is a zero-if IQ transceiver). The RYI and RYQ are the signals delivered to the digital interface of the chip. Since the LMS7200M has two RX channels, there are two identical chains, one for each channel. The parameters of each chain can be programmed completely independently.

LMS7200M digital signal processing, extracted from the datasheet

There is no way of sending the signal of one ADC to the two RXTSPs. The connection between each ADC and its corresponding RXTSP is fixed. Therefore, we need to feed in the antenna signal through the two RX channels, but we can easily do this with an external splitter. Remember that both of the LMS7200M RX channels share the same LO, as illustrated by the block diagram below. So the point here is to tune the LO to a frequency between the two DME channels, set the sample rate high enough that both DME channels are present in the ADC output, and finally to use each of the two RXTSPs to extract one of the DME channels, sending it at a low sample rate through the digital interface.

LMS7200M block diagram, extracted from the datasheet

This approach has worked quite well. I have set the ADC to 80 Msps and used the RXTSPs to dowconvert and decimate the DME channels to 2.5 Msps, recording that data directly in GNU Radio.

I have done a two hour recording of DME and published it in the Zenodo dataset Recording of Colmenar (CNR) VOR-DME air-to-ground and ground-to-air DME channels.

In the rest of this post I explain the details of the recording set up and do a preliminary analysis of the recording quality.

Maia SDR DDC

I have implemented an FPGA DDC (digital downconverter) in Maia SDR. Intuitively speaking, a DDC is used to select a slice of the input spectrum. It works by using an NCO and mixer to move to the centre of the slice to baseband, and then applying low-pass filtering and decimation to reduce the sample rate as desired (according to the bandwidth of the slice that is selected).

At the moment, the output of the Maia SDR DDC can be used as input for the waterfall display (which uses a spectrometer that runs in the FPGA) and the IQ recorder. Using the DDC allows reaching sample rates below 2083.333 ksps, which is the minimum sample rate that can be used with the AD936x RFIC in the ADALM Pluto (at least according to the ad9361 Linux kernel module). Therefore, the DDC is useful to monitor or record narrowband signals. For instance, using a sample rate of 48 ksps, the 400 MiB RAM buffer used by the IQ recorder can be used to make a recording as long as 36 minutes in 16-bit integer mode, or 48 minutes in 12-bit integer mode. With such a sample rate, the 4096-point FFT used in the waterfall has a resolution of 11.7 Hz.

In the future, the DDC will be used by receivers implemented on the FPGA, both for analogue voice signals (SSB, AM, FM), and for digital signals. Additionally, I also have plans to allow streaming the DDC IQ output over the network, so that Maia SDR can be used with an SDR application running on a host computer. It is possible to fit several DDCs in the Pluto FPGA, so this would allow tuning independently several receivers within the same window of 61.44 MHz of spectrum. In the rest of this post I describe some technical details of the DDC.

Running the AD9361 at 122.88 Msps

The Analog Devices AD9361 is an RFIC that is used in several popular SDRs, such as the USRP B2xx series and E3xx series, the BladeRF 2.0 micro, the ADALM Pluto, the ANTSDR, and in many other products (some of these use the AD9363 or the AD9364, which are similar chips in the same family). This RFIC has a nominal maximum sample rate of 61.44 Msps, and an analog bandwidth of 56 MHz.

A few days ago, Nuand has published a new software version that allows running the BladeRF 2.0 at 122.88 Msps. This has attracted some interest in Twitter, specially regarding questions about how they manage to achieve this and how good the performance is. One of the changes that Nuand has done to support the 122.88 Msps mode is an 8-bit wire protocol for the USB 3.0 interface. This is required to be able to pass 122.88 Msps through the USB. This change affects the FPGA gateware and host drivers. The other change involves manually setting some registers of the AD9361 in the host drivers in order to bypass a half-band filter, effectively doubling the output sample rate. In this post I will give a short review of the AD9361 register settings that enable the 122.88 Msps mode.

Maia SDR

I’m happy to announce the release of Maia SDR, an open-source FPGA-based SDR project focusing on the ADALM Pluto. The first release provides a firmware image for the Pluto with the following functionality:

  • Web-based interface that can be accessed from a smartphone, PC or other device.
  • Real-time waterfall display supporting up to 61.44 Msps (limit given by the AD936x RFIC of the Pluto).
  • IQ recording in SigMF format, at up to 61.44 Msps and with a 400 MiB maximum data size (limit given by the Pluto RAM size). Recordings can be downloaded to a smartphone or other device.

Connecting the Pluto SDR to an Android phone

I have a couple of ideas in mind that involve connecting an ADALM-Pluto SDR to a phone or tablet. Usually, the Pluto is connected to a PC through USB, and the Pluto acts as an Ethernet device, so that network communications between the PC and Pluto are possible. I want to have the same thing running with my Android phone, which is an unrooted Xiaomi Mi 11 Lite (model M2101K9AG, if anyone is curious).

As usual when trying to do something slightly advanced with Android, this hasn’t worked on the first go, so I’ve spent some time debugging the problem. Long story short, in the end, the only thing I need to make this work is to run

# fw_setenv usb_ethernet_mode ecm
# fw_setenv ipaddr 192.168.89.1

on the Pluto once and reboot (these settings are saved as uBoot environment variables to persistent storage), then enable Ethernet tethering on the phone every time that I connect the Pluto. I can go to the web browser in the phone and check that I can access the Pluto web server at 192.168.89.1.

ADALM-Pluto web server browsed from Android

Hopefully the rest of this post will give useful information about how everything works behind the scenes, as your mileage may vary with other Android devices (or if you try with an iOS device, of which I know next to nothing).

I haven’t seen many people doing this, so the documentation is scarce. PABR did a set up with LeanTRX, the Pluto and an Android phone, but they were running the Pluto in host mode and the Android phone in device mode, and I’m doing the opposite. Note that when you connect a Pluto and phone together, the roles they take will depend on the USB cable. My phone has USB-C, so I’m using a USB-C plug to type-A receptacle cable (USB-C OTG cable) together with the usual USB type-A plug to USB micro-B plug cable (the cable provided with the Pluto). There is also this thread in the ADI forums, but it doesn’t really say anything about Ethernet over USB.

Calculating the QO-100 beacons frequency separation

In my previous post I set out to measure the phase difference between the QO-100 8APSK and BPSK beacons. One of the things I mentioned is that the frequency separation between these two beacons was approximately 1.6 Hz larger than the nominal 245 kHz.

A frequency error of a couple of Hz is typical when working with SDRs unless special care is taken. Many SDRs allow choosing the sample rate and centre frequency with great flexibility, but the drawback is that the frequencies that are achieved are often not exactly the ones we indicated. Fractional-N synthesis PLLs are used to generate the sampling clock and local oscillator, so there are small rounding errors in the generated frequencies.

With enough knowledge of how the SDR hardware works and how it is configured, it is possible to determine these frequency errors exactly, as a rational number \(p/q\) that we can calculate explicitly, multiplied by the reference frequency of the SDR. Then we can use this exact value to correct our measurements.

I have asked Mario Lorenz DL5MLO and Kurt Moraw DJ0ABR the details of how the beacons are generated in the Bochum groundstation. Two ADALM Pluto‘s are used: one generates the CW and BPSK beacons, and the other generates the 8APSK multimedia beacon. With the data they have given me, I have been able to compute the frequency separation of the 8APSK and BPSK beacons exactly, and the result matches well my experimental observations.

In this post we will look at how the fractional-N synthesis calculations for the Pluto can be done. Since the Pluto uses an AD9363 RFIC, these calculations are applicable to any product using one of the chips from the AD936x family, and to the FMCOMMS3 evaluation board.

Hermes-Lite 2 external 10 MHz reference

Interested by the forthcoming HamSci December 2021 eclipse festival of frequency measurement, I have decided to enable and test the external 10 MHz input of my Hermes-Lite 2 DDC/DUC HF transceiver. This will allow me to use a GPSDO (the Vectron MD-011 which has appeared in other posts) to reference the Hermes-Lite 2 in order to measure frequency accurately.

Measuring the Allan deviation of a GPSDO with an SDR

A few days ago I tried to measure the QO-100 NB transponder LO stability using my DF9NP 10MHz GPSDO. It turned out that my GPSDO was less stable than the LO, so my measurements showed nothing about the QO-100 LO. Carlos Cabezas EB4FBZ has been kind enough to lend me a Vectron MD-011 GPSDO, which is much better than my DF9NP GPSDO and should allow me to measure the QO-100 LO.

Before starting the measurements with QO-100, I have taken the time to use the Vectron GPSDO to measure the Allan deviation of my DF9NP GPSDO over several days. This post is an account of the methods and results.

Using an external reference with the LimeSDR Mini

A while ago I spoke about feeding an external reference to the LimeSDR USB. Now I wanted to use an external reference with the LimeSDR Mini that I have in my QO-100 groundstation to lock all the system to GPS. Preferably I wanted to use 27MHz as the reference, since this is what I am using in my LNB, so this would save me from having to run 10MHz or another frequency to the groundstation.

I wasn’t so sure how well this would work, since there are a few threads with questions in the MiriadRF forums, but I haven’t seen any explaining things in a clear way. There are different anecdotes of things that worked or didn’t work for several people, but not that many definitive answers. Among all the threads, this one seems mostly helpful.

Somewhat surprisingly, everything has worked well on the first try. I am now using a 27MHz external reference with my LimeSDR Mini. Hopefully this post will be of help to other people.

Measuring the gain of a dish

Here I want to show a technique for measuring the gain of a dish that I first learned from an article by Christian Monstein about the Moon’s temperature at a wavelength of 2.77cm. The technique only uses power measurements from an observation of a radio source, at different angles from the boresight. Ideally, the radio source should be strong and point-like. It is also important that the angles at which the power measurements are made are known with good accuracy. This can be achieved either with a good rotator or by letting an astronomical object drift by on a dish that is left stationary.