GPSBabel

Hi, John.

> here is a second test version of the MTK-logger

Getting really close.

There is still the issue of "read" writing files - that's, well, weird.

Please address the fixed buffer in do_send_cmd() as per last review,
doc, and testcases
and I think it's ready to go.   If we can get that in the next week or
two, we can probably make
the 1.3.5 train.  If we wait for the release after that, so be it.

Thanx!
RJL

Hello,
here is a third test version of the MTK-logger
support
for gpsbabel. Changes since last version:
 - a few bug fixes
 - removed some unnecessary stack variable
 - Updated documentation somewhat
 - Added testcase for mtk-bin parse module
 - ...

Data downloaded from the GPS logger is still saved as
temporary
'data.bin' file. This may later be processed with the
mtk-bin interface. This is the reason for opening a 
file when reading from GPS unit. 
Output files may also be created in MTK application
compatible 
.csv format.

Example usage::
   # Read from USB port, output in GPX format
  ./gpsbabel -D 2 -t -w -i mtk -f /dev/ttyUSB0 -o gpx
-F out.gpx

   # Parse an existing .bin file
(data_2007_09_04.bin), output as
   #  both CSV file and GPX
  ./gpsbabel -D 2 -t -w -i
mtk-bin,csv=data__2007_09_04.csv -f
data_2007_09_04.bin -o gpx -F out.gpx

You may also add an 'erase' flag to the command which
will perform 
a flash erase after downloading the GPS data.

  Todo:
    o ....

Two files attached, one diff with source/gpx against
current CVS version and a binary reference data blob -

this should be placed in
reference/track/mtk_logger.bin

/Per Borgentun



      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

On Jan 29, 2008 1:57 PM, John Doe <e4borgen@...> wrote:

> Hello,
> here is a third test version of the MTK-logger
> support
> for gpsbabel. Changes since last version:
>  - a few bug fixes
>  - removed some unnecessary stack variable
>  - Updated documentation somewhat
>  - Added testcase for mtk-bin parse module
>

Great.  Those were the missing pieces I needed.  I applied a few
minor tweaks after testing a PPC and x86 build on Mac (catches
endianness problems) and have committed this.  I fixed the whitespace
problem, turned on the "missing" test, and changed a stray "WBT-200"
to match the hardware in the doc.


Thanx for working through this.
RJL

Hi, and welcome

On Jan 26, 2008 5:14 PM, Franziska Simmank <franziska.simmank@...> wrote:

> ,
> I like GPSBabel for converting .loc files to .gs files for my Magellan
> Explorist. I noticed that, after converting, the description of the cache


What you're describing is known in this crowd as the alchemy problem.
You're
converting from a format that's not very smart, has multiple fields jammed
together
and such, and trying to convert it into a format that does have unique
fields for
different things.

As you can guess from the name we've given it, it's kind of hard to do this
well in
the general case. :-)

At various times, we've actually done both variations of what describe.
Both were
utlimately changed as not all the world's data is geocaches and people with
waypoints
named "by river" got annoyed when we shortened their names to (gulp) 0
bytes, for example.

The 'nuke_placer' option
http://www.gpsbabel.org/htmldoc-development/fmt_geo.html does exactly what
your first
patch does, only it's optional - it doesn't change input unless you ask for
it.

In general, we strongly discourage our writers from trying to "fix" quirks
of the readers.



Do let me say that if you want to do anything other than the simplest "send
to GPS"
functions that LOC files are a dead end.   Pocket Queries from Groundspeak
aren't
free ($3/month, $30/year) but they're a boon to programmatically
manipulating geocache
info.

RJL

On Jan 20, 2008 11:21 AM, Tom Hughes <tom@...> wrote:

> Attached is code to add support for the NaviLink protocol to GPSBabel.


Thanx for the contribution.   Looks like this is another variation of the
Sirf binary
protocol.   The implementation looks good and you've provided everything
needed
to drop it in, so thanx for making my task easier.

.Please let me know if you can see any problems with this code, and
>
I'll do my best to address them.


It looks like there's some numeric instability.  On Mac (x86 - didn't test
Power yet) it looks like the third and fourth bytes (waypoint id) jitter.
The coords
look kind of flat, too.

This may help:

