Re: gpsd and ublox

[Gary E. Miller]

Yo Joseph M. - US!

BTW, in the future, please use a quoting that separates my
text from yours.

On Tue, 5 Mar 2024 20:42:15 +0000
"Beissel, Joseph M. - US" <joseph.beissel@caci.com> wrote:

> Thank you for the initial reply.  See embedded.  I added more details
> and asked a few more questions.  Thank you for your patience.

We live for gpsd, and have to spread the good word!

> On Fri, 1 Mar 2024 21:18:59 +0000
> "Beissel, Joseph M. - US" <joseph.beissel@caci.com> wrote:
> 
> > I was wondering if there is any documentation that you can point me
> > to on the interactions (if any) that occur between gpsd and a ublox
> > device when gpsd starts.  
> 
> Sorry, no doc.  And it depends a lot on your u-blox model and your
> gpsd configuration.  You can look in the doc, use ubxtool to watch it,
> or ask here (after providing model number, configuration, etc.)

Sorry, doc wass a typo, I meant srouce.

> We are using a Ublox MAX-M8W-0 device on our board.  Does the doc
> contain specifics based on the type of device?

Yes:

https://content.u-blox.com/sites/default/files/products/documents/u-blox8-M8_ReceiverDescrProtSpec_UBX-13003221.pdf

> Users fall into 2 types.  The majority want gpsd to "Just Work"tm, and
> for them auto-configuration is fine.  A small minority, will use
> "--passive" mode, and use ubxtool (or similar) to program their device
> just the way they want it.
> 
> Which user type are you?

I'm all of the above.

> We do not use gpsd and are looking into moving to it.  We currently
> use custom interface code that configures the device and then process
> messages that it sends.  We configure it to send out several UBX
> messages as well as NMEA sentences.   Since we are currently locked
> into Warrior which has GPSD 3.17 (I know, sucks to be me) we have to
> work things keeping that in mind.

I appreciate you are contrained, and only your company can make decisions
for your products.

> With that above in mind I guess we would be part of the small
> minority that would need to configure the device and then use
> "--passive" mode if I understand correctly.  We need to configure the
> device to send UBX messages as well as NMEA strings  since we process
> both of them.

Not a good idea, but not uncommon either.

> If we need to get a few of the UBX message (an example
> is NAV_TIMEGPS), does that require usage of the "--passive" mode and
> either ubxtool (or similar) to program the device?

Nothing requires passive mode.  You can always reconfigure the device
after gpsd is finished reconfigureing.

Any way you can reconfigure the device is fair game.  use the device-hook,
ubxtool, cat a binary file to the device, gpsctl, etc.

Or, if you have configuration storage on your device.  Configure it
offline, and use --passive to force it to stay that way.

IMHO, TIME_GPS is useless, bau can't do any harm, other than overloading
the serial bus.

> A follow-on question about the above, would or could gpsd be
> configured to pass along UBX messages to the user if the device is
> configured to send them out?

That is what ubxtool, gpsctl, device-hook, cat, can do for you.

> Or do we need to stay with our custom
> interface code.

That I can not say.

> > and start gpsd
> > (since we are not running it by default as of yet).  I can then run
> > gpsmon and see things getting reported (really nice tool).  I am
> > just looking for documentation that indicates what happens when gpsd
> > starts.  
> 
> Uh, you reallize thet gpsmon is old, obsolete, unmaintened, and not
> evern a try gpsd client?  Try ubxtool, cgps, xgps, etc.
> 
> Did not realize that it is old, obsolete, etc.  Was this true in 3.17
> or in later versions?  Just curious.

Yes.  But much worse now.

> > We are running an image on our custom hardware that is built using
> > Yocto Warrior that came packaged with version 3.17.  
> 
> Uh, you realize that is 6 years old?  We can't support that.
> 
> Obviously.  I am hoping that questions can still be answered on the
> later versions.

Other than the lack of (on host) ubxtool, and a ton of bug fixes, most
applies, but there are old dark corners to fall into.

> > I know there are
> > newer gpsd versions with later releases of Yocto but we are unable
> > to move away from Warrior at this time.  
> 
> Sucks to be you.
> 
> Yup, but the reality is products need to be supported in the field
> beyond the dates of the software used to coble together the build
> products.  In a perfect this would not be a problem, but ...

Yeah, but you refuse to use the tools to do so.

> > I see in later releases and read documentation about ubxtool that
> > can be used to send configuration commands to a ublox device.  Is
> > there something similiar to that in 3.17?  I am not sure I have seen
> > anything like that.  
> 
> Nope, you are out of luck.
> 
> Yup.  Have a custom tool that is currently used to program device.

So what is the problem?

> Uh, no.  Don't do that.  This is a FOSS project and we do not do:

And yet, you do it again.  Please stop that:

> This electronic message contains information from CACI International
> Inc or subsidiary companies, which may be company sensitive,
> proprietary, privileged or otherwise protected from disclosure. The
> information is intended to be used solely by the recipient(s) named
> above. If you are not an intended recipient, be aware that any
> review, disclosure, copying, distribution or use of this transmission
> or its contents is prohibited. If you have received this transmission
> in error, please notify the sender immediately.

You send this to an archived public email list.  Deal with it.

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

pgpSJYf_9OWle.pgp
Description: OpenPGP digital signature