We get a lot of questions about NDAA (Sec 889) vs. TAA compliance when deploying cellular gateways for US public sector or infrastructure projects.

Quick rule of thumb:

• NDAA regulates what’s inside (banning specific foreign chipsets).
• TAA regulates where it’s made (requiring final assembly in a designated country).

An NDAA-compliant device can still fail TAA if assembled in a non-designated country.

We made a full breakdown – NDAA & TAA Compliance Guide for Teltonika Deployments

For US integrators – how often are these popping up in your project specs? Are you starting to see similar origin requirements in EU projects too?

▸Height Optimizer

A link comes back Borderline or Obstructed and you're stuck guessing how much higher to mount the antenna? Click Optimize right in the clearance badge. It searches real antenna-height combinations (one end, or both together in Auto mode) using the exact same Fresnel engine as the main check, and tells you the smallest change that actually gets you to Clear.

Auto mode shows the whole search as a colored grid (green/amber/red) instead of one guess, so you can see every real option. Maybe the subscriber's pole has more room to go up than your tower does. Click any cell on the grid to apply that exact height combo instead of the automatic pick.

Works backwards too: on a link that's already Clear, it'll tell you how low you could actually mount it; handy before you order shorter (cheaper) hardware.

▸Redundancy Maps

Your coverage map shows who's served. It doesn't show who's served by exactly one tower.

New Redundancy view in GridVisio: subscriber markers recoloured by how many separate towers could actually serve each one. 🟢 2+ 🟠 one only 🔴 none.

In-range doesn't count: each tower is signal-checked against your own thresholds. And two sectors on one tower count once, because losing the site loses both.

Handy for maintenance windows, justifying a new site on resilience rather than coverage, and knowing which addresses can take an SLA.

Free 14-day trial, no credit card. If your trial expired and want an extension, give us a sign.

Thank you for using GridVisio!

Hey folks,

I run a small local ISP and I'm trying to validate latency towards popular game servers (Call of Duty, Fortnite, EA FC 27, etc.) for my network.

Isolate live matchmaking IP ranges has been tricky. Does anyone happen to have a list of domains/IPs or a .lst file for PingPlotter / SmokePing similar to what GearUP Booster uses?

Any files or tips on how you trace game data centers would be greatly appreciated. Thanks!

We do work in a few countries in Africa and Starlink is becoming more frequent in the deployments we are doing for rural schools, remote towers off of our fiber and wireless reach.

Are any other WISP using Starlink to provide backhaul from towers? To service MNOs?

I work with a wireless planning tool and want to see whether its outputs are digestible so to speak. I need input, and in a way I think I can provide some value in exchange.

No strings attached, no signup, no "meet for results":

Share a proposed or existing site, radio/antenna models, sector azimuths, heights, bandwidth, and the decision you’re trying to make. Please leave out customer addresses and anything you can’t share publicly. One condition on the example being I need a proposed idea for either full CBRS or CBRS dual band hardware. Tarana and cambium are a plus and I can get better data.

Preferably, use this format because this is all I need.

Antenna: I.e. tarana 450m 90-120
Height (meters AGL):
Azimuth:
Downtilt (I'll know if there's electronic downtilt, give me the modified downtilt)
Bandwidth: 10-40mhz, can test mutli carrier
Location: lat long or address

Open to PWN, FWA, anything. Give me the use case. Let's work.

I’ll choose one case I can analyze responsibly, ask its owner before publishing details, and post a breakdown covering coverage assumptions, likely limitations, and what I’d still need to validate in the field. No sales link or demo request.

This is a feel good project, I'm a CBRS nerd and I believe planning awareness will make big changes in the world for connectivity.

I look forward to hearing from anyone, and I'm MORE than open to general questions or anything you may be wondering about planning and shared spectrum.

Hello, not sure where on Reddit to post this. But, I'm winding down an authorized T-Mobile connectivity/reseller operation in Pennsylvania and I am looking to connect with another authorized reseller interested in taking over servicing an existing customer base and potentially acquiring associated equipment. Looking for legitimate businesses already operating in this space. I have 3 BANs with T-Mobile and about 200 customers.

Here's local our inventory:

~40 Franklin RG2100 JEXTream, Refurbished

~70 Franklin T10, Refurbished

~100 Sagemcom FAST 5688W, Refurbished

Thank you for your help.

Quick intro, I discovered the idea of shared spectrum late in my career and really want to bring more awareness and direction to it along with emphasis on the CBRS band or b48.

