GridVisio Documentation

GridVisio is a professional coverage mapping and network planning tool built for Wireless Internet Service Providers (WISPs). It helps operators visualize their network, identify coverage gaps, manage subscribers, and collaborate with their team — all from a browser.

What GridVisio does

Who It's For

GridVisio is designed for:

• WISP operators — small to mid-size wireless internet providers managing fixed wireless infrastructure
• Network engineers — planning new tower deployments and sector coverage
• Operations managers — tracking subscriber coverage status and identifying growth areas
• Grant applicants — preparing BDC (Broadband Data Collection) and BEAD program filings
• Field technicians — looking up tower coordinates in Lambert or WGS84 format

GridVisio works for WISPs of any size and in any country. All geographic coordinate systems are supported. Regional tools (such as the Lambert coordinate converter for Belgian operators) are available alongside standard lat/lng workflows without limiting users in other regions.

Technical Overview

GridVisio is a web application accessible from any modern browser. No installation is required.

Account & Plans

Every GridVisio account starts with a 14-day free trial giving full Starter-level access with no credit card required. After the trial you choose a plan to continue.

Plan badge

Your current plan is always visible in the bottom-left corner of the sidebar as a coloured badge on your user widget: amber for Trial, gray for Free, blue for Starter, purple for Pro.

Projects

A project is the top-level container for a network deployment. Each project has its own towers, subscribers, shared maps, and team members.

Creating a project

1. 1
   Click "New Project"

   From the Projects list, click the New Project button in the top right.

2. 2
   Fill in project details

   Name (required), description, country, and region. These appear on the project dashboard.

3. 3
   Save and configure

   After saving you'll be taken to the project view where you can add towers, configure settings, and invite team members.

Project dashboard

The project view page shows live statistics for the project:

• Subscriber coverage % — percentage of served subscribers with a progress bar
• Subscriber breakdown — served / unserved / potential / unknown counts
• Infrastructure — tower and sector counts, sectors by status (active/planned/offline)
• Frequency bands — breakdown of sectors by frequency with usage bars

Project actions

From the project view header:

• Open on Map — opens the coverage map centred on this project
• New Tower — create a tower pre-assigned to this project
• New Subscriber — create a subscriber pre-assigned to this project
• Shared Maps — manage shareable read-only links
• Team — invite and manage collaborators
• Settings — configure project-specific defaults

Towers & Sectors

A tower represents a physical site where antennas are mounted. Each tower has one or more sectors, each defining a beam of coverage (direction, width, radius, frequency).

Tower fields

• Name — display name shown on the map
• Latitude / Longitude — position; click on the map picker to set
• Tower / structure height (shown in m or ft per your Distance Unit preference) — the physical structure's height (the mast, rooftop, water tower, etc. the antennas are mounted on) — not an antenna height itself. It's the reference ceiling each sector's antenna height below can't exceed, and the starting default for a new sector's antenna height.
• Notes — free-text site notes

Sector fields

• Name — e.g. "North 5GHz", "Omni"
• Azimuth (°) — direction the sector points (0=North, 90=East, 180=South, 270=West)
• Beamwidth (°) — horizontal angular width of the beam. Use 360 for omnidirectional
• Radius (shown in km or mi per your Distance Unit preference) — coverage distance. Determines the size of the coverage shape on the map. Must be greater than 0 and at most 35 km on every plan — for a genuine point-to-point backhaul link longer than that, use the LoS Link Check tool instead of a Sector. See Classification below for how a subscriber just outside this radius can still qualify as Served.
• Antenna height (m or ft, same preference) — this specific sector's antenna mounting height on the tower. Different sectors on the same physical tower are often mounted at different heights (e.g. a 5GHz sector near the top, a 900MHz sector lower down) — this field lets the LoS checker use the real height for whichever sector actually serves a given direction, instead of one flat tower-wide number. Must be greater than 0 and cannot exceed the parent tower's structure height; defaults to the tower's current height when a new sector is added, but can be lowered.
• Frequency band — selected from this project's own frequency list (configured in Project Settings, starts from a default set of 19 common bands and is fully editable). A small "?" hint next to the field explains where to add a precise value if what you need isn't in the list. See also Equipment Presets — the adjacent "Preset" selector fills this and five other RF fields in one click.
• Colour — fill colour of the coverage shape on the map
• Status — active / planned / offline. See the callout below for what this controls beyond the map legend colour.
• TX power (dBm) — this sector's radio's conducted output power. Typical WISP AP gear runs 20–27 dBm. Used only by the RF Propagation Heatmap feature, not by the LoS Link Check or Coverage Widget.
• Antenna gain (dBi) — this sector's antenna boresight gain. Typical WISP sector antennas run 16–22 dBi (up to ~41 dBi for 60 GHz mmWave gear, e.g. Ubiquiti Wave Nano). Same scope as TX power above — heatmap only.
• Downtilt (°) — mechanical or electrical antenna tilt relative to horizontal. Negative = downtilt (e.g. −5 = 5° below horizontal), 0 = horizontal boresight. Typical WISP AP values: −3° to −8°. Used only by the heatmap — the vertical pattern adjustment reduces effective gain for grid points well above or below the boresight angle. Default: 0.
• Vertical beamwidth (°) — the 3 dB (half-power) beamwidth of the antenna in the vertical plane. Check your antenna datasheet; typical values: 7° for high-gain narrow-beam sectors, 10–14° for wider beams. Together with downtilt, this determines how quickly gain rolls off away from boresight. Default: 10°. Used only by the heatmap.

Adding a tower from the map

Click + → Add Tower, then click the map. The tower form opens immediately with a pre-configured default Omni sector already shown. You can adjust the name, height, sector radius, antenna height, colour, and frequency before saving — or just click Add Tower to accept the defaults and place the tower instantly. Default sector values (radius, frequency, colour, beamwidth) are taken from Project Settings; antenna height defaults to the tower's own height.

Editing an existing tower

Click any tower marker on the map to open the edit modal directly. The modal shows all tower fields plus a collapsible sector repeater where you can add, edit, clone, and delete sectors. Click Update to save.

Each sector's Preset dropdown (next to Name, Status, and Colour) fills the six RF fields — frequency, beamwidth, TX power, antenna gain, downtilt, and vertical beamwidth — from a saved equipment preset in one click. See the screenshot below: selecting a preset copies its values as a one-time fill, not a live link, so hand-editing any of those fields afterward automatically resets the dropdown to — Custom —.

Importing towers

See the Importing Data section for CSV/XLSX import format and field mapping.

Equipment Presets

An equipment preset is a named, reusable bundle of the six RF fields a sector needs — frequency band, beamwidth, TX power, antenna gain, downtilt, and vertical beamwidth. Save the specs for a radio/antenna combination you actually run once, then fill a sector from it in one click instead of re-typing the same numbers on every tower. Presets are manufacturer-agnostic — GridVisio doesn't care whether the underlying hardware is Ubiquiti, Cambium, Mimosa, or anything else; a preset is just a set of numbers you define.

Presets are account-level, enabled per project

Presets belong to your account, not to any one project — save one and it's available everywhere you work. Whether it's actually offered when editing a sector is controlled per project, in that project's Settings → Equipment Presets tab. A new project starts with every existing preset enabled; disabling one there just stops it appearing in that project's Preset dropdown; it doesn't touch the preset itself or any sector already filled from it.

Creating a preset

Click New equipment preset. Above the fields, a row of buttons offers real vendor specs researched from datasheets — Ubiquiti, Cambium, and Mimosa sector radios — as starting points: click one to fill in the frequency, beamwidth, TX power, antenna gain, downtilt, and vertical beamwidth fields, then edit freely before saving. Copying from a suggestion is a one-time fill, not a link back to it — the saved preset is fully independent afterward. You can also skip the suggestions and enter your own values directly for hardware not on the list.

The Enable this for all projects checkbox (on by default) enables the new preset across every one of your existing projects immediately; turn it off to enable it by hand later, per project, in each project's Settings page.

Filling a sector from a preset

Wherever a sector is edited — the map's tower edit modal and the admin tower-edit form both — a Preset selector sits next to the sector's Name, Status, and Colour fields. Its options are labelled "name — frequency" so you can see at a glance which band each preset uses; an option is greyed out with an explanatory tooltip if its frequency isn't on the current project's frequency list. Selecting a preset copies its six RF values into the sector's fields as a one-time fill.

The dropdown always reflects the sector's current values, recomputed after every change — it isn't edit history. Opening a sector that already happens to match a preset's values shows that preset pre-selected; hand-editing any of the six copied fields afterward clears the selector back to — Custom —; reproducing another preset's exact values re-selects that preset automatically.

Subscribers

A subscriber is a customer or installation point. Subscribers are plotted on the map and their coverage status is automatically calculated based on whether they fall within any sector's coverage area.

Coverage status

• Served — subscriber falls within at least one active sector's coverage area (and, if RSSI verification is on, predicted signal is at or above the threshold)
• Marginal — geometrically served, but RSSI verification is on and predicted signal has fallen below the threshold while still above the hard floor. See Classification below.
• Unserved — subscriber has coordinates but is outside all coverage areas, or predicted signal has fallen below the hard floor
• Unknown — no coordinates yet, or coverage not yet calculated

"Potential" (a manually-flagged prospect, independent of coverage) still exists as a separate marker layer/filter elsewhere in the app but is not one of the four coverage-status values above.

Subscriber fields

• Name — customer name or site identifier
• Address — physical address (for reference, not geocoded automatically)
• Latitude / Longitude — position; click on the map picker to set
• Height (m or ft per your Distance Unit preference) — subscriber module (SM) / antenna mounting height above ground. Default 5 m; must be greater than 0 and at most 1000 m. Pre-fills automatically in the LoS Link Check tool when this subscriber is selected as an endpoint.
• Status — calculated automatically (served/marginal/unserved) or set manually (potential)

Predicted signal popover

Hovering a subscriber marker on the map (when RSSI verification is on for the project, and your plan includes it) shows a small popover with the predicted signal for that subscriber: predicted RSSI against the configured threshold, predicted throughput against the configured minimum (if throughput qualification is also on), and which tower/sector the prediction is measured against. For a subscriber promoted beyond its sector's configured radius, or measured against non-serving infrastructure while still Unserved, this is the only place that measured tower/sector identity is shown — the subscriber's own Tower/Sector fields only change on a real promotion.

Importing Data

GridVisio supports bulk import of towers and subscribers via CSV or XLSX files. Import is available from the Towers and Subscribers list pages.

Tower import format

Accepted columns (CSV headers, case-insensitive) — the sample file offered in the import dialog uses radius_km/height_m/antenna_height_m or radius_mi/height_ft/antenna_height_ft to match your own Distance Unit preference:

• tower_name, lat, lng — required
• radius_km (or radius_mi) — required per sector row; a file may use either column name regardless of your account's own Distance Unit setting — GridVisio converts and stores it correctly either way. Must be greater than 0 and at most 35 km (21.7 mi) — a row outside that range is skipped with a warning in the import log, stated in whichever unit that row's own column used.
• height_m (or height_ft) — optional, tower/structure height; defaults to 30 m (98.43 ft) if empty. Either column name is accepted regardless of your account's own Distance Unit setting.
• beamwidth, frequency_band, color — fall back to project defaults if empty
• antenna_height_m (or antenna_height_ft) — optional; defaults to that row's tower height if empty. Must be greater than 0 and not exceed the tower's height — a row with an out-of-range value is skipped with a warning in the import log, stated in whichever unit that row's own column used, same treatment as an invalid lat/lng.
• tx_power_dbm — optional; defaults to 24. Must be between 0 and 37 — out-of-range skips the row.
• antenna_gain_dbi — optional; defaults to 17. Must be between 0 and 50 — out-of-range skips the row.
• tilt_deg — optional; defaults to 0 (horizontal boresight). Negative = downtilt (e.g. −5). Must be between −90 and 90 — out-of-range skips the row.
• vertical_beamwidth_deg — optional; defaults to 10. Must be between 1 and 90 — out-of-range skips the row.
• Multiple sectors per tower: repeat the tower row with the same name and different sector columns

Subscriber import format

• lat, lng — required for coverage calculation
• height — optional; subscriber module mounting height in meters. Defaults to 5 m if omitted. If provided, must be greater than 0 and at most 1000 m — rows with an invalid height are skipped, same as an invalid lat/lng.
• status — optional; defaults to "unknown" if not provided

Import log

After import, a scrollable log shows the result for each row: imported, skipped (with reason), or failed. The log can be downloaded as a text file.

Coverage Map

The coverage map is the primary workspace in GridVisio. It shows all towers, coverage sectors, subscribers, temp pins, links, drive test data, and analysis overlays for the selected project.

Project selector

The project selector in the Layers & Filters panel (top-right) switches between your projects. The map reloads all data for the selected project.

Map type

Switch between Map, Satellite, Hybrid (satellite + labels), and Terrain using the map type control in the top-right of the map. Your chosen map type is remembered across sessions.

Stats bar

The bottom-left stats bar shows live counts for the currently loaded data: towers, subscribers with served/unserved breakdown, and coverage percentage. These numbers reflect the viewport filter if it is active.

Viewport filter & Refresh Map

Quicksearch

A floating search box at the top of the map (positioned to always clear the Layers & Filters panel) finds Towers, Sectors, Subscribers, Links, and Temp Pins by name or address without leaving the map.

Searching

Typing searches automatically once you've entered at least 3 characters (a short debounce after you stop typing). Press Enter to search immediately on 1 or 2 characters instead of waiting until a third.

Results are capped at 20, sorted alphabetically across all types together (a matching tower and a matching subscriber can sit next to each other — results are not grouped by type). If more than 20 items match, a line at the bottom of the list shows the total match count and prompts you to keep typing to narrow it down.

Filtering by type

Prefix the search term with a type qualifier to search only one type of item, the same "operator:value" pattern used by GitHub/Gmail search:

The qualifier must be the very first thing typed. No qualifier searches every type, as described above.

Selecting a result

Clicking a result pans and zooms the map to that item's location.

Layers & Filters

The Layers & Filters panel (toggle with the filter icon top-right) controls what is visible on the map and how data is filtered.

Layer toggles

• Towers — show/hide tower markers and labels
• Coverage — show/hide sector coverage shapes
• Heatmap — show/hide the multi-color RF propagation heatmap for towers currently in view. Disabled until at least one heatmap has been generated for the project — see RF Propagation Heatmap.
• Subscribers — show/hide subscriber markers
• Temp Pins — show/hide hypothetical tower pins and planning pins
• Drive Tests — show/hide drive test signal strength overlays
• White Areas — show/hide unserved subscriber cluster polygons
• Interference Analysis — show/hide sector overlap/interference zone indicators

Subscriber status filter

Filter subscriber markers by status: served (green), marginal (amber), unserved (red), unknown (gray). Multiple statuses can be selected simultaneously. ("Potential" is a separate manually-flagged layer, not a coverage-status filter value.)

Tower status filter

Filter towers by sector status: active, planned, offline.

Frequency filter

Show only towers that have at least one sector on a specific frequency band. Chips appear for each frequency band present in the project. Multiple frequencies can be selected.

Subscriber clustering

When a project has many subscribers, they are automatically clustered into group bubbles at lower zoom levels. The clustering threshold (below which individual markers are shown) is configurable in Project Settings.

Viewport filter

When enabled, only towers and subscribers within the current map viewport are loaded. A Refresh button appears when you pan the map — click it to reload data for the new viewport. This improves performance on large projects.

Map Tools

The bottom toolbar contains tools for adding elements and exporting the map.

Adding elements (+ menu)

• Add Tower — click the map to place a new tower at that position. A default sector is created automatically.
• Add Subscriber — click the map to place a new subscriber.
• Add Pin — place a temporary planning pin (hypothetical tower or general marker).
• LoS Link Check — enter link drawing mode to connect two points. Computes distance, bearing, terrain profile with Fresnel zone, LoS status, and free-space path loss. See LoS Link Check for details.

Export menu (▾)

• Export PNG — exports the current map view as a high-resolution PNG image
• PDF Report — generates a formatted PDF report with map image and project statistics
• XLSX Export — exports tower and subscriber data as a structured Excel spreadsheet
• Export KMZ — exports towers, coverage sectors, subscribers, the RF Propagation Heatmap, and saved LoS Checker links as a KMZ file for Google Earth or GIS tools. Towers/sectors/subscribers/heatmap respect the active viewport filter; saved links always export the full project.
• BDC Export — exports subscriber coverage data in Broadband Data Collection format
• BEAD Export — exports in BEAD program format
• Share Map — creates a shareable read-only link to the current map view

Temp Pins & Links

Temporary pins

Temp pins are planning markers that exist on the map without being permanent towers. Two types:

• Hypothetical tower — shows a coverage radius to model a planned deployment. Has azimuth, beamwidth, radius, and frequency fields. Coverage is rendered on the map in real time.
• Planning pin — a general-purpose marker for annotations, potential sites, or reference points.

Pins can be dragged to new positions on the map, or repositioned by editing the latitude/longitude fields in the pin's info panel. Coordinates are validated when you leave the field — a valid position takes effect on the map immediately (the marker moves and any coverage redraws), just like the colour and radius fields. An out-of-range value (latitude outside -90…90 or longitude outside -180…180) shows an error and is not applied; the marker stays where it was until you correct the value.

A new pin lives only in your current session until you click Save to project in its info panel, which persists it to the database (subject to the saved-pin plan limits below). Once saved, further edits — including coordinate changes — are saved automatically. Hypothetical-tower pins can be promoted to real towers from their info panel. Session pins (saved or not) are kept when you refresh the map.

Links

