Zone-based outdoor Wi-Fi over a 5 GHz point-to-multipoint backhaul, fed by Starlink Priority and gated at a RouterOS 7 hotspot edge. Designed for flat, high-density suburb, clear line of sight above roof height.
An outdoor AP's real limit is the phone's transmitter, not the AP's. A handset runs about 15 dBm into a 0 dBi antenna, so in a dense suburb your usable radius is roughly 120 m on 2.4 GHz and 55–70 m on 5 GHz — regardless of how loud the AP shouts. Blanketing a 1 km disc at that spacing needs 70 APs bare minimum, closer to 110 with sane overlap. That is not a bootstrapped build.
So the design below places 10 zones on the gathering points — shop clusters, corners, the borehole queue, transport stops — and leaves the residential interior uncovered on purpose. The coverage circles in the drawing are drawn to scale so you can see the gaps honestly rather than being sold a solid blue disc.
Tap any marker for its build sheet. Bearings are magnetic from the hub; ranges are slant-free ground distance.
The CPE510 is a 13 dBi dish at roughly 45° horizontal beamwidth. To reach six nodes spread around 360° you would need six of them on the mast, individually aimed, all fighting each other for channel space on one 12 m pole. That is the wrong shape and the wrong bill.
Instead: 3 × MikroTik mANTBox 15s at the hub — 120° × 15 dBi integrated 5 GHz sectors, RouterOS, ~$185 each. Three of them close 360° cleanly. The CPE510s move to the client end, which is exactly where they're excellent: cheap, directional, two Ethernet ports, PoE passthrough to the AP below them.
One caveat that will bite you if you miss it: MikroTik's Nv2 TDMA is proprietary. With TP-Link CPE510s as clients you must run the mANTBox radios in plain 802.11 mode with WPA2. You lose Nv2's collision handling, which matters at 30+ clients per sector — at 6 nodes and under 100 users it does not. If you later standardise on MikroTik SXTsq 5 ac at the nodes, turn Nv2 back on.
Worst case in this plan is N5 at 900 m: 25 dBm TX + 15 dBi sector + 13 dBi CPE − 107 dB free-space loss ≈ −54 dBm received. You need about −65 dBm for a solid MCS7 at 40 MHz, so you have 11 dB of margin to burn on rain, cheap pigtails and misalignment. Fresnel clearance and interference are what will actually break these links, not signal strength — which is why the mast goes to 12 m.
At 900 m on 5.8 GHz the first Fresnel radius is 3.4 m, so you want ~2 m of clearance over anything at the path midpoint. A 12 m hub to an 8 m node puts the midpoint line at ~10 m against 5–6 m rooftops. Comfortable. At your current 6–10 m it is marginal, and every new second storey in the suburb becomes your problem.
Keep authentication on the MikroTik, not on Omada. Your OTP-anchored time passes and content-class ladder already live in RouterOS; the EAPs should stay dumb Layer 2 with a VLAN 20 SSID and nothing else. One auth brain, one place to debug.
| Purpose | Band | Channel | Width | Notes |
|---|---|---|---|---|
| Sector A backhaul (000–120°) | 5 GHz upper | 149 | 40 MHz | Serves N1, N2 |
| Sector B backhaul (120–240°) | 5 GHz upper | 157 | 40 MHz | Serves N3, N4 |
| Sector C backhaul (240–360°) | 5 GHz upper | 165 | 20 MHz | Serves N5, N6 — top of band, keep narrow |
| Access — 5 GHz | 5 GHz lower | 36 / 44 | 40 MHz | Reuse freely between zones >300 m apart |
| Access — 2.4 GHz | 2.4 GHz | 1 / 6 / 11 | 20 MHz | Never 40 MHz. This is your real coverage layer |
| Mesh uplink (M1, M2) | 5 GHz lower | 48 | 40 MHz | Dedicated — do not share with local access radio |
Three sector radios on one 12 m mast will desensitise each other. Give them at least 1 m of vertical separation, keep C at 20 MHz, and if you still see retries, drop A and B to 20 MHz too — you only have 100 Mbps upstream, so backhaul width is not where your throughput is lost.
The CPE210 is tempting for the one obstructed shot to N6, but a 2.4 GHz backhaul steals a channel from the layer that's actually doing your coverage. Prefer a 5 GHz mesh hop from N1 instead, and keep the CPE210s as your NLOS spares and a same-day fix when a link goes down. If you must use it, put the link on channel 11 and force that zone's AP onto channel 1.
| VLAN | Name | Subnet | Gateway | Carries |
|---|---|---|---|---|
| 10 | MGMT | 10.10.10.0/24 | 10.10.10.1 | CPEs, sectors, EAPs, switches, controllers. Untagged nowhere |
| 20 | HOTSPOT | 10.20.0.0/22 | 10.20.0.1 | Public SSID. Client isolation on. 1 022 hosts |
| 30 | BACKHAUL | 10.30.30.0/24 | — | Router-to-router transit when the second Starlink lands |
| 40 | OPS | 10.40.40.0/24 | 10.40.40.1 | Site cameras, your own laptop, anything you own |
DHCP lease on VLAN 20 should be short — 30 to 60 minutes. A /22 fills faster than you'd expect when every passing phone probes and grabs an address it never uses.
That number is the whole design. It is genuinely workable for messaging, social and standard-definition video — but only if the queueing is right, because Starlink's variable latency will wreck an unshaped hotspot long before the bandwidth runs out.
| Setting | Value | Why |
|---|---|---|
| WAN queue type | cake or fq_codel | Kills bufferbloat on the Starlink uplink. Single biggest quality win available to you |
| Global limit | 85–90 Mbps | Shape below the real rate or the queue lives in Starlink's buffer instead of yours |
| Per-user fairness | PCQ on dst-address | One user with a download can't flatten a zone |
| Messaging tier | 0.5 Mbps | Plenty for WhatsApp text and voice notes |
| Social tier | 1.5 Mbps + burst | Burst makes feeds feel fast without costing sustained capacity |
| Video tier | 3 Mbps | Reliable 480p, occasional 720p |
| Unlimited tier | 6 Mbps | Cap it anyway. "Unlimited" is about time, not rate |
Every dish sits behind CGNAT with no public IP, so there is nothing on your side to bond to. Anyone promising "combined 300 Mbps" from three dishes on one router is describing load balancing, not bonding.
What you can do, in ascending order of cost and complexity:
| Approach | What you get | Cost | Verdict |
|---|---|---|---|
| Zone assignment + failover Each dish serves its nearest zones; backhaul ring reroutes on failure | Full capacity per island, automatic survival of one dish going down or getting obstructed | Backhaul links only | Do this. It's also the only one that survives a dish outage |
| PCC load balancing on the RB5009 Per-connection hashing across two WANs | Aggregate throughput across many users. No single session goes faster | Free, config only | Add it on top. Hash on src-address so a user's sessions stay on one path |
| True bonding via VPS + SpeedFusion or OpenMPTCProuter | Genuine session aggregation and seamless failover | VPS + its bandwidth, monthly, plus added latency | Only worth it if you're selling an SLA. Not for open hotspot |
Physically: put dish 2 at N2 and dish 3 at N5 — your two shop clusters, which are also your two heaviest zones and roughly 180° apart. That's where the E50UG earns its place: a small RouterOS box at each satellite site doing local NAT and hotspot, with OSPF between the three routers over VLAN 30 so traffic reroutes automatically when a path or a dish drops. Then close the ring by adding one CPE510 link N2↔N5 so the topology is a triangle, not a star — that single extra link is what turns three dishes into redundancy instead of three separate outages waiting to happen.
Not RF. Not capacity. Power. And the surprise is that Starlink is roughly 60% of your hub's entire draw — it dwarfs every router and radio combined.
| Site type | Load | Daily energy | Battery / solar |
|---|---|---|---|
| Hub — Starlink, RB5009, PoE switch, 3 sectors, EAP | ~130 W | 3.1 kWh | 200 Ah LiFePO4 @12.8 V + ~1 kW PV, or 48 V bank. Budget the dish separately |
| Standard node — CPE510 + EAP225 via passthrough | ~17 W | 0.41 kWh | 50 Ah LiFePO4 + 200 W PV ≈ 1.5 days autonomy |
| Dense node — CPE510 + SG1005P + EAP610 | ~35 W | 0.84 kWh | 100 Ah + 300 W PV |
| Mesh point — EAP225 only | ~12 W | 0.29 kWh | 50 Ah + 150 W PV |
Every mast run gets an Ethernet surge protector at both ends, an earth rod at the base bonded to the mast, and outdoor shielded Cat5e with the shield grounded at one end only. A single close strike on an unprotected node takes out the CPE, the AP and quite often the switch port back at the hub. At roughly $12 a protector this is the cheapest insurance in the whole BOM.
| Item | Qty | Unit | Line | Role |
|---|---|---|---|---|
| MikroTik RB5009UG+S+IN | 1 | $220 | $220 | Hotspot edge, queues, OSPF |
| MikroTik mANTBox 15s | 3 | $185 | $555 | 120° hub sectors |
| TP-Link CPE510 | 7 | $55 | $385 | Node clients + 1 spare + ring link |
| TP-Link CPE210 | 2 | $40 | $80 | NLOS spares, emergency link |
| TP-Link EAP225-Outdoor | 6 | $100 | $600 | Standard + mesh zones |
| TP-Link EAP610-Outdoor | 3 | $170 | $510 | Hub zone + 2 shop clusters |
| TP-Link EAP110-Outdoor | 1 | $55 | $55 | Low-value edge zone |
| TP-Link TL-SG2210MP | 1 | $180 | $180 | Hub PoE+ trunk, 150 W |
| TP-Link TL-SG1005P | 2 | $60 | $120 | PoE+ at dense nodes |
| MikroTik E50UG | 2 | $130 | $260 | Satellite routers — Phase 3 |
| Omada OC200 | 1 | $110 | $110 | Or run software controller free |
| Ethernet surge protectors | 18 | $12 | $216 | Both ends of every mast run |
| Masts, brackets, guy kit, shielded cable | — | — | $650 | 12 m hub pole + 8 m node poles |
| Hub power — LiFePO4 + PV + MPPT | 1 | $900 | $900 | Excludes the dish itself |
| Node power kits | 9 | $220 | $1 980 | Battery, MPPT, panel, enclosure |
| Full build, before Starlink hardware and duty | ≈ $6 821 | |||
Prices are indicative landed USD and will move with your import route — treat them as ratios, not quotes. Note the shape of it: radios are only about 40% of the spend. Power and steel are the rest, and they're the parts people forget to budget.
Yes. Pharos OS gives you AP, Client, Repeater, Bridge, AP Router and AP Client Router. But the antenna is a 13 dBi dish at ~45°, so it behaves as a narrow sector, not a hotspot. Worse, the link is asymmetric: a phone 400 m away will see full bars from the CPE and be completely unable to reply. Use it as a backhaul client. That is what it's good at.
802.11n, 2×2, 5 GHz only — expect around 150 Mbps of real TCP throughput, which comfortably exceeds your entire 100 Mbps Starlink feed. As a backhaul client it is more than enough. As a shared AP for a shop cluster, 802.11n's lack of MU-MIMO and its airtime behaviour with 20+ phones is exactly why the EAP610 goes there instead.
Some of them, and this is the one spec to verify against your actual hardware revision before you order. The two-port CPE510/CPE210 pass 24 V passive PoE out of the second port. That suits the EAP225-Outdoor and EAP110-Outdoor, which accept 24 V passive on most revisions. It will not run the EAP610-Outdoor or EAP650-Outdoor — those are 802.3af/at only and need a proper PoE+ source. TP-Link changes passthrough support between v1/v2/v3, so check the label. Practical rules: keep the passthrough run under 30 m, never chain two devices off it, and budget a TL-SG1005P plus local power at any site getting a 610 or 650.
Omada mesh on the EAP225-Outdoor works well, and your 2-hop ceiling is the right instinct — each hop roughly halves usable throughput on a shared radio. Keep hops under about 150 m with clear LOS, run the mesh uplink on a dedicated 5 GHz channel, and steer clients at mesh points onto 2.4 GHz so the backhaul radio isn't also serving phones. Mesh is infill, not architecture: any zone that proves busy should get a CPE510 and become a wired node.
One place only: a low-value edge zone where you want presence more than performance. It's 2.4 GHz, 802.11n, single-band — it will cover ground cheaply and fall over under load. N6 in this plan is that site. Don't put one anywhere you expect to sell passes in volume.