How Hover actually works.

The path

A drone in the field produces an H.264 video stream and a MAVLink autopilot link. Both have to reach an operator at a command post — possibly across a partner agency network, possibly to a public viewer the incident commander can hand to a press officer. Hover sits in the middle and carries the bytes.

There are three software components:

• Field proxy. Runs on a Panasonic Toughbook on the drone's local network. Picks up the drone's video and telemetry and sends them out over whatever uplink the team has — cellular hotspot, Starlink, bonded router. Records to an SD card while it's at it, in case the uplink drops.
• Cloud relay. Runs on AWS in a single US region. The proxy connects in and stays connected. So does the operator client. The relay forwards bytes between them and adds the resilience layer that makes cellular bearable.
• Operator client. Runs as a Windows service on the command-post laptop. Exposes the drone's video and MAVLink at 127.0.0.1, so any standard ground-control software (CCA3, Mission Planner, QGroundControl) connects to it as if the drone were sitting on the same desk.

That's the whole architecture. From the drone's point of view, it's talking to a Toughbook on its own network. From the operator's point of view, the drone is on the laptop. In between, Hover handles the public internet.

Why the middle is the interesting part

Cellular and satellite links don't behave like Ethernet. Packets show up out of order. They drop in bursts when a tower hands off. Round-trips spike from 50 ms to 600 ms when the link saturates. A naive RTP relay over UDP turns those events into pixelation, frozen frames, and command lag.

Hover's relay has three things in it that make this bearable:

Loss recovery (NACK retransmit)

The relay keeps a rolling buffer of recent packets. When the receiving end notices a sequence gap, it asks for a retransmit. The relay pulls the packet from buffer and resends it, paced so retransmits don't pile on top of fresh video and saturate the uplink. Both legs of the path — field-to-cloud and cloud-to-operator — have their own retransmit layer.

Reorder tolerance

Cellular networks reorder packets routinely. A naive system reads a sequence gap and immediately requests a retransmit. Most of the time the "missing" packet shows up 15 to 25 ms later, having taken a different cell-tower path. Hover holds the gap for 75 ms before classifying it as loss. The result: retransmit traffic stays roughly equal to actual loss, instead of being dominated by reorder noise that resolves itself.

Honest measurement

Loss counters credit late arrivals back. When a packet shows up after we briefly counted it lost, the counter decrements. Sounds obvious, but most relays don't do this — and the result is loss numbers that inflate over a session and lose any operational meaning. Hover's /api/network tells you what's actually happening on the link.

What the operator sees

Day-to-day, almost nothing about Hover should be visible to the operator. The drone shows up at 127.0.0.1 in their existing GCS software. The video plays in their existing viewer. A small admin page on the operator's laptop — port 8081, browser-only — shows live logs and a real-time loss chart for diagnostics. A matching page on the field proxy (port 8080) does the same on the field side. No SSH, no command-line, no troubleshooting guides taped to the inside of the Toughbook lid.

What's optional

Two extras sit alongside the core path:

• Public viewer. A browser URL that an incident commander can hand to a partner agency or public-information officer. Same drone, same feed, accessible by URL without installing anything.
• Field-side recording. The proxy continuously records H.264 to a labeled SD card. When the operator is done, they swap the card out and hand it to evidence, the same way they'd hand off a body-worn-camera card.