---
title: "Mru Flight ran in orbit"
url: https://mru.space/research/flight-orbit/
description: "On 18 October 2026, v0.3.1 ran on ESA's OPS-SAT PRETTY as three software replicas on one processor, with injected faults: 2,745 correct results and 0 wrong."
---

[Research](https://mru.space/research/) / [Results](https://mru.space/research/?kind=results) / № 006

№ 006 · Results

# Mru Flight ran in orbit

On 18 October 2026, Mru Flight v0.3.1 ran on ESA's OPS-SAT PRETTY satellite. Three software replicas on one flight processor, faults from a schedule, and a prediction written two days before the run, met on every tick.

By **Will Binns** Published **18 Oct 2026** 6 min read Release [**v0.3.1**](https://github.com/mruspace/flight/releases/tag/v0.3.1) Experiment [**exp4051**](https://github.com/mruspace/flight/blob/main/docs/opssat.md) Raw files [**opssat/results**](https://github.com/mruspace/flight/tree/main/opssat/results)

## What ran

On 18 October 2026 at 09:45 UTC, Mru Flight v0.3.1 ran on ESA's OPS-SAT PRETTY satellite, as experiment exp4051 of the ESA OPS-SAT Space Lab. The experiment was registered on 7 October and the package was sent on 15 October: eleven days from registration to orbit.

The package is the fault-injection demo from release v0.3.1, built as a static 32-bit ARM binary. One entry point runs the shrinking quorum, then fixed triple redundancy (TMR), with the same seed and the same fault schedule (one tick is one voting round): a sensor self-test at tick 20, a bit flip in replica 2 at tick 60, replica 1 stuck at tick 120, replica 0 killed at tick 240. Each run has 110 seconds, a 5% share of the processor, 128 MB per process, and a 64 MB block of memory scanned for upsets every 250 ticks.

Status:Prototype, v0.3.1. One run in orbit, 227 seconds, on a Linux payload processor in user space. Not a hardware-redundancy test.

## Three hosts, the same events

The same binary ran three times: in ESA's software environment on 15 October (a Linux virtual machine, not the flight processor), on TU Graz's FlatSat on the flight processor on 16 October, and in orbit on 18 October. Every scheduled fault landed on the same tick on every host. No run gave a wrong result.

| Run | Shrinking quorum: correct, wrong, ticks | Fixed TMR: correct, then detected disagreements to tick | Total | Exit |
| --- | --- | --- | --- | --- |
| Software environment, 15 Oct | 14,886 · 0 · 29,532 | 239, to 19,250 | 222 s | 0, 0 |
| FlatSat, 16 Oct | 2,745 · 0 · 5,250 | 239, to 4,778 | 224 s | 0, 0 |
| In orbit, 18 Oct | 2,745 · 0 · 5,250 | 239, to 4,500 | 227 s | 0, 0 |

Tick counts follow the speed of the host: the virtual machine ran about six times as many ticks as the SEPP in the same 110 seconds. The FlatSat and the orbit run gave the same counts for the shrinking quorum. Total is both runs plus start-up and the result files, from the run-info times.

Hosts:The flight processor is the SEPP: an Altera Cyclone V SoC with two ARM Cortex-A9 cores at 800 MHz, 1 GB of memory and Linux 4.9. The demo ran in a container as an unprivileged user, in user space only.

## In orbit

The shrinking quorum retired the stuck replica at tick 122, two ticks after the fault. It ran alone on the last replica from tick 240, checked by known-answer tests (80 in the run). The memory scan at tick 250 found the injected flip and repaired it. After 5,250 ticks and 113.5 seconds it had delivered 2,745 correct results and 0 wrong, at about 46 ticks per second.

Fixed TMR, on the same faults, delivered 239 correct results. From tick 240 it had one good replica and one stuck one, and it detected a disagreement on every tick to 4,500 without delivering a result. On the last replica, where fixed TMR stops, the shrinking quorum keeps delivering checked results.

The voter used 65,992 KiB resident, almost all of it the 64 MB sensor block, and 5.2% of wall time including start-up. Each replica used 452 KiB.

Source:summary-shrink.txt, summary-tmr.txt and run-info.txt in [opssat/results](https://github.com/mruspace/flight/tree/main/opssat/results), the files the satellite sent down. The operations note is [docs/opssat.md](https://github.com/mruspace/flight/blob/main/docs/opssat.md).

![Timeline of the two runs in orbit by tick, with an axis break at tick 300. Faults at ticks 20, 120 and 240, and the memory scan at tick 250. The shrinking quorum delivers checked results to tick 5,250: 2,745 correct, 0 wrong. Fixed TMR delivers 239 correct results to tick 239, then detects 4,261 disagreements and delivers nothing to tick 4,500.](https://mru.space/charts/flight-orbit-light.svg)

Fig. 1 · Events as the program logged them on OPS-SAT PRETTY, from the files the satellite sent down. The axis breaks at tick 300: every fault lands before it, both runs go on past it. The bit flip in replica 2 at tick 60 is outvoted and leaves no event in the log, so it has no mark.

## What we said it would do

The prediction had five parts. The same events on the same ticks as on the FlatSat: met, every fault on its tick. About 2,700 correct results for the shrinking quorum: 2,745. 239 for fixed TMR: 239. Zero wrong results: zero. About 225 seconds in total: 227. We also wrote that any real upset would show as an extra sensor\_upset line in the log. There was none.

Prediction:Written to ESA on 16 October 2026 at 14:10 UTC, after the FlatSat test and before the run in orbit.

## What it shows, and what it does not

It shows that the policy runs on a flight processor, in user space, at a 5% share of the processor, and keeps delivering correct results on the last replica where fixed TMR stops. It shows that one binary gives the same events on a virtual machine, on the FlatSat and in orbit. For an operator, that answers one question: the policy behaves the same on the flight processor as on the ground.

It does not show more than that. The three replicas were software processes on one Linux processor, not three processors. The faults came from a schedule, not from the environment. The memory sensor saw no real upset in 227 seconds. The run used the demo voter and replicas, not the F⁠´ components. [Qualification evidence](https://docs.mru.space/concepts/qualification/) needs the F⁠´ version in orbit, real upsets and a long run. This run is the step before that.

One defect: both runs overran the 110-second cap by about 3 seconds. The limit is checked once per tick, and the last tick was a 64 MB scan. A fix is planned for the next version.

Scope:The 1.34× figure in [№ 002](https://mru.space/research/dusk-results/) comes from 10,000 simulated missions, not from this run. With no real upset in the window, the run calibrates nothing.

## Next

A second run of five minutes or less is proposed to ESA, with a hung replica, a stuck bit on the last replica, a safe halt and a resume across a restart. It is not scheduled. Until then, the numbers above are the whole record: one run, 227 seconds, zero wrong results.

Credit:ESA OPS-SAT Space Lab ran experiment exp4051 on OPS-SAT PRETTY. TU Graz operates the satellite and ran the FlatSat test.

[Previous · № 005 Mru Flight 0.2.0](https://mru.space/research/flight-measured/) [Back to Log](https://mru.space/research/)