Maybe read a little better, try to answer questions asked, not repeat
mistakes previously pointed out, and I'll not need to use such words.
Look, I have tried to read and respond to every word, and do everything exactly as you have asked -- at first exactly following the FAQ, and then after you gave me the actual methods you want me to use, following your methods instead. And I'll keep trying. The mistake I think you keep pointing out is that I missed giving the full commandline I used on more than one occasion.
Good. Or you could just use cgps or xgps and skip a ton of steps. The
data is right there, decoded and everythong.
That is pretty much exactly the thing that you have told me not to do at least three separate times, as far as I can can interpret the following:
(1)
> Here is an example of output captured from the cgps display:
Not useful.
(2)
Do not mistake what cgps shows for what the M8 is sending.
(3)
> Here are the first few messages displayed by cgps,
Once again, useless. You are not using cgps as your client and the
way cgps interacts with gpsd is not how your client is interacting with
gpsd.
As far as feedback like this:
I use the raw log as I
have no access to your running daemon, but locally you use the simple
tools gpsd provides.
..can you please put together a FAQ section with some simple, canonical examples of commands (i.e. commands with the most useful default switches) for debugging: capturing logs, decoding logs, decoding live gpsd data, replaying logs, decoding binary format data, etc. -- and with a short explanation of when to use raw gpsd data, and what differences to expect when using data received in a client like cgps? The info you sent me so far has been very helpful. But if it had already been posted on the gpsd site, it would have saved me a lot of time, and would have saved you having to coach me in this stuff. Remember I'm coming at this with zero knowledge, and you're stating a lot of usage patterns and commands like they should already be obvious to me -- they're not. It will probably save you time in the future too when others need to report bugs if the site has all this info.
> I have no idea what switched the receiver to
> NMEA mode.
No need to chase that until you get an idea. Speculation is not
helpful, yet. Work on good experimental technique.
I did not speculate about anything. I stated I did not know. If you have not seen this happen before, and/or don't know the cause, that's fine. But it is fair for me to at least ask if you have seen this phenomenon before, because I am brand new to this and you are not.
> /usr/sbin/gpsd $GPSD_OPTIONS $OPTIONS $DEVICES
Uh, systemd does not launch cgps.
Actually that's exactly what it does.
systemd manages daemons, not client programs
The way it does this is by maintaining a socket file to see if the daemon (the client program) is up. Other that that, pretty much the only thing systemd does is launch client programs. Some client programs use some of the more advanced facilities of systemd, but cgps does not -- the only thing the Fedora cgps package does is to include the .service file so that systemd knows the name of the binary and the commandline arguments. So there is absolutely zero difference between whether I launch cgps or systemd does, assuming the commandline arguments are the same in both ways of launching cgps.
> 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:
>
> /usr/sbin/gpsd
Prove it. Try this, as root:
pstree -paul | fgrep gpsd
$ pstree -paul | fgrep gpsd
|-gpsd,22880,nobody
But, as I said before, I don't do systemd. So, useless info to
me.
So forget I mentioned systemd, if you want. If it will make you more comfortable, I can launch cgps manually in the future, with no commandline arguments -- but I guarantee there will be zero difference in behavior or logs between systemd launch and manual launch.
> I am not debating that gps_udm is good, I already said it's junk.
Yup. As you said, you already said that. No need to repeat yourself.
> However it's the only game in town in ROS right now.
Not my problem. I'd be happy to work with a maintainer of it, but no
such thing exists. So, not my problem.
I more or less offered to write a new ROS gpsd client from scratch in my last message, so I would be that potential maintainer.
> Can you please point me to some client code you
> actually like, so I can take a look?
cgps, xgps, gpspipe, gpscat, gpxlogger, etc. All there in gpsd.
Of course I can study those. But you're also not always reading my questions -- I didn't ask for a list of which clients were included in the gpsd repo. I asked you what code you actually like, since you have strong opinions about what a good gpsd client should look like (or at least what a bad gpsd client looks like). So among the clients available in the gpsd repo, is there one in particular that has good quality code, and uses the gpsd API in an optimal way? If they're all of equal quality, I'll just pick one.
Ah, you have mentioned several "problems". Some, like "altitude" seem
to be coming and going, and are exagerated by the old and obviously
broken gps_udm client. The others, like epX changing, and slight jitter
in lat/lon, are normal.
So, how about, in the interests of brevity, you pick one and
focus on that one, instead of any of my word choices that you are
misunderstanding?
> I will try capturing a raw log that shows the alternating
> altitude.
I guess you did not read my admonishments that "altitude" is an
undefined and useless term. Please note I repeat myself only when
you fail to get it the first time.
In the future, for brevity, use altMSL or altHAE. Use them precisely,
or don't bother. When you continue to think "altitude" you are setting
yourself up to fail.
[...]
Just keep in mind that "altitude" is undefined and not to be ever
mentioned again.
Let's survey the clients you recommended to me (other than gpscat, which is irrelevant) to see how they represent altMSL or altHAE:
`cgps`: "Altitude"
`xgps`: "Altitude"
`gpspipe -w`: "alt"
`gpxlogger -D 3`: "ALTITUDE: altitude: [...]"
Therefore I don't think it's fair for you to come down hard on my use of the word "altitude" when gpsd clients all use the word "altitude" exclusively, rather than altMSL or altHAE. The standard clients don't even specify which altitude number they are citing, they just call it "altitude". If you want this word to never be mentioned again, you need to fix all those clients.
So for your future reference, if I ever use the word "altitude", please interpret it as "the number shown in the 'Altitude' display of the cgps client". I don't even know which of the two options the client is displaying, but I presume you know. If you ask me to give you specific altMSL or altHAE numbers, I will look those up using the commandline patterns you have given me.
Another thing to do, is to look at that lightly processed raw data
this way:
ubxtool -v 2
That will show NMEA and lightly decoded u-blox binary in real time.
Thanks. This should also be in the FAQ under debugging instructions, along with any similar commands for other GPS chipsets.
The output I get from `ubxtool -v 2 > /tmp/ubx.log` is attached.
> Hopefully the problem will show up in the raw log, and not
> just in the behavior of clients like cgps and xgps.
I don't care where the issue may be, and neither should you.
I'm not saying I hope to see the problem in a specific place. I'm saying I hope I can find evidence to reject any of the currently possible hypotheses, such as that the M8 hardware is buggy or quirky, or that cgps' binary u-blox driver may be buggy or doesn't understand the M8N's hardware's quirks, or that clients are interpreting cgps' update messages in a way that causes the clients to perceive the behavior I have described even though the problem is not in cgps itself. The only way to collect this evidence is to look at logs, as you have repeatedly pointed out.
ubx.log