Thread: [Gpsbabel-misc] Canmore GT-730FL-S
Brought to you by:
robertl
From: Andrew M. <2bi...@gm...> - 2012-04-23 19:17:08
|
Howdy All - Having some trouble with gpsbabel and my GT-730FL-S unit. If I grab my track log from the unit with: gpsbabel -i skytraq,baud=230400 -f /dev/ttyUSB0 -o gpx -F /tmp/poop.gpx the first point in the track is: <trkpt lat="0.030309890" lon="44.968534372"> <ele>6063243649.881560</ele> <time>2012-04-23T16:23:20Z</time> <speed>0.000000</speed> <name>TP0001</name> </trkpt> elevation, lat, and long are all way way off, and time is just a bit off, compared to the first point in the track when extracted via the stupid windows tool: WNO TOW Time Date DECEF_X DECEF_Y DECEF_Z ECEF_X ECEF_Y ECEF_Z Speed Longitude Latitude Altitude Mode 1685 145413 16:23:18 4/23/2012 0 0 0 -740815 -5454823 3210852 0 -97.733975 30.421571 184.224399 1 what additional information will help troubleshoot this? Thanks! Andrew |
From: Robert L. <rob...@gp...> - 2012-04-27 13:33:46
|
My first reaction was to say that the GT-730FL-S isn't compatible with the Canmores with fewer letters. But in the process of Googling around, I found a discussion where people are using that very model with GPSBabel succesfully. http://www.rcgroups.com/forums/showthread.php?t=1623262 Perhaps a conversation with those guys to compare firmware versions and options will help. I don't have that device. Mathias, any tips? RJL On Mon, Apr 23, 2012 at 2:17 PM, Andrew Malota <2bi...@gm...>wrote: > Howdy All - > Having some trouble with gpsbabel and my GT-730FL-S unit. > > If I grab my track log from the unit with: > gpsbabel -i skytraq,baud=230400 -f /dev/ttyUSB0 -o gpx -F /tmp/poop.gpx > > the first point in the track is: > <trkpt lat="0.030309890" lon="44.968534372"> > <ele>6063243649.881560</ele> > <time>2012-04-23T16:23:20Z</time> > <speed>0.000000</speed> > <name>TP0001</name> > </trkpt> > > elevation, lat, and long are all way way off, and time is just a bit > off, compared to the first point in the track when extracted via the > stupid windows tool: > WNO TOW Time Date DECEF_X DECEF_Y DECEF_Z ECEF_X ECEF_Y ECEF_Z Speed > Longitude Latitude Altitude Mode > 1685 145413 16:23:18 4/23/2012 0 0 0 -740815 -5454823 3210852 0 > -97.733975 30.421571 184.224399 1 > > what additional information will help troubleshoot this? > > Thanks! > Andrew > > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > Gpsbabel-misc mailing list http://www.gpsbabel.org > Gps...@li... > To unsubscribe, change list options, or see archives, visit: > https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc > |
From: Mathias A. <m....@ad...> - 2012-04-28 11:31:03
|
Hi, Am 27.04.2012 15:33, schrieb Robert Lipe: > My first reaction was to say that the GT-730FL-S isn't compatible with > the Canmores with fewer letters. But in the process of Googling > around, I found a discussion where people are using that very model with > GPSBabel succesfully. > > http://www.rcgroups.com/forums/showthread.php?t=1623262 > > Perhaps a conversation with those guys to compare firmware versions and > options will help. > > I don't have that device. Mathias, any tips? I neither know the device. Can you provide a raw dump (--dump-file) and gpx from gpsbabel, and the corresponding output of the windows tool (gpx, if possible) for the same data? > On Mon, Apr 23, 2012 at 2:17 PM, Andrew Malota <2bi...@gm... > <mailto:2bi...@gm...>> wrote: > > Howdy All - > Having some trouble with gpsbabel and my GT-730FL-S unit. > > If I grab my track log from the unit with: > gpsbabel -i skytraq,baud=230400 -f /dev/ttyUSB0 -o gpx -F /tmp/poop.gpx > > the first point in the track is: > <trkpt lat="0.030309890" lon="44.968534372"> > <ele>6063243649.881560</ele> > <time>2012-04-23T16:23:20Z</time> > <speed>0.000000</speed> > <name>TP0001</name> > </trkpt> I tried to convert that with the method from Robert's link: gpsbabel -i gpx -f test_in.gpx -x height,wgs84tomsl -o gpx -F test_out.gpx However, only the elevation changed slightly, so it seems not to be a fix in this case... > > elevation, lat, and long are all way way off, and time is just a bit > off, compared to the first point in the track when extracted via the > stupid windows tool: > WNO TOW Time Date DECEF_X DECEF_Y DECEF_Z ECEF_X ECEF_Y ECEF_Z Speed > Longitude Latitude Altitude Mode > 1685 145413 16:23:18 4/23/2012 0 0 0 -740815 -5454823 3210852 0 > -97.733975 30.421571 184.224399 1 As for the time being off some seconds: that's a known issue in gpsbabel skytraq module (calculation of leap seconds isn't fully implemented yet). (@Robert: is there a generic function in gpsbabel which provides this that I could use?) Regards, Mathias |
From: Robert L. <rob...@gp...> - 2012-04-30 14:01:13
|
> > As for the time being off some seconds: that's a known issue in gpsbabel > skytraq module (calculation of leap seconds isn't fully implemented yet). > > (@Robert: is there a generic function in gpsbabel which provides this that > I could use?) > No. It's not really something we can compute. Time nerds decide when Leap Seconds are added or subtracted from UTC based on the rotation of the Earth. GPS maintains a constant time based on International Atomic Time. The constellation of SVs broadcasts the current offset between UTC and IAT in the packets and most GPS receivers that expose such things bring that data out to the programmer. (See line 705 of garmin.c) If the unit doesn't provide this (shame on them) and you don't want to introduce the calculations of the Earth's orbit into the module (please don't) it'd be OK with me if you just use a hard-coded "19 seconds" and move on. Most users of data loggers frankly won't notice the times being slightly off from UTC anyway as long as they're all correct relative to each others. Oh, and the elevation in his example would have changed only slightly when adjusted for sea level as his reported altitude would be something like 10x the moon's orbit from Earth. :-) |
From: Andrew M. <2bi...@gm...> - 2012-05-01 02:22:41
|
> I neither know the device. Can you provide a raw dump (--dump-file) and gpx from gpsbabel, and the corresponding output of the windows tool (gpx, if possible) for the same data? Actually having trouble getting the binary dump for you... First some versions: GPS Module (As reported by windows app:) kernel 1.4.89 skytraq 1.10.24 skytraq rev 2011.8.23 gpsbabel -V GPSBabel Version 1.4.2 when i try to pull your binary dump: gpsbabel -i skytraq,baud=230400 -f /dev/ttyUSB1 --dump-file raw.bin Failed to open port (No such file or directory) skytraq: Can't open port '--dump-file running as: gpsbabel -i skytraq,baud=230400 -f /dev/ttyUSB1 -o gpx -F my.gpx has RC=0, but the file has the wrong data not sure how to proceed from here. the windows tool has the ability to pull a "compressed log" which may be the binary file you seek. threw it here https://www.2bitoperations.com/gps/binary-from-win.log along with the corresponding human-readable win output here: https://www.2bitoperations.com/gps/human-readable.log aside: sparkfun has some datasheets, including a logging format/command datasheet listed here that might be applicable: http://www.sparkfun.com/products/9060 |
From: Mathias A. <m....@ad...> - 2012-05-01 16:39:10
|
Hi Andrew, Am 01.05.2012 04:22, schrieb Andrew Malota: >> I neither know the device. Can you provide a raw dump (--dump-file) and gpx from gpsbabel, and the corresponding output of the windows tool (gpx, if possible) for the same data? > Actually having trouble getting the binary dump for you... > > when i try to pull your binary dump: > gpsbabel -i skytraq,baud=230400 -f /dev/ttyUSB1 --dump-file raw.bin > Failed to open port (No such file or directory) > skytraq: Can't open port '--dump-file my bad, it's not --dump-file, rather use something like this: gpsbabel -D 2 -i skytraq,baud=230400,dump-file=raw.bin -f /dev/ttyUSB0 Can you try again please, and get the raw dump (along with gpx, and debug output)? > not sure how to proceed from here. the windows tool has the ability to > pull a "compressed log" which may be the binary file you seek. indeed, seems to be the raw binary. I was able to convert it to gpx using gpsbabel (v1.4.0 and v1.4.3-beta20111112, both gave the same): gpsbabel -i skytraq-bin -f binary-from-win.log -o gpx -F binary-from-win_conv.gpx Interestingly, the result seems reasonable to me (elevation ~185m, somewhere in Austin...). Btw, which OS are you running gpsbabel under? (I just tested under Linux/Debian 6.0) > aside: > sparkfun has some datasheets, including a logging format/command > datasheet listed here that might be applicable: > http://www.sparkfun.com/products/9060 > I've known them already, but thanks anyway :-) Regards, Mathias |
From: Andrew M. <2bi...@gm...> - 2012-05-02 12:58:51
|
> my bad, it's not --dump-file, rather use something like this: > > gpsbabel -D 2 -i skytraq,baud=230400,dump-file=raw.bin -f /dev/ttyUSB0 > > Can you try again please, and get the raw dump (along with gpx, and debug > output)? gpsbabel -D2 -i skytraq,baud=230400,dump-file=raw2.bin -f /dev/ttyUSB0 -o gpx -F test3.gpx GPSBabel Version: 1.4.2 options: module/option=value: skytraq/erase="0" (=default) options: module/option=value: skytraq/targetlocation="" (=default) options: module/option=value: skytraq/baud="230400" (=default) options: module/option=value: skytraq/initbaud="0" (=default) options: module/option=value: skytraq/read-at-once="255" (=default) options: module/option=value: skytraq/first-sector="0" (=default) options: module/option=value: skytraq/last-sector="-1" (=default) options: module/option=value: skytraq/dump-file="raw2.bin" options: module/option=value: skytraq/no-output="0" (=default) skytraq: Probing SkyTraq Venus at 9600baud... skytraq: Didn't get message start tag Didn't receive ACK (-3), retrying... skytraq: Didn't get message start tag Didn't receive ACK (-3) skytraq: Probing SkyTraq Venus at 230400baud... Receiving message with 2 bytes of payload (expected >=2) Receiving message with 2 bytes of payload (expected >=2) Receiving message with 14 bytes of payload (expected >=14) skytraq: Venus device found: Kernel version = 1.4.89, ODM version = 1.10.24, revision (Y/M/D) = 11/08/23 Receiving message with 2 bytes of payload (expected >=2) Receiving message with 2 bytes of payload (expected >=2) Receiving message with 41 bytes of payload (expected >=9) skytraq: Device status: free sectors: 510 / total sectors: 510 / 0% used / write ptr: 8966 skytraq: Reading log data from device... Reading 1 sectors beginning from #0... Receiving message with 2 bytes of payload (expected >=2) Receiving message with 2 bytes of payload (expected >=2) Receiving data of sector #0... skytraq: Got 93 trackpoints from 1 sectors. skytraq: Didn't get message start tag skytraq: Got neither ACK nor NACK, resending msg (id=0x01)... Receiving message with 2 bytes of payload (expected >=2) Receiving message with 2 bytes of payload (expected >=2) options: module/option=value: gpx/snlen="32" (=default) options: module/option=value: gpx/gpxver="1.0" (=default) <back to prompt here> resultant files: https://www.2bitoperations.com/gps/test3.gpx https://www.2bitoperations.com/gps/raw2.bin then straight to windows tool, pulled: https://www.2bitoperations.com/gps/kml-win2.kml https://www.2bitoperations.com/gps/bin-win2.log https://www.2bitoperations.com/gps/ascii-win2.log (near as I can tell, win tool doesn't offer GPX output, but they DO offer KML.) > gpsbabel -i skytraq-bin -f binary-from-win.log -o gpx -F > binary-from-win_conv.gpx > > Interestingly, the result seems reasonable to me (elevation ~185m, > somewhere in Austin...). well that's correct. I tried the same test on "my end": gpsbabel -D2 -i skytraq-bin -f bin-win2.log -o gpx -F skytraq-bin-test.gpx gpsbabel -D2 -i skytraq-bin -f raw2.bin -o gpx -F skytraq-bin-test2.gpx and both resultant gpx files have incorrect data. i'm starting to suspect this is an ubuntu packaging/built bug rather than a legit gpsbabel bug I'll fetch source in an hour or so and build myself. > Btw, which OS are you running gpsbabel under? > (I just tested under Linux/Debian 6.0) Ubuntu 12.04 amd64 |
From: Andrew M. <2bi...@gm...> - 2012-05-02 13:11:40
|
> I'll fetch source in an hour or so and build myself. even building myself, all the points are wrong. just fetched with cvs -d:pserver:ano...@gp...:/cvsroot/gpsbabel login cvs -z3 -d:pserver:ano...@gp...:/cvsroot/gpsbabel co -P gpsbabel configure, make -j3, re-run test with: ~/appinstall/gps-dongle/gpsbabel/gpsbabel -D2 -i skytraq,initbaud=230400,baud=230400,dump-file=raw4.bin -f /dev/ttyUSB0 -o gpx -F test4.gpx GPSBabel Version: 1.4.2 options: module/option=value: skytraq/erase="0" (=default) options: module/option=value: skytraq/targetlocation="" (=default) options: module/option=value: skytraq/baud="230400" (=default) options: module/option=value: skytraq/initbaud="230400" options: module/option=value: skytraq/read-at-once="255" (=default) options: module/option=value: skytraq/first-sector="0" (=default) options: module/option=value: skytraq/last-sector="-1" (=default) options: module/option=value: skytraq/dump-file="raw4.bin" options: module/option=value: skytraq/no-output="0" (=default) skytraq: Probing SkyTraq Venus at 230400baud... Receiving message with 2 bytes of payload (expected >=2) Receiving message with 2 bytes of payload (expected >=2) Receiving message with 14 bytes of payload (expected >=14) skytraq: Venus device found: Kernel version = 1.4.89, ODM version = 1.10.24, revision (Y/M/D) = 11/08/23 Receiving message with 2 bytes of payload (expected >=2) Receiving message with 2 bytes of payload (expected >=2) Receiving message with 41 bytes of payload (expected >=9) skytraq: Device status: free sectors: 510 / total sectors: 510 / 0% used / write ptr: 10590 skytraq: Reading log data from device... skytraq: start=0 used=1 skytraq: opt_last_sector_val=-1 Reading 1 sectors beginning from #0... Receiving message with 2 bytes of payload (expected >=2) Receiving message with 2 bytes of payload (expected >=2) Receiving data of sector #0... skytraq: Got 291 trackpoints from 1 sectors. restart system skytraq: Didn't get message start tag skytraq: Got neither ACK nor NACK, resending msg (id=0x01)... skytraq: Didn't get message start tag skytraq: Got neither ACK nor NACK, resending msg (id=0x01)... Receiving message with 2 bytes of payload (expected >=2) Receiving message with 2 bytes of payload (expected >=2) options: module/option=value: gpx/snlen="32" (=default) options: module/option=value: gpx/gpxver="1.0" (=default) 64 bit problem? i'll try and dig up a 32-bit box around here somewhere and re-run test. andrew |
From: Mathias A. <m....@ad...> - 2012-05-02 13:16:41
|
Hi Andrew, Am 02.05.2012 15:11, schrieb Andrew Malota: > 64 bit problem? i'll try and dig up a 32-bit box around here somewhere > and re-run test. yes, that's what just came to my mind when reading you're using amd64... I think that's worth a try. Currently I don't have a 64bit machine around, so cannot do the opposite test. Regards, Mathias |
From: Andrew M. <2bi...@gm...> - 2012-05-02 13:32:03
|
>> 64 bit problem? i'll try and dig up a 32-bit box around here somewhere >> and re-run test. > > > yes, that's what just came to my mind when reading you're using amd64... > I think that's worth a try. Currently I don't have a 64bit machine around, > so cannot do the opposite test. 32nd time is the charm? on my old 32-bit box, I get correct output:./gpsbabel -D2 -i skytraq,initbaud=230400,baud=230400,dump-file=raw5.bin -f /dev/ttyUSB0 -o gpx -F test5.gpx GPSBabel Version: 1.4.2 options: module/option=value: skytraq/erase="0" (=default) options: module/option=value: skytraq/targetlocation="" (=default) options: module/option=value: skytraq/baud="230400" (=default) options: module/option=value: skytraq/initbaud="230400" options: module/option=value: skytraq/read-at-once="255" (=default) options: module/option=value: skytraq/first-sector="0" (=default) options: module/option=value: skytraq/last-sector="-1" (=default) options: module/option=value: skytraq/dump-file="raw5.bin" options: module/option=value: skytraq/no-output="0" (=default) skytraq: Probing SkyTraq Venus at 230400baud... Receiving message with 2 bytes of payload (expected >=2) Receiving message with 2 bytes of payload (expected >=2) Receiving message with 14 bytes of payload (expected >=14) skytraq: Venus device found: Kernel version = 1.4.89, ODM version = 1.10.24, revision (Y/M/D) = 11/08/23 Receiving message with 2 bytes of payload (expected >=2) Receiving message with 2 bytes of payload (expected >=2) Receiving message with 41 bytes of payload (expected >=9) skytraq: Device status: free sectors: 510 / total sectors: 510 / 0% used / write ptr: 11984 skytraq: Reading log data from device... skytraq: start=0 used=1 skytraq: opt_last_sector_val=-1 Reading 1 sectors beginning from #0... Receiving message with 2 bytes of payload (expected >=2) Receiving message with 2 bytes of payload (expected >=2) Receiving data of sector #0... skytraq: Got 464 trackpoints from 1 sectors. restart system skytraq: Didn't get message start tag skytraq: Got neither ACK nor NACK, resending msg (id=0x01)... skytraq: Didn't get message start tag skytraq: Got neither ACK nor NACK, resending msg (id=0x01)... Receiving message with 2 bytes of payload (expected >=2) Receiving message with 2 bytes of payload (expected >=2) options: module/option=value: gpx/snlen="32" (=default) options: module/option=value: gpx/gpxver="1.0" (=default) from GPX file: <trkpt lat="30.376904113" lon="-97.664988237"> <ele>166.142176</ele> <time>2012-05-02T12:42:39Z</time> <speed>0.000000</speed> <name>TP0001</name> </trkpt> (woohoo looks good) OK - SO - 64 bit problem. i'll try taking a look at the source this evening and fiddling. should be pretty easy to validate when it's done - I should get the same GPX file from my amd64 machine as I do for my 32bit box when I feed it an identical dump from the stick, right? Andrew |
From: Robert L. <rob...@gp...> - 2012-05-02 14:23:40
|
It looks like there's an implicit sign extension that's not happening. pst->x = f.x; pst->y = f.y; pst->z = f.z; These are 'long' which means they get sign extended differenly on a 32 and 64 system. Try something like this on for size: Index: skytraq.c =================================================================== --- skytraq.c (revision 4163) +++ skytraq.c (working copy) @@ -585,18 +585,18 @@ } typedef struct { - short gps_week; - long gps_sec; - unsigned long x; - unsigned long y; - unsigned long z; + gbuint32 gps_week; + gbuint32 gps_sec; + gbint32 x; + gbint32 y; + gbint32 z; } full_item; typedef struct { - short dt; - short dx; - short dy; - short dz; + gbuint16 dt; + gbuint16 dx; + gbuint16 dy; + gbuint16 dz; } compact_item; Elevation is still wacky so maybe I've overpainted but this should at least get you on the road to a final fix. Why is this not failing our test suite, anyway? RJL On Wed, May 2, 2012 at 8:31 AM, Andrew Malota <2bi...@gm...>wrote: > >> 64 bit problem? i'll try and dig up a 32-bit box around here somewhere > >> and re-run test. > > > > > > yes, that's what just came to my mind when reading you're using amd64... > > I think that's worth a try. Currently I don't have a 64bit machine > around, > > so cannot do the opposite test. > > 32nd time is the charm? > on my old 32-bit box, I get correct output:./gpsbabel -D2 -i > skytraq,initbaud=230400,baud=230400,dump-file=raw5.bin -f /dev/ttyUSB0 -o > gpx -F test5.gpx > GPSBabel Version: 1.4.2 > options: module/option=value: skytraq/erase="0" (=default) > options: module/option=value: skytraq/targetlocation="" (=default) > options: module/option=value: skytraq/baud="230400" (=default) > options: module/option=value: skytraq/initbaud="230400" > options: module/option=value: skytraq/read-at-once="255" (=default) > options: module/option=value: skytraq/first-sector="0" (=default) > options: module/option=value: skytraq/last-sector="-1" (=default) > options: module/option=value: skytraq/dump-file="raw5.bin" > options: module/option=value: skytraq/no-output="0" (=default) > skytraq: Probing SkyTraq Venus at 230400baud... > Receiving message with 2 bytes of payload (expected >=2) > Receiving message with 2 bytes of payload (expected >=2) > Receiving message with 14 bytes of payload (expected >=14) > skytraq: Venus device found: Kernel version = 1.4.89, ODM version = > 1.10.24, revision (Y/M/D) = 11/08/23 > Receiving message with 2 bytes of payload (expected >=2) > Receiving message with 2 bytes of payload (expected >=2) > Receiving message with 41 bytes of payload (expected >=9) > skytraq: Device status: free sectors: 510 / total sectors: 510 / 0% used / > write ptr: 11984 > skytraq: Reading log data from device... > skytraq: start=0 used=1 > skytraq: opt_last_sector_val=-1 > Reading 1 sectors beginning from #0... > Receiving message with 2 bytes of payload (expected >=2) > Receiving message with 2 bytes of payload (expected >=2) > Receiving data of sector #0... > skytraq: Got 464 trackpoints from 1 sectors. > restart system > skytraq: Didn't get message start tag > skytraq: Got neither ACK nor NACK, resending msg (id=0x01)... > skytraq: Didn't get message start tag > skytraq: Got neither ACK nor NACK, resending msg (id=0x01)... > Receiving message with 2 bytes of payload (expected >=2) > Receiving message with 2 bytes of payload (expected >=2) > options: module/option=value: gpx/snlen="32" (=default) > options: module/option=value: gpx/gpxver="1.0" (=default) > > from GPX file: > <trkpt lat="30.376904113" lon="-97.664988237"> > <ele>166.142176</ele> > <time>2012-05-02T12:42:39Z</time> > <speed>0.000000</speed> > <name>TP0001</name> > </trkpt> > (woohoo looks good) > > > OK - SO - 64 bit problem. i'll try taking a look at the source this > evening and fiddling. > should be pretty easy to validate when it's done - I should get the same > GPX file from my amd64 machine as I do for my 32bit box when I feed it an > identical dump from the stick, right? > > Andrew > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Gpsbabel-misc mailing list http://www.gpsbabel.org > Gps...@li... > To unsubscribe, change list options, or see archives, visit: > https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc > > |
From: Andrew M. <2bi...@gm...> - 2012-05-02 16:24:02
|
> It looks like there's an implicit sign extension that's not happening. > > pst->x = f.x; > pst->y = f.y; > pst->z = f.z; --- skytraq.c 11 Nov 2010 03:32:47 -0000 1.7 +++ skytraq.c 2 May 2012 15:20:16 -0000 @@ -562,18 +562,18 @@ } typedef struct { - short gps_week; - long gps_sec; - unsigned long x; - unsigned long y; - unsigned long z; + gbuint32 gps_week; + gbuint32 gps_sec; + gbint32 x; + gbint32 y; + gbint32 z; } full_item; typedef struct { - short dt; - short dx; - short dy; - short dz; + gbint16 dt; + gbint16 dx; + gbint16 dy; + gbint16 dz; } compact_item; struct full_item_frame { @@ -603,7 +603,7 @@ { int res = 0; double lat, lon, alt; - unsigned int ts; + gbint32 ts; int poi = 0; full_item f; compact_item c; this patch seems to give me what I want. my gpx file looks sane and tests pass: ./vtesto Running testo.d/bushnell.test Running testo.d/classic-1.test Running testo.d/classic-2.test --- /tmp/gpsbabel.31847/navi.wpt 2012-05-02 10:56:48.105331664 -0500 +++ ./reference/navicache.ref 2003-09-21 20:38:15.000000000 -0500 @@ -1,2 +1,2 @@ -N00927 3334.415N 11146.587W 0000000m Eagle's Nest a -N00926 3431.053N 11146.178W 0000000m Clear Creek Cache a +2343 3334.415N 11146.587W 0000000m Eagle's Nest a +2342 3431.053N 11146.178W 0000000m Clear Creek Cache a ERROR comparing /tmp/gpsbabel.31847/navi.wpt ./reference/navicache.ref Running testo.d/classic-3.test Running testo.d/classic-4.test Running testo.d/compegps.test Running testo.d/garmin_xt.test Running testo.d/igo8.test Running testo.d/kml.test /tmp/gpsbabel.31847/earth-gc.kml validates /tmp/gpsbabel.31847/gpx_garmin_extensions-kml_track.kml validates /tmp/gpsbabel.31847/segmented_tracks.kml validates /tmp/gpsbabel.31847/gtrnctr_power-kml.kml validates /tmp/gpsbabel.31847/bounds-test-track.kml validates /tmp/gpsbabel.31847/bounds-test.kml validates /tmp/gpsbabel.31847/earth-expertgps.kml validates /tmp/gpsbabel.31847/earth-expertgps-track.kml validates Running testo.d/sbn.test Running testo.d/track.test Running testo.d/wintec_tes.test of course, reverting the patch everything still passes :) I'll double-check my work when I get home - i will feed the same binary file to an unpatched gpsbabel and diff the gpx files. should be same. andrew |
From: Andrew M. <2bi...@gm...> - 2012-05-02 22:37:32
|
> > > I'll double-check my work when I get home - i will feed the same > binary file to an unpatched gpsbabel and diff the gpx files. should be > same. I fed this file: https://www.2bitoperations.com/gps/raw2.bin to both the patched amd64 binary I built as well as an unpatched i686 gpsbabel GPX output was identical, except for the timestamp in the header (expected? i didn't generate them at the EXACT same time :) ) i think life is good with the patch. can someone commit? would still be instructive to understand why the test cases aren't failing. perhaps this bin file should be added as another test case for the skytraq module? andrew |
From: Mathias A. <m....@ad...> - 2012-05-03 13:14:36
|
Am Mi, 2.05.2012, 16:23 schrieb Robert Lipe: > It looks like there's an implicit sign extension that's not happening. > > pst->x = f.x; > pst->y = f.y; > pst->z = f.z; > > These are 'long' which means they get sign extended differenly on a 32 and > 64 system. Despite I've read that we now have a working patch, just a comment as I'm not sure about its implications: as you pointed out, pst->x,y,z are (signed) long while f.x/y/z are unsigned long. The patch changes the latter to gbint32, which is long on MSVC and uint32_t=(signed) int on other platforms (right?). However, those are being set by me_read32(), which returns an unsigned int -- at least at first glance, I cannot decide whether this could cause any other problems.. As for ts in process_data_item(), that definitely should stay unsigned. The upper 20 bits count seconds in a week, a week has >600 000 seconds so MSB is required as a digit. > > Why is this not failing our test suite, anyway? The only test is the one I provided -- as being recorded in Europe, both lat and lon are >0 over here so the sign problem probably doesn't appear. I think we should add Andrew's example as a second test. Regards, Mathias |
From: Mathias A. <m....@ad...> - 2012-05-14 14:02:17
|
Hi, Am 03.05.2012 00:37, schrieb Andrew Malota: > > I'll double-check my work when I get home - i will feed the same > binary file to an unpatched gpsbabel and diff the gpx files. should be > same. > > I fed this file: > https://www.2bitoperations.com/gps/raw2.bin > to both the patched amd64 binary I built as well as an unpatched i686 > gpsbabel > GPX output was identical, except for the timestamp in the header > (expected? i didn't generate them at the EXACT same time :) ) > > i think life is good with the patch. can someone commit? > > would still be instructive to understand why the test cases aren't > failing. perhaps this bin file should be added as another test case for > the skytraq module? I'd like to get back on this: I just created a new set of test cases: 1) skytraq-realdata.bin consists of real log data (the old skytraq.bin and your binary-from-win.log) 2) skytraq-artificial.bin: artificial data, tests some more specific corner cases The reference-gpx's were created with gpsbabel on a 32-bit i686 under Linux/Debian 6.0. (even on 32-bit I had to correct a data type to get one very rare case right. The discussed patch for amd64 fixes this too). Can someone verify on amd64? Regards, Mathias |
From: Robert L. <rob...@gp...> - 2012-05-14 14:15:54
|
Great timing. I just did something very similar and committed this minutes ago as revision 4176. I've added your test case in 4177 and, unfortunately, they fail on my Mac. (64-bit programs are the norm on Macs these days. The original failed on a 64-bit Mac build identically for me as it did for Andrew.) Can you please update and see if I've just missed a patch somewhere? Note that I busted skytrak out of the classic-4 and into a test of its own so you can run it in isolation. I'm doing that for pretty much any format I have to touch non-trivially these days. rjlimac:gpsbabel robertlipe$ ./testo skytraq Running testo.d/skytraq.test --- /tmp/gpsbabel.59165/skytraq-artificial.gpx 2012-05-14 09:10:56.000000000 -0500 +++ ./reference/skytraq-artificial.gpx 2012-05-14 09:08:43.000000000 -0500 @@ -82,7 +82,7 @@ </trkpt> <trkpt lat="47.547749767" lon="9.679499575"> <ele>435.413042</ele> - <time>2009-09-10T03:07:53Z</time> + <time>2009-09-10T21:20:09Z</time> <speed>0.000000</speed> <name>TP0009</name> </trkpt> @@ -100,13 +100,13 @@ </trkpt> <trkpt lat="47.547749767" lon="9.679499575"> <ele>435.413042</ele> - <time>1999-08-15T22:21:39Z</time> + <time>1999-08-28T01:37:55Z</time> <speed>0.000000</speed> <name>TP0012</name> </trkpt> <trkpt lat="47.547749767" lon="9.679499575"> <ele>435.413042</ele> - <time>1999-08-16T08:43:31Z</time> + <time>1999-08-28T11:59:47Z</time> <speed>0.000000</speed> <name>TP0013</name> </trkpt> @@ -124,13 +124,13 @@ </trkpt> <trkpt lat="47.547749767" lon="9.679499575"> <ele>435.413042</ele> - <time>2019-03-24T22:21:39Z</time> + <time>2019-04-06T01:37:55Z</time> <speed>27.777779</speed> <name>TP0016</name> </trkpt> <trkpt lat="47.547749767" lon="9.679499575"> <ele>435.413042</ele> - <time>2019-03-25T20:42:31Z</time> + <time>2019-04-06T23:58:47Z</time> <speed>55.555557</speed> <name>TP0017</name> </trkpt> @@ -226,13 +226,13 @@ </trkpt> <trkpt lat="-30.376944904" lon="-97.665051294"> <ele>186.112471</ele> - <time>2019-03-24T23:21:39Z</time> + <time>2019-04-06T02:37:55Z</time> <speed>55.555557</speed> <name>TP0033</name> </trkpt> <trkpt lat="-30.376946121" lon="-97.665030673"> <ele>185.882330</ele> - <time>2019-03-24T15:09:23Z</time> + <time>2019-04-06T12:37:55Z</time> <speed>55.555557</speed> <name>TP0034</name> </trkpt> On Mon, May 14, 2012 at 9:01 AM, Mathias Adam <m....@ad...> wrote: > Hi, > > Am 03.05.2012 00:37, schrieb Andrew Malota: > > >> I'll double-check my work when I get home - i will feed the same >> binary file to an unpatched gpsbabel and diff the gpx files. should be >> same. >> >> I fed this file: >> https://www.2bitoperations.**com/gps/raw2.bin<https://www.2bitoperations.com/gps/raw2.bin> >> to both the patched amd64 binary I built as well as an unpatched i686 >> gpsbabel >> GPX output was identical, except for the timestamp in the header >> (expected? i didn't generate them at the EXACT same time :) ) >> >> i think life is good with the patch. can someone commit? >> >> would still be instructive to understand why the test cases aren't >> failing. perhaps this bin file should be added as another test case for >> the skytraq module? >> > > I'd like to get back on this: I just created a new set of test cases: > > 1) skytraq-realdata.bin consists of real log data (the old skytraq.bin > and your binary-from-win.log) > 2) skytraq-artificial.bin: artificial data, tests some more specific > corner cases > > The reference-gpx's were created with gpsbabel on a 32-bit i686 under > Linux/Debian 6.0. (even on 32-bit I had to correct a data type to get one > very rare case right. The discussed patch for amd64 fixes this too). > > Can someone verify on amd64? > > > Regards, > Mathias > |
From: Robert L. <rob...@gp...> - 2012-05-14 14:20:08
|
Sorry. I missed a change. Please update to 4178. That gets it down to one failure for me. rjlimac:gpsbabel robertlipe$ ./testo skytraq Running testo.d/skytraq.test --- /tmp/gpsbabel.59530/skytraq-artificial.gpx 2012-05-14 09:16:46.000000000 -0500 +++ ./reference/skytraq-artificial.gpx 2012-05-14 09:08:43.000000000 -0500 @@ -82,7 +82,7 @@ </trkpt> <trkpt lat="47.547749767" lon="9.679499575"> <ele>435.413042</ele> - <time>2009-09-10T03:07:53Z</time> + <time>2009-09-10T21:20:09Z</time> <speed>0.000000</speed> <name>TP0009</name> </trkpt> @@ -232,7 +232,7 @@ </trkpt> <trkpt lat="-30.376946121" lon="-97.665030673"> <ele>185.882330</ele> - <time>2019-04-05T18:25:39Z</time> + <time>2019-04-06T12:37:55Z</time> <speed>55.555557</speed> <name>TP0034</name> </trkpt> On Mon, May 14, 2012 at 9:15 AM, Robert Lipe <rob...@gp...>wrote: > Great timing. I just did something very similar and committed this > minutes ago as revision 4176. I've added your test case in 4177 and, > unfortunately, they fail on my Mac. (64-bit programs are the norm on Macs > these days. The original failed on a 64-bit Mac build identically for me > as it did for Andrew.) > > Can you please update and see if I've just missed a patch somewhere? > > Note that I busted skytrak out of the classic-4 and into a test of its own > so you can run it in isolation. I'm doing that for pretty much any format > I have to touch non-trivially these days. > > rjlimac:gpsbabel robertlipe$ ./testo skytraq > Running testo.d/skytraq.test > --- /tmp/gpsbabel.59165/skytraq-artificial.gpx 2012-05-14 > 09:10:56.000000000 -0500 > +++ ./reference/skytraq-artificial.gpx 2012-05-14 09:08:43.000000000 -0500 > @@ -82,7 +82,7 @@ > </trkpt> > <trkpt lat="47.547749767" lon="9.679499575"> > <ele>435.413042</ele> > - <time>2009-09-10T03:07:53Z</time> > + <time>2009-09-10T21:20:09Z</time> > <speed>0.000000</speed> > <name>TP0009</name> > </trkpt> > @@ -100,13 +100,13 @@ > </trkpt> > <trkpt lat="47.547749767" lon="9.679499575"> > <ele>435.413042</ele> > - <time>1999-08-15T22:21:39Z</time> > + <time>1999-08-28T01:37:55Z</time> > <speed>0.000000</speed> > <name>TP0012</name> > </trkpt> > <trkpt lat="47.547749767" lon="9.679499575"> > <ele>435.413042</ele> > - <time>1999-08-16T08:43:31Z</time> > + <time>1999-08-28T11:59:47Z</time> > <speed>0.000000</speed> > <name>TP0013</name> > </trkpt> > @@ -124,13 +124,13 @@ > </trkpt> > <trkpt lat="47.547749767" lon="9.679499575"> > <ele>435.413042</ele> > - <time>2019-03-24T22:21:39Z</time> > + <time>2019-04-06T01:37:55Z</time> > <speed>27.777779</speed> > <name>TP0016</name> > </trkpt> > <trkpt lat="47.547749767" lon="9.679499575"> > <ele>435.413042</ele> > - <time>2019-03-25T20:42:31Z</time> > + <time>2019-04-06T23:58:47Z</time> > <speed>55.555557</speed> > <name>TP0017</name> > </trkpt> > @@ -226,13 +226,13 @@ > </trkpt> > <trkpt lat="-30.376944904" lon="-97.665051294"> > <ele>186.112471</ele> > - <time>2019-03-24T23:21:39Z</time> > + <time>2019-04-06T02:37:55Z</time> > <speed>55.555557</speed> > <name>TP0033</name> > </trkpt> > <trkpt lat="-30.376946121" lon="-97.665030673"> > <ele>185.882330</ele> > - <time>2019-03-24T15:09:23Z</time> > + <time>2019-04-06T12:37:55Z</time> > <speed>55.555557</speed> > <name>TP0034</name> > </trkpt> > > > > On Mon, May 14, 2012 at 9:01 AM, Mathias Adam <m....@ad...> wrote: > >> Hi, >> >> Am 03.05.2012 00:37, schrieb Andrew Malota: >> >> >>> I'll double-check my work when I get home - i will feed the same >>> binary file to an unpatched gpsbabel and diff the gpx files. should be >>> same. >>> >>> I fed this file: >>> https://www.2bitoperations.**com/gps/raw2.bin<https://www.2bitoperations.com/gps/raw2.bin> >>> to both the patched amd64 binary I built as well as an unpatched i686 >>> gpsbabel >>> GPX output was identical, except for the timestamp in the header >>> (expected? i didn't generate them at the EXACT same time :) ) >>> >>> i think life is good with the patch. can someone commit? >>> >>> would still be instructive to understand why the test cases aren't >>> failing. perhaps this bin file should be added as another test case for >>> the skytraq module? >>> >> >> I'd like to get back on this: I just created a new set of test cases: >> >> 1) skytraq-realdata.bin consists of real log data (the old skytraq.bin >> and your binary-from-win.log) >> 2) skytraq-artificial.bin: artificial data, tests some more specific >> corner cases >> >> The reference-gpx's were created with gpsbabel on a 32-bit i686 under >> Linux/Debian 6.0. (even on 32-bit I had to correct a data type to get one >> very rare case right. The discussed patch for amd64 fixes this too). >> >> Can someone verify on amd64? >> >> >> Regards, >> Mathias >> > > |
From: Robert L. <rob...@gp...> - 2012-07-15 22:32:25
|
I've been out of town a ridiculous amount lately, but we need to pick this back up as what's checked in fails. We also need a way to work out a solution for the test suite for that stupid hardcoded time zone offset. It might be something sleazy like "if (week < XXX) offset = 13 else offset = 16" RJL On Mon, May 14, 2012 at 9:19 AM, Robert Lipe <rob...@gp...>wrote: > Sorry. I missed a change. Please update to 4178. That gets it down to > one failure for me. > > rjlimac:gpsbabel robertlipe$ ./testo skytraq > Running testo.d/skytraq.test > --- /tmp/gpsbabel.59530/skytraq-artificial.gpx 2012-05-14 > 09:16:46.000000000 -0500 > +++ ./reference/skytraq-artificial.gpx 2012-05-14 09:08:43.000000000 -0500 > @@ -82,7 +82,7 @@ > </trkpt> > <trkpt lat="47.547749767" lon="9.679499575"> > <ele>435.413042</ele> > - <time>2009-09-10T03:07:53Z</time> > + <time>2009-09-10T21:20:09Z</time> > <speed>0.000000</speed> > <name>TP0009</name> > </trkpt> > @@ -232,7 +232,7 @@ > </trkpt> > <trkpt lat="-30.376946121" lon="-97.665030673"> > <ele>185.882330</ele> > - <time>2019-04-05T18:25:39Z</time> > + <time>2019-04-06T12:37:55Z</time> > <speed>55.555557</speed> > <name>TP0034</name> > </trkpt> > > > On Mon, May 14, 2012 at 9:15 AM, Robert Lipe <rob...@gp...>wrote: > >> Great timing. I just did something very similar and committed this >> minutes ago as revision 4176. I've added your test case in 4177 and, >> unfortunately, they fail on my Mac. (64-bit programs are the norm on Macs >> these days. The original failed on a 64-bit Mac build identically for me >> as it did for Andrew.) >> >> Can you please update and see if I've just missed a patch somewhere? >> >> Note that I busted skytrak out of the classic-4 and into a test of its >> own so you can run it in isolation. I'm doing that for pretty much any >> format I have to touch non-trivially these days. >> >> rjlimac:gpsbabel robertlipe$ ./testo skytraq >> Running testo.d/skytraq.test >> --- /tmp/gpsbabel.59165/skytraq-artificial.gpx 2012-05-14 >> 09:10:56.000000000 -0500 >> +++ ./reference/skytraq-artificial.gpx 2012-05-14 09:08:43.000000000 >> -0500 >> @@ -82,7 +82,7 @@ >> </trkpt> >> <trkpt lat="47.547749767" lon="9.679499575"> >> <ele>435.413042</ele> >> - <time>2009-09-10T03:07:53Z</time> >> + <time>2009-09-10T21:20:09Z</time> >> <speed>0.000000</speed> >> <name>TP0009</name> >> </trkpt> >> @@ -100,13 +100,13 @@ >> </trkpt> >> <trkpt lat="47.547749767" lon="9.679499575"> >> <ele>435.413042</ele> >> - <time>1999-08-15T22:21:39Z</time> >> + <time>1999-08-28T01:37:55Z</time> >> <speed>0.000000</speed> >> <name>TP0012</name> >> </trkpt> >> <trkpt lat="47.547749767" lon="9.679499575"> >> <ele>435.413042</ele> >> - <time>1999-08-16T08:43:31Z</time> >> + <time>1999-08-28T11:59:47Z</time> >> <speed>0.000000</speed> >> <name>TP0013</name> >> </trkpt> >> @@ -124,13 +124,13 @@ >> </trkpt> >> <trkpt lat="47.547749767" lon="9.679499575"> >> <ele>435.413042</ele> >> - <time>2019-03-24T22:21:39Z</time> >> + <time>2019-04-06T01:37:55Z</time> >> <speed>27.777779</speed> >> <name>TP0016</name> >> </trkpt> >> <trkpt lat="47.547749767" lon="9.679499575"> >> <ele>435.413042</ele> >> - <time>2019-03-25T20:42:31Z</time> >> + <time>2019-04-06T23:58:47Z</time> >> <speed>55.555557</speed> >> <name>TP0017</name> >> </trkpt> >> @@ -226,13 +226,13 @@ >> </trkpt> >> <trkpt lat="-30.376944904" lon="-97.665051294"> >> <ele>186.112471</ele> >> - <time>2019-03-24T23:21:39Z</time> >> + <time>2019-04-06T02:37:55Z</time> >> <speed>55.555557</speed> >> <name>TP0033</name> >> </trkpt> >> <trkpt lat="-30.376946121" lon="-97.665030673"> >> <ele>185.882330</ele> >> - <time>2019-03-24T15:09:23Z</time> >> + <time>2019-04-06T12:37:55Z</time> >> <speed>55.555557</speed> >> <name>TP0034</name> >> </trkpt> >> >> >> >> On Mon, May 14, 2012 at 9:01 AM, Mathias Adam <m....@ad...> wrote: >> >>> Hi, >>> >>> Am 03.05.2012 00:37, schrieb Andrew Malota: >>> >>> >>>> I'll double-check my work when I get home - i will feed the same >>>> binary file to an unpatched gpsbabel and diff the gpx files. should >>>> be >>>> same. >>>> >>>> I fed this file: >>>> https://www.2bitoperations.**com/gps/raw2.bin<https://www.2bitoperations.com/gps/raw2.bin> >>>> to both the patched amd64 binary I built as well as an unpatched i686 >>>> gpsbabel >>>> GPX output was identical, except for the timestamp in the header >>>> (expected? i didn't generate them at the EXACT same time :) ) >>>> >>>> i think life is good with the patch. can someone commit? >>>> >>>> would still be instructive to understand why the test cases aren't >>>> failing. perhaps this bin file should be added as another test case for >>>> the skytraq module? >>>> >>> >>> I'd like to get back on this: I just created a new set of test cases: >>> >>> 1) skytraq-realdata.bin consists of real log data (the old skytraq.bin >>> and your binary-from-win.log) >>> 2) skytraq-artificial.bin: artificial data, tests some more specific >>> corner cases >>> >>> The reference-gpx's were created with gpsbabel on a 32-bit i686 under >>> Linux/Debian 6.0. (even on 32-bit I had to correct a data type to get one >>> very rare case right. The discussed patch for amd64 fixes this too). >>> >>> Can someone verify on amd64? >>> >>> >>> Regards, >>> Mathias >>> >> >> > |