[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-users] Communication loss with GR-701W
|
From: |
Gary E. Miller |
|
Subject: |
Re: [gpsd-users] Communication loss with GR-701W |
|
Date: |
Thu, 6 Jun 2019 20:06:27 -0700 |
Yo Benoît!
On Wed, 5 Jun 2019 15:42:31 +0200
Benoît Thébaudeau <address@hidden> wrote:
> So far, I have not been able to duplicate the catatonic module issue
> with f900fb5b3c3f312ccd0908e5e4f22968a54e9912. However, I still get
> the checksum errors:
Yeah, still problems. See below:
> gpsd:IO: UBX: len 108
> gpsd:IO: UBX checksum 0xc421 over length 108, expecting 0x010f (type 0x0a04)
This should never happen...
> Here are the requested command results in this case, which confirm
> the overrun:
Yeah, not good.
> $ ./ubxtool -P 14 -p MON-IO -v 2
[...]
> UBX-MON-IO:
[...]
> Port: 1 (UART1)
> rxBytes 2214 txBytes 60884 parityErrs 0 framingErrs 0
> overrunErrs 1936 breakCond 0 reserved 1
^^^^^^^^^^^^^^^^
Not good.
From the doc:
overrunErrs: Number of 100ms timeslots with overrun errors
So, not just errors, time slots with errors.
> $ ./ubxtool -P 14 -p MON-MSGPP -v 2
[...]
> skipped 0 0 0 0 196623 0
^^^^^^
A lot of skjipped messages. But, odd. Port 5 is some sort of
undocumented internal port.
> $ ./ubxtool -P 14 -p MON-RXBUF -v 2
[...]
> ubxtool: poll MON-RXBUF
> sent:
> UBX-MON-RXBUF:
> Poll request
>
> {"class":"VERSION","release":"3.19-dev","rev":"r1711","proto_major":3,"proto_minor":14}
> {"class":"DEVICES","devices":[{"class":"DEVICE","path":"/dev/ttyUSB0","driver":"u-blox","subtype":"SW
> 1.00 (59842),HW 00070000,PROTVER
> 14.00,GPS;SBAS;GLO;QZSS","activated":"2019-06-05T13:15:49.292Z","flags":1,"native":1,"bps":9600,"parity":"N","stopbits":1,"cycle":1.00,"mincycle":0.25}]}
> {"class":"WATCH","enable":true,"json":false,"nmea":false,"raw":2,"scaled":false,"timing":false,"split24":false,"pps":false}
> {"class":"DEVICE","path":"/dev/ttyUSB0","driver":"u-blox","subtype":"SW
> "bps":9600
Any way you can get that speed higher? 9600 should be enough...
> UBX-MON-RXBUF:
> pending 0 0 0 0 0 0
> usage 0 0 0 0 0 0
> peakUsage 0 0 0 0 0 0
That says the GPS input buffers never filled. Even a tiny bit.
> $ ./ubxtool -P 14 -p MON-TXBUF -v 2
[...]
> UBX-MON-TXBUF:
> pending 0 0 0 0 0 0
> usage 0 0 0 0 0 0
> peakUsage 0 0 0 0 0 0
> tUsage 3 tPeakUsage 12 errors x0 reserved1 0
> errors () limit (0)
The output buffer never more than 12% full. So not a problem either.
> Same thing with gpsd 3.18.1 catatonic module issue + ubxtool
Yeah, more checksum, and other, errors:
> gpsd:IO: UBX checksum 0xb0ff over length 108, expecting 0x3020 (type 0x0a04)
> gpsd:WARN: TXT: Error: trk tick 3 144000 dt 9644
> gpsd:IO: <= GPS: $GPTXT,01,01,00,trk tick 2 96000 dt 43249*32
> gpsd:WARN: TXT: Error: trk tick 2 96000 dt 43249
> gpsd:IO: <= GPS: $GPTXT,01,01,00,trk tick 2 96000 dt 4451*0E
> gpsd:WARN: TXT: Error: trk tick 2 96000 dt 4451
> gpsd:IO: <= GPS: $GPTXT,01,01,00,trk tick 4 192000 dt 39852*0C
> gpsd:WARN: TXT: Error: trk tick 4 192000 dt 39852
So. We know:
The GPS UART1 input buffer is not overrunning.
The GPS UART1 output buffer is not overrunning.
The GPS UART1 input is seeing overrun errors.
Seems to me a lot like a bad serial connection to UART1.
How is the GPS UART1 connected to your host?
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
address@hidden Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin
pgpt_84jSfzoz.pgp
Description: OpenPGP digital signature