Re: [gpsd-dev] Fw: [gpsd-commit-watch] [SCM] GPSD branch, master, updated. dev-3.19a-435-g7fc42e4

[Gary E. Miller]

Yo Fred!

On Thu, 28 Mar 2019 16:27:03 -0700 (PDT)
Fred Wright <address@hidden> wrote:

> > u-blox5_Protocol_Specifications\(GPS.G5-X-07036\).pdf  
> 
> Ah, OK.  For the most part, the newer protocol manuals seem to be
> designed as supersets of the old, so the notion that something would
> be documented only in *older* manuals hadn't occurred to me.
> 
> It looks like dual UARTs are covered by the v5 and v6 protocol 
> documentation, but not by v7 or v8.

I think you misunderstood.  I just got lazy after finding one old
and one new document.  If you want to be exhaustive please feel free
to continue my search.

> BTW, see the note in sec 3.3.1, indicating that UART2 isn't fully
> general, anyway.

Yes, but the context was about -S.  Serial port speed applies to
both UART 1 and UART 2.

> >> I sometimes see "reserved" values in the USB port which look
> >> suspiciously like the flags and baud rate for a UART port.  I
> >> suspect that this is due to GPSD itself indiscriminately setting
> >> them.  It's technically illegal to send nonzero values for
> >> reserved fields, but what the receiver appears to do in this case
> >> is just set and echo the values, while probably completely
> >> ignoring them internally.  This is one of a few "not new" GPSD
> >> UBX-related bugs that I'll probably look at after chasing the new
> >> bug I reported earlier.  
> >
> > Crn you cite where reserved must be zero for ubx?  I can not find a
> > general statement of that.  Feel free to dig into that mess.  
> 
> The notion that you're supposed to ignore reserved fields on receipt
> and either leave them as is or set them to zero on sending is fairly
> general, and not specific to u-Blox.

Once again, you overbroaden the context. 

> But it looks like they didn't
> get around to stating that explicitly until v8, where it appears
> under "UBX Payload Definition Rules":
> 
>       r11: Sec 30.3.2
>       r15: Sec 32.3.2
>       r16: Sec 33.3.2

Fair enough.  Feel free to fix any place you find that rule broken
in ubxtool.  Just remember that what is reserved in one version is
not reserved in all versions.  Extensive checking is required.

> But how many of these cases appear in the pure factory-config state, 
> before gpsd or gpsctl or whatever has monkeyed with them (and you've 
> possibly saved the modified values)?

Tons.  But also off topic.

> > I think what u-center does is read the existing value, and mask in
> > the changes.  A PITA to do.  The new 9 series does away with that
> > mess.  
> 
> It would take a pretty major protocol change to avoid the need to do
> that.

Yup.  I'm hearing scream of anguish from certain people...

Read the u-blox 9 doc for more info.  Look into:

"6 Configuration Interface" in:

ZED-F9T_InterfaceDescription_\(18053584\)_Public_1.0.pdf 

Be prepared for a headache...

Everything becomes key value pairs in: UBX-CFG-VALGET, UBX-CFG-VALSET,
and UBX-CFG-VALDEL.

> What I did to ubxtool is essentially the bare minimum needed to
> enable doing that sort of thing manually (via copy and paste).

A start.  We both need to get beyond the bare minimum.  This will be
hard.  Users will always want it to do more.  Mind reading is on the
schedule for 2025.

> Making it convenient would need both a mechanism to read the settings
> before modifying them (as noted by the FIXME in the speed setting
> section), and also a substantial expansion of the command
> architecture to allow specifying a zillion possible fields and values.

Yup.  I could not do it all on day one.  Ideas and patches welcome.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin

pgpvatag6nhqz.pgp
Description: OpenPGP digital signature