Links connect two points on the map for distance measurement, bearing calculation, and line-of-sight analysis. The full LoS Link Check feature — including Fresnel zone, terrain profile, and PDF export — is documented in the next section.

LoS Link Check

The LoS Link Check tool measures the line-of-sight path between two map points, renders a terrain cross-section with Fresnel zone overlay, and determines whether the link is clear or obstructed — accounting for estimated vegetation and building height on top of bare-earth elevation, not terrain alone. It is the primary tool for validating antenna placement before deployment.

How to use

1. Click LoS Link Check in the map + menu to enter link drawing mode.
2. Click point A on the map (e.g. your tower), then click point B (e.g. a subscriber location).
3. The link popover opens automatically with the full analysis.
4. Adjust frequency, antenna heights, or elevation source — the terrain profile and Fresnel verdict recompute immediately (pure geometry, no extra fetch). The predicted RSSI number is different: it deliberately does NOT recompute on every keystroke (a real propagation-model spawn, not free) — changed inputs instead dim the RSSI card and show an explicit Re-check button, so the number on screen is never silently wrong, just clearly marked stale until you click it.

Inputs

• Freq (GHz) — link frequency used to calculate Fresnel zone radius and free-space path loss. Default: 5.8 GHz.
• Ant. height A / B (shown in m or ft per your Distance Unit preference) — antenna height above ground at each endpoint, pre-filled automatically and always editable afterward:
  • Tower endpoint — GridVisio works out which of the tower's sectors actually covers the direction toward the other endpoint (same geometric test used for subscriber served/unserved status, status-agnostic — a Planned or Offline sector still counts) and pre-fills that sector's antenna height. If more than one sector overlaps that direction, the greater of the two is used by default. If no sector on the tower covers that direction at all — or the tower has none — it falls back to the tower's structure height instead. This applies the same way to a hypothetical tower (planning-only pin), which falls back to the generic 30 m (98.43 ft) default below since hypothetical towers have no per-sector antenna heights to resolve.
  • Subscriber endpoint — pre-fills that subscriber's own height field (default 5 m / 16.4 ft).
  • Arbitrary map point or temp pin — no record to read a height from, so this falls back to a generic 30 m (98.43 ft) default.
  Reopening a previously saved link restores this value exactly as you left it — see that section for why.
• Sector selector — whenever an endpoint is a tower, a small dropdown appears right under its name showing every sector on that tower that geometrically covers the direction toward the other endpoint — including two or more overlapping sectors (different frequencies/heights pointed the same way), not just the one auto-picked above. Sectors within the tower's declared radius (or extended margin, if your project has that enabled) are listed first, sectors beyond it after — still selectable, never hidden, since checking a link deliberately beyond a sector's declared range is a legitimate use of this tool. Picking a different sector applies its own antenna height and frequency and reruns the full check against it, including a fresh predicted RSSI using that sector's real transmit power and gain. Shown even when only one sector matches, as confirmation of which one GridVisio identified.
• Elevation data — choose between:
  • SRTM (Standard) — Open-Elevation API, global coverage, ~30 m resolution. Default.
  • Copernicus GLO-30 — Copernicus DEM via OpenTopoData, 30 m resolution, more accurate in mountainous terrain.
  • USGS NED 10m (US) — USGS National Elevation Dataset via OpenTopoData, ~10 m resolution, continental US only.
  This choice only affects bare-earth elevation. Where real USGS 3DEP LiDAR data exists for a point (see below), it replaces this bare elevation entirely for that point with a real measured surface height — LiDAR isn't selected here, it's used automatically whenever available regardless of which bare elevation source you pick.
• Propagation model — an ephemeral, session-only override of which model computes the predicted RSSI for this specific link (ITU-R P.1812, ITM/Longley-Rice, or FSPL+ITU-R P.526 — see Choosing a propagation model for how each is selected by default). Pre-filled with whatever the project would normally resolve for this sector's real frequency; changing it never affects any other link or the project default.

Terrain data: LiDAR, land cover & elevation

Every LoS check looks up the most precise terrain data actually available for each point along the path, in priority order, before running the Fresnel check:

