Thread: [Gpsbabel-misc] gpsbabel <->gardump data?
Brought to you by:
robertl
From: paul b. <pau...@gm...> - 2008-08-12 16:27:35
|
new subscriber, and I am on digest so if you reply I may not read it right away. I am trying to work out getting data into and out of a Garmin eTrex on FreeBSD 6. I successfully (?) used garmin-utils/gardump to get a lot of data off of it. But I don't know how to tell gpsbabel what kind of data it is so it can munge it into something useful. And as many have noted gpsbabel is having some issues with the serial port. I can work that with the port's maintainer, but I can handle dumping with gardump and doing post processing with gpsbabel -- if only I can find out how to. This is the head of the file gardump creates: [gardump version 2.5] [product 295, version 351: eTrex Software Version 3.51] [tracks, 2928 records] # [Track: track name] # [yyyy-mm-dd hh:mm:ss] lat long [alt] [start] Track: ACTIVE LOG 2007-04-15 21:36:56 47.740574 -122.285324 -16.685791 start 2007-04-15 21:37:09 47.740273 -122.284866 6.385864 2007-04-15 21:37:14 47.740273 -122.284866 5.424561 2007-04-15 21:37:25 47.740273 -122.284889 8.308594 -- Paul Beard / www.paulbeard.org/ <paulbeard.org> |
From: Robert L. <rob...@gp...> - 2008-08-12 16:59:19
|
On Tue, Aug 12, 2008 at 11:27 AM, paul beard <pau...@gm...> wrote: > new subscriber, and I am on digest so if you reply I may not read it right > away. > I am trying to work out getting data into and out of a Garmin eTrex on > FreeBSD 6. I successfully (?) used garmin-utils/gardump to get a lot of > data off of it. But I don't know how to tell gpsbabel what kind of data it > is so it can munge it into something useful. > We have no explicit support for the format you're describing. > And as many have noted gpsbabel is having some issues with the serial port. > The only problem I know of is that broken USB/serial adapters that lose data don't recover with retries. > I can work that with the port's maintainer, but I can handle dumping with > gardump and doing post processing with gpsbabel -- if only I can find out > how to. > > This is the head of the file gardump creates: > > [gardump version 2.5] > [product 295, version 351: eTrex Software Version 3.51] > [tracks, 2928 records] > # [Track: track name] > # [yyyy-mm-dd hh:mm:ss] lat long [alt] [start] > Track: ACTIVE LOG > 2007-04-15 21:36:56 47.740574 -122.285324 -16.685791 start > 2007-04-15 21:37:09 47.740273 -122.284866 6.385864 > 2007-04-15 21:37:14 47.740273 -122.284866 5.424561 > 2007-04-15 21:37:25 47.740273 -122.284889 8.308594 > If this is something that's not worth doing well, you could just trim the headers and create a style file to read it. $ cat pb.style # DESCRIPTION gardump SHORTLEN 8 # # # FILE LAYOUT DEFINITIIONS: # FIELD_DELIMITER SPACE RECORD_DELIMITER NEWLINE # # INDIVIDUAL DATA FIELDS, IN ORDER OF APPEARANCE: # DATATYPE TRACK IFIELD GMT_TIME,"","%Y-%m-%d" IFIELD HMSG_TIME,"","%H:%M:%S" IFIELD LAT_DECIMAL, "", "%08.5f" IFIELD LON_DECIMAL, "", "%08.5f" IFIELD ALT_METERS, "", "%08.5f" $ ./gpsbabel -i xcsv,style=pb.style -f pb.data -o gpx -F - <?xml version="1.0" encoding="UTF-8"?> <gpx version="1.0" creator="GPSBabel - http://www.gpsbabel.org" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.topografix.com/GPX/1/0" xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd"> <time>2008-08-12T16:55:18Z</time> <bounds minlat="47.740273000" minlon="-122.285324000" maxlat="47.740574000" maxlon="-122.284866000"/> <trk> <trkseg> <trkpt lat="47.740574000" lon="-122.285324000"> <ele>-16.685791</ele> <time>2007-04-15T00:00:00Z</time> </trkpt> <trkpt lat="47.740273000" lon="-122.284866000"> <ele>6.385864</ele> <time>2007-04-15T00:00:00Z</time> </trkpt> <trkpt lat="47.740273000" lon="-122.284866000"> <ele>5.424561</ele> <time>2007-04-15T00:00:00Z</time> </trkpt> <trkpt lat="47.740273000" lon="-122.284889000"> <ele>8.308594</ele> <time>2007-04-15T00:00:00Z</time> </trkpt> </trkseg> </trk> </gpx> You could improve that import template to ignore the headers. If you really do have multiple tracks in there and need to preserve them, you could trivially write a "real" GPSBabel module to handle them. But if Gardump is as abandoned as I recall it is and you're doing this to circumvent some problem with your system/configuration with GPSBabel on it, it's probably worth tackling it head-on instead... RJL |
From: paul b. <pau...@gm...> - 2008-08-12 17:20:04
|
On Tue, Aug 12, 2008 at 9:59 AM, Robert Lipe <rob...@gp...> wrote: > > > On Tue, Aug 12, 2008 at 11:27 AM, paul beard <pau...@gm...> wrote: >> >> new subscriber, and I am on digest so if you reply I may not read it right away. >> I am trying to work out getting data into and out of a Garmin eTrex on FreeBSD 6. I successfully (?) used garmin-utils/gardump to get a lot of data off of it. But I don't know how to tell gpsbabel what kind of data it is so it can munge it into something useful. > > We have no explicit support for the format you're describing. > It's not a new format, but I infer that it's not a Garmin format, rather one devised by the guy who wrote garmin-utils? >> >> And as many have noted gpsbabel is having some issues with the serial port. > > The only problem I know of is that broken USB/serial adapters that lose data don't recover with retries. > >> >> I can work that with the port's maintainer, but I can handle dumping with gardump and doing post processing with gpsbabel -- if only I can find out how to. >> This is the head of the file gardump creates: >> [gardump version 2.5] >> [product 295, version 351: eTrex Software Version 3.51] >> [tracks, 2928 records] >> # [Track: track name] >> # [yyyy-mm-dd hh:mm:ss] lat long [alt] [start] >> Track: ACTIVE LOG >> 2007-04-15 21:36:56 47.740574 -122.285324 -16.685791 start >> 2007-04-15 21:37:09 47.740273 -122.284866 6.385864 >> 2007-04-15 21:37:14 47.740273 -122.284866 5.424561 >> 2007-04-15 21:37:25 47.740273 -122.284889 8.308594 > > If this is something that's not worth doing well, you could just trim the headers and create a style file to read it. > Now that -- "If this is something that's not worth doing well" -- is a phrase I will be re-using . . . > > $ cat pb.style > # > DESCRIPTION gardump > SHORTLEN 8 > # > # > # FILE LAYOUT DEFINITIIONS: > # > FIELD_DELIMITER SPACE > RECORD_DELIMITER NEWLINE > > # > # INDIVIDUAL DATA FIELDS, IN ORDER OF APPEARANCE: > # > DATATYPE TRACK > IFIELD GMT_TIME,"","%Y-%m-%d" > IFIELD HMSG_TIME,"","%H:%M:%S" > IFIELD LAT_DECIMAL, "", "%08.5f" > IFIELD LON_DECIMAL, "", "%08.5f" > IFIELD ALT_METERS, "", "%08.5f" > > $ ./gpsbabel -i xcsv,style=pb.style -f pb.data -o gpx -F - > <?xml version="1.0" encoding="UTF-8"?> > <gpx > version="1.0" > creator="GPSBabel - http://www.gpsbabel.org" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns="http://www.topografix.com/GPX/1/0" > xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd"> > <time>2008-08-12T16:55:18Z</time> > <bounds minlat="47.740273000" minlon="-122.285324000" maxlat="47.740574000" maxlon="-122.284866000"/> > <trk> > <trkseg> > <trkpt lat="47.740574000" lon="-122.285324000"> > <ele>-16.685791</ele> > <time>2007-04-15T00:00:00Z</time> > </trkpt> > <trkpt lat="47.740273000" lon="-122.284866000"> > <ele>6.385864</ele> > <time>2007-04-15T00:00:00Z</time> > </trkpt> > <trkpt lat="47.740273000" lon="-122.284866000"> > <ele>5.424561</ele> > <time>2007-04-15T00:00:00Z</time> > </trkpt> > <trkpt lat="47.740273000" lon="-122.284889000"> > <ele>8.308594</ele> > <time>2007-04-15T00:00:00Z</time> > </trkpt> > </trkseg> > </trk> > </gpx> > > > > You could improve that import template to ignore the headers. If you really do have multiple tracks in there and need to preserve them, you could trivially write a "real" GPSBabel module to handle them. > > But if Gardump is as abandoned as I recall it is and you're doing this to circumvent some problem with your system/configuration with GPSBabel on it, it's probably worth tackling it head-on instead... I'm not sure it's abandoned so much as at equilibrium. I would just as soon use GPSBabel if I could get to to work but the inability to connect to serial ports[*] is holding that up. * http://www.nabble.com/gpsbabel-1.3.0-hangs-whilst-connecting-to-Garmin-eTrex-on-OpenBSD-td5450271.html -- Paul Beard / www.paulbeard.org/ <paulbeard.org> |
From: Robert L. <rob...@gp...> - 2008-08-12 17:43:02
|
> > We have no explicit support for the format you're describing > > It's not a new format, but I infer that it's not a Garmin format, > rather one devised by the guy who wrote garmin-utils? > It's not a Garmin format. > Now that -- "If this is something that's not worth doing well" -- is a > phrase I will be re-using . . . > "Not all things worth doing are worth doing well." is a good engineering adage to remember. > as soon use GPSBabel if I could get to to work but the inability to > connect to serial ports[*] is holding that up. > > * > http://www.nabble.com/gpsbabel-1.3.0-hangs-whilst-connecting-to-Garmin-eTrex-on-OpenBSD-td5450271.html [ blink ] Ok, so I promised a lead. The port lockup happens after you hit ^C while downloading with gardump (e.g. in the middle of downloading a long track). After that if you try to download using gpsbabel or gpstrans the software locks up while trying to open the port. gardump is happy to As I said in that thread, if killing one program that has a port open leaves the port in a state where it's not usable to other programs, that's a serial driver problem; there's not much that an application can do about that. I don't know how many OpenBSD users we have. It's non-zero but it's not a huge number by the percentages. We do have a few active OpenBSD guys on -code. We do have a reasonable following of serial Garmins on Mac and Linux, both of which use the same code path as OpenBSD for us. I won't say stupid things like "our code is blameless", but we don't exactly have users storming the gates about this on those OSes. The symptoms described above sure sound like an OS driver bug to me. I get that might not be terribly helpful to you. :-) But if you can find an OpenBSD kernel dude that wants to disagree on why open(2) works differently depending on who has been on the port first, send 'em my way. I'd really like it to be reliable and useful there. RJL P.S. If the trigger really is "hangs after I abort gardump", then I get to evoke another engineering adage: "Don't do that." :-) |
From: paul b. <pau...@gm...> - 2008-08-12 18:12:57
|
On Tue, Aug 12, 2008 at 10:43 AM, Robert Lipe <rob...@gp...> wrote: > >> > We have no explicit support for the format you're describing >> >> It's not a new format, but I infer that it's not a Garmin format, >> rather one devised by the guy who wrote garmin-utils? > > It's not a Garmin format. > >> >> Now that -- "If this is something that's not worth doing well" -- is a >> phrase I will be re-using . . . > > "Not all things worth doing are worth doing well." is a good engineering > adage to remember. >> >> as soon use GPSBabel if I could get to to work but the inability to >> connect to serial ports[*] is holding that up. >> >> * >> http://www.nabble.com/gpsbabel-1.3.0-hangs-whilst-connecting-to-Garmin-eTrex-on-OpenBSD-td5450271.html > > [ blink ] > > Ok, so I promised a lead. The port lockup happens after you hit ^C while > downloading with gardump (e.g. in the middle of downloading a long > track). After that if you try to download using gpsbabel or gpstrans the > software locks up while trying to open the port. gardump is happy to > As I said in that thread, if killing one program that has a port open leaves > the port in a state where it's not usable to other programs, that's a serial > driver problem; there's not much that an application can do about that. > > I don't know how many OpenBSD users we have. It's non-zero but it's not a > huge number by the percentages. We do have a few active OpenBSD guys on > -code. We do have a reasonable following of serial Garmins on Mac and Linux, > both of which use the same code path as OpenBSD for us. I won't say stupid > things like "our code is blameless", but we don't exactly have users > storming the gates about this on those OSes. The symptoms described above > sure sound like an OS driver bug to me. > > I get that might not be terribly helpful to you. :-) But if you can find an > OpenBSD kernel dude that wants to disagree on why open(2) works differently > depending on who has been on the port first, send 'em my way. I'd really > like it to be reliable and useful there. > I'll take it up with the FreeBSD guys, I just thought this might have been solved and I missed it ;-) > > P.S. If the trigger really is "hangs after I abort gardump", then I get to > evoke another engineering adage: "Don't do that." :-) Yeah, I have used that one myself. That doesn't seem to be the issue here. I can let gardump run to completion and still see this. Not sure how I unlock the driver's grip w/ rebooting (what is this? Windows?). Thanks. -- Paul Beard / www.paulbeard.org/ <paulbeard.org> |