OT Wireless
Search/Menu

Search the field guide, causes, requirements, and glossary

Wireless cameras and sensor networks

Wi-Fi cameras stream continuously on whatever channel they join, and 2.4 GHz instrument networks transmit where Wi-Fi often cannot hear them, so both compete with your control traffic for the same channel.

Ben RutterIndustrial network engineer
  • Updated
  • Reviewed
  • 3 min read
  • 9 sources
On this page5 sections
  1. How it presents
  2. Why it happens
  3. How to confirm it
  4. The fix
  5. Prevent it at design time

Is this your problem? It presents like this

  • Channel utilization stays high all shift, even when vehicles and handhelds are idle.
  • The heaviest uplink talkers on the channel are cameras, and their load climbs when the scene below them gets busy.
  • Control latency and retries rise in the area a camera covers, and ease when it is switched off.
  • On 2.4 GHz, Wi-Fi retries climb near instrument gateways or field devices while a Wi-Fi scan shows nothing new.
  • Wireless instruments lose packets, reroute, or drop channels when the Wi-Fi channel next to them is busy.
Bands
2.4 GHz5 GHz
Not sure?
Rank the likely causes from your symptoms

Why it happens

A Wi-Fi camera is a streaming client: it sends for as long as it records, on whatever channel its access point uses. Its bitrate is not fixed either. One camera maker notes that motion in the scene can raise stream size and bitrate significantly, so a camera over a busy floor takes more airtime than the same camera over an idle one.

Priority does not rescue you, and can make it worse. A design guide for EtherNet/IP over wireless maps I/O into the WMM video queue and reserves that queue for control, stating it is not used for IP video in the plant. The IETF’s mapping sends streaming video to the same video access category. WMM gives each access category one queue and one set of access parameters, so a camera marked that way contends on equal terms with your I/O. The design guide’s advice is plain: keep video streaming off the control channel.

Instrument networks share 2.4 GHz as well. Zigbee, WirelessHART, and ISA100 Wireless run on IEEE 802.15.4 radios with a nominal 5 MHz bandwidth1. WirelessHART hops across 15 channels and ISA100.11a across 162, while Zigbee stays on one. NIST’s own capture of the band shows Wi-Fi and hopping sensor traffic side by side, where they may interfere with each other.

That interference runs both ways, and Wi-Fi barely sees it. Low-power 802.15.4 traffic is likely to be overlooked by Wi-Fi’s carrier sensing, so Wi-Fi can transmit on top of it. Work cited in the same study found nearby 802.15.4 quality very difficult to guarantee under middle or high Wi-Fi load, and 802.11 performance degrading significantly under 802.15.4 interference. One lab found that a Zigbee signal 15 dB weaker than the Wi-Fi signal was enough to cause 100% packet errors at MCS 73. WirelessHART answers by blacklisting the channels where it loses packets, which leaves it fewer to hop across. A channel you share with a camera, or a band you share with instruments, is not a control channel.

How to confirm it

  1. List every camera and every instrument or sensor network near the affected cell, with its band, its channels, and who owns it.
  2. Capture per-client airtime on the affected channel and rank clients by uplink airtime.
  3. Check which DSCP marking and WMM access category the camera stream actually uses over the air, and compare them with your control traffic's.
  4. Record a spectrogram on 2.4 GHz near instrument gateways. 802.15.4 radios appear as narrow signals that a Wi-Fi scan does not list.
  5. Pull the instrument network manager's per-channel statistics and blocked-channel list, and compare them with your Wi-Fi channel plan.
  6. Switch the cameras off or move them for a test window, and compare control latency and retries with the window before.

The fix

  • Move cameras to their own channel, band, or a wired connection, away from the control channel.
  • Remark camera traffic so it does not share the access category your control traffic uses.
  • Cap camera bitrate with a maximum bitrate setting, so motion in the scene cannot push the stream up without limit.
  • Coordinate 2.4 GHz with the instrument owners. Keep plant Wi-Fi off 2.4 GHz near instruments where you can, or agree which channels each side uses.

Prevent it at design time

  • Keep a spectrum management plan that lists every radio network, including cameras and instrument networks, with owner, band, and channels.
  • Dedicate a channel to control traffic and keep video off it.
  • Require camera suppliers to state bitrate, rate control mode, band, and QoS marking before installation.
  • Review the plan with the instrument team before either side adds radios in 2.4 GHz.

Related causes

Terms on this page

About this page

Built from 9 sources: 3 standards bodies and labs, 1 protocol owner or alliance, 3 research papers and theses and 2 vendor documents. Researched and drafted with AI assistance, then reviewed and approved by Ben Rutter on . How pages are made

First published
Last updated
Change history (1)
  • First published
Cite this page

Plain

Ben Rutter. "Wireless cameras and sensor networks." OT Wireless, published October 5, 2026. https://otwireless.com/causes/wireless-cameras-and-sensor-networks/

APA 7

Rutter, B. (2026, October 5). Wireless cameras and sensor networks. OT Wireless. https://otwireless.com/causes/wireless-cameras-and-sensor-networks/

BibTeX

@misc{rutter2026wirelesscamerasandsensornetworks,
  author = {Rutter, Ben},
  title = {{Wireless cameras and sensor networks}},
  year = {2026},
  howpublished = {\url{https://otwireless.com/causes/wireless-cameras-and-sensor-networks/}},
  organization = {OT Wireless},
}