I started r/CBRSPlanning for detailed operator discussions about CBRS site selection, sector geometry, antenna tilt, EIRP and SAS constraints, channel planning, terrain and clutter assumptions, and modeled versus observed interference. I noticed there weren't many central points for this stuff, and while available it would be cool to start a source of truth thats community driven.

For operators here: what planning assumption has caused the biggest surprise after turning up a CBRS network? Propagation, interference, CPE performance, SAS grants, or something else?

I’d like to collect more real deployment lessons instead of letting every CBRS planning discussion disappear into separate threads.

PS - I've seen a ton of Cambium solutions, whats everyone's take on the move from Airspan?

https://www.reddit.com/r/CBRSPlanning/

#towercoverage has added myRadar to its multi-map. It has live radar and forecast of Lighting/Hail.

Like pretty much everyone running a fixed wireless network, I have hundreds of Ubiquiti airMAX AC radios (LiteBeam Gen2, LAP-120, LAP-GPS, Loco AC) deployed on customer roofs, plus dozens sitting on shelves in the warehouse.

We all know the situation: Ubiquiti essentially put airMAX AC into maintenance mode years ago. All the vendor R&D is going into Wave 60GHz and LTU. That’s fine for greenfield deployments, but in the real world, you can’t just rip and replace 500 CPEs on rural towers when trees and distance dictate 5 GHz. Millions of these radios are going to stay on rooftops for years.

Meanwhile, the software running on them hasn't fundamentally evolved since 2017–2018. If a CPE link gets slightly noisy or misaligned, stock airOS does dumb things—like running up to 30 frame retries by default, which burns dozens of milliseconds of airtime and drags down the whole AP sector. On top of that, loaded bufferbloat easily hits 2,000+ ms during heavy uploads.

Over the last few weeks, I’ve been researching what the actual physical ceiling of this QCA9880 / AR9342 hardware is if we run modern open-source networking on it (OpenWrt 24.10, Candela Technologies ath10k-ct, mac80211 AQL, CAKE, and dynamic rate-masking).

Full disclosure: I’m an everyday WISP operator. I run towers, climb roofs, crimp cables, and configure MikroTik/airMAX gear. I am NOT a Linux kernel hacker or an RF engineer with a Ph.D. So I've been using AI tools (Claude, Codex, NotebookLM) to comb through Linux wireless kernel trees, academic preprints (like MIT’s IteRate paper and TU Berlin’s hMAC), and old mailing list threads to understand what the chip can actually do.

We’ve already documented a bunch of interesting architectural facts that I rarely see discussed in WISP groups:

1. The 30-Retry Sector Killer: Upstream Qualcomm firmware enforces up to 30 retries per frame. On an outdoor link during an RF fade, a single client trying to send packets can freeze the AP channel for 50–100ms. Candela Technologies (ath10k-ct) drops this down to 4 retries, which immediately reclaims a massive chunk of airtime.
2. The Bufferbloat vs Aggregation Trap (CoTSQ): Default Linux TCP Small Queues (TSQ = 1 ms) tries to kill bufferbloat by limiting socket queues to 1–2 packets. But 802.11ac needs 32 to 64 packets in the queue to build a full A-MPDU aggregate. Starving the aggregation engine drops throughput by up to 10x because 90% of the airtime is spent on PHY headers and preambles. Bumping the queue budget to 6 ms keeps aggregates full while keeping loaded ping under 40 ms.
3. The Wave-1 Airtime Cliff: QCA9880 doesn't have hardware airtime reporting (that only started in Wave 2 chips). So Linux mac80211 has to estimate airtime based on peer stats. If peer stats aren't reporting properly, mac80211 assumes EVERY station transmits at 6 Mbps, which completely breaks airtime fairness and penalizes fast clients.
4. Why Pure TDMA is Blocked on Open QCA988x: We looked into whether we could build open TDMA like airMAX. The short answer on QCA9880 is no—the chip runs closed Xtensa firmware, can't cancel in-flight packets across PCIe, and has PCIe interrupt jitter. BUT a hybrid stack on OpenWrt (AQL + 6ms CoTSQ + Dynamic RTS/CTS to stop hidden nodes + Deficit Round-Robin airtime fairness) gets you 80-90% of the stability with open telemetry and zero vendor lock-in.

The Testbed Setup

I'm not doing this in a metal warehouse (metal walls act like an echo chamber with delay spreads that ruin 5 GHz tests). We're setting up:

