On Wed, Feb 26, 2020 at 4:30 PM Gary E. Miller <address@hidden> wrote:
That is info on the board, we need the GPS model. You can find it
this way with gpsd running:
ubxtool -p MON-VER
Here you go.. warnings and all :-)
$ ubxtool -p MON-VERubxtool: poll MON-VERsent:UBX-MON-VER:Poll request/usr/bin/ubxtool:6715: DeprecationWarning: time.clock has been deprecated in Python 3.3 and will be removed from Python 3.8: use time.perf_counter or time.process_time insteadstart = time.clock()/usr/bin/ubxtool:6716: DeprecationWarning: time.clock has been deprecated in Python 3.3 and will be removed from Python 3.8: use time.perf_counter or time.process_time insteadwhile read_opts['input_wait'] > (time.clock() - start):UBX-MON-VER:swVersion EXT CORE 3.01 (107900)hwVersion 00080000extension ROM BASE 3.01 (107888)extension FWVER=SPG 3.01extension PROTVER=18.00extension MOD=NEO-M8N-0extension FIS=0xEF4015 (100111)extension GPS;GLO;GAL;BDSextension SBAS;IMES;QZSS
Yup. Such are the problems with NMEA. That is why u-blox binary
mode is preferred.
Sure, but surely cgps could simply not generate location updates with SKY messages?
Either way, the GPS should always be in binary mode as far as I am aware, if that is gpsd's default.
However, I just tried running `gpspipe -R -n 100 > /tmp/raw2.log` again, and this time the log is in NMEA mode. See attachment. I didn't even touch the receiver, other than maybe unplugging it and plugging it back in. So gpsd is not even reliably selecting binary mode for some reason. Restarting the gpsd daemon and unplugging / replugging the GPS receiver switched it back to binary mode.
> The slight drift in location during these
> non-location updates is probably due to Kalman filtering or something.
Nope. gpsd does no filtering.
Then why would a SKY message, which contains no location information, generate a location update that was not the same as, but a tiny bit offset from, the previous location? Here's a plot of lat/long over time for a few seconds of GPS data. Note the near-double-ups (or triple-ups). (This is a plot of the lat/long/altitude table I sent in my previous message):
This combination of responses was a little bewildering:
> > Which might be the bug fixed in 3.19. Is the delta equal to your
> > geoid separation?
I'll ask again for you geoid separation.
[...]
> I don't know how to check delta or geoid separation, please advise.
It would be in the raw.log I asked for.
[...]
This shows us what is in your raw.log:
ubxtool -f raw.log -v 2
As I said I didn't know what geoid separation was or how to find it. I did send the log as requested. You even opened the log attachment and found the geoid separation :-D
> I'm using 3.19 (specifically Fedora's binary gpsd-3.19-2.fc31.x86_64
> package).
3.20 is the latest release. No idea here how Fedora may have miunged it.
gpsd 3.20 was released on 2020-01-01. Fedora 31 was released on 2019-10-29. Fedora usually only updates package versions between releases if they need to address critical bugfixes. Hopefully Fedora will update to the latest gpsd for the Fedora 32 release, due 2020-04-21.
How are you starting pgsd? With systemd? Or? Are you using the "-n"
option. These affect gpsd operation.
With systemd:
$ cat /usr/lib/systemd/system/gpsd.service[Unit]Description=GPS (Global Positioning System) DaemonRequires=gpsd.socket# Needed with chrony SOCK refclockAfter=chronyd.service[Service]Type=forkingEnvironmentFile=-/etc/default/gpsdEnvironmentFile=-/etc/sysconfig/gpsdExecStart=/usr/sbin/gpsd $GPSD_OPTIONS $OPTIONS $DEVICES[Install]WantedBy=multi-user.targetAlso=gpsd.socket
/etc/default/gpsd does not exist. /etc/sysconfig/gpsd is:
# Options for gpsd, including serial devicesOPTIONS=""# Set to 'true' to add USB devices automatically via udevUSBAUTO="true"
> I am using only defaults.
Are you sure? Did you reset the device? Many receivers get changed
from the defaults before shipping.
In that case no, I'm not sure the settings are default. I am using the device as shipped, except that I updated the firmware using the u-blox tool to the latest (3.01) release. But you also now have the output of `ubxtool -f raw.log -v 2`, so you should be able to see what the settings are -- right?
That looks very different than you sent last time. You previously
sent NMEA as the output of your receiver, and you just sent u-blox
binary. NMEA != binary. So either you did not collect what you
thought you collected, or you changed something.
As I mentioned, last time I just used gpscat to capture the log, because that's what your FAQ suggested doing:
5. Capture a log that triggers the problem
If we can reproduce your gpsd problem, we can usually fix it very rapidly. If we can't reproduce it, you might get lucky or you might not — and we try hard, but all too often the result is 'not'.
Therefore the most important step you can take is to capture a log of some receiver output that reproduces the bug;
gpscatwill help you.
In my previous message I followed the request from your previous message, and instead used `gpspipe -R -n 100 > raw.log`. Hence the difference. You need to update that part of the FAQ too.
This is why we need to know how you collect data that you send here.
Of course, I am trying to follow your instructions closely, but they were different from what I sent initially because I followed the FAQ closely the first time around, before posting to this mailing list. Please be patient as I catch up, I'm totally new to the GPS device and protocol world.
Notice "height" (height above the ellipsoid) is 1344.541 meters,
and hMSL (height Mean Sea Level) is 1363.357 meters. So your
geoid separation (height - hMSL) is -18.816.
OK, thanks for explaining. I just tested this:
height = 1332.800
hMSL = 1351.616
geoid separation = -18.816 (same exact value as before for the same location, despite a drift in altitude measurement)
Now the altitude is stable between messages, but the epv, epx, epy values are oscillating. Here is the output of `gpspipe -w` for two seconds:
{"class":"SKY","device":"/dev/ttyUSB0","xdop":0.58,"ydop":0.72,"vdop":1.22,"tdop":0.84,"hdop":0.93,"gdop":1.74,"pdop":1.53,"satellites":[{"PRN":1,"el":12,"az":37,"ss":15,"used":false,"gnssid":0,"svid":1},{"PRN":2,"el":11,"az":193,"ss":13,"used":false,"gnssid":0,"svid":2},{"PRN":3,"el":3,"az":77,"ss":0,"used":false,"gnssid":0,"svid":3},{"PRN":6,"el":35,"az":169,"ss":22,"used":true,"gnssid":0,"svid":6},{"PRN":12,"el":5,"az":289,"ss":16,"used":false,"gnssid":0,"svid":12},{"PRN":13,"el":17,"az":224,"ss":19,"used":true,"gnssid":0,"svid":13},{"PRN":15,"el":12,"az":255,"ss":16,"used":true,"gnssid":0,"svid":15},{"PRN":17,"el":71,"az":31,"ss":24,"used":true,"gnssid":0,"svid":17},{"PRN":19,"el":79,"az":268,"ss":23,"used":true,"gnssid":0,"svid":19},{"PRN":22,"el":3,"az":55,"ss":0,"used":false,"gnssid":0,"svid":22},{"PRN":24,"el":30,"az":310,"ss":18,"used":true,"gnssid":0,"svid":24},{"PRN":28,"el":50,"az":79,"ss":24,"used":true,"gnssid":0,"svid":28},{"PRN":30,"el":19,"az":155,"ss":31,"used":true,"gnssid":0,"svid":30},{"PRN":46,"el":40,"az":206,"ss":0,"used":false,"gnssid":1,"svid":133},{"PRN":51,"el":43,"az":173,"ss":0,"used":false,"gnssid":1,"svid":138},{"PRN":68,"el":1,"az":305,"ss":0,"used":false,"gnssid":6,"svid":4},{"PRN":69,"el":2,"az":351,"ss":0,"used":false,"gnssid":6,"svid":5},{"PRN":75,"el":5,"az":132,"ss":12,"used":true,"gnssid":6,"svid":11},{"PRN":76,"el":53,"az":119,"ss":0,"used":false,"gnssid":6,"svid":12},{"PRN":77,"el":63,"az":339,"ss":0,"used":false,"gnssid":6,"svid":13},{"PRN":78,"el":12,"az":319,"ss":0,"used":false,"gnssid":6,"svid":14},{"PRN":86,"el":49,"az":33,"ss":27,"used":true,"gnssid":6,"svid":22},{"PRN":87,"el":64,"az":207,"ss":39,"used":true,"gnssid":6,"svid":23},{"PRN":88,"el":17,"az":210,"ss":0,"used":false,"gnssid":6,"svid":24}]}{"class":"TPV","device":"/dev/ttyUSB0","mode":3,"time":"2020-02-27T00:30:20.000Z","leapseconds":18,"ept":0.005,"lat":40.599271500,"lon":-111.887282000,"alt":1357.600,"epx":8.710,"epy":10.771,"epv":28.060,"speed":0.014,"climb":0.300,"eps":16.87,"epc":37.66,"eph":17.670,"sep":29.070}{"class":"GST","device":"/dev/ttyUSB0","time":"2020-02-27T01:20:40.000Z","rms":5424.000,"lat":4.300,"lon":6.200,"alt":9.600}{"class":"TPV","device":"/dev/ttyUSB0","mode":3,"time":"2020-02-27T00:30:20.000Z","leapseconds":18,"ept":0.005,"lat":40.599271500,"lon":-111.887282000,"alt":1357.600,"epx":6.200,"epy":4.300,"epv":9.600,"speed":0.014,"climb":0.300,"eps":16.87,"epc":37.66,"eph":17.670,"sep":29.070}{"class":"SKY","device":"/dev/ttyUSB0","xdop":0.58,"ydop":0.72,"vdop":1.22,"tdop":0.84,"hdop":0.93,"gdop":1.74,"pdop":1.53,"satellites":[{"PRN":1,"el":12,"az":37,"ss":15,"used":false,"gnssid":0,"svid":1},{"PRN":2,"el":11,"az":193,"ss":13,"used":false,"gnssid":0,"svid":2},{"PRN":3,"el":3,"az":77,"ss":0,"used":false,"gnssid":0,"svid":3},{"PRN":6,"el":35,"az":169,"ss":22,"used":true,"gnssid":0,"svid":6},{"PRN":12,"el":5,"az":289,"ss":16,"used":false,"gnssid":0,"svid":12},{"PRN":13,"el":17,"az":224,"ss":19,"used":true,"gnssid":0,"svid":13},{"PRN":15,"el":12,"az":255,"ss":16,"used":true,"gnssid":0,"svid":15},{"PRN":17,"el":71,"az":31,"ss":24,"used":true,"gnssid":0,"svid":17},{"PRN":19,"el":79,"az":268,"ss":22,"used":true,"gnssid":0,"svid":19},{"PRN":22,"el":3,"az":55,"ss":0,"used":false,"gnssid":0,"svid":22},{"PRN":24,"el":30,"az":310,"ss":18,"used":true,"gnssid":0,"svid":24},{"PRN":28,"el":50,"az":79,"ss":25,"used":true,"gnssid":0,"svid":28},{"PRN":30,"el":19,"az":155,"ss":31,"used":true,"gnssid":0,"svid":30},{"PRN":46,"el":40,"az":206,"ss":0,"used":false,"gnssid":1,"svid":133},{"PRN":51,"el":43,"az":173,"ss":0,"used":false,"gnssid":1,"svid":138},{"PRN":68,"el":1,"az":305,"ss":0,"used":false,"gnssid":6,"svid":4},{"PRN":69,"el":2,"az":351,"ss":0,"used":false,"gnssid":6,"svid":5},{"PRN":75,"el":5,"az":132,"ss":12,"used":true,"gnssid":6,"svid":11},{"PRN":76,"el":53,"az":119,"ss":0,"used":false,"gnssid":6,"svid":12},{"PRN":77,"el":63,"az":339,"ss":0,"used":false,"gnssid":6,"svid":13},{"PRN":78,"el":12,"az":319,"ss":0,"used":false,"gnssid":6,"svid":14},{"PRN":86,"el":49,"az":33,"ss":27,"used":true,"gnssid":6,"svid":22},{"PRN":87,"el":64,"az":207,"ss":39,"used":true,"gnssid":6,"svid":23},{"PRN":88,"el":17,"az":210,"ss":0,"used":false,"gnssid":6,"svid":24}]}{"class":"TPV","device":"/dev/ttyUSB0","mode":3,"time":"2020-02-27T00:30:21.000Z","leapseconds":18,"ept":0.005,"lat":40.599268500,"lon":-111.887273333,"alt":1358.400,"epx":8.710,"epy":10.771,"epv":28.060,"speed":0.127,"climb":0.800,"eps":16.97,"epc":37.66,"eph":17.670,"sep":29.070}{"class":"GST","device":"/dev/ttyUSB0","time":"2020-02-27T01:20:42.000Z","rms":60.000,"lat":4.300,"lon":6.200,"alt":9.600}{"class":"TPV","device":"/dev/ttyUSB0","mode":3,"time":"2020-02-27T00:30:21.000Z","leapseconds":18,"ept":0.005,"lat":40.599268500,"lon":-111.887273333,"alt":1358.400,"epx":6.200,"epy":4.300,"epv":9.600,"speed":0.127,"climb":0.800,"eps":16.97,"epc":37.66,"eph":17.670,"sep":29.070}
Notice that the message order for a single update is SKY -> TPV -> GST -> TPV. The two TPV messages differ from each other in ep* values, e.g. epv keeps switching back and forth between 28.060 and 9.600. Previously I assume the two TPV messages also differed in altitude, since xgps showed the altitude oscillating between the two at the same time as these error messages were also fluctuating. I don't know why altitude is consistent now.
> gps_umd is a gpsd client that converts gpsd updates into ROS NavSatFix
> messages:
> http://docs.ros.org/melodic/api/sensor_msgs/html/msg/NavSatFix.html
Dunno what that means...
ROS is the Robot OS, it's a pub-sub message bus for robotics components to talk to each other. GPS is widely used in the ROS world, and unfortunately the gps_umd driver is the standard way to talk to a GPS device.
Looking at the code here:
https://github.com/ros-drivers/gps_umd/blob/master/gpsd_client/src/client.cpp
They do not really support gpsd 3.19.
The code is junk, for sure. Do you have any specific issues you can point out, and/or pointers to a good (simple) gpsd client that could be studied to produce a better ROS gpsd client?
I say "simple" because all most ROS users care about is lat, long, altitude, and possibly covariance measures for each axis, and they just want everything to work out of the box.
Since you are not really using NMEA, the you are off in the wilderness.
You are using u-blox binary which has not GSV or GLL.
Well I'm not so sure anymore, after gpsd (or the u-blox device) randomly switched into NMEA mode from binary, as described earlier.
Luke
