Re: UBLOX and NTPD

[Joseph Beissel]

> Yes, good, not great.  UBX is a richer protocol than NMEA 0183.

If you have a legacy product that has been designed to use NMEA, there is really no reason to throw it all away to move to UBX.  I agree it is a much richer protocol.  But the cost of moving legacy products to UBX is cost prohibitive ("time is money").  Now if you are developing new products then I am all in on using newer technologies like gpsd.  SInce you seem to like car analogies, there are a lot of old cars out there that people hang onto because the new ones are just out of their price range and are much more expensive to operate and maintain.

In our case we are trying to integrate a legacy product and a newer product that is a gpsd client. I am trying to integrate gpsd into the legacy product without making major changes to the legacy software.  

> It means your GPS receiver sis saying: Help, Ive fallen and I can't get up.

> Ignore at your own peril.

To be honest, our current product has been around for a while and is doing exactly what it needs to do.  But I get what you are saying.  

> I am also curious,  but without the newer logging, nothing more I can
> say.  It was situations similar to this one that lead to the newer
> logging.

Well I found out what is causing my problem.  The code makes ASSumptions about running in a test harness.  It ASSumes that when you have a sourcetype that is a "source_pty", you are running in a test harness.  In that case the ntpshm_link_activate() method bails and does not set up the thread that ultimately updates the shared memory segments.  That is too bad.  In our use case we create a pseudoterminal (by calling openpty) that our software writes everything it gets from the gps device.  This is what we start gpsd off with.  The first lines in ntpshm_link_activate() are:

if (session->sourcetype == source_pty)

return;

You weren't clear on what openpty does and kept asking why I use a symbolic link.  We call openpty to create a pseudoterminal.  Using openpty grabs one of the available pseudoterminals (/dev/tty/#)..  This could change based on what is running on the box and how they are being used.  Using openpty allows flexibility.  However to hide the fact that the  pseudoterminal can and most likely will change, we hide that behind a symbolic link that our software uses.  This isolates the user from knowing anything about the pseudoterminal.  

On Wed, Mar 20, 2024 at 5:27 PM Gary E. Miller <gem@rellim.com> wrote:

Yo Joseph!

On Wed, 20 Mar 2024 17:03:35 -0500
Joseph Beissel <joebeis64@gmail.com> wrote:

> Again only replying to questions to not be too confusing with
> indentation issues.
>
> > Nothing we can do about that.  A lot of these weird serial drivers
> > are broken.  That means gpsd init will fail.  And it did.  Which is
> > why your device  ends up in NMEA 0183 mode. 
>
> So if it ends up in NMEA 0183 mode is that a bad thing?

I think so.  YMMV.

> When I run
> gpsd directly connecting to the ublox device, things seem good.

Yes, good, not great.  UBX is a richer protocol than NMEA 0183.

> When
> I run ntpshmmon I am getting samples written to the shared memory
> segment and the time on the box gets set correctl (running "data" is
> correct to the second).

Remember what I said about first failure?  You keep looking at the
damaged roof on the convertible, the accident started way back when
the care rolled over.  Stop looking at ntshmon, you issue is much, much
earlier.

> So even if gpsd init fails, it soldiers on.

Yup, by design.

> So what does "broken" mean.

It means your GPS receiver sis saying: Help, Ive fallen and I can't get up.

Ignore at your own peril.

> gpsd seems to do "enough" to get things
> working.

Only you can say it if it good enaough for you.

> Even if the serial driver is "broken", which isn't a good
> thing I agree, it doesn't seem to hamper the functionality of gpsd or
> does it?

Sure looked like a problem to me.  YMMV.

> I attached a debuginfo file which pulls some of the output
> of the script gpsdebuginfo that I pulled down off the site when
> running gpsd in the direct scenario.

We are past that now, but it was very incomplete.  Don't bother, I've
seen enough.

> > We can't really support that usage.   Unless you setup the receiver
> > in a way that gpsd can use it, your results will be marginal.  Too
> > many variables out of our control. 
>
> I get that this is not a normal situation and that you can't support
> it.  I am not asking to have it supported. I am just curious as to
> why it would not work.

I am also curious,  but without the newer logging, nothing more I can
say.  It was situations similar to this one that lead to the newer
logging.

> What setup is done to the receiver by gpsd so it can use it?

Check out drivers/driver_ubx.c, but that is so old I don't recall
exactly.  And as you first log shows, that is not working for you
either.

> Speaking of nmea messages, when I search through the debug output
> (-D4 -D5 -D6) generated when running directly connected, I see GSV,
> GGA, GLL, GSA, RMC, VTG and GSV sentences being processed by gpsd.  I
> don't see any other messages that are being processed.  Are these the
> messsages that gpsd relies on?

gpsd can only rely on what you give it, and that is what you gave it.

> > And what driver creates a /dev/TTPS1 ??  Clearly problems there. 
>
> Typo.  Should be /dev/ttyPS1.  This is the physical device (uart) on
> our processor that has been wired to communicate with the GPS device.

Pay attention to my words, my question was "what driver".

> > gpsd knows nothing of pseudo-terminals. 
>
> Does gpsd assume anything about the device you send it?

Nope, it checks for the device that is use.  gpsd does not "assume".


> I didn't
> think it mattered.

And without the proper logging, I have no way of knowing.  But, your
first log clearly shows it broken.


> So if I create "/dev/ttyGPS0" and link it to the
> pseudo-terminal

Another of the qustions I keep asking that you do not answer.  Why to
you link?  Adding a link does almost nothing as far as gpsd cares.


> > Why bother with a link? 
>
> A link is created so the underlying pseudo terminal is hidden from the
> software.  The software can refer to the same name even if openpty
> gives different results.  Provides portability.

Nut my question was why rename it for gpsd?  gpsd does not care.

> Also nothing I see indicates to my why the ntpshm_link_1_activate
> link is not getting set to "1" which you indicated is why the shared
> memory segment is not getting set.

As I keep telling you, newer logs would tell you.

>  Maybe you can point me to a place
> in the code that could help me out.

Code from 3.17 is too old and I can't support it.  I don't have time to
keep fixing the same really old code again and again.

Even better when you ansert the questions I asked.

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