|
»
»
MiniHomer: Problems downloading tracks
|
View:
New views
8 Messages
—
Rating Filter:
Alert me
|
 |
MiniHomer: Problems downloading tracks
by Olaf Petersen
::
Rate this Message:
Hi everyone,
I am facing problems to download data from my MiniHomer logger, using GPSBabel ver. 1.4.3-beta20111112 on MS Windows 7 Home Premium SP1. The logger was updated to the FNAM Sports 4 - firmware and everything runs fine on nTrip 1.2.14 When I try to invoke GPSBabel with "gpsbabel -D3 -i miniHomer,baud=38400,read-at-once=0 -f com3 -x height,wgs84tomsl -x track,split=1h,title="TRACK" -o gtm -F c:\Users\olafpe\Documents\GPS\lasttrack.gtm" I get an error message "Error reading sector #0". Same if I try to dump-file. I have appended a full printout at the end of this message. Each time, GPSBabel pauses for a few moments after printing the line "Reading sector #0", on a higher debug-level it can be seen that the MiniHomer only sends NMEA-data meanwhile, so I do have the idea that a new binary command-set is used in the newer firmware-versions. When I experiment with first-sector and last-sector options, all I manage is to download the POIs when I force GPSBabel to read an empty sector by e.g. setting first-sector and last-sector to 2. Only then a GTM-file is created. It is no problem to delete the MiniHomer's log using GPSBabel. Should I return to a previous firmware version? FNAM Sports 3 won't do the job. Thank you in advance! Olaf Printout follows options: module/option=value: miniHomer/baud="38400" options: module/option=value: miniHomer/erase="0" (=default) options: module/option=value: miniHomer/first-sector="0" (=default) options: module/option=value: miniHomer/initbaud="38400" (=default) options: module/option=value: miniHomer/last-sector="-1" (=default) options: module/option=value: miniHomer/no-output="0" (=default) options: module/option=value: miniHomer/read-at-once="0" Translated port name: "com3" skytraq: Probing SkyTraq Venus at 38400baud... Receiving message with 2 bytes of payload (expected >=2) Receiving message with 2 bytes of payload (expected >=2) Got ACK (id=0x02) Receiving message with 14 bytes of payload (expected >=14) skytraq: Venus device found: Kernel version = 1.4.42, ODM version = 1.4.41, revision (Y/M/D) = 11/03/23 Receiving message with 2 bytes of payload (expected >=2) Receiving message with 2 bytes of payload (expected >=2) Got ACK (id=0x17) Receiving message with 37 bytes of payload (expected >=9) skytraq: Device status: free sectors: 509 / total sectors: 509 / 0% used / write ptr: 10996 skytraq: Reading log data from device... skytraq: start=0 used=1 skytraq: opt_last_sector_val=-1 Reading sector #0... Receiving message with 2 bytes of payload (expected >=2) Receiving message with 2 bytes of payload (expected >=2) Got ACK (id=0x1b) skytraq: Didn't get sector end tag Reading sector #0... Receiving message with 2 bytes of payload (expected >=2) Receiving message with 2 bytes of payload (expected >=2) Got ACK (id=0x1b) skytraq: Didn't get sector end tag Reading sector #0... Receiving message with 2 bytes of payload (expected >=2) Receiving message with 2 bytes of payload (expected >=2) Got ACK (id=0x1b) skytraq: Didn't get sector end tag -- Olaf Petersen <olafpe@...> ------------------------------------------------------------------------------ Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ _______________________________________________ Gpsbabel-misc mailing list http://www.gpsbabel.org Gpsbabel-misc@... To unsubscribe, change list options, or see archives, visit: https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc |
|
|
Re: MiniHomer: Problems downloading tracks
by Josef Reisinger
::
Rate this Message:
Hi out there,
I can verify the same for 1.4.3 on Windows and Linux. I did a quick compare of the sources of the relevant module between 1.4.2 and 1.4.3 and couldn't see changes which immediately would point me to this issue. As minihomer and skytraq inputs are broken, this seems not to be minihomer-specific. I contributed the miniHomer add-on on top of the skytraq module and the changes I made against 1.4.2 work quite a while for me. There are other changes in the sources for 1.4.3 which I don't know who applied them. Depended on my availability I might do a debug session over the weekend - a thing which I would like to avoid :-( Mathias, Jean-Christophe, any views from your side? Kind regards /jr On 06.12.2011 19:10, Olaf Petersen wrote: > Hi everyone, > > I am facing problems to download data from my MiniHomer logger, using GPSBabel ver. 1.4.3-beta20111112 on MS Windows 7 Home Premium SP1. The logger was updated to the FNAM Sports 4 - firmware and everything runs fine on nTrip 1.2.14 > > When I try to invoke GPSBabel with > "gpsbabel -D3 -i miniHomer,baud=38400,read-at-once=0 -f com3 -x height,wgs84tomsl > -x track,split=1h,title="TRACK" -o gtm -F c:\Users\olafpe\Documents\GPS\lasttrack.gtm" > I get an error message "Error reading sector #0". Same if I try to dump-file. I have appended a full printout at the end of this message. Each time, GPSBabel pauses for a few moments after printing the line "Reading sector #0", on a higher debug-level it can be seen that the MiniHomer only sends NMEA-data meanwhile, so I do have the idea that a new binary command-set is used in the newer firmware-versions. > > When I experiment with first-sector and last-sector options, all I manage is to download the POIs when I force GPSBabel to read an empty sector by e.g. setting first-sector and last-sector to 2. Only then a GTM-file is created. It is no problem to delete the MiniHomer's log using GPSBabel. > > Should I return to a previous firmware version? FNAM Sports 3 won't do the job. > > > Thank you in advance! > > Olaf > > > Printout follows > options: module/option=value: miniHomer/baud="38400" > options: module/option=value: miniHomer/erase="0" (=default) > options: module/option=value: miniHomer/first-sector="0" (=default) > options: module/option=value: miniHomer/initbaud="38400" (=default) > options: module/option=value: miniHomer/last-sector="-1" (=default) > options: module/option=value: miniHomer/no-output="0" (=default) > options: module/option=value: miniHomer/read-at-once="0" > Translated port name: "com3" > skytraq: Probing SkyTraq Venus at 38400baud... > Receiving message with 2 bytes of payload (expected>=2) > Receiving message with 2 bytes of payload (expected>=2) > Got ACK (id=0x02) > Receiving message with 14 bytes of payload (expected>=14) > skytraq: Venus device found: Kernel version = 1.4.42, ODM version = 1.4.41, revision (Y/M/D) = 11/03/23 > Receiving message with 2 bytes of payload (expected>=2) > Receiving message with 2 bytes of payload (expected>=2) > Got ACK (id=0x17) > Receiving message with 37 bytes of payload (expected>=9) > skytraq: Device status: free sectors: 509 / total sectors: 509 / 0% used / write ptr: 10996 > skytraq: Reading log data from device... > skytraq: start=0 used=1 > skytraq: opt_last_sector_val=-1 > Reading sector #0... > Receiving message with 2 bytes of payload (expected>=2) > Receiving message with 2 bytes of payload (expected>=2) > Got ACK (id=0x1b) > skytraq: Didn't get sector end tag > Reading sector #0... > Receiving message with 2 bytes of payload (expected>=2) > Receiving message with 2 bytes of payload (expected>=2) > Got ACK (id=0x1b) > skytraq: Didn't get sector end tag > Reading sector #0... > Receiving message with 2 bytes of payload (expected>=2) > Receiving message with 2 bytes of payload (expected>=2) > Got ACK (id=0x1b) > skytraq: Didn't get sector end tag > > > > ------------------------------------------------------------------------------ Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ _______________________________________________ Gpsbabel-misc mailing list http://www.gpsbabel.org Gpsbabel-misc@... To unsubscribe, change list options, or see archives, visit: https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc |
|
|
Re: MiniHomer: Problems downloading tracks
by Robert Lipe-2
::
Rate this Message:
Could you please experiment with for foo[] vs foo[13]) change at the top? That was the only thing that caught my eye as potentially suspicious when I reviewed it yesterday. The changes are small and I think I broke it. Like me, Mathias is traveling right now and said he'd help investigate when he's back. On Dec 7, 2011 7:01 AM, "Josef Reisinger" <datafabdriver@...> wrote:
Hi out there, ------------------------------------------------------------------------------ Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ _______________________________________________ Gpsbabel-misc mailing list http://www.gpsbabel.org Gpsbabel-misc@... To unsubscribe, change list options, or see archives, visit: https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc |
|
|
|
|
|
Re: MiniHomer: Problems downloading tracks [SOLVED]
by Mathias Adam-2
::
Rate this Message:
Hi,
Am 12.12.2011 03:17, schrieb Robert Lipe: > > > On Fri, Dec 9, 2011 at 4:57 AM, Josef Reisinger <datafabdriver@... > <mailto:datafabdriver@...>> wrote: > > Folks, > > there seems to be a lot of "embellishment" in the source code which > might have broken one line. Robert, you are right, it is line 247 > (SECTOR_READ_END[] vs. SECTOR_READ_END[13]) which breaks the code. > Could you revert the line to have the [13] specified? > > > I had a bad feeling that was it. The code actually is doing something > odd - it's defining S_R_E as a buffer of 13 bytes but using an > initializer of 14 bytes. (Remember that C strings always have a > terminating NUL.) In C++, that's simply not legal. indeed, that's no proper C++... though it's ok in C (if I remember correctly, the compiler doesn't add a trailing \0 if the initializer otherwise fits exactly into the array?). However in this case I'd avoid that syntax even in C as I suspect that the \0 embedded in the string would cause trouble sometime (as it did now; after all it worked ok for more than 2 years now ;-) ). > So I'll revert this for now, but we probably need to go back to the [] > notation and use sizeof(blah)-1 in the various loops that use it that > don't want to see a terminator. But release cycles as they are (esp. as > I don't have the affected hardware) we'll go with low risk for now. Because, with the embedded \0, it in fact isn't a string but rather an array of chars, I'd suggest to change it like this: --- 02_checkout-rev4135/gpsbabel/skytraq.c 2011-12-12 03:58:40.000000000 +0100 +++ 03_02-make/gpsbabel/skytraq.c 2011-12-13 00:04:40.000000000 +0100 @@ -244,7 +244,7 @@ gbuint8 NL[2] = { 0x0D, 0x0A }; gbuint8 MSG_START[2] = { 0xA0, 0xA1 }; -gbuint8 SECTOR_READ_END[13] = "END\0CHECKSUM="; +gbuint8 SECTOR_READ_END[] = { 'E','N','D', 0, 'C','H','E','C','K','S','U','M','=' }; static int skytraq_calc_checksum(const unsigned char *buf, int len) ------------------ btw Robert, why'd you remove the length specifier there? should this be done with NL and MSG_START too? Regards, Mathias > > > As you touch the sources anyway, could you replace line 646 > f.gps_week = ts & 0x00000FFF; > by > f.gps_week = ts & 0x00000 *3* FF; > > (replace mask 0xfff by 0x3ff) > > > Done. > Thanx for checking it out. > > You said you had some other changes pending. Was that it, or are now > now clear for takeoff for 1.4.3 from you? > > RJL > > > > Kind regards > /jr > > Am 07.12.2011 17:52, schrieb Robert Lipe: >> >> Could you please experiment with for foo[] vs foo[13]) change at >> the top? That was the only thing that caught my eye as potentially >> suspicious when I reviewed it yesterday. The changes are small and >> I think I broke it. >> >> Like me, Mathias is traveling right now and said he'd help >> investigate when he's back. >> >> On Dec 7, 2011 7:01 AM, "Josef Reisinger" <datafabdriver@... >> <mailto:datafabdriver@...>> wrote: >> >> Hi out there, >> >> I can verify the same for 1.4.3 on Windows and Linux. I did a >> quick >> compare of the sources of the relevant module between 1.4.2 >> and 1.4.3 >> and couldn't see changes which immediately would point me to >> this issue. >> As minihomer and skytraq inputs are broken, this seems not to be >> minihomer-specific. >> >> I contributed the miniHomer add-on on top of the skytraq >> module and the >> changes I made against 1.4.2 work quite a while for me. There >> are other >> changes in the sources for 1.4.3 which I don't know who >> applied them. >> >> Depended on my availability I might do a debug session over >> the weekend >> - a thing which I would like to avoid :-( >> >> Mathias, Jean-Christophe, any views from your side? >> >> Kind regards >> /jr >> >> On 06.12.2011 19:10, Olaf Petersen wrote: >> > Hi everyone, >> > >> > I am facing problems to download data from my MiniHomer >> logger, using GPSBabel ver. 1.4.3-beta20111112 on MS Windows 7 >> Home Premium SP1. The logger was updated to the FNAM Sports 4 >> - firmware and everything runs fine on nTrip 1.2.14 >> > >> > When I try to invoke GPSBabel with >> > "gpsbabel -D3 -i miniHomer,baud=38400,read-at-once=0 -f com3 >> -x height,wgs84tomsl >> > -x track,split=1h,title="TRACK" -o gtm -F >> c:\Users\olafpe\Documents\GPS\lasttrack.gtm" >> > I get an error message "Error reading sector #0". Same if I >> try to dump-file. I have appended a full printout at the end >> of this message. Each time, GPSBabel pauses for a few moments >> after printing the line "Reading sector #0", on a higher >> debug-level it can be seen that the MiniHomer only sends >> NMEA-data meanwhile, so I do have the idea that a new binary >> command-set is used in the newer firmware-versions. >> > >> > When I experiment with first-sector and last-sector options, >> all I manage is to download the POIs when I force GPSBabel to >> read an empty sector by e.g. setting first-sector and >> last-sector to 2. Only then a GTM-file is created. It is no >> problem to delete the MiniHomer's log using GPSBabel. >> > >> > Should I return to a previous firmware version? FNAM Sports >> 3 won't do the job. >> > >> > >> > Thank you in advance! >> > >> > Olaf >> > >> > >> > Printout follows >> > options: module/option=value: miniHomer/baud="38400" >> > options: module/option=value: miniHomer/erase="0" (=default) >> > options: module/option=value: miniHomer/first-sector="0" >> (=default) >> > options: module/option=value: miniHomer/initbaud="38400" >> (=default) >> > options: module/option=value: miniHomer/last-sector="-1" >> (=default) >> > options: module/option=value: miniHomer/no-output="0" (=default) >> > options: module/option=value: miniHomer/read-at-once="0" >> > Translated port name: "com3" >> > skytraq: Probing SkyTraq Venus at 38400baud... >> > Receiving message with 2 bytes of payload (expected>=2) >> > Receiving message with 2 bytes of payload (expected>=2) >> > Got ACK (id=0x02) >> > Receiving message with 14 bytes of payload (expected>=14) >> > skytraq: Venus device found: Kernel version = 1.4.42, ODM >> version = 1.4.41, revision (Y/M/D) = 11/03/23 >> > Receiving message with 2 bytes of payload (expected>=2) >> > Receiving message with 2 bytes of payload (expected>=2) >> > Got ACK (id=0x17) >> > Receiving message with 37 bytes of payload (expected>=9) >> > skytraq: Device status: free sectors: 509 / total sectors: >> 509 / 0% used / write ptr: 10996 >> > skytraq: Reading log data from device... >> > skytraq: start=0 used=1 >> > skytraq: opt_last_sector_val=-1 >> > Reading sector #0... >> > Receiving message with 2 bytes of payload (expected>=2) >> > Receiving message with 2 bytes of payload (expected>=2) >> > Got ACK (id=0x1b) >> > skytraq: Didn't get sector end tag >> > Reading sector #0... >> > Receiving message with 2 bytes of payload (expected>=2) >> > Receiving message with 2 bytes of payload (expected>=2) >> > Got ACK (id=0x1b) >> > skytraq: Didn't get sector end tag >> > Reading sector #0... >> > Receiving message with 2 bytes of payload (expected>=2) >> > Receiving message with 2 bytes of payload (expected>=2) >> > Got ACK (id=0x1b) >> > skytraq: Didn't get sector end tag >> > >> > >> > >> > >> >> >> ------------------------------------------------------------------------------ >> Cloud Services Checklist: Pricing and Packaging Optimization >> This white paper is intended to serve as a reference, >> checklist and point of >> discussion for anyone considering optimizing the pricing and >> packaging model >> of a cloud services business. Read Now! >> http://www.accelacomm.com/jaw/sfnl/114/51491232/ >> _______________________________________________ >> Gpsbabel-misc mailing list http://www.gpsbabel.org >> Gpsbabel-misc@... >> <mailto:Gpsbabel-misc@...> >> To unsubscribe, change list options, or see archives, visit: >> https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc >> > > > ------------------------------------------------------------------------------ Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure _______________________________________________ Gpsbabel-misc mailing list http://www.gpsbabel.org Gpsbabel-misc@... To unsubscribe, change list options, or see archives, visit: https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc |
|
|
Re: MiniHomer: Problems downloading tracks [SOLVED]
by Josef Reisinger
::
Rate this Message:
Robert,
there may be indeed another change necessary to reflect the behavior of the miniHomer device (which is based on syktraq chip set). According to the specification, the speed is stored as a 10-Bit value, resulting into a maximum speed of 1023 km/h in the recording. I had one occasion where a plane exceeded the speed. Looking at the low-level data in the protocol, it seems as if at least miniHomer correctly uses 11 bits to recording the speed. I don't know whether this is miniHomer specific. The three bits "above" the 10 for speed are marked as reserved in the specification. I own another skytraq-based device (as you might remember from a previous discussion quite a time ago), but I won't travel at a speed > 1023km/h in the next couple of weeks, so I cannot compare the behaviour of miniHomer with the other device. I would anyway assume that logging is part of the core skytraq software and any skytraq based device will use eleven bits for speed. Therefor I would propose to change the skytraq.c module. To correctly record speeds exceeding 1023km/h, the following change would be necessary: In line 622 of skytraq.c , the 0x0F mask needs to be changed to 0x1F Old: #define ITEM_SPEED(item) (item->type_and_speed[1] | ((item->type_and_speed[0] & 0x0F) << 8)) New: #define ITEM_SPEED(item) (item->type_and_speed[1] | ((item->type_and_speed[0] & 0x1F) << 8)) Let me know about your view. Kind regards Josef Reisinger On 12.12.2011 03:17, Robert Lipe wrote:
------------------------------------------------------------------------------ 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ _______________________________________________ Gpsbabel-misc mailing list http://www.gpsbabel.org Gpsbabel-misc@... To unsubscribe, change list options, or see archives, visit: https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc |
|
|
Re: MiniHomer: Problems downloading tracks [SOLVED]
by Robert Lipe-2
::
Rate this Message:
+gpsbabel-code, gpsbabel-misc to bcc. We scare the masses when we talk about bits and bytes like this...
On Mon, Dec 12, 2011 at 5:42 PM, Mathias Adam <m.adam@...> wrote:
Because, with the embedded \0, it in fact isn't a string but rather an array of chars, I'd suggest to change it like this: Yes, that's "obviously" the right way to do that. Lying that a character buffer is a string is silly. btw Robert, why'd you remove the length specifier there? should this be done with NL and MSG_START too? To break the beta.... As I described before, I was planning to move the project to C++. Once I started looking at a time frame before I'd get everything put back together, I decided to push out a maintenance release before doing that. Once I fed it into G++ and it complained about the string going into a character buf, I applied the "obvious" fix...Which broke a target that I couldn't test.
Tic, it looks to me like the units are Kilometers/hour, not knot/hour. I defer to those with hardware and datasheets. Josef, I'm nervous about adding undocumented bits into a supported field. If some other build or version of that chipset uses that reserved bit for something else, we screw up the speed for everyone. I'll defer to Matthais as a tie-breaker.
RJL ------------------------------------------------------------------------------ Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure _______________________________________________ Gpsbabel-misc mailing list http://www.gpsbabel.org Gpsbabel-misc@... To unsubscribe, change list options, or see archives, visit: https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc |
|
|
Re: MiniHomer: Problems downloading tracks [SOLVED]
by AMB2
::
Rate this Message:
I have a very similar problem as the original poster running Windows 7, minihomer FNAM4. It seems to read a few sectors, then can't read the last ones. The tracks can be downloaded properly with NTRIP version 1.2.14. I am using GPSBabel 1.4.3 created on 29th January 2012. Debug trace level 3 attached.... so I don't think the problem reported above has been fully fixed. In case it is relevant, my Minihomer reports: "Skytraq kernel 1.4.42, version 1.4.33, revision 2010.10.21" when responding to 'query software version'.
Andy ******************** gpsbabel -D3 -w -t -i miniHomer,baud=38400,erase=0,initbaud=38400,last-sector=-1,no-output=0,read-at-once=0 -f COM11 -o kml,lines=1,points=1,floating=0,extrude=0,track=0,trackdata=1,trackdirection=0,labels=1 -F C:/Users/abarnard/Desktop/output.kml options: module/option=value: miniHomer/baud="38400" options: module/option=value: miniHomer/erase="0" (=default) options: module/option=value: miniHomer/first-sector="0" (=default) options: module/option=value: miniHomer/initbaud="38400" (=default) options: module/option=value: miniHomer/last-sector="-1" (=default) options: module/option=value: miniHomer/no-output="0" (=default) options: module/option=value: miniHomer/read-at-once="0" Translated port name: "\\.\\COM11" skytraq: Probing SkyTraq Venus at 38400baud... Receiving message with 2 bytes of payload (expected >=2) Receiving message with 2 bytes of payload (expected >=2) Got ACK (id=0x02) Receiving message with 14 bytes of payload (expected >=14) skytraq: Venus device found: Kernel version = 1.4.42, ODM version = 1.4.33, revision (Y/M/D) = 10/10/21 Receiving message with 2 bytes of payload (expected >=2) Receiving message with 2 bytes of payload (expected >=2) Got ACK (id=0x17) Receiving message with 37 bytes of payload (expected >=9) skytraq: Device status: free sectors: 502 / total sectors: 509 / 2% used / write ptr: 40650 skytraq: Reading log data from device... skytraq: start=0 used=8 skytraq: opt_last_sector_val=-1 Reading sector #0... Receiving message with 2 bytes of payload (expected >=2) Receiving message with 2 bytes of payload (expected >=2) Got ACK (id=0x1b) Received 4090 bytes of log data Reading sector #1... Receiving message with 2 bytes of payload (expected >=2) Receiving message with 2 bytes of payload (expected >=2) Got ACK (id=0x1b) Received 4090 bytes of log data Reading sector #2... skytraq: Didn't get message start tag skytraq: Got neither ACK nor NACK, resending msg (id=0x1b)... Receiving message with 2 bytes of payload (expected >=2) Receiving message with 2 bytes of payload (expected >=2) Got ACK (id=0x1b) Received 4090 bytes of log data Reading sector #3... skytraq: Didn't get message start tag skytraq: Got neither ACK nor NACK, resending msg (id=0x1b)... skytraq: Didn't get message start tag skytraq: Got neither ACK nor NACK, resending msg (id=0x1b)... skytraq: Didn't get message start tag skytraq: Got neither ACK nor NACK, aborting (msg id was 0x1b). skytraq: Didn't receive ACK Reading sector #3... skytraq: Didn't get message start tag skytraq: Got neither ACK nor NACK, resending msg (id=0x1b)... skytraq: Didn't get message start tag skytraq: Got neither ACK nor NACK, resending msg (id=0x1b)... skytraq: Didn't get message start tag skytraq: Got neither ACK nor NACK, aborting (msg id was 0x1b). skytraq: Didn't receive ACK Reading sector #3... skytraq: Didn't get message start tag skytraq: Got neither ACK nor NACK, resending msg (id=0x1b)... skytraq: Didn't get message start tag skytraq: Got neither ACK nor NACK, resending msg (id=0x1b)... skytraq: Didn't get message start tag skytraq: Got neither ACK nor NACK, aborting (msg id was 0x1b). skytraq: Didn't receive ACK GPSBabel Version: 1.4.3 skytraq: Error reading sector 3 Error running gpsbabel: Process exited unsucessfully with code 1 |
| Free embeddable forum powered by Nabble | Forum Help |
