You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just before the lock, the frequency drifts to ~ -20 ppm!
2022-08-22.13-41-29-cut.3.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.
The text was updated successfully, but these errors were encountered:
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!
2022-08-22.13-41-29-cut.3.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.
The text was updated successfully, but these errors were encountered: