Thank you Gary for taking time to answer.
My ntpshm works on, I see the timestamps and ntp synch is working linke a charm (after a bunch of calibration runs).
the problem in fact is that in my program, when I read the pps timestamps I get:
with socket:
PPS clk: 1562247898.884325242 -> a realistic pps timestamp (UTC epoch in seconds, with subsecond information).
and with shared memory:
PPS clk: 0.1077805056 -> not comparable with the actual timestamp.
in fact with socket export i can know how much time has passed since the PPS hit, but with shared memory export i cannot compare my local UTC time with pps timestamp, since seconds part is missing. So it makes me conclude that the same information decoded under two different export methods is in fact different. The only explanation I have is that PPS is not exported in shared memory export. Is it really that?
Thank you again!
Guido
Il giorno gio 4 lug 2019 alle ore 17:12 Gary E. Miller <
address@hidden> ha scritto:
Yo Guido!
On Thu, 4 Jul 2019 16:03:32 +0200
Guido Gavilanes <address@hidden> wrote:
> I have been working with gpsd with the socket export for some time.
> Now I am required to bring timign information from our receivers, so
> I configured a serial-based GNSS receiver + PPS wiring to my imx6
> board. I configured pps input through pps-gpio linux module. both
> serial and PPS sources are configured in my gpsd DEVICES and ntp is
> currently taking information from SHM exports generated by gpsd for
> synchronization.
Sounds a lot like the setup described in the time service howto.
> The program I am working on (using socket export) has been accessing
> positioning information. Since the host is doing other stuff, timings
> between JSON-socket and my application are variable, due to the
> networking stack activity, so positioning information is not received
> always with the same period of gps samples; instead 2 or 3 samples
> (samples are produced at 10Hz) are received together, and this messes
> up other applications.
Yup. Do do not do that.
> So I decided to use shared-memory export, since sample transfer time
> between receiver and my application are far much stable. In fact it
> works for positioning information and samples can be read regularly.
Yup. That is why that is the preferred method for time keeping.
> Here comes the problem, when reading the PPS objects, the member
> "clock" timestamp is set to the time when pps was asserted (according
> to documentation); but when I read it with the socket export I can
> read it with seconds and nanosecond resolution; instead with shared
> memory export, I always read invalid values ( I mean values with the
> tv_sec=0 or less tan zero) by using exactly the same program
> (attached).
Did you see if ntpshmmon works for you? It reads the SHM too.
> with Socket Export I get (clocks compatible with fix times):
>
> PPS clk: 1562247898.884325242
> PPS rea: 1562247898.799999952
> --- GNSS - last sample elapsed time: -0.000002 1562247898800
>
> PPS clk: 1562247898.884325242
> PPS rea: 1562247898.799999952
> --- GNSS - last sample elapsed time: -0.000002 1562247898800
>
> instead with Shared Memory I got (clocks not compatible with fix
> times):
>
> PPS clk: 0.1077805056
> PPS rea: 0.1090546784
> --- GNSS - last sample elapsed time: -0.000003 1562247940000
>
> PPS clk: 0.1077805056
> PPS rea: 0.1090546784
> --- GNSS - last sample elapsed time: -0.000003 1562247940000
Odd, I would expect the SHM to be more accurate tham the socket.
But both are pretty good. With a bit of tuning you should earn
another zero.
> Does this mean that shared memory export does not export PPS
> information?
You just showed it does. And that is how gpsd talks to ntpd.
> Am I forgetting something that avoids to access PPS
> information?
Forgetting means you already knew it. I cant say about that.
> I need to access PPS timings since it allows me to keep
> my application synchronized directly with the receiver and I can tell
> the user how much time has passed since the pps was triggered.
And you showed above two ways to get it. So the problem is?
Also, check out how ntpshmmon works for you, and what it shows.
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
--