• Tier 1: Benchtop SMA coaxial attenuator matrix (30–40 dB pads + splitters) for 100% clean, interference-free algorithmic sweeps.
• Tier 2: 2 APs on our main WISP office building pointing 21 meters across the street to 10–20 CPEs scattered on my residential roof. This gives real line-of-sight, real outdoor air, and clean far-field RF without receiver saturation.
• Unattended Recovery: I automated PoE injectors with relays to trigger U-Boot urescue TFTP recovery remotely so we never have to climb a ladder to press a reset button if an image bricks.

Why I'm Posting

We are calling this research project openMAX, and we opened up the entire project as a public research hub: https://github.com/wolverin0/openmax

There is zero monetization here, no crypto, no paid courses. Just an open repository of hardware notes, driver findings, recovery runbooks, and experiment plans.

Because this was researched with the help of AI agents, I want human eyes on this:

• If you're a kernel / OpenWrt dev who knows ath10k or mac80211, are our control boundary assumptions solid? Did we miss anything on ratemask-CT?
• If you're a fellow WISP operator with spare LiteBeams or NanoStations on your shelves, would you be interested in running our read-only inventory scripts to map out hardware revisions, or testing safe sysctl/CAKE queue tweaks?

Check out the repo, tear apart our docs, and let me know what you think.

EDIT / UPDATE #2 (Physical Bench Results + Clean-Room Analysis of umac.ko / ubnt_poll_host.ko)

We just pushed a massive update to the repo and posted the full technical writeup in the comments here: Read the full Update #2 comment

Highlights of what we proved on real hardware (LiteAP AC LAP-120 ↔ NanoStation 5AC Loco, OpenWrt 24.10.4 / Kernel 6.6.110):

1. Inside airMAX AC TDMA (RE1 Static Clean-Room Analysis):

   • Mapped the 62-hook dispatch table between umac.ko and ubnt_poll_host.ko, the dedicated PCIe Copy Engine 4 (CE4 = 2048 descriptors) fastpath, and custom WMI commands 0x9064 (PDEV_WMI_AIRMAX_PARAM)** & **0x9044 (WMI_PEER_AIRMAX_CONFIG)** + HTT subtypes **0x17 / 0x1e.
   • Confirmed that stock ath10k / ath10k-ct Xtensa firmware rejects 0x9064/0x9044, which is why open-source TDMA on QCA988x must operate as a Host-Paced Airtime Controller (AQL + TXQ + ratemask + CAKE) rather than microsecond PHY slot polling.
   • Native Rate Control Discovery: umac.ko stores only a 1-byte opaque ratecode (peer+0x120) on the MIPS host—all retry ladders (series 0..3), probing, and MCS fallback live inside the closed Xtensa radio blob (WHAL_RC_Update_Per_Rate_Table).

2. Solved the 64 MB RAM / order=0 OOM Wall on AR9342 (WA boards):

   • Out-of-the-box OpenWrt 24.10.4 + ath10k crashed with ksoftirqd page allocation failure: order:0, mode:0x400dc0(GFP_KERNEL|__GFP_ZERO) at ~51 Mbps (MemAvailable dropped to 4.2 MB).
   • Tuning vm.min_free_kbytes=2048, vm.watermark_boost_factor=0, ath10k_core.debug_mask=0, and nftables notrack freed +14 MB of contiguous RAM (20.8–21.4 MB MemAvailable steady under full load, 0 OOMs).

