Wireless camera links for UAV vision: latency and wired fallback

A camera on a flying platform has to put pixels in front of your processing code, and the consumer market sells plenty of wireless kits that promise to do it. The real decision is not which cameras your software lists as supported but whether the radio holds your frame rate, your latency budget and your frame count while the airframe banks and the band fills with other traffic. Measured Wi-Fi video from UAVs runs 200-300 ms of mean latency; a wired USB3 or GigE tether runs in milliseconds. Certify the vision loop on a tether, process onboard, and let the radio carry results instead of raw frames. The arithmetic below sizes both paths.

Can a machine-vision camera run over Wi-Fi at all?

Physically yes — a GigE or USB3 camera behind a Wi-Fi bridge will pass frames — but as an acquisition path it fails a timed vision loop, because consumer Wi-Fi video adds 100-500 ms of latency and drops frames exactly when the airframe banks or the band gets busy.

GigE Vision and USB3 Vision are wired standards. They assume a cable that neither loses bytes nor holds them long; replace that cable with a radio bridge and the link becomes a lossy, variably delayed Ethernet segment. The camera does not care. Your scheduler does. Two things break when the acquisition path goes over air: frames stop arriving reliably, because airtime contention removes bursts of them, and arrival time stops being predictable, so any loop that matches images to a trigger or an encoder position drifts. The support question therefore dissolves into an architecture question: where does the pixel processing run? Keep acquisition wired — a tether during certification, onboard compute in flight — and the radio becomes a downlink for what the ground genuinely needs. Every number below serves that split.

How much latency does a wireless link add to your images?

Budget 200-300 ms as the measured mean for Wi-Fi video from a UAV, with consumer stacks anywhere in the 100-500 ms band; a wired GigE or USB3 link moves frames in milliseconds, not hundreds of them.

The wireless total stacks three buffers on top of the camera pipeline. The encoder holds roughly a frame while it compresses; the radio queue waits for airtime and retransmits losses; the decoder holds two to four frames to smooth the arriving stream. Published measurements of real-time video over Wi-Fi links to UAVs put the mean at 200-300 ms, and consumer streaming stacks commonly land anywhere from 100 to 500 ms. A wired link has none of those stages: a 12.8 Mb mono frame crosses a GigE tether in 12.8 Mb ÷ 940 Mb/s ≈ 14 ms, and the rest of the pipeline is exposure and readout you already count. Hold the radio number against your loop period: at a 30 Hz guidance rate one cycle is 33 ms, so a 200-300 ms link feeds you images 6-9 cycles old.

What throughput can you actually plan on from a Wi-Fi link?

Plan on roughly half the nominal radio rate: a 54 Mb/s link is worth 20-30 Mb/s of usable throughput once retransmissions and airtime contention take their share, and every frame in your budget has to fit inside that number, not the one on the box.

The rate printed on the box is the radio's best-case signalling rate with a clear channel and a close antenna. Retransmissions, airtime shared with your control and telemetry links, and neighbour traffic in the 2.4 GHz band take the rest, so planning on half the nominal rate has proved a durable rule. A 54 Mb/s link is therefore worth 20-30 Mb/s, and a 150 Mb/s single-stream 802.11n link about 75 Mb/s, before the video stack's own overhead comes out. This is the same discipline as a wired plant: divide the pipe before you promise streams, exactly as you would for several cameras on one GigE link or a USB hub that quietly halves a camera's frame rate. Distance and RSSI move the number most — every step down in signal adds retransmits — along with channel width and how many devices contend for the channel.

How do you compute the data rate your camera produces?

Multiply resolution, bytes per pixel and frame rate, then convert to bits: a 3.1 MP mono camera at 120 fps and 8-bit depth makes 24.8 Mb per frame and 372 MB/s ≈ 2.98 Gb/s of raw stream, which fits a USB3 tether and dwarfs any radio link.

Run both paths for two shop cameras. The LS-BCM-0003 pairs a 3.1 MP global-shutter sensor with a USB3 port and runs 120 fps. The MV-CB016-10GM-M-W pairs a 1.6 MP mono sensor with a GigE port and an M12 mount.

8-bit mono on the 3.1 MP sensor: frame size = 3.1 × 1 × 8 = 24.8 Mb, raw stream = 24.8 Mb × 120 fps = 2,976 Mb/s ≈ 2.98 Gb/s, or 372 MB/s. USB3 moves about 400 MB/s of real bulk data (5 Gb/s signalling less encoding and protocol overhead), so this stream fits a tether with roughly 7% headroom. Switch the pixel format to 12-bit and the same line gives 3.1 × 1.5 × 8 = 37.2 Mb per frame × 120 fps = 4,464 Mb/s = 558 MB/s, over the tether's budget — pixel format is part of the link budget.

Against the radio: 27 Mb/s usable ÷ 24.8 Mb ≈ 1.1 fps. One frame per second is what a 54 Mb/s-class link carries of this stream raw. The smaller sensor: a 1.6 MP 8-bit frame is 12.8 Mb; at a 30 fps target the stream is 384 Mb/s, which a GigE tether holds with 2.4× margin (940 ÷ 384) and the radio turns into 27 ÷ 12.8 ≈ 2.1 fps — one frame every 474 ms. Run the same method one sensor size down and it sizes a USB2 link; the numbers change, the method stays.

Why does a wireless link drop frames mid-run?

Airtime contention, multipath off the airframe, RSSI fade in a bank and retransmission timeouts remove bursts of frames, and the video stack then hides the loss behind a growing buffer that shows up as latency spikes rather than clean errors.

