Software – Daniel Estévez

A high-sensitivity ADS-B receiver

Since the end of August I have been working on a new ADS-B receiver application that is intended to outperform existing open source receivers in scenarios with weak signals or message collisions. Now I have reached a point where this software is ready to be published. The name of this project is more1090, and it is a Rust application and library licensed under an Apache 2.0 or MIT license. The receiver operates at 8 Msps IQ and uses FFTs for signal detection. Therefore, it is much more CPU intensive than other ADS-B receivers such as readsb. It will probably not run on your Raspberry Pi (I haven’t tried; maybe there is a hope for the Pi 5 or other modern high-performance ARM boards), but it runs 4 times faster than real-time on a modern x86-64 laptop (the receiver is single-threaded, so the core count doesn’t matter), and it can decode way more messages than readsb.

The more1090 receiver only decodes Mode-S extended squitter replies (DF17 and DF18), which is how ADS-B is transmitted at 1090 MHz. Other receivers such as readsb also attempt to decode other Mode-S reply message types and even Mode-A/C replies. The challenge to decode other Mode-S message types is that only extended squitter and acquisition squitter (one particular use of DF11) are intended to be broadcast messages to be decoded by any receiver. The remaining messages are intended to be replies to an interrogator, to be decoded only by that interrogator. Their CRC is XORed with information only known to the interrogator, such as the ICAO address of the replier or the interrogator identification code. Therefore, it is difficult for another receiver to determine if it has decoded these messages without errors. Because of this, more1090 focuses on decoding extended squitter messages as best as possible and ignoring everything else. It is possible to decode acquisition squitter messages using a similar approach, but these messages only contain the ICAO address of the transmitter, so they are of limited interest, and decoding them is not implemented at the moment.

In addition to the ADS-B receiver, more1090 contains a signal simulator that can generate all types of Mode-S and Mode-A/C replies that appear at 1090 MHz in the real world. This simulator can generate both signal snippets containing a single message, which are useful for benchmarking things such as decode probability at a given CN0, and full scenarios which contain all message types with transmission times following a Poisson process. The full scenarios characterize the receiver performance in more realistic conditions.

At the moment this simulator doesn’t generate TACAN/DME signals. There are a few ground-to-air TACAN channels that are within 4 MHz of 1090 MHz: 125Y, 126Y, 1Y, 2Y, 3Y, 4Y, 5Y, 6Y, 7Y. These channels are used infrequently (an example is the SSY VOR/DME in Madrid, Spain, which transmits on 125Y at 1086 MHz). Additionally, there are also air-to-ground TACAN channels within 4 MHz of 1090 MHz: 62X, 62Y, 63X, 63Y, 64X, 64Y, 65X, 65Y, 66X, 66Y, 67X, 67Y, 68X, 68Y, 69X, 69Y, 70X, 70Y. Real world usage of these channels includes around 100 civilian VOR/DME, VORTAC or DME-only in channel 70X (1094 MHz) and a number of military TACAN in the remaining X channels. These are a potential source of interference to ADS-B and other secondary surveillance radar services at 1090 MHz.

The signal simulator is used for benchmarking the more1090 receiver, both in synthetic conditions (isolated messages at a fixed CN0) and in scenarios which are representative of a typical terrestrial receiver and a typical receiver on a LEO satellite.

In the rest of this post I explain more details about this new ADS-B receiver.

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.

Tianwen-2 low data rate telemetry

Thomas Telkamp has shared with me an IQ recording of the Tianwen-2 telemetry downlink made with the Bochum 20 metre antenna on June 8. This is part of an ongoing effort led by Peter Gülzow, AMSAT-DL‘s president, for closely monitoring Tianwen-2’s operations. All the material I have used in previous posts about Tianwen-2 has come from these activities.

This recording was made just before Tianwen-2 did a manoeuvre (recall that the orbital insertion at asteroid Kamo’oalewa was reported to be on June 7). During this recording Tianwen-2 was transmitting telemetry at a slower rate than the usual 16384 baud. This makes sense, given the fact that the attitude during the manoeuvre would be unfavourable. In this short post I decode this recording.

The only two configuration differences between the regular 16 kbaud telemetry and this lower data rate telemetry is that the baudrate is reduced to 4096 baud, and the frame size is reduced to 220 bytes. This means that a single Reed-Solomon codeword from the shortened (252, 220) code is used, instead of four interleaved Reed-Solomon codewords from the full (255, 223) code. The over-the-air frame duration is still one second.

The corresponding modifications to the GNU Radio decoder are simple. This plot shows the decoder running on the recording. The SNR is excellent.

GNU Radio decoder processing the Tianwen-2 low data rate recording

The contents of the telemetry frames are the same as the regular 16384 baud telemetry. There are very few differences. One difference is that the last two bytes of the AOS insert zone, which are always 0x300b in 16384 baud telemetry, are always 0x0001 in this 4096 baud telemetry. I don’t know what these bytes mean, and this difference doesn’t give me a clue either.

Almost all the same APIDs as in the regular telemetry are present, although their transmission rate is reduced due to the lower data rate. Comparing, I see that only APIDs 1553 and 1554 are missing in the low rate telemetry.

The GNU Radio decoder used in this post is here, the Jupyter notebook is here, and the binary file containing the decoded frames is here.

An update about Tianwen-2 telemetry

