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.
0.1–0.75 seconds, configurable by 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.
580+ automated tests across the workspace and adapters.
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. 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, but the complete capability set is not yet 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, signatures, CycloneDX software bills of materials and build provenance support independent review.
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.
No invented customer or production-availability claims.
Hemus was a controlled relevant-environment demonstration, not sustained operation on an end-user production network.
No claim of live RF jamming at Hemus.
The demonstration used physical path cuts and software-injected loss, delay and jitter. 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.
An Android build exists but awaits device validation; terrain analysis is not yet connected to live scheduling; TDMA and L2 coordination remain future 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.