In order of how often they bite: airtime contention (your own control and telemetry links plus every other 2.4 GHz device in range), multipath reflections off the airframe and its propellers, RSSI fade as the aircraft banks and puts the fuselage between antenna and ground, and hidden-node transmissions near the ground station. Radio loss is bursty — tens of frames go, then the link recovers — and the video stack hides it: the decoder buffer swells, latency spikes by another 100 ms or more, then a burst of stale frames arrives together. That is why a radio link fails soft and late: the frame rate collapses into bursts, the age of the freshest frame climbs, and nothing throws a clean error. Wired links fail hard instead, which is far easier to see — streaked or torn frames point at the link before the sensor. Put a sequence number on every frame at the sender and count gaps at the receiver: that one counter settles whether the link or the algorithm ate your frames.

What should the wired baseline look like before you certify it?

Certify the vision loop on a tether first: a GigE link moves about 940 Mb/s of usable rate and USB3 about 400 MB/s (3.2 Gb/s), both moving frames in milliseconds rather than hundreds of them, so any shortfall you measure on the bench is your algorithm, not the radio.

Two tethers cover the design space. GigE carries about 940 Mb/s of usable rate on a 1 Gb/s link — the frame-rate arithmetic for GigE Vision resolves to a few milliseconds of transfer for a small sensor — and USB3 carries about 400 MB/s. Certify at your highest planned resolution and rate, not the flight configuration: if the loop holds at 12 MP and 30 fps on the bench, the flight sensor is a rounding error. For that stress test the LS-CMR-0166 outputs 4000 × 3000 at 30 fps over USB3. The budget check is 12 MP × 1 B × 30 fps = 360 MB/s, leaving about 10% headroom against USB3's 400 MB/s.

On the airframe the same logic picks a compact camera whose stream fits what the onboard compute accepts, at the resolution the measurement actually needs. The area scan cameras listing filters by interface, shutter and resolution, and the camera finder sorts the same shelf by sensor format.

How do you keep the radio from carrying raw frames?

Run the detection, measurement or tracking onboard and transmit results — a pose, a defect flag, a few coordinates — which at 30 Hz is kilobits per second, against the hundreds of megabits the same raw frames would demand.

A pose message of six 32-bit numbers at 30 Hz is 24 B × 30 Hz = 720 B/s; against a 27 Mb/s radio budget that is about 4,700× headroom, so results never crowd the link. The budget then goes to compressed monitoring video for the operator: a typical H.264 stream at 1080p30 runs 4-10 Mb/s and fits the 20-30 Mb/s plan with margin left for the control link's own traffic. Two practices make the split work. Store raw frames onboard and sync them after landing, so nothing measurable is lost to the radio. Treat the ground station as a display, not a decision-maker: guidance stays onboard or on the tether. The board-level cameras listing is the weight-conscious end of the camera shelf, with shutter type and lens mount shown per model.

When is a wireless camera link the right choice?

Wireless is right when the ground station consumes results, logs or compressed monitoring video — 4-10 Mb/s typical at 1080p30 — and wrong whenever a ground-side loop must act on the current image within tens of milliseconds.

The decisions fall out of the table:

• A ground loop that must act within a frame or two — docking, tracking, any closed chain through the image — keeps the tether or moves onboard: at 30 Hz, 200-300 ms is 6-9 stale cycles.
• An operator who needs to see the scene gets compressed monitoring video, sized by the numbers above.
• Mapping, survey and inspection records keep raw frames onboard, downlink results and thumbnails, and sync the full data after landing.
• Metrology on live radio frames is off the table: the latency moves frame to frame and the frames arrive in bursts.

If your build blends several cameras and links, the systems topic page collects the worked bandwidth cases.

How do you test the link before you commit the design?

Measure three things in one bench session — wired latency, raw throughput on the tether, and radio loss at half-nominal load for ten minutes — and refuse the wireless path if a single frame goes missing under load.

1. Certify raw throughput on the tether. Run the flight sensor at planned resolution and frame rate over USB3 or GigE for ten minutes and watch the host frame counter: zero gaps passes, and a sag traces to exposure or bandwidth — fps that collapses mid-run lists the usual suspects.
2. Measure wired latency. Put a running millisecond counter in the camera's view, subtract the in-image value from the host receive timestamp across 1,000 frames, and keep the mean and the maximum.
3. Repeat the latency test across the radio at mission distance. The delta against the tether number is the radio's cost; expect the 100-500 ms class and design to the tail, not the mean.
4. Load the radio to half its nominal rate with synthetic traffic for ten minutes and count sequence-number gaps at the receiver. Any gap means shrink the payload — crop, drop fps, compress — or move processing onboard.
5. Sweep the attitude envelope. Bank and pitch the airframe through its full range while streaming; loss bursts that track attitude are an antenna-placement problem, not a bandwidth one.
6. Read rates from the API, not a video window — fps read reliably from the capture object beats a stopwatch every time.

The tether itself is a two-line order: the camera cables listing sorts by length and connector, and the two below cover bench and field. The LS-CBL-0219 is a 3 m high-flex USB3.0 camera cable made for drag-chain use. The LS-CBL-0117 runs 15 m between RJ45 connectors with a locking stud, which is what keeps a tether attached while the cable swings.

Decide the architecture first, then buy: acquisition wired or onboard, radio for results, never raw frames over the air. The accessories finder sorts cables by length and type, the system configurator assembles the tether set-up, and if your numbers do not close, send us the frame size and loop rate and we will check the budget with you.