The problem in the field
Wireless camera links fail in ways a laptop speed test doesn't catch. The installer stands at the mount, the phone shows four bars, the site gets signed off, and the stream drops at 2 a.m. when the lot is busy and the camera is pushing four times the bitrate it did at noon. Nobody measured what the camera would need. They measured what the phone could see.
Why the usual answers fail
Android throttles foreground scans to four per two minutes, so the AR heatmap apps are drawing beautiful false precision. Signal strength isn't quality. And one phone at one moment is not the camera that will live there for five years. The market splits into consumer visualizers at zero to ten dollars and professional survey kits at five thousand dollars of hardware plus a seat per year. Nothing in between sells evidence and a verdict at phone price.
What I built
So far, the numbers. I ran 20-second RTSP over TCP captures, VBR, uncapped, on my own cameras. A P3285 on a quiet 1080p30 H.264 scene averaged 1.1 Mbps with a 2.3 peak. A Q6358 on a static 4K60 scene sat at 10.8. A Q6325 on a busy roundabout at 1080p60 ran 28 to 36.5 average and peaked at 43.1. The Q6358 on a valley scene at 4K60 ran 80.6 to 82.9 with an 86.9 peak. Motion dominates: a 30x spread between quiet and busy. Peaks run 1.2 to 2.1 times average. H.265 and AV1 saved nothing at uncapped VBR, and 60 fps costs about double.
How it works
The wedge is a pin: a 5-to-10-second active workload run at each mount point while associated, measuring sustained throughput, latency, jitter, loss, roam and BSSID, and band state. Pass means every one-second bucket clears the profile's floor, loss stays under 0.5 percent, and jitter under 20 ms. The output is a Commissioning Certificate PDF with a pass or fail. The report is the product.
profile floor pin pass rule, every 1 s bucket CAM-QUIET 4 Mbps 10 s ≥ floor, loss < 0.5%, jitter < 20 ms CAM-STD 8 Mbps 10 s same CAM-BUSY 45 Mbps 15 s same CAM-4K 20 Mbps 15 s same CAM-4K60-BUSY 100 Mbps 15 s same
Where it stands
Thresholds are frozen at v0.1 and there is no app. The night run on August 30 changed the design. IR didn't inflate bitrate, and the Q6358 held about 30 fps at 17.8 Mbps. But the P3285 in IR wash collapsed to 0.1 Mbps of unusable gray, which means a bandwidth-only walk would pass a blind camera. An image-sanity check, entropy or edge density, is now part of the plan. Caveats: Zipstream state isn't readable on OS 12.x, so these numbers are near worst case, and a multi-camera uplink needs N times the profile.
What's next
An Android pin-sampler spike to find out whether a phone can run the workload honestly, then three to five installer interviews. If it earns its keep it may live as a "WiFi hold" pin inside camspec rather than as its own app.