Connect a camera to a wireless sensor network: keep image data wired

A plant already runs a wireless sensor network for temperatures, vibration switches and presence signals, so the next request sounds simple: hang the camera on the same network and skip the cable. This page gives you the numbers that settle it. A ZigBee-class mesh moves at most 250 kbit/s per channel, while a machine-vision camera moves megabits per frame and gigabits per second. You get the bandwidth math for both sides, a worked example that puts a 12 MP camera against a 250 kbit/s mesh, the wired link that actually carries the images, the place where the two networks should meet, and the one case where wireless video is the right call.

What a wireless sensor network is built to carry

A sensor mesh is engineered around small, slow payloads and years of battery life, not throughput. ZigBee radios move 250 kbit/s per channel raw in the 2.4 GHz band, 40 kbit/s in the 915 MHz band and 20 kbit/s in the 868 MHz band, per the Zigbee data-rate table. After medium-access overhead, retries and duty-cycle limits, the payload rate a node actually achieves lands in the tens of kbit/s. That is the design point: report a value, sleep, repeat.

Telemetry fits that envelope easily. A temperature reading is 2-8 bytes of payload, so one reading per second is 16-64 bit/s of real data. A single 250 kbit/s channel has room for on the order of 15,000 one-per-second readings, which is why these meshes handle plant-floor sensing so well. None of that budget survives contact with pixels.

If you have already tried to push an image through the serial side, the failure modes are catalogued in Camera image data over a Zigbee mesh: why serial transfer fails. This page answers the earlier question: whether the camera belongs on the mesh at all.

Worked example: 4000 × 3000 pixels at 30 fps against a 250 kbit/s mesh

The inputs. Image geometry is 4000 × 3000 pixels at 30 fps, the printed output of the 12 MP USB3 camera below. Bit depth is 8 bit/pixel, the usual mono depth and a fair assumption for raw color too; a 10-bit or 12-bit output scales every rate that follows to 1.25× or 1.5×. The mesh channel runs at its 2.4 GHz maximum of 250 kbit/s raw. Frame rate and region of interest scale the result linearly.

The LS-CMR-0166 prints 4000 × 3000 resolution at 30 fps:

The rule is two lines. A camera's raw data rate is pixels per frame times bits per pixel times frames per second. The airtime one frame needs on a link is frame bits divided by the link's bit rate.

The arithmetic:

• Pixels per frame: 4000 × 3000 = 12,000,000 px.
• Bits per frame: 12,000,000 px × 8 bit = 96,000,000 bit, which is 96 Mbit or 12 MB.
• Stream rate: 96,000,000 bit × 30 1/s = 2,880,000,000 bit/s, about 2.9 Gbit/s or 360 MB/s.
• Airtime on the mesh: 96,000,000 bit ÷ 250,000 bit/s = 384 s. One frame takes about 6.4 minutes of a perfect channel, before any protocol overhead, so the real figure is longer.
• Margin: 2,880,000,000 ÷ 250,000 = 11,520. The stream asks for 11,520 times the channel's raw capacity.

Shrink the camera and the verdict holds. At 320 × 240 px, 8 bit and 30 fps: 320 × 240 = 76,800 px, × 8 bit = 614,400 bit per frame, × 30 = 18,432,000 bit/s. That thumbnail stream is still about 18.4 Mbit/s, roughly 74 times the channel (18,432,000 ÷ 250,000 ≈ 74).

The decision follows from one threshold. A continuous pixel stream of any deployable size needs megabits to gigabits per second; a WSN channel tops out at 0.25 Mbit/s raw. So images do not go on the mesh, at any resolution you would actually run. Give the camera a wired link rated above its stream with headroom, and keep the mesh for the sensor values it was sized for. The same sizing discipline applies on the wired side; Full resolution image capture is slow or stalls: size the data first walks it step by step.

Why compress-and-send fails for measurement

The obvious workaround is to compress the video. For a viewing stream that works; for measurement it does not. JPEG-class compression at useful ratios smooths edges and shifts edge positions by a pixel or more, and the 4:2:0 chroma subsampling common in video halves color resolution in both directions. If the pixels become numbers — an edge position, a diameter, a code module width — compression alters the part before you measure it. Measurement streams go lossless: raw frames or a mathematically lossless codec only.

The bandwidth says the same thing. Even a heavily compressed 1 Mbit/s video stream is four times a full 2.4 GHz ZigBee channel, and carrying it means starving every sensor node sharing that channel. Compression cannot close an 11,520-fold gap; only a different link can.

