[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ✘ Add NEO-M9N NMEA logfile.
|
From: |
Fred Wright |
|
Subject: |
Re: ✘ Add NEO-M9N NMEA logfile. |
|
Date: |
Wed, 29 Jul 2020 17:32:48 -0700 (PDT) |
|
User-agent: |
Alpine 2.23 (OSX 453 2020-06-18) |
On Thu, 23 Jul 2020, Gary E. Miller wrote:
On Thu, 23 Jul 2020 14:40:29 -0700 (PDT)
Fred Wright <fw@fwright.net> wrote:
I was figuring on fixing the GSV problem before fixing the
mode-switching problem, since the latter makes it convenient to
test the former. But I also added the logfile as a hedge, and of
course one can always put the receiver in NMEA mode and launch gpsd
with -b to get NMEA behavior.
I've now switched my position on the order of those fixes, since:
1) The GSV mishandling is a long-standing problem, albeit one that's
becoming more significant with advances in receiver technology and
satellite deployments.
I'll ask again: what mishandling? On what u-blox model? Works for me.
I already answered this, though it shows as "Message not available" in the
archive. Here's the main excerpt:
-----------------------------------------------------------------------------
On Tue, 14 Jul 2020, Fred Wright wrote:
It's the known problem with multiple GSV groups. At one point, a special
kludge was added for the specific case of GPGSV/GLGSV (and only if they
appear in that order), but it doesn't work for the more general case. The
result is that each update in the GP/GL/GA/GB case produces three successive
SKY reports, with increasing sets of satellites, restarting on each update
cycle. I'm pretty sure the reason it's only three instead of four is due to
the GP/GL coagulation.
The effect is obvious with any of the clients that display constellation
info. To see it with the logfile:
$ GPSD_HOME=. ./gpsfake -S test/daemon/ublox-neo-m9n-nmea.log
Then just run one of the relevant clients (though in trying it for this email
I stubled across a previously unknown crash in xgps). The display is very
spastic, as many of the satellites keep coming and going on every update.
-----------------------------------------------------------------------------
BTW, gpsmon in this case is even more spastic than the other programs,
since it keeps completely switching its display back and forth between
NMEA and u-blox.
2) The mode-switching problems were introduced since the 3.20
release, making them regressions which should be considered release
blockers. I'd initially thought that they were related to the u-blox
9, but actually it's the gpsd version not the u-blox version that
matters.
News to me. Care to elaborate?
3) If the u-blox mode switching worked properly (or at least as well
as it did in 3.20), the GSV problem would be much less important in
the u-blox case.
Care to elaborate?
The short answer is that the presence of NMEA sentences poisons the
handling of u-blox data in many cases. This only became a problem when
"binary" stopped disabling NMEA.
In theory, gpsd could do a better job of "blending" NMEA and binary, but
that's a significant undertaking.
The automatic reconfigure in gpsd was broken by commit e2e0f8d5.
That change isn't unreasonable per se, since gpsd was formerly doing
a complete reconfigure upon receipt of any CFG-PRT message, even one
that didn't apply to its own port (e.g., a response to a CFG-PRT from
ubxtool).
Yup, the CFG-PRT was broken. And that code was redundant:
- /* Need to reinitialize since port changed */
- if (session->mode == O_OPTIMIZE) {
- ubx_mode(session, MODE_BINARY);
- } else {
- ubx_mode(session, MODE_NMEA);
- }
But it seems that the intended reconfigure code never
worked properly
Exact same code is called elsewhere. So not the code that is called,
but when it is called.
Exactly. Though it turns out that this is the right place (but not the
right conditions) to call it.
(at least in some cases), and the only reason this
went unnoticed is that the extra reconfigure in response to CFG-PRT
gave it a second bite of the apple.
What exactly is not happending for you?
The manual reconfigure via "gpsctl -b" was broken by commit 35b1cfYea.
A lot longer than that. There was a long thread about it here early
this year. That code that 35b1cfYea changed fixed some really, really,
old and bad bugs.
Care to elaborate?
I'd puzzled over how a change that only set more bits in the
protocol mask could result in less UBX data, until I realized that
that wasn't what was really happening at all. The problem is that
the receiver now emits both NMEA and UBX data, which isn't
necessarily a bad thing (though it's probably undesirable in common
cases),
Which is solved when the receiver is configured for NMEA or binary.
Which gpsctl -b/-n does. But should happen on init, which e2e0f8d5
was doubly doing for most people. Seems not at all for you.
No, with the recent changes, "binary" means NMEA+binary, which is
problematic.
but the presence of the mishandled GSV data causes constant
clobbering of the correct data from SVINFO. This is aggravated by
the fact that SVINFO is only appearing every 10 seconds, while GSV
data is appearing every second.
GSV every second would be a bug. The receiver only updates GSV every 10
seconds or so. SVINFO is updated at the same rate the receiver updates
its internal data. So 10 seconds is about right.
1Hz is both the factory-default update rate for GSV, and the rate
configured by gpsd when it's configuring for NMEA. If you're seeing
something different, it probably means that you've reconfigured your
receiver(s) and avoided having gpsd change the settings. But testing with
reconfigured receivers isn't representative of what most users will see.
I'm still not understanding what you do not like about GSV??
With regard to fixes:
There seem to be multiple issues with the intended reconfigure code
in gpsd, including some mishandling of the port ID.
Yup, forever. I do not think a perfect solution is possible until
u-blox 9.
It just means that it has to poll CFG-PRT to determine the ID before doing
anything that cares about it. The code that I'm currently testing (though
I had to put that aside for the library stuff) does exactly that.
I've been aware
of that for a while, but since it seems to have been at least
partially motivated by some confusion over how to handle the GR-601W,
I was reluctant to touch that code without an actual GR-601W to test
with.
I can get you one, if that is your only hold-up. But the same issue
happens on 7 and 8 series.
I currently have a way to connect any MikroElektronika GPS/GNSS "Click"
module to an FTDI serial cable, which is functionally similar to the
GR-601W. I have Click modules with LEA-6S, NEO-M8N, and NEO-M9N. The
LEA-6S case is closest to the GR-601W. The biggest difference is that the
USB/UART adapter here is FTDI rather than Prolific. In most respects,
that's a plus (Google "Prolific vs FTDI" to see), but it does mean that
it's not fully crapwise-compatible with the GR-601W.
I'd planned to verify that I hadn't broken autobaud, even though none of
the changes I've made should interact with autobaud. But it appears that
autobaud was already broken, at least as far back as 3.19. Fortunately,
the new option to set the speed makes that less problematic.
But since it's now causing real trouble, it makes sense to fix
it, and I've cobbled together what should be a good enough
approximation of a GR-601W for this test purpose.
I'm still not understanding what you do not like about GSV? Or what
you define as "real trouble".
See above.
[...]
Thus, the short-term fix would be to put back the
two-way mode-switched mask as before, except for including the RTCM3
bit along with UBX.
Which reverts all the problems that got fixed.
Which problems?
One could still get "mixed" mode via ubxtool, if
desired.
Nope. The old code would readily brick the u-blox. Can't have that.
In which case? The most dangerous thing it currently does is to start
probing before it knows it has the right baud rate, potentially sending
complete garbage to the receiver. But that's a completely separate issue.
I've certainly never seen a case of a receiver getting literally
"bricked" (i.e. in a state where even a power cycle wouldn't recover). I
have occasionally seen a state requiring a reset, but I can't rule out the
possibility that it related to sending to it at the wrong baud rate.
Including NMEA data in "binary" mode at the very least greatly increases
the probability of data overrun at lower baud rates. And it causes other
problems, as noted above. If it's to have NMEA vs. "binary" at all, this
means it either has to:
1) Adjust the protocol mask.
or
2) Adjust the individual message/sentence rates.
Clearly #2 could cause much more interference with user configuration than
#1, so it's less desirable.
Fred Wright