./gpsbabel -i navilink -f reference/navilink_waypoints.wpt -o navilink -F  -
| hexdump -C
00000000  00 40 00 00 4d 30 30 30  00 00 00 00 9b 45 db 1e
|.@...?.|
00000010  32 96 00 00 df 00 07 09  1b 0d 25 26 00 00 00 7e
|2...?.....%&...~|
00000020  00 40 00 00 4d 30 30 30  00 00 00 00 9b 45 db 1e
|.@...?.|
00000030  32 96 00 00 df 00 07 0a  03 11 04 35 00 00 00 7e
|2...?......5...~|
00000040  00 40 00 00 4d 30 30 31  00 00 00 00 12 53 dc 1e
|.@...?.|
00000050  34 b7 00 00 00 00 07 09  1d 0e 2d 02 00 00 00 7e
|4?........-....~|
00000060  00 40 00 00 4d 30 30 31  00 00 00 00 12 53 dc 1e
|.@...?.|
00000070  34 b7 00 00 00 00 07 0a  03 11 04 35 00 00 00 7e
|4?.........5...~|
00000080  00 40 00 00 4d 30 30 32  00 00 00 00 b8 d7 d9 1e
|.@.......???.|
00000090  00 00 00 00 77 00 07 0a  03 10 04 30 00 00 00 7e
|....w......0...~|
000000a0  00 40 00 00 4d 30 30 32  00 00 00 00 b8 d7 d9 1e
|.@.......???.|
000000b0  00 00 00 00 77 00 07 0a  03 11 04 35 00 00 00 7e
|....w......5...~|
000000c0  00 40 00 00 53 55 42 57  41 59 00 00 02 e2 d9 1e
|.@......??.|
000000d0  00 00 00 00 74 00 07 0a  03 10 07 0c 00 00 00 7e
|....t..........~|
000000e0  00 40 00 00 53 55 42 57  41 59 00 00 02 e2 d9 1e
|.@......??.|
000000f0  00 00 00 00 74 00 07 0a  03 11 04 35 00 00 00 7e
|....t......5...~|
00000100

I've committed it even in this form in the hope that we can quickly iterate
down
to stability without getting tripped up in multiple overlapping patches.



> Incidentally, while developing this I ran into some problems caused by
> a combination of a linux kernel bug and the fact that gbser_posix.c
> likes to reset the read timeouts before each read from a serial port.


Yeah, they introduced that a few weeks ago and agreed to fix it.  Our
behaviour
is weird, but it's legal.  They didn't put up a fuss that changing
VMIN/VTIME (as
opposed to changing cflags) shouldn't corrupt data, but since this does seem
to
trigger a similar bug in  another serial driver (from a less responsive
vendor) we
should look into changing that.


> PS Giving the address of a mailing list that only allows posting by
> subscribers as the address for new submissions is not such a brilliant


It keeps spammers out.

It also helps get the developers involved in conversation - at least for a
little while while
the problems get  worked out as the code is exercised the first time on a
variety
of systems.  I'm more interested in contributions from folks that don't see
participating
in community as a chore than lowering the entry for "drive-by" coders.


Thanx,
RJL

In message <82a839a50801201437w37715dfbj17e1a32c3922c0f6@...>
          "Robert Lipe" <robertlipe@...> wrote:

> On Jan 20, 2008 11:21 AM, Tom Hughes <tom@...> wrote:
> 
> > Attached is code to add support for the NaviLink protocol to GPSBabel.
> 
> Thanx for the contribution.   Looks like this is another variation of the
> Sirf binary protocol.   The implementation looks good and you've provided
> everything needed to drop it in, so thanx for making my task easier.

It's a Sirf II based receiver, so that is quite likely (the newly
announced GT-31 model is Sirf III based and will I assume use the
same protocol).

> > Please let me know if you can see any problems with this code, and
> > I'll do my best to address them.
> 
> It looks like there's some numeric instability.  On Mac (x86 - didn't test
> Power yet) it looks like the third and fourth bytes (waypoint id) jitter.
> The coords look kind of flat, too.

When writing I always write the waypoint ID as zero largely because
there didn't seem anything obviously better to do - if you're writing
to the GPS unit then it ignores the ID anyway and just allocates the
next free ID to that waypoint.

I'm not aware of any issues with the coordinates beyond rounding
errors going back and forth.

> > PS Giving the address of a mailing list that only allows posting by
> > subscribers as the address for new submissions is not such a brilliant
> 
> It keeps spammers out.
> 
> It also helps get the developers involved in conversation - at least for a
> little while while the problems get  worked out as the code is exercised
> the first time on a variety of systems.  I'm more interested in
> contributions from folks that don't see participating in community as a
> chore than lowering the entry for "drive-by" coders.

