gpsd-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Duplicate or near-duplicate messages on u-blox M8


From: Luke Hutchison
Subject: Re: Duplicate or near-duplicate messages on u-blox M8
Date: Thu, 27 Feb 2020 04:49:43 -0700

I have narrowed down what's going on.

Actually it is the binary protocol, not the NMEA protocol, that has the problem.

Here are the steps I followed:

1. Disabled gpsd systemd service

2. Plugged in GPS device

3. In terminal 1:

$ gpsd -S 4000 -D 3 -N /dev/ttyUSB0

4. In terminal 2, switched the device mode from the default ("native":1) to NMEA ("native":0). Changing the "native" flag usually takes a couple of attempts (or maybe I didn't wait long enough). Sent characters are in red, the response is in green, and important parts are bolded and underlined in the response.

$ telnet localhost 4000
Trying ::1...
Connected to localhost.
Escape character is '^]'.
{"class":"VERSION","release":"3.19","rev":"3.19","proto_major":3,"proto_minor":14}
?DEVICE;
{"class":"DEVICE","path":"/dev/ttyUSB0","activated":"2020-02-27T11:15:45.149Z","native":0,"bps":4800,"parity":"N","stopbits":1,"cycle":1.00}
?DEVICE;
{"class":"DEVICE","path":"/dev/ttyUSB0","activated":"2020-02-27T11:15:45.149Z","native":0,"bps":4800,"parity":"N","stopbits":1,"cycle":1.00}
?DEVICE;
{"class":"DEVICE","path":"/dev/ttyUSB0","driver":"u-blox","subtype":"SW EXT CORE 3.01 (107900),HW 00080000,ROM BASE 3.01 (107888),FWVER=SPG 3.01,PROTVER=18.00,MOD=NEO-M8N-0,FIS=0xEF4015 (100111),G","activated":"2020-02-27T11:16:16.336Z","flags":1,"native":1,"bps":9600,"parity":"N","stopbits":1,"cycle":1.00,"mincycle":0.25}
?DEVICE={"native":0}
{"class":"DEVICE","path":"/dev/ttyUSB0","driver":"u-blox","subtype":"SW EXT CORE 3.01 (107900),HW 00080000,ROM BASE 3.01 (107888),FWVER=SPG 3.01,PROTVER=18.00,MOD=NEO-M8N-0,FIS=0xEF4015 (100111),G","activated":"2020-02-27T11:16:48.331Z","flags":1,"native":1,"bps":9600,"parity":"N","stopbits":1,"cycle":1.00,"mincycle":0.25}
?DEVICE={"native":0}
{"class":"DEVICE","path":"/dev/ttyUSB0","driver":"u-blox","subtype":"SW EXT CORE 3.01 (107900),HW 00080000,ROM BASE 3.01 (107888),FWVER=SPG 3.01,PROTVER=18.00,MOD=NEO-M8N-0,FIS=0xEF4015 (100111),G","activated":"2020-02-27T11:16:53.717Z","flags":1,"native":0,"bps":9600,"parity":"N","stopbits":1,"cycle":1.00,"mincycle":0.25}


5. In terminal 3: 

$ gpspipe -R -n 100 localhost:4000 > /tmp/nmea.log

6. I repeated the above steps, but instead used `?DEVICE={"native":1}` to switch the receiver to binary mode rather than NMEA mode using terminal 2, and then I used `gpspipe -R -n 100 localhost:4000 > /tmp/binary.log` in terminal 3 to record to a second logfile.

=> nmea.log and binary.log are attached.

7. Now I used the following commands to replay these logfiles, one at a time: (I used a different port so I could be sure which gpsd protocol listener I was talking to)

$ gpsfake -c 0.5 -P 4001 /tmp/nmea.log

$ gpsfake -c 0.5 -P 4001 /tmp/binary.log

and in another terminal, while running each of the above `gpsfake` commands I viewed the replay of each log with

$ cgps localhost:4001

RESULTS:

(To preempt any reaction about this word, "Altitude" literally means the literal display field in cgps that says "Altitude"!)
  • For nmea.log:
    • Latitude, Longitude and Altitude are all stable, and update about once per second. (The log replay delay `-c 0.5` above slows this down to take longer than a second though.)
  • For binary.log:
    • Altitude is not stable -- it oscillates down and then up with each update (i.e. swings down then swings up by a few meters, or vice versa, every second).
    • Sometimes there are three location adjustments per 1Hz update, and two of these will be high and the other low, or vice versa.
    • The Latitude and Longitude fields change by a tiny amount as Altitude oscillates up and then down within the two or three updates within a 1 second update window. i.e. Latitude and Longitude are almost, but not exactly, held stable during each 1 second update window.
The logfiles were captured maybe a minute apart, without moving the receiver. The above behavior ("RESULTS") has 100% reproducibility, by simply setting the "native":0 or "native":1 device parameter in the telnet console.

You can of course replay the attached logfiles yourself to observe this phenomenon.

Thanks for taking a look at these logs. I hope you now have what you need to get to the bottom of the problem. Please let me know if there are other tests you want me to run.

Luke



Attachment: nmea.log
Description: Text Data

Attachment: binary.log
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]