Develop an end-to-end hypothetical reference model, network architectures, precision time tools, performance objectives and the methods to distribute, operate, monitor time synchronization within data center and much more...
MIT License
1.32k
stars
101
forks
source link
TimeCard starts with a random frequency offset on 10 MHz output #74
If this behavior is unavoidable (i.e., saving the last corrections and applying them on boot), there should be an option to squelch 10MHz output until it gets the initial lock, as in the current state, it breaks the 4.6 ppm limits of SyncE while locking.
Time Card starts with a random frequency offset (around 5ppm). It doesn't correct the frequency until it gets the GNSS lock.
The issue is shown in the video below. It shows two traces:
Timestamps: 0:00 - boot and enable gnss_sync monitor 1:35 - GNSS sync acquired 4:20 - pull-in begins 5:11 - biggest frequency drift 5:14 - lock acquired
Just before the lock, the frequency drifts to ~ -20 ppm!
https://user-images.githubusercontent.com/86620984/185916904-a05f1b7f-7723-457e-877f-3e3ee13e429b.mp4
If this behavior is unavoidable (i.e., saving the last corrections and applying them on boot), there should be an option to squelch 10MHz output until it gets the initial lock, as in the current state, it breaks the 4.6 ppm limits of SyncE while locking.