{"id":57130,"date":"2026-07-30T11:13:27","date_gmt":"2026-07-30T09:13:27","guid":{"rendered":"https:\/\/wodatherm.com\/?p=57130"},"modified":"2026-07-30T11:14:29","modified_gmt":"2026-07-30T09:14:29","slug":"tuning-tdma-scheduling-for-a-multi-station-ptmp-deployment-a-field-case","status":"publish","type":"post","link":"https:\/\/wodatherm.com\/de\/tuning-tdma-scheduling-for-a-multi-station-ptmp-deployment-a-field-case\/","title":{"rendered":"Tuning TDMA Scheduling for a Multi-Station PtMP Deployment: A Field Case"},"content":{"rendered":"\n

A recent PtMP deployment we worked on had a familiar problem: the hardware checked every box on paper \u2014 right frequency band, right range, right radio \u2014 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.<\/p>\n\n\n\n

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 \u2014 how airtime gets allocated across stations, not the raw RF performance.<\/p>\n\n\n\n

\"Article<\/figure>\n\n\n\n

What we found<\/strong><\/p>\n\n\n\n

Standard TDMA firmware implementations often use static or near-static slot allocation \u2014 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 \u2014 a fixed schedule fights the physical reality it’s trying to serve.<\/p>\n\n\n\n

We rebuilt the scheduling logic on the firmware side to allocate airtime dynamically \u2014 closer to a priority\/demand-weighted model than a fixed round-robin \u2014 and re-ran the same deployment topology: 8 remote stations, one base station, downlink test, same OpenWrt-based platform.<\/p>\n\n\n\n

Result:<\/strong> per-station throughput of 130\u2013265 Mbit\/s, aggregate peak of 1,797.28 Mbit\/s, aggregate average of 625.16 Mbit\/s \u2014 with the spread between best- and worst-performing stations narrowing noticeably compared to the default static-scheduling baseline.<\/p>\n\n\n\n

\"Article<\/figure>\n\n\n\n

Why this matters beyond one deployment<\/strong><\/p>\n\n\n\n

The hardware didn’t change. The module, the antenna, the base station \u2014 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.<\/p>\n\n\n\n

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 \u2014 robotics, drones, distributed sensor networks \u2014 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.<\/p>\n\n\n\n

If your team has a multi-station deployment that’s hitting a similar wall \u2014 good radios, uneven real-world performance \u2014 we’re happy to compare notes, or scope what a scheduling-level fix would look like for your specific topology.<\/p>\n","protected":false},"excerpt":{"rendered":"

A recent PtMP deployment we worked on had a familiar problem: the hardware checked every box on paper \u2014 right frequency band, right range, right radio \u2014 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 […]<\/p>\n","protected":false},"author":3,"featured_media":57131,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[55],"tags":[2729,2367,2728,2725,862,2727,1099,2233,2539,2683,315,2726,345,1868],"class_list":["post-57130","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-instalation-support","tag-case","tag-deployment","tag-field","tag-multi-station","tag-ptmp","tag-ptp-link","tag-radio","tag-report","tag-scheduling","tag-tdma","tag-test","tag-tuning","tag-wifi","tag-wireless"],"acf":[],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/wodatherm.com\/de\/wp-json\/wp\/v2\/posts\/57130","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wodatherm.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/wodatherm.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/wodatherm.com\/de\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/wodatherm.com\/de\/wp-json\/wp\/v2\/comments?post=57130"}],"version-history":[{"count":1,"href":"https:\/\/wodatherm.com\/de\/wp-json\/wp\/v2\/posts\/57130\/revisions"}],"predecessor-version":[{"id":57134,"href":"https:\/\/wodatherm.com\/de\/wp-json\/wp\/v2\/posts\/57130\/revisions\/57134"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/wodatherm.com\/de\/wp-json\/wp\/v2\/media\/57131"}],"wp:attachment":[{"href":"https:\/\/wodatherm.com\/de\/wp-json\/wp\/v2\/media?parent=57130"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wodatherm.com\/de\/wp-json\/wp\/v2\/categories?post=57130"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wodatherm.com\/de\/wp-json\/wp\/v2\/tags?post=57130"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}