• 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.

  • Tianwen-1 safe mode telemetry

    On 2026-08-02, Peter Gülzow, AMSAT-DL‘s president, noticed that Tianwen-1 was transmitting very low rate telemetry, in contrast to the usual 16 kbaud telemetry. This is typical of a safe mode configuration, since it allows decoding even when low gain antennas are used and the attitude is unfavourable. Peter made a couple of short IQ recordings. Mars was setting in Bochum, at an elevation of 4º, when the recordings were done, so he could not record for longer. After this event, Tianwen-1 has been operating again nominally with 16 kbaud telemetry, so we do not know the details of what happened. In this post I will analyse the safe mode telemetry signal.

  • 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.

  • 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.


5g 10ghz artemis1 astronomy astrophotography ATA ccsds ce5 contests digital modes doppler dslwp dsp eshail2 fec filters freedv frequency gmat gnss gnuradio gomx hermeslite hf jt kits lilacsat limesdr linrad lte microwaves mods noise ofdm orbital dynamics outernet polarization radar radioastronomy rust satellites sdr signal generators tianwen vhf & uhf