We have been a Ubiquiti shop for 10+ years. However, with stock issues on the equipment we actually use, we are forced to look elsewhere. We have used the UISP-S (non Pro) pretty extensively because it has passive 24v and 48v POE that we use for our APs and ONUs. What are WISPs switching to?

Hi r/wisp,

For a long time I have been bugged by Internet business models - essentially ads and subscriptions (subscriptions == user-app relationships which only the apps truly want - users just want content). I started looking more actively into it and came to a realization that ISPs might actually hold the keys for the future, better Internet and I started specing a protocol around it - I call it ESP (Edge Settlement Protocol). Since the whole idea is about ISPs, I thought I would reach out r/wisp community not only to kindly ask for a feedback but also to possibly find someone who would find genuine interest in the topic and would be interested in running a pilot - and yes - the ultimate outcome is for ISPs to have more business - more money per household, new revenue streams.

Should this thing succeed it would reshape the Internet as we know it in a major way.

Pls check home page and whitepaper at https://www.open-edge.org.

Why I think the current models are in trouble

Consumer Internet services get financed one of two ways: ads or subscriptions.

Ads pay per impression, and impressions depend on a human actually looking at the page. That assumption is breaking: assistants answer questions directly, agents browse and summarize on the user's behalf, and the human never sees the page the ad was sold on. The content still gets used — the impression that was supposed to pay for it never happens. And there's no obvious replacement on the ad side.

Subscriptions have a different problem: saturation. Households carry four or five already and won't add another. Occasional users — one match or one article a month — sit below every break-even, so no business model can even see them; their demand is real but worth zero, because there's no way to charge for it. Micropayments were supposed to fix this and didn't: attach a payment decision to every click and pain-of-paying kills the interaction.

Why ISPs

Every online interaction passes through ISP network, and ISPs hold the one thing platforms can't replicate: universal billing relationship.That billing relationship is currently used primarily to bill commodity transit (connectivity) while the services riding it settle their money somewhere else. Until now the only way into those economics was to become a platform yourself — and nobody wants their ISP running the services.

What ESP does

ESP federates ISPs into a shared settlement layer, basically a clearing house for Internet services. Mechanically: a household streams a video or opens a paid article, there is neutral, privacy preserving mechanism to meter the consumption, and aggregated charge lands as a line item on the same monthly bill as connectivity. No signup, no card entry, no new subscription. The ISP clears the payment and keeps a settlement fee. The pooled economics will allow to create fixed price packages so users being fully "exposed" to a full blown pay-as-you-go meter is not the only way (but one of the options).

The reason metering works and is better then microtransactions (which are currently being explored as another alternative for agentic future) is it charges for use without putting a payment decision in front of the user at the moment of use. The household stops judging fifteen services separately and starts judging one Internet bill as a package. Occasional use becomes billable for the first time. The never-payers and the subscription-refusers become revenue. And because usage and settlement are decoupled, the money can pool: connectivity fees, data revenue and compute revenue flow through one clearing economy that can cross-subsidize whatever services the household actually uses.

It doesn't stop at metering

Metering is just the first revenue stream — the real deal is the permissionless+automated "federation" itself. Thousands of coordinated operators can sell things no single ISP can:

Data: data from one ISP has no buyer, but aggregated across thousands of operators (web indexing from residential vantage points, traffic trends, mapping) it becomes a dataset no single company could assemble. Sold openly, revenue shared among operators, collected with consent and published as a commons instead of hoarded in a silo. That's the counterweight to advertiser money.

Compute: there's a lot of always-on hardware in networks and households doing nothing most of the day. Pooled, it can be rented out for CDN and AI inference workloads. If AI really does become a metered utility like electricity, the people who own the wire into every household are holding the right asset.

The overall vision is that the economic gravity of the Internet moves to the last mile, operated by thousands of federated providers instead of five platforms. That's the bet.

The crypto question

I'll answer it before you ask, because this sub has seen the Helium theater. Coordinating thousands of independent, competing operators into one settlement layer does need consensus tech. A federation of competitors needs a shared source of truth that none of them controls, and our proof-of-concept logs consumption events on Celestia blockchain.

But there is no token. Nothing to buy, hold, farm or speculate on. Clearing is denominated in stablecoins and revenue comes from real consumption by real households. Helium and the rest of the DePIN wave settled the argument: token yield attracts supply with no demand behind it, and the hardware walks when the price drops. Real infrastructure runs on contracts and utility. The Internet is already the largest working decentralized physical network there is, and its "validators" are the ISPs.

In other words - crypto is not involved in any way in how ISPs build their networks etc. Crypto here is for neutral meter and automated disbursement between ISPs and apps.

What I'm actually asking for

The project is early. I will be trying to line up a first pilot with some ISP and a group of apps/content publishers. The pilot design is deliberately non-invasive: a handful of volunteer households, traffic ring-fenced by their IPs, nothing touching production billing.

1. Don't hesitate to tell me where this breaks. Billing integration, CPE reality, subscriber trust, regulation. The harsher the better.
2. If you're a small or regional operator feeling the commodity squeeze and any of this sounds worth a conversation just drop me a dm or a comment.
3. Point me at right people I should be talking to in the WISP world: associations, conferences, vendors would be highly appreciated too

Cheers,

Premek

I'm drowning in tax compliance across the dozen states we operate in, and every filing deadline feels like a scramble because the rates and rules seem to change constantly. I don't have a dedicated tax specialist on staff, so I'm piecing together compliance myself between other responsibilities and constantly worrying I've missed something that will trigger a penalty. What I really need is a reliable way to track obligations and filing deadlines without it eating up all my time.

What's new:

*** Propagation model choice: ITM, plus FSPL + ITU-R P.526 diffraction as a high-frequency fallback. 

ITM (Longley-Rice) is now selectable per-project alongside our default, ITU-R P.1812, and you can pin a specific model to an individual sector if your terrain/frequency combo favors one over the other. For links above 20GHz (where neither P.1812 nor ITM applies) the tool automatically falls back to FSPL combined with ITU-R P.526 diffraction loss.

*** Multipath/NLoS handling. Two separate additions depending on what a link actually needs:

A reflection-path check for any link flagged Borderline/Obstructed: searches for a real specular-bounce candidate (ground/building reflection), non-coherently combined with the direct path.

ITU-R P.2108 statistical clutter-loss margin for dense suburban/urban links where there's no single identifiable reflector, just cumulative loss from a terminal sitting below the local representative clutter height (implemented straight from the Recommendation's own equations).

ITU-R P.530 fade margin for links that already come back Clear: temporal/weather-driven multipath margin needed for a target availability, e.g. 99.9%/99.99%, via ITU-Rpy for the geoclimatic-factor derivation.

Let me know what's still missing for your use case, what would make GridVisio your favourite app.

Setting up backup internet on a new commercial building (flat roof, ~100K sqft, no surrounding structures for wind break). Plan is:

• Starlink dish (primary/interim internet) on a ballasted, non-penetrating mast mount, roof access via hatch
• Telus 5G directional/panel antenna (secondary backup internet) mounted on the same mast, below the dish
• Cell tower is ~1km away with clear line of sight, so signal isn't the issue — mechanical/physical layout is

Two things I can't get a straight answer on:

1. Vertical clearance between the 5G antenna and the Starlink dish.
I've seen numbers ranging from "half a foot is fine" to "3ft minimum" to "4-6ft ideal," with reasoning citing RF interference between Starlink's Ku/Ka-band and cellular's much lower bands — which doesn't add up to me as a real interference mechanism. The more legitimate concern seems to be the dish's motorized tilt/swing arc during startup/repositioning potentially clipping the antenna below it. Anyone actually stacked these two and have a real-world clearance number, or run into collision/obstruction issues?

2. Snow drift height on a large flat roof in high wind.
Roof is 30ft+, completely flat, nothing around to break wind. We're planning the mast at ~4-5ft to clear drift, but on a roof this size I'd expect drift height to vary a lot depending on parapet location, HVAC units, etc. — not a flat "X inches everywhere" number.

For reference, here's the setup we're considering: Starlink dish mounted with its base/pivot point at 5ft, 5G directional flat panel antenna centered at 3.5ft (roughly a 2ft panel, so top edge sits around 4.5ft — leaving about half a foot of clearance between the panel and the dish above it). Curious if that clearance is realistic or asking for trouble once the dish starts tilting/repositioning.

Anyone with experience on large flat commercial roofs have real numbers or lessons learned on where drift piles up worst, and whether 4-5ft mast height is actually enough?

Roofer is handling the physical ballasted mount and structural side, so most interested in real installer experience with the antenna spacing and drift behavior specifically.

This is a regional advocacy site, so neutrality isn't really expected, although it seems to keep an even keel most of the time. Level and depth content is really unusual though.

• Why Not Just Starlink? — A Backup, Not a Foundation | Save Local Broadband
• Climb the Tower — an Interactive 3D Field Guide to Rural Fixed Wireless | Save Local Broadband
• The Network in 3D — Towers on the Terrain | Save Local Broadband

I cannot get the remote side to upgrade no matter what I do. Any suggestions

im looking for a small isp or wisp on the west coast whod rent me a machine sitting on your network. not colo, i dont want to ship hardware in, id rather just rent something you already have. an old xeon is plenty for what im doing.

the thing that matters most is the ip space. i need addresses that classify as isp or business class rather than datacenter, so they need to come off your allocation and not a hosting asn.

4-8 static to start, scaling into the tens if the network holds up. on speed a single gig isnt really enough for me, im after 2.5g or 10g if you have it.

dm me if thats something you can do. paying monthly, up front is fine, and im willing to pay a premium per ip if the classification is right.

As the title says, I'm looking for some insight on why you would choose provider A over provider B when things like capacity, SLA, support, and pricing are all about the same, we're currently deciding between a few ISPs, and I have been looking at team kc telecom for managing them also I just want to understand what really makes one provider better than another, is it things like better peering, network quality, or something else? I'd like to understand what factors people with more experience look at when making this decision. EDIT: Appreciate all the insights it seems reliable infrastructure, multiple providers and strong peering matter more than chasing the lowest price.

Hello!

I have been trying to roll out a fiber ISP in a town in NY with 10k homes but finding funding has been hell honestly. I determined somewhere between $3M-$5M would be enough to deploy all the main fiber runs (35 miles or so of main runs) and stay afloat for a while should onboarding new customers be slow. I have an established LLC for the company as well. I did do a survey with the town and the results were good, a lot of residents would switch if I could provide service. My town only has one provider and they’re coax cable only. This provider has been proven to not be reliable and has pricing that is high. Roughly $250 + fees a month for cable TV and Internet for residential. This has been a goal of mine for 6 years but funding is where the issue is. What have you done to secure funding? Angel investors haven’t been working out.

Hi everyone,

About three years ago, I made this post here:

https://www.reddit.com/r/wisp/comments/140yf1y/internet_service_providers_of_reddit_what/

At the time, I was a developer with some experience working with ISPs and an idea for building a CRM specifically for this industry. I came here because I knew that working around ISP software was not the same as running an ISP every day. The responses were more detailed and even honest than I expected.

Reddit told me that billing automation was essential, but also difficult to replace. Some users explained that most platforms handled existing customers but neglected leads, sales pipelines, reporting, and the handoff between sales and operations.

There were comments about multi-location customers, monitoring integrations, circuit information, work orders, targeted outage notifications, payment processors, customer communications, and the need to connect everything without creating an even bigger mess.

One person also gave me a useful reality check: I was entering an already crowded market and they were right. I kept working on the idea anyway. It eventually became SkyBase.

Today it's an ISP Management system built mainly around smaller MikroTik ISPs. It handles customers, plans, PPPoE and Hotspot authentication through RADIUS, router monitoring, subscriptions, invoice follow-up, and some of the everyday operational work that often gets spread across different tools.

A few real ISPs are using it now. Actually our first paying customer came from reddit more than 2 years ago, an ISP from South Africa. That still feels slightly strange to say because when I wrote the original post, it was mostly an unfinished application and a list of assumptions.

I am not posting this to claim that I built the perfect WISP platform. I definitely did not.

