Feature Request: DXCluster Integration

[joshuarubin]

It would be amazing if we could directly add support for dxcluster and being able to mark received spots in the display (basically as ephemeral bookmarks named by callsign).

As direct support for this might be outside the scope of the project, an alternative would be some sort of remote interface that could interact with sdrpp to be able to add and remove the spots from the display.

[AlexandreRouma]

Hello,

I think it's in the scope, everything being a module in SDR++, it's easy to add a niche feature like that and make it optional.

If the API of dxcluster is simple enough it shouldn't be too hard of an addition.

[joshuarubin]

Sounds good.

Here are some notes for when you (or maybe I could take a stab at it) look to implement this:

• DX Cluster is just telnet. You'd need to be able to set the host and port to connect.
• You'd need to show the telnet output somewhere
• User needs to be able to type in new input
• A "nice to have" would be to have a script that could be executed on initial connection
• It would be nice to be able to remember multiple servers and choose which to connect to

The output lines are all pretty standard and easy to parse, here are a few that I have up right now:

DX de K9IMM-#:  14050.00  K0HNL        CW 35 dB 18 WPM CQ             2001Z
DX de KM3T-#:   14018.00  I1ULJ/8      CW 13 dB 23 WPM CQ             2001Z
DX de W1NT-6-#: 14057.00  W8ARC        CW 12 dB 13 WPM CQ             2001Z
DX de VE6WZ-#:  14056.50  AI5P         CW 11 dB 20 WPM CQ             2001Z

Not every line is like that (e.g. status line, welcome lines, etc.), but those are the ones that need to be parsed. It's just:

DX de <from_callsign>: <freq> <spotted_callsign> <notes>

The only really important parts are the frequency and spotted callsign. The output format might vary from server to server, so it's best not to be too strict about whitespace amounts. You can check the notes for things like CW which indicates the mode, but that info is all completely up to the spotter to provide in any way they want so there is no standardization.

Also, it's important that each entry expire after some (configurable?) amount of time (e.g. 10m) unless spotted again.

Here's a list of a bunch of servers you can test with: https://www.ng3k.com/Misc/cluster.html

Thanks again!

[JackHunt]

Good morning both. Firstly @AlexandreRouma thank you for building this software. I have wanted something this feature rich and cross platform for some time. @joshuarubin I was thinking this morning about forking and working on this, but if you do start working on a PR then let me know. I'm a full time software engineer with a ton of life stuff going on (plus ham activities) so it might be some time until I can sit down and start it. I'd love to see it anyway.

[joshuarubin]

@JackHunt I'm a full time software engineer as well as an active ham. I'm extremely frustrated at the state of software for hams. This community was built on open platforms and sharing technology (e.g. radio hardware schematics). However, the software that runs our gear and on (most of) our computers is completely closed. So much of the stuff that is open source isn't great (this project showing obvious promise). We have some other good building blocks with gnuradio and hamlib. The software so many hams rely on, things like N1MM, are all closed and so many are built by "a guy" even if it's "free". I'd love to start building community supported, open tools that work on all platforms that will eventually replace the closed software in use today. If only so that when the people that have built the current tools become silent keys we have ways to continue.

Anyway, sorry for my rant/manifesto. This project looks great, thank you @AlexandreRouma, and I think it fills an important gap. gqrx hasn't had much work lately and this seems more flexible.

I'm open to whatever/however we can start building a community to support this, larger, endeavor.

[n2iw]

Cluster integration or a plugin will be very useful for DXers (like me) and contesters. A widely used contest software is called WaterfallBandmap (written by N2IC), it displays a waterfall and DX spots. It syncs frequency with N1MM (bidirectional UDP + XML), and receives dx spots info from N1MM (UDP + XML).

I have a Python script to sync frequencies between SDR++ and N1MM(or RUMlogNG), next step would be displaying DX spots in SDR++. If API and some documentation/examples are available, I can try to write a plugin to accept DX spots from N1MM and display them in SDR++.

[AlexandreRouma]

In the end I've decided I won't support it myself.