4G LTE Support: Cellular Telemetry and Video with EasyDrone4G

What This Actually Is

EasyDrone4G is companion-board software for a small single-board computer — a Radxa Zero 3W or Raspberry Pi class device — that rides on the aircraft. It connects to your flight controller's TELEM port over UART, takes a camera feed, and pushes both out through an LTE modem. Phone and board join the same private VPN, so your Android device sees the drone as an ordinary network peer.

From MAVLink HUD's perspective the aircraft becomes two UDP streams:

• Telemetry on port 14550: standard MAVLink 2, exactly as it arrives from any other link. Attitude, position, battery, GPS fix, flight mode, arming state, and STATUSTEXT warnings all populate the HUD as usual.
• Video on port 5604: an RTP stream carrying H.264 or H.265, rendered as the background layer beneath the instrument overlay.

Nothing about the HUD changes. The artificial horizon, the offline vector map, the audio callouts, and the XR glasses output all behave identically — they simply no longer care whether the data arrived over ELRS, USB, or a cell tower three counties away.

Receive-Only: You Still Fly With Your Transmitter

This is the most important thing to understand before you order hardware.

This is a receive-only solution for both video and telemetry. MAVLink HUD does not support flying the aircraft over LTE, and there is no RC transmitter integration. Your normal radio link remains the control link, and it remains the thing that determines how far you can safely operate. What cellular gives you is a telemetry and video path that is not bounded by RF line-of-sight — a way to see what the aircraft sees and know what it is doing, not a way to command it.

Practically, that makes this a monitoring and situational-awareness tool. It pairs naturally with autonomous missions, where the aircraft is flying a planned route under its own control and what you need from the ground is visibility rather than stick input. It is equally useful for long-range observation flights where the video downlink dies well before the control link does.

Sending control input over a cellular network is a fundamentally different engineering and safety problem — variable latency, carrier-dependent jitter, and no guarantees about packet delivery. We would rather ship a link that is honest about being one-directional than one that quietly encourages you to rely on it for control. It remains on the roadmap, gated behind the failsafe work it deserves.

The Video Path

We built the receiver natively rather than embedding a general-purpose media framework. Video arrives as raw RTP — no RTSP handshake, no container, no negotiation — so the entire receive path is a jitter buffer, a depacketizer, and Android's hardware video decoder. That is roughly a thousand lines of Java instead of a 1GB SDK and a JNI layer, and it keeps the whole pipeline debuggable.

• Automatic H.264 / H.265 detection. There is no SDP exchange on this link and both codecs use the same dynamic payload type, so the app identifies the codec from the video bitstream itself. Radxa-class boards typically encode H.265, Pi-class boards H.264. You do not configure this, and if the board reboots into a different encoder the app follows it mid-session.
• Built for a lossy link. Cellular reorders occasionally and drops packets routinely. A bounded reorder buffer restores sequence and gives up on a gap after 50ms rather than stalling, discarding the damaged frame instead of feeding the decoder a torn one.
• Latency over smoothness. Decoded frames are displayed the moment they emerge rather than scheduled against their timestamps, and the input queue is deliberately shallow — a decoder that falls behind drops frames instead of accumulating a growing delay. For a live feed, the newest frame is the only one worth showing.
• Hardware decoded. Video goes straight to the GPU surface. The telemetry overlay is drawn separately at 60FPS on top, so a grainy or stuttering video link never degrades the instruments.

Data Usage

Cellular data is metered, and the codec choice matters more than anything else. An H.265 board runs roughly 1.0–1.5 Mbps, or about 450–700 MB per hour of flight. H.264 runs closer to 2.0–3.0 Mbps, or 900 MB–1.3 GB per hour. A standard consumer data SIM handles this comfortably; the app reports live bitrate, frame rate, resolution and packet loss so you can see exactly what the link is costing you.

Why This Matters

The interesting consequence is not raw distance. It is that terrain stops mattering. RF links fail behind ridges, buildings, and tree lines. A cellular link routes through infrastructure that was built specifically to cover those places. Flying a valley, working the far side of a hill, or operating in a built-up area no longer means accepting that your video and telemetry will drop out at the worst moment.

It also decouples the ground station from the field. The phone does not have to be near the takeoff point, or hold an antenna, or have line of sight to anything.

Two things worth stating plainly. Cellular coverage at altitude is not the same as coverage on the ground — networks are engineered to point downward, and you should expect to characterise your local coverage rather than assume it. And regardless of how good the downlink is, beyond-visual-line-of-sight operation is a regulatory question, not a technical one. This feature does not change what you are permitted to do in your airspace. Check your local rules and keep flying within them.

Getting Started

You will need a companion board running EasyDrone4G, an LTE modem and data SIM, a camera, and a VPN tying the board and your phone together. Wire the board to a spare TELEM port, point the board at your phone's VPN address, and set the same address as the Target IP in the HUD's connection widget. Telemetry appears on 14550 and video on 5604 with no further configuration — the app works out the codec on its own.

Support is in the current release. As always, test on the bench before you trust it in the air.