Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TimeCard starts with a random frequency offset on 10 MHz output #74

Open
MaciekMachni opened this issue Aug 22, 2022 · 1 comment
Open

Comments

@MaciekMachni
Copy link
Contributor

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:

  • yellow: 10MHz from a PTP source synchronized to the GNSS signal
  • green: 10MHz output of the Time Card.

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.

@ahmadexp
Copy link
Collaborator

ahmadexp commented Aug 9, 2023

Perhaps that is because it that point the internal XTAL on the SOM is in use.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants