Re: SatPulse: server-oriented alternative to gpsd for chrony

--00000000000064c72f064f68d920
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 14, 2026 at 9:55=E2=80=AFAM Miroslav Lichvar <[email protected]=
om>
wrote:

>  I'm curious to see how it compares to higher-rate PPS +
> filtering. IIRC the u-blox sawtooth correction works only with 1Hz PPS.
>

Yes. SatPulse configures things with the recommended u-blox config for
timing,
which is PPS and measurement rate and navigation rate all at 1Hz.

From the chrony point of view it would be simpler if satpulse could
> provide a PPS-based SOCK with the corrections already applied.
>

I am not sure I have understood what you have in mind. Could you explain
what the tv and offset fields of the sock_sample would be?

From my perspective, the natural way to do a PPS-based SOCK for sawtooth
corrections is:

- tv being the top of the UTC second to which the correction applies
- offset being the fractional part of the time of the pulse measured in UTC

For the sawtooth-corrected refclock SOCK that SatPulse produces at the
moment, one of the complexities is that in some cases the sawtooth
correction comes in a message before the pulse (UBX-TIM-TP) and in some
cases it comes in a message after the pulse (UBX-TIM-TOS). This is made
worse by the fact that on the CM4/5 the kernel delivers the PHC timestamp
between 0 and 0.25 seconds after the pulse actuallly occurred.

James

--00000000000064c72f064f68d920
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Tue, Apr 14, 2026 at 9:55=E2=80=AFAM M=
iroslav Lichvar &lt;<a href=3D"mailto:[email protected]">mlichvar@redhat.=
com</a>&gt; wrote:</div><div class=3D"gmail_quote gmail_quote_container"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">=C2=A0I&#39;m curious to se=
e how it compares to higher-rate PPS +<br>
filtering. IIRC the u-blox sawtooth correction works only with 1Hz PPS.<br>=
</blockquote><div><br></div><div>Yes. SatPulse configures things with the r=
ecommended u-blox config for timing,</div><div>which is PPS and measurement=
 rate and navigation rate all at 1Hz.</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
From the chrony point of view it would be simpler if satpulse could<br>
provide a PPS-based SOCK with the corrections already applied.<br></blockqu=
ote><div><br></div><div>I am not sure I have understood what you have in mi=
nd. Could you explain what the tv and offset fields=C2=A0of the=C2=A0sock_s=
ample would be?</div><div><br></div><div>From my perspective, the natural w=
ay to do a PPS-based SOCK for sawtooth corrections is:</div><div><br></div>=
<div>- tv being the top of the UTC second to which the correction applies</=
div><div>- offset being the fractional=C2=A0part of the time of the pulse m=
easured in UTC</div><div><br></div><div>For the sawtooth-corrected refclock=
 SOCK that SatPulse produces at the moment, one of the complexities is that=
 in some cases the sawtooth correction comes in a message before the pulse =
(UBX-TIM-TP) and in some cases it comes in a message after the pulse (UBX-T=
IM-TOS). This is made worse by the fact that on the CM4/5 the kernel delive=
rs the PHC timestamp between 0 and 0.25 seconds after the pulse actuallly o=
ccurred.</div><div><br></div><div>James</div><div><br></div><div><br></div>=
</div></div>

--00000000000064c72f064f68d920--

-- 
To unsubscribe email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org 
with "unsubscribe" in the subject.
For help email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org 
with "help" in the subject.
Trouble?  Email [email protected]