Robert Jordens wrote:
> Downloading from garmin does not cause the high CPU load I was
I never received a complaint about this, but I'm assuming you're giving
a nod to this change:
----------------------------
revision 1.18
date: 2004/11/01 17:34:28; author: robertl; state: Exp; lines: +1 -1
On UNIX, there's no reason to spin on the select. Wait at least a character
time before looking again.
----------------------------
> <bounds minlat="-286276469720.843139648" minlon ="9999.000000000"
> maxlat="46404771532.667770386" maxlon="634281368307.067993164" />
> <wpt lat="46184670052.667800903" lon="634281368133.769653320">
> <ele>9999999562023526247432192.000000</ele>
> <cmt>c^P</cmt>
> <desc>c^P</desc>
> <sym>Waypoint</sym>
> </wpt>
Garmin "serial protocol" is actually a collection of about 17 marginally
unrelated (sigh) protocols. What GPS (and what firwmare version) is
this?
> (gdb) run
> Starting program: /home/rj/work/debian/jgoerzen/gpsbabel-1.2.5/gpsbabel -r -i
> garmin -f /dev/ttyS0 -o gpx -F r.gpx
>
Let's start with waypoint read, then proceed to route read and track read.
It looks like things are basically working. There's probably some
word sizing problem somewhere in the serial code.
If your unit has a couple of waypoints in it, show me the output of
gpsbabel -D9 -i garmin -f /dev/ttyS0
Extract just the first dozen or so once it gets into the highly
repetetive stuff if your unit has many waypoints in it.
Then we'll proceed to tracks.
gpsbabel -D9 -t -i garmin -f /dev/ttyS0
And then to routes
gpsbabel -D9 -r -i garmin -f /dev/ttyS0
Sadly, they're all three different protocols in Garmin-land, so it won't
shock me if they're three different fixes... I just want to tackle them
in increasing complexity.
RJL
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