Yesterday I posted about my decoding of some recordings of the X-band telemetry of Tianwen-2 done by the Dwingeloo radio telescope. Today I have some small updates.

First of all, I have figured out the format of the AOS insert zone. In the previous post I mentioned that the AOS insert zone contains 8 bytes that are mostly static, except for one byte that seems to be a frame counter. I suspected that the AOS insert zone would contain timestamps, which was the case with Tianwen-1, but this didn’t seem to be the case with Tianwen-2. However, today I have found that the 8-byte insert zone contains a 6-byte timestamp in little endian format that counts the number of \(2^{-16}\) second ticks since the epoch, which is 2019-12-31 16:00:00 UTC (or 2020-01-01 00:00:00 Beijing time). The remaining two bytes have the constant value 0x300b. I don’t know what these two bytes are, since they don’t seem to be a CCSDS time code P-field.

There were two things about this timestamp field that were confusing me: the fact that it is little-endian, since CCSDS and the telemetry data in the Space Packet payloads is always big-endian, and the fact that these AOS frames take exactly one second to transmit. This means that the change in the timestamp in each frame is just an increment in the byte corresponding to seconds, which carries over to the next bytes on overflows, plus a very slow drift in the least significant byte caused by the relative drift of the symbol rate clock and the spacecraft clock. Only now that I’ve seen how this field evolves during longer periods of time, I have been able to figure its format.

Using an epoch in Beijing time instead of UTC is common in Chinese spacecraft. For instance, Tianwen-1 uses 2016-01-01 00:00:00 Beijing time as its epoch.

The second update is that AMSAT-DL has been tracking Tianwen-2 with their 20 m dish in Bochum and decoding the telemetry signal in real time with SatDump. They have shared the decoded AOS frames with me, and I have run them through my Jupyter notebook. They have collected a good amount of data: a few hours on May 26 and a full track of about 10 hours on May 27. This data is what has given me the clues to figure out how the timestamps work. The following plot shows the APIDs received over time. This indicates that there are no APIDs that are only active occasionally.

Even though now we have a much longer time span of data, the qualitative behaviour of the telemetry is still the same as I mentioned in the last post. The Jupyter notebook where I analyse the frames received by Bochum is here.

Decoding Tianwen-2

Tianwen-2 is a Chinese mission that will return samples from the Earth quasi-satellite asteroid 469219 Kamoʻoalewa and rendezvous with the 311P/PanSTARRS comet. It was launched on 28 May 2025 from the Xichang Satellite Launch Center. It is planned to perform its orbital insertion at Kamoʻoalewa on 7 June 2026, and study the asteroid until 24 April 2027. Since ephemerides for this mission are not publicly available, it has been difficult for amateur observers to track it so far, but now it is close enough to Kamoʻoalewa to find it by pointing around the asteroid.

On Monday, CAMRAS used the 25 meter Dwingeloo radio telescope to receive and record the X-band telemetry signal from Tianwen-2, publishing the SigMF recordings in their data archive. They reported that the spacecraft was 1.1 degrees away from the asteroid. In this post I will decode and analyse the telemetry using these recordings.

Getting peak TOPS on a Ryzen AI 7 350 NPU

I have a Framework Laptop 13 that has a Ryzen AI 7 350 CPU that includes an NPU. I have started playing with this NPU to understand how to develop software for it. While NPUs are mainly intended as accelerators for inference of ML models, they are fundamentally hardware accelerators for matrix multiplication and other similar linear algebra operations, so they are also useful for signal processing and other compute applications, which is why I am interested in them. Another reason why I am interested in this NPU is that, as I will explain below, it is very similar to the AIE-ML v2 AI engine in Versal FPGA SoCs, so this laptop is a great platform to learn how to use this AI engine.

NPUs use the concept of TOPS (tera operations per second) as a high-level marketing figure of their capabilities. An operation is generally understood as an addition or multiplication for int8 data types, since the amount of parallelization that can be achieved depends on the datatype width. The NPU on the Ryzen AI 7 350 is marketed as a 50 TOPS NPU. The main goal of this post is to understand where this number comes from, in terms of hardware execution units and capabilities, understand under which conditions it can be reached, and write a small application that reaches this TOPS value.

I think this is a good way of gaining in-depth understanding about a compute architecture. Most typical real world use cases are going to be slower than this, because the algorithms will have bottlenecks that result in hardware underutilization. By understanding how the hardware needs to be used to reach peak performance, we have a better idea of the gaps of these algorithms and also how to rewrite the algorithms to reduce the gap if possible. In a post last year about NEON kernels on the ARM Cortex-A53 I worked in a similar way, by choosing a simple kernel to accelerate and by comparing performance benchmarks with the peak performance allowed by the hardware.

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.

Tooling for CSP

CSP is the Cubesat Space Protocol. It is a network protocol that was developed by Aalborg university, and is commonly used in cubesats, in particular those using GOMspace hardware. Initially the protocol allowed different nodes on a satellite to exchange packets over a CAN bus, but eventually it grew into a protocol that spans a network composed by nodes in the satellite and the groundstation that communicate over different physical layers, including RF links.

Recently I have been working on a project that involves CSP. To measure network performance and debug network issues, I have written some tooling in Rust, as well as a Wireshark dissector in Lua. The Rust tooling is an implementation from scratch and doesn’t use libcsp. Now I have open sourced these tools in a csp-tools repository and csp-tools Rust crate. In this post I showcase how the tools work.

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.