miniHomer : checksum error, last-sector

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

miniHomer : checksum error, last-sector

nt.guilde
Hardware : Navin miniHomer.
Software : gpsbabel-1.5.2 / Archlinux / RaspberryPi.

The GPS reports this :

    ...
    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 >=35)
    #logging: tmin=5, tmax=65535, dmin=0, dmax=65535, vmin=0, vmax=65535
    skytraq: Device status: free sectors: 465 / total sectors: 509 / 9% used /
    write ptr: 191134
    skytraq: Reading log data from device...
    skytraq: start=0 used=45
    ...


0) Great software ; thank you very much.


1) Checksum error

  Sector 26 is corrupted :

    $ gpsbabel -D3 -i skytraq -f /dev/navin -o gpx -F -
 
    ...
    Reading sector #25...
    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 #26...
    Receiving message with 2 bytes of payload (expected >=2)
    Receiving message with 2 bytes of payload (expected >=2)
    Got ACK (id=0x1b)
    Received 2674 bytes of log data
    skytraq: Checksum error while reading sector: got 0xf7, expected 0xf8
    Reading sector #26...
    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 2674 bytes of log data
    skytraq: Checksum error while reading sector: got 0xf7, expected 0xf8
    Reading sector #26...
    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 2674 bytes of log data
    skytraq: Checksum error while reading sector: got 0xf7, expected 0xf8
    skytraq: Error reading sector 26

  In my opinion, the corrupted sectors must be discarded, but the others
should be exploited ; less data is better than no data at all. I downloaded
the sources, modified

    static void skytraq_read_tracks(void) (file skytraq.cc)

from

        if (got_sectors <= 0) {
          fatal(MYNAME ": Error reading sector %i\n", i);
        }

to

        if (got_sectors <= 0) {
          i++ ;
          // fatal(MYNAME ": Error reading sector %i\n", i);
        }

and salvaged 44 sectors.


2) last-sector is disregarded when next to last sector is not full

    $ gpsbabel -D3 -i skytraq,last-sector=25 -f /dev/navin -o gpx -F -
   
    ...
    Reading sector #25...
    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
    skytraq: Last sector is nearly full, reading one more sector
    Reading sector #26...
    Receiving message with 2 bytes of payload (expected >=2)
    Receiving message with 2 bytes of payload (expected >=2)
    Got ACK (id=0x1b)
    Received 2674 bytes of log data
    skytraq: Checksum error while reading sector: got 0xf7, expected 0xf8
    ...

It should stop after sector 25, but it does not. Sector 24 is nearly full also ;
it does not stop after sector 24 either.


3) miniHomer is broken

    $ gpsbabel -D3 -i miniHomer -f /dev/navin -o gpx -F -
    GPSBabel Version: 1.5.2
    options: module/option=value: miniHomer/baud="115200" (=default)
    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="255" (=default)
    skytraq: Probing SkyTraq Venus at 38400baud...
    skytraq: Didn't get message start tag
    Didn't receive ACK (-3), retrying...
    skytraq: Didn't get message start tag
    Didn't receive ACK (-3)
    skytraq: Can't find skytraq device on '/dev/navin'


4) Compilation warnings : variables declared but never used, type mismatch

    skytraq.cc: In function 'int skytraq_rd_msg(const void*, unsigned int)':
    skytraq.cc:288:29: warning: comparison between signed and unsigned integer
    expressions [-Wsign-compare]
       if ((rcv_len = rd_word()) < len) {
                                 ^

5) db() writes to stdout

  It should write to stderr, in my opinion.

  Thank you. -Nicolas

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
Reply | Threaded
Open this post in threaded view
|

Re: miniHomer : checksum error, last-sector

Robert Lipe-4


On Sun, Jul 5, 2015 at 1:41 PM, <[hidden email]> wrote:
Hardware : Navin miniHomer.
Software : gpsbabel-1.5.2 / Archlinux / RaspberryPi.

The GPS reports this :

    ...
    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 >=35)
    #logging: tmin=5, tmax=65535, dmin=0, dmax=65535, vmin=0, vmax=65535
    skytraq: Device status: free sectors: 465 / total sectors: 509 / 9% used /
    write ptr: 191134
    skytraq: Reading log data from device...
    skytraq: start=0 used=45
    ...


0) Great software ; thank you very much.

Thanx.  Can't say we've had many reports on Pi.  You're likely to be the only one with that combination. 

 
1) Checksum error
[ ... ] 
  
  In my opinion, the corrupted sectors must be discarded, but the others
should be exploited ; less data is better than no data at all. I downloaded
the sources, modified

I'm not sure that corrupt data is better than no data.  Discarding defective blocks seems bad.  Are we misreading them, or does your device perhaps actually have defective flash or a firmware bug that creates defective blocks or is the serial driver dropping data or something?  


