Testing Andy’s SOTA cluster with DXLabs. Works perfectly and is so cool. See the spot, click on it, rig is set, antenna is switched, log form is filled in. Add the RST and summit info and hit ‘log’. Hmmmm, I really need to add rotor control to my list 
DXLabs suite is great software and is totally free. Dave/AA6YQ’s (the author) support is second to none. If you’re at all interested in DX’ing beyond SOTA it is worth checking out.
Thanks Andy!
Jim/KK1W
In reply to KK1W:
Ditto for Logger32. I cant brag enough about how well it works.
Now that I am a bit past the “alpha test mode” I have Logger32 configured to connect to Andy’s SOTA cluster as well as my normal DX cluster (VE7CC). My DX spots window now gives me integrated SOTA specific spots along with “normal” DX spots. I’ve color coded all SOTA specific spots from Andys cluster so that they stand out as a different color from the regular DX spots from the VE7CC cluster. I see a new summit show up, I point, click, the KX3 jumps to the correct frequency and I am ready go.
I think Andy’s probably gone about as far as he can go with the system he has. It works with most (not all) logging programs and it does exactly what we (I) asked for. I cant brag enough about Andy’s efforts on this project.
Thinking ahead, I can see the next logical step forward being Eric’s suggestion of inserting an actual DX cluster between Andy’s work and the general SOTA public. This new SOTA DX cluster would only take feeds from Andy’s SOTA telnet node. It would have no connection to standard DX feeds nor would it send any SOTA spots to outside DX cluster nodes. It would be a true stand alone SOTA DX cluster dedicated to SOTA traffic only. We as end users then point our logging programs to this dedicated SOTA DX Cluster which allows us to then issue standard cluster commands…ie, pull up the past few hours of SOTA spots, pull up SOTA spots for a specific band, etc…something that we cannot do with Andy’s system now.
I am very happy with Andy’s work as is and it does what I want. I can live without the ability to pull up the past 10 or 15 SOTA spots. However, if we want that additional functionality of DX cluster commands, someone is going to have to set up a DX cluster and dedicate it to SOTA feeds.
A fork in the road.
Dave
N5XL
In reply to N5XL:
How do we donate for your time?
Kent
SM/K9EZ
In reply to N5XL:
I agree Dave. Andy (as usual) has done a brilliant job here. If we get the extra bells and whistles then its a bonus - but not essential.
73 Phil G4OBK
In reply to G4OBK:
Time for a status update.
There is a very simple cluster running that a group of alpha testers have been using. It is dumb (oh is it dumb), in that it takes spots from SOTAwatch and outputs them in “cluster format” to anyone who has connected. I’ve had reports back that it’s working with Logger32, xdx, DX4WIN, Band Master and MacLoggerDX. It doesn’t work with HRD and due to the decisions made by HRD’s author it’s unlikely I’ll have time to add support for HRD within any realistic timescale.
There are still two bugs I want to fix. Both these are threading issues (fellow programmers will understand) but they have become considerably less frequent since I made some more changes. However, they still exist and do need fixing.
So my next plan is to roll out testing to more people. There will be a limited number of logins available and it will be first come first served. I’ll publish the connection details later today/tomorrow. Alpha testers should continue to use the details they know not the new ones. With some more load I’m hoping to get to the bottom of the bugs and then we can have a wider rollout.
Eric KU6J’s idea of using a real high performance freeware cluster driven by our own feed is an interesting idea and in the end may prove to be a better solution. There are some simple reasons for not progressing with this right now. Firstly I was actually writing some code for work (multithreaded socket sever) that has some similarities to what is in this cluster code. I’ve been able to write some of what we needed and get paid for it, getting paid to write amateur code is too sweet to pass up! Secondly, the cluster sofwtare Eric found runs on Windows/C# and I don’t have any available hardware free. Maybe, just maybe, it could be run on the same hardware our SOTA database runs on. But we’ve seen the problems we had over the summer when the server was very heavily loaded. It’s running well on the new hardware and has gained Maserati performance compared to before. I don’t want to adversely affect that performance gain TBH. The cluster I’ve produced is written in Python and runs on anything. I’ve tested versions running on Win7, Linux x86. Currently the server is a Linux amd64 virtual machine in a datacentre in Iceland.
To run the full cluster will need a Windows machine with a suitably reliable power feed and internet feed. Virtual low end Linux machines are pennies as there’s no software license fees, it’s why I have a several around the world. Windows machines tend to need more resources and so cost more to buy/run/rent. There is a chance the Windows/C# code will run on Linux with some software called Mono as that replicates the C# support missing from Linux. I haven’t got time to investigate that now but it could be valuable to know. If anyone wants to get involved in these possible solutions then get in touch.
Thanks for the feedback from the alpaha testers, without you etc. etc. Some have been hugely helpful with their serious testing and also very supporttive with encouraging comments.
Thank you for plaudits as well. This kind of software is not hard to write, it’s just like Lego really. All I’ve done is clip together something out of all the basic building blocks floating about out in cyberspace!
Fun time over, back to USB3 virtualisation 
Andy
MM0FMF
In reply to MM0FMF:
Although I lack understanding of the technical discussion, I have been following this thread with interest. After reading the whole thing again today, I have now decided that I actually understand less than I thought I did!
In order to clarify things in my mind, and perhaps for the benefit of others, I have a few questions that will hopefully result in yes/no type answers.
Is the perceived benefit merely to allow users of various logging programs to “point and click” spotted SOTA activations?
Is SOTAcluster intended to replace the existing SOTAwatch eventually?
Will the existing SMS and RBNgate spotting functions continue?
Will SOTAwatch and SOTAcluster contain and promulgate the same data, or will both have to be monitored to gain the full picture?
Will SOTAcluster monitor the normal DXcluster network for spots containing the keyword “SOTA”, or will this be achieved via RBNgate?
As I have already expressed concerns about the behaviour of some chasers following a SOTAwatch spot, I worry that “point and click” functionality will merely make it easier for the lids out there.
73 de Les, G3VQO
In reply to G3VQO:
Answers in line:
- Is the perceived benefit merely to allow users of various logging programs to “point and click” spotted SOTA activations?
Yes, primarily logging into personal logging programs.
- Is SOTAcluster intended to replace the existing SOTAwatch eventually?
Absolutely not. SOTAwatch is the primary source of data. The spots on SOTAcluster come from SOTAwatch only. You cannot spot from SOTAcluster, it’s read only.
- Will the existing SMS and RBNgate spotting functions continue?
Yes, they are separate systems. They, along with normal spotting feed SOTAwatch. SOTAcluster retransmits SOTAwatch spots in a different format.
- Will SOTAwatch and SOTAcluster contain and promulgate the same data, or will both have to be monitored to gain the full picture?
They will have the same data (maybe a minute or 2 delay between them)
- Will SOTAcluster monitor the normal DXcluster network for spots containing the keyword “SOTA”, or will this be achieved via RBNgate?
No.
Andy
MM0FMF
In reply to MM0FMF:
Thanks Andy.
In reply to G3VQO:
To give everyone an idea of what this looks like, here is a screen capture of my logbook display which shows one of the many ways people can use the data that Andy’s SOTA cluster is generating.
The two small circles towards the middle left of this picture (light blue and red) show that I am connected to two separate “DX Clustersâ€. The blue circle is my normal DX cluster connection and it outputs DX spots in the window below (areas that I have boxed off in light blue is the output I see from this particular DX cluster…in this particular example is it populated with CW skimmer spots). The red circle is Andys SOTA cluster. Its output also shows up in the window below, intermixed with all of the other DX spots. Because I want to see both DX spots and SOTA spots in the same window and because I want to call attention to the SOTA specific information, I have customized the Andy’s SOTA cluster spots to appear as a reddish color to stand out from the other data. With a quick glance I can now tell SOTA traffic from regular DX traffic.
As I am sitting at my operating desk and I glance over to my log screen, I can see that Tom, M1EYP is on the air and making a SOTA activation of G/CD-004 (circled in red). I can also see several other activators out and about too (OK2BTK/P, S57MS/P). I click on Tom, M1EYP’s entry in the DX spots window and instantly, several things happen. First, Tom’s information populates other parts of my log screen. Using automatic callsign lookup in Logger32, Toms address pops up in the ADIF lookup box and I can see Toms mailing address should I need to send him a paper QSL. Since Tom is a LOTW user (the small orange box to the far left of his callsign in the DX spot window tells me this), I don’t have to worry about a paper QSL. If I can make contact with Tom on his activation, once I upload my log information to LOTW (and he does the same), we get automatic confirmation of the QSO…which is very hand should we need each others contact for DXCC purposes. A couple of other things happened when I clicked on Tom call. My radio (Elecraft KX3) is hooked up to the same computer running the logging program. When I clicked on Toms call, the KX3 switched band, frequency and mode over to where Tom is transmitting. Within a second, I am now listening for Tom and if conditions are good enough, I’ll be hearing his SSB transmission.
Tom is on 12 meters but unfortunately the band is not open just yet to Arizona from England, so no contact is made. I now click on OK2BTK/P (Petr) and the KX3 jumps instantly to 20 meters where I might have a better chance of hearing him. I can hear stations working Petr but I cant hear him so unfortunately, no contact is made there either. I could try S57MS/P on 40 meters, but the chances of me hearing Marko with my antenna system means its not likely, but I listen anyway. I click on Marko’s call and I’m now instantly on 40 meters listening to huge S9 static crashes from distant lightning storms. Doesn’t look like I’ll be able to work Marko today.
All three of these attempts have happened in a time frame of less than 20-30 seconds and I’ve not had to touch my radio or logbook. Had I been successful with any of these attempts, logging would have taken seconds.
Everyone should understand that none of this amazing work has changed any of the existing SOTA tools, websites or any of the SOTA policies that we already have. None of this impacts the existing DX cluster network so no problems are created there either. What Andy has done is to create a basic way for those of us with advanced logging programs a new way to track SOTA spots and make rig control and logging SOTA contacts much easier.
I know some reading this post are rolling their eyes at why anyone would want this but remember, its entirely your choice if you want to use this kind of functionality. Nobody will force you to use it and you don’t have to use it to successfully participate in SOTA. Its just another tool to have should you want it.
Dave
N5XL
In reply to N5XL:
I have also been using SOTA cluster spots with my DX4WIN logging program. For a few days I merged SOTA spots with VE7CC DX cluster spots but have since dropped the VE7CC spots. The DX cluster generates 5-10 DX spots per minute on average depending on time of day, etc. Any of the SOTA spots would quickly scroll off the DX spots window and I would miss the SOTA spots. So I’m back to using a dedicated SOTA log plus only showing SOTA spots in my spots window. There’s not enough SOTA spot traffic and my spot window easily holds 15-20 spots. Plenty of room for an hour or more of SOTA spots. Plus I can filter out any bands or modes.
Plus having a dedicated SOTA log allows me to easily output a day’s SOTA qsos and with a little massaging in excel, I quickly have a log that I can bulk upload. I’m currently writing a Python script to do what Excel does for me.
Just a double click on the spot populates my qso window and changes my rig to the freq/mode, and an enter key then logs the qso. Cool! At the end of the day, I generate a report for the days SOTA qsos and bulk upload to the SOTA database.
Much easier/better than the logging into the SOTAdatabase each SOTA chaser qso as it occurred.
Thanks Andy! Guy/N7UN
There are a limited number of beta testing connections available if you want to try this cluster.
addr = elgur.dyndns.org
port = 7300
Set your keep alive timer to somewhere in the range of 10 to 15 minutes. Login when prompted with your callsign. Once the limit is reached, no more beta connections are accepted and an error message is printed. You will have to wait till someone disconnects or the software is restarted.
Connections for the alpha testers are not limited.
Andy
MM0FMF
In reply to MM0FMF:
The Cluster machine went offline this morning for a short period but the Cluster is running now. I spent some time last night trying to get to the bottom of 2 deadlocks that cause it to lockup. I think I have resolved one and have a solution for the other. There maybe some short interruptions to service and a few restarts over the coming evenings as I finally try to nail these obstinate bugs.
Andy
MM0FMF
In reply to MM0FMF:
I got a moment to try and sort out the SOTA cluster and all hell breaks loose at work and at the datacenter. I thought I had a fix to one of the issues, I didn’t but found I couldn’t connect at all. This was due to a DDOS (distributed denial of service) attack at a website hosted in the same datacentre. Followed by multiple reboots of the servers. Grr!
By the time the datacentre was running OK, I’d made some changes, didn’t want to go back to old software and had some customer issues to resolve in a hurry at work. It never rains… Anyway today I think I have sorted the lockups. It took numerous attempts and I apologise to those people who were trying to use the cluster for the frequent outages.
I’d like to think the socket handling algorithm is now correct and devoid of deadlock opportunities. We shall see.
Andy
MM0FMF
In reply to MM0FMF:
Hi Andy
The cluster is running well this morning. I noticed a few hickups over the last day or so and I thought you were doing some engineering work. Thanks for your efforts. The SOTA cluster is a real boon.
73 Phil
In reply to G4OBK:
The address used to connect to the cluster is changing. This is because Dyn.org are closing down the free dynamic DNS service they have been offering for the last 15years. I’ve been using it without issue for 9 years but recently they’ve decided to monetise their service.
So the new connection details for the cluster are:
addr = elgur.dtdns.net
port = 7300
Please, set your keepalive rate to no more than once every 15mins.
These details are active now. The old address will work until Dyn.org shuts down their free service on May 7th 2014. Change your connection details sooner rather than later.
Andy
MM0FMF
In reply to MM0FMF:
Thanks Andy, the service you provide is extremely useful. A pint (or a half litre) is coming your way at the Friedrichshafen Ham Radio SOTA lunch.
73 Phil
In reply to MM0FMF:
If anyone is trying to connect to the SOTA cluster using PuTTY then set the protocol to Raw and not Telnet. PuTTY being a good piece of software implements the Telnet protocol properly. However, as I am a lazy oaf, I don’t implement Telnet properly. Thus PuTTY (in Telnet mode) and the cluster do not get on. In Raw mode, they’re fine.
Andy
MM0FMF
In reply to MM0FMF:
Can I remind anyone using this cluster feed that the old hostname will die soon when the DynDNS free service stops being free. I have already deleted the auto update client from all my machines that were using DynDNS services. I’m now using dtdns as a dynamic DNS service. I’m impressed enough by their services that I think I’ll push the boat out and send them $5 for their lifetime services rather than just leach the free service.
Please update any clients you may have to use the following details.
addr = elgur.dtdns.net
port = 7300
Andy
MM0FMF
In reply to MM0FMF:
Sorry for the lack of service tonight (Thursday).
I noticed my cluster console drop out earlier tonight and I couldn’t reconnect. The server was running when I VNC’d in. I wasn’t sure if this was a network issue to the datacentre in Iceland or what and the hosting company did report IPv6 issues.
After a while I tried the age old IT trick for fixing problems… I turned it off and on again. Bingo! Everything working. I’ll put this down to flakeyness in the virtual network.
It’s up and running now.
Andy
MM0FMF
In reply to MM0FMF:
There will be a short outage on the SOTA Cluster and the SMS spotter on Wednesday 16th July between 0800Z and 1200Z. The hosting company is doing some upgrades and maintainence work. The outage should not be longer than 30mins during that period although there could be some throughput limits which may slow things down a little.
Andy
MM0FMF