A recent PtMP deployment we worked on had a familiar problem: the hardware checked every box on paper — right frequency band, right range, right radio — but once more than a handful of remote stations came online, performance got uneven. Some stations ran fine. Others lagged, dropped packets under load, or just underperformed relative to what the spec sheet promised.
The instinct in situations like this is usually to blame the radio hardware. In our experience, the actual bottleneck is almost always the scheduling layer — how airtime gets allocated across stations, not the raw RF performance.
What we found
Standard TDMA firmware implementations often use static or near-static slot allocation — every remote station gets a roughly equal time slice, regardless of what that station actually needs or how far it is from the base station. That works fine at low station counts. It breaks down as deployments scale, because distance, interference, and per-station data demand aren’t equal across a real network — a fixed schedule fights the physical reality it’s trying to serve.
We rebuilt the scheduling logic on the firmware side to allocate airtime dynamically — closer to a priority/demand-weighted model than a fixed round-robin — and re-ran the same deployment topology: 8 remote stations, one base station, downlink test, same OpenWrt-based platform.
Result: per-station throughput of 130–265 Mbit/s, aggregate peak of 1,797.28 Mbit/s, aggregate average of 625.16 Mbit/s — with the spread between best- and worst-performing stations narrowing noticeably compared to the default static-scheduling baseline.
Why this matters beyond one deployment
The hardware didn’t change. The module, the antenna, the base station — none of it changed. What changed was the software layer managing how that hardware gets used across multiple simultaneous stations. That’s usually the part vendors don’t customize, because it means going deeper than swapping a chipset or bumping a spec sheet number.
This is also where we think there’s room for more collaboration than the industry typically does. A lot of teams building PtMP or multi-node wireless products — robotics, drones, distributed sensor networks — have strong hardware instincts but limited bandwidth to go deep on scheduling firmware, OpenWrt customization, or protocol-level tuning. That’s specifically the kind of work we do on the software side, independent of whether the hardware itself comes from us.
If your team has a multi-station deployment that’s hitting a similar wall — good radios, uneven real-world performance — we’re happy to compare notes, or scope what a scheduling-level fix would look like for your specific topology.
