How to compensate for systematic offset?

[jclark]

I did not have any issue setting up with TimeHAT V6 + UBLOX. I did build satpulse from source as the last release deb did not support some of the diagnostic commands in the (excellent) documentation.

I chose to stay with the unpatched igc driver after confirming that I could apply the patch. It seemed unecessary as linuxptp (latest) seems to deal with the dual-edge just fine in ts2phc. I rolled it back. Maybe someday updates will go upstream that improve on the SDP event capture options.

I can confirm that 1PPS output polarity from the SDP pin aligns the falling edge (start of low phase) to the start of second. I can also confirm I ran the same wild goose chase trying to make this not so and gave up.

One thing I have noted and that I would like to understand how to compensate is that when the PHC is synchronized from GNSS by satpulse, the start of second "leads" a reference PPS I have from another receiver (meinberg microSync) by approximately 400ns.

When the PHC is synchronized by ptp4l with 802.1as from that GM (the microSync) it aligns the SDP 1PPS output to within 50ns.

I did not see a 'twiddle' knob to apply a correction in satpulse.toml. I assume this is some systematic offset in the system that I would like to be able to dial-out as I may use either sync mechanism depending on use-case.

Am I missing a small detail / feature that I can control to compensate systematic offset?

Thanks & Regards

Originally posted by @dcattley in #149

[jclark]

u-blox receivers provide a couple of knobs that you can use to tweak the alignment of the PPS output.

• antenna cable delay
• user-configurable delay

Currently satpulse exposes only antenna cable delay. This is done with antennaCableDelay option in the GPS section satpulse.toml. Now normally this is positive and moves the pulse forward to compensate for the delay from the signal passing through the cable. The default is 50ns on u-blox receivers. But in fact it is allowed to be negative. So I think you can (ab)use this and specify antennaCableDelay = -350 to get what you want.

ptp4l also has some knobs you can twiddle:

• ingressLatency
• egressLatency
• delayAsymmetry

I am a bit puzzled as to why this should happen. 400ns is a lot in this context. Is the difference consistent? Are there switches between the GM and TimeHAT?

[jclark]

This raises the question of whether satpulse should offer one or more knobs here. I think a systematic error of this kind will be quite common. I see two possibilities (not mutually exclusive).

First is an option that says to add this many nanoseconds to the GNSS timestamps before using them to sync the PHC. There are potentially many options that could be provided to tune how the PHC is adjusted. For example, the proportional/integral constants for the PI controller. There aren't any of these knobs at the moment, because the code needs a lot of improvement in this area, and I am not clear what are the right knobs. But this one is clear and simple, and won't be impacted by future improvements. But I need to think what section it goes in and what it is called. I will make a separate issue for this.

Second is to expose user-configurable delay as a separate option, since it is a much more appropriate for this use case. The problem here is that I cam trying to make the configuration model vendor-independent, and most vendors expose a single delay value. So what would I do with those GNSSs? I will make a separate issue for this also.