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

[Fred Wright]

On Thu, 28 Mar 2019, Gary E. Miller wrote:
> On Thu, 28 Mar 2019 13:48:22 -0700 (PDT)
> Fred Wright <address@hidden> wrote:
>
> > On Thu, 28 Mar 2019, Gary E. Miller wrote:
> >
> > > Newer u-blox may have two serial ports.  So in some cases it would
> > > need to apply to the -S as well.
> >
> > I considered that possibility, but as yet there's no readily
> > available documentation covering such receivers.  In particular, if
> > any protocol documentation for the 9 series exists at all, it's not
> > published on their website.
> It is part of the 5 series.  Documented here:
>
> 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.

> It is part of the 9 series.  Documented here:
>
> ZED-F9P_IntegrationManual_\(UBX-18010802\).pdf

That's just an integration manual.  There are a variety of datasheets and 
integration manuals for a variety of parts, but the protocol is only 
documented in the protocol manuals.  So far, I haven't found one available 
for v9 (or before v5, for that matter).

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

> > 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.  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

> I have lots of samples where u-blox set "reserved" data fields.

That's different.  *They're* allowed to set them, but you're not. :-)

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)?

> 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.

What I did to ubxtool is essentially the bare minimum needed to enable 
doing that sort of thing manually (via copy and paste).  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.

Fred Wright