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 laptop on the drone's local network: a rugged Toughbook, any Linux/macOS/Windows machine, whatever the team has. Picks up the drone's video and telemetry and sends them out over whatever uplink is available, whether cellular hotspot, Starlink, or bonded router. Records to an SD card at the same time, so footage survives if 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 recovery layer that keeps video usable over cellular.
• Operator client. Runs on the command-post laptop, optionally as a service so it starts on boot. 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.

You run the proxy and the client either with the Hover CLI (hover proxy start and hover client start) or with the Hover Relay desktop app, a point-and-click version of the same two roles for operators who don't work in a terminal. From the drone's point of view, it's talking to a machine 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 mechanisms for this:

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; the result is loss numbers that inflate over a session and lose any operational meaning. Hover surfaces the real numbers live, in the Hover Relay app's link readout, in hover logs, and in the dashboard, rather than letting them drift.

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. When they do want to check the link, the surfaces are built in: the Hover Relay app shows live connection health and a console right where you start the relay; the CLI streams the same events with hover logs; and the dashboard shows each deployment's live status. No SSH, no troubleshooting guides taped to the inside of the laptop lid.

What's optional

Several capabilities sit alongside the core relay. The first two are available on every tier; the rest are paid features (see pricing).

• Public viewer. A PIN-protected browser URL that an incident commander can hand to a partner agency or public-information officer. Same drone, same feed, accessible by URL with nothing to install. Every tier.
• 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. This is the canonical recording. Every tier.
• Cloud recording. In parallel with the SD card, the flight can be muxed to cloud storage so it's browsable and shareable from the dashboard, with tier-based retention. Opt-in per deployment. Fleet and above.
• Sentry. One-button gimbal automation that cycles a station-keeping drone's camera through points of interest and hands control back the instant the operator touches the sticks. Fleet and above.
• Detections. AI watching the live feed against a plain-language rule and surfacing matches on the timeline. Fleet and above; currently private beta.
• Sensor mesh. Beyond drones, Hover relays low-power LoRa sensor assets (e.g. ocean drifters) and plots them on the same map. See Concepts.