1. Real measured LiDAR — a real measured surface height, not an estimate, wherever a free public LiDAR dataset covers the location: USGS 3DEP (US), Environment Agency (England), Natural Resources Wales, Scottish Remote Sensing Portal, NRCan HRDEM (Canada), IGN LiDAR HD (France), AHN (Netherlands), IGN/CNIG (Spain), or LINZ (New Zealand). See About the real-measurement LiDAR sources below.
2. Land-cover clutter estimate (used wherever LiDAR wasn't used for a point) — estimated land cover (forest, urban, scrub, etc.) with a reference height added on top of bare elevation. Coordinates inside the continental US use USGS NLCD; everywhere else (including Romania/EU) uses ESA WorldCover.
3. Bare elevation only — used when neither LiDAR nor land-cover data is available for a point.

The result panel always shows which source was actually used:

• Terrain: USGS 3DEP LiDAR (US) — real measured surface height used along this path. Outside the US, the same wording appears with the actual source that resolved it — e.g. "Environment Agency LiDAR (England, UK)", "AHN LiDAR (Netherlands)" — see below for the full list.
• Terrain: USGS NLCD (US) — NLCD land cover used along this path
• Terrain: ESA WorldCover (Global) — WorldCover land cover used along this path
• Terrain: Mixed sources — different stretches of the same path resolved to different sources (e.g. LiDAR for part of the path, land cover for the rest, right at the edge of 3DEP coverage)
• Terrain: bare elevation only — none of the above had data for this location; the check falls back to bare elevation with no height added, and this is shown explicitly rather than silently degrading

Clutter height estimates (e.g. 15 m for deciduous forest, 25 m for evergreen forest, 8 m for medium-density urban) are reference defaults, tunable by GridVisio admins, with a per-project override layer for WISPs whose region runs taller or shorter than the default — this does not require a code deploy and does not affect any other project.

About the real-measurement LiDAR sources

USGS 3DEP (the 3D Elevation Program) is the USGS's ongoing, multi-year effort to collect airborne LiDAR across the United States — laser pulses fired from a plane that measure the height of whatever they reflect off. Unlike the land-cover estimate above, which infers a typical height for a general category like "forest" or "medium-density urban," LiDAR records the actual height of the real object at that spot: a specific tree, a specific roofline. GridVisio takes the highest of these recorded points within a couple of meters of each point along the link path — the real treetop or rooftop there, not a category average. No file formats or point-cloud jargon to know — GridVisio just uses the most precise real measurement available and shows you which kind of data backed the result.

The same real-measurement precision is also available, automatically, from eight other free public government LiDAR programs outside the US: the Environment Agency (England), Natural Resources Wales, the Scottish Remote Sensing Portal, NRCan's HRDEM (Canada), IGN's LiDAR HD (France), AHN (Netherlands), IGN/CNIG (Spain), and LINZ (New Zealand). There's no setting or toggle for any of this and nothing to pick — GridVisio checks USGS 3DEP first, and only if that finds nothing for a location does it check whichever of the other eight actually covers that spot; a WISP outside the US or these other eight countries never sees any difference in behaviour, and a US-only WISP's checks are entirely unaffected by these eight sources existing at all.

This is more precise than the land-cover estimate, but coverage is not yet nationwide for any of the nine sources — each is an ongoing government acquisition project, still expanding year over year, and GridVisio only draws on the freely available public portion of each (no paid data tier, no extra cost passed on to you). Where none of the nine has coverage for a location, the check automatically falls back to the land-cover estimate, then bare elevation, exactly as described above.

Where a real LiDAR measurement exists, the entire path — the terrain profile, the Fresnel/clearance verdict, and the predicted RSSI number, not just the chart — is resolved at a genuine 2 metre grid, the native resolution LiDAR data is actually stored and cached at. Where LiDAR isn't available for any part of the path, the check instead uses a ~30 metre grid, matching the real resolution of the underlying bare-earth/land-cover data itself (SRTM, Copernicus GLO-30, and NLCD/WorldCover are all natively 10–30 m; USGS NED is 10 m) — going any finer there wouldn't add real information, since the source data itself isn't that precise. Point count therefore always scales with the link's actual length and whether LiDAR covers it, never a fixed sample count, so a narrow obstruction like a single tree or roofline can't slip through between two checked points at either resolution. There is one limit on the LiDAR lookup specifically: links longer than 20 km skip the USGS 3DEP lookup entirely (an unusually long distance for the fixed-wireless links GridVisio is built for) and use the land-cover estimate instead. The eight other regional sources have their own length limit instead, based on your plan: 5 km on Free, 10 km on Starter and Trial, 20 km on Pro — long enough for real long-haul WISP backhaul links on Pro. The map's LoS Link Check tool shows an on-chart note whenever LiDAR isn't contributing to a result, explaining whether it's because the link is over the length limit or because no real measurement was found for that specific path. Separately, the LoS Link Check tool itself has an overall maximum link length of 35 km (matching the maximum coverage sector radius elsewhere in GridVisio) — well beyond any realistic single fixed-wireless hop, and rejected with a clear message rather than attempted.

For a regional link past about 6 km, GridVisio automatically splits the real-data fetch into several pieces requested at once, to keep response times reasonable rather than making you wait on one very large request. This is why a longer regional link can show somewhat less continuous LiDAR coverage along its length than a short link does — every point that is LiDAR is still a real measurement, never an estimate; a long link just has more real gaps between measured points than a short one, the same way a wider search area naturally samples less densely than a narrow one. Nothing to configure here — it happens automatically based on the link's own length.

The terrain source used is also recorded per-tower on any lead the Coverage Widget captures (alongside the existing classification and clearance fields), so the same attribution shown here is visible later in the Lead Inbox and the lead notification email — useful for judging how precise a particular lead's coverage assessment actually was.

Terrain profile & Fresnel zone

• Blue line — bare-earth elevation profile
• Green line — clutter-raised profile (bare elevation + estimated vegetation/building height), layered on top of the blue line, on segments where land-cover data was used
• Orange line — LiDAR-raised profile (real measured surface height from whichever of the seven sources covers this location — see above), layered on top of the blue line, on segments where real LiDAR coverage was used — drawn thicker than the green line since it's the more precise of the two where both could apply
• Dashed line — straight line-of-sight from antenna A to antenna B at their effective ASL heights
• Shaded zone (green = clear, amber = tight) — first Fresnel zone boundary, checked against the most precise profile available at each point (LiDAR, then land cover, then bare elevation), not bare elevation alone. For reliable links, 60% of the first Fresnel zone must be clear at every point along the path.
• Red terrain fill — segments of that profile that penetrate the 60% Fresnel zone clearance
• Red dot — worst obstruction point along the path
• Blue dot (A) / Red dot (B) — antenna positions at effective above-sea-level height

The shaded-zone colour and red fill above show exactly where along the path clearance drops below the 60% line — a per-point view. The overall Clear / Borderline / Obstructed badge below summarises that into one verdict for the whole link, using the worst point on the path.

Click the chart to open a larger, zoomable view — useful for inspecting a specific stretch in detail, especially where LiDAR resolved many more points than the small inline chart can show individually. Scroll/pinch to zoom (toward wherever your cursor/fingers are), drag to pan, or use the on-screen −/+/Fit controls; zooming out floors at the original fit-to-screen view, so there's never empty space around the chart. This is a viewing aid only — Export PDF/PNG always captures the full, un-zoomed chart regardless of what you're currently zoomed into when you export.

Clearance tiers

The Fresnel check computes a continuous clearance value at every point along the path — what fraction of the first Fresnel zone radius is actually clear, expressed as a percentage. The 60% line described above is the pass/fail threshold for that percentage at the single worst point on the path. Rather than collapse that number straight to a binary Clear/Obstructed verdict, the result panel shows one of three tiers:

• Clear (clearance ≥75%) — comfortably above the 60% pass line. A confident clear call.
• ~ Borderline (clearance 40–75%) — close enough to the 60% line that it could go either way depending on real-world conditions and equipment. Treated as inconclusive, not a pass or fail.
• Obstructed (clearance <40%) — well below the line. A confident obstruction call.

The clearance percentage is always shown next to the badge (e.g. "Borderline — 52% Fresnel clearance"), and is saved alongside the existing classification fields on any lead the Coverage Widget captures, so the same tier and percentage are visible later in the Lead Inbox and lead notification email.

Near a path's endpoints the underlying percentage is a ratio against a Fresnel radius that shrinks toward zero, which can swing to extreme, uninformative values (e.g. "-2000%"). Below −100% GridVisio shows "Severely obstructed" instead of the raw number — a display-only clamp; the stored clearance percentage itself is unaffected.

Free-space path loss (FSPL), shown alongside the badge, is the theoretical signal loss over distance assuming a completely unobstructed path — it does not measure or relate to obstruction severity, which is why it's labelled "baseline, no obstruction" rather than placed next to the clearance percentage as if the two were related.

NLoS reflection path check

On a Borderline or Obstructed result, a Check NLOS path toggle appears next to the Propagation model selector, and the terrain panel below gains a second tab (labelled with the toggle's own name) alongside Terrain Profile. Switching tabs is purely a view change — it never fetches anything; only the toggle itself does that, and turning it on jumps you straight to its tab so the search is never running invisibly in the background. It searches for one possible reflected signal path — off a nearby flat surface such as a rooftop, water, or open ground — in addition to the direct line already shown above, using the exact same terrain and real-LiDAR precision as the main check (including LiDAR from all seven regional sources, not just the US). It's on-demand only: a real extra terrain fetch runs only when you switch it on, never automatically.

• Additional path found — shows the reflection's lateral offset from the direct line (in metres), the extra path loss it contributes (in dB), and a combined estimate in dBm that accounts for both the direct and reflected paths together, alongside what the direct path alone would predict.
• Reflection path profile — a small terrain chart for the reflected path specifically (tx → reflection point → rx), with its own distance and elevation axes, and the same real-LiDAR-percentage note used on the main terrain profile below.
• No viable additional path found — the search tried several candidate reflection points and none had a genuinely clear path on both legs. This is a real, common result, not an error.

Like the predicted RSSI figure, changing frequency, antenna height, or the "Ignore clutter" toggle marks a previously-found reflection result stale (a one-click Re-check banner appears) rather than silently keeping an outdated number on screen — the same banner covers RSSI staleness too, since both go stale from the same input changes.

Local clutter margin (ITU-R P.2108)

Directly below the reflection result, the same tab reports a second, independent number: an additional signal-loss margin from ITU-R P.2108's statistical clutter-loss model, for whichever end of the link (transmitter, receiver, or both) sits below the representative height of its surrounding land cover. This targets a different problem than the single-reflection search above — dense suburban and urban environments rarely fail from one identifiable missing reflector; they fail from many small, unresolvable scatterers (house facades, fences, tree canopy) around a terminal that's embedded in clutter rather than clearing it. No land-cover category or extra terrain fetch is needed — the model's only inputs are frequency, total link distance, and which end(s) qualify, evaluated against the clutter height GridVisio already resolves for that end.

• Neither end embedded — "no additional margin applies." Both antennas already sit above their local clutter height, so this model has nothing to add.
• One or both ends embedded — reports a typical additional loss (dB) and a separate worst-case combined RSSI, using the 90th-percentile figure from the same model. This is a statistical envelope around the whole link, not another arriving signal path — it's never summed into the reflection check's combined RSSI above.

Fade margin (ITU-R P.530)

On a Clear result, the second tab is labelled Fade Margin instead — a different question again: given this direct path is already geometrically clear, how much signal margin (dB) does it need in reserve to keep working through ordinary weather and atmospheric multipath fading, for a given target availability (e.g. 99.9%, 99.99%)? This uses ITU-R P.530's real geoclimatic prediction method (via the same terrain/frequency/distance already known for the link), not another reflection search. There's no separate toggle — since it needs no new terrain fetch, it computes automatically the first time you open the tab.

Saving a link

Save Link persists a link's endpoints and styling (colour, line style, width, label) to the project, subject to the link limits noted under Temp Pins & Links above. It also persists every field on the analysis panel — frequency, both antenna heights, elevation source, CPE model, propagation model override, and whether the NLoS reflection toggle was on — so reopening the link later picks up exactly where you left off, without re-entering anything.

Export

• Export PNG — downloads the terrain + Fresnel profile as a PNG image
• Export PDF — single-page PDF with link name, endpoint coordinates, antenna heights, bearing, frequency, terrain profile, LoS status, and FSPL. Available on all plans. If the NLoS reflection check was run for this link, its result (offset, reflected loss, combined RSSI, and profile chart) is included too, along with the local clutter margin figure — omitted entirely if the toggle was never switched on, never shown as "not checked."

3D Corridor Check

The 3D Corridor Check renders an actual three-dimensional view of a link's real LiDAR terrain, surrounding buildings, and Fresnel zone — a visual companion to the numbers on the LoS Link Check panel, for the cases where seeing the actual obstruction is clearer than reading a clearance percentage. It fetches the same class of real LiDAR data described above, at a fine grid resolution, and renders it as an explorable 3D scene you can orbit, pan, and walk through.

How to use

1. Open a LoS Link Check for the link you want to see in 3D.
2. Click Check 3D. A progress bar shows the real LiDAR corridor fetch — this is a separate fetch from the 2D check above, at a finer grid resolution and covering the full width of the corridor, not just the path itself, so it takes longer than the 2D chart appearing.
3. Once complete, the 3D scene loads: real terrain height along the whole corridor width, nearby buildings, and the Fresnel zone rings running between the two antennas.
4. Switching back to the 2D terrain chart and returning to 3D for the same link is instant — it reuses what was already fetched rather than fetching again. Changing antenna height or frequency in the 2D panel and coming back updates the 3D scene to match, without a fresh fetch either.

What you'll see

• LiDAR terrain columns — the real measured surface, extruded to height and coloured on a relative scale (greener = lower, orange = higher, relative to the rest of the current scene, not an absolute colour key) — the same real measurement described in About the real-measurement LiDAR sources above, just shown as terrain instead of a 2D chart. A column outlined in red marks a cell that intrudes into the first Fresnel zone.
• Buildings — nearby building footprints (from OpenStreetMap) extruded to their real height, drawn semi-transparent so the LiDAR detail underneath remains visible rather than being hidden behind a solid grey box. Where a building is mapped with individually-tiered sections (OSM's building:part data — common for setback/stepped towers), each tier is drawn at its own real height and starting elevation instead of one flat box for the whole structure.
• Fresnel zone rings — a series of rings along the path showing the first Fresnel zone's true radius at each point, exactly matching the geometry the 2D clearance check itself uses.
• Clearance badge — the same Clear / Obstructed verdict and clearance percentage as the 2D panel's badge, computed from the same real terrain now visible around it.

Navigating the scene

• Orbit / pan / zoom — drag to orbit, scroll to zoom, right-click-drag (or two-finger drag) to pan, the same controls as the main map.
• A-end / B-end — jump the camera straight to either antenna.
• A→B / B→A — animates the camera flying along the link from one end to the other, following the real terrain height.
• Click anywhere in the 3D scene — on either the LiDAR terrain or a building — pans the 2D map underneath to that exact real-world ground point. This uses a real depth-buffer read, not a naive click-ray projection, so it stays precise even when you're viewing a surface from an angle rather than straight down (clicking the visible side of a tall column or building still resolves to its true position, not wherever the click ray happens to continue to). Useful for identifying what a specific feature in the 3D view actually is on the map — a street, a specific building — without leaving the 3D check.
• Fullscreen — expands the 3D view to fill the available space.
• Back to 2D — returns to the LoS Link Check panel without losing the 3D scene; reopening Check 3D for the same link picks up instantly (see above).

On the 2D map, at the same time

Opening Check 3D doesn't only draw the 3D scene — it also overlays two things directly on the real satellite map, so the corridor's shape and any obstruction are visible even while you're not looking at the 3D view:

• The true Fresnel zone shape — a blue tapering outline (narrow at each antenna, widest at the path's midpoint — the real first Fresnel zone shape, not a plain rectangle) appears on the map the instant you click Check 3D, from pure geometry, before any LiDAR data has even loaded. It's redrawn slightly once the real fetch completes, using the corridor's actual (occasionally capped) width.
• Obstruction markers — once clearance is computed, red "✕" markers appear on the map at the worst obstruction point along each of 20 equal segments of the path (the single worst point per segment, not every intruding cell, to keep the map readable) — the same intrusions drawn as solid red columns in the 3D scene.

Drive Tests

Drive test data shows signal strength measurements collected while driving through a coverage area. It is overlaid on the map as coloured dots or a heatmap.

Import format

Drive test files are imported as CSV with columns:

Signal strength is displayed on a colour scale from red (weak, e.g. −90 dBm) to green (strong, e.g. −60 dBm).

Coordinate Converter

The coordinate converter is a map tool for converting between WGS84 decimal coordinates (latitude/longitude) and Belgian Lambert projected coordinates (X/Y easting/northing) — and, since it's the fastest way to get a specific location onto the map, for looking up an address directly. Available to all plans.

How to use

1. 1
   Open the converter

   Click the target icon () in the bottom toolbar. The converter popover opens.

2. 2
   Search an address (optional)

   Type an address into the Address field at the top and click Go — the map jumps straight to it and every coordinate field below fills in automatically. This is the fastest way to get a specific address onto the map without knowing its coordinates up front.

3. 3
   Or activate click mode

   Click the button again to activate crosshair mode (button turns purple). Click anywhere on the map to populate the coordinates automatically.

4. 4
   Enter or edit coordinates

   Type in any field — lat/lng or Lambert X/Y. All other fields update automatically. The DMS (degrees, minutes, seconds) display updates in real time below the lat/lng fields.

5. 5
   Choose Lambert system

   Select Lambert 72 (EPSG:31370), Lambert 2008 (EPSG:3812), or Lambert 2005 (EPSG:3447) from the dropdown. Your choice is remembered for the session.

6. 6
   Copy or navigate

   Click Copy next to WGS84 to copy "lat, lng" to clipboard. Click Copy next to Lambert to copy "X, Y". Click Go here to pan the map to the coordinates. Click Add pin to create a temp pin at that location — useful as a target for POP Scan when you want to check line of sight to an address rather than a spot you clicked by eye.

Supported systems

• Lambert 72 (EPSG:31370) — legacy Belgian standard, widely used in existing infrastructure documentation, Ericsson/Nokia site databases, and topographic maps
• Lambert 2008 (EPSG:3812) — modern replacement for Lambert 72, used in new Belgian government datasets
• Lambert 2005 (EPSG:3447) — intermediate system, superseded by Lambert 2008

White Area Detection

White area detection identifies geographic clusters of unserved or unknown subscribers — areas where coverage is absent despite apparent demand. Results are shown as shaded polygons on the map.

Configuration (Project Settings)

• Cluster radius (ε) — maximum distance between two subscribers to be considered neighbours. Default: 2.0 km
• Minimum subscribers — minimum cluster size to form a white area. Default: 3
• Hull buffer — outward padding on polygon edges. Default: 0.3 km

These parameters can be tuned in Project Settings → White Area Detection.

Viewport filtering

White area detection respects the viewport filter. When the filter is active, only subscribers within the current map bounds are analysed.

Interference Analysis

Identifies sectors from different towers whose coverage areas could realistically interfere with each other, and — on Pro plans and trials — computes a real, terrain-and-propagation-backed carrier-to-interference number for the worst point in each zone, not just a geometric "these shapes intersect" flag.

How a zone is found

For every pair of sectors on different towers, the system first checks whether they could realistically interfere at all:

• Co-channel — the two sectors' configured frequencies are identical. Always checked, regardless of whether either sector has a linked equipment preset.
• Adjacent-channel — different frequencies whose channels spectrally overlap, given known channel bandwidth (from a linked equipment preset) on at least one side. Where only one side's bandwidth is known, the system still proves overlap using that side's known channel span reaching the other sector's exact frequency — a provable lower bound, never a guess. Where neither side's bandwidth is known, the pair is not checked (no assumed bandwidth is ever substituted — a real project mixes equipment from many vendors, and guessing one bandwidth for unmodeled gear would misrepresent it as confidently as the modeled sectors).

Pairs are excluded entirely if both sectors are on the same tower — co-located/"co-site" interference is a real, different phenomenon (near-field antenna-to-antenna coupling, not the terrain-based path loss this feature otherwise models) and isn't covered by this analysis.

Sector status: both active and planned sectors are checked — this analysis exists to catch a conflict before it goes live, not just after, so a not-yet-built sector's configured frequency/power is treated as real as an active one's. Offline sectors are excluded (typically decommissioned or dead gear, not "coming soon"). Any zone involving a non-active sector shows that sector's status everywhere it's named — the zone list, the summary popover, and the grid-cell contributor breakdown — so a planned-sector conflict is never mistaken for a live one.

Qualifying, geometrically-overlapping pairs are clustered into zones — a zone can involve more than 2 sectors where several pairwise overlaps connect, and the map list is sorted worst-estimated-severity first so the areas most worth checking on a dense network surface at the top. Clicking a zone (in the list or on the map) zooms and centers the map so the zone's real overlap area fills roughly the middle half of the screen — needed because a real overlap area can be a small sliver that's invisible at whatever zoom you were already at, especially on a dense multi-sector project.

Severity thresholds

Each grid point is classified clean / degraded / severe by its computed C/(I+N) in dB, using whichever threshold is more specific:

• Equipment-derived — where the carrier sector's linked equipment preset publishes a per-modulation required SNR (e.g. Cambium's 450 platform), "clean" is the requirement for its highest modulation tier (enough margin for full-rate operation) and "severe" is the requirement for its lowest tier (below this, not even the most robust modulation is usable).
• Fallback — where no such equipment data exists, ≥18dB is treated as clean and <12dB as severe, sourced from published cellular/point-to-multipoint carrier-to-interference planning literature (not CloudRF's commonly-cited J/S tiers, which are tuned for a jamming-assessment context rather than ordinary link-budget planning and would misrepresent what's actually acceptable for a WISP link).

RF Propagation Heatmap

The heatmap predicts signal strength across the area around a sector — not just along one line like LoS Link Check, but as a continuous grid. It answers "roughly how strong is the signal here" for every point within a sector's radius, not just "is this one specific spot in line of sight."

Pro's generation radius: up to ~22 km, area-based rather than one flat number

A sector's real generation cost tracks its query area — radius combined with beamwidth, capped against a real, measured safe-area ceiling — not radius alone: a narrow, focused sector covers far less real ground than a wide or omnidirectional one at the same radius, so it can safely reach much further out. Pro's own ceiling reflects that directly: the narrower a sector's beamwidth, the further its heatmap can reach, up to ~22 km at the narrowest.

Some real examples of beamwidth/radius combinations at that safe-area ceiling:

A sector configured with a radius beyond its own beamwidth's ceiling still generates — coverage is computed out to that ceiling, not rejected outright; the remainder of the configured radius simply isn't included in that generation.

This area-based ceiling currently applies to towers within the continental US. Towers in Canada or any of the other seven supported LiDAR regions (England, Wales, Scotland, France, Netherlands, Spain, New Zealand) keep a flat 15 km ceiling for now, regardless of beamwidth — that number hasn't yet been measured against each region's own real data the way the US figures above have.

What it actually computes

Each generated heatmap is one computed grid of predicted signal strength (dBm), using this project's configured propagation model(s) to predict path loss to every point in the grid. It uses the same real terrain elevation and land-cover (vegetation/building height) data as LoS Link Check, plus each sector's transmit power and antenna gain, to convert that path loss into an absolute signal strength.

Grid resolution adapts to each sector automatically — a small or narrow (directional) sector gets a finer grid than a large, wide-coverage one, so detail isn't wasted where it isn't needed and isn't sacrificed where it is. This happens without any setting to configure; every generated heatmap picks the finest resolution that's safe for that specific sector.

Choosing a propagation model

GridVisio supports three propagation models, each with a different valid frequency range — no single model covers every WISP frequency band, so relying on one alone left real gaps (an 11 GHz backhaul sector or a 60 GHz mmWave link would previously fail to compute at all).

Every project defaults to all three, in that order (P.1812 first for accuracy on the common case, automatically extending into ITM's and then FSPL+P.526's wider domains as needed) — configurable in Project Settings → RF Heatmap → Model Selection, where you can disable a model entirely or reorder the preference. A single sector can also pin one specific model of its own (in the sector's edit form, next to Colour) — if that model can't cover the sector's own frequency, resolution automatically falls back to the project's order instead of failing. Reordering so a wider-domain model sits before a narrower one it fully covers makes the narrower one unreachable — Project Settings flags this with a non-blocking warning if it happens.

Every computed result — heatmap, LoS Link Check, subscriber classification, BEAD export — records which model actually ran, shown as a small badge/tag next to the number.

Antenna tilt (mechanical or electrical downtilt) is not modelled — every point within a sector's azimuth/beamwidth wedge is treated as receiving that sector's full antenna gain, regardless of elevation angle. This is a deliberate scope decision for now, not an oversight.

Generating a heatmap

A heatmap can be generated for a single sector, a whole tower (all its sectors), or an entire project (all towers). Generation runs in the background — it does not block the page, and you don't need to keep it open while it runs.

• Single sector / whole tower — click a tower marker to open its detail popover (not the edit modal), then use the Generate Heatmap button on a sector card, or Heatmap in the popover's footer for all of that tower's sectors.
• Entire project — the + button next to the Heatmap row in the map's Layers panel, or the Generate Heatmap button on the project view page.

Every trigger opens a confirmation explaining what's about to happen and roughly how long it can take before actually starting — nothing is generated without that explicit confirmation.

Checking status

Each request appears as one row showing its scope (sector / tower / project), status (Queued / Running / Done / Failed / Done with errors), and timestamps. A tower or project-wide request fans out into one underlying computation per sector — shown as a compact per-sector status list ( / / ) on that same row, so a request covering several sectors can finish with some done and others failed without losing the ones that succeeded.

Two display modes, one underlying grid

Both modes render from the exact same computed grid for a given sector — generating a heatmap is never done twice for the same data, only the threshold/colours applied at display time differ, configurable in Project Settings. The internal map's Heatmap layer also has its own live opacity slider (Layers panel, next to the layer toggle) — session-only, adjusts instantly with no re-fetch, and never touches Project Settings; it just starts from that project's saved percentage the first time a heatmap loads each session. The Coverage layer (sector wedge/circle shapes) has the same style of slider right below it, for the same reason — it just has no Project Settings value behind it, so it always starts at a fixed 25%.

Link budget

Every propagation model above only predicts path loss from geometry and terrain — converting that into an absolute signal strength (dBm) needs a simple link-budget calculation on top, identical regardless of which model computed the loss: signal = TX power + antenna gain − cable loss − path loss + CPE gain. TX power and antenna gain are real, sector-specific hardware values (see Sector fields); cable loss and CPE gain are project-wide assumptions about a typical subscriber radio, configurable in Project Settings, since there's no real subscriber to read a value from for a hypothetical grid cell.

Rooftop Scan

Rooftop Scan answers a different question than a single LoS Link Check: not "is this one exact spot clear," but "where on this specific building would a dish actually get the best signal." Click a rooftop on the map and it automatically detects the building's footprint, scans a ring of realistic mounting points around its edge against your chosen tower, and surfaces the best one it found — instead of you guessing a spot and checking it by hand.

How it works

1. Open the map's + menu and choose Rooftop Scan, then click a building on the map.
2. GridVisio looks up that building's real footprint from OpenStreetMap first; if OSM has no traced outline there, it falls back to detecting the roof directly from LiDAR surface data. Either way, you see the detected outline over the satellite basemap and can confirm or adjust it before scanning.
3. Pick the tower/sector to test against, then run the scan. Every sector — on any tower — that geometrically reaches the rooftop is listed as its own candidate, including two or more overlapping sectors on the same tower (e.g. different frequencies pointed the same direction), not collapsed down to one option per tower.
4. The scan runs in the background — you don't need to keep the panel open while it works — and returns a ring of candidate points around the roof's edge, each with its own predicted signal strength and Fresnel clearance, plus a highlighted Best point: the candidate with the strongest realistic signal.

From a scan result

Clicking any candidate point (including the Best point) opens the same result popover the map's other LoS tools use — predicted signal strength, Fresnel clearance status, and surface elevation source. A LoS Check button on that popover opens the full interactive LoS Link Check panel pre-filled with that exact point, if you want to explore antenna heights, frequency, or CPE equipment beyond what the scan itself assumed.

POP Scan

POP Scan answers a different question than a single LoS Link Check: not "is this one specific tower clear to this point," but "which of my POPs — Points of Presence, i.e. towers — can actually reach this point, and which one is best?" Click any point on the map — an address, a subscriber, an existing tower, or just a spot — and GridVisio finds every tower/sector whose coverage geometrically reaches it, checks line of sight to each one, and ranks them by predicted signal strength, instead of you drawing and comparing links to each candidate tower one at a time.

How it works

1. Open the map's + menu and choose POP Scan, then click a point on the map — a plain spot, an existing tower, a subscriber, or a pin (including a pin dropped from the Coordinate Converter's address lookup).
2. Confirm the point, then click Find towers. GridVisio lists every tower/sector whose coverage geometrically reaches that point — including two or more overlapping sectors on the same tower, listed adjacent to each other, exactly like Rooftop Scan's own candidate list.
3. Click Run checks. Each candidate is checked individually — the identical Fresnel/RSSI computation a manually-drawn LoS Link Check line would run — and results stream into the list as each one finishes, so you see progress rather than waiting on the whole batch.
4. Results are sorted by predicted signal strength, best first, regardless of which tower each one is on — the fastest way to see which POP actually gives the strongest link to that point.

From a result

Each result row shows the Fresnel clearance tier, predicted signal strength (and throughput, where a CPE model resolves), distance, frequency, and terrain data source. An Open in LoS Checker button on every row reopens the full interactive LoS Link Check panel for that exact tower/sector pair — including, for a tower with more than one candidate sector, the specific one that row actually checked, not just whichever one the tower would auto-select on its own.

Subscriber Statistics

Subscriber statistics are visible in multiple places:

• Map stats bar (bottom-left) — live counts for the currently loaded data
• Project view dashboard — served/unserved/potential/unknown with coverage percentage
• Subscriber list — filterable by status, searchable by name and address

Team Management

Projects can be shared with other GridVisio users as collaborators. Each collaborator has a role that determines their level of access.

Roles

• Owner — full access, can invite and remove team members, can delete the project
• Editor — can add/edit/delete towers, subscribers, pins, and links. Can configure project settings
• Viewer — read-only access to the project and map. Cannot make any changes

Inviting a collaborator

1. 1
   Go to Team page

   From the project view, click the Team button in the header.

2. 2
   Enter email and role

   Type the invitee's email address and select their role (Editor or Viewer).

3. 3
   Send invitation

   The invitee receives an email with an accept link. Until they accept, their status shows as "Pending".

Shared Maps

Shared maps are read-only, publicly accessible links to a project's map view. No GridVisio account is required to view a shared map.

Creating a shared link

• Label — optional name for the link (e.g. "For client review")
• Expiry — never, 7 days, 30 days, or 90 days
• Content — choose what to show: towers, coverage, subscribers, heatmap
• Viewport — when sharing from the map, optionally lock the shared view to the current viewport bounds

The Heatmap option shows the single-color "covered / not covered" view of any already-generated RF Propagation Heatmap data for the project — not the internal multi-color signal-strength bands, which stay map-only. It defaults off (unlike the other three, which default on), since a project can easily have no generated heatmap yet when a link is created. When sharing directly from the map, this mirrors whatever the map's own Heatmap layer toggle is currently set to, the same way the other three options already do.

Managing links

From the Shared Maps page you can activate/deactivate links (without deleting them), see access counts and last viewed date, and delete links permanently.

Export Options

GridVisio supports multiple export formats for different use cases.

BDC & BEAD Export

GridVisio supports export in the formats required for US government broadband funding programs.

BDC (Broadband Data Collection)

The FCC's Broadband Data Collection program requires ISPs to submit coverage data in a specific format. GridVisio's BDC export generates a file conforming to the BDC specification, including coverage polygons and technology codes derived from your sector frequency bands.

BEAD (Broadband Equity, Access, and Deployment)

The BEAD program requires ISPs to identify unserved and underserved locations for federal grant applications. Clicking BEAD Export opens a modal where you fill in applicant and project details, then start the export — terrain/signal verification for every location in scope runs automatically as part of it, no separate step required.

What the export produces

The BEAD export downloads as a ZIP archive containing four files:

BEAD export modal

The modal has two sections: applicant information and project details. All fields are saved automatically in your browser (localStorage) so they are pre-filled the next time you open the modal — even for a different project. Applicant-level fields (name, EIN, address, contact, email, phone, state) are shared across all projects; project-specific fields (project description, target area, tech type, etc.) are saved per project.

Automatic verification (queued export)

Building a BEAD export runs in the background rather than blocking your browser on one long request. After you click Download BEAD Bundle:

1. A small progress banner ("Building BEAD export…") appears at the top of the map. You can keep working — it polls for status every few seconds.
2. The export first ensures every subscriber in the export area has a real, stored signal measurement (predicted RSSI, LoS/Fresnel verdict, and — if a CPE model resolves — predicted throughput). A subscriber that was already measured (from a prior recalculation, or a prior export) is not re-measured — only ones genuinely missing a measurement are computed, which is why a repeat export on the same project is typically much faster than the first one. Once at least one location needs measuring, the banner also shows a running count ("N of M subscribers measured").
3. This is the exact same 50-sample, LiDAR-aware engine used everywhere else in GridVisio (the map's own RSSI verification, the RF Heatmap) — not a separate, faster, less-precise bulk check. Every active sector that geometrically reaches the location is tested (same multi-candidate matching described under Classification), and the best-performing one is used, so the export's serving tower/sector can legitimately differ from the one shown elsewhere if the project's classification settings were changed since the last recalculation. This measurement pass always runs regardless of whether the project has RSSI/throughput verification turned on at all — it can only fill in a number, never change a subscriber's served/unserved status. There is no manual "Verify with LoS" step or subscriber cap to configure; every location in the export's scope gets a result.
4. Once every location is measured, the PDF/CSV/GeoJSON are built directly from those stored values and the ZIP downloads automatically.

Export Area: Full Project vs. Polygon

Clicking BEAD Grant Package opens a small Export Area panel before the main modal, letting you choose what the export covers:

• Full Project (default) — every subscriber location in the project is included; the PDF's tower table shows up to 15 rows.
• Polygon — click points on the map to draw a custom area, then click Finish to close the shape. Only subscriber locations inside the drawn polygon are included in the CSV, the unserved-cluster detection (and its GeoJSON), and the PDF's tower table (capped at 10 rows). A live location count updates once the shape is closed. Drag any vertex to reshape it afterward, or use Draw new / Remove to start over or clear it.

The drawn polygon is resolved on the server against your project's full data every time it's used — it does not depend on what the map happens to have loaded or rendered at the time, and it's remembered per project (saved in your browser) so it's still there the next time you open the panel. Click Next step to continue to the applicant/project details modal, or Edit from inside that modal to come back and change the area. In both scope modes, an overflow note in the PDF lists how many additional towers exist and includes project-wide network totals.

PDF structure

• Section 1 — Current Network Summary — five coloured stat cards (active towers, sectors, average radius, max radius, frequency bands) on a single row, followed by the BEAD eligibility table, an FCC downlink classification table (Pro/Trial plans with throughput data — see above), a tower table, and an unserved location cluster table
• Section 2 — Applicant Information — organisation name, EIN, address, state, primary contact
• Section 3 — Project Description — free-text description with newlines preserved
• Section 4 — BEAD Readiness Checklist — checklist of required documents referencing the companion CSV and GeoJSON files
• Section 5 — Additional Resources

Coverage Widget

The Coverage Widget embeds a compact interactive checker on your website. Visitors enter their address or drop a pin on the map, and the widget tells them whether they're in your service area — no GridVisio account required. With lead capture enabled it also collects visitor contact details and runs a full line-of-sight analysis, sending you a notification with the result.

Widget modes

Each widget has one of three modes, set in the widget settings:

Visitor flow — Coverage only

1. Enter an address or drop the pin on the map.
2. Click Check — the server runs the same line-of-sight analysis described below (see What the LoS analysis covers) and returns a result.
3. Result: Covered (with serving tower), ~ Marginal, or Not covered. No contact details are collected in this mode, so nothing is ever saved as a lead.

Visitor flow — Coverage → Lead

1. Enter address / drop pin → Click Check. Result shows instantly.
2. If covered (or unserved capture is enabled): the location picker collapses and the contact form appears below the result.
3. Visitor fills in name / email / phone → Click Send. Full LoS analysis runs server-side.
4. Fields become read-only, a thank-you message appears, and a ← New inquiry button resets the widget for the next visitor.

Visitor flow — Lead form first

1. Contact form is shown immediately — name / email / phone → Click Next →.
2. Location picker appears (address, map, GPS). Visitor picks location → Click Check.
3. Full LoS analysis runs. Coverage result + thank-you shown. ← New inquiry resets to the contact form.

Widget settings

• Mode — Coverage only / Coverage → Lead / Lead form first
• Enable LiDAR — applies to every mode; pulls real LiDAR measurements into the LoS analysis for higher precision, at the cost of a slower response. Off by default — see Enable LiDAR above.
• Allowed Domains — comma-separated list of domains allowed to embed the widget's iframe. Required for the embedded widget to complete real checks — leave it blank and the iframe still loads, but anonymous visitors' checks are rejected until a domain is set. See Public API for exactly what this does and doesn't protect against.
• API Secret — Bearer credential for calling the Coverage Check API directly from your own server, bypassing the iframe. Generate/regenerate it next to the webhook secret. See Public API for the exact header format.
• Form fields — choose which fields (name, email, phone) to show and which are required
• Towers to test — up to 3 (Starter / trial) or 6 (Pro) towers used for the LoS analysis on lead submission
• Capture when unserved — in Coverage → Lead mode, also show the form when the visitor is outside coverage
• Brand colour — hex colour applied to the Check / Send buttons and focus rings
• Thank-you message — custom message shown after a successful lead submission
• Redirect URL — instead of a thank-you message, redirect the visitor to a page on your site
• Notification email — address that receives the lead notification email
• Webhook URL + secret — optional POST to your CRM or automation tool, signed with HMAC-SHA256

Embedding the widget

1. Open the project → click Coverage Widget in the header.
2. Click Enable Coverage Widget and configure the mode and settings.
3. Set Allowed Domains to the domain(s) you'll embed on — required, see below.
4. Copy the generated <iframe> snippet and paste it into your website HTML.

The embed code uses height="330", which fits all three widget modes and their post-submission states. Do not reduce this value.

Managing leads

Captured leads appear under Leads in the sidebar. Each lead shows the visitor's contact details, the address they checked, the coverage result, and a per-tower LoS breakdown. You can:

• Update the lead status (New → Contacted → Qualified → Converted / Lost)
• Add internal notes
• Filter by date, classification, or tower
• Export all leads to CSV in bulk

An unread badge on the Leads sidebar entry shows how many new leads haven't been opened yet.

Token management

• Regenerate token — issues a new embed URL and invalidates the old one. Update your website after regenerating.
• Regenerate API secret — invalidates the current one immediately; update it in any server-side integration calling the Coverage Check API directly. Doesn't affect the embedded iframe at all, which doesn't use this secret.
• Disable widget — deactivates immediately; visitors see a "temporarily unavailable" message.

Public API

Everything the embedded widget's own JavaScript does, you can also do yourself: call the same endpoint directly from your own server or front end instead of embedding the iframe. This page documents the first endpoint made available this way — the Coverage Widget's check call. More endpoints will be added here over time as GridVisio exposes further functionality for direct integration.

Coverage Check

POST/api/widget/{token}/check

Same domain as your widget's embed URL (shown on the Coverage Widget settings page) — for example:

Request body

Response body

Each tower_results entry

• tower_id, tower_name, distance_km
• in_sector (bool) — whether an active sector was found covering the visitor's direction from this tower.
• excluded + exclusion_reason — present instead of the fields below when in_sector is false (see A nearby tower can still be excluded above).
• served (bool), tier ("clear" / "borderline" / "obstructed"), clearance_pct (Fresnel-zone clearance), fspl_db (free-space path loss)
• terrain_source ("bare" / "clutter" / "lidar"), lidar_coverage_pct, lidar_provider — which elevation data actually backed the worst point on this tower's path; lidar_coverage_pct is 0 unless Enable LiDAR (see Widget settings) is on for this widget.
• sector_name, rssi_dbm, throughput_mbps, modulation — only present when the project owner's plan includes predicted RSSI/throughput (Pro).

Example response

Error response — not authenticated

HTTP 401. Also returned for a stale or expired embedded-widget session — this is stateless and short-lived, so a visitor who keeps the same tab open for a long time may need to reload before their next check.

Error response — invalid source_url

Project Settings

Project settings configure per-project defaults and algorithm parameters. Settings apply to all users working on the project. The page is organized into tabs — Tower Marker, Sector Defaults, Frequencies, Equipment Presets, RF Heatmap, Classification, Clutter, Clustering, and White Area Detection — with one Save Settings button that saves whichever tab is active plus any others you've changed; it isn't per-tab. Changing a field that affects stored subscriber classification (see Classification below) shows a confirmation step naming how many subscribers will be re-classified before Save actually runs — recalculation itself then follows with a real progress bar, the same one the map's own Recalculate Coverage button uses.

Subscriber clustering

• Clustering threshold — subscriber count below which individual markers are shown instead of clusters. Default: 150. Lower = more clusters at higher subscriber counts.

White area detection

• Cluster radius — DBSCAN epsilon parameter. Default: 2.0 km
• Minimum subscribers — DBSCAN min_points parameter. Default: 3
• Hull buffer — convex hull outward padding. Default: 0.3 km

Sector defaults

These values pre-fill the sector form when adding a new tower, and serve as fallbacks when importing towers with missing sector fields.

• Default sector colour
• Default frequency band
• Default radius
• Default beamwidth (°)

Frequencies

This project's own list of assignable frequency bands — every sector-editing screen (map and admin) only offers values from this list, shown as a compact grid of one field per frequency. A new project starts with a default set of 19 common bands (900MHz through 80GHz, plus common LTE/LoRa numeric bands); add your own precise value if what you need isn't there, or delete ones you don't use. A frequency still used by an enabled equipment preset for this project can't be removed until that preset is disabled first, in the Equipment Presets tab below.

Equipment Presets

Which of your account-level equipment presets are offered when filling a sector's RF fields on this project's map and tower forms. New projects start with every existing preset enabled; manage the presets themselves (create, edit, delete) from the Equipment Presets page under Network in the sidebar. Enabling a preset here automatically ensures its frequency is on this project's Frequencies list above.

Classification

Turns on real signal-strength verification for subscriber coverage status, on top of the geometric sector-membership test described under Subscribers above. Off by default — every project behaves exactly as it always has (geometric served/unserved only) until you opt in.

• Verify with predicted RSSI — runs a real signal prediction, using this project's configured propagation model(s) (the same engine as the RF Heatmap and LoS Link Check), for every subscriber, not just a geometric check. A geometrically-served subscriber whose predicted signal falls below Minimum usable signal (dBm) becomes Marginal; below Hard floor / receiver sensitivity (dBm) it downgrades further to Unserved. A missing prediction (terrain data unavailable, etc.) never downgrades anyone — the geometric result stands.
• Allow RSSI to extend beyond configured radius — only meaningful with the toggle above on. Treats a sector's radius as a planning boundary rather than a hard coverage edge: a subscriber just outside the radius but still inside the beam can be promoted to Served if its predicted signal clears the threshold. Off by default — leave it off if your radii represent real business limits (install crew reach, franchise boundaries), not just "how far the antenna throws power."
• Extend margin (%) — only shown when the toggle above is on. A slider from 5% to 30% (default 15%) that sets how far beyond a sector's own radius a subscriber can still be considered: each sector's own search reach is radius_km × (1 + margin% / 100) — a 10 km sector at the default 15% margin reaches 11.5 km, a 20 km sector reaches 23 km. On Free, Trial, and Starter plans this per-sector reach is additionally capped at your plan's flat maximum RF link distance (5 km Free/Trial, 10 km Starter); on Pro (and for admin accounts) there is no additional cap beyond the formula itself — adjust either the sector's own radius or this margin to reach further. Whenever a tower or sector edit could change who qualifies, the map shows the margin percentage (and plan cap, if any) being used before recalculating so the effect is never a surprise.
• Require minimum throughput + Minimum throughput (Mbps) — an independent, further gate: a subscriber whose predicted throughput (from its CPE model's real MCS/sensitivity table — see Equipment Presets) falls below this number downgrades to Unserved, regardless of signal strength. Needs a resolvable CPE model (the subscriber's own, or this project's Default CPE model above) — without one, throughput stays honestly blank and never downgrades anyone.

Predicted RSSI/throughput numbers are computed and stored whenever either toggle is on, and are also computed on demand for a BEAD export regardless of these toggles — see BDC & BEAD Export. Viewing the stored numbers (the map popover, the subscriber list) requires a Pro or Trial plan; the toggles and thresholds themselves are configurable on any plan, but only take effect once the project owner's plan qualifies.

Tower marker

• Marker fill colour — colour of the tower dot on the map and its label background
• Marker border colour — stroke colour around the tower dot

RF Heatmap

Both the link-budget assumptions and the display/colour settings live together in this one tab. See RF Propagation Heatmap for what these control — both display modes render from the same computed data, only the threshold/colours applied here differ. The multi-color signal-strength bands are shown as a compact table, one row per band.

• Assumed CPE antenna gain (dBi) — a project-wide stand-in for "a typical subscriber radio," since there's no real subscriber to read a value from for a hypothetical heatmap grid cell. Default: 20 dBi (up to 50 dBi accepted, for projects modeling 60 GHz mmWave CPE).
• Assumed cable/connector loss (dB) — same reasoning, typical short jumper + connector loss. Default: 1.0 dB.
• Overlay opacity — how solid the public/embeddable single-color view looks. From 10% to 100%, default 50%. Display-only — changing it re-colours the already-computed heatmap the next time it's rendered, it never clears or recomputes any heatmap. The internal map's own Heatmap layer has a separate, session-only live opacity slider instead (in the Layers panel, next to the layer toggle) — this project setting only seeds that slider's starting position, it doesn't otherwise control the internal map.
• Minimum usable signal (dBm) — the single threshold for the public/embeddable single-color view: points at or above this show as "covered". Default: −80 dBm.
• Covered colour — the single-color view's "covered" colour.
• Multi-color signal-strength bands — a list of dBm ranges and colours for the internal map layer, ordered strongest to weakest. Either end of a band can be left blank for an open-ended range (the strongest band has no upper limit, the weakest has no lower limit).

Account Settings

Account settings manage your personal profile and subscription.

Account page

• Update your name and email address
• Choose your preferred currency (USD or EUR) and distance unit (kilometers or miles)
• Change your password
• Delete your account (see below)

Deleting your account

Account deletion is available in the Danger Zone section at the bottom of the Account page. Deletion is not immediate — the following process applies:

1. Click Delete Account and confirm your email address
2. A confirmation email is sent with a cancellation link
3. A 7-day grace period begins — your account remains fully accessible during this time
4. To cancel the deletion, click the link in the email or click Cancel Account Deletion on the Account page
5. After 7 days, your account and all data are permanently and irreversibly deleted: projects, towers, sectors, subscribers, coverage data, drive tests, LoS links, shared maps, and exports

Billing page

• View current plan and trial status
• See usage vs limits for projects, towers, subscribers, and saved links
• Upgrade, downgrade, or cancel your subscription
• Switch between monthly and annual billing
• Switch between USD and EUR currency
• Access the Stripe customer portal to manage payment methods and invoices

Feature Requests

Suggest new features and vote on proposals from other users. The roadmap is shaped by the community.

Submitting a request

Any registered user can submit a feature request with a title and description. Requests are reviewed by the GridVisio team before being published for voting.

Voting

Once approved, feature requests are open for voting. Vote weights depend on your plan:

• Free / Trial: 1 vote weight
• Starter: 2 vote weight
• Pro: 3 vote weight

Each user can vote once per feature request. Implemented features are marked accordingly.

Bug Reports

Report issues or unexpected behaviour directly from within the app.

Submitting a report

• Title — brief description of the issue
• Severity — Low / Medium / High / Critical
• Description — what happened and what you expected
• Steps to reproduce — optional numbered steps
• Screenshots — up to 2 screenshots (max 500 KB each)

You can track the status of your submitted reports from the same page. Statuses: Open → Acknowledged → In Progress → Fixed → Closed.

Plans & Limits

GridVisio is available on four plan tiers. All new accounts start with a 14-day free trial (Starter-level access, no credit card required).