dsp – Daniel Estévez

X-engine correlator on a Ryzen NPU

Back in May I wrote a post explaining the architecture of AMD NPUs and demonstrating a simple kernel that reaches close to the peak TOPS allowed by the hardware resources. That program was very simple and there was no data movement between the NPU compute tiles and the rest of the system. After writing that post, I wanted to write a more complex program to understand better the NPU architecture and the software stack, and what the challenges are when working on real-world projects.

I decided to implement an X-engine correlator, such as the ones commonly used in radio astronomy. This is a problem that I’m personally interested in, and it is basically a big matrix multiplication, with some small caveats that I will explain below. As the main goal of NPUs is to be used for matrix multiplication in machine learning inference, I thought “how hard can this be?”. After a few months of working on and off on this project, I now have something ready to show.

The design has actually been quite challenging. There are many nuances I will get into below, and many dead-end paths I have taken until I discovered that when using some particular approaches performance would be killed for one reason or another, so I had to backtrack multiple times. I should also mention that while it is usually very clear what is happening at low level (which was one of the main messages of my previous post), the lack of flexibility of the hardware is often quite limiting, in particular regarding the programmability of the DMA engines, so it is quite challenging to design approaches that actually work well in the hardware.

This post is a full presentation of my X-engine implementation.

ORI’s lunar descent CTF

Open Research Institute has recently published the solutions for a Lunar Descent CTF that they ran at BSides San Diego 2026. The CTF revolves around the Ka-band radio altimeter used by the Chandrayaan-3 lunar lander. The CTF includes a simulation of the radio altimeter and the goal is to discover why the lander is crashing in this simulation and fix the problem. The CTF is in the Github repository OpenResearchInstitute/lunar-descent-ctf, which includes both the CTF and the solutions (in a spoilers directory). This seemed like an interesting topic, and in the past I have enjoyed a lot other CTFs that were organized by Michelle Thompson, so I decided to clone the repo, delete the spoilers directory, and start playing. In this post I comment on the CTF and my solution, so read no further if you don’t want to see spoilers.

PLL coefficients for rate-only feedback

A couple years ago I wrote a post about the paper Controlled-Root Formulation for Digital Phase-Locked Loops, by Stephens and Thomas. In this paper, the authors study digital PLLs by studying the transfer function in discrete time, rather than doing any continuous-time approximations or equivalences. They give values for the loop coefficients that are needed to achieve a certain noise bandwidth for some standard loop root placements (the supercritical damped response and the standard underdamped response). In general, the loop coefficients are obtained numerically. In my post, I show that in the case of a loop of order 2 with supercritical response the loop coefficients can be calculated explicitly in terms of the loop bandwidth by using the solution of a cubic equation. However, in that post, I treated only the phase/phase-rate feedback case. In this post I cover the rate-only feedback case.

Decoding the NB-IoT downlink

Recently I have been posting about V16 beacons, which are car emergency warning beacons that have been introduced this year in Spain, and which use the LTE NB-IoT cellular network to transmit their geolocation data to the traffic authority network when they are switched on. As part of experimenting with these beacons, I made recording of the downlink and uplink NB-IoT signals while the beacon was sending data to the network. My hope was to be able to decode these signals and extract the two-way traffic that shows how the beacon attaches to the LTE network and sends its data. I already decoded all the uplink transmission in a previous post. In this post I will decode the corresponding recording of the downlink channel.

However, as I already suspected when I was decoding the uplink recording, due to how I physically set up the experiment to avoid saturating the SDR receiver with the beacon transmissions, it turns out that the beacon was talking to an NB-IoT cell that is relatively weak in the downlink recording. More specifically, the antenna for the SDR receiver was set up near a window in the north side of the house, while the beacon was placed on the window sill on the south side of the house. The SDR receiver sees strong downlink signals from cell 145, which is located northeast of the house and is the cell to which the beacon connected in a previous experiment I did with the beacon placed in the north window. However, in this experiment with the beacon on the south window, the beacon connected to cell 261, which is southwest of the house. The signal from this cell is weaker in the downlink recording and is frequently overwhelmed by the signals from cell 145 and other strong cells. So I have had partial success decoding the transmissions that the network sent to the beacon.

