Re: [Gpsbabel-misc] gpx to garmin

[Robert L. <rob...@us...>]

Gary Paulson wrote:
> I am noticing that when I send the cordinates to my garmin e-trex legend
> [ ... ] 
> my coordinates in the garmin are off - so that a coordinate that is

You're not the first Garmin user to observe that, but in fairness that
last digit is entering the land of fantasy on precision anyway.  Can you
tell if the problem is on reads, writes, or both?

I'm going to try to borrow a Garmin this weekend and will stare at that
a little more.


[ Questions from here down should probably go back to gpsbabel-code
since I think I recall Gary being a programmer.  In fact, people that
don't own a pocket protector are excused now... ]


> I tried to figure out how to get the -o garmin -F temp.txt - but I get an
> init error, so cannot debug that part.

You can't dump it to a file becuase it's an interactive communication
protocol.  There's a little conversation that goes something like:

PC: Is anybody there?
Garmin: Yep.
PC: What Kind of Garmin are you?
Garmin: A black one.
PC: What kind of waypoint formats do you understand?
Garmin: Klingon, Romulan, and Pig Latin.
PC: Would you like some waypoints in Romulan?
Garmin: Yep.
PC: [ waypoint in romulan ]   
Garmin: Yummy.
PC: Would you like another?
Garmin: Yep.
[ repeats until done. ] 

You can see that just directing this conversation to a file we we
wouldn't get past the first question (since the answer would both come
from and go to a file instead of a Garmin) is just sort of doomed.  The
trained eye recognizes at this point that when chasing a problem in the
conversation, one must determine which waypoint type (Klingon, Romulan,
or Pig Latin) was actually used.

But you CAN specify '-D 9' on the command line and watch every byte
coming and going in full agonizing detail.  Without a copy of the Garmin
comm spec from Garmins site, it's very painful to read.

But my gut tells me this isn't a protocol problem at all but rather a
programmer that thought he understood floating point when he doesn't.

Internally to GPSBabel, waypoints are stored as host doubles in decimal
degrees.  The GPSBabel part of this is simple.  It's the jeeps code
that has to deal with the horrors of the Garmin serial mechanics.  This
is one reason I used that code; so I wouldn't have to figure it out.
Unfortunately, that plan has been a mixed vicotry, but that's another
rant.

In gpsapp.c::GPS_A100_{Send,Get} we make the Romulan/Klingon distinction
and then call code that knows how to handle every Dxxx packet.  I think
I remember D103 on a Banana and D108 on a Vista with old firmware and
D109 with a V and and Vista with new firmware, but could be fuzzy on
that.  The punchline is that a bug in one garmin model may or may
not show on another since it's different code to handle each one.
D109_Send, as an example, has to convert our lat and lon to a semicircle
using gpsmath.c::GPS_Math_Deg_To_Semi which is one of those functions
that it's hard to "prove" correct with only eyeballs.  However, since
the Garmin manual with integer math, I've long had a suspicion that
function should change from

int32 GPS_Math_Deg_To_Semi(double v)
{
    return (int32) (((double)2.147483e9/(double)180)*(double)v);
}

to something approximately like
	return (int32) ((1U << 31) / 180) * v);

in order to keep the constant integer part of that, well, a constant
integer becuase we all know that first part is "2147483648" (don't ask
why I know these things) and not "2147483000 and a little bit".

If that holds water, GPS_Math_Semi_To_Deg should be beaten with a
similar stick.

If you can whack at that pinata a little bit on your unit, that would be
most helpful.

(I can't believe that I've just written two pages of crap describing a
*guess* for a proposed two line change.  Maybe I should go work for the
government or something...)