RefCheck.Radio is a reflector availability monitoring and hostfile distribution service for digital voice ham radio modes – YSF, FCS, DMR, D-Star (D-Plus, D-Extra, DCS), P25, NXDN, M17, and XLX. It was developed and is operated by me, W0CHP, and it does three related but distinct things:

1. Probes every reflector registered in DVRef for reachability every 30 minutes, around the clock, and records the results.
2. Produces and serves formatted hostfiles – the data files hotspot software use to build their reflector lists.
3. Partners with DVRef.com – the authoritative digital voice reflector registry – to keep both services accurate and mutually reinforcing.

The Problem Hostfile Scrubbing Solves

Every digital voice mode ships with a hostfile: a plain-text list of every known reflector, its address, and its port. Those lists are built from registry data and can grow to hundreds or thousands of entries. The problem is that reflectors come and go. Operators retire them, servers crash, home internet connections fail. When that happens, the dead entry stays in the hostfile indefinitely – because registries track existence, not reachability. Think of a registry like a phone book: it tells you who is listed and what number to call, but not whether anyone is home to answer.

The practical result: your hotspot’s reflector list fills up with entries that look valid but time out when you try to connect. Scrubbing is the process of removing those entries before the hostfile reaches your device.

RefCheck.Radio is the scrubbing engine behind the hostfiles that WPSD – and soon Pi-Star – deliver to your device.

The Partnership with DVRef.com

DVRef.com is the canonical registry for digital voice reflectors worldwide. It was founded by Steve Miller (KC1AWV) and co-developed by KC1AWV and me (W0CHP). Operators register their reflectors in DVRef, and DVRef is what WPSD, Pi-Star, DVSwitch, BlueDV, DroidStar, and SharkRF devices ultimately draw from.

RefCheck.Radio and DVRef are not the same organization, but we are partnered. The relationship is bidirectional: each service feeds the other.

DVRef → RefCheck: The Reflector Feed

DVRef exposes a live API that RefCheck.Radio polls to get the full list of registered reflectors for each mode. This is how RefCheck knows what to check – it does not maintain its own registry. When a new reflector is added to DVRef, it automatically enters RefCheck’s check cycle on the next sync, and its reachability is verified before the next hostfile publish.

RefCheck → DVRef: The Availability Feedback Loop

RefCheck.Radio feeds its availability data back to DVRef via a token-gated API – DVRef holds an API token the same way WPSD does. DVRef ingests this data and uses it to flag reflectors that RefCheck has reported as continuously unreachable for 72 hours or more as stale in the DVRef registry. This keeps the authoritative registry itself cleaner – entries that are clearly abandoned do not silently accumulate indefinitely.

