[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ✘ Add NEO-M9N NMEA logfile.
Gary E. Miller
Re: ✘ Add NEO-M9N NMEA logfile.
Wed, 29 Jul 2020 18:17:14 -0700
On Wed, 29 Jul 2020 17:32:48 -0700 (PDT)
Fred Wright <email@example.com> wrote:
> > 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:
If the archive did not get it, then I likely did not either.
> > 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.
Oh, as you say, known problem. If you have an idea to fix it then
have at it.
> > 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
Everything gpsmon does is spastic. I never use it. Beyond repair.
> 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.
So turn off NMEA. The number of complaints about what gpsd
turned on and off in u-blox keeps rising. No agreement on
what to do, so let every use suit himself.
> In theory, gpsd could do a better job of "blending" NMEA and binary,
> but that's a significant undertaking.
Yes, and for no win over just going all binary. Or all NMEA.
> > 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.
Suggestions welcome. The current code works for some, but not all.
> > 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?
A long thread, s/b easy to find.
> > 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
If gpsctl -b is broken for you, please proved a log from gpsd of what
it is doing. Works for me.
> > 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.
I am not.
> But testing
> with reconfigured receivers isn't representative of what most users
> will see.
Lost me. Way too many independent threads going around here...
> > 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.
Sadly polling of u-blox is problematic. u-blox drops requests
far too often for polling to be reliable. I'd be happy if you got it
to work, but not this cycle. Better to never need CFG-PRT. It is
never needed on 9-series, and a PITA on earlier firmware.
> >> 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.
So now you don't need one? Let me know your final answer.
> 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
Odd, autobaud working for me. Just way slow.
> >> 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?
As discussed on this list.
> > 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.
As discussed on this list and IRC. When the protocol mask conflicts
with the enabled messages, you get nothing. N ot gonna go nack to that
> 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
Most u-blox have no way to save config. Those that do can be bricked.
> Including NMEA data in "binary" mode at the very least greatly
> increases the probability of data overrun at lower baud rates.
Yup, no one disagrees with that. How to ensure that is the issue.
> 1) Adjust the protocol mask.
Nope. Not gonna do that. Bricking is not an option.
> 2) Adjust the individual message/sentence rates.
Yup. Which is what gpsd does now, with a few holes.
> Clearly #2 could cause much more interference with user configuration
> than #1, so it's less desirable.
Blocking all NMEA or all binary with out user intervention is more
desireable? Nope. That is the bug that got fixed.
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
firstname.lastname@example.org Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin
Description: OpenPGP digital signature