MRU-FIELD
A guest node for the W1M3A buoy: technical summary for CNR
A small industrial Linux board in a DIN-rail case that runs Mru's fault-tolerance software and injects faults into itself on a stored schedule. To the buoy it is one more guest instrument: DC power in, a short ASCII record out, nothing needed from shore.
The node
Reference board: Sfera Labs Strato Pi CM Duo with a Raspberry Pi Compute Module 4S, a plug-in industrial module your lab can mount and wire like your own equipment. Vendor figures; the node is not built yet.
| Item | Value | Note |
|---|---|---|
| Size | 36.3 × 90.5 × 62.0 mm | Two-module DIN-rail case, included in the figure. |
| Mass | 160 g | Including the Compute Module. |
| Supply | 9 to 28 V DC, 24 V nominal | Reverse-polarity protection, 1.1 A resettable fuse. 12 V or 24 V bus. |
| Draw, vendor | 12 V: 170 mA low, 410 mA full 24 V: 100 mA low, 220 mA full | 2.0 W low and 4.9 W full on 12 V; 2.4 W and 5.3 W on 24 V. |
| Draw, this run | About 2 W average, under 6 W peak | About 50 Wh a day continuous. Mru caps its CPU share at 5%. Measured on the bench before shipping. |
| Power allowance | Whatever you can give | Power it on a schedule (10 minutes per hour is about 8 Wh a day), shed it first when the bank runs low, or run it continuously. It survives every cut. Rationing is the experiment. |
| Temperature | -20 to +50 °C operating | -30 to +80 °C storage. |
| Data out | 1 line per hour, about 200 bytes | Under 10 kB a day, down to 1 kB if the link is tight. NMEA-style line, CSV, or a file over Ethernet, to match your logger. |
| Interfaces | RS-485, Ethernet 10/100, 2 × USB 2.0 | RS-485 half-duplex, optoisolated, 1,200 to 115,200 baud. You pick one. RS-232 via USB adapter if you prefer. |
| Data in | None required | Optional: a copy of one buoy data stream, so data triage runs on real data. |
| Resilience | 2 × microSD, watchdog, RTC | Boot failover between two industrial cards, read-only root, capped logs. Restarts after a cut and resumes from the clock. |
| Radio, own battery, wet or moving parts | None | Wireless off, no antenna. Power from the buoy, so no lithium on board; ships as a parcel. |
Vendor figures: Sfera Labs product page and Raspberry Pi documentation, read 16 October 2026.
What the node needs, and what it never needs
- A dry slot in the electronics enclosure: a DIN rail, or a flat surface for the clip.
- One DC feed from the buoy's battery bus, 12 or 24 V, under 0.5 A, that you can switch off at any time.
- One serial or Ethernet line into the acquisition and control system, so the hourly record rides your satellite transmission.
- Commands from shore.
- Its own antenna or modem.
- A hull penetration, or anything in the water.
- A battery of its own. It runs on the buoy's DC bus.
- Attention between service visits.
Who supplies what
| Northforge | CNR lab, as hardware adaptation |
|---|---|
| Board and Compute Module, two microSD cards, software image, fault schedule, bench test before shipping, remote reading of the record during the run. | Mounting (DIN rail or bracket), DC and data cables and connectors, the line in your acquisition software that stores the record, installation and recovery on planned service visits. |
EMSO's grant covers "hardware adaptations (mechanical and electrical)" so a facility can host a user's equipment. We propose these parts and your hours sit in the "Funding for Regional Facility" column, so EMSO pays CNR directly.
The path we would like
A short trial at your test site at the Port of Genoa, then offshore on a planned service visit, staying aboard until the next one. The 12-week experiment runs inside that window, and anything beyond it is extra data. If space and power are easy for you, the node can be three small boards instead of one, one processor per replica. One board is the safer first deployment.
What runs on the node today
Mru builds software for systems that cannot be repaired after deployment, so that the hardware keeps doing useful work as it decays. Ocean nodes and spacecraft share that constraint, and they run the same code.
Mru Flight 0.3.1, the same build that ESA ran in its OPS-SAT software environment on 15 October 2026 (experiment exp4051). Three replica processes compute the same result each cycle. A voter keeps the quorum: vote on three, compare on two, self-check on one with known-answer tests. It keeps a health record per replica, counts memory upsets in a scanned block, and logs every decision. Static binary of 642 to 675 kB, about 2 MB per process, CPU share capped at 5%.
Faults
| Who injects | Fault | Status |
|---|---|---|
| The node, on its schedule | Replica kill, hang, stuck output, bit flip in working memory, stuck bit, sensor self-test flip, random upsets, common-mode upsets. | Runs today |
| You, at any time | Power cut, with no warning. | A real fault, welcome |
| The node, buoy build | Power-budget step-down (the node rations a declining energy allowance) and sensor loss. | Planned, built before deployment |
One measured result, with its scope
Under injected faults on general-purpose processors, the shrinking quorum delivered 1.25 to 3.00 times the correct results of fixed triple modular redundancy, and never fewer, in 150 of 150 run pairs. Bench on three hosts, 11 October 2026, 20,000 ticks per run. Not flight hardware, not yet a board.
In ESA's OPS-SAT software environment, with one replica stuck and one killed in the first 240 ticks, the same build delivered 14,886 correct results in a 110-second run. Fixed TMR delivered 239, then only detections. One run, two Arm cores, 5% CPU share.
Twelve weeks
- Weeks 1 to 2. Healthy baseline in both modes.
- Weeks 3 to 10. Scheduled faults, one every few days. Fixed-redundancy mode and shrinking-quorum mode alternate in matched periods on the same hardware, so no second node is needed.
- Weeks 11 to 12. Recovery of retired replicas, end state, final log.
Measured: correct results delivered per day, time to recover from each fault, results lost per fault, and energy per correct result once the power-budget step-down exists. A twin node in Faial runs the same schedule on the bench.
What W1M3A gets
- The fault log and the field data, published through EMSO in the format you use (NetCDF on ERDDAP, if that suits), with CNR named as host.
- Co-authorship on the field paper. A journal article and a conference paper are planned.
- A free reliability analysis of the buoy's own failure and maintenance history with Dusk, Mru's fault simulator, if you share the logs: which parts limit unattended time, and by how much.
- First access to the software for your own acquisition system. The node can stay aboard after the 12 weeks.
To settle on the call
- The slot, the DC bus voltage, the power allowance (continuous, scheduled, or shed first), and the line into your acquisition system: serial or Ethernet, and the record format you prefer.
- The 2027 service visits: which one installs, which one recovers. EMSO says the activity starts in Q2 2027 at the earliest.
- Access Units: which kinds apply to a hosted guest (remote hosting, remote co-development, in person), the days of each, and the unit price, so the budget lists them by action as your in-kind contribution. The Letter of Intent estimated about 73 AU: 5 for interface design, 3 for integration, 65 for 12 weeks of remote hosting.
- Where the line sits between hardware adaptation, which EMSO funds through CNR, and our own equipment.
- Logistics and liabilities: shipping to Genoa, installation and recovery by your team (I come to Genoa for the integration and the port trial), insurance for the node on the buoy, early failure, and return at the end.
- What would make the results usable for you: which of your own data or health signals the node should carry, and what you want measured.
- The cut-off, 31 October or 31 December, and who signs the proposal as facility manager and when you can review the draft.
- Whether someone from CNR joins the user group as a team member.