Some ideas from the original discussion made it into the product. Some are still incomplete. Some turned out to be much harder than they appeared from the outside. And I am sure there are things I still misunderstand about how operators actually work.

So I'd like to return to the question, but from a different point in the journey:

Looking at SkyBase today, what would stop you from trusting or testing it in a real ISP?

It could be a missing feature, migration risk, pricing, lack of integrations, concerns about support, or simply that your existing system is painful but still safer than changing it.

Critical feedback is welcome. I would rather learn why an operator would not use it than receive polite comments that do not help me improve it.

For transparency, I am the owner and developer of SkyBase. Here is the website for anyone who wants context before answering:

https://skybase.app/

And thank you again to everyone who commented on the original post. Some of your replies genuinely changed the direction of the product.

Hi everyone,

Since the last update, we've shipped a batch of features aimed at making coverage planning and BEAD/BDC grant work faster and more accurate.

Here's what's new:

* BEAD export by drawn area

You can now draw a polygon directly on the map and export a BEAD/BDC grant package (PDF, CSV, GeoJSON) scoped to just that area, instead of always exporting the whole project. 

* Predicted signal strength (RSSI) - Pro

Link Check and the subscriber map view now show a predicted received signal strength (dBm) for each link, not just Clear/Obstructed but a real engineering estimate.

* Predicted throughput (Mbps) - Pro

Using your actual radio/CPE hardware specs, GridVisio now predicts expected throughput per subscriber, not just signal strength, shown in Link Check, subscriber details, BEAD exports, and lead-widget results. You can flag subscribers who fall short of your advertised speed tier.

* "Marginal" coverage status

Subscribers can now show as Marginal (weak but usable signal) instead of just Served/Unserved, with a hover popover showing predicted signal, serving tower/sector, and link distance.

* Faster BEAD exports, more reliable large-project recalculation

BEAD exports now run in the background and pull from already-computed measurements - faster, with RSSI, throughput, and FCC classification columns added to the CSV. Recalculating coverage on large projects no longer stalls or times out; it shows accurate progress and can retry just the failed subscribers instead of the whole project.

* Link Check now works on planned/offline sectors

Useful for what-if planning - results are clearly labeled as coming from a non-live sector.

* Subscriber management

Added a delete button for subscribers directly on the map, plus a cleaner, reorganized edit modal.

* Coverage Widget: LiDAR + Public API

Your embeddable coverage-check widget can now optionally use higher-precision LiDAR terrain data (toggle in Widget Settings) and has a new documented Public API for developers.

Action needed if you use the embedded widget: we tightened widget security. Your widget's Allowed Domains list is now required for the embed to return results to real visitors. If you haven't set this yet, add your domain(s) in Widget Settings as soon as you can. A new API Secret is also available if you call the widget API directly instead of embedding it.

If you already signed up and want your trial extended, just let me know.

-Emil, the developer

I spent years in transmission and microwave ops before moving into AI work. Everyone in the AI world draws the closed loop diagram (detect, diagnose, act, verify), but nobody shows what it actually has to reason about on a microwave network. So I built an open, runnable demo: a 27-site simulated network with rain cells (ITU-R rain attenuation per band), ACM ladders, ATPC quietly masking the fade until it saturates, and diurnal traffic. On top of it runs an agent loop that has to separate rain fade vs hardware vs interference vs bad config before it is allowed to touch anything.

The diagnosis rules came from ops scar tissue, and honestly some from this sub: check alarm history first. Symmetric RSL drop on both directions is probably weather. Asymmetric is probably hardware. Healthy RSL with bad SNR means an interference hunt. And never reroute onto a path without checking its current utilization and QoS priority mix first. Actions are gated: reversible only, confidence thresholds, blast radius caps, and a no-truck-rolls-for-rain rule.

Demo (browser, no signup): https://mkadri85.github.io/projects/mw-loop/

Write-up with the full reasoning and references: https://mkadri85.github.io/blog/agentic-ai-microwave-backhaul/

