Re: GPSMAP 60Cx or 76Cx?

Wolfgang S. Rupprecht wrote:
Terje Mathisen <terje.mathisen@xxxxxxxxxxxxx> writes:
Wolfgang, I agree. OTOH it is still one more decimal than any other
external format Garmin have used previously. For my 76S
WAAS/EGNOS/ESTB tests last year I had to write my own sw to download
the semi-circle format binary values directly, having 10-cm level info
directly available is _nearly_ as good.

The semi-circles are nice aren't they? They roll around at
automatically 360-degrees without having to explicitly clip them and
they don't waste any bits by not having any huge unused bit patterns.
I just wish someone would write a set of trig routines for them.

I'm almost certain you can find those, possibly even inside open source trig libs:

If you want to do trig "right", then you probably want to return exact (i.e. correctly rounded) results for all possible inputs: This requires you to do range reduction with a value for pi which is accurate to more than 1024 bits (which is the range of the exponent in IEEE double precision).

The only really good way to do this is by converting, at least temporarily, to semi-circles by multiplication by an array of values that add up to 1/(2*pi) (possibly scaled by a power of two).

Doing this will then convert the input to a floating point number where the fraction is identical to the Garmin trig format, and the integer part can be discarded. Using the top 3 fractional bits to determine the relevant octant of the circle, the remainder can then be used more or less directly in a Cheby polynomial to calculate sin/cos/tan. The scale factor to convert from semi-circles back to radians can instead be pulled into the individual polynomial terms. :-)

(BTW, there is one good reason for working in radians for sin/cos: It is possible to modify the normal Cheby poly to force the first term to be the same as for the Taylor series, i.e. 1.0, which makes it easier to achieve near-perfect accuracy.)

One thing I noticed long after doing tests on a 12xl and oncore m12
was that I was seeing quite a bit of error that reoccured roughly once
per 24hrs. After pondering this for a day it hit me to try to line up
the peaks and get a good handle on the amount of shift each day.
Turned out to have a very very high correlation for 23hrs 56minutes.
(At this point all the astronomers are probably jumping in their
seats. Me I'm just a hardware jock turned code geek so it took a
while for the significance of that number to sink in.)

<BG>

Did you not see a significant term at half that period, i.e. 11:58? This is the GPS sat period, so the constellation should repeat with this period, but over just a few weeks, the day/night difference will probably make one of the error peaks much more noticeable than the other?

Terje

--
- <Terje.Mathisen@xxxxxxxxxxxxx>
"almost all programming can be viewed as an exercise in caching"
.

Relevant Pages

  • Re: GPSMAP 60Cx or 76Cx?
    ... external format Garmin have used previously. ... I just wish someone would write a set of trig routines for them. ... The only really good way to do this is by converting, at least temporarily, to semi-circles by multiplication by an array of values that add up to 1/. ... This is the GPS sat period, so the constellation should repeat with this period, but over just a few weeks, the day/night difference will probably make one of the error peaks much more noticeable than the other? ...
    (sci.geo.satellite-nav)
  • Re: Constants, Variables, data types, and intrinsic functions??
    ... things like Cos, Sin, Atn for trig and Trim$, Format$ and ...
    (microsoft.public.vb.general.discussion)
  • Re: Memory Map Categories
    ... all the trig points in the UK, is there a way to import them all straight ... In what format is your list of trigpoints before importing them?. ... parameter) for each Mark. ... assuming a unique positional context could be established for that parameter. ...
    (uk.rec.walking)