I just got a bit annoyed when I got to my third attempt at submitting
the code (first time bounced as I attached the new files as a zip, and
thec second time as I wasn't subscribed)... Maybe a warning in the
README.contrib file that you need to be subscribed?

Tom

-- 
Tom Hughes (tom@...)
http://www.compton.nu/

> I'm not aware of any issues with the coordinates beyond rounding
> errors going back and forth.
>

Please do look at that hexdump.   The first of the (lat/lon) pair is zero
for most of them.  This is causing testo failures.   I'll try to get it in a

debugger soon if you don't see a cause.



> Maybe a warning in the
> README.contrib file that you need to be subscribed?
>

That's the curse of multiple doc written in different times.  I'll tweak
that.

Thanx,
RJL

In message <82a839a50801201615s45c61670mae6e08291e0ca1e4@...>
          "Robert Lipe" <robertlipe@...> wrote:

> > I'm not aware of any issues with the coordinates beyond rounding
> > errors going back and forth.
> 
> Please do look at that hexdump.   The first of the (lat/lon) pair is zero
> for most of them.  This is causing testo failures.   I'll try to get it in
> a debugger soon if you don't see a cause.

The latitudes don't appear to have zeros. The longitude values do
all have the high bytes as zero, but that's because I live about
half a mile west of the Greenwich meridian and the waypoints were
gathered locally so the longitude values are all fairly close to
zero.

Tom

-- 
Tom Hughes (tom@...)
http://www.compton.nu/

> > Please do look at that hexdump.   The first of the (lat/lon) pair is
> zero
> > for most of them.  This is causing testo failures.   I'll try to get it
> in
> > a debugger soon if you don't see a cause.
>
> The latitudes don't appear to have zeros. The longitude values do
> all have the high bytes as zero, but that's because I live about


I see this on Linux/x86 (FC7), too, so it's not just a Mac thing.

Let's take apart the last waypoint and look at the latitudes..  The
reference file contains:

e$ hexdump -C reference/navilink_waypoints.wpt | tail -3
000000e0  00 40 07 00 53 55 42 57  41 59 00 00 02 e2 d9 1e
|.@......??.|
000000f0  22 c6 fe ff 74 00 07 0a  03 11 04 35 00 00 00 7e
|"???t......5...~|
00000100

 ./gpsbabel -i navilink -f reference/navilink_waypoints.wpt -o navilink -F -
| hexdump -C | tail -3



000000e0  00 40 00 00 53 55 42 57  41 59 00 00 02 e2 d9 1e
|.@......??.|
000000f0  00 00 00 00 74 00 07 0a  03 11 04 35 00 00 00 7e
|....t......5...~|
00000100


The lontitude matches, but the latitude is zero.   Your latitudes are around
51.795.  You're not near integer overflow.   Do you have any idea what makes
those special?

Let's take apart the last waypoint and look at the latitudes..  The
> reference file contains:
>

OK, I found it and fixed it.   You were multiplying a double by an integer
and thus getting a double, but passing it to a function expecting an int.  I
don't know why the compile wasn't fussing about this, but the following
change makes it succeed for me.

Index: navilink.c
===================================================================
RCS file: /cvsroot/gpsbabel/gpsbabel/navilink.c,v
retrieving revision 1.1
diff -p -u -r1.1 navilink.c
--- navilink.c    20 Jan 2008 22:44:19 -0000    1.1
+++ navilink.c    21 Jan 2008 02:44:33 -0000
@@ -311,8 +311,8 @@ decode_position(const unsigned char *buf
 static void
 encode_position(const waypoint *waypt, unsigned char *buffer)
 {
-    le_write32(buffer + 0, waypt->latitude * 10000000);
-    le_write32(buffer + 4, waypt->longitude * 10000000);
+    le_write32(buffer + 0, (int) (waypt->latitude * 10000000));
+    le_write32(buffer + 4, (int) (waypt->longitude * 10000000));
     le_write16(buffer + 8, METERS_TO_FEET(waypt->altitude));
 }

I've committed this.

RJL

> I've done some serial sniffing this morning and managed to work out
> how to upload tracks (the doco was incorrect and I hadn't managed to
> get it working before) so the attached patch adds support for that.

Applied.  Thanx.

I am preparing a patch with the following parts:
 * Implement more Garmin fitness protocols in jeeps
 * Storing Garmin fitness extensions in garmin_fs
 * Reading fitness information in garmin module
 * Write fitness support in GTC format (change from .HST to TCX)

What is not yet there:
 * Have not finalized or tested fully yet so there are sure some bugs
 * Need to handle source data not from Garmin a little better

Future:
 * Write support for courses to devices (low level almost there, but
there must be some funky logic in the garmin module)
 * Read support for GTC. This will also be required to get support for
stuff like CoursePoints.
 * Eventually, it could be expanded to read/write workout information
and user information as well.

GPSBabel is used as a data reader (eventually writer) serving data to
other applications, no fitness processing in GPSBabel.

If this will be merged at all, later or included in the beta is another matter.
I could add a pre patch to the enhancement request, but I assume that
Robert at al wants the final patches.

/Gerhard

On Jan 21, 2008 4:17 AM, Robert Lipe <robertlipe@...> wrote:
> HI, Babel-heads.
>
> I've swept through my many trees, resolving various outstanding changes and
> working through various reports on the lists that had accumulated.  I've
> updated http://www.gpsbabel.org/changes.html and the doc in
> htmldoc-development and pushed the updates to the public web.
>
>
> There's enough accumulated stuff that I think a short beta before a real
> release is worthwhile.   I'd like to check in to see if any of you know of
> reasons that shouldn't happen w/in the next week or so.   Are there any
> outstanding pieces in progress that we'd want to be sure were on board a
> 1.3.5 beta/release cycle?
>
> Thanx,
> RJL

On Jan 21, 2008 6:47 AM, Gerhard Olsson <gerhard.nospam@...> wrote:

> I am preparing a patch with the following parts:
>  * Implement more Garmin fitness protocols in jeeps


Sigh.  Just last night I noticed
http://sourceforge.net/tracker/index.php?func=detail&aid=1852998&group_id=58972&atid=489477
which seems to overlap with that.   I've tried to move that conversation
here so that maybe we can quit running over the same ground.

(I *hate* the sf tracking system.   I must find a way to disable it so that
people will quit sending patches to what's effectively a box that's rarely
checked.)


Whether either (both?) of these make it to the beta or not is kind of a
tossup right now for me.  I have concerns about Achim's change introducing
instability of existing support without adding any actual benefit so I'd
lean toward "out" for now just in the name of stability management.
Rewriting track support for the Garmins at the last minute gives me an
uneasy feeling.

RJL

Hi Robert,

> 1.3.5 beta/release cycle?

I'm over the open GPI documents and will commit them in next hours. Currently 
I don't have any mature changes for project. 

I think the beta would be really good for the GPI changes.

O.K.

On Jan 4, 2008 6:02 PM, Mirko Parthey <
mirko.parthey@...> wrote:
>
>
> first segment reverted -> works OK
> first segment applied -> breaks
>

Odd.

In case it helps those w/o access to the hardware, the device in question
runs at 115BPS and uses an embedded PL2303 part.

The thing that's a little non-standard in the way we talk to the device is
that we frequently reset VMIN/VTIME (but _not_ cflags) while the device may
be streaming data at us.   On Mac, at least, it looks like he PL2303 driver
reprograms the device resulting in a brief interrupt of data that's in
flight (either in the shift register at that moment or still in flight into
the bit decoders) and that corrupts receive data.

I don't know if that's the problem here.  I can't correlate it ot the second
hunk of the patch that was cited, but I offer it in the hope it helps
describe our slightly weird ioctl action on the tty system.

On Sat, Jan 05, 2008 at 02:09:32AM +0000, Alan Cox wrote:
> > first segment reverted -> works OK
> > first segment applied -> breaks
> 
> So I would guess while data is being transferred your code sets the tty
> settings to the exact ones that were still in use, and this now drops
> bytes ?

Yes - as far as I can see, only VMIN and VTIME change between ioctl()s.

I made two strace logs:
* strace-OK with patch segment 1 backed out
* strace-broken with patch segment 1 applied

They are trimmed at the beginning and end, and select() calls were
removed.

I'll attach a diff between the two logs, with lots of context.
Please let me know if you need anything further.

Mirko

On Mon, Jan 07, 2008 at 12:42:03PM +0000, Alan Cox wrote:
> Please try the following
>
> drivers/char/tty_ioctl.c    |   19 +++++++++++++++++++
> drivers/usb/serial/pl2303.c |    7 +++++++
> include/linux/tty.h         |    1 +
> 3 files changed, 27 insertions(+)

Your patch works fine here, the regression seems to be fixed.

Thanks!
Mirko

now, my problem is that the xcsv gpsbabel system does not seem to have a
> "track delimiter". There are a field delimiter and a record delimiter,
>


Our XCSV scheme is for reading and writing pretty simple files - the kind
that don't have track delimiters.   Sorry, but  you can't represent that our
xcsv plumbing; you'd have to write a "real" C module to do it or extend the
xcsv handlers.