The link that carries the camera: GigE Vision or USB3 Vision

For a fixed camera the wired answer is ordinary equipment. A dedicated gigabit link under GigE Vision yields about 950 Mbit/s of usable image bandwidth after protocol overhead, which carries about 10 of the 12 MP frames above per second (950,000,000 ÷ 96,000,000 ≈ 9.9). USB 3.0 signals at 5 Gbit/s and a USB3 Vision camera sustains roughly 3.2-3.8 Gbit/s of image data in practice, so the full 30 fps stream fits with room to spare. Beyond that, 10GigE and CoaXPress move multi-gigabit streams over longer distances; Most reliable camera interface: GigE, USB3, Camera Link or CoaXPress ranks the choices, and 5GBASE-T camera interface: bandwidth, cables and distance covers long cable runs.

Distance is rarely the blocker indoors. Standard gigabit Ethernet runs 100 m per segment, which reaches across a bay or a line from one switch. Run length, flexing and connector locking are cable questions, not radio questions; pick from the camera cables category.

Both interfaces use locked, shielded connectors, and moving runs want the high-flex builds:

If your frames are small, the same discipline holds — a 2.5 MP GigE camera still rides a wire:

Browse the area scan cameras by resolution, shutter and interface, or use the camera finder. If you go USB3, watch the host side: buffer sizing and bandwidth contention are the usual causes of dropped frames, laid out in USB3 Vision transfer errors: diagnose bandwidth and buffers.

Where the two networks meet

The layout that works is two networks, one PC. The camera gets its own network interface on the vision PC, on its own subnet; Connect a GigE camera on a different subnet: set remote and local IPs shows the addressing. The WSN gateway reaches that same PC over the plant LAN, a serial port or a second interface. Sensor values do not need to speak IP at the node at all: a wireless 4-20 mA sensor network bridged to TCP/IP puts the analog readings onto the wired network at the gateway.

When the camera subnet and the plant LAN must stay separated, routing between them is a solved problem; wireless network integration on a different IP subnet walks one controller setup through it.

For alignment, read the frame timestamp from Chunk data on camera frames: carry timestamp and exposure per image and store it with each sensor record. If the camera must share the plant LAN instead of a dedicated NIC, watch for contention; Machine vision network congestion: diagnose transfer faults is the diagnostic to reach for.

When wireless is the right call

One recurring case justifies wireless video: the camera moves. On a UAV, an AGV or a crane hook, a cable is physically impossible, so the tool is a purpose-built wireless video link carrying compressed video sized for viewing or navigation, with latency and jitter accepted by design. Wireless camera links for UAV vision: latency and wired fallback works through that trade and the handoff back to a wired network when the carrier lands.

Note what that link is not: a sensor mesh. A video link is engineered to move megabits with quality-of-service controls; a ZigBee-class mesh is engineered to move kilobits for years on a battery. A viewing stream on the right radio is engineering. A measurement stream on the wrong one is hope.

The decision, per case

• Fixed camera, any measurement or inspection: wired GigE Vision or USB3 Vision, sized above the stream rate with headroom. The mesh stays telemetry-only.
• Fixed camera, viewing only: still wired when a cable can reach. Compressed video over wireless only where no cable can go — and never for pixels that become numbers.
• Moving camera: a purpose-built wireless video link with a wired fallback, compression accepted, measurements deferred to the wired side.
• Slow process values (temperature, vibration, presence): the WSN mesh as designed, bridged to the vision PC or plant LAN at the gateway.
• Safety signals: wired safety I/O, or wireless hardware certified for the safety function. Never the telemetry mesh.

Checks before you order

• Compute the stream first. Width × height × bit depth × frame rate gives the bit rate; compare it with the usable rate of the interface, not the headline line rate.
• Walk the cable path. Confirm run length, bends and whether any segment moves; moving runs need high-flex cable.
• Reserve the camera's network. Plan a dedicated NIC and subnet on the vision PC before installation day.
• Plan the gateway path. Decide now how sensor values reach the vision PC and how results travel back to displays or the PLC.
• Plan power at the camera. A wired data link does not remove the power question; confirm how each camera is powered where it mounts.

Start the system configurator at the camera step to size camera, lens and link together, or send your layout through the contact page and we will check the numbers with you. More on links, networks and data rates lives on the systems topic page.