For my DXing work, I find it incredibly useful to just click on a station and have my radio change frequency and enter the call. Is there any reason that we could not set up the same thing but for SOTA? I have a few servers laying around that could be put into use, but I would need some help with the programming – if there is any interest.
It could run within Ham Radio Deluxe and other programs (ermmm programmes for the UK types :-D)
Over and out…
K9EZ
In reply to K9EZ:
It sounds like some simple software plumbing. That probably means it’s more complex than it seems.
Thinking aloud…
Use W1HKJ’s excellent flrig to control the transceiver. This program exists for Windows, Linux & Mac OSX and supports numerous transceivers. It has an interface that allows fldigi to control flrig and hence the TRX.
Sotwatch has an RSS feed. The best way to get spots is to use the feed. It’s stable and works. I use it for my Twitter bot, Eric uses it for RBNGate for example. Much better than scraping the webpage.
So the 2 key components exist, a feed of raw information and a cross platform program that will drive rigs via their CAT interface. All (ha!) that’s need is something to plug them together and let you click the spot you want to tune to. .NET app, Python/TK, TCL/TK etc. Trivial for anyone with the time. Sadly that’s not me at present.
Andy
MM0FMF
In reply to MM0FMF:
Huh, I wonder if I can grab that RSS feed and dump it into DXCluster… OK OK I guess it will be a good read on my flight to Stockholm.
In reply to K9EZ:
In reply to MM0FMF:
Huh, I wonder if I can grab that RSS feed and dump it into
DXCluster…
Tried that about 2 yrs ago with the Twitter feed to qrpspots.com and the DXCluster. At that time, the DXCluster folks didn’t want the SOTA traffic. They didn’t consider SOTA spots to be “real” DX.
Maybe the DXCluster folks have a different opinion now. Maybe. But probably not. But it might be functionality the HRD folks might consider integrating into their package??
Guy/N7UN
In reply to N7UN:
Wouldnt there be a way to not get “in to” the DXCluster network, i.e. not share the posts, but just keep it on one or a few nodes without broadcasting it?
I am not sure if I see the need to integrate the cluster into HRD, as you still would need nodes somewhere. That said, I would GREATLY like them to include tracking. But I digress…
In reply to K9EZ:
I would think it would be great to have a dedicated “SOTA cluster” that we can all point our logging programs towards. Most logging programs like HRD, Logger32, etc already have the capability to “point and click” on various DX spots that show up in a Telnet window, so all that is really missing is a dedicated Telnet SOTA cluster that lives out on the internet somewhere. We would enter its IP and port address into our logging program and it would generate SOTA DX spots instead of regular DX spots.
Dave
N5XL
In reply to N5XL:
Hmmmmm…
Andy
MM0FMF
In reply to MM0FMF:
Like I said I have some Dell servers, and could put it on my private home network, or even better if I could put it on the server I rent for a web page. Linux. To be honest I do not have a lot of time to develop as I am working my tail end off. But I will do what I can.
For you wizards, how do we convert RSS to telnet?
In reply to MM0FMF:
Haven’t looked to see if any of these cluster programs are open-source since re-inventing the wheel would be painful. Lot’s of cool functionality (band, time, country filters, for instance) with these programs.
See DXCluster.INFO - DX Cluster Software
Guy/N7UN
In reply to N7UN:
Hmmmmmmmm…
“CLX is a clone of AK1A PacketCluster that runs under the Linux operating system. The name CLX stands for CLuster software running under linuX and is written by Franta Bendl, DJØZY and Bernhard (Ben) Büttner, DL6RAI.”
And its freeware…
In reply to MM0FMF:
I have a very basic server running that gives a telnet interface to the SOTAwatch spots. It’s fed from my Twitter bot and pumps out any new spots every minute. You can connect and watch what comes out. No commands, no filters. If it’s spotted on SOTAwatch it will sent out to all connected clients. That’s it but it should be enough for now.
e.g.
andy@revo:~$ telnet spotsrv 5000
Trying xxx.xxx.xxx.xxx…
Connected to spotsrv.
Escape character is ‘^]’.
DX de MM0FMF: 7032.0 GS3PYU GM/SS-214
DX de MM0FMF: 7283.0 KI4SVM W4T/SU-033
So I’d like some volunteers to try it. email me (mm0fmf AT hotmail.com) and I’ll give you the details.
Andy
MM0FMF
In reply to K9EZ:
One of the features I was going to put into SOTA Spot Monitor, but haven’t got around to yet, is a Telnet port that would output the spots in the same format as DXCluster. You would then be able to tell your logging program to read spots from SOTA Spot Monitor on your local computer, just like how you now tell it to read spots from a DXCluster node out on the Internet.
If your logging program supports multiple Telnet spot feeds that then get combined into a single window (I use LOGic9 and it has that capability) you would be able to see the SOTA spots mixed in with the DXCluster spots for a “unified” spot display. If double-clicking a DX spot causes your rig to change to that frequency and mode, the same thing would happen if you double-clicked a SOTA spot.
Maybe when the snow falls I’ll look into implementing that.
73,
Eric KU6J
In reply to N7UN:
Haven’t looked to see if any of these cluster programs are open-source
since re-inventing the wheel would be painful. Lot’s of cool
functionality (band, time, country filters, for instance) with these
programs.
I’ve done a bit more research and noodling on this topic. I think that there is a relatively easy way to create a scalable and highly reliable SOTACluster that includes all the usual DXCluster functionality without reinventing any wheels.
AB5K has already created the scalable and highly reliable AR-Cluster v6:
Per his SysOp Manual, the software can be configured to receive spot inputs from a variety of external sources:
“The Client I/O allows you to connect to other nodes or skimmer devices. Sample connections are provided to the Reverse Beacon Network, popular skimmers, IRC channel, ARC6 node connections, ARC4 Active Node connection, ARC4 Passive Node connection, and other Telnet connections.”
http://www.ab5k.net/ArcDocsVer6/SysopManual/AR-ClusterServer.htm
This means that the only new piece of software we would need to provide is a middleware piece that would read spots from SOTAWatch and then output them on a telnet port in DXCluster format. The middleware piece need not be scalable, it will only be servicing a single connected client (the AR-Cluster v6 software).
See the posts above, we are very close to having this middleware capability already via two possible methods:
Andy’s basic server that provides a telnet interface to SOTAwatch spots. It may be sufficient as-is with no more development time required.
I could add a telnet output to SOTA Spot Monitor as described in my post above. This actually isn’t very hard to do. SOTA Spot Monitor and RBNGate share the same code base and RBNGate already has telnet capabilities (for reading spots from RBN).
If the intent were also to allow people to spot SOTA stations via this SOTACluster and have those spots be replicated over in SOTAWatch, this would take additional effort and it is trickier than it seems. There are a number of issues that would need to be carefully thought through and addressed (e.g., handling dupes, preventing infinite spot loops, etc.). Since it doesn’t appear that anyone is looking for this type of bi-directional spotting functionality, I won’t bore you with further discussion of this aspect.
73,
Eric KU6J
In reply to KU6J:
I think feeding the real cluster network would not be want most people want. Our own cluster keeps SOTA spots in the SOTA community. e.g. someone activates a SOTA summit on VP8. It’s likely that the activator would primarily want SOTA chasers to have a QSO over non-SOTA amateurs. Feeding the normal cluster network makes that less likely. It may result in more contacts for the activator but when they have limited summit time, feeding the people who support the program comes first.
Andy
MM0FMF
In reply to KU6J:
My primary interest is using my general logging program (DX4WIN) for SOTA. And with the telnet connection, SOTA spots now populate my DXspots window thereby allowing a double-click for populating my QSO window as well as controlling my connected rig to move to the spotted frequency/mode. Seems to me this is the major functionality of the SOTA cluster, i.e. via a telnet connection, populate my local logging program with spot info along with rig control.
Currently I only log SOTA qsos into the SOTA database and not locally in DX4WIN. But now, I generate a report from DX4WIN for SOTA qsos, upload into Excel for some field formatting, then bulk load that file into the SOTA database. Easy. Since DX4WIN doesn’t yet support the latest SOTA fields in the ADI spec, I have to manually type that in my qso window. Then Excel creates a V2 CSV file for upload. In the next few weeks, I’ll write a simple Python script to do all that post processing exclusive of Excel.
Cool stuff but I don’t think the intent is replace SOTAwatch which is a unique web-based spotting/alerts cluster on its own.
I’ll send you some screen snags of some windows in DX4WIN and what the interface looks like.
73, Guy/N7UN
In reply to MM0FMF:
I think feeding the real cluster network would not be want most people
want. Our own cluster keeps SOTA spots in the SOTA community. e.g.
someone activates a SOTA summit on VP8.
I agree Andy, that’s why we would be running our own SOTA-specific instance of the AR-Cluster v6 software. It would receive SOTA spots from SOTAWatch as I described above, but have no connection at all to the DXCluster.
Users would still enter their new spots into SOTAWatch via existing means. There would be no need for this dedicated instance of AR-Cluster to have an outbound gateway at all, unless you also wanted to allow users to enter spots directly into it and have them replicated over to SOTAWatch (this part gets tricky and is hopefully not needed at all).
In reply to N7UN:
And with the telnet connection, SOTA spots now populate my
DXspots window thereby allowing a double-click for populating my QSO
window as well as controlling my connected rig to move to the spotted
frequency/mode. Seems to me this is the major functionality of the
SOTA cluster, i.e. via a telnet connection, populate my local logging
program with spot info along with rig control.
That is how I interpreted the “requirements” as well: a means of getting SOTA spots into logging programs via the telnet-based DXCluster interfaces that logging programs already have, and to allow the spots to be filtered via all the same methods available in DXCluster.
How are you currently retrieving SOTA spots via Telnet? Are you connecting to Andy’s server?
73,
Eric KU6J
In reply to N7UN:
In reply to KU6J:
Seems to me this is the major functionality of the
SOTA cluster, i.e. via a telnet connection, populate my local logging
program with spot info along with rig control.
This is exactly the way I see it and the way I would use it.
Dave
N5XL
In reply to KU6J:
Yes, I connect to Andy’s server via telnet. He’s making improvements with a login function as well as adding robustness. I’ve not yet had to implement “keep alive” on my side (generally a ping every so often) and have only lost the connection a few times which I attribute to Andy’s development work.
If DX4WIN supported the latest ADI spec which includes the my/there SOTA Ref Nrs, I would not have to enter there SOTA ref nr into my logging program. It would populate automagically. But will still have to post-process my log into a V2 format required by the SOTAdata upload field format requirement.
Guy
In reply to N7UN:
It’s working with DX4WIN, Logger32, Band Master & XDX according to reports from the alpha testers. Not yet with HRD. There’s an net exception being thrown that I’ve not captured yet. I’ve poked about this morning and it’s on uptime testing now. Every now and then I hit the server with a connection flood to check it stays up. It’s handy having computers in data centres… you can’t half generate some network traffic with a 1Gbps net connection!
I’ve spent this afternoon adding SWL support to the database and removing centre-justifcation changes. Tom probably wont believe there’s mainline SWL support till he sees it working!
Andy
MM0FMF
In reply to N7UN:
In reply to KU6J:
Yes, I connect to Andy’s server via telnet. He’s making improvements
with a login function as well as adding robustness.
OK, then you are already doing a significant part of what (I think) was requested. If one were to insert a dedicated instance of AR-Cluster v6 in between you and Andy, you would then gain the ability to filter the spots via the standard and robust DXCluster methods:
http://www.dxcluster.org/main/filtering_en.html
Andy wouldn’t need to spend any time assuring that his server can support hundreds or thousands of simultaneous SOTA chaser connections, implementing filtering or logins, etc. AB5K has already taken care of all that and more.
73,
Eric KU6J