[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: UBLOX and NTPD
From: |
Gary E. Miller |
Subject: |
Re: UBLOX and NTPD |
Date: |
Wed, 20 Mar 2024 15:26:32 -0700 |
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
pgpzo8ixPcMih.pgp
Description: OpenPGP digital signature