Patience is not really what you want from us, you want answers, and I'm
trying to give those to you. Many of us are happy to take the time
to help people get it right. GNSS do not really work the way you think
they do, so try to be flexible.
As I have said in previous messages, I am grateful that you are taking the time to look into this issue. However I do want to point out that emotionally-charged phrases like "useless" and "pay attention" and "I'll ask again" do not present a welcoming environment to a newcomer. I have been on enough open source mailing lists for the last 30 years to know that communities that don't fall over themselves to be diplomatic and generous towards newcomers rarely last long, and eventually implode. I have thick skin, but you will alienate some people with language choices like this, and you have used phrases like this in every message so far.
With that out of the way, I'll try to condense my responses as each successive response back and forth is getting longer.
> OK, thanks for explaining. I just tested this:
I'm unclear what you tested and how?
> 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)
Where did you get that? cgps, xgps, ubxtool, gps_udm?
I obtained height and hMSL using the only method you showed me so far to determine the geoid -- exactly as you suggested it. `gpspipe -R -n 100 > raw.log` followed by `ubxtool -f raw.log -v 2`. I'm trying to follow your instructions exactly.
Yes, I did a hard reset of the receiver because after the receiver started outputting NMEA in `gpspipe` output, I wanted to go back to defaults, particularly after your emphasis on the binary protocol being the gold standard. I have no idea what switched the receiver to NMEA mode. The only tools I have even used with gpsd during the course of this conversation thread are `gpspipe`, `gpscat`, `cgps` and `xgps` -- and I have used all of them with default values. The only commandline switch I may have supplied (e.g. to `gpscat`) was the device, e.g. `-F /dev/ttyUSB0`. I haven't configured anything or overridden any defaults for any of those programs. So what do you think switched the receiver from binary to NMEA mode?
systemd sucks for sure, but all it does is launch the cgps binary, nothing more, nothing less. I sent you the .service file previously, but this is the launch command:
/usr/sbin/gpsd $GPSD_OPTIONS $OPTIONS $DEVICES
And since none of the three above environment variables is either set or is non-empty in the two gpsd config files, this commandline reduces to simply:
Nothing more, nothing less. The only other part of this that affects the launch is the file /usr/lib/udev/rules.d/99-gpsd.rules , which causes systemd to run the above bare `gpsd` command if a CP201x device is plugged in:
ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SYMLINK+="gps%n", TAG+="systemd", ENV{SYSTEMD_WANTS}="gpsdctl@%k.service"
So any weirdness seen here has nothing to do with systemd. cgps is launched with no commandline switches.
> 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.
I looked at the gps_udm code. Last update 7 years ago! Any robot using
that will soon have 3rd law violations and be sent to the scrap heap.
You use that old broken stuff, that is your problem, not gpsd's.
> > 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 have many specific issues with that code, but I have more than enough
issues with the gpsd to care. I see a 4 year old MR waiting on the
gps_udm code. Not gonna waste my time on that.
I am not debating that gps_udm is good, I already said it's junk. However it's the only game in town in ROS right now. I'm asking for a concrete pointer to some actually-good gpsd client code, so that I can strip out gps_udm and replace it with something more modern, clean, and correct. Can you please point me to some client code you actually like, so I can take a look?
It sounds like you still don't have an idea of what is causing the problem. I will try capturing a raw log that shows the alternating altitude. Hopefully the problem will show up in the raw log, and not just in the behavior of clients like cgps and xgps.
Thanks,
Luke