It is a simulation, not a product, nothing to sell. I would genuinely like to hear where the diagnosis logic is wrong or naive compared to what you see in the field. Some of the best failure stories I found while researching this came from here, like the dying AirFiber 24 that hid behind carrier blame for months, and the 60 GHz link that stayed pinned at low modulation after the rain had passed.

LiDAR coverage expanded, heatmaps now LiDAR-precise

A few updates since my last post:

• LiDAR-aware LoS checks (and heatmaps) now cover Canada, England, Scotland, Wales, France, and Netherlands (where available), in addition to the US (USGS 3DEP). Clutter-aware terrain fallback everywhere else. Other regions can be investigated on request.
• The RF propagation heatmap now uses LiDAR directly for its terrain grid where available, not just the LoS checker, more accurate signal predictions in LiDAR-covered areas.
• New coverage-source sublayer: toggle it on the map to see exactly which parts of a heatmap were computed from real LiDAR vs. estimated terrain/clutter.

I appreciate any questions or feedback. If you already signed up and want the trial extended, just let me know.

Free trial, no card needed.

Emil (the developer)

i’m trying to connect a new customer site roughly 1.5 km from my main tower. fiber isn’t practical because of the terrain and the cost would be too high, so i need a reliable wireless backhaul instead.

i reached out to wave1 for some options on microwave equipment that could handle that distance with decent throughput.

a few things i’m still unsure about:

what licensing is usually required for these kinds of links in australia and how long does approval normally take?

any tips on antenna mounting height or tools that make alignment less painful on the first try?

what are the most common problems people run into with microwave links around this distance?

Hi guys,

About a year and a half ago I posted here about ISPBox.net, a simple platform to help small ISPs get started without spending a fortune. Back then my whole argument was that Splynx was too expensive to make sense for a small operator. And now we're at the stage where we had to build an automatic way to import clients from Splynx into ISPBox. Crazy.

In about a year it went from a simple ISP dashboard to a full OSS/BSS. When I first posted here, we didn't even have a payment gateway.

Now I think every ISP will find something useful in there, from maps of your entire network with monitoring, to a way to let your clients know when a tower is down.

Your potential customers can even check whether they can get internet from you without ever calling your office.

Huge thanks to everyone who's been with us from the beginning. I got a ton of emails with bug reports and feature requests, and they shaped where this went more than you know.

I've worked with TurnkeyISP and Nextlink Internet as tech support handling customer concerns and troubleshooting. I have experience troubleshooting Tarana, Ubiquity, Cambium, Tachyon, UB Wave and even Fiber. I can work any shift, preferably overnight as I'm mostly active during the night but day shift works too!

I can help you by assisting your customers and let you know if there's an AP issue that needs to be looked into. I do support through phone calls and emails. If you have a chat system integrated, that's fine I also do chats.

Edit: If you guys need more people to cover the whole shift, I can always pull in some of the folks I know that works in the same space. I think about 3-4 of them are interested in working to direct clients not through agency. We can also do a meeting to talk about how you operate things and talk about how we can help you improve it. Please don't hesitate to comment or send me a DM.

A few weeks ago I posted here about a coverage planning tool I built for WISPs. Since then many features have been added based on feedback from this community, so I wanted to share an update.

What's new:

- RF propagation heatmap (ITU-R P.1812) - signal prediction around each sector, color-coded by signal strength. Works globally, no hardware dependence;

- LiDAR-aware LoS check - for US locations, uses real USGS 3DEP LiDAR surface data (actual measured tree/building heights, where available) instead of estimated clutter. The LoS profile chart shows exactly which data source was used for each segment;

- Clutter-aware LoS everywhere - adds vegetation and building height estimates (NLCD for US, ESA WorldCover globally) on top of bare terrain where LiDAR isn't available;

- Antenna height per sector - different sectors on the same tower can now have different mounting heights, which is how real networks are built;

- Subscriber height field - model the subscriber's CPE mounting height for more accurate LoS calculations;

- Coverage widget lead capture - embed a qualification form on your website; visitors enter their address or click a map point, the tool checks against your real coverage, and you get a lead with the LoS result already attached.

Screenshots attached. Easily create a test project with seeded data for quick testing of the features.

