Re: [chrony-users] SatPulse: server-oriented alternative to gpsd for chrony

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Thu, Apr 23, 2026 at 02:46:22PM +0700, James Clark wrote:
> Immediately after reading each PHC timestamp, it uses
> PTP_SYS_OFFSET_EXTENDED/PRECISE ioctl to get a cross-sample. When in
> tracking mode, it generates a chrony sample from the cross-sample, assuming
> the PHC value in the cross-sample provides the true time.

Ok, that explains what I was seeing.

> It is configured just by putting `sync=false` in the `[phc]` section;
> there's also a new `[sample.phc]` that can configure various parameters of
> the sample generation algorithm. This is on the phc-sample branch, if you
> want to try it.

I tried it with the default sample.phc configuration. It produced only
few SOCK samples. Is the validation too strict? In the log I have seen few
of these:
"could not derive offset from PHC" err="phcsample: wallClock median residual 50.465527ms exceeds limit 50ms

but mostly it was silent and produced no samples. The offset of the
PHC and system clock to GPS was less than 100 nanoseconds, not clear
where that 50ms is coming from. When I set sync back to true, it
starts working again (with no steps).

> I have put in code to detect and handle PHC discontinuities, so I think it
> should also work with chrony disciplining the PHC, but my feeling is that
> this approach is not ideal for that, and another refclock which works along
> the lines you suggested here would work better:

Yes, I suspect the issue will just move to the other side, satpulsed
confused by chronyd's adjustments to the PHC.

> > > I think tv should be the timestamp from the extts event (if using a
> > > PHC) or pps assert/clear provided by the kernel (rounded to
> > > microseconds). Offset should be the difference to the top of the
> > > second indicated by the serial message and the sawtooth correction.
> 
> One question here: for the purpose of determining the difference, should
> the PHC be treated as being in TAI or UTC?

Either is fine. chrony refclock directive has the "tai" option.
Ideally, it would be configurable.

> P.S. it seems satpulsed doesn't currently work with /dev/gnss devices
> > (e.g. provided by some Intel NIC drivers). I'm getting this error:
> >
> > ioctl(TCGETS) /dev/gnss0: inappropriate ioctl for device
> >
> > The serial-specific ioctls need to be disabled in this case or their
> > errors ignored.
> >
> 
> Thanks. I have put in a fix for this on master (and phc-sample), but it's a
> bit more complicated than just not doing the serial-specific ioctls: I have
> to switch over to using poll for timeouts rather the the VMIN/VTIME serial
> timeouts. I think Go's netpoller will work with /dev/gnss*, but I am not
> 100% sure. So it would be great if you could try it out.

It's receiving messages now, but there is some issue with
configuration (or transmitting messages in general?):

level=DEBUG msg="inter-packet timeout detected during GPS configuration"
level=DEBUG msg="inter-packet timeout detected during GPS configuration"
level=DEBUG msg="first valid packet received" tag=NMEA
level=DEBUG msg="first input received, cancelling silence timer"
level=DEBUG msg="sent probe packets" probeNum=1
level=DEBUG msg="inter-packet timeout detected during GPS configuration"
level=DEBUG msg="probe succeeded"
level=DEBUG msg="sent configuration message" index=0 len=8
level=DEBUG msg="inter-packet timeout detected during GPS configuration"
level=DEBUG msg="sent configuration message" index=1 len=40
level=DEBUG msg="inter-packet timeout detected during GPS configuration"
level=DEBUG msg="sent configuration message" index=2 len=151
level=DEBUG msg="inter-packet timeout detected during GPS configuration"
level=WARN msg="GPS configuration failed" err="GPS receiver sent NACK for request CFG-VALSET"
level=INFO msg="GPS configuration" cfg="map[mode:map[static:false] signalsEnabled:map[] timeGNSS:GPS]"
level=INFO msg="GPS receiver" vendor=u-blox hardware=ZED-F9T firmware="TIM 2.20 PROTVER 29.20" gnss=GPS,GAL,BDS,GLO,QZSS,NAVIC,SBAS
level=INFO msg="message types received during configuration" protocol=NMEA msgIDs="[GNGSA GPGSV GNVTG GLGSV GAGSV GBGSV GQGSV GNGLL GNZDA GNRMC GNGGA]"
level=INFO msg="message types received during configuration" protocol=UBX msgIDs="[ACK-ACK CFG-VALGET ACK-NAK MON-VER CFG-PRT]"

When I set config to false, it seems to work fine.

Thanks,

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.