The OpenCPI team recently resolved Issue #3566 (When using a PPS input the time service provides time that is neither monotonic or correctly phase aligned (#3566) · Issues · OpenCPI / OpenCPI · GitLab) pertaining to the time server providing a monotonic and correctly phased aligned time when using a PPS input. When a PPS signal is detected, the time server worker initiates a process to synchronize time to PPS. During the synchronization process, time is unstable with the fractional element jumping forwards and backwards while adjusting to acquire synchronization. A ‘pps_locked’ signal has been added to the worker to indicate when synchronization has been accomplished. To complete modification of the time server device worker, we are seeking concurrence regarding behavior of the presented time during synchronization. Here are a couple possible options that have arisen but were open to discussion and other suggestions. We’d like to close the topic within a couple weeks to make final modifications.
Option #1:
Use ‘pps_locked’ signal to set the time interface ‘valid’ signal high when the “using_PPS” property is set ‘true’. Time prior to initial PPS detected would be monotonic but free flowing with local clock. During alignment, time unstable but ‘valid’ is ‘false. Following time alignment with PPS, if the PPS is subsequently lost, time will continue using the last calculated fractional increment and remain monotonic. However, incrementation will occur based on the cycle of the local clock which may drift from PPS. When PPS is once again detected, the worker reinitiates the synchronization process which leads to time being temporarily non-monotonic, but ‘valid’ remains ‘false’ until PPS lock occurs. We are seeking responses as to whether or not this is sufficient for most use cases.
Option #2:
Another possible use-case and topic for discussion is a case for presenting monotonic time during the synchronization process when the ‘valid’ is set ‘false’. Whether initial PPS synchronization or re-synchronization following loss of PPS, is there a case where the free flow time using local clock should be presented to the time interface during synchronization? Once synchronization occurs, then the time interface would present the PPS aligned time. This would occur once PPS lock has been indicated but a jump forward or backwards in the fractional time may occur dependent on drift of local clock. It is our understanding that a jump backwards in some use-cases may not be acceptable.