[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ✘ Add NEO-M9N NMEA logfile.
From: |
Gary E. Miller |
Subject: |
Re: ✘ Add NEO-M9N NMEA logfile. |
Date: |
Wed, 29 Jul 2020 18:17:14 -0700 |
Yo Fred!
On Wed, 29 Jul 2020 17:32:48 -0700 (PDT)
Fred Wright <fw@fwright.net> 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
> programs,
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
> problematic.
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.
Yes.
> 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
> problematic.
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
mess.
> 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).
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.
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin
pgp2XqGkBW7_O.pgp
Description: OpenPGP digital signature