This post is mainly about the NB-IoT downlink in general. At the end I focus on the downlink transmissions to the V16 beacon that I have been able to decode. It is a rather long post, because I cover all the main physical channels and signals of the NB-IoT downlink. I show how the NPSS and NSSS primary and secondary synchronization signals and the NRS reference signals work, how to decode the MIB-NB in the NPBCH, how to decode the SIB1-NB and SI messages carrying other SIB-NBs, how to decode NPDCCH transmissions in the Type1 common search space, which corresponds to paging, as well as decoding the corresponding NPDSCH transmissions carrying paging messages, how to do blind decoding of NPDCCH transmissions in the Type2 common search space and UE-specific search space, which correspond to uplink grants and downlink scheduling, and decode the corresponding NPDSCH transmissions that send data to the V16 beacon.

The recording used in this post is published in the dataset Recording of the NB-IoT downlink of a V16 beacon in Zenodo.

V16 beacon full uplink conversation

In my previous post I decoded a transmission from a V16 beacon. The V16 beacon has mandatorily replaced warning triangles in Spain in 2026. It is a device that contains a strobe light and an NB-IoT modem that sends its GNSS geolocation using the cellular network. It is said that the beacon first transmits is geolocation 100 seconds after it has been powered on, and then it transmits it again every 100 seconds. In that post I recorded one of those transmissions done after the beacon had been powered on for a few minutes and I decoded it by hand. I showed that the transmission contains a control plane service request NAS message that embeds a 158 byte encrypted message, which is what presumably contains the geolocation and other beacon data.

In that post I couldn’t show how the beacon connects to the cellular network and sets up the EPS security context used to encrypt the message, since that would have happened some minutes before I made the recording. I have now made a recording that contains both the NB-IoT uplink and the corresponding NB-IoT downlink and starts before the V16 beacon is switched on. In this post I show the contents of the uplink recording.

Decoding a V16 beacon

The V16 beacon is a car warning beacon that will mandatorily replace the warning triangles in Spain starting in 2026. In the event of an emergency, this beacon can be magnetically attached to the roof of the car and switched on. It has a bright LED strobe light and a connection to the cellular network, which it uses to send its GNSS position to the DGT 3.0 cloud network (for readers outside of Spain, the Spanish DGT is roughly the equivalent of the US DMV). The main point of these beacons is that placing warning triangles far enough from a vehicle can be dangerous, while this beacon can be placed without leaving the car.

There has been some criticism surrounding the V16 beacons and their mandatory usage that will start in January 2026, both for economical and implantation roadmap reasons, and also for purely technical reasons. The strobe light is so bright that you shouldn’t look at it directly while standing next to the beacon (which makes it tricky to pick it up and switch it off), but I have heard that it is not so easy to see in daylight from several hundreds of meters away.

The GNSS geolocation and cellular network service is also somewhat questionable. I purchased a V16 beacon from the brand NK connected (certificate number LCOE 2024070678G1), for no reason other than the fact that it was sold in a common supermarket chain. The instructions in the box directed me to the website validatuv16.com for testing it. In this website you can register the serial number or IMEI of your beacon and your email. Then you switch on the beacon. After 100 seconds the beacon should send a message to the DGT network, and then periodically every 100 seconds. This test service is somehow subscribed to the DGT network, and it sends you an email that contains the message data (GNSS position and battery status) when the DGT network receives it. This is great, but there is no test mode or anything that declares that you are using the beacon just for testing purposes. They only say that you should not leave the beacon on for much longer than what it takes you to receive the email, to avoid the test being mistaken for a real emergency. The fact that the test procedure for this system is literally the same as the emergency procedure is a red flag for me. Additionally, this beacon only includes cellular data service for 12 years, and it is not clear what happens after that.

Technical shortcomings aside, my main interest is how the RF connection to the DGT network works. The beacon I bought has a logo in the box saying that it uses the Orange cellular network. When I tested it, after receiving the confirmation email from the test service, I used a Pluto SDR running Maia SDR and quickly found that the beacon was transmitting NB-IoT on 832.3 MHz. I made a recording of one of the periodic transmissions. In this post I analyse and decode the recording.

First analysis of the Lunar GNSS Receiver Experiment data