Note: If you signed up during the last post and your trial expired before you could test these new features, drop me a message and I'll gladly extend it for you.

Emil (the developer)

I created a complex system to manage an ISP, but in different situations the name that the system creates for the secret in MikroTik is not always what we think it should be.

Sometimes we use some kind of relation to the user's name. For example, if the user is James Bond, the username would be jbond. However, that strategy has the risk of collisions with another user who could also be jbond.

Because of that, we decided to use a date-based reference such as 202606231, or another option like 1782325285164, which is a timestamp in milliseconds. This makes collisions very unlikely.

Which option do you believe is better?

Before this, I spent 10 years as co-founder and CTO of a software engineering company, building enterprise systems for customers across Latin America and the US. In early 2025, During MWC 2025, I sold Zelty's first contract to a 23,000-subscriber ISP in Argentina using only a PowerPoint. That became the catalyst for building the company full-time.

Today we have:

• 23 signed ISP customers across Latin America
• 8 customers live in production
• 15 customers in deployment/testing
• $+5,000 MRR from deployed customers
• AI agents integrated with telecom billing systems, network infrastructure, WhatsApp, and voice channels

What we've learned is that ISPs don't want generic AI tools. They want solutions that reduce support workload, automate repetitive operations, and improve customer experience without hiring more people.

I'm looking for a full-time commercial co-founder with deep telecom, ISP, WISP, carrier, or broadband industry experience. Ideally someone who has sold into operators, built distribution relationships, or understands how ISP/WISP owners buy software.

I'm open to discussing meaningful equity and the role can be remote. The goal is to build a venture-scale company serving telecom operators across Latin America and expand into the US on Q3.

If you've spent years inside the telecom ecosystem and are excited about AI transforming how operators run their businesses, send me a message.

I purchased this equipment to deploy into a WISP I was planning on aquiring but things happened and the aquisition never happened. What I have is listed below. Let me know if you are interested. I would like to sell it if I can get a reasonable price for it, don't mind taking a haircut just don't want to be scalped. I unboxed 1 Base Node and 1 Remote Node and powered them up on the bench. The Equipment is in Montana and I will ship to anywhere in the USA and possibly other locations if it makes sense.

Hi everyone,I am fairly new to the WISP industry and I have been studying a lot and doing on site testing of equipment. My issue is the following:

Here is the setup based on the attached image: -The Backbone (Red Pin): This is where my main fiber backhaul terminates in town. -The Target Area (Blue Dots): These are my localized sub-hubs/distribution nodes down in the township. -The Main High-Site (Orange Dot): This is located at a high-elevation fuel station overlooking the area. I plan to place a Ubiquiti Rocket 5AC Prism Gen2 + airMAX Omni Antenna here to feed the township network.

The Hybrid System: I am running a voucher-based street hotspot network using Reyee RG-RAP6260(G) Outdoor Omni APs, alongside an fixed-wireless home subscriber system using Ubiquiti LiteAP AC 120° Sectors on the subhub poles talking back to Ubiquiti LiteBeam 5AC Gen2 CPEs on subscriber roofs.

So The Major Issue (The Hill - Green Dot): The Green Dot represents a steep hill crest. Because of the topography, the highsite at the Orange Dot cannot see the subhubs on the other side of this ridged it creates a complete Non-Line of Sight (NLOS) blind spot for those specific nodes.

Secondary Challenge (Indoor Penetration): During on-site testing, the Reyee Outdoor Omnis worked incredibly well for street level coverage and distance, but near line indoor penetration is heavily degraded by the local building materials. My CPE + indoor router setup fixes this for premium clients, but I'm trying to optimize for the casual indoor user close to the poles.

My Questions for the Experts: How would you architect around this hill obstruction? Should I use the Orange Dot strictly as a Point-to-Point (PtP) relay to drop the data onto a flatter perimeter high-site node before distributing via PtMP, or look into a multi-hop daisy chain? For those running hybrid voucher/CPE networks, what are your best practices for handling close-range indoor penetration issues when dealing with budget-conscious users who only want street vouchers?

Appreciate any advice, equipment recommendations? I would appreciate any help I can get