flowchart TD
    DVREF["DVRef.com
Authoritative reflector registry
Operators register here"]
    RC["RefCheck.Radio
Polls every reflector
Every 30 minutes"]
    HFRC["hostfiles.refcheck.radio
Unfiltered formatted hostfiles
Public -- not scrubbed"]
    RCAPI["RefCheck API
Live status + scrubbed hostfiles
Partner access only"]
    WPSD["WPSD Hostfile Server
hostfiles.w0chp.net
Publishes at :15 and :45"]
    PISTAR["Pi-Star
Coming soon"]
    DEVICE["Your Hotspot
Refreshes every ~4 hours"]
    OTHERS["Other Consumers
DroidStar, DVSwitch,
repeater & reflector software,
and more"]

    DVREF -->|"Reflector list via API"| RC
    RC -->|"Availability data via API"| DVREF
    RC -->|"Formatted, unfiltered files"| HFRC
    HFRC -->|"public hostfiles"| OTHERS
    RC -->|"Scrubbed hostfiles via API"| WPSD
    RC -->|"Scrubbed hostfiles via API"| PISTAR
    WPSD -->|"Clean files on schedule"| DEVICE
    PISTAR -.->|"soon"| DEVICE
  

What RefCheck.Radio Produces

Public Availability Portal

Anyone can visit refcheck.radio to see a live dashboard of every monitored reflector, its current status, and how long it has been down. The stats tab shows outage history, the most unreliable reflectors by mode, and the longest current outages. No account or API token is required to browse the public portal.

Unfiltered Hostfiles – Public, Not Scrubbed

hostfiles.refcheck.radio serves formatted hostfiles for every supported mode in both plain-text (.txt) and JSON (.json) formats. These are not scrubbed – they contain all registered reflectors, whether currently reachable or not. They are updated after each sync cycle.

These public files are useful for developers who want ready-formatted hostfiles without hitting the DVRef API directly, and for operators who want to consume the full list for their own filtering logic.

Scrubbed Hostfiles – Partner Access Only

The scrubbed hostfile API – which returns hostfiles with unreachable reflectors already removed – is reserved for prominent projects and developers. Access requires an API token issued by me directly. Current authorized consumers include:

• DVRef.com – consumes availability data to flag and delist stale reflectors in the registry
• WPSD Project – full scrubbed hostfile access for all modes
• Pi-Star – API token issued to Andy Taylor (MW0MWZ); integration in progress

Requests from individual users or smaller projects are evaluated case-by-case. The same meritocracy-and-consensus standard that governs DVRef access applies here: access is granted based on what a project contributes to the digital voice landscape and whether the existing authorized teams agree.

What Scrubbing Means for End Users

The concrete user experience benefit is simple: every reflector in your list actually works when you try to connect to it.

Without scrubbing, hotspot software downloads whatever the registry contains – and registries accumulate dead entries over time. Operators shut down reflectors, servers go offline, internet connections fail. Those entries stay in the hostfile until someone manually removes them from the registry, which often never happens. The result is a reflector selector full of entries that spin and time out, forcing you to try entry after entry before finding one that responds.

With scrubbing, that dead weight is removed before the file reaches your device. The list is shorter – sometimes noticeably so – but every entry on it has been continuously reachable within the last 24 hours. A reflector that fails a single check is not immediately removed – brief blips and transient network hiccups do not yank a reflector from the list. Only after 24 hours of continuous unreachability is an entry omitted from the scrubbed hostfile. You pick a reflector and it connects.

The secondary benefit is noise reduction in the other direction: reflectors that come back online after a short outage automatically reappear in the next published hostfile with no manual intervention needed – as long as they recover before DVRef’s 72-hour stale threshold triggers. Once a reflector has been flagged as stale and delisted from DVRef, it exits RefCheck’s check cycle and will not reappear automatically; the operator needs to re-validate it in DVRef first. See When DVRef Delists a Reflector for how that cascade works.

How the Check Cycle Works

RefCheck.Radio runs a full sync every 30 minutes. For each mode, it:

1. Fetches the current reflector list from the DVRef API.
2. Fires a mode-appropriate probe packet at every reflector concurrently – the same type of handshake a hotspot would use to link. Up to three attempts are made per reflector before it is marked down.
3. Updates the database with the result, recording down events and the time each outage began.
4. Writes updated hostfiles to hostfiles.refcheck.radio.
5. Makes the result available immediately via the scrubbed hostfile API, omitting any reflector that has been continuously unreachable for 24 hours or more.

flowchart LR
    A["Fetch list
DVRef API → RefCheck"]
    B["Probe reflectors
UDP checks in parallel
Up to 3 attempts each"]
    C["Update database
Record up/down events
Track outage duration"]
    D["Publish hostfiles
Unfiltered → hostfiles.refcheck.radio
Scrubbed → API for partners"]
    E["Feed back to DVRef
Flag 72h+ unreachable
reflectors as stale"]

    A --> B --> C --> D
    C --> E
  

The Full Pipeline to Your Device

Putting it all together, hostfiles travel through a three-stage pipeline before reaching your WPSD hotspot:

flowchart LR
    RC["RefCheck.Radio
Polls every reflector

Every 30 min"]
    WHS["WPSD Hostfile Server
Waits for sync to finish,
then pulls scrubbed files

At :15 and :45 each hour"]
    DEV["Your WPSD Device
Checks hourly;
downloads if local copy >4h old

~Every 4--5 hours"]

    RC -->|"scrubbed files via API"| WHS
    WHS -->|"clean files on schedule"| DEV
  

Worst-case end-to-end latency: approximately 5 hours – up to 30 minutes of RefCheck sync latency, plus up to 30 minutes between server publishes and your device’s next check, plus up to 4–5 hours until your device’s next refresh cycle. Most other hotspot software only refreshes once every 24 hours.

For a detailed look at how WPSD specifically consumes these files, what each hostfile contains, and how to force an immediate update on your device, see How WPSD Hostfiles Work .

Availability Data Flowing Back to DVRef

The feedback loop from RefCheck to DVRef deserves a closer look, because it closes a gap that a pure registry model cannot close on its own.

DVRef knows about every reflector that has ever been registered. It does not know whether those reflectors are still running. RefCheck does. By feeding availability data back to DVRef, the two services together can answer a question neither can answer alone: “Is this reflector both registered and currently reachable?”

flowchart LR
    subgraph DVRef ["DVRef.com"]
        REG["Reflector Registry"]
        VALID["Validity / Stale Flags"]
    end
    subgraph RC ["RefCheck.Radio"]
        CHECK["Availability Checks"]
        STATUS["Status Database"]
    end

    REG -->|"registered reflectors"| CHECK
    CHECK --> STATUS
    STATUS -->|"72h+ unreachable → stale"| VALID
    VALID -->|"updated registry data"| REG
  

A reflector that has been continuously unreachable for 72 hours or more is flagged as stale in the DVRef registry. Stale reflectors are not removed outright – operators can fix and re-validate them – but the flag prevents stale entries from silently living forever in the canonical data.

When DVRef Delists a Reflector

When Steve acts on a stale flag and removes a reflector from the DVRef registry, the removal cascades automatically through the entire pipeline – no manual intervention needed anywhere downstream.

1. DVRef removes the reflector; it no longer appears in the DVRef API response.
2. RefCheck’s next sync (within 30 minutes) downloads the updated reflector list. Any ID present in the RefCheck database but absent from the new list is immediately removed from the live monitoring tables.
3. RefCheck’s hostfiles – both the public unfiltered files on hostfiles.refcheck.radio and the scrubbed API feed – are written at the end of that same sync. The delisted entry is gone from both.
4. WPSD Hostfile Server picks it up at its next :15 or :45 publish and serves the clean file.
5. WPSD client devices pull the updated file within their next refresh cycle.

Worst case: a DVRef delisting reaches thousands of WPSD client devices within approximately 5 hours, entirely automatically.

What Happens to the Outage History?

The delisted reflector’s live record is removed, but its outage history is preserved. RefCheck stores availability events in a separate log table that references reflectors by a plain ID string – not by a database relationship – so deleting the live record does not touch the historical data.

Within the 90-day retention window, the outage history for a delisted reflector remains available via the history API and can still surface in the Most Unreliable stats table. This is intentional: if a reflector was chronically unreliable before being delisted, that record still exists for reference. It simply no longer appears as a live entry in the monitor or hostfiles.

RefCheck.Radio is developed and operated by Chip Cuccio, W0CHP. For live reflector status, visit refcheck.radio . For hostfile downloads, visit hostfiles.refcheck.radio .