Hardware, built
to be flown.
Test racks, radios, power, boards and the code that runs on them — designed, built and proven on a bench that behaves like the mission. One team, from schematic to firmware.
HIL / SIL racks
A rack that behaves like the vehicle, so the flight computer can fail on the bench instead of on orbit.
We design and build hardware-in-the-loop and software-in-the-loop test racks: real-time plant models, I/O breakout for every sensor and actuator bus, fault injection, and a harness that matches the flight connector pin-for-pin. Software-only stages run the same scenarios without the hardware attached.
- —Real-time plant + environment models
- —Fault injection on every channel
- —Flight-identical harnessing and connectors
- —Scripted regression runs with logged evidence
RF
Front ends, links and test fixtures — measured, not assumed.
Transceiver front-end design, antenna and link budgets, filter and amplifier chains, and the fixtures to characterise them: conducted and radiated tests, noise figure, spurious emissions, and link margin under the conditions the mission actually sees.
- —Link budget and front-end architecture
- —Filter, LNA and PA chain design
- —Conducted + radiated characterisation
- —Fixtures and repeatable test procedures
Electrical
Power that stays up when the load does something you didn't plan for.
Power distribution, protection and sequencing; battery and bus management; grounding and EMI strategy; and the harness design that ties it together with a drawing package a technician can build from.
- —Power distribution and protection
- —Grounding, bonding and EMI/EMC strategy
- —Harness design with build-to drawings
- —Bus and battery management
Electronics
Boards designed for the environment they'll live in, then proven on a bench that reproduces it.
Schematic and layout for mixed-signal, high-speed and power boards; parts selection with derating and obsolescence in mind; signal and power integrity analysis; and bring-up with a test plan written before the first board arrives.
- —Mixed-signal and high-speed layout
- —Derating, parts and obsolescence review
- —Signal and power integrity analysis
- —Bring-up plans and test fixtures
Embedded software
Deterministic code on the metal, with the tooling to prove what it did.
Bare-metal and RTOS applications, board support packages, bus and sensor drivers, command and telemetry handling, and the logging and replay tooling that lets an anomaly be reproduced on the rack rather than argued about.
- —RTOS and bare-metal applications
- —Board support packages and bus drivers
- —Command, telemetry and fault handling
- —Logging, replay and on-target debug
FPGA
Where a microcontroller isn't fast enough, or deterministic enough.
RTL design and verification for signal processing, high-rate I/O, timing-critical control and protocol bridges; constraint-driven timing closure; and simulation testbenches that check the design against its requirements before it meets silicon.
- —RTL design in VHDL / Verilog
- —Simulation testbenches and coverage
- —Timing closure and constraints
- —Protocol bridges and high-rate I/O
Linux drivers
Custom silicon and off-board devices, visible to userspace the way the rest of the system expects.
Kernel drivers and device-tree work for custom boards and peripherals, platform bring-up on embedded Linux, DMA and interrupt handling, and the userspace interfaces and tooling that make the hardware usable by the application team.
- —Kernel drivers and device tree
- —Embedded Linux platform bring-up
- —DMA, interrupts and performance
- —Userspace APIs and tooling
Firmware
Bootloaders, updates and the code that has to be right the first time.
Secure boot and bootloaders, in-field update mechanisms with rollback, peripheral firmware for power, sensor and communication subsystems, and the programming fixtures and release process that get a known image onto every unit.
- —Bootloaders and secure boot
- —Field update with rollback
- —Peripheral and subsystem firmware
- —Programming fixtures and release control
Requirements in, evidence out.
[hil] run 0417 scenario=separation_sequence plant=v3.2 [io ] 128 ch armed harness=FLT-J4 pinmap verified [t+0.000] cmd ARM_PYRO fc-> ack bus=OK [t+0.250] sense SEP_SW_A expect=OPEN got=OPEN [t+0.250] sense SEP_SW_B expect=OPEN got=OPEN [t+0.312] fault INJECT bus_b_dropout 40ms [t+0.352] fc FDIR -> bus_a recovery=38ms PASS [t+1.000] telemetry rate 50Hz frames=50 dropped=0 [hil] run 0417 result=PASS log=./runs/0417.h5
Every run on the rack leaves a log like this one — the command, what the sensor was expected to read, what it actually read, the fault we injected, and how fast the flight computer recovered. That's the evidence pack you hand to a review board, and it's the same file we replay when something looks wrong six months later.
This log is illustrative of the format, not a record from a customer program.
Bring us the box.
A board that won't boot, a link that won't close, a rack you need before the next campaign — send the problem and we'll tell you what it takes.
Talk to engineering