SOTAwatch distance and bearing calculations

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!

In reply to M1MAJ:

It would surely be better to remove this facility than give wrong
answers.

Hi,

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?

Kind regards

Dave

In reply to M1MAJ:

I’ve no idea what it can be using now - possibly a flat earth model.

What heresy is this? Of course it’s flat. Remember what happened to Galileo!

In reply to G0ELJ:

In reply to M1MAJ:

It would surely be better to remove this facility than give wrong
answers.

It’s nevertheless a very useful tool for VHF operation.

Leave it alone!
I use it all the time for initially pointing the beam in the general direction.

A very useful tool for VHF operation.

David g6lkb

In reply to G6LKB:

Leave it alone!

You mean you wouldn’t prefer it to be correct?

In reply to M1MAJ:

No he’s saying given a choice between the current inaccuracy and errors and no bearing info at all he’d prefer what he has now!

:wink:

Andy
MM0FMF

In reply to MM0FMF:

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.

73

Brian G8ADD

In reply to G8ADD:

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
their wall.

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.

In reply to M1MAJ:

In reply to G8ADD:

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.

But what is the error at typical V/UHF ranges of a few hundred kilometres, compared with the beamwidth?

73

Brian G8ADD

In reply to G8ADD:

I know the backlash in a rotator is often greater than the beamwidth of 4x 55ele Tonnas for 23cms. In fact it’s often more than the beanwidth of a single 55!

Typical 3dB beamwidth for a 3ele Yagi is about 60deg.

Andy
MM0FMF

In reply to G8ADD:

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.

In reply to M1MAJ:

Falklands less than 9000km away from the UK, but actually it’s more
like 12800km.

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.

73, Jaakko OH7BF/F5VGL

In reply to F5VGL:

must be a bug in the program.

I don’t think anybody disputes that. The discussion appears to be about whether it matters enough to be worth fixing. Personally I think it does matter, but I am not the one who has to do it.

Interesting discussion which reminded me of an article I recently read in the phpclasses newsletter about a class to calculate distances and bearings from coordinates - the class can be found at: Geo Tools: Perform calculations with geographic coordinates - PHP Classes.

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.

EDIT by the SOTA MT.
73, Rob DM1CM

In reply to M1MAJ:

I don’t dispute that it is something that needs fixing eventually, I just think that it is not a priority job, it must take its place in the queue.

73

Brian G8ADD

Hi guys, sorry not to have replied sooner.

I suspect the code was pretty crude and I did it specifically for UK VHF many, many years ago at the beginning of SOTAwatch. I would be happy to look at upgrading it.

  1. A very quick fix would be to only show the bearing for distances sub 500km or similar.

  2. The link given above by Rob looks helpful and I’ll take a look asap.

Can we live with it as it is for a little while or should I apply fix 1. quickly?

73, Jon

In reply to GM4ZFZ:

  1. The link given above by Rob looks helpful and I’ll take a look
    asap.

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

  1. quickly?

I don’t think it is urgent.

Sometime ago I found a number of routines for calculating Great Circle distances in both PHP and PERL (A search for ‘GeoCalc.php’, ‘DXbearing.pm’ might locate some of them).

I even use some on my own website that I put together myself (from various snippets of code) which can (for the time being) be found at g0lgs(dot)co(dot)uk/conversion.phps

Stewart G0LGS

Guys,

The distance and bearing errors have now been fixed for the summit page and now should be accurate for long distances.

I am indebted to Martyn MAJ for spotting errors in my code.

There is still a small issue on the summit search results being slightly out. I’ll address this shortly.

73, Jon