2) last-sector is disregarded when next to last sector is not full

    $ gpsbabel -D3 -i skytraq,last-sector=25 -f /dev/navin -o gpx -F -

    ...
    Reading sector #25...
    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
    skytraq: Last sector is nearly full, reading one more sector
    Reading sector #26...
    Receiving message with 2 bytes of payload (expected >=2)
    Receiving message with 2 bytes of payload (expected >=2)
    Got ACK (id=0x1b)
    Received 2674 bytes of log data
    skytraq: Checksum error while reading sector: got 0xf7, expected 0xf8
    ...

It should stop after sector 25, but it does not. Sector 24 is nearly full also ;
it does not stop after sector 24 either.

I don't know the skytraq protocol from the top of my head, but it seems odd to have partial sectors in the middle.  Patch welcome.

 
3) miniHomer is broken

    $ gpsbabel -D3 -i miniHomer -f /dev/navin -o gpx -F -
    GPSBabel Version: 1.5.2
    options: module/option=value: miniHomer/baud="115200" (=default)
    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="255" (=default)
    skytraq: Probing SkyTraq Venus at 38400baud...
    skytraq: Didn't get message start tag
    Didn't receive ACK (-3), retrying...
    skytraq: Didn't get message start tag
    Didn't receive ACK (-3)
    skytraq: Can't find skytraq device on '/dev/navin'

I defer to Josef or Dirk or someone else with that combination.

I think Minihomer is Skytraq with abiliity to read waypoints and different defaults, so understanding why you can work with Skytraq and not MiniHomer would be interesting.


 

4) Compilation warnings : variables declared but never used, type mismatch

    skytraq.cc: In function 'int skytraq_rd_msg(const void*, unsigned int)':
    skytraq.cc:288:29: warning: comparison between signed and unsigned integer
    expressions [-Wsign-compare]
       if ((rcv_len = rd_word()) < len) {

That's a good example of a case where "fixing" a warning in a mechanical way is risky. rd_word is explicitly called 'unsigned int', yet rcv_len is signed and then tested < 0. Should rd_word return signed int?  Should there be an explicit cast there?  Hard to say from inspection of small amount of code.  If you have the hardware and ability to test it, recommendations welcome.

 
5) db() writes to stdout

  It should write to stderr, in my opinion.

There's no winning move on that one; some people will prefer stdout or stderr.  This is an area where I've not done well as project leader enforcing consistency.  Different formats/modules have different debugging implementations. 

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
Reply | Threaded
Open this post in threaded view
|

Re: miniHomer : checksum error, last-sector

nt.guilde
Quoting Robert Lipe, Wed  8 Jul 2015, 19:51 +0200 CEST :
> I'm not sure that corrupt data is better than no data.  Discarding
> defective blocks seems bad.  Are we misreading them, or does your device
> perhaps actually have defective flash or a firmware bug that creates
> defective blocks or is the serial driver dropping data or something?

  I don't know how to answer your questions ; but I could clarify the
description I gave in my previous message.
  There is one bad sector (#26) among the 45 used sectors reported
by gpsbabel ; because of it, gpsbabel does not extract any data from
the GPS ; it tries to read sector #26 three times, then exits with
a failure message on stderr. Of course, sector #26 must be discarded,
but the data in the other 44 sectors is valid. That is why I modified
the code as described.
  This is the first time I saw this behaviour from the GPS ; I never saw
a corrupted sector until now.

> 2) last-sector is disregarded when next to last sector is not full
> >
> >     $ gpsbabel -D3 -i skytraq,last-sector=25 -f /dev/navin -o gpx -F -
> >
> >     ...
> >     Reading sector #25...
> >     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
> >     skytraq: Last sector is nearly full, reading one more sector
> >     Reading sector #26...
> >     Receiving message with 2 bytes of payload (expected >=2)
> >     Receiving message with 2 bytes of payload (expected >=2)
> >     Got ACK (id=0x1b)
> >     Received 2674 bytes of log data
> >     skytraq: Checksum error while reading sector: got 0xf7, expected 0xf8
> >     ...
> >
> > It should stop after sector 25, but it does not. Sector 24 is nearly full
> > also ;
> > it does not stop after sector 24 either.
> >
>
> I don't know the skytraq protocol from the top of my head, but it seems odd
> to have partial sectors in the middle.  Patch welcome.

  My understanding, from reading the code, is that a sector ends with
the sequence "END\0CHECKSUM=", followed by a one-octet checksum. Could that
sequence occur as valid data within a sector ? Something like this :

      <data>END\0CHECKSUM=<more-data>END\0CHECKSUM=<checksum>
      <-------------------- sector 26 ---------------------->

If someone knows the answer, that would spare me some experimenting with
the code.

> > 5) db() writes to stdout
> >
> >   It should write to stderr, in my opinion.
> >
>
> There's no winning move on that one; some people will prefer stdout or
> stderr.

  In my opinion, data should be separated from the diagnostic messages ;
those who want them together can still redirect stderr to stdout ;
splitting them is not possible, however. But this is a very minor issue.
  gpsbabel has been managing my GPS for four years now ; thank you very
much indeed. -Nicolas

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc