Software – Daniel Estévez

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.

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.

Notes on debugging Rust microcontroller stack usage

A few days ago I was doing some refactoring of my galileo-osnma project. This is a Rust library that implements the Galileo OSNMA (open service navigation message authentication) system. The library includes a demo that runs in a Longan nano GD32VF103 RISC-V microcontroller board. The purpose of this demo is to show that this library can run on small microcontrollers. My refactoring was in principle a simple thing: I was mainly organizing the repository as a Cargo workspace, and unifying the library and some supporting tools into the same crate. However, after the refactor, users reported that the Longan nano software was broken. It would hang after processing some messages. This post is a collection of notes about how I investigated the issue, which turned out to be related to stack usage.

sigmf-toolkit

I have published a new Python package called sigmf-toolkit. It is intended to be a collection of Python tools to work with SigMF files. At the moment it only contains two tools, but I plan on adding more tools to this package as the needs arise. These tools are:

gr_meta_to_sigmf. It converts a GNU Radio metadata file with detached headers to a SigMF file. At the moment it is really simple, and it doesn’t handle capture discontinuities.
sigmf_pcap_annotate. This tool parses a PCAP file using Scapy and it adds annotations to a SigMF file for each packet in the PCAP file.

I find this sigmf_pcap_annotate tool quite useful when comparing side by side a SigMF file in Inspectrum and a PCAP file in Wireshark to debug issues with digital communications systems. In this post I showcase how this tool can be used.

n78 band 5G NR recordings

In my last post about 5G NR, which was part of a series in which I analyzed the signals in a short recording of an idle srsRAN gNB, I mentioned that I had already decoded all the signals that appear in the recording, and that to move on with my 5G series I would need to make and use some more complex real world recordings next.

A 5G band I’m particularly interested in is n78 (3.3 – 3.8 GHz TDD). This is being used to deploy 5G in many European countries, including Spain, as showed by this list in Wikipedia. Due to the large bandwidth available, it is common to see cells with 100 MHz bandwidth in this band.

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.

Z-Sat VHF transmissions

Z-Sat is a microsatellite by Mitsubishi Heavy Industries that was launched in 2021. It is a demonstrator for multi-wavelength infrared Earth observation technologies. It carries an amateur radio payload that was coordinated by IARU and which consists of a BBS (bulletin board system) with a 145.875 MHz downlink and 435.480 MHz uplink. I have not been able to find more information about the amateur radio payload on this satellite.

Recently, Daniel Ekman SA2KNG asked me to analyze some transmissions by this satellite. Apparently it has recently begun to transmit a digital modulation, as shown in this SatNOGS observation, while it typically had transmitted CW telemetry in the past. The point where this started appears to be on 2025-06-20, as there is a SatNOGS observation of CW telemetry on that day followed by an observation of the digital modulation. In this post I analyze this digital modulation and explain what it is.

5G NR PDSCH

In my previous post in the 5G NR RAN series, I showed how to decode the PDCCH (physical downlink control channel), which is used to send control information from the gNB (base station) to the UEs (cellphones). In this series I am using as an example a short recording of the downlink of an srsRAN gNB. The PDCCH transmission that I decoded in the previous post was a DCI (downlink control information) containing the scheduling of the SIB1 PDSCH transmission. The PDSCH is the physical downlink shared channel, which is the channel where the gNB transmits data. The SIB1 is the system information block 1. It contains basic information about the cell, and it is decoded by the UE after decoding the MIB in the PBCH, as part of the cell attach procedure. In this post I will show how to decode this PDSCH SIB1 transmission.

5G NR PDCCH

This is a new post in my series about the 5G NR RAN. As in previous posts, I am analyzing a short recording of the downlink of an srsRAN gNB. There are no UEs connected to the cell during this recording, so there isn’t much interesting traffic, but the recording contains all the essential 5G signalling. In particular, there is a SIB1 transmission in the PDSCH, with its corresponding transmission in the PDCCH.

The PDCCH (physical downlink control channel) is used to transmit control information to the UEs in the form of DCI messages (downlink control information). The most common types of DCIs are those that specify the scheduling parameters of transmissions in the PDSCH (physical downlink shared channel), and the uplink grants for UEs in the PUSCH (physical uplink shared channel). The role that the 5G PDCCH plays is very similar to the role that it plays in LTE, so my post about the LTE PDCCH can be good for more context. However, in 5G the channel coding and physical layer of the PDCCH is substantially different from LTE.