Dr James Murphy, Founder & CTO, Setanta Space Systems
Space is nothing new to FPGAs. They’ve become crucial for high-speed communications, payload management, sensor data analysis, and critical control systems in satellites, rovers, and probes. As of February 2026, there were ~14,400 active satellites in space1, and that’s predicted to grow to 100,000 by 20302, driven mostly by the deployment of large, small-satellite constellations by companies such as Starlink and OneWeb.
This in turn has prompted the next big challenge for FPGAs: using AI to detect and manage anomalies like hardware malfunctions, software errors, and environmental impacts in small satellites to enable, improve and enhance real-time decision-making.
This automated approach is crucial because while satellites generate substantial amounts of data, only a fraction makes it to ground due to downlink bandwidth restrictions. They’re also limited when it comes to autonomy. If an error occurs on a satellite, it will either recover from it using pre-established procedures, or go into a safe state while waiting for an on- ground operator to analyze it. The trade-off here is the delay involved in the downlink cycle and the limited information that can be provided due to the download budget. This can potentially lead to the loss of the satellite and the premature end of the mission. To understand this further, an ESA-funded project was undertaken in partnership with University College Dublin (UCD), which built Educational Irish Research Satellite-1 (EIRSAT-1), Ireland’s first domestically produced satellite. This was based around a CubeSat, one of the smallest satellites you’re going to see in space. These follow the CubeSat architecture where 1U is 10cm x 10cm x 10cm. A 2U version was used in the EIRSAT-1 mission, but was still very small.
The satellite launched on a SpaceX Falcon 9 in December 2023 and de-orbited in September 2025 after fulfilling its mission parameters. Our work didn’t fly on EIRSAT-1, but we treated the project as a pseudo mission where we deployed AI models on-ground, but on hardware that could have flown on the mission, and using a live Flight Dataset from the mission downloaded in real time. That distinction allowed us to explore the constraints of real flight systems without the cost and risk of an actual launch.
Those constraints are severe because even the 2U CubeSats are small, they’re low power with only solar panels for power generation, and the vacuum environment adds thermal management problems. So there are a lot of issues that you encounter when you try to put electronics in space. On top of that, the worst thing about space is its radiation environment. That’s one of the reasons we looked at FPGAs for this project because you can make FPGAs resilient in those environments, whereas you can’t with other edge devices like GPUs.
Understanding the data
Every satellite, no matter how small, produces telemetry in the form of streams of data describing temperatures, voltages, currents, reaction wheel speeds, payload states, and countless other parameters.
EIRSAT-1 was no exception. It carried three payloads:
The Gamma-ray Module (GMOD), designed to detect and analyze gamma-ray bursts;
The ENBIO Module (EMOD), which tested advanced thermal management coatings on the exterior of the spacecraft;
and the Wave-Based Control (WBC) experiment, a UCD-developed software platform that used Earth’s magnetic field to orient the CubeSat.
Beyond the payloads, the satellite also had a full suite of telemetry, command, and data-handling systems which enabled communication with ground stations and transmission of scientific data back to Earth. Ground analysis of the data the satellite system provided was conducted for both nominal spacecraft operations and the onboard payloads.
This raw data was down-sampled from the satellite as hexadecimal bytes and a data dictionary broke the data stream into individual rows and subsequent features. Each row of features was then stored in a CSV file with a Row ID and a time stamp, resulting in a time-series dataset. This was the live Flight Dataset we could work with on the ground, and we could view it as a concatenation of a series of channels translated into a 2D image (figure 2).
The data in each dataset is divided into four categories:
Housekeeping, Telemetry-Enhanced-Diagnostics (TED), Attitude Control (ADCS), and Power. In our case, we were looking primarily at the Housekeeping telemetry which provides core health-and-status data. and our experiment was to develop an AI model for anomaly detection in that category.Building an unsupervised anomaly detection model
We took an unsupervised approach and trained the AI model using the EIRSAT-1 dataset as the data source. This actually consisted of three sub-datasets because every satellite sent to space has to go through a qualification campaign to make sure that it works. So alongside the live Flight Dataset, we also had the Flight Test Dataset and the Thermal Vacuum Test Dataset. The satellite suffered some failures during qualification, which is quite common given the advanced technologies involved, and we had some labeled data we could use to quantify how well our model was performing. We initially trained the AI model on the labeled artificial anomalies from the Flight Test dataset, before validating the trained model on the unseen Thermal Vacuum Test dataset in order to classify anomalies. We could then use the metrics and insights gained to deploy a model and threshold to the live Flight Dataset. At this stage, we had no idea if something was going to happen or not. If it did, we didn’t know if it was an anomaly or not since we were looking at unsupervised learning, so any highlighted regions were called Out of Ordinary Operations (OOO), which we referred to as “Uh-ohs”. Interestingly, we successfully detected all of the anomalies plus one that wasn’t picked up, which was an extremely good result (Figure 3).
We contacted the team and worked out the anomaly was payloads pairing on and off. So while it was an OOO rather than an anomaly, its detection helped to validate our model.
Deploying the model on FPGA hardware
We began our FPGA development on an AMD KCU105 Evaluation Kit and ended up moving to an AMD Zynq UltraScale+ MPSoC ZCU106 platform, which offered a more convenient and flexible pipeline for our deployment workflow.
The process required converting the original TensorFlow models into TFLite format, and then transforming those TFLite models into C header files suitable for use with TFLite for Microcontrollers. Along the way, issues within the TFLite repository required a complete refactoring of the build system. The resulting flow consists of two main stages: the first builds the TFLite libraries for the target microcontroller, and the second uses a separate makefile to compile the application itself against those precompiled libraries.
Despite the engineering hurdles, the performance results were encouraging. We benchmarked the FPGA implementation against a number of edge devices operating within a comparable 5-watt power envelope. That included the NVIDIA Jetson Orin Nano SoM, the Nano NX which was just above the envelope, the Intel Movidius Myriad X Vision Processing Unit (VPU), and the Raspberry Pi 4. All platforms achieved the required inference rate of 10–100 Hz and, although the FPGA landed toward the lower end of the performance range, it still comfortably met the demands of onboard telemetry workloads.
The really interesting thing here is that you’re not losing that much performance by going from the smaller edge devices to an FPGA, but you are gaining the resilience that FPGAs offer for space missions. That trade-off of a slightly lower performance for dramatically higher resilience is what makes FPGAs so attractive for spaceborne AI.
Autonomy in high-radiation environments
One of the driving factors is that if you’re deploying in low Earth orbit (LEO), most of the edge devices will last three to five years. The Nvidia Orin NX has been radiation-tested and the results say that it will fail within three years of LEO. The Myriad X has also been radiation-tested and it’s a little bit more resilient and will be around for five to ten years in LEO. And while Raspberry Pis are used in space, they’re susceptible to Single Event Upsets (SEUs) where memory becomes corrupted or the processor freezes due to radiation exposure, and are confined to auxiliary operations which can be briefly interrupted rather than critical operations.
All of that is in LEO and once you start pushing the envelope and leave LEO, you see substantially more radiation, and all of the edge devices will fail, except the FPGAs. That’s an issue because the push in the space sector now is autonomy in high radiation environments as well as low radiation environments.
A good example is NASA’s Perseverance Rover which, together with its Ingenuity Mars Helicopter, landed on Mars in February 2021. Ingenuity, which was actually a drone not a full-size helicopter, was only meant to be a technology demonstration that would make five flights in 30 days. It ended up making 72 flights over three years. It was the first aircraft to achieve powered, controlled flight on another planet and in many ways it also redefined Mars exploration.
It demonstrated that aerial rather than ground navigation could survey vast areas that would take wheeled vehicles months or even years to cover.
The Perseverance Rover and Ingenuity used radiation-hardened AMD and Microchip FPGAs, respectively, for tasks like image detection, matching, and rectification; range and velocity measurements; operational control and system management; and flight control and power conservation.
That’s why it’s really interesting to push for this autonomy, and when we’re looking at deep space missions, it becomes even more necessary. So I think it’s very promising for FPGAs in the space sector and always has been.
Our work with EIRSAT-1 telemetry demonstrated that unsupervised anomaly detection can be deployed on FPGA hardware without sacrificing mission constraints. It also showed that AI can detect both genuine anomalies and operational events like payload power cycles, offering valuable insights into spacecraft behavior.
Most importantly, it showed that the combination of AI and FPGAs is not just feasible, it’s promising. As missions push beyond LEO and into harsher environments, that combination may become essential.
We’ve made our research dataset publicly available at https://zenodo.org/records/11551556, so if you want to base your own models on satellite telemetry, please go ahead. It’s an open-source system, and if anyone wants to try and match us or beat us, our results are also available. Please do so because we want to make this a much better system for everybody.
- CelesTrak Active Satellites tracker, https://celestrak.org/NORAD/elements/table.php?GROUP=active&FORMAT=tle, accessed February 2026
- ‘Space Debris: Is it a Crisis’, The European Space Agency, https://www.esa.int/ESA_Multimedia/Videos/2025/04/Space_Debris_Is_it_a_Crisis, accessed February 2026
Cover and article artwork includes rendering of EIRSAT-1, @ESA; EIRSAT-1 team
