Thread: [Gpsbabel-misc] Raspberry Pi 3 and Garmin
Brought to you by:
robertl
From: ceelo <min...@gm...> - 2018-07-15 09:40:18
Attachments:
test.gpx
|
Hello I am trying to use gpsbabel (Version 1.5.3) on a Raspberry Pi 3 with Raspbian OS to communicate with an old Garmin Etrex Legend Hcx. The program keeps terminating with the message: "GARMIN:Can't init usb:", whatever I try. Output of uname -a: Linux raspberrypi 4.9.80-v7+ #1098 SMP Fri Mar 9 19:11:42 GMT 2018 armv7l GNU/Linux Output of dmesg: usb 1-1.3.4: new full-speed USB device number 6 using dwc_otg usb 1-1.3.4: New USB device found, idVendor=091e, idProduct=0003 usb 1-1.3.4: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Output of gpsbabel -D9 -i garmin -f usb: -o gpx - 1> test.gpx in the attachment. There seems to be communication with the Garmin unit but I can't upload nor download any data. Any help would be greatly appreciated. Kind regards, Eelco |
From: Robert L. <rob...@gp...> - 2018-07-15 10:15:16
|
Wow. That's a very unusual combination. You may be the first that's tried it. Anyone else on this list tried it? I wouldn't be surprised if libusb on the Pi is broken slightly. You may have to involve your OS vendor for help. Vendor 091e is the Garmin and we expect to have NO kernel devices bound to it. Have you successfully used this combination on a more typical computer? If so, that might point to Pi-specific issues in the kernel's HCI driver or configuration. You may find inspiration in: https://www.gpsbabel.org/os/Linux_Hotplug.html I'd hope that after 15 years, that's been fixed by now and your reported symptoms don't really match. We don't get a couple of complaints a week about it any more, but those GPSes have been out of manufacture long enough that the user pool may have dropped to zero. RJL On Sun, Jul 15, 2018 at 4:40 AM ceelo <min...@gm...> wrote: > Hello > > I am trying to use gpsbabel (Version 1.5.3) on a Raspberry Pi 3 with > Raspbian OS to communicate with an old Garmin Etrex Legend Hcx. > The program keeps terminating with the message: "GARMIN:Can't init > usb:", whatever I try. > > Output of uname -a: > Linux raspberrypi 4.9.80-v7+ #1098 SMP Fri Mar 9 19:11:42 GMT 2018 > armv7l GNU/Linux > > Output of dmesg: > usb 1-1.3.4: new full-speed USB device number 6 using dwc_otg > usb 1-1.3.4: New USB device found, idVendor=091e, idProduct=0003 > usb 1-1.3.4: New USB device strings: Mfr=0, Product=0, SerialNumber=0 > > Output of gpsbabel -D9 -i garmin -f usb: -o gpx - 1> test.gpx in the > attachment. > > There seems to be communication with the Garmin unit but I can't upload > nor download any data. > > Any help would be greatly appreciated. > > Kind regards, > > > Eelco------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > 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: Robert L. <rob...@gp...> - 2018-07-15 18:23:54
|
+the list so that someone running this combination has a chance to pipe in. So you've used it on Ubuntu and you know how this all should work and you have proof things can and do work and proven the GPS isn't broken or such. Good. That'll at least get you some A/B testing. There is nearly packet-level debugging built into our Garmin implementation that you can turn on with -D9 gpsbabel -D9 -i garmin -f usb: Be prepared for a LOT of output when it works. Most of the code at the nexus of Garmin and USB for Linux is in jeeps/gpslibusb.cc - This is the code that's the meat in the sandwich between liubusb (the lower layer talking to your kernel) and jeeps/gpsapp.c and friends. When I wrote that code, I had access to very expensive (about the price of a nice new car) USB protocol analyzers, which I no longer have. Debugging it will be you seeing how far it gets on one and comparing that to the other. You're probably going to have to get the experts of libusb and/or the USB systems for that hardware (The Pi Foundation?) and/or that Kerrnel (Debian or whomever) to get any help. That code is about 15 years in my rear view mirror at this point and it's unpleasant to read because it was trying to build a three-way abstraction at one level (linux, mac, windows - it turns out the Linux and Mac were both ultimately filled by libusb) and an internal USB driver abstraction (which it turns out we ultimately didn't need because GPS vendors came to their senses and quit bolting serial protocols onto USB like this). I can't think of anything material that's changed in the USB implementation in many years at this point. (I also don't remember getting out of bed this morning, but I know I did. :-) We've done some bulk code cleanup at the top of tree but we've intentionally treaded lightly on the Garmin code because it's fragile and expensive to retest. This is why you'll need to be very methodical when reporting these issues to your software vendors. "I'm using GPSBabel version X as provided by Y and Z with kernel versions K and L on ubuntu version U and the following packet transfer is acting differently on a Pi Model P than on x86 running on motherboard M. On Sun, Jul 15, 2018 at 8:30 AM ceelo <min...@gm...> wrote: > Hi Robert > > Thank you very much for your quick reply. > > I use gpsbabel with my Garmin successfully on a x86 ubuntu linux > machine since Qlandkartegt (that had Garmin support for my device) was > replaced by QMapShack. > > I have garmin_gps blacklisted on both machines (raspberry and x86). > I have a rules.d/garmin-rules on both machines. > > I did lsmod | grep hci on both machines: > > x86 output: > > hci 49152 2 mei_phy,pn544 > nfc 114688 2 hci,pn544 > ahci 36864 3 > sdhci_pci 28672 0 > libahci 32768 1 ahci > sdhci_acpi 16384 0 > sdhci 45056 2 sdhci_pci,sdhci_acpi > > raspberry pi output: > > hci_uart 20020 1 > btbcm 7916 1 hci_uart > bluetooth 365844 29 hci_uart,bnep,btbcm,rfcomm > > Have you any idea how to proceed to investigate the HCI driver > configuration? > > Eelco > > On Sun, 15 Jul 2018 05:14:55 -0500 > Robert Lipe <rob...@gp...> wrote: > > > Wow. That's a very unusual combination. You may be the first that's > > tried it. Anyone else on this list tried it? > > > > I wouldn't be surprised if libusb on the Pi is broken slightly. You > > may have to involve your OS vendor for help. Vendor 091e is the > > Garmin and we expect to have NO kernel devices bound to it. Have you > > successfully used this combination on a more typical computer? If so, > > that might point to Pi-specific issues in the kernel's HCI driver or > > configuration. > > > > You may find inspiration in: > > https://www.gpsbabel.org/os/Linux_Hotplug.html I'd hope that after 15 > > years, that's been fixed by now and your reported symptoms don't > > really match. We don't get a couple of complaints a week about it any > > more, but those GPSes have been out of manufacture long enough that > > the user pool may have dropped to zero. > > > > RJL > > > > On Sun, Jul 15, 2018 at 4:40 AM ceelo <min...@gm...> wrote: > > > > > Hello > > > > > > I am trying to use gpsbabel (Version 1.5.3) on a Raspberry Pi 3 with > > > Raspbian OS to communicate with an old Garmin Etrex Legend Hcx. > > > The program keeps terminating with the message: "GARMIN:Can't init > > > usb:", whatever I try. > > > > > > Output of uname -a: > > > Linux raspberrypi 4.9.80-v7+ #1098 SMP Fri Mar 9 19:11:42 GMT 2018 > > > armv7l GNU/Linux > > > > > > Output of dmesg: > > > usb 1-1.3.4: new full-speed USB device number 6 using dwc_otg > > > usb 1-1.3.4: New USB device found, idVendor=091e, idProduct=0003 > > > usb 1-1.3.4: New USB device strings: Mfr=0, Product=0, > > > SerialNumber=0 > > > > > > Output of gpsbabel -D9 -i garmin -f usb: -o gpx - 1> test.gpx in > > > the attachment. > > > > > > There seems to be communication with the Garmin unit but I can't > > > upload nor download any data. > > > > > > Any help would be greatly appreciated. > > > > > > Kind regards, > > > > > > > > > > Eelco------------------------------------------------------------------------------ > > > Check out the vibrant tech community on one of the world's most > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > > > 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: ceelo <min...@gm...> - 2018-07-15 21:30:22
Attachments:
test.gpx
|
OK, thanks for your hints. I am going to compare the output gpsbabel on both machines and see how far I can get. Btw in the initial mail I had attached the file test.gpx which is the output of "gpsbabel -D9 -i garmin -f usb: -o gpx -F - " on the Raspberry . It shows communication with the Garmin unit: it detects its model, software version, GPS software version. Isn't it strange that gpsbabel is capable of reading these data and complaining about initialisation of the bus at the same time? On Sun, 15 Jul 2018 13:23:32 -0500 Robert Lipe <rob...@gp...> wrote: > +the list so that someone running this combination has a chance to > pipe in. > > So you've used it on Ubuntu and you know how this all should work and > you have proof things can and do work and proven the GPS isn't broken > or such. Good. That'll at least get you some A/B testing. > > There is nearly packet-level debugging built into our Garmin > implementation that you can turn on with -D9 > gpsbabel -D9 -i garmin -f usb: > Be prepared for a LOT of output when it works. > > Most of the code at the nexus of Garmin and USB for Linux is in > jeeps/gpslibusb.cc - This is the code that's the meat in the sandwich > between liubusb (the lower layer talking to your kernel) and > jeeps/gpsapp.c and friends. > > When I wrote that code, I had access to very expensive (about the > price of a nice new car) USB protocol analyzers, which I no longer > have. Debugging it will be you seeing how far it gets on one and > comparing that to the other. You're probably going to have to get the > experts of libusb and/or the USB systems for that hardware (The Pi > Foundation?) and/or that Kerrnel (Debian or whomever) to get any > help. That code is about 15 years in my rear view mirror at this > point and it's unpleasant to read because it was trying to build a > three-way abstraction at one level (linux, mac, windows - it turns > out the Linux and Mac were both ultimately filled by libusb) and an > internal USB driver abstraction (which it turns out we ultimately > didn't need because GPS vendors came to their senses and quit bolting > serial protocols onto USB like this). > > I can't think of anything material that's changed in the USB > implementation in many years at this point. (I also don't remember > getting out of bed this morning, but I know I did. :-) We've done > some bulk code cleanup at the top of tree but we've intentionally > treaded lightly on the Garmin code because it's fragile and expensive > to retest. This is why you'll need to be very methodical when > reporting these issues to your software vendors. "I'm using GPSBabel > version X as provided by Y and Z with kernel versions K and L on > ubuntu version U and the following packet transfer is acting > differently on a Pi Model P than on x86 running on motherboard M. > > On Sun, Jul 15, 2018 at 8:30 AM ceelo <min...@gm...> wrote: > > > Hi Robert > > > > Thank you very much for your quick reply. > > > > I use gpsbabel with my Garmin successfully on a x86 ubuntu linux > > machine since Qlandkartegt (that had Garmin support for my device) > > was replaced by QMapShack. > > > > I have garmin_gps blacklisted on both machines (raspberry and x86). > > I have a rules.d/garmin-rules on both machines. > > > > I did lsmod | grep hci on both machines: > > > > x86 output: > > > > hci 49152 2 mei_phy,pn544 > > nfc 114688 2 hci,pn544 > > ahci 36864 3 > > sdhci_pci 28672 0 > > libahci 32768 1 ahci > > sdhci_acpi 16384 0 > > sdhci 45056 2 sdhci_pci,sdhci_acpi > > > > raspberry pi output: > > > > hci_uart 20020 1 > > btbcm 7916 1 hci_uart > > bluetooth 365844 29 hci_uart,bnep,btbcm,rfcomm > > > > Have you any idea how to proceed to investigate the HCI driver > > configuration? > > > > Eelco > > > > On Sun, 15 Jul 2018 05:14:55 -0500 > > Robert Lipe <rob...@gp...> wrote: > > > > > Wow. That's a very unusual combination. You may be the first > > > that's tried it. Anyone else on this list tried it? > > > > > > I wouldn't be surprised if libusb on the Pi is broken slightly. > > > You may have to involve your OS vendor for help. Vendor 091e is > > > the Garmin and we expect to have NO kernel devices bound to it. > > > Have you successfully used this combination on a more typical > > > computer? If so, that might point to Pi-specific issues in the > > > kernel's HCI driver or configuration. > > > > > > You may find inspiration in: > > > https://www.gpsbabel.org/os/Linux_Hotplug.html I'd hope that > > > after 15 years, that's been fixed by now and your reported > > > symptoms don't really match. We don't get a couple of complaints > > > a week about it any more, but those GPSes have been out of > > > manufacture long enough that the user pool may have dropped to > > > zero. > > > > > > RJL > > > > > > On Sun, Jul 15, 2018 at 4:40 AM ceelo <min...@gm...> > > > wrote: > > > > Hello > > > > > > > > I am trying to use gpsbabel (Version 1.5.3) on a Raspberry Pi 3 > > > > with Raspbian OS to communicate with an old Garmin Etrex Legend > > > > Hcx. The program keeps terminating with the message: > > > > "GARMIN:Can't init usb:", whatever I try. > > > > > > > > Output of uname -a: > > > > Linux raspberrypi 4.9.80-v7+ #1098 SMP Fri Mar 9 19:11:42 GMT > > > > 2018 armv7l GNU/Linux > > > > > > > > Output of dmesg: > > > > usb 1-1.3.4: new full-speed USB device number 6 using dwc_otg > > > > usb 1-1.3.4: New USB device found, idVendor=091e, idProduct=0003 > > > > usb 1-1.3.4: New USB device strings: Mfr=0, Product=0, > > > > SerialNumber=0 > > > > > > > > Output of gpsbabel -D9 -i garmin -f usb: -o gpx - 1> test.gpx > > > > in the attachment. > > > > > > > > There seems to be communication with the Garmin unit but I > > > > can't upload nor download any data. > > > > > > > > Any help would be greatly appreciated. > > > > > > > > Kind regards, > > > > > > > > > > > > > > Eelco------------------------------------------------------------------------------ > > > > Check out the vibrant tech community on one of the world's most > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > _______________________________________________ > > > > 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: Robert L. <rob...@gp...> - 2018-07-15 23:31:56
|
Since I knew the info I'd be looking for wasn't GPX info and if it failed, it was long before we'd have written any GPX file, it didn't occur to me to open the GPX file that doesn't have GPX in it. :-) It definitely gets a healthy way into the initialization. I *think* we've made it through GPS_A000() in gpsapp.cc and have returned from GPS_A001 back to GPS_A000. A))) must have returned success becuase we continue on to GPS_COMMAND_GET_TIME() which we see in the final packets: TX [14]:14 00 00 00 0a 00 00 00 02 00 00 00 05 00 ..............(CMDDAT Xfer Time) RX (bulk) [0]:(RET2INTR) RX (intr) [12]:00 00 00 00 02 00 00 00 00 00 00 00 ............(REQBLK ) RX (bulk) [20]:14 00 00 00 0e 00 00 00 08 00 00 00 02 1c f6 07 09 00 01 37 ...................7(DATTIM ) RX (bulk) [0]:(RET2INTR) GARMIN:Can't init usb: So we're inside GPS_Command_Get_Time() The capability for an A600 packet has been determined to be a D600 frame as reported above: Capability A600: D600 so we head into GPS_A600_Get(). Error logging in this function is a bit sparse. We build a XferTime packet and transfer it and look for an ack. We then attempt a read and request an ack. On USB, the acks don't exist but we can see we issue the Xfer Time and get an empty read on the bulk piple (maybe that's how they did acks when moving from serial. It's been a while.) We see we get back a DATTIME packet so we probably pass this to D600_Get() I don't feel like digging up the specification, but that's easy enough to decode: p = packet.data; ts.tm_mon = *p++ - 1; ts.tm_mday = *p++; ts.tm_year = (int32) GPS_Util_Get_Short(p) - 1900; p+=2; ts.tm_hour = (int32) GPS_Util_Get_Short(p); p+=2; ts.tm_min = *p++; ts.tm_sec = *p++; so month is February. mday is 28 We pull 0x7f6 (which is 2038 - which sounds frighteningly familiar) and subtract 1900) and stuff that into tm_year. Hour becomes 9 ( Minutes is 1 Seconds is 55. This time is after 2038-01-19 so on a 32-bit system (most Pis run this way), this is probably going to blow up. mktme will fail and the error will be propagated back to the top. This is a ridiculously specific failure. Are you absolutely certain this GPS works on your other computer? Is your other computer perhaps a 64-bit machine? Does the time on your GPS perhaps display a stupid value? I agree the error handling in this path is atrocious and the code path in question is not year 2038 ready on 32-bit systems where time_t is an int. (I pray that these glorified serial Garmins will finally be out of my life by 2038...) Is it possible that the key isn't Raspberry Pi USB stack at all, but instead a whacked out GPS that's hanging out with Marty McFly <https://www.youtube.com/watch?v=wO4frwbZep8> and that it worked on the other system because it's 64 bit? For grins, try building a 32-bit GPSBabel on your "real" computer and see if that fails in the same way. Man, this stuff is expensive to track down... On Sun, Jul 15, 2018 at 4:30 PM ceelo <min...@gm...> wrote: > OK, thanks for your hints. I am going to compare the output gpsbabel on > both machines and see how far I can get. > Btw in the initial mail I had attached the file > test.gpx which is the output of > "gpsbabel -D9 -i garmin -f usb: -o gpx -F - " > on the Raspberry . It shows communication with the Garmin unit: it > detects its model, software version, GPS software version. Isn't it > strange that gpsbabel is capable of reading these data and complaining > about initialisation of the bus at the same time? > > > > On Sun, 15 Jul 2018 13:23:32 -0500 > Robert Lipe <rob...@gp...> wrote: > > > +the list so that someone running this combination has a chance to > > pipe in. > > > > So you've used it on Ubuntu and you know how this all should work and > > you have proof things can and do work and proven the GPS isn't broken > > or such. Good. That'll at least get you some A/B testing. > > > > There is nearly packet-level debugging built into our Garmin > > implementation that you can turn on with -D9 > > gpsbabel -D9 -i garmin -f usb: > > Be prepared for a LOT of output when it works. > > > > Most of the code at the nexus of Garmin and USB for Linux is in > > jeeps/gpslibusb.cc - This is the code that's the meat in the sandwich > > between liubusb (the lower layer talking to your kernel) and > > jeeps/gpsapp.c and friends. > > > > When I wrote that code, I had access to very expensive (about the > > price of a nice new car) USB protocol analyzers, which I no longer > > have. Debugging it will be you seeing how far it gets on one and > > comparing that to the other. You're probably going to have to get the > > experts of libusb and/or the USB systems for that hardware (The Pi > > Foundation?) and/or that Kerrnel (Debian or whomever) to get any > > help. That code is about 15 years in my rear view mirror at this > > point and it's unpleasant to read because it was trying to build a > > three-way abstraction at one level (linux, mac, windows - it turns > > out the Linux and Mac were both ultimately filled by libusb) and an > > internal USB driver abstraction (which it turns out we ultimately > > didn't need because GPS vendors came to their senses and quit bolting > > serial protocols onto USB like this). > > > > I can't think of anything material that's changed in the USB > > implementation in many years at this point. (I also don't remember > > getting out of bed this morning, but I know I did. :-) We've done > > some bulk code cleanup at the top of tree but we've intentionally > > treaded lightly on the Garmin code because it's fragile and expensive > > to retest. This is why you'll need to be very methodical when > > reporting these issues to your software vendors. "I'm using GPSBabel > > version X as provided by Y and Z with kernel versions K and L on > > ubuntu version U and the following packet transfer is acting > > differently on a Pi Model P than on x86 running on motherboard M. > > > > On Sun, Jul 15, 2018 at 8:30 AM ceelo <min...@gm...> wrote: > > > > > Hi Robert > > > > > > Thank you very much for your quick reply. > > > > > > I use gpsbabel with my Garmin successfully on a x86 ubuntu linux > > > machine since Qlandkartegt (that had Garmin support for my device) > > > was replaced by QMapShack. > > > > > > I have garmin_gps blacklisted on both machines (raspberry and x86). > > > I have a rules.d/garmin-rules on both machines. > > > > > > I did lsmod | grep hci on both machines: > > > > > > x86 output: > > > > > > hci 49152 2 mei_phy,pn544 > > > nfc 114688 2 hci,pn544 > > > ahci 36864 3 > > > sdhci_pci 28672 0 > > > libahci 32768 1 ahci > > > sdhci_acpi 16384 0 > > > sdhci 45056 2 sdhci_pci,sdhci_acpi > > > > > > raspberry pi output: > > > > > > hci_uart 20020 1 > > > btbcm 7916 1 hci_uart > > > bluetooth 365844 29 hci_uart,bnep,btbcm,rfcomm > > > > > > Have you any idea how to proceed to investigate the HCI driver > > > configuration? > > > > > > Eelco > > > > > > On Sun, 15 Jul 2018 05:14:55 -0500 > > > Robert Lipe <rob...@gp...> wrote: > > > > > > > Wow. That's a very unusual combination. You may be the first > > > > that's tried it. Anyone else on this list tried it? > > > > > > > > I wouldn't be surprised if libusb on the Pi is broken slightly. > > > > You may have to involve your OS vendor for help. Vendor 091e is > > > > the Garmin and we expect to have NO kernel devices bound to it. > > > > Have you successfully used this combination on a more typical > > > > computer? If so, that might point to Pi-specific issues in the > > > > kernel's HCI driver or configuration. > > > > > > > > You may find inspiration in: > > > > https://www.gpsbabel.org/os/Linux_Hotplug.html I'd hope that > > > > after 15 years, that's been fixed by now and your reported > > > > symptoms don't really match. We don't get a couple of complaints > > > > a week about it any more, but those GPSes have been out of > > > > manufacture long enough that the user pool may have dropped to > > > > zero. > > > > > > > > RJL > > > > > > > > On Sun, Jul 15, 2018 at 4:40 AM ceelo <min...@gm...> > > > > wrote: > > > > > Hello > > > > > > > > > > I am trying to use gpsbabel (Version 1.5.3) on a Raspberry Pi 3 > > > > > with Raspbian OS to communicate with an old Garmin Etrex Legend > > > > > Hcx. The program keeps terminating with the message: > > > > > "GARMIN:Can't init usb:", whatever I try. > > > > > > > > > > Output of uname -a: > > > > > Linux raspberrypi 4.9.80-v7+ #1098 SMP Fri Mar 9 19:11:42 GMT > > > > > 2018 armv7l GNU/Linux > > > > > > > > > > Output of dmesg: > > > > > usb 1-1.3.4: new full-speed USB device number 6 using dwc_otg > > > > > usb 1-1.3.4: New USB device found, idVendor=091e, idProduct=0003 > > > > > usb 1-1.3.4: New USB device strings: Mfr=0, Product=0, > > > > > SerialNumber=0 > > > > > > > > > > Output of gpsbabel -D9 -i garmin -f usb: -o gpx - 1> test.gpx > > > > > in the attachment. > > > > > > > > > > There seems to be communication with the Garmin unit but I > > > > > can't upload nor download any data. > > > > > > > > > > Any help would be greatly appreciated. > > > > > > > > > > Kind regards, > > > > > > > > > > > > > > > > > > > Eelco------------------------------------------------------------------------------ > > > > > > Check out the vibrant tech community on one of the world's most > > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > > _______________________________________________ > > > > > 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: ceelo <min...@gm...> - 2018-07-16 08:38:45
Attachments:
out.txt
|
Wow, congratulations, it seems you found the source of my problem. My x86 computer is indeed a 64 bit one. The Garmin is indeed showing the wrong date: today it is 1-MAR-2038. My apologies for not mentioning that in the first place. It just didn't seem relevant to me. I had already tried to correct the date with gpsbabel -D9 -i garmin -f usb: -o garmin,resettime=1 -F usb: on the x86. The command terminated fine, Garmin responded with a beep but the date didn't change. The output is in out.txt in the attachment. So if there is a way to correct the date in my Garmin unit it might work on the Raspberry too. I also tried several times to hard reset the Garmin but the date remains the same. The resettime option was build in for specific garmin etrex models according to the help file. Is there a way to adapt the code to include the etrex legend HCx model? On Sun, 15 Jul 2018 18:31:35 -0500 Robert Lipe <rob...@gp...> wrote: > Since I knew the info I'd be looking for wasn't GPX info and if it > failed, it was long before we'd have written any GPX file, it didn't > occur to me to open the GPX file that doesn't have GPX in it. :-) > > It definitely gets a healthy way into the initialization. I *think* > we've made it through GPS_A000() in gpsapp.cc and have returned from > GPS_A001 back to GPS_A000. A))) must have returned success becuase we > continue on to GPS_COMMAND_GET_TIME() which we see in the final > packets: > > TX [14]:14 00 00 00 0a 00 00 00 02 00 00 00 05 > 00 ..............(CMDDAT Xfer Time) > RX (bulk) [0]:(RET2INTR) > RX (intr) [12]:00 00 00 00 02 00 00 00 00 00 00 > 00 ............(REQBLK ) RX (bulk) [20]:14 00 00 00 0e 00 00 00 08 > 00 00 00 02 1c f6 07 09 00 01 37 ...................7(DATTIM ) > RX (bulk) [0]:(RET2INTR) > GARMIN:Can't init usb: > > So we're inside GPS_Command_Get_Time() The capability for an A600 > packet has been determined to be a D600 frame as reported above: > > Capability A600: D600 > > so we head into GPS_A600_Get(). Error logging in this function is a > bit sparse. We build a XferTime packet and transfer it and look for > an ack. We then attempt a read and request an ack. On USB, the acks > don't exist but we can see we issue the Xfer Time and get an empty > read on the bulk piple (maybe that's how they did acks when moving > from serial. It's been a while.) We see we get back a DATTIME packet > so we probably pass this to D600_Get() I don't feel like digging up > the specification, but that's easy enough to decode: > > > p = packet.data; > > ts.tm_mon = *p++ - 1; > ts.tm_mday = *p++; > ts.tm_year = (int32) GPS_Util_Get_Short(p) - 1900; > p+=2; > ts.tm_hour = (int32) GPS_Util_Get_Short(p); > p+=2; > ts.tm_min = *p++; > ts.tm_sec = *p++; > > so month is February. > mday is 28 > We pull 0x7f6 (which is 2038 - which sounds frighteningly familiar) > and subtract 1900) and stuff that into tm_year. > Hour becomes 9 ( > Minutes is 1 > Seconds is 55. > > This time is after 2038-01-19 so on a 32-bit system (most Pis run this > way), this is probably going to blow up. mktme will fail and the > error will be propagated back to the top. > > > This is a ridiculously specific failure. Are you absolutely certain > this GPS works on your other computer? Is your other computer perhaps > a 64-bit machine? Does the time on your GPS perhaps display a stupid > value? > > I agree the error handling in this path is atrocious and the code > path in question is not year 2038 ready on 32-bit systems where > time_t is an int. (I pray that these glorified serial Garmins will > finally be out of my life by 2038...) > > > Is it possible that the key isn't Raspberry Pi USB stack at all, but > instead a whacked out GPS that's hanging out with Marty McFly > <https://www.youtube.com/watch?v=wO4frwbZep8> and that it worked on > the other system because it's 64 bit? For grins, try building a > 32-bit GPSBabel on your "real" computer and see if that fails in the > same way. > > Man, this stuff is expensive to track down... > > > > > > On Sun, Jul 15, 2018 at 4:30 PM ceelo <min...@gm...> wrote: > > > OK, thanks for your hints. I am going to compare the output > > gpsbabel on both machines and see how far I can get. > > Btw in the initial mail I had attached the file > > test.gpx which is the output of > > "gpsbabel -D9 -i garmin -f usb: -o gpx -F - " > > on the Raspberry . It shows communication with the Garmin unit: it > > detects its model, software version, GPS software version. Isn't it > > strange that gpsbabel is capable of reading these data and > > complaining about initialisation of the bus at the same time? > > > > > > > > On Sun, 15 Jul 2018 13:23:32 -0500 > > Robert Lipe <rob...@gp...> wrote: > > > > > +the list so that someone running this combination has a chance to > > > pipe in. > > > > > > So you've used it on Ubuntu and you know how this all should work > > > and you have proof things can and do work and proven the GPS > > > isn't broken or such. Good. That'll at least get you some A/B > > > testing. > > > > > > There is nearly packet-level debugging built into our Garmin > > > implementation that you can turn on with -D9 > > > gpsbabel -D9 -i garmin -f usb: > > > Be prepared for a LOT of output when it works. > > > > > > Most of the code at the nexus of Garmin and USB for Linux is in > > > jeeps/gpslibusb.cc - This is the code that's the meat in the > > > sandwich between liubusb (the lower layer talking to your kernel) > > > and jeeps/gpsapp.c and friends. > > > > > > When I wrote that code, I had access to very expensive (about the > > > price of a nice new car) USB protocol analyzers, which I no longer > > > have. Debugging it will be you seeing how far it gets on one and > > > comparing that to the other. You're probably going to have to get > > > the experts of libusb and/or the USB systems for that hardware > > > (The Pi Foundation?) and/or that Kerrnel (Debian or whomever) to > > > get any help. That code is about 15 years in my rear view mirror > > > at this point and it's unpleasant to read because it was trying > > > to build a three-way abstraction at one level (linux, mac, > > > windows - it turns out the Linux and Mac were both ultimately > > > filled by libusb) and an internal USB driver abstraction (which > > > it turns out we ultimately didn't need because GPS vendors came > > > to their senses and quit bolting serial protocols onto USB like > > > this). > > > > > > I can't think of anything material that's changed in the USB > > > implementation in many years at this point. (I also don't remember > > > getting out of bed this morning, but I know I did. :-) We've done > > > some bulk code cleanup at the top of tree but we've intentionally > > > treaded lightly on the Garmin code because it's fragile and > > > expensive to retest. This is why you'll need to be very > > > methodical when reporting these issues to your software vendors. > > > "I'm using GPSBabel version X as provided by Y and Z with kernel > > > versions K and L on ubuntu version U and the following packet > > > transfer is acting differently on a Pi Model P than on x86 > > > running on motherboard M. > > > > > > On Sun, Jul 15, 2018 at 8:30 AM ceelo <min...@gm...> > > > wrote: > > > > Hi Robert > > > > > > > > Thank you very much for your quick reply. > > > > > > > > I use gpsbabel with my Garmin successfully on a x86 ubuntu linux > > > > machine since Qlandkartegt (that had Garmin support for my > > > > device) was replaced by QMapShack. > > > > > > > > I have garmin_gps blacklisted on both machines (raspberry and > > > > x86). I have a rules.d/garmin-rules on both machines. > > > > > > > > I did lsmod | grep hci on both machines: > > > > > > > > x86 output: > > > > > > > > hci 49152 2 mei_phy,pn544 > > > > nfc 114688 2 hci,pn544 > > > > ahci 36864 3 > > > > sdhci_pci 28672 0 > > > > libahci 32768 1 ahci > > > > sdhci_acpi 16384 0 > > > > sdhci 45056 2 sdhci_pci,sdhci_acpi > > > > > > > > raspberry pi output: > > > > > > > > hci_uart 20020 1 > > > > btbcm 7916 1 hci_uart > > > > bluetooth 365844 29 hci_uart,bnep,btbcm,rfcomm > > > > > > > > Have you any idea how to proceed to investigate the HCI driver > > > > configuration? > > > > > > > > Eelco > > > > > > > > On Sun, 15 Jul 2018 05:14:55 -0500 > > > > Robert Lipe <rob...@gp...> wrote: > > > > > > > > > Wow. That's a very unusual combination. You may be the first > > > > > that's tried it. Anyone else on this list tried it? > > > > > > > > > > I wouldn't be surprised if libusb on the Pi is broken > > > > > slightly. You may have to involve your OS vendor for help. > > > > > Vendor 091e is the Garmin and we expect to have NO kernel > > > > > devices bound to it. Have you successfully used this > > > > > combination on a more typical computer? If so, that might > > > > > point to Pi-specific issues in the kernel's HCI driver or > > > > > configuration. > > > > > > > > > > You may find inspiration in: > > > > > https://www.gpsbabel.org/os/Linux_Hotplug.html I'd hope that > > > > > after 15 years, that's been fixed by now and your reported > > > > > symptoms don't really match. We don't get a couple of > > > > > complaints a week about it any more, but those GPSes have > > > > > been out of manufacture long enough that the user pool may > > > > > have dropped to zero. > > > > > > > > > > RJL > > > > > > > > > > On Sun, Jul 15, 2018 at 4:40 AM ceelo <min...@gm...> > > > > > wrote: > > > > > > Hello > > > > > > > > > > > > I am trying to use gpsbabel (Version 1.5.3) on a Raspberry > > > > > > Pi 3 with Raspbian OS to communicate with an old Garmin > > > > > > Etrex Legend Hcx. The program keeps terminating with the > > > > > > message: "GARMIN:Can't init usb:", whatever I try. > > > > > > > > > > > > Output of uname -a: > > > > > > Linux raspberrypi 4.9.80-v7+ #1098 SMP Fri Mar 9 19:11:42 > > > > > > GMT 2018 armv7l GNU/Linux > > > > > > > > > > > > Output of dmesg: > > > > > > usb 1-1.3.4: new full-speed USB device number 6 using > > > > > > dwc_otg usb 1-1.3.4: New USB device found, idVendor=091e, > > > > > > idProduct=0003 usb 1-1.3.4: New USB device strings: Mfr=0, > > > > > > Product=0, SerialNumber=0 > > > > > > > > > > > > Output of gpsbabel -D9 -i garmin -f usb: -o gpx - 1> > > > > > > test.gpx in the attachment. > > > > > > > > > > > > There seems to be communication with the Garmin unit but I > > > > > > can't upload nor download any data. > > > > > > > > > > > > Any help would be greatly appreciated. > > > > > > > > > > > > Kind regards, > > > > > > > > > > > > > > > > > > > > > > > > Eelco------------------------------------------------------------------------------ > > > > > > > > Check out the vibrant tech community on one of the world's > > > > > > most engaging tech sites, Slashdot.org! > > > > > > http://sdm.link/slashdot > > > > > > _______________________________________________ > > > > > > 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: Gary T. <g...@el...> - 2018-07-16 23:31:13
|
Leave it outside for a bit? That's the 'normal' way to set the time. On 16/07/2018 20:38, ceelo wrote: > Wow, congratulations, it seems you found the source of my problem. > My x86 computer is indeed a 64 bit one. > The Garmin is indeed showing the wrong date: today it is 1-MAR-2038. My > apologies for not mentioning that in the first place. It just didn't > seem relevant to me. I had already tried to correct the date with > gpsbabel -D9 -i garmin -f usb: -o garmin,resettime=1 -F usb: > on the x86. The command terminated fine, Garmin responded with a beep > but the date didn't change. The output is in out.txt in the attachment. > > So if there is a way to correct the date in my Garmin unit it might > work on the Raspberry too. I also tried several times to hard reset the > Garmin but the date remains the same. > > The resettime option was build in for specific garmin etrex models > according to the help file. Is there a way to adapt the code to include > the etrex legend HCx model? > > > On Sun, 15 Jul 2018 18:31:35 -0500 > Robert Lipe <rob...@gp...> wrote: > >> Since I knew the info I'd be looking for wasn't GPX info and if it >> failed, it was long before we'd have written any GPX file, it didn't >> occur to me to open the GPX file that doesn't have GPX in it. :-) >> >> It definitely gets a healthy way into the initialization. I *think* >> we've made it through GPS_A000() in gpsapp.cc and have returned from >> GPS_A001 back to GPS_A000. A))) must have returned success becuase we >> continue on to GPS_COMMAND_GET_TIME() which we see in the final >> packets: >> >> TX [14]:14 00 00 00 0a 00 00 00 02 00 00 00 05 >> 00 ..............(CMDDAT Xfer Time) >> RX (bulk) [0]:(RET2INTR) >> RX (intr) [12]:00 00 00 00 02 00 00 00 00 00 00 >> 00 ............(REQBLK ) RX (bulk) [20]:14 00 00 00 0e 00 00 00 08 >> 00 00 00 02 1c f6 07 09 00 01 37 ...................7(DATTIM ) >> RX (bulk) [0]:(RET2INTR) >> GARMIN:Can't init usb: >> >> So we're inside GPS_Command_Get_Time() The capability for an A600 >> packet has been determined to be a D600 frame as reported above: >> >> Capability A600: D600 >> >> so we head into GPS_A600_Get(). Error logging in this function is a >> bit sparse. We build a XferTime packet and transfer it and look for >> an ack. We then attempt a read and request an ack. On USB, the acks >> don't exist but we can see we issue the Xfer Time and get an empty >> read on the bulk piple (maybe that's how they did acks when moving >> from serial. It's been a while.) We see we get back a DATTIME packet >> so we probably pass this to D600_Get() I don't feel like digging up >> the specification, but that's easy enough to decode: >> >> >> p = packet.data; >> >> ts.tm_mon = *p++ - 1; >> ts.tm_mday = *p++; >> ts.tm_year = (int32) GPS_Util_Get_Short(p) - 1900; >> p+=2; >> ts.tm_hour = (int32) GPS_Util_Get_Short(p); >> p+=2; >> ts.tm_min = *p++; >> ts.tm_sec = *p++; >> >> so month is February. >> mday is 28 >> We pull 0x7f6 (which is 2038 - which sounds frighteningly familiar) >> and subtract 1900) and stuff that into tm_year. >> Hour becomes 9 ( >> Minutes is 1 >> Seconds is 55. >> >> This time is after 2038-01-19 so on a 32-bit system (most Pis run this >> way), this is probably going to blow up. mktme will fail and the >> error will be propagated back to the top. >> >> >> This is a ridiculously specific failure. Are you absolutely certain >> this GPS works on your other computer? Is your other computer perhaps >> a 64-bit machine? Does the time on your GPS perhaps display a stupid >> value? >> >> I agree the error handling in this path is atrocious and the code >> path in question is not year 2038 ready on 32-bit systems where >> time_t is an int. (I pray that these glorified serial Garmins will >> finally be out of my life by 2038...) >> >> >> Is it possible that the key isn't Raspberry Pi USB stack at all, but >> instead a whacked out GPS that's hanging out with Marty McFly >> <https://www.youtube.com/watch?v=wO4frwbZep8> and that it worked on >> the other system because it's 64 bit? For grins, try building a >> 32-bit GPSBabel on your "real" computer and see if that fails in the >> same way. >> >> Man, this stuff is expensive to track down... >> >> >> >> >> >> On Sun, Jul 15, 2018 at 4:30 PM ceelo <min...@gm...> wrote: >> >>> OK, thanks for your hints. I am going to compare the output >>> gpsbabel on both machines and see how far I can get. >>> Btw in the initial mail I had attached the file >>> test.gpx which is the output of >>> "gpsbabel -D9 -i garmin -f usb: -o gpx -F - " >>> on the Raspberry . It shows communication with the Garmin unit: it >>> detects its model, software version, GPS software version. Isn't it >>> strange that gpsbabel is capable of reading these data and >>> complaining about initialisation of the bus at the same time? >>> >>> >>> >>> On Sun, 15 Jul 2018 13:23:32 -0500 >>> Robert Lipe <rob...@gp...> wrote: >>> >>>> +the list so that someone running this combination has a chance to >>>> pipe in. >>>> >>>> So you've used it on Ubuntu and you know how this all should work >>>> and you have proof things can and do work and proven the GPS >>>> isn't broken or such. Good. That'll at least get you some A/B >>>> testing. >>>> >>>> There is nearly packet-level debugging built into our Garmin >>>> implementation that you can turn on with -D9 >>>> gpsbabel -D9 -i garmin -f usb: >>>> Be prepared for a LOT of output when it works. >>>> >>>> Most of the code at the nexus of Garmin and USB for Linux is in >>>> jeeps/gpslibusb.cc - This is the code that's the meat in the >>>> sandwich between liubusb (the lower layer talking to your kernel) >>>> and jeeps/gpsapp.c and friends. >>>> >>>> When I wrote that code, I had access to very expensive (about the >>>> price of a nice new car) USB protocol analyzers, which I no longer >>>> have. Debugging it will be you seeing how far it gets on one and >>>> comparing that to the other. You're probably going to have to get >>>> the experts of libusb and/or the USB systems for that hardware >>>> (The Pi Foundation?) and/or that Kerrnel (Debian or whomever) to >>>> get any help. That code is about 15 years in my rear view mirror >>>> at this point and it's unpleasant to read because it was trying >>>> to build a three-way abstraction at one level (linux, mac, >>>> windows - it turns out the Linux and Mac were both ultimately >>>> filled by libusb) and an internal USB driver abstraction (which >>>> it turns out we ultimately didn't need because GPS vendors came >>>> to their senses and quit bolting serial protocols onto USB like >>>> this). >>>> >>>> I can't think of anything material that's changed in the USB >>>> implementation in many years at this point. (I also don't remember >>>> getting out of bed this morning, but I know I did. :-) We've done >>>> some bulk code cleanup at the top of tree but we've intentionally >>>> treaded lightly on the Garmin code because it's fragile and >>>> expensive to retest. This is why you'll need to be very >>>> methodical when reporting these issues to your software vendors. >>>> "I'm using GPSBabel version X as provided by Y and Z with kernel >>>> versions K and L on ubuntu version U and the following packet >>>> transfer is acting differently on a Pi Model P than on x86 >>>> running on motherboard M. >>>> >>>> On Sun, Jul 15, 2018 at 8:30 AM ceelo <min...@gm...> >>>> wrote: >>>>> Hi Robert >>>>> >>>>> Thank you very much for your quick reply. >>>>> >>>>> I use gpsbabel with my Garmin successfully on a x86 ubuntu linux >>>>> machine since Qlandkartegt (that had Garmin support for my >>>>> device) was replaced by QMapShack. >>>>> >>>>> I have garmin_gps blacklisted on both machines (raspberry and >>>>> x86). I have a rules.d/garmin-rules on both machines. >>>>> >>>>> I did lsmod | grep hci on both machines: >>>>> >>>>> x86 output: >>>>> >>>>> hci 49152 2 mei_phy,pn544 >>>>> nfc 114688 2 hci,pn544 >>>>> ahci 36864 3 >>>>> sdhci_pci 28672 0 >>>>> libahci 32768 1 ahci >>>>> sdhci_acpi 16384 0 >>>>> sdhci 45056 2 sdhci_pci,sdhci_acpi >>>>> >>>>> raspberry pi output: >>>>> >>>>> hci_uart 20020 1 >>>>> btbcm 7916 1 hci_uart >>>>> bluetooth 365844 29 hci_uart,bnep,btbcm,rfcomm >>>>> >>>>> Have you any idea how to proceed to investigate the HCI driver >>>>> configuration? >>>>> >>>>> Eelco >>>>> >>>>> On Sun, 15 Jul 2018 05:14:55 -0500 >>>>> Robert Lipe <rob...@gp...> wrote: >>>>> >>>>>> Wow. That's a very unusual combination. You may be the first >>>>>> that's tried it. Anyone else on this list tried it? >>>>>> >>>>>> I wouldn't be surprised if libusb on the Pi is broken >>>>>> slightly. You may have to involve your OS vendor for help. >>>>>> Vendor 091e is the Garmin and we expect to have NO kernel >>>>>> devices bound to it. Have you successfully used this >>>>>> combination on a more typical computer? If so, that might >>>>>> point to Pi-specific issues in the kernel's HCI driver or >>>>>> configuration. >>>>>> >>>>>> You may find inspiration in: >>>>>> https://www.gpsbabel.org/os/Linux_Hotplug.html I'd hope that >>>>>> after 15 years, that's been fixed by now and your reported >>>>>> symptoms don't really match. We don't get a couple of >>>>>> complaints a week about it any more, but those GPSes have >>>>>> been out of manufacture long enough that the user pool may >>>>>> have dropped to zero. >>>>>> >>>>>> RJL >>>>>> >>>>>> On Sun, Jul 15, 2018 at 4:40 AM ceelo <min...@gm...> >>>>>> wrote: >>>>>>> Hello >>>>>>> >>>>>>> I am trying to use gpsbabel (Version 1.5.3) on a Raspberry >>>>>>> Pi 3 with Raspbian OS to communicate with an old Garmin >>>>>>> Etrex Legend Hcx. The program keeps terminating with the >>>>>>> message: "GARMIN:Can't init usb:", whatever I try. >>>>>>> >>>>>>> Output of uname -a: >>>>>>> Linux raspberrypi 4.9.80-v7+ #1098 SMP Fri Mar 9 19:11:42 >>>>>>> GMT 2018 armv7l GNU/Linux >>>>>>> >>>>>>> Output of dmesg: >>>>>>> usb 1-1.3.4: new full-speed USB device number 6 using >>>>>>> dwc_otg usb 1-1.3.4: New USB device found, idVendor=091e, >>>>>>> idProduct=0003 usb 1-1.3.4: New USB device strings: Mfr=0, >>>>>>> Product=0, SerialNumber=0 >>>>>>> >>>>>>> Output of gpsbabel -D9 -i garmin -f usb: -o gpx - 1> >>>>>>> test.gpx in the attachment. >>>>>>> >>>>>>> There seems to be communication with the Garmin unit but I >>>>>>> can't upload nor download any data. >>>>>>> >>>>>>> Any help would be greatly appreciated. >>>>>>> >>>>>>> Kind regards, >>>>>>> >>>>>>> >>>>>>> >>>>> >>> Eelco------------------------------------------------------------------------------ >>> >>>>>>> Check out the vibrant tech community on one of the world's >>>>>>> most engaging tech sites, Slashdot.org! >>>>>>> http://sdm.link/slashdot >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>> > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > 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: ceelo <min...@gm...> - 2018-07-17 16:37:02
|
Thank you Gary, but it doesn't work on this unit. I just returned from a two weeks hike with the unit turned on during the day. From day one the unit displayed the wrong date. Back home I did several hard resets and let it outside to get a new fix. That didn't change the date. It keeps displaying year 2038. Maybe this unit is suffers from the gps week roll over? On Tue, 17 Jul 2018 11:08:48 +1200 Gary Turner <g...@el...> wrote: > Leave it outside for a bit? That's the 'normal' way to set the time. > > On 16/07/2018 20:38, ceelo wrote: > > Wow, congratulations, it seems you found the source of my problem. > > My x86 computer is indeed a 64 bit one. > > The Garmin is indeed showing the wrong date: today it is > > 1-MAR-2038. My apologies for not mentioning that in the first > > place. It just didn't seem relevant to me. I had already tried to > > correct the date with gpsbabel -D9 -i garmin -f usb: -o > > garmin,resettime=1 -F usb: on the x86. The command terminated fine, > > Garmin responded with a beep but the date didn't change. The output > > is in out.txt in the attachment. > > > > So if there is a way to correct the date in my Garmin unit it might > > work on the Raspberry too. I also tried several times to hard reset > > the Garmin but the date remains the same. > > > > The resettime option was build in for specific garmin etrex models > > according to the help file. Is there a way to adapt the code to > > include the etrex legend HCx model? > > > > > > On Sun, 15 Jul 2018 18:31:35 -0500 > > Robert Lipe <rob...@gp...> wrote: > > > >> Since I knew the info I'd be looking for wasn't GPX info and if it > >> failed, it was long before we'd have written any GPX file, it > >> didn't occur to me to open the GPX file that doesn't have GPX in > >> it. :-) > >> > >> It definitely gets a healthy way into the initialization. I *think* > >> we've made it through GPS_A000() in gpsapp.cc and have returned > >> from GPS_A001 back to GPS_A000. A))) must have returned success > >> becuase we continue on to GPS_COMMAND_GET_TIME() which we see in > >> the final packets: > >> > >> TX [14]:14 00 00 00 0a 00 00 00 02 00 00 00 05 > >> 00 ..............(CMDDAT Xfer Time) > >> RX (bulk) [0]:(RET2INTR) > >> RX (intr) [12]:00 00 00 00 02 00 00 00 00 00 00 > >> 00 ............(REQBLK ) RX (bulk) [20]:14 00 00 00 0e 00 00 00 08 > >> 00 00 00 02 1c f6 07 09 00 01 37 ...................7(DATTIM ) > >> RX (bulk) [0]:(RET2INTR) > >> GARMIN:Can't init usb: > >> > >> So we're inside GPS_Command_Get_Time() The capability for an A600 > >> packet has been determined to be a D600 frame as reported above: > >> > >> Capability A600: D600 > >> > >> so we head into GPS_A600_Get(). Error logging in this function is > >> a bit sparse. We build a XferTime packet and transfer it and look > >> for an ack. We then attempt a read and request an ack. On USB, the > >> acks don't exist but we can see we issue the Xfer Time and get an > >> empty read on the bulk piple (maybe that's how they did acks when > >> moving from serial. It's been a while.) We see we get back a > >> DATTIME packet so we probably pass this to D600_Get() I don't feel > >> like digging up the specification, but that's easy enough to > >> decode: > >> > >> > >> p = packet.data; > >> > >> ts.tm_mon = *p++ - 1; > >> ts.tm_mday = *p++; > >> ts.tm_year = (int32) GPS_Util_Get_Short(p) - 1900; > >> p+=2; > >> ts.tm_hour = (int32) GPS_Util_Get_Short(p); > >> p+=2; > >> ts.tm_min = *p++; > >> ts.tm_sec = *p++; > >> > >> so month is February. > >> mday is 28 > >> We pull 0x7f6 (which is 2038 - which sounds frighteningly familiar) > >> and subtract 1900) and stuff that into tm_year. > >> Hour becomes 9 ( > >> Minutes is 1 > >> Seconds is 55. > >> > >> This time is after 2038-01-19 so on a 32-bit system (most Pis run > >> this way), this is probably going to blow up. mktme will fail and > >> the error will be propagated back to the top. > >> > >> > >> This is a ridiculously specific failure. Are you absolutely certain > >> this GPS works on your other computer? Is your other computer > >> perhaps a 64-bit machine? Does the time on your GPS perhaps > >> display a stupid value? > >> > >> I agree the error handling in this path is atrocious and the code > >> path in question is not year 2038 ready on 32-bit systems where > >> time_t is an int. (I pray that these glorified serial Garmins will > >> finally be out of my life by 2038...) > >> > >> > >> Is it possible that the key isn't Raspberry Pi USB stack at all, > >> but instead a whacked out GPS that's hanging out with Marty McFly > >> <https://www.youtube.com/watch?v=wO4frwbZep8> and that it worked on > >> the other system because it's 64 bit? For grins, try building a > >> 32-bit GPSBabel on your "real" computer and see if that fails in > >> the same way. > >> > >> Man, this stuff is expensive to track down... > >> > >> > >> > >> > >> > >> On Sun, Jul 15, 2018 at 4:30 PM ceelo <min...@gm...> > >> wrote: > >>> OK, thanks for your hints. I am going to compare the output > >>> gpsbabel on both machines and see how far I can get. > >>> Btw in the initial mail I had attached the file > >>> test.gpx which is the output of > >>> "gpsbabel -D9 -i garmin -f usb: -o gpx -F - " > >>> on the Raspberry . It shows communication with the Garmin unit: it > >>> detects its model, software version, GPS software version. Isn't > >>> it strange that gpsbabel is capable of reading these data and > >>> complaining about initialisation of the bus at the same time? > >>> > >>> > >>> > >>> On Sun, 15 Jul 2018 13:23:32 -0500 > >>> Robert Lipe <rob...@gp...> wrote: > >>> > >>>> +the list so that someone running this combination has a chance > >>>> to pipe in. > >>>> > >>>> So you've used it on Ubuntu and you know how this all should work > >>>> and you have proof things can and do work and proven the GPS > >>>> isn't broken or such. Good. That'll at least get you some A/B > >>>> testing. > >>>> > >>>> There is nearly packet-level debugging built into our Garmin > >>>> implementation that you can turn on with -D9 > >>>> gpsbabel -D9 -i garmin -f usb: > >>>> Be prepared for a LOT of output when it works. > >>>> > >>>> Most of the code at the nexus of Garmin and USB for Linux is in > >>>> jeeps/gpslibusb.cc - This is the code that's the meat in the > >>>> sandwich between liubusb (the lower layer talking to your kernel) > >>>> and jeeps/gpsapp.c and friends. > >>>> > >>>> When I wrote that code, I had access to very expensive (about the > >>>> price of a nice new car) USB protocol analyzers, which I no > >>>> longer have. Debugging it will be you seeing how far it gets on > >>>> one and comparing that to the other. You're probably going to > >>>> have to get the experts of libusb and/or the USB systems for > >>>> that hardware (The Pi Foundation?) and/or that Kerrnel (Debian > >>>> or whomever) to get any help. That code is about 15 years in my > >>>> rear view mirror at this point and it's unpleasant to read > >>>> because it was trying to build a three-way abstraction at one > >>>> level (linux, mac, windows - it turns out the Linux and Mac were > >>>> both ultimately filled by libusb) and an internal USB driver > >>>> abstraction (which it turns out we ultimately didn't need > >>>> because GPS vendors came to their senses and quit bolting serial > >>>> protocols onto USB like this). > >>>> > >>>> I can't think of anything material that's changed in the USB > >>>> implementation in many years at this point. (I also don't > >>>> remember getting out of bed this morning, but I know I did. :-) > >>>> We've done some bulk code cleanup at the top of tree but we've > >>>> intentionally treaded lightly on the Garmin code because it's > >>>> fragile and expensive to retest. This is why you'll need to be > >>>> very methodical when reporting these issues to your software > >>>> vendors. "I'm using GPSBabel version X as provided by Y and Z > >>>> with kernel versions K and L on ubuntu version U and the > >>>> following packet transfer is acting differently on a Pi Model P > >>>> than on x86 running on motherboard M. > >>>> > >>>> On Sun, Jul 15, 2018 at 8:30 AM ceelo <min...@gm...> > >>>> wrote: > >>>>> Hi Robert > >>>>> > >>>>> Thank you very much for your quick reply. > >>>>> > >>>>> I use gpsbabel with my Garmin successfully on a x86 ubuntu linux > >>>>> machine since Qlandkartegt (that had Garmin support for my > >>>>> device) was replaced by QMapShack. > >>>>> > >>>>> I have garmin_gps blacklisted on both machines (raspberry and > >>>>> x86). I have a rules.d/garmin-rules on both machines. > >>>>> > >>>>> I did lsmod | grep hci on both machines: > >>>>> > >>>>> x86 output: > >>>>> > >>>>> hci 49152 2 mei_phy,pn544 > >>>>> nfc 114688 2 hci,pn544 > >>>>> ahci 36864 3 > >>>>> sdhci_pci 28672 0 > >>>>> libahci 32768 1 ahci > >>>>> sdhci_acpi 16384 0 > >>>>> sdhci 45056 2 sdhci_pci,sdhci_acpi > >>>>> > >>>>> raspberry pi output: > >>>>> > >>>>> hci_uart 20020 1 > >>>>> btbcm 7916 1 hci_uart > >>>>> bluetooth 365844 29 hci_uart,bnep,btbcm,rfcomm > >>>>> > >>>>> Have you any idea how to proceed to investigate the HCI driver > >>>>> configuration? > >>>>> > >>>>> Eelco > >>>>> > >>>>> On Sun, 15 Jul 2018 05:14:55 -0500 > >>>>> Robert Lipe <rob...@gp...> wrote: > >>>>> > >>>>>> Wow. That's a very unusual combination. You may be the first > >>>>>> that's tried it. Anyone else on this list tried it? > >>>>>> > >>>>>> I wouldn't be surprised if libusb on the Pi is broken > >>>>>> slightly. You may have to involve your OS vendor for help. > >>>>>> Vendor 091e is the Garmin and we expect to have NO kernel > >>>>>> devices bound to it. Have you successfully used this > >>>>>> combination on a more typical computer? If so, that might > >>>>>> point to Pi-specific issues in the kernel's HCI driver or > >>>>>> configuration. > >>>>>> > >>>>>> You may find inspiration in: > >>>>>> https://www.gpsbabel.org/os/Linux_Hotplug.html I'd hope that > >>>>>> after 15 years, that's been fixed by now and your reported > >>>>>> symptoms don't really match. We don't get a couple of > >>>>>> complaints a week about it any more, but those GPSes have > >>>>>> been out of manufacture long enough that the user pool may > >>>>>> have dropped to zero. > >>>>>> > >>>>>> RJL > >>>>>> > >>>>>> On Sun, Jul 15, 2018 at 4:40 AM ceelo <min...@gm...> > >>>>>> wrote: > >>>>>>> Hello > >>>>>>> > >>>>>>> I am trying to use gpsbabel (Version 1.5.3) on a Raspberry > >>>>>>> Pi 3 with Raspbian OS to communicate with an old Garmin > >>>>>>> Etrex Legend Hcx. The program keeps terminating with the > >>>>>>> message: "GARMIN:Can't init usb:", whatever I try. > >>>>>>> > >>>>>>> Output of uname -a: > >>>>>>> Linux raspberrypi 4.9.80-v7+ #1098 SMP Fri Mar 9 19:11:42 > >>>>>>> GMT 2018 armv7l GNU/Linux > >>>>>>> > >>>>>>> Output of dmesg: > >>>>>>> usb 1-1.3.4: new full-speed USB device number 6 using > >>>>>>> dwc_otg usb 1-1.3.4: New USB device found, idVendor=091e, > >>>>>>> idProduct=0003 usb 1-1.3.4: New USB device strings: Mfr=0, > >>>>>>> Product=0, SerialNumber=0 > >>>>>>> > >>>>>>> Output of gpsbabel -D9 -i garmin -f usb: -o gpx - 1> > >>>>>>> test.gpx in the attachment. > >>>>>>> > >>>>>>> There seems to be communication with the Garmin unit but I > >>>>>>> can't upload nor download any data. > >>>>>>> > >>>>>>> Any help would be greatly appreciated. > >>>>>>> > >>>>>>> Kind regards, > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>> Eelco------------------------------------------------------------------------------ > >>> > >>>>>>> Check out the vibrant tech community on one of the world's > >>>>>>> most engaging tech sites, Slashdot.org! > >>>>>>> http://sdm.link/slashdot > >>>>>>> _______________________________________________ > >>>>>>> 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 > >>>>> > >>> > > > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > > > _______________________________________________ > > 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: Erik K. <eri...@gm...> - 2018-07-18 16:27:09
|
Am 17.07.2018 um 18:36 schrieb ceelo: > It keeps displaying year 2038. Hmmm, 2038? Perhaps something with https://en.wikipedia.org/wiki/Year_2038_problem -- Erik Krause --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus |
From: Robert L. <rob...@gp...> - 2018-07-17 21:35:48
|
We sent the packet and it didn't return an error. I think this is between you and Garmin at this point. *TX* [20]:14 00 00 00 0e 00 00 00 08 00 00 00 07 10 *e2 07 *09 00 38 2c ..................8.(DATTIM ) RX (bulk) [0]:(RET2INTR) RX (intr) [12]:00 00 00 00 02 00 00 00 00 00 00 00 ............(REQBLK ) $ bc -l bc 1.06 Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. 7E2*2018* There's some irony that GPS relies on extremely accurate time keeping and Garmin gets this so wrong on your device. Good luck. RJL On Tue, Jul 17, 2018 at 11:37 AM ceelo <min...@gm...> wrote: > Thank you Gary, but it doesn't work on this unit. > I just returned from a two weeks hike with the unit turned on > during the day. From day one the unit displayed the wrong date. Back > home I did several hard resets and let it outside to get a new fix. That > didn't change the date. It keeps displaying year 2038. > Maybe this unit is suffers from the gps week roll over? > > > On Tue, 17 Jul 2018 11:08:48 +1200 > Gary Turner <g...@el...> wrote: > > > Leave it outside for a bit? That's the 'normal' way to set the time. > > > > On 16/07/2018 20:38, ceelo wrote: > > > Wow, congratulations, it seems you found the source of my problem. > > > My x86 computer is indeed a 64 bit one. > > > The Garmin is indeed showing the wrong date: today it is > > > 1-MAR-2038. My apologies for not mentioning that in the first > > > place. It just didn't seem relevant to me. I had already tried to > > > correct the date with gpsbabel -D9 -i garmin -f usb: -o > > > garmin,resettime=1 -F usb: on the x86. The command terminated fine, > > > Garmin responded with a beep but the date didn't change. The output > > > is in out.txt in the attachment. > > > > > > So if there is a way to correct the date in my Garmin unit it might > > > work on the Raspberry too. I also tried several times to hard reset > > > the Garmin but the date remains the same. > > > > > > The resettime option was build in for specific garmin etrex models > > > according to the help file. Is there a way to adapt the code to > > > include the etrex legend HCx model? > > > > > > > > > On Sun, 15 Jul 2018 18:31:35 -0500 > > > Robert Lipe <rob...@gp...> wrote: > > > > > >> Since I knew the info I'd be looking for wasn't GPX info and if it > > >> failed, it was long before we'd have written any GPX file, it > > >> didn't occur to me to open the GPX file that doesn't have GPX in > > >> it. :-) > > >> > > >> It definitely gets a healthy way into the initialization. I *think* > > >> we've made it through GPS_A000() in gpsapp.cc and have returned > > >> from GPS_A001 back to GPS_A000. A))) must have returned success > > >> becuase we continue on to GPS_COMMAND_GET_TIME() which we see in > > >> the final packets: > > >> > > >> TX [14]:14 00 00 00 0a 00 00 00 02 00 00 00 05 > > >> 00 ..............(CMDDAT Xfer Time) > > >> RX (bulk) [0]:(RET2INTR) > > >> RX (intr) [12]:00 00 00 00 02 00 00 00 00 00 00 > > >> 00 ............(REQBLK ) RX (bulk) [20]:14 00 00 00 0e 00 00 00 08 > > >> 00 00 00 02 1c f6 07 09 00 01 37 ...................7(DATTIM ) > > >> RX (bulk) [0]:(RET2INTR) > > >> GARMIN:Can't init usb: > > >> > > >> So we're inside GPS_Command_Get_Time() The capability for an A600 > > >> packet has been determined to be a D600 frame as reported above: > > >> > > >> Capability A600: D600 > > >> > > >> so we head into GPS_A600_Get(). Error logging in this function is > > >> a bit sparse. We build a XferTime packet and transfer it and look > > >> for an ack. We then attempt a read and request an ack. On USB, the > > >> acks don't exist but we can see we issue the Xfer Time and get an > > >> empty read on the bulk piple (maybe that's how they did acks when > > >> moving from serial. It's been a while.) We see we get back a > > >> DATTIME packet so we probably pass this to D600_Get() I don't feel > > >> like digging up the specification, but that's easy enough to > > >> decode: > > >> > > >> > > >> p = packet.data; > > >> > > >> ts.tm_mon = *p++ - 1; > > >> ts.tm_mday = *p++; > > >> ts.tm_year = (int32) GPS_Util_Get_Short(p) - 1900; > > >> p+=2; > > >> ts.tm_hour = (int32) GPS_Util_Get_Short(p); > > >> p+=2; > > >> ts.tm_min = *p++; > > >> ts.tm_sec = *p++; > > >> > > >> so month is February. > > >> mday is 28 > > >> We pull 0x7f6 (which is 2038 - which sounds frighteningly familiar) > > >> and subtract 1900) and stuff that into tm_year. > > >> Hour becomes 9 ( > > >> Minutes is 1 > > >> Seconds is 55. > > >> > > >> This time is after 2038-01-19 so on a 32-bit system (most Pis run > > >> this way), this is probably going to blow up. mktme will fail and > > >> the error will be propagated back to the top. > > >> > > >> > > >> This is a ridiculously specific failure. Are you absolutely certain > > >> this GPS works on your other computer? Is your other computer > > >> perhaps a 64-bit machine? Does the time on your GPS perhaps > > >> display a stupid value? > > >> > > >> I agree the error handling in this path is atrocious and the code > > >> path in question is not year 2038 ready on 32-bit systems where > > >> time_t is an int. (I pray that these glorified serial Garmins will > > >> finally be out of my life by 2038...) > > >> > > >> > > >> Is it possible that the key isn't Raspberry Pi USB stack at all, > > >> but instead a whacked out GPS that's hanging out with Marty McFly > > >> <https://www.youtube.com/watch?v=wO4frwbZep8> and that it worked on > > >> the other system because it's 64 bit? For grins, try building a > > >> 32-bit GPSBabel on your "real" computer and see if that fails in > > >> the same way. > > >> > > >> Man, this stuff is expensive to track down... > > >> > > >> > > >> > > >> > > >> > > >> On Sun, Jul 15, 2018 at 4:30 PM ceelo <min...@gm...> > > >> wrote: > > >>> OK, thanks for your hints. I am going to compare the output > > >>> gpsbabel on both machines and see how far I can get. > > >>> Btw in the initial mail I had attached the file > > >>> test.gpx which is the output of > > >>> "gpsbabel -D9 -i garmin -f usb: -o gpx -F - " > > >>> on the Raspberry . It shows communication with the Garmin unit: it > > >>> detects its model, software version, GPS software version. Isn't > > >>> it strange that gpsbabel is capable of reading these data and > > >>> complaining about initialisation of the bus at the same time? > > >>> > > >>> > > >>> > > >>> On Sun, 15 Jul 2018 13:23:32 -0500 > > >>> Robert Lipe <rob...@gp...> wrote: > > >>> > > >>>> +the list so that someone running this combination has a chance > > >>>> to pipe in. > > >>>> > > >>>> So you've used it on Ubuntu and you know how this all should work > > >>>> and you have proof things can and do work and proven the GPS > > >>>> isn't broken or such. Good. That'll at least get you some A/B > > >>>> testing. > > >>>> > > >>>> There is nearly packet-level debugging built into our Garmin > > >>>> implementation that you can turn on with -D9 > > >>>> gpsbabel -D9 -i garmin -f usb: > > >>>> Be prepared for a LOT of output when it works. > > >>>> > > >>>> Most of the code at the nexus of Garmin and USB for Linux is in > > >>>> jeeps/gpslibusb.cc - This is the code that's the meat in the > > >>>> sandwich between liubusb (the lower layer talking to your kernel) > > >>>> and jeeps/gpsapp.c and friends. > > >>>> > > >>>> When I wrote that code, I had access to very expensive (about the > > >>>> price of a nice new car) USB protocol analyzers, which I no > > >>>> longer have. Debugging it will be you seeing how far it gets on > > >>>> one and comparing that to the other. You're probably going to > > >>>> have to get the experts of libusb and/or the USB systems for > > >>>> that hardware (The Pi Foundation?) and/or that Kerrnel (Debian > > >>>> or whomever) to get any help. That code is about 15 years in my > > >>>> rear view mirror at this point and it's unpleasant to read > > >>>> because it was trying to build a three-way abstraction at one > > >>>> level (linux, mac, windows - it turns out the Linux and Mac were > > >>>> both ultimately filled by libusb) and an internal USB driver > > >>>> abstraction (which it turns out we ultimately didn't need > > >>>> because GPS vendors came to their senses and quit bolting serial > > >>>> protocols onto USB like this). > > >>>> > > >>>> I can't think of anything material that's changed in the USB > > >>>> implementation in many years at this point. (I also don't > > >>>> remember getting out of bed this morning, but I know I did. :-) > > >>>> We've done some bulk code cleanup at the top of tree but we've > > >>>> intentionally treaded lightly on the Garmin code because it's > > >>>> fragile and expensive to retest. This is why you'll need to be > > >>>> very methodical when reporting these issues to your software > > >>>> vendors. "I'm using GPSBabel version X as provided by Y and Z > > >>>> with kernel versions K and L on ubuntu version U and the > > >>>> following packet transfer is acting differently on a Pi Model P > > >>>> than on x86 running on motherboard M. > > >>>> > > >>>> On Sun, Jul 15, 2018 at 8:30 AM ceelo <min...@gm...> > > >>>> wrote: > > >>>>> Hi Robert > > >>>>> > > >>>>> Thank you very much for your quick reply. > > >>>>> > > >>>>> I use gpsbabel with my Garmin successfully on a x86 ubuntu linux > > >>>>> machine since Qlandkartegt (that had Garmin support for my > > >>>>> device) was replaced by QMapShack. > > >>>>> > > >>>>> I have garmin_gps blacklisted on both machines (raspberry and > > >>>>> x86). I have a rules.d/garmin-rules on both machines. > > >>>>> > > >>>>> I did lsmod | grep hci on both machines: > > >>>>> > > >>>>> x86 output: > > >>>>> > > >>>>> hci 49152 2 mei_phy,pn544 > > >>>>> nfc 114688 2 hci,pn544 > > >>>>> ahci 36864 3 > > >>>>> sdhci_pci 28672 0 > > >>>>> libahci 32768 1 ahci > > >>>>> sdhci_acpi 16384 0 > > >>>>> sdhci 45056 2 sdhci_pci,sdhci_acpi > > >>>>> > > >>>>> raspberry pi output: > > >>>>> > > >>>>> hci_uart 20020 1 > > >>>>> btbcm 7916 1 hci_uart > > >>>>> bluetooth 365844 29 hci_uart,bnep,btbcm,rfcomm > > >>>>> > > >>>>> Have you any idea how to proceed to investigate the HCI driver > > >>>>> configuration? > > >>>>> > > >>>>> Eelco > > >>>>> > > >>>>> On Sun, 15 Jul 2018 05:14:55 -0500 > > >>>>> Robert Lipe <rob...@gp...> wrote: > > >>>>> > > >>>>>> Wow. That's a very unusual combination. You may be the first > > >>>>>> that's tried it. Anyone else on this list tried it? > > >>>>>> > > >>>>>> I wouldn't be surprised if libusb on the Pi is broken > > >>>>>> slightly. You may have to involve your OS vendor for help. > > >>>>>> Vendor 091e is the Garmin and we expect to have NO kernel > > >>>>>> devices bound to it. Have you successfully used this > > >>>>>> combination on a more typical computer? If so, that might > > >>>>>> point to Pi-specific issues in the kernel's HCI driver or > > >>>>>> configuration. > > >>>>>> > > >>>>>> You may find inspiration in: > > >>>>>> https://www.gpsbabel.org/os/Linux_Hotplug.html I'd hope that > > >>>>>> after 15 years, that's been fixed by now and your reported > > >>>>>> symptoms don't really match. We don't get a couple of > > >>>>>> complaints a week about it any more, but those GPSes have > > >>>>>> been out of manufacture long enough that the user pool may > > >>>>>> have dropped to zero. > > >>>>>> > > >>>>>> RJL > > >>>>>> > > >>>>>> On Sun, Jul 15, 2018 at 4:40 AM ceelo <min...@gm...> > > >>>>>> wrote: > > >>>>>>> Hello > > >>>>>>> > > >>>>>>> I am trying to use gpsbabel (Version 1.5.3) on a Raspberry > > >>>>>>> Pi 3 with Raspbian OS to communicate with an old Garmin > > >>>>>>> Etrex Legend Hcx. The program keeps terminating with the > > >>>>>>> message: "GARMIN:Can't init usb:", whatever I try. > > >>>>>>> > > >>>>>>> Output of uname -a: > > >>>>>>> Linux raspberrypi 4.9.80-v7+ #1098 SMP Fri Mar 9 19:11:42 > > >>>>>>> GMT 2018 armv7l GNU/Linux > > >>>>>>> > > >>>>>>> Output of dmesg: > > >>>>>>> usb 1-1.3.4: new full-speed USB device number 6 using > > >>>>>>> dwc_otg usb 1-1.3.4: New USB device found, idVendor=091e, > > >>>>>>> idProduct=0003 usb 1-1.3.4: New USB device strings: Mfr=0, > > >>>>>>> Product=0, SerialNumber=0 > > >>>>>>> > > >>>>>>> Output of gpsbabel -D9 -i garmin -f usb: -o gpx - 1> > > >>>>>>> test.gpx in the attachment. > > >>>>>>> > > >>>>>>> There seems to be communication with the Garmin unit but I > > >>>>>>> can't upload nor download any data. > > >>>>>>> > > >>>>>>> Any help would be greatly appreciated. > > >>>>>>> > > >>>>>>> Kind regards, > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>> > > >>> > Eelco------------------------------------------------------------------------------ > > >>> > > >>>>>>> Check out the vibrant tech community on one of the world's > > >>>>>>> most engaging tech sites, Slashdot.org! > > >>>>>>> http://sdm.link/slashdot > > >>>>>>> _______________________________________________ > > >>>>>>> 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 > > >>>>> > > >>> > > > > > > > > > > ------------------------------------------------------------------------------ > > > Check out the vibrant tech community on one of the world's most > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > > > > > > _______________________________________________ > > > 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 > > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > 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: ceelo <min...@gm...> - 2018-07-20 21:21:22
|
Robert, thank you very much for the thorough investigation you did on this. I discovered that when I sent the gpsbabel command with the resettime option it displays the proper time for less than a second and immediately returns to year 2038. So the resettime function of gpsbabel seems functioning fine but the firmware of my unit is persistent in misinterpreting the GPS signal. Maybe I should follow your link and try to sell it as a prop for "Back to the future". Kind regards Eelco (Btw. I am not sure whether I used the right command to invoke resettime. I used: gpsbabel -i garmin -f usb: -o garmin,resettime -F usb: With -i gpx -f test.gpx -o garmin,resettime -F usb: the output was: [ERROR] Send_Time: Unknown date/time protocol) On Tue, 17 Jul 2018 16:35:26 -0500 Robert Lipe <rob...@gp...> wrote: > We sent the packet and it didn't return an error. I think this is > between you and Garmin at this point. > > > > *TX* [20]:14 00 00 00 0e 00 00 00 08 00 00 00 07 10 *e2 07 *09 00 38 > 2c ..................8.(DATTIM ) > RX (bulk) [0]:(RET2INTR) > RX (intr) [12]:00 00 00 00 02 00 00 00 00 00 00 > 00 ............(REQBLK ) > > $ bc -l > bc 1.06 > Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc. > This is free software with ABSOLUTELY NO WARRANTY. > For details type `warranty'. > 7E2*2018* > > > There's some irony that GPS relies on extremely accurate time keeping > and Garmin gets this so wrong on your device. > > Good luck. > RJL > > On Tue, Jul 17, 2018 at 11:37 AM ceelo <min...@gm...> wrote: > > > Thank you Gary, but it doesn't work on this unit. > > I just returned from a two weeks hike with the unit turned on > > during the day. From day one the unit displayed the wrong date. Back > > home I did several hard resets and let it outside to get a new fix. > > That didn't change the date. It keeps displaying year 2038. > > Maybe this unit is suffers from the gps week roll over? > > > > > > On Tue, 17 Jul 2018 11:08:48 +1200 > > Gary Turner <g...@el...> wrote: > > > > > Leave it outside for a bit? That's the 'normal' way to set the > > > time. > > > > > > On 16/07/2018 20:38, ceelo wrote: > > > > Wow, congratulations, it seems you found the source of my > > > > problem. My x86 computer is indeed a 64 bit one. > > > > The Garmin is indeed showing the wrong date: today it is > > > > 1-MAR-2038. My apologies for not mentioning that in the first > > > > place. It just didn't seem relevant to me. I had already tried > > > > to correct the date with gpsbabel -D9 -i garmin -f usb: -o > > > > garmin,resettime=1 -F usb: on the x86. The command terminated > > > > fine, Garmin responded with a beep but the date didn't change. > > > > The output is in out.txt in the attachment. > > > > > > > > So if there is a way to correct the date in my Garmin unit it > > > > might work on the Raspberry too. I also tried several times to > > > > hard reset the Garmin but the date remains the same. > > > > > > > > The resettime option was build in for specific garmin etrex > > > > models according to the help file. Is there a way to adapt the > > > > code to include the etrex legend HCx model? > > > > > > > > > > > > On Sun, 15 Jul 2018 18:31:35 -0500 > > > > Robert Lipe <rob...@gp...> wrote: > > > > > > > >> Since I knew the info I'd be looking for wasn't GPX info and > > > >> if it failed, it was long before we'd have written any GPX > > > >> file, it didn't occur to me to open the GPX file that doesn't > > > >> have GPX in it. :-) > > > >> > > > >> It definitely gets a healthy way into the initialization. I > > > >> *think* we've made it through GPS_A000() in gpsapp.cc and have > > > >> returned from GPS_A001 back to GPS_A000. A))) must have > > > >> returned success becuase we continue on to > > > >> GPS_COMMAND_GET_TIME() which we see in the final packets: > > > >> > > > >> TX [14]:14 00 00 00 0a 00 00 00 02 00 00 00 05 > > > >> 00 ..............(CMDDAT Xfer Time) > > > >> RX (bulk) [0]:(RET2INTR) > > > >> RX (intr) [12]:00 00 00 00 02 00 00 00 00 00 00 > > > >> 00 ............(REQBLK ) RX (bulk) [20]:14 00 00 00 0e 00 00 > > > >> 00 08 00 00 00 02 1c f6 07 09 00 01 > > > >> 37 ...................7(DATTIM ) RX (bulk) [0]:(RET2INTR) > > > >> GARMIN:Can't init usb: > > > >> > > > >> So we're inside GPS_Command_Get_Time() The capability for an > > > >> A600 packet has been determined to be a D600 frame as reported > > > >> above: > > > >> > > > >> Capability A600: D600 > > > >> > > > >> so we head into GPS_A600_Get(). Error logging in this > > > >> function is a bit sparse. We build a XferTime packet and > > > >> transfer it and look for an ack. We then attempt a read and > > > >> request an ack. On USB, the acks don't exist but we can see we > > > >> issue the Xfer Time and get an empty read on the bulk piple > > > >> (maybe that's how they did acks when moving from serial. It's > > > >> been a while.) We see we get back a DATTIME packet so we > > > >> probably pass this to D600_Get() I don't feel like digging up > > > >> the specification, but that's easy enough to decode: > > > >> > > > >> > > > >> p = packet.data; > > > >> > > > >> ts.tm_mon = *p++ - 1; > > > >> ts.tm_mday = *p++; > > > >> ts.tm_year = (int32) GPS_Util_Get_Short(p) - 1900; > > > >> p+=2; > > > >> ts.tm_hour = (int32) GPS_Util_Get_Short(p); > > > >> p+=2; > > > >> ts.tm_min = *p++; > > > >> ts.tm_sec = *p++; > > > >> > > > >> so month is February. > > > >> mday is 28 > > > >> We pull 0x7f6 (which is 2038 - which sounds frighteningly > > > >> familiar) and subtract 1900) and stuff that into tm_year. > > > >> Hour becomes 9 ( > > > >> Minutes is 1 > > > >> Seconds is 55. > > > >> > > > >> This time is after 2038-01-19 so on a 32-bit system (most Pis > > > >> run this way), this is probably going to blow up. mktme will > > > >> fail and the error will be propagated back to the top. > > > >> > > > >> > > > >> This is a ridiculously specific failure. Are you absolutely > > > >> certain this GPS works on your other computer? Is your other > > > >> computer perhaps a 64-bit machine? Does the time on your GPS > > > >> perhaps display a stupid value? > > > >> > > > >> I agree the error handling in this path is atrocious and the > > > >> code path in question is not year 2038 ready on 32-bit systems > > > >> where time_t is an int. (I pray that these glorified serial > > > >> Garmins will finally be out of my life by 2038...) > > > >> > > > >> > > > >> Is it possible that the key isn't Raspberry Pi USB stack at > > > >> all, but instead a whacked out GPS that's hanging out with > > > >> Marty McFly <https://www.youtube.com/watch?v=wO4frwbZep8> and > > > >> that it worked on the other system because it's 64 bit? For > > > >> grins, try building a 32-bit GPSBabel on your "real" computer > > > >> and see if that fails in the same way. > > > >> > > > >> Man, this stuff is expensive to track down... > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> On Sun, Jul 15, 2018 at 4:30 PM ceelo <min...@gm...> > > > >> wrote: > > > >>> OK, thanks for your hints. I am going to compare the output > > > >>> gpsbabel on both machines and see how far I can get. > > > >>> Btw in the initial mail I had attached the file > > > >>> test.gpx which is the output of > > > >>> "gpsbabel -D9 -i garmin -f usb: -o gpx -F - " > > > >>> on the Raspberry . It shows communication with the Garmin > > > >>> unit: it detects its model, software version, GPS software > > > >>> version. Isn't it strange that gpsbabel is capable of reading > > > >>> these data and complaining about initialisation of the bus at > > > >>> the same time? > > > >>> > > > >>> > > > >>> > > > >>> On Sun, 15 Jul 2018 13:23:32 -0500 > > > >>> Robert Lipe <rob...@gp...> wrote: > > > >>> > > > >>>> +the list so that someone running this combination has a > > > >>>> chance to pipe in. > > > >>>> > > > >>>> So you've used it on Ubuntu and you know how this all should > > > >>>> work and you have proof things can and do work and proven > > > >>>> the GPS isn't broken or such. Good. That'll at least get you > > > >>>> some A/B testing. > > > >>>> > > > >>>> There is nearly packet-level debugging built into our Garmin > > > >>>> implementation that you can turn on with -D9 > > > >>>> gpsbabel -D9 -i garmin -f usb: > > > >>>> Be prepared for a LOT of output when it works. > > > >>>> > > > >>>> Most of the code at the nexus of Garmin and USB for Linux is > > > >>>> in jeeps/gpslibusb.cc - This is the code that's the meat in > > > >>>> the sandwich between liubusb (the lower layer talking to > > > >>>> your kernel) and jeeps/gpsapp.c and friends. > > > >>>> > > > >>>> When I wrote that code, I had access to very expensive > > > >>>> (about the price of a nice new car) USB protocol analyzers, > > > >>>> which I no longer have. Debugging it will be you seeing how > > > >>>> far it gets on one and comparing that to the other. You're > > > >>>> probably going to have to get the experts of libusb and/or > > > >>>> the USB systems for that hardware (The Pi Foundation?) > > > >>>> and/or that Kerrnel (Debian or whomever) to get any help. > > > >>>> That code is about 15 years in my rear view mirror at this > > > >>>> point and it's unpleasant to read because it was trying to > > > >>>> build a three-way abstraction at one level (linux, mac, > > > >>>> windows - it turns out the Linux and Mac were both > > > >>>> ultimately filled by libusb) and an internal USB driver > > > >>>> abstraction (which it turns out we ultimately didn't need > > > >>>> because GPS vendors came to their senses and quit bolting > > > >>>> serial protocols onto USB like this). > > > >>>> > > > >>>> I can't think of anything material that's changed in the USB > > > >>>> implementation in many years at this point. (I also don't > > > >>>> remember getting out of bed this morning, but I know I > > > >>>> did. :-) We've done some bulk code cleanup at the top of > > > >>>> tree but we've intentionally treaded lightly on the Garmin > > > >>>> code because it's fragile and expensive to retest. This is > > > >>>> why you'll need to be very methodical when reporting these > > > >>>> issues to your software vendors. "I'm using GPSBabel version > > > >>>> X as provided by Y and Z with kernel versions K and L on > > > >>>> ubuntu version U and the following packet transfer is acting > > > >>>> differently on a Pi Model P than on x86 running on > > > >>>> motherboard M. > > > >>>> > > > >>>> On Sun, Jul 15, 2018 at 8:30 AM ceelo <min...@gm...> > > > >>>> wrote: > > > >>>>> Hi Robert > > > >>>>> > > > >>>>> Thank you very much for your quick reply. > > > >>>>> > > > >>>>> I use gpsbabel with my Garmin successfully on a x86 ubuntu > > > >>>>> linux machine since Qlandkartegt (that had Garmin support > > > >>>>> for my device) was replaced by QMapShack. > > > >>>>> > > > >>>>> I have garmin_gps blacklisted on both machines (raspberry > > > >>>>> and x86). I have a rules.d/garmin-rules on both machines. > > > >>>>> > > > >>>>> I did lsmod | grep hci on both machines: > > > >>>>> > > > >>>>> x86 output: > > > >>>>> > > > >>>>> hci 49152 2 mei_phy,pn544 > > > >>>>> nfc 114688 2 hci,pn544 > > > >>>>> ahci 36864 3 > > > >>>>> sdhci_pci 28672 0 > > > >>>>> libahci 32768 1 ahci > > > >>>>> sdhci_acpi 16384 0 > > > >>>>> sdhci 45056 2 sdhci_pci,sdhci_acpi > > > >>>>> > > > >>>>> raspberry pi output: > > > >>>>> > > > >>>>> hci_uart 20020 1 > > > >>>>> btbcm 7916 1 hci_uart > > > >>>>> bluetooth 365844 29 hci_uart,bnep,btbcm,rfcomm > > > >>>>> > > > >>>>> Have you any idea how to proceed to investigate the HCI > > > >>>>> driver configuration? > > > >>>>> > > > >>>>> Eelco > > > >>>>> > > > >>>>> On Sun, 15 Jul 2018 05:14:55 -0500 > > > >>>>> Robert Lipe <rob...@gp...> wrote: > > > >>>>> > > > >>>>>> Wow. That's a very unusual combination. You may be the > > > >>>>>> first that's tried it. Anyone else on this list tried it? > > > >>>>>> > > > >>>>>> I wouldn't be surprised if libusb on the Pi is broken > > > >>>>>> slightly. You may have to involve your OS vendor for help. > > > >>>>>> Vendor 091e is the Garmin and we expect to have NO kernel > > > >>>>>> devices bound to it. Have you successfully used this > > > >>>>>> combination on a more typical computer? If so, that might > > > >>>>>> point to Pi-specific issues in the kernel's HCI driver or > > > >>>>>> configuration. > > > >>>>>> > > > >>>>>> You may find inspiration in: > > > >>>>>> https://www.gpsbabel.org/os/Linux_Hotplug.html I'd hope > > > >>>>>> that after 15 years, that's been fixed by now and your > > > >>>>>> reported symptoms don't really match. We don't get a > > > >>>>>> couple of complaints a week about it any more, but those > > > >>>>>> GPSes have been out of manufacture long enough that the > > > >>>>>> user pool may have dropped to zero. > > > >>>>>> > > > >>>>>> RJL > > > >>>>>> > > > >>>>>> On Sun, Jul 15, 2018 at 4:40 AM ceelo > > > >>>>>> <min...@gm...> wrote: > > > >>>>>>> Hello > > > >>>>>>> > > > >>>>>>> I am trying to use gpsbabel (Version 1.5.3) on a Raspberry > > > >>>>>>> Pi 3 with Raspbian OS to communicate with an old Garmin > > > >>>>>>> Etrex Legend Hcx. The program keeps terminating with the > > > >>>>>>> message: "GARMIN:Can't init usb:", whatever I try. > > > >>>>>>> > > > >>>>>>> Output of uname -a: > > > >>>>>>> Linux raspberrypi 4.9.80-v7+ #1098 SMP Fri Mar 9 19:11:42 > > > >>>>>>> GMT 2018 armv7l GNU/Linux > > > >>>>>>> > > > >>>>>>> Output of dmesg: > > > >>>>>>> usb 1-1.3.4: new full-speed USB device number 6 using > > > >>>>>>> dwc_otg usb 1-1.3.4: New USB device found, idVendor=091e, > > > >>>>>>> idProduct=0003 usb 1-1.3.4: New USB device strings: Mfr=0, > > > >>>>>>> Product=0, SerialNumber=0 > > > >>>>>>> > > > >>>>>>> Output of gpsbabel -D9 -i garmin -f usb: -o gpx - 1> > > > >>>>>>> test.gpx in the attachment. > > > >>>>>>> > > > >>>>>>> There seems to be communication with the Garmin unit but > > > >>>>>>> I can't upload nor download any data. > > > >>>>>>> > > > >>>>>>> Any help would be greatly appreciated. > > > >>>>>>> > > > >>>>>>> Kind regards, > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>> > > > >>> > > Eelco------------------------------------------------------------------------------ > > > >>> > > > >>>>>>> Check out the vibrant tech community on one of the world's > > > >>>>>>> most engaging tech sites, Slashdot.org! > > > >>>>>>> http://sdm.link/slashdot > > > >>>>>>> _______________________________________________ > > > >>>>>>> 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 > > > >>>>> > > > >>> > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > Check out the vibrant tech community on one of the world's most > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > 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: Gary T. <g...@el...> - 2018-07-19 02:02:00
|
That sounds exactly like the problem. 2038/3/1 is 264 days before the GPS rollover date of 2038/11/20 264 days before the previous (next!) rollover date 2019/4/6 is 2018/7/16 which was exactly the date you sent the below information. According to https://spectracom.com/resources/blog/lisa-perdue/2018/gps-2019-week-rollover-what-you-need-know some units use the firmware date as a hack to get the right rollover date. Assuming you aren't using hacked firmware, perhaps the date has been corrupted. Perhaps a firmware reload might help? On 18/07/2018 04:36, ceelo wrote: > Thank you Gary, but it doesn't work on this unit. > I just returned from a two weeks hike with the unit turned on > during the day. From day one the unit displayed the wrong date. Back > home I did several hard resets and let it outside to get a new fix. That > didn't change the date. It keeps displaying year 2038. > Maybe this unit is suffers from the gps week roll over? > > > On Tue, 17 Jul 2018 11:08:48 +1200 > Gary Turner <g...@el...> wrote: > >> Leave it outside for a bit? That's the 'normal' way to set the time. >> >> On 16/07/2018 20:38, ceelo wrote: >>> Wow, congratulations, it seems you found the source of my problem. >>> My x86 computer is indeed a 64 bit one. >>> The Garmin is indeed showing the wrong date: today it is >>> 1-MAR-2038. My apologies for not mentioning that in the first >>> place. It just didn't seem relevant to me. I had already tried to >>> correct the date with gpsbabel -D9 -i garmin -f usb: -o >>> garmin,resettime=1 -F usb: on the x86. The command terminated fine, >>> Garmin responded with a beep but the date didn't change. The output >>> is in out.txt in the attachment. >>> >>> So if there is a way to correct the date in my Garmin unit it might >>> work on the Raspberry too. I also tried several times to hard reset >>> the Garmin but the date remains the same. >>> >>> The resettime option was build in for specific garmin etrex models >>> according to the help file. Is there a way to adapt the code to >>> include the etrex legend HCx model? >>> >>> >>> On Sun, 15 Jul 2018 18:31:35 -0500 >>> Robert Lipe <rob...@gp...> wrote: >>> >>>> Since I knew the info I'd be looking for wasn't GPX info and if it >>>> failed, it was long before we'd have written any GPX file, it >>>> didn't occur to me to open the GPX file that doesn't have GPX in >>>> it. :-) >>>> >>>> It definitely gets a healthy way into the initialization. I *think* >>>> we've made it through GPS_A000() in gpsapp.cc and have returned >>>> from GPS_A001 back to GPS_A000. A))) must have returned success >>>> becuase we continue on to GPS_COMMAND_GET_TIME() which we see in >>>> the final packets: >>>> >>>> TX [14]:14 00 00 00 0a 00 00 00 02 00 00 00 05 >>>> 00 ..............(CMDDAT Xfer Time) >>>> RX (bulk) [0]:(RET2INTR) >>>> RX (intr) [12]:00 00 00 00 02 00 00 00 00 00 00 >>>> 00 ............(REQBLK ) RX (bulk) [20]:14 00 00 00 0e 00 00 00 08 >>>> 00 00 00 02 1c f6 07 09 00 01 37 ...................7(DATTIM ) >>>> RX (bulk) [0]:(RET2INTR) >>>> GARMIN:Can't init usb: >>>> >>>> So we're inside GPS_Command_Get_Time() The capability for an A600 >>>> packet has been determined to be a D600 frame as reported above: >>>> >>>> Capability A600: D600 >>>> >>>> so we head into GPS_A600_Get(). Error logging in this function is >>>> a bit sparse. We build a XferTime packet and transfer it and look >>>> for an ack. We then attempt a read and request an ack. On USB, the >>>> acks don't exist but we can see we issue the Xfer Time and get an >>>> empty read on the bulk piple (maybe that's how they did acks when >>>> moving from serial. It's been a while.) We see we get back a >>>> DATTIME packet so we probably pass this to D600_Get() I don't feel >>>> like digging up the specification, but that's easy enough to >>>> decode: >>>> >>>> >>>> p = packet.data; >>>> >>>> ts.tm_mon = *p++ - 1; >>>> ts.tm_mday = *p++; >>>> ts.tm_year = (int32) GPS_Util_Get_Short(p) - 1900; >>>> p+=2; >>>> ts.tm_hour = (int32) GPS_Util_Get_Short(p); >>>> p+=2; >>>> ts.tm_min = *p++; >>>> ts.tm_sec = *p++; >>>> >>>> so month is February. >>>> mday is 28 >>>> We pull 0x7f6 (which is 2038 - which sounds frighteningly familiar) >>>> and subtract 1900) and stuff that into tm_year. >>>> Hour becomes 9 ( >>>> Minutes is 1 >>>> Seconds is 55. >>>> >>>> This time is after 2038-01-19 so on a 32-bit system (most Pis run >>>> this way), this is probably going to blow up. mktme will fail and >>>> the error will be propagated back to the top. >>>> >>>> >>>> This is a ridiculously specific failure. Are you absolutely certain >>>> this GPS works on your other computer? Is your other computer >>>> perhaps a 64-bit machine? Does the time on your GPS perhaps >>>> display a stupid value? >>>> >>>> I agree the error handling in this path is atrocious and the code >>>> path in question is not year 2038 ready on 32-bit systems where >>>> time_t is an int. (I pray that these glorified serial Garmins will >>>> finally be out of my life by 2038...) >>>> >>>> >>>> Is it possible that the key isn't Raspberry Pi USB stack at all, >>>> but instead a whacked out GPS that's hanging out with Marty McFly >>>> <https://www.youtube.com/watch?v=wO4frwbZep8> and that it worked on >>>> the other system because it's 64 bit? For grins, try building a >>>> 32-bit GPSBabel on your "real" computer and see if that fails in >>>> the same way. >>>> >>>> Man, this stuff is expensive to track down... >>>> >>>> >>>> >>>> >>>> >>>> On Sun, Jul 15, 2018 at 4:30 PM ceelo <min...@gm...> >>>> wrote: >>>>> OK, thanks for your hints. I am going to compare the output >>>>> gpsbabel on both machines and see how far I can get. >>>>> Btw in the initial mail I had attached the file >>>>> test.gpx which is the output of >>>>> "gpsbabel -D9 -i garmin -f usb: -o gpx -F - " >>>>> on the Raspberry . It shows communication with the Garmin unit: it >>>>> detects its model, software version, GPS software version. Isn't >>>>> it strange that gpsbabel is capable of reading these data and >>>>> complaining about initialisation of the bus at the same time? >>>>> >>>>> >>>>> >>>>> On Sun, 15 Jul 2018 13:23:32 -0500 >>>>> Robert Lipe <rob...@gp...> wrote: >>>>> >>>>>> +the list so that someone running this combination has a chance >>>>>> to pipe in. >>>>>> >>>>>> So you've used it on Ubuntu and you know how this all should work >>>>>> and you have proof things can and do work and proven the GPS >>>>>> isn't broken or such. Good. That'll at least get you some A/B >>>>>> testing. >>>>>> >>>>>> There is nearly packet-level debugging built into our Garmin >>>>>> implementation that you can turn on with -D9 >>>>>> gpsbabel -D9 -i garmin -f usb: >>>>>> Be prepared for a LOT of output when it works. >>>>>> >>>>>> Most of the code at the nexus of Garmin and USB for Linux is in >>>>>> jeeps/gpslibusb.cc - This is the code that's the meat in the >>>>>> sandwich between liubusb (the lower layer talking to your kernel) >>>>>> and jeeps/gpsapp.c and friends. >>>>>> >>>>>> When I wrote that code, I had access to very expensive (about the >>>>>> price of a nice new car) USB protocol analyzers, which I no >>>>>> longer have. Debugging it will be you seeing how far it gets on >>>>>> one and comparing that to the other. You're probably going to >>>>>> have to get the experts of libusb and/or the USB systems for >>>>>> that hardware (The Pi Foundation?) and/or that Kerrnel (Debian >>>>>> or whomever) to get any help. That code is about 15 years in my >>>>>> rear view mirror at this point and it's unpleasant to read >>>>>> because it was trying to build a three-way abstraction at one >>>>>> level (linux, mac, windows - it turns out the Linux and Mac were >>>>>> both ultimately filled by libusb) and an internal USB driver >>>>>> abstraction (which it turns out we ultimately didn't need >>>>>> because GPS vendors came to their senses and quit bolting serial >>>>>> protocols onto USB like this). >>>>>> >>>>>> I can't think of anything material that's changed in the USB >>>>>> implementation in many years at this point. (I also don't >>>>>> remember getting out of bed this morning, but I know I did. :-) >>>>>> We've done some bulk code cleanup at the top of tree but we've >>>>>> intentionally treaded lightly on the Garmin code because it's >>>>>> fragile and expensive to retest. This is why you'll need to be >>>>>> very methodical when reporting these issues to your software >>>>>> vendors. "I'm using GPSBabel version X as provided by Y and Z >>>>>> with kernel versions K and L on ubuntu version U and the >>>>>> following packet transfer is acting differently on a Pi Model P >>>>>> than on x86 running on motherboard M. >>>>>> >>>>>> On Sun, Jul 15, 2018 at 8:30 AM ceelo <min...@gm...> >>>>>> wrote: >>>>>>> Hi Robert >>>>>>> >>>>>>> Thank you very much for your quick reply. >>>>>>> >>>>>>> I use gpsbabel with my Garmin successfully on a x86 ubuntu linux >>>>>>> machine since Qlandkartegt (that had Garmin support for my >>>>>>> device) was replaced by QMapShack. >>>>>>> >>>>>>> I have garmin_gps blacklisted on both machines (raspberry and >>>>>>> x86). I have a rules.d/garmin-rules on both machines. >>>>>>> >>>>>>> I did lsmod | grep hci on both machines: >>>>>>> >>>>>>> x86 output: >>>>>>> >>>>>>> hci 49152 2 mei_phy,pn544 >>>>>>> nfc 114688 2 hci,pn544 >>>>>>> ahci 36864 3 >>>>>>> sdhci_pci 28672 0 >>>>>>> libahci 32768 1 ahci >>>>>>> sdhci_acpi 16384 0 >>>>>>> sdhci 45056 2 sdhci_pci,sdhci_acpi >>>>>>> >>>>>>> raspberry pi output: >>>>>>> >>>>>>> hci_uart 20020 1 >>>>>>> btbcm 7916 1 hci_uart >>>>>>> bluetooth 365844 29 hci_uart,bnep,btbcm,rfcomm >>>>>>> >>>>>>> Have you any idea how to proceed to investigate the HCI driver >>>>>>> configuration? >>>>>>> >>>>>>> Eelco >>>>>>> >>>>>>> On Sun, 15 Jul 2018 05:14:55 -0500 >>>>>>> Robert Lipe <rob...@gp...> wrote: >>>>>>> >>>>>>>> Wow. That's a very unusual combination. You may be the first >>>>>>>> that's tried it. Anyone else on this list tried it? >>>>>>>> >>>>>>>> I wouldn't be surprised if libusb on the Pi is broken >>>>>>>> slightly. You may have to involve your OS vendor for help. >>>>>>>> Vendor 091e is the Garmin and we expect to have NO kernel >>>>>>>> devices bound to it. Have you successfully used this >>>>>>>> combination on a more typical computer? If so, that might >>>>>>>> point to Pi-specific issues in the kernel's HCI driver or >>>>>>>> configuration. >>>>>>>> >>>>>>>> You may find inspiration in: >>>>>>>> https://www.gpsbabel.org/os/Linux_Hotplug.html I'd hope that >>>>>>>> after 15 years, that's been fixed by now and your reported >>>>>>>> symptoms don't really match. We don't get a couple of >>>>>>>> complaints a week about it any more, but those GPSes have >>>>>>>> been out of manufacture long enough that the user pool may >>>>>>>> have dropped to zero. >>>>>>>> >>>>>>>> RJL >>>>>>>> >>>>>>>> On Sun, Jul 15, 2018 at 4:40 AM ceelo <min...@gm...> >>>>>>>> wrote: >>>>>>>>> Hello >>>>>>>>> >>>>>>>>> I am trying to use gpsbabel (Version 1.5.3) on a Raspberry >>>>>>>>> Pi 3 with Raspbian OS to communicate with an old Garmin >>>>>>>>> Etrex Legend Hcx. The program keeps terminating with the >>>>>>>>> message: "GARMIN:Can't init usb:", whatever I try. >>>>>>>>> >>>>>>>>> Output of uname -a: >>>>>>>>> Linux raspberrypi 4.9.80-v7+ #1098 SMP Fri Mar 9 19:11:42 >>>>>>>>> GMT 2018 armv7l GNU/Linux >>>>>>>>> >>>>>>>>> Output of dmesg: >>>>>>>>> usb 1-1.3.4: new full-speed USB device number 6 using >>>>>>>>> dwc_otg usb 1-1.3.4: New USB device found, idVendor=091e, >>>>>>>>> idProduct=0003 usb 1-1.3.4: New USB device strings: Mfr=0, >>>>>>>>> Product=0, SerialNumber=0 >>>>>>>>> >>>>>>>>> Output of gpsbabel -D9 -i garmin -f usb: -o gpx - 1> >>>>>>>>> test.gpx in the attachment. >>>>>>>>> >>>>>>>>> There seems to be communication with the Garmin unit but I >>>>>>>>> can't upload nor download any data. >>>>>>>>> >>>>>>>>> Any help would be greatly appreciated. >>>>>>>>> >>>>>>>>> Kind regards, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> Eelco------------------------------------------------------------------------------ >>>>> >>>>>>>>> Check out the vibrant tech community on one of the world's >>>>>>>>> most engaging tech sites, Slashdot.org! >>>>>>>>> http://sdm.link/slashdot >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>> >>>>> >>> >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> >>> >>> _______________________________________________ >>> 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 > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > 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: ceelo <min...@gm...> - 2018-07-20 21:33:44
|
Gary, thank you for the link. I had not found that one in my search. A firmware reload was one of the first things I tried, without success. I am curious about what my unit will display after 260 days from now. On Thu, 19 Jul 2018 12:52:09 +1200 Gary Turner <g...@el...> wrote: > That sounds exactly like the problem. > > 2038/3/1 is 264 days before the GPS rollover date of 2038/11/20 > 264 days before the previous (next!) rollover date 2019/4/6 is > 2018/7/16 which was exactly the date you sent the below information. > > According to > https://spectracom.com/resources/blog/lisa-perdue/2018/gps-2019-week-rollover-what-you-need-know > some units use the firmware date as a hack to get the right rollover > date. Assuming you aren't using hacked firmware, perhaps the date has > been corrupted. > > Perhaps a firmware reload might help? > > On 18/07/2018 04:36, ceelo wrote: > > Thank you Gary, but it doesn't work on this unit. > > I just returned from a two weeks hike with the unit turned on > > during the day. From day one the unit displayed the wrong date. Back > > home I did several hard resets and let it outside to get a new fix. > > That didn't change the date. It keeps displaying year 2038. > > Maybe this unit is suffers from the gps week roll over? > > > > > > On Tue, 17 Jul 2018 11:08:48 +1200 > > Gary Turner <g...@el...> wrote: > > > >> Leave it outside for a bit? That's the 'normal' way to set the > >> time. > >> > >> On 16/07/2018 20:38, ceelo wrote: > >>> Wow, congratulations, it seems you found the source of my problem. > >>> My x86 computer is indeed a 64 bit one. > >>> The Garmin is indeed showing the wrong date: today it is > >>> 1-MAR-2038. My apologies for not mentioning that in the first > >>> place. It just didn't seem relevant to me. I had already tried to > >>> correct the date with gpsbabel -D9 -i garmin -f usb: -o > >>> garmin,resettime=1 -F usb: on the x86. The command terminated > >>> fine, Garmin responded with a beep but the date didn't change. > >>> The output is in out.txt in the attachment. > >>> > >>> So if there is a way to correct the date in my Garmin unit it > >>> might work on the Raspberry too. I also tried several times to > >>> hard reset the Garmin but the date remains the same. > >>> > >>> The resettime option was build in for specific garmin etrex models > >>> according to the help file. Is there a way to adapt the code to > >>> include the etrex legend HCx model? > >>> > >>> > >>> On Sun, 15 Jul 2018 18:31:35 -0500 > >>> Robert Lipe <rob...@gp...> wrote: > >>> > >>>> Since I knew the info I'd be looking for wasn't GPX info and if > >>>> it failed, it was long before we'd have written any GPX file, it > >>>> didn't occur to me to open the GPX file that doesn't have GPX in > >>>> it. :-) > >>>> > >>>> It definitely gets a healthy way into the initialization. I > >>>> *think* we've made it through GPS_A000() in gpsapp.cc and have > >>>> returned from GPS_A001 back to GPS_A000. A))) must have returned > >>>> success becuase we continue on to GPS_COMMAND_GET_TIME() which > >>>> we see in the final packets: > >>>> > >>>> TX [14]:14 00 00 00 0a 00 00 00 02 00 00 00 05 > >>>> 00 ..............(CMDDAT Xfer Time) > >>>> RX (bulk) [0]:(RET2INTR) > >>>> RX (intr) [12]:00 00 00 00 02 00 00 00 00 00 00 > >>>> 00 ............(REQBLK ) RX (bulk) [20]:14 00 00 00 0e 00 00 00 > >>>> 08 00 00 00 02 1c f6 07 09 00 01 37 ...................7(DATTIM > >>>> ) RX (bulk) [0]:(RET2INTR) > >>>> GARMIN:Can't init usb: > >>>> > >>>> So we're inside GPS_Command_Get_Time() The capability for an A600 > >>>> packet has been determined to be a D600 frame as reported above: > >>>> > >>>> Capability A600: D600 > >>>> > >>>> so we head into GPS_A600_Get(). Error logging in this function > >>>> is a bit sparse. We build a XferTime packet and transfer it and > >>>> look for an ack. We then attempt a read and request an ack. On > >>>> USB, the acks don't exist but we can see we issue the Xfer Time > >>>> and get an empty read on the bulk piple (maybe that's how they > >>>> did acks when moving from serial. It's been a while.) We see we > >>>> get back a DATTIME packet so we probably pass this to D600_Get() > >>>> I don't feel like digging up the specification, but that's easy > >>>> enough to decode: > >>>> > >>>> > >>>> p = packet.data; > >>>> > >>>> ts.tm_mon = *p++ - 1; > >>>> ts.tm_mday = *p++; > >>>> ts.tm_year = (int32) GPS_Util_Get_Short(p) - 1900; > >>>> p+=2; > >>>> ts.tm_hour = (int32) GPS_Util_Get_Short(p); > >>>> p+=2; > >>>> ts.tm_min = *p++; > >>>> ts.tm_sec = *p++; > >>>> > >>>> so month is February. > >>>> mday is 28 > >>>> We pull 0x7f6 (which is 2038 - which sounds frighteningly > >>>> familiar) and subtract 1900) and stuff that into tm_year. > >>>> Hour becomes 9 ( > >>>> Minutes is 1 > >>>> Seconds is 55. > >>>> > >>>> This time is after 2038-01-19 so on a 32-bit system (most Pis run > >>>> this way), this is probably going to blow up. mktme will fail and > >>>> the error will be propagated back to the top. > >>>> > >>>> > >>>> This is a ridiculously specific failure. Are you absolutely > >>>> certain this GPS works on your other computer? Is your other > >>>> computer perhaps a 64-bit machine? Does the time on your GPS > >>>> perhaps display a stupid value? > >>>> > >>>> I agree the error handling in this path is atrocious and the code > >>>> path in question is not year 2038 ready on 32-bit systems where > >>>> time_t is an int. (I pray that these glorified serial Garmins > >>>> will finally be out of my life by 2038...) > >>>> > >>>> > >>>> Is it possible that the key isn't Raspberry Pi USB stack at all, > >>>> but instead a whacked out GPS that's hanging out with Marty McFly > >>>> <https://www.youtube.com/watch?v=wO4frwbZep8> and that it worked > >>>> on the other system because it's 64 bit? For grins, try building > >>>> a 32-bit GPSBabel on your "real" computer and see if that fails > >>>> in the same way. > >>>> > >>>> Man, this stuff is expensive to track down... > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> On Sun, Jul 15, 2018 at 4:30 PM ceelo <min...@gm...> > >>>> wrote: > >>>>> OK, thanks for your hints. I am going to compare the output > >>>>> gpsbabel on both machines and see how far I can get. > >>>>> Btw in the initial mail I had attached the file > >>>>> test.gpx which is the output of > >>>>> "gpsbabel -D9 -i garmin -f usb: -o gpx -F - " > >>>>> on the Raspberry . It shows communication with the Garmin unit: > >>>>> it detects its model, software version, GPS software version. > >>>>> Isn't it strange that gpsbabel is capable of reading these data > >>>>> and complaining about initialisation of the bus at the same > >>>>> time? > >>>>> > >>>>> > >>>>> > >>>>> On Sun, 15 Jul 2018 13:23:32 -0500 > >>>>> Robert Lipe <rob...@gp...> wrote: > >>>>> > >>>>>> +the list so that someone running this combination has a chance > >>>>>> to pipe in. > >>>>>> > >>>>>> So you've used it on Ubuntu and you know how this all should > >>>>>> work and you have proof things can and do work and proven the > >>>>>> GPS isn't broken or such. Good. That'll at least get you some > >>>>>> A/B testing. > >>>>>> > >>>>>> There is nearly packet-level debugging built into our Garmin > >>>>>> implementation that you can turn on with -D9 > >>>>>> gpsbabel -D9 -i garmin -f usb: > >>>>>> Be prepared for a LOT of output when it works. > >>>>>> > >>>>>> Most of the code at the nexus of Garmin and USB for Linux is in > >>>>>> jeeps/gpslibusb.cc - This is the code that's the meat in the > >>>>>> sandwich between liubusb (the lower layer talking to your > >>>>>> kernel) and jeeps/gpsapp.c and friends. > >>>>>> > >>>>>> When I wrote that code, I had access to very expensive (about > >>>>>> the price of a nice new car) USB protocol analyzers, which I no > >>>>>> longer have. Debugging it will be you seeing how far it gets on > >>>>>> one and comparing that to the other. You're probably going to > >>>>>> have to get the experts of libusb and/or the USB systems for > >>>>>> that hardware (The Pi Foundation?) and/or that Kerrnel (Debian > >>>>>> or whomever) to get any help. That code is about 15 years in my > >>>>>> rear view mirror at this point and it's unpleasant to read > >>>>>> because it was trying to build a three-way abstraction at one > >>>>>> level (linux, mac, windows - it turns out the Linux and Mac > >>>>>> were both ultimately filled by libusb) and an internal USB > >>>>>> driver abstraction (which it turns out we ultimately didn't > >>>>>> need because GPS vendors came to their senses and quit bolting > >>>>>> serial protocols onto USB like this). > >>>>>> > >>>>>> I can't think of anything material that's changed in the USB > >>>>>> implementation in many years at this point. (I also don't > >>>>>> remember getting out of bed this morning, but I know I did. :-) > >>>>>> We've done some bulk code cleanup at the top of tree but we've > >>>>>> intentionally treaded lightly on the Garmin code because it's > >>>>>> fragile and expensive to retest. This is why you'll need to be > >>>>>> very methodical when reporting these issues to your software > >>>>>> vendors. "I'm using GPSBabel version X as provided by Y and Z > >>>>>> with kernel versions K and L on ubuntu version U and the > >>>>>> following packet transfer is acting differently on a Pi Model P > >>>>>> than on x86 running on motherboard M. > >>>>>> > >>>>>> On Sun, Jul 15, 2018 at 8:30 AM ceelo <min...@gm...> > >>>>>> wrote: > >>>>>>> Hi Robert > >>>>>>> > >>>>>>> Thank you very much for your quick reply. > >>>>>>> > >>>>>>> I use gpsbabel with my Garmin successfully on a x86 ubuntu > >>>>>>> linux machine since Qlandkartegt (that had Garmin support for > >>>>>>> my device) was replaced by QMapShack. > >>>>>>> > >>>>>>> I have garmin_gps blacklisted on both machines (raspberry and > >>>>>>> x86). I have a rules.d/garmin-rules on both machines. > >>>>>>> > >>>>>>> I did lsmod | grep hci on both machines: > >>>>>>> > >>>>>>> x86 output: > >>>>>>> > >>>>>>> hci 49152 2 mei_phy,pn544 > >>>>>>> nfc 114688 2 hci,pn544 > >>>>>>> ahci 36864 3 > >>>>>>> sdhci_pci 28672 0 > >>>>>>> libahci 32768 1 ahci > >>>>>>> sdhci_acpi 16384 0 > >>>>>>> sdhci 45056 2 sdhci_pci,sdhci_acpi > >>>>>>> > >>>>>>> raspberry pi output: > >>>>>>> > >>>>>>> hci_uart 20020 1 > >>>>>>> btbcm 7916 1 hci_uart > >>>>>>> bluetooth 365844 29 hci_uart,bnep,btbcm,rfcomm > >>>>>>> > >>>>>>> Have you any idea how to proceed to investigate the HCI driver > >>>>>>> configuration? > >>>>>>> > >>>>>>> Eelco > >>>>>>> > >>>>>>> On Sun, 15 Jul 2018 05:14:55 -0500 > >>>>>>> Robert Lipe <rob...@gp...> wrote: > >>>>>>> > >>>>>>>> Wow. That's a very unusual combination. You may be the first > >>>>>>>> that's tried it. Anyone else on this list tried it? > >>>>>>>> > >>>>>>>> I wouldn't be surprised if libusb on the Pi is broken > >>>>>>>> slightly. You may have to involve your OS vendor for help. > >>>>>>>> Vendor 091e is the Garmin and we expect to have NO kernel > >>>>>>>> devices bound to it. Have you successfully used this > >>>>>>>> combination on a more typical computer? If so, that might > >>>>>>>> point to Pi-specific issues in the kernel's HCI driver or > >>>>>>>> configuration. > >>>>>>>> > >>>>>>>> You may find inspiration in: > >>>>>>>> https://www.gpsbabel.org/os/Linux_Hotplug.html I'd hope that > >>>>>>>> after 15 years, that's been fixed by now and your reported > >>>>>>>> symptoms don't really match. We don't get a couple of > >>>>>>>> complaints a week about it any more, but those GPSes have > >>>>>>>> been out of manufacture long enough that the user pool may > >>>>>>>> have dropped to zero. > >>>>>>>> > >>>>>>>> RJL > >>>>>>>> > >>>>>>>> On Sun, Jul 15, 2018 at 4:40 AM ceelo <min...@gm...> > >>>>>>>> wrote: > >>>>>>>>> Hello > >>>>>>>>> > >>>>>>>>> I am trying to use gpsbabel (Version 1.5.3) on a Raspberry > >>>>>>>>> Pi 3 with Raspbian OS to communicate with an old Garmin > >>>>>>>>> Etrex Legend Hcx. The program keeps terminating with the > >>>>>>>>> message: "GARMIN:Can't init usb:", whatever I try. > >>>>>>>>> > >>>>>>>>> Output of uname -a: > >>>>>>>>> Linux raspberrypi 4.9.80-v7+ #1098 SMP Fri Mar 9 19:11:42 > >>>>>>>>> GMT 2018 armv7l GNU/Linux > >>>>>>>>> > >>>>>>>>> Output of dmesg: > >>>>>>>>> usb 1-1.3.4: new full-speed USB device number 6 using > >>>>>>>>> dwc_otg usb 1-1.3.4: New USB device found, idVendor=091e, > >>>>>>>>> idProduct=0003 usb 1-1.3.4: New USB device strings: Mfr=0, > >>>>>>>>> Product=0, SerialNumber=0 > >>>>>>>>> > >>>>>>>>> Output of gpsbabel -D9 -i garmin -f usb: -o gpx - 1> > >>>>>>>>> test.gpx in the attachment. > >>>>>>>>> > >>>>>>>>> There seems to be communication with the Garmin unit but I > >>>>>>>>> can't upload nor download any data. > >>>>>>>>> > >>>>>>>>> Any help would be greatly appreciated. > >>>>>>>>> > >>>>>>>>> Kind regards, > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>> Eelco------------------------------------------------------------------------------ > >>>>> > >>>>>>>>> Check out the vibrant tech community on one of the world's > >>>>>>>>> most engaging tech sites, Slashdot.org! > >>>>>>>>> http://sdm.link/slashdot > >>>>>>>>> _______________________________________________ > >>>>>>>>> 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 > >>>>>>> > >>>>> > >>> > >>> ------------------------------------------------------------------------------ > >>> Check out the vibrant tech community on one of the world's most > >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot > >>> > >>> > >>> _______________________________________________ > >>> 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 > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > 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 > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > 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 |