Evidence
Demonstrated behavior, presented with its boundary.
Nexus Atlas pairs every headline number with the environment in which it was observed. Controlled demonstrations and automated tests show behavior; they do not replace customer-specific integration, pilot and qualification evidence.
Hemus 2026
Four days. Eight nodes. Heterogeneous paths.
Nexus Atlas ran on two ground-control laptops, five Raspberry Pi relay nodes and one UAV. MAVLink command, H.265 video and gimbal traffic continued through repeated physical path cuts and injected loss, delay and jitter.
Up to six heterogeneous underlay types were available in the demonstrated setup, including serial telemetry radio, Bluetooth, Wi-Fi ad-hoc, 802.11s mesh and Ethernet.
No live RF jamming was performed. This is not customer deployment evidence, a production availability figure or an SLA claim.
What the demonstration establishes
Real software, mixed hardware and visible failure.
The value of the demonstration is the combination of a real fleet, real application traffic and repeatable physical or software-induced path impairment.
Mixed platform fleet
The same communications layer operated across laptops, small relay computers and an airborne node.
Heterogeneous underlays
Paths with different speeds, interfaces and operational characteristics contributed to one logical network.
Physical path loss
USB radio power and cables were physically cut in addition to repeatable software impairment.
Application continuity
Command, video and gimbal traffic exercised the network while paths changed.
Multi-node topology
Relay nodes participated in the logical network instead of limiting the demonstration to one endpoint pair.
Repeated operation
The setup ran across four exhibition days rather than one isolated laboratory transaction.
Field flight trial
The same software, in the air, as one mesh.
A ground station, a mast carrying omnidirectional and directional antennas, and two aircraft were all members of a single mesh — every one of them a routing member relaying for the others, not an endpoint hanging off a link.
Multi-link bonding, the scheduler in broadcast, traffic classes and traversal of a carrier-grade NAT all ran airborne. Links were made and lost by distance and antenna pattern as the aircraft moved, rather than by a path being cut on the ground.
This was our own flight trial. No live RF jamming was performed, and it is not customer deployment evidence, a production availability figure or an SLA claim.
Typically configured between 0.1 and 0.75 seconds per deployment.
The configured interval controls how often traffic weighting can be reconsidered as path conditions change. It is not a universal dead-link declaration or application-recovery guarantee.
Every two minutes, with zero packet loss in the end-to-end test.
Make-before-break session rotation kept the previous session available for in-flight packets. The result describes that automated test boundary, not every external network condition.
p50 0.18 ms / p95 0.42 ms added latency, self-measured.
The daemon continuously measures what its own pipeline adds — transmit, queue wait, receive, reassembly — and publishes the ledger through its API. The figures describe the reference measurement environment and are reproducible from any node’s statistics endpoint.
Three 30%-loss links delivered ~2.7% effective loss.
In the scripted broadcast-mode demonstration, three links each forced to 30% packet loss produced roughly 2.7% end-to-end loss. The arithmetic case — three independent links at 2% loss yielding 0.0008% — describes the same mechanism at realistic loss rates.
End-to-end tests across the workspace and adapters, on every change.
Two real daemons over real interfaces exercise handshake, link-kill failover, roaming and rekey under load. Coverage includes core transport, protocol, QoS, erasure recovery, Traversal, terrain components, daemon behavior and radio adapters.
Direct discovery, CGNAT relay paths and hole punching built and tested.
End-to-end harnesses exercise two peers behind simulated CGNATs, hosted relay/exit locations in the EU and North America are live, and traversal of a carrier-grade NAT ran in the flight trial. The stack is not presented as a customer-site deployment.
Per-class priority, deadline, store-carry-forward and recovery components are opt-in.
They are implemented and tested, and traffic classes ran in the flight trial; the complete capability set is not deployed across the Hemus demonstration fleet.
Software assurance
Built for technical due diligence.
Engineering evidence extends beyond the live data path into release integrity, dependency visibility and controlled Linux deployment.
Memory-safe Rust core
The core data plane is implemented in Rust, reducing exposure to common memory-safety defects in systems software.
Automated and end-to-end tests
Unit, integration and network-namespace suites cover failover, roaming, rekeying, Traversal and supporting components.
Verifiable artifacts
Checksums, cosign signatures, CycloneDX software bills of materials and SLSA Level 3 build provenance are produced by the release pipeline, with an auditor verification recipe in the documentation.
Hardened operating model
Linux service profiles, deployment automation, diagnostics and operational APIs support customer-controlled integration.
Procurement boundary. These artifacts support security, supply-chain and regulatory review. They do not by themselves constitute certification or complete legal compliance. The trust page carries the full posture and the certification roadmap.
No invented customer or production-availability claims.
Hemus was a controlled relevant-environment demonstration and the flight trial was run by our own team; neither is sustained operation on an end-user production network.
No claim of live RF jamming, at Hemus or in the air.
The demonstration used physical path cuts and software-injected loss, delay and jitter; the flight trial lost and regained links through distance and antenna pattern. Live RF testing requires an appropriate controlled environment.
Linux and IPv4 inner traffic today.
The current daemon targets Linux. Underlay endpoints can use IPv4 or IPv6; the inner logical tunnel remains IPv4.
Atlas mesh relays are trusted participating nodes.
They decrypt one protected hop and re-encrypt toward the next. Hosted Traversal relay frames use a different, opaque end-to-end model.
Android, terrain scheduling and cross-layer control retain explicit maturity labels.
The Android build runs the engine on real devices but remains an evaluation build; terrain analysis is not yet connected to live scheduling; TDMA and L2 coordination remain research directions.
From evidence to qualification
Each step earns the next.
A useful evaluation moves from a visible product behavior to the customer’s actual compute, communications equipment, RF environment and acceptance criteria.
Brief
Agree the operational problem, links, traffic, constraints and success criteria.
Demonstrate
Introduce visible, controlled failures in a repeatable representative setup.
Pilot
Move onto customer compute, real links, applications and operating conditions.
Qualify
Record the evidence required for the actual platform, programme and deployment owner.