NavList:

   

Reply

I applied my sight reduction simulator to the HO 211 ("Ageton") method.
Altitude accuracy (square root of the mean squared error) was 1.2
minutes and azimuth accuracy was 2.7'. About 95% of the altitudes were
within .8' of the truth. The worst altitude was 29.6' off.

It's well known that HO 211 becomes increasingly inaccurate in azimuth
as the body approaches exactly east or west. The worst azimuth error I
found was 95.7', at (correct) azimuth 271°35.7'. However, errors that
bad were rare; only .01% of azimuth errors exceeded 1°. The worst errors
always occurred at high altitudes. If max altitude was restricted to 60°
(vs. my normal limit of 80°), max azimuth error was 55'.

The possibility of an occasional poor altitude is not so well known. For
example, my program flagged this as bad: latitude = +10°39.4', LHA =
90°39.0', and declination = +40°12.0'. Work it by hand.

       2.8  A(t) (t = 90°39.0')
+ 11702    B(dec) (dec = 40°12.0')
---------
   11704.8  A(R)

   19013    A(dec)
- 19013    B(R)
-------
       0    A(K) (K = 90°00')

   90 00.0  K
- 10 39.4  lat
---------
   79 20.6  K - lat

   19013    B(R)
+ 73294    B(K-lat)
-------
   92307    A(h) (h = 6°50.5)

The correct h is 6°21.8'.

Note that angle K is somewhat indeterminate because A(K) isn't even
known to the nearest tenth, and 11 entries in the table (90°00' through
90°05') have an A value of 0.0.

I suspect that K very near zero is a warning of poor altitude accuracy,
though I haven't worked additional problems to confirm it.


This wasn't as easy as the slide rule simulations. For HO 211 I had to
simulate a table with entries every .5' and values of A and B rounded to
the nearest integer, except that small values are rounded to the nearest
tenth. My simulated navigator always picked the closest table entry but
did not interpolate.

The simulated latitudes were from 0 to 70 and altitudes from 5 to 80. As 
before, the random latitudes and altitudes were weighted so the density 
of points on the sphere would tend to remain constant instead of 
increasing near the pole and zenith.

I configured the program to generate 500,000 problems per run. Why not a
million? Short attention span. Half a million run fast enough that I can
stare at the screen waiting for results without becoming impatient.

-- 



--~--~---------~--~----~------------~-------~--~----~
Navigation List archive: www.fer3.com/arc
To post, email NavList@fer3.com
To , email NavList-@fer3.com
-~----------~----~----~----~------~----~------~--~---

   

Reply