With the increasing interest in long distance SOTA, especially transatlantic, I think it is perhaps time to take another look at the distance/bearing calculations on SOTAwatch. I don’t know what formulae are used but the answers are fairly hopeless for long distances. For example I looked at the bearing from the UK to Carolyn’s proposed summit in W5, and was told 218 degrees. In fact the correct bearing is more like 305 degrees - a huge difference if you’re pointing a beam. The distance is also way out, though that has less drastic consequences.
It would surely be better to remove this facility than give wrong answers. However I don’t think the formulae for a spherical earth approximation are very complicated, and this would surely be good enough. I’ve no idea what it can be using now - possibly a flat earth model. Or maybe it’s just a coding error!
It would surely be better to remove this facility than give wrong
It’s nevertheless a very useful tool for VHF operation. If it
can be made accurate at inter-continental range, well and good,
but if this is not practical, wouldn’t it be better to retain it
and state it’s limitations - say give a maximum useable distance?
Let’s be realistic. V/UHF uses very narrow beams, for them the current feature is fine. HF beams by comparison are as wide as barn doors, and there are few HF users that don’t have a great circle map pinned to their wall. The only band where it might be a problem is six metres, where some users have fairly narrow beams, and it remains to be seen if six will give us any F2 openings in cycle 24 but the current facility is reasonable for one or two hop Es.
At some point it will be nice to have something more accurate but at present there are jobs with a higher priority.
Let’s be realistic. V/UHF uses very narrow beams, for them the current
feature is fine.
I don’t think that argument works. The narrower the beam, the more accurate you need to be.
HF beams by comparison are as wide as barn doors
Well perhaps, but 90 degrees out is fairly serious.
there are few HF users that don’t have a great circle map pinned to
The system I was using sets the beam heading on a digital readout, and there wasn’t actually a map to hand. Hence I wanted to arm myself with a number.
Fully understand if the effort to fix it isn’t available, but there’s no merit in trying to make a virtue of the error! A warning that the answers are likely to be wildly wrong over large distances might be a good idea.
But what is the error at typical V/UHF ranges of a few hundred
kilometres, compared with the beamwidth?
Since I don’t know which incorrect formula has been used, it is futile to speculate, and a bit tedious to experiment. The size of the error is likely to depend on the latitude, and whether the general direction is N-S or E-W.
From my QTH the error for Ben Nevis is about 4 degrees and Snowdon about 3. So indeed not much, but it wasn’t short distance VHF paths I was complaining about. Whilst it may well be true that HF DXers should have a Great Circle map, I could equally well say that VHF/UHF chasers should have a pretty good idea of the general direction of “local” hills.
One thing I did notice in the testing I did is that the bearing given by SOTAwatch is, in all the examples I looked at, remarkably close to the FINAL bearing of the great circle path at the point at which it reaches the summit site. IOW, if you add 180 degrees, you get the correct back bearing to the chaser! This may be pure coincidence, but it may indicate that a plausible formula has been used but with start point and end point mixed up in some way. If true, this ought to be very easy to fix.
The distance for DX is still way out though. For example it puts the Falklands less than 9000km away from the UK, but actually it’s more like 12800km.
Falklands less than 9000km away from the UK, but actually it’s more
Without checking the numbers must be a bug in the program. The spherical trigonometry is not that difficult. The distance is basically the angle between UK and Falkland on the great circle going through these two points times the radius of (spherical) Earth.
No mention is made in the code of which geoid is used in the calculations, but a quick search online shows that it is in fact the International Astronomical Union 1976 ellipsoid, so should be accurate enough for SOTA.
The code - which is basically a copy of many examples to be found online - is simple enough to be rewritten in practically any programming language so should be adaptable for the SOTA abacus.
The link given above by Rob looks helpful and I’ll take a look
I suspect that the formulae for a sphere are more than adequate for this purpose. They can be found in lots of places. If the language you are writing in has trig functions of reasonable precision available they should be straightforward to code up. You can find sample code fragments online for many languages.
Some of the formulae can become numerically unstable at very short distances but that is unlikely to be a problem unless people deliberately provoke it. The other degenerate case to watch out for is the antipodal point, where the bearing becomes indeterminate.
Can we live with it as it is for a little while or should I apply fix