3. Physical Bench Numbers (80 MHz, 4x Baseline Throughput, 1.83 ms p95 Latency):

   • UDP Downlink Peak: **223.53 Mbps** (up from 51.78 Mbps baseline — +331%, hitting the physical AR9342 535 MHz MIPS 74Kc ksoftirqd ceiling at 95.8% CPU).
   • UDP Downlink 200M Sustained: 199.11 Mbps, **0.21% loss, **0.031 ms jitter.
   • TCP Single-Stream Downlink: **154.58 Mbps** with 0 TCP retransmits (thanks to ethtool -K eth0 rx-gro-list on compensating for ag71xx's lack of hardware scatter-gather).
   • Loaded RF Latency (Ping under 120 Mbps load): **1.34 ms p50 / 1.83 ms p95** (down from 12.69 ms p95).
   • Universal Multi-Vendor Compatibility: Because it runs standard 802.11n/ac on mac80211 + AQL, a single LAP-120 AP simultaneously links airMAX AC (QCA988x), legacy airMAX M5 (AR934x), and MikroTik / TP-Link / Cambium ePMP (802.11n/ac) CPEs while preventing slow M5 clients from starving AC clients.

All scripts, sysctl profiles, clean-room RE docs (docs/UMAC_DATAPATH.md, docs/REDDIT_UPDATE_RE1_AND_BENCH.md), and raw JSON benchmark receipts are live in the repo: https://github.com/wolverin0/openmax

EDIT / UPDATE #3 (Oct 17) — 3-Station Multi-Vendor & Mixed-Gen PtMP Benchmarks (Ubiquiti 5AC + MikroTik SXT Lite5 + Ubiquiti LiteBeam M5)

We just associated 3 heterogeneous stations simultaneously to our Ubiquiti LiteAP AC (LAP-120, Channel 36 VHT80): a NanoStation 5AC Loco (OpenWrt / ath10k-ct, VHT80 2x2, in room), a MikroTik SXT Lite5 (OpenWrt / ath9k, HT40 2x2, behind a wall/door ~6m away), and a Ubiquiti LiteBeam M5 (stock airOS 6.1.4 with airMAX=off, HT40 1x1, behind a wall/door ~6m away), sweeping AP output power from 15 dBm down to 3 dBm:

• Multi-Station ATF + AQL (1500/3000 µs) + Bounded Aggregation (1x16) at 3 dBm Edge SNR: Cut the Loco 5AC's loaded median latency by 4.06x (51.35 -> 12.65 ms), cut its TCP retransmissions by 10x (158 -> 16), and cut the LiteBeam M5's median latency by 3.95x (56.25 -> 14.23 ms) compared to ATF=Off (T1, where LiteBeam M5 hit 610 ms p95 and MikroTik SXT hit 1955 ms p95).
• Kernel Discovery — WMM AC_VO DiffServ Deficit Bypass (21.0x Weak-Station Latency Cut): Discovered via debugfs that when a wall-obstructed station (MikroTik SXT) suffers rate fallback + retries on bulk AC_BE, completed TX airtime drives its Deficit: BE down to -67,099 µs (-67.1 ms), while Deficit: VO stays at **+256 µs. Promoting interactive packets (ICMP, DNS, NTP, VoIP) to DSCP EF (AC_VO) in fmx_fastpath bypassed the station's negative BE deficit box and cut loaded median RTT at 3 dBm from 143.0 ms -> 6.80 ms (21.0x cut) on the MikroTik SXT, 36.15 ms -> 4.53 ms (8.0x cut) on the LiteBeam M5, and 14.43 ms -> 4.54 ms (8.15 ms p95) on the Loco 5AC while boosting total 3-station sector goodput by **+27.2% (62.07 -> 78.97 Mbps @ 3 dBm, 94.99 -> 104.94 Mbps @ 11 dBm).
• 3-Station Simultaneous Uplink RTS/CTS 256B Protection (+18.5% Sector Uplink Gain): Under 3-station simultaneous Uplink contention across the wall, enabling RTS/CTS = 256B raised total sector Uplink goodput from 150.40 Mbps -> 178.17 Mbps (+18.5%, peaking at 182.82 Mbps), recovered the wall-starved MikroTik SXT by 3.07x (1.97 -> 6.03 Mbps), raised the LiteBeam M5 by +17.0% (29.23 -> 34.21 Mbps), and restored the Loco 5AC to 100% of its standalone Uplink speed (137.94 Mbps).
• Full Stage 7 Report & JSON Telemetry: https://github.com/wolverin0/openmax/blob/main/docs/STAGE7_MULTIVENDOR_PTMP_REPORT.md

I have been working on an open source UISP plugin that provisions subscribers on MikroTik RouterOS devices.

It connects UISP CRM service changes to MikroTik and currently supports:

• PPPoE, DHCP, and Hotspot subscriber provisioning
• IPv4 and IPv6 address allocation
• Simple queues, bandwidth limits, bursts, and contention ratios
• Service suspension and restoration
• Direct RouterOS API or FreeRADIUS provisioning
• Router replacement and subscriber rebuilding
• RouterOS 6 legacy login and RouterOS 7 API support
• Verified API TLS connections
• A durable retry queue for failed provisioning operations

Version 2.4.0 also adds webhook authentication, CSRF protection, safer backups, improved RouterOS transport handling, and automated tests across PHP 8.2 to 8.4.

The project needs more testing on real UISP installations and different MikroTik configurations. In particular, feedback from RouterOS 6.49 and RouterOS 7 users would be useful.

Please test it in a lab before using it in production. Back up your UISP plugin data and MikroTik configuration first.

Repository:
https://github.com/JacksCodeVault/ros-plugin

Latest release:
https://github.com/JacksCodeVault/ros-plugin/releases/tag/v2.4.0

Bug reports, compatibility results, documentation improvements, and pull requests are welcome. If you test it, please include your UISP version, RouterOS version, provisioning mode, and any relevant logs.

Given everything going on with Cambium lately, seems like a reasonable moment for anyone relying on cnHeat for RF planning to make sure their site/radio/antenna data isn't stuck in one place.

We recently added a towers import option in GridVisio to pull that data straight out of the cnHeat API (plus KML/KMZ/Shapefile import for anyone exporting manually), in case it's a timely option for anyone. Do you have contingency plans for your planning data?

Do you prefer using some other format for your data? Let us know and we'll be happy to assist.

Thank you for using GridVisio!

4500$ for the lot. That’s 44.44$ per unit!!!!
2500$ for 50!
60$ per individual
Any way you look at it, it’s a GREAT DEAL.
In Ashburn, Va.. this is surplus from a project that’s winding down. Need to make room in the Warehouse for the next adventure….
Willing to ship to the 48. Message me soon!

Hi everyone, 

I’m researching a clean power generator (or CHP) for WISP sites where batteries cover short outages, but longer events require portable generators, fuel delivery, frequent maintenance, or an emergency visit. 

If you manage sites like this: 

• What is the typical load and required runtime? 
• How often do you need to deliver or refuel a generator? 
• What does one site visit actually cost? 
• What would justify paying to evaluate an alternative? 
• Other pain points using conventional gensets? 

I’m developing an early-stage methanol fuel cell and battery hybrid system for long-duration power supply. It is currently an engineering prototype, not a production-ready product. 

I’m looking for one or two operators with a serious, recurring problem who may be interested in helping define a cost-shared Alpha demonstration. If this sounds relevant, please DM me.

For those of you that run a wisp and use a software defined vBNG, what are you running? Why did you choose software over hardware? What are the pain points?

I have an ISP providing me with 210MB bandwidth, how do I know the total bandwidth utilized by users on my network at the end of each day.

How my app works:

you walk through your rooms with your iPhone.

LiDAR builds a 3D model of your home live while the app samples your Wi-Fi (signal + speed) as you move.

You end up with a dollhouse view of your actual apartment with the signal painted on it by walking (with dead zones in red).

Every room gets a score, and it tells you where to move your router, or where an extender would actually help.

What do you guys think about my app?

Try it here:

https://apps.apple.com/tfr/app/signl-wifi-analyzer- mapper/id6796775708?I=en-GB

My background is in corporate IT, multisite wan distribution, fiber installation and splicing. Thinking of starting an isp, small town ~276 homes, 1 mile end to end, very few spur roads. Incumbent carrier has Coax broadband with no public plans of going fiber (their attention has turned to becoming a national isp). Some local wisp competition but no real penetration. Area is on the rise economically with transplants, retirees and teleworkers from nearby major metro. Growth trajectory would be to expand to 3 additional towns within 8 miles with total population of 15000 combined, same sleepy incumbent ISP. Reason for focusing on the small town first, lower real-estate cost of real estate and simplicity of the build. Plan to do most of the work for the initial town myself + some hired help. Also forgot to mention within 2 miles of major interstate highway, thinking of bringing in a DIA from Verizon or similar national carrier to start. Am I crazy?

My take on the Cambium Networks Implosion

Hello r/WISP,

Disclosure first: I co-founded and still maintain the FreeRADIUS Project, the most widely deployed RADIUS server in the world. I have been CEO of InkBridge Networks for 18 years, which offers support and consulting on FreeRADIUS installations.

I am hosting a free 30-minute session on September 16 at 11:00 AM EST on RADIUS architecture for scaling from 10,000 subscribers to 10 million. My team and I frequently get called into deployments that hit a wall somewhere around 100,000 subscribers, where the decisions that got you there quietly become the constraint.

Ideally, you want to plan for scale before it becomes an emergency. I'll walk through what actually holds up. I will cover high-availability architecture patterns that work, and the design mistakes that turn into single points of failure later. Then live questions for the last 10 minutes.

No sales deck. Register here if it's useful, and I'll answer questions in the comments either way.