[no subject]

- 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:mlichvar@xxxxxxxxxx";>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">