The Lunar GNSS Receiver Experiment (LuGRE) is a NASA and Italian Space Agency payload that flew in the Firefly Blue Ghost Mission 1 lunar lander. An overview of this experiment can be found in this presentation. The payload contains a Qascom GPS/Galileo L1 + L5 receiver capable of both real time positioning and raw IQ recording, and a 16 dBi high-gain antenna that was pointed towards Earth. For decades the GNSS community has been talking about using GNSS in the lunar environment, and LuGRE has been the first payload to actually demonstrate this concept.

The LuGRE payload ran a total of 25 times over the Blue Ghost mission duration, starting with a commissioning run on 2025-01-15 a few hours after launch and ending with a series of 9 runs on the lunar surface between 2025-01-03 (the day after the lunar landing) and 2025-01-16 (end of mission after lunar sunset). Back in October 15, the experiment data was published in Zenodo in the dataset Lunar GNSS Receiver Experiment (LuGRE) Mission Data. This dataset includes some short raw IQ recordings, as well as output from the real time GNSS receiver (raw observables, PVT, ephemeris and acquisition data). Since I have some professional background implementing high-sensitivity GNSS acquisition algorithms and I find this experiment quite interesting, I decided to do some data analysis, mainly of the raw IQ data.

The initial results of the experiment were presented on September 11 in the ION GNSS+ 2025 conference in a talk titled Initial Results of the Lunar GNSS Receiver Experiment (LuGRE). This talk is only available to registered ION attendees. As I don’t want to resort to my network to scrounge some ION paper credits (which is how proceedings are usually downloaded from the ION website), I haven’t seen anything about this talk besides the abstract. It is quite possible that something of what I will mention here was already presented in this talk. This is what we get as a society for not doing science in a completely public and open way. However, it’s interesting that this also makes my analysis less likely to be biased. I’ve just downloaded some raw IQ data and started looking at it with only basic context about the instrument that produced it and how it was run.

For a first analysis, I have implemented a high-sensitivity acquisition algorithm for the GPS L1 C/A signal in CUDA. I have run this on all the 20 L1 IQ recordings that are available. In this post I present the algorithm and the results.

Non-coherent m-FSK BER

Yesterday I posted about how to compute the well known formula for the bit error rate of FSK with non-coherent demodulation. Later I realized that the same kind of argument can be extended to cover the case of \(m\)-FSK in which the \(m\) tones are orthogonal. The formula for this is not so well known, and I don’t recall having seen it before, although surely it is somewhere in the literature. Here I show the calculations and the closed-form expression that is obtained.

Non-coherent FSK BER

It is well known that the formula for the bit error rate of 2-FSK using non-coherent demodulation is \(\exp(-\frac{E_b}{2N_0})/2\). However, I can never quickly find a source where this formula is derived, so I decided to figure this out and write down the derivation. I will use my post about m-FSK symbol error rate as a starting point.

About FLLs with band-edge filters

Using band-edge filters for carrier frequency recovery with an FLL is an interesting technique that has been studied by fred harris and others. Usually this technique is presented for root-raised cosine waveforms, and in this post I will limit myself to this case. The intuitive idea of a band-edge FLL is to use two filters to measure the power in the band edges of the signal (the portion of the spectrum where the RRC frequency response rolls off). If there is zero frequency error, the powers will be equal. If there is some frequency error, the signal will have more “mass” in one of the two filters, so the power difference can be used as an error discriminant to drive an FLL.

The band-edge FLL is presented briefly in Section 13.4.2 of fred harris’ Multirate Signal Processing for Communication Systems book. Additionally, fred also gave a talk at GRCon 2017 that was mainly focused on how band-edge filters can also be used for symbol timing recovery, but the talk also goes through the basics of using them for carrier frequency recovery. Some papers that are referenced in this talk are fred harris, Elettra Venosa, Xiaofei Chen, Chris Dick, Band Edge Filters Perform Non Data-Aided Carrier and Timing Synchronization of Software Defined Radio QAM Receivers and fred harris, Band Edge Filters: Characteristics and Performance in Carrier and Symbol Synchronization.

Recently I was looking into band-edge FLLs and noticed some problems with the implementation of the FLL Band-Edge block in GNU Radio. In this post I go through a self-contained analysis of some of the relevant math. The post is in part intended as background information for a pull request to get these problems fixed, but it can also be useful as a guideline for implementing a band-edge FLL outside of GNU Radio.