The WiFi was fine.
That was the problem.
A passive 802.11 site survey of Plainsboro Public Library — a three-storey, 46,500 sq ft civic building. Two floors, 67 measurement points, 1,523 network observations. Every single point met the −67 dBm design threshold. There were no dead zones to find. What the data showed instead was eight access points competing with each other for airtime.
2.4 GHz occupancy — distinct BSSIDs heard at ≥ −80 dBm
Five of the library's eight access points sit on channel 6. Channels 1, 6 and 11 are the only non-overlapping options in 2.4 GHz — putting five radios on one of them forces them into a single collision domain, where they hear each other and take turns.
Findings
Six findings. Each states what was measured, the probable cause, the impact, and what to do about it. Every number traces back to the raw data in the repository.
2.4 GHz channel plan is heavily unbalanced
Five of eight access points operate on channel 6; two on channel 11, one on channel 1. Channel 6 carries 24 distinct BSSIDs at −80 dBm or stronger — channel 11 carries seven.
Redistribute across 1/6/11. No hardware cost.
5 GHz radios crowded into UNII-3 at mismatched widths
Three access points share channel 149 — one at 20 MHz, two at 80 MHz. Two more share channel 153. An 80 MHz channel with primary 149 occupies 149 through 161, swallowing both 153 and 157. Six of eight radios contend inside one band segment while UNII-1 and UNII-2 sit almost unused.
Move radios into the empty ranges and standardise width. In a dense deployment 40 MHz beats 80 — half the peak rate, twice the non-overlapping channels.
Access point density exceeds the coverage requirement
At a typical location the survey device heard 7.3 library radios at −75 dBm or stronger, peaking at 13 — while every measured point met −67 dBm with margin to spare.
Measured independently: while associated at roughly −50 dBm, the client negotiated a 96 Mbps link against a device ceiling of 433 Mbps. A fifth of capability under near-ideal signal is contention, not coverage.
Reduce transmit power to tighten cell overlap. Do not add access points — the data does not support a coverage-gap argument.
Hidden BSSIDs advertise a legacy security capability
Eighteen non-broadcast BSSIDs carry a capability string Android renders as WEP. The public network reports no encryption and is labelled "Security: weak" by Android's own classifier.
Android reports WEP when a beacon sets the privacy bit without a modern RSN element — consistent with real WEP, but also with certain captive-portal configurations. This is not confirmed and is not presented as fact. It needs verification by someone with administrative access.
Worth noting regardless: hiding an SSID is not a security control. All eighteen were enumerated passively during a routine walk.
Coverage propagates freely between floors
Six of eight access points are audible on both floors at −67 dBm or better. Three whose peak is upstairs still reach −42, −46 and −49 dBm downstairs, across essentially every ground floor point.
The building's central volume is a double-height reading room open between levels. A vertical void carries signal between floors far better than the surrounding slabs do.
Plan channels for the building as one three-dimensional volume. Vertically adjacent access points near the atrium need different channels too — not just different from their neighbours on the same floor.
External RF environment is active but not dominant
Thirty-plus outside networks, strongest at −51 dBm: four printers broadcasting direct-connect SSIDs, personal hotspots, and residential networks from the attached homes the architect's site plan places next door.
Disable direct-connect radios on printers that are already network-attached. Factor neighbouring channel usage into the 2.4 GHz replan.
How it was done
Passive survey only — broadcast beacon measurement. No association testing, no traffic capture, no interaction with library infrastructure. Permission was asked on arrival and again for the community room after its event ended; a study room was reserved through the library's normal booking system.
| Instrument | Detail |
|---|---|
| Software | NetSpot for Android, Survey mode, passive |
| Device | Moto G Stylus 5G (2024) · Wi-Fi 5 · dual-band · 1×1 |
| Ground floor | 36 points |
| Second floor | 31 points |
| On site | 15:30–19:00 · approx. 50 people in the building |
| Floor plans | Architect's drawings · scale from the graphic scale bar |
.netspu file is a zip
containing SQLite. Every figure on this page came from querying it directly rather than
reading colours off a heatmap. Counting access points, for instance, means grouping the 94
distinct BSSIDs by the radio prefix they share — which collapses to eight physical APs, each
running two radios advertising several BSSIDs apiece.
What this survey cannot tell you
Stated plainly, because a survey report claiming no limitations is telling you the author doesn't know what they are.
- No 6 GHz visibility. The survey device is dual-band Wi-Fi 5. If the building runs 6E or 7 equipment, that band is absent from this data entirely.
- Single-stream client. A 1×1 radio caps at 433 Mbps. No throughput figure here describes the network's capability — only this client's experience.
- Uncalibrated radio. Consumer chipsets carry roughly ±3–6 dB of absolute uncertainty. Findings rest on relative comparison under a consistent method.
- No spectrum analyser. Non-WiFi interference can be inferred, not observed. The device reported no noise floor, so no SNR-based finding appears anywhere.
- AP positions are estimated. Trilaterated by software, not physically verified. Channel assignments and AP counts come from beacon data and are reliable.
- Materials are documentary. Construction materials come from the building's published product schedule, not on-site assessment.
- Single time sample. One evening. Conditions vary by hour and by crowd.
- Two floors of three. The children's level was excluded by choice — an unaccompanied adult walking a measurement grid through a children's area isn't appropriate regardless of policy. The mechanical room was not entered.
Heatmaps
Exported directly from the survey, filtered to the library's own networks only. Click a metric to switch — the geometry looks similar across signal, SIR and SNR because interference and ambient noise here don't vary sharply by location; that's expected, not an export error (see the methodology notes).
* The survey device did not expose per-point noise-floor data. SNR here reflects NetSpot's internal calculation rather than measured ambient noise, and is indicative only.
Source floor plans
Extracted directly from the survey project. Design drawings from Architectural Record (2011) — not as-builts.
Everything, downloadable
Raw export, extracted data, the written report, and the field methodology used to run the survey. Reproduce any figure on this page from the CSVs.
How this page reaches you
The survey is one half of the work. The other half is that this site is served from hardware on a desk, not a hosting provider.
| Layer | What runs there |
|---|---|
| Host | ThinkPad T14 · Proxmox VE |
| Container | Debian LXC on VLAN 40 (DMZ), 10.10.40.0/24 |
| Web server | nginx — second vhost alongside the Cherwood site |
| Perimeter | FortiGate 60E · DMZ→Internet permitted; DMZ→Trusted, Servers and Guest all denied |
| Publication | Cloudflare named tunnel — outbound only, no inbound rule exists |
This runs on infrastructure built for Cherwood Corporation — a documented FortiGate 60E, Cisco 3560E and autonomous-AP network with four segmented zones. Packetgeist is Division 02, and it needed no new container, tunnel or firewall rule: an isolated DMZ built properly the first time takes a second public service without opening anything.