Add dstar and other digital modes

[jbburns]

I know the primary use case for ham alert is HF, but it would be nice to get an alert when a friend or someone from a previous QSO is seen on a reflector or a specific digital repeater.

The good news is given it's digital, the data is already out there on dstarusers and other platforms - there just isn't a push mechanism to get alerts.

My idea is to build a pipeline that can pull from these sources and generate alerts based on the existing trigger mechanism.

I'm happy to contribute this myself, but would like some opinions on it first and hear appetite from maintainer

[chrisdebian]

Great idea — this would genuinely extend HamAlert's usefulness beyond HF.

If it helps for scoping: HamAlert's existing spot sources (sotaspots.js, pskreporter.js, rbn.js, potaspots.js) all follow the same shape — a small EventEmitter-based poller that normalises whatever external feed into a common spot object (source, time, fullCallsign, frequency, mode, comment, spotter, rawText) and hands it to the existing matcher. A digital-voice source could follow exactly the same pattern, with no changes needed to the trigger/matcher pipeline itself.

Two real, already-existing real-time feeds worth considering as the actual data source, rather than scraping dstarusers.info's dashboard directly:

• D-STAR: ircDDB already does real-time "last heard" reporting across the whole connected-gateway network — it's what feeds dstarusers.info in the first place. It's a TCP/IRC-like protocol rather than a REST API, but genuinely real-time and covers the whole network, not just one reflector.
• DMR: BrandMeister has an official Last Heard API plus MQTT support for pushing events live — probably the more straightforward of the two to integrate first, since it's a documented API rather than a legacy IRC-shaped protocol.

Given DMR's talkgroup/repeater model and D-STAR's reflector/gateway model don't map cleanly onto each other, a new field (analogous to sotaspots.js's summitRef) would probably be needed in the shared spot schema, rather than trying to force it into the mode/frequency fields alone.

@manuelkasper — interested to hear if this fits where you'd want the project to go. @jbburns, happy to help with the D-STAR/ircDDB side specifically if useful, though very happy to leave the build to you given you've already offered.

73 de Chris, 2E0FRU

[manuelkasper]

Sounds good to me – seeing as we already have PSK Reporter as a massive, automated spot source, I see no reason why this concept shouldn't also extend to VHF/UHF digital voice modes.

One question – best answered by someone who actually uses things like D-STAR, DMR or C4FM, i.e. not me – would be what kind of activity should trigger an alert. For example, should a QSO between two parties already be enough to trigger alerts for both of them, or only if a station actively calls CQ? That distinction could be made on D-STAR, as far as I know, but not on the other common DVMs. We want to avoid people feeling overly “spied upon” by the system (see the discussion at https://forum.hamalert.org/t/privacy-concerns-and-user-control-suggestions-for-ham-alert/1021).

The other question concerns the additional load imposed on the backend by these new spot sources, but I suspect that compared to the ~30 million spots per day generated by PSK Reporter, it will be negligible 😂

73, Manuel HB9DQM

[jbburns]

The privacy thing is somewhat of a solved problem in D-STAR world. You can set your radio to NO VIS and it won't be reported by irddb.
That said, it's pretty open already. Anyone can go to dstarusers and see who is doing what on which reflector.

Regarding activity:
When someone connects (links) to a reflector, that is registered and visible in the dashboards/irddb feed.
When someone keys up, that is also published as a last heard.

Ex) https://ref030.dstargateway.org/

Basically all we're doing here is taking the existing information and turning it into push notifications.

Regarding load:
Take with pinch of salt because my Claude Code did the research... but DStar seems to be considerably less active than DX.
~192k messages/day and not all of those would be "spots" maybe 1/3

[chrisdebian]

Good question, and I think the answer differs by mode:

D-STAR – as Manuel notes, the protocol carries both "UR" (destination) and "MY" (source) callsign fields, so a station calling CQ sets UR to CQCQCQ, while a directed QSO sets UR to the other station's callsign. This is visible on the Dashboard/gateway feeds and via things like DExtra/DPlus reflector logs, so HamAlert could reliably fire only on CQ calls and skip directed traffic entirely. That's the safest default and avoids the "being spied on" problem for two hams having a private QSO.

DMR – there's no equivalent CQ/directed distinction in the protocol itself; every transmission is just a source ID keyed to a talkgroup or private call. Brandmeister's Last Heard feed (available via API/MQTT) shows talkgroup activity but can't tell you whether someone "called CQ" versus was mid-QSO. Realistically the only workable proxy is talkgroup-based: alert on activity on well-known "calling" talkgroups (e.g. a regional or worldwide TG) rather than trying to infer intent from a single transmission.

C4FM/YSF – similar story to DMR. Wires-X and YSFReflector-based systems expose "last heard" data per reflector/room, but again there's no structural CQ marker. Same fallback: treat activity on a reflector/room as the trigger rather than trying to distinguish call types.

So my suggestion: implement the CQ-only distinction for D-STAR since the protocol actually supports it, but for DMR/YSF be upfront that "spotted" means "was heard on this talkgroup/reflector" rather than "called CQ" — and maybe surface that difference in the alert wording itself so users aren't surprised. That, plus making all three opt-in per callsign (as the forum privacy thread suggests), should keep it from feeling like surveillance.

73 de 2E0FRU

[jbburns]

Pull requests for the D-STAR part are up, one per repo:

• Server (QuadNet/ircDDB presence source, new dvEvent/dvNode/dvReflector conditions, local dev mode): Add D-STAR presence alerts (QuadNet/ircDDB source) and local dev mode hamalert-server#29
• Web (trigger editor conditions, docs, Alerts page, dev Docker image): D-STAR trigger conditions, Alerts page, dev Docker image hamalert-web#7
• App (rendering of D-STAR spots without a frequency): Render D-STAR presence spots hamalert-app#26

🤖 Generated with Claude Code

[jbburns]

Thank you for the feedback. I went ahead and had a stab at D-STAR. I'm not familiar with other DV modes so only felt knowledgeable enough to do this.

Also modified code a bit to make local validation easy and uploaded a bunch of screenshots/gif. That is why server PR seems big... touched every file to allow config loading rather than hard coded... that made local testing easier.
I added alert page to UI so you don't have to use telnet - and originally didn't have app working.

I got app working locally in browser, not actual app.

Basically, it seems like it is working - but happy to have any feedback.

[manuelkasper]

Thanks for the PRs! It will take me a while to sift through all the generated code, but I want to understand all of it before I merge anything.

Two questions so far:

• The default polling interval is only 5 seconds, which seems quite aggressive to me. Do we know whether QuadNet and ircDDB are OK with that, or with us using them as a data source at all?
• Apparently we have no frequency/band information on these spots, and also not always a spotter callsign. I guess it's not safe to assume this is all 70cm, as there are 2m D-STAR relays as well? I would very much like to have the basic set of information on all spots (callsign, spotter, band/frequency, mode).