general design question about gpsdo systems
Dear Time Nuts,
I have in the past experimented with GPSDO systems that I have built
myself. Now I am designing another sensor circuitry, and I would like time
synchronization tru GPS to be an integral part of it. So I have a
microcontroller unit with a 24mhz xtal, that is voltage controlled, i.e. I
can pull the frequency +-6ppm. My circuit takes advantage of a DAC to feed
the Vref of the xtal, so it is digital in nature.
As you all know, I can either use a divider from main xtal, and a phase
comparator, usually constructed with flip flops, or a xor gate. The divider
and the phase comparator will have at least 50ns propagation delay each.
(under optimistic conditions) - maybe I could be somewhat outdated on
components, but the datasheets I reviewed, especially for counters that can
do multiples of 10, do have propagation delays exceeding 100ns.
So here is my question, I have interrupt latency of 12.5ns in the
microcontroller system I am using. Lets say 20ns practical. At this point
all I have to do is take a note of system clock counter in the
microcontroller, and then make my calculations to send the correct commands
to DAC, so Vref is in order for the XTAL. I understand there are many ways
of doing dividers and phase comparators, and in more professional systems,
they take advantage of analog mixers, etc, to do this very fast.
Should I continue with all digital design, or attempt to design a divider /
phase comparator, where the output of the phase comparator is filtered, and
ADC'ed back to MCU?
Are there any components that can do div by 1M+ and phase comparison under
20ns?
Best Regards,
C.
Hi Cam,
So, you talk about latency. Latency isn't my biggest concern. Variation
of latency is, but that's a fine point.
If you build up a latency of say 20 ns, that is miniscule to the
time-constant of the control loop, and is not of particular worry. What
I should focus on is the resolution of your clock comparison, as that
will be a much larger limitation to your performance than latency.
Latency may cause a few shift in apparent time of occurrence and may
need a bit of compensation, but that is finer details that can be left
as a later exercise.
So my first advice is to analyze timing resolution and any major
systematic or noise components.
Cheers,
Magnus
On 2025-02-23 19:04, Cam Bazz via time-nuts wrote:
Dear Time Nuts,
I have in the past experimented with GPSDO systems that I have built
myself. Now I am designing another sensor circuitry, and I would like time
synchronization tru GPS to be an integral part of it. So I have a
microcontroller unit with a 24mhz xtal, that is voltage controlled, i.e. I
can pull the frequency +-6ppm. My circuit takes advantage of a DAC to feed
the Vref of the xtal, so it is digital in nature.
As you all know, I can either use a divider from main xtal, and a phase
comparator, usually constructed with flip flops, or a xor gate. The divider
and the phase comparator will have at least 50ns propagation delay each.
(under optimistic conditions) - maybe I could be somewhat outdated on
components, but the datasheets I reviewed, especially for counters that can
do multiples of 10, do have propagation delays exceeding 100ns.
So here is my question, I have interrupt latency of 12.5ns in the
microcontroller system I am using. Lets say 20ns practical. At this point
all I have to do is take a note of system clock counter in the
microcontroller, and then make my calculations to send the correct commands
to DAC, so Vref is in order for the XTAL. I understand there are many ways
of doing dividers and phase comparators, and in more professional systems,
they take advantage of analog mixers, etc, to do this very fast.
Should I continue with all digital design, or attempt to design a divider /
phase comparator, where the output of the phase comparator is filtered, and
ADC'ed back to MCU?
Are there any components that can do div by 1M+ and phase comparison under
20ns?
Best Regards,
C.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
Dear Magnus,
Thank you for your illustrative answer. I understand that latency can be
compensated.
My purpose is to timestamp measurements I make from different units. That's
why I would like an internal GPS disciplined clock. And I don't really need
the most precise and accurate timing, as long as the clocks of different
systems beat at the same time. I am guessing that 60ns-100ns accuracy
should be fine.
Best Regards,
C.
So, you talk about latency. Latency isn't my biggest concern. Variation
of latency is, but that's a fine point.
If you build up a latency of say 20 ns, that is miniscule to the
time-constant of the control loop, and is not of particular worry. What
I should focus on is the resolution of your clock comparison, as that
will be a much larger limitation to your performance than latency.
Latency may cause a few shift in apparent time of occurrence and may
need a bit of compensation, but that is finer details that can be left
as a later exercise.
So my first advice is to analyze timing resolution and any major
systematic or noise components.
Cheers,
Magnus
On Mon, Feb 24, 2025 at 3:51 AM Magnus Danielson via time-nuts <
time-nuts@lists.febo.com> wrote:
Hi Cam,
So, you talk about latency. Latency isn't my biggest concern. Variation
of latency is, but that's a fine point.
If you build up a latency of say 20 ns, that is miniscule to the
time-constant of the control loop, and is not of particular worry. What
I should focus on is the resolution of your clock comparison, as that
will be a much larger limitation to your performance than latency.
Latency may cause a few shift in apparent time of occurrence and may
need a bit of compensation, but that is finer details that can be left
as a later exercise.
So my first advice is to analyze timing resolution and any major
systematic or noise components.
Cheers,
Magnus
On 2025-02-23 19:04, Cam Bazz via time-nuts wrote:
Dear Time Nuts,
I have in the past experimented with GPSDO systems that I have built
myself. Now I am designing another sensor circuitry, and I would like
time
synchronization tru GPS to be an integral part of it. So I have a
microcontroller unit with a 24mhz xtal, that is voltage controlled, i.e.
I
can pull the frequency +-6ppm. My circuit takes advantage of a DAC to
feed
the Vref of the xtal, so it is digital in nature.
As you all know, I can either use a divider from main xtal, and a phase
comparator, usually constructed with flip flops, or a xor gate. The
divider
and the phase comparator will have at least 50ns propagation delay each.
(under optimistic conditions) - maybe I could be somewhat outdated on
components, but the datasheets I reviewed, especially for counters that
can
do multiples of 10, do have propagation delays exceeding 100ns.
So here is my question, I have interrupt latency of 12.5ns in the
microcontroller system I am using. Lets say 20ns practical. At this point
all I have to do is take a note of system clock counter in the
microcontroller, and then make my calculations to send the correct
commands
to DAC, so Vref is in order for the XTAL. I understand there are many
ways
of doing dividers and phase comparators, and in more professional
systems,
they take advantage of analog mixers, etc, to do this very fast.
Should I continue with all digital design, or attempt to design a
divider /
phase comparator, where the output of the phase comparator is filtered,
and
ADC'ed back to MCU?
Are there any components that can do div by 1M+ and phase comparison
under
20ns?
Best Regards,
C.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
Why not decode the NMEA data from the GPS to get time and use the 1 pps for "tick accuracy"?
-----Original Message-----
From: Cam Bazz via time-nuts time-nuts@lists.febo.com
Sent: 24 February 2025 13:39
To: Discussion of precise time and frequency measurement time-nuts@lists.febo.com
Cc: Cam Bazz cambazz@gmail.com
Subject: [time-nuts] Re: general design question about gpsdo systems
Dear Magnus,
Thank you for your illustrative answer. I understand that latency can be compensated.
My purpose is to timestamp measurements I make from different units. That's why I would like an internal GPS disciplined clock. And I don't really need the most precise and accurate timing, as long as the clocks of different systems beat at the same time. I am guessing that 60ns-100ns accuracy should be fine.
Best Regards,
C.
So, you talk about latency. Latency isn't my biggest concern.
Variation of latency is, but that's a fine point.
If you build up a latency of say 20 ns, that is miniscule to the
time-constant of the control loop, and is not of particular worry.
What I should focus on is the resolution of your clock comparison, as
that will be a much larger limitation to your performance than latency.
Latency may cause a few shift in apparent time of occurrence and may
need a bit of compensation, but that is finer details that can be left
as a later exercise.
So my first advice is to analyze timing resolution and any major
systematic or noise components.
Cheers,
Magnus
On Mon, Feb 24, 2025 at 3:51 AM Magnus Danielson via time-nuts < time-nuts@lists.febo.com> wrote:
Hi Cam,
So, you talk about latency. Latency isn't my biggest concern.
Variation of latency is, but that's a fine point.
If you build up a latency of say 20 ns, that is miniscule to the
time-constant of the control loop, and is not of particular worry.
What I should focus on is the resolution of your clock comparison, as
that will be a much larger limitation to your performance than latency.
Latency may cause a few shift in apparent time of occurrence and may
need a bit of compensation, but that is finer details that can be left
as a later exercise.
So my first advice is to analyze timing resolution and any major
systematic or noise components.
Cheers,
Magnus
On 2025-02-23 19:04, Cam Bazz via time-nuts wrote:
Dear Time Nuts,
I have in the past experimented with GPSDO systems that I have built
myself. Now I am designing another sensor circuitry, and I would
like
time
synchronization tru GPS to be an integral part of it. So I have a
microcontroller unit with a 24mhz xtal, that is voltage controlled, i.e.
I
can pull the frequency +-6ppm. My circuit takes advantage of a DAC
to
feed
the Vref of the xtal, so it is digital in nature.
As you all know, I can either use a divider from main xtal, and a
phase comparator, usually constructed with flip flops, or a xor
gate. The
divider
and the phase comparator will have at least 50ns propagation delay each.
(under optimistic conditions) - maybe I could be somewhat outdated
on components, but the datasheets I reviewed, especially for
counters that
can
do multiples of 10, do have propagation delays exceeding 100ns.
So here is my question, I have interrupt latency of 12.5ns in the
microcontroller system I am using. Lets say 20ns practical. At this
point all I have to do is take a note of system clock counter in the
microcontroller, and then make my calculations to send the correct
commands
to DAC, so Vref is in order for the XTAL. I understand there are
many
ways
of doing dividers and phase comparators, and in more professional
systems,
they take advantage of analog mixers, etc, to do this very fast.
Should I continue with all digital design, or attempt to design a
divider /
phase comparator, where the output of the phase comparator is
filtered,
and
ADC'ed back to MCU?
Are there any components that can do div by 1M+ and phase comparison
under
20ns?
Best Regards,
C.
time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe
send an email to time-nuts-leave@lists.febo.com
time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe send
an email to time-nuts-leave@lists.febo.com
time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe send an email to time-nuts-leave@lists.febo.com
Hi Cam,
On 2/24/25 14:39, Cam Bazz via time-nuts wrote:
Dear Magnus,
Thank you for your illustrative answer. I understand that latency can be
compensated.
My purpose is to timestamp measurements I make from different units. That's
why I would like an internal GPS disciplined clock. And I don't really need
the most precise and accurate timing, as long as the clocks of different
systems beat at the same time. I am guessing that 60ns-100ns accuracy
should be fine.
That simplifies a lot. Then you can focus on the stability of latency
and achieving the time-stamp robust.
For those other sources, if you timestamp at a higher rate and average,
you can get improved accuracy if you later wish to have that.
Cheers,
Magnus
Best Regards,
C.
So, you talk about latency. Latency isn't my biggest concern. Variation
of latency is, but that's a fine point.If you build up a latency of say 20 ns, that is miniscule to the
time-constant of the control loop, and is not of particular worry. What
I should focus on is the resolution of your clock comparison, as that
will be a much larger limitation to your performance than latency.
Latency may cause a few shift in apparent time of occurrence and may
need a bit of compensation, but that is finer details that can be left
as a later exercise.So my first advice is to analyze timing resolution and any major
systematic or noise components.
Cheers,
Magnus
On Mon, Feb 24, 2025 at 3:51 AM Magnus Danielson via time-nuts <
time-nuts@lists.febo.com> wrote:
Hi Cam,
So, you talk about latency. Latency isn't my biggest concern. Variation
of latency is, but that's a fine point.If you build up a latency of say 20 ns, that is miniscule to the
time-constant of the control loop, and is not of particular worry. What
I should focus on is the resolution of your clock comparison, as that
will be a much larger limitation to your performance than latency.
Latency may cause a few shift in apparent time of occurrence and may
need a bit of compensation, but that is finer details that can be left
as a later exercise.So my first advice is to analyze timing resolution and any major
systematic or noise components.Cheers,
MagnusOn 2025-02-23 19:04, Cam Bazz via time-nuts wrote:
Dear Time Nuts,
I have in the past experimented with GPSDO systems that I have built
myself. Now I am designing another sensor circuitry, and I would like
time
synchronization tru GPS to be an integral part of it. So I have a
microcontroller unit with a 24mhz xtal, that is voltage controlled, i.e.
I
can pull the frequency +-6ppm. My circuit takes advantage of a DAC to
feed
the Vref of the xtal, so it is digital in nature.As you all know, I can either use a divider from main xtal, and a phase
comparator, usually constructed with flip flops, or a xor gate. The
divider
and the phase comparator will have at least 50ns propagation delay each.
(under optimistic conditions) - maybe I could be somewhat outdated on
components, but the datasheets I reviewed, especially for counters that
can
do multiples of 10, do have propagation delays exceeding 100ns.So here is my question, I have interrupt latency of 12.5ns in the
microcontroller system I am using. Lets say 20ns practical. At this point
all I have to do is take a note of system clock counter in the
microcontroller, and then make my calculations to send the correct
commands
to DAC, so Vref is in order for the XTAL. I understand there are many
ways
of doing dividers and phase comparators, and in more professional
systems,
they take advantage of analog mixers, etc, to do this very fast.Should I continue with all digital design, or attempt to design a
divider /
phase comparator, where the output of the phase comparator is filtered,
and
ADC'ed back to MCU?Are there any components that can do div by 1M+ and phase comparison
under
20ns?Best Regards,
C.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
Cam,
I have a similar requirement: synchronized timestamps from multiple
devices possibly at multiple locations.
My solution, like yours, is to use a 80 MHz microcontroller with N GPIO
pins, each with a capture counter. The difference is that I use N-1 of
the inputs (A, B, C, ...) for the signals I want to timestamp and 1 of
the inputs (G) for a 1PPS signal from a cheap GPS board. There's no
GPSDO, no OCXO, no EFC, no DAC. Each microcontroller runs from its own
cheap XO, none of which are calibrated.
So I get a stream of N readings with 12.5 ns resolution that are neither
accurate in frequency or time. It sounds like a bad design until you
realize that you can use the channel G data to measure the frequency and
phase error of the XO in real time, numerical corrections that you then
apply to readings from all channels before the user sees them. The
result is that all the timestamps are precisely synchronized to UTC. You
could call it a "software GPSDO", except is doesn't discipline an
oscillator, it disciplines the readings.
See if this simple design works for your application. I've been using
the technique for years. Note this also solves interrupt or pin latency
issues because the same timestamping h/w and s/w is used for the signal
inputs as the GPS/1PPS input.
/tvb
I've used a similar technique - it's well established in the space business and called "time correlation" - that is, everything is measured relative to the spacecraft clock oscillator (SCLK, generically), and then by comparing something (typically the earth received time of telemetry frames) you can reconstruct the behavior of the onboard clock.
The problem with these techniques in general is that they are "post hoc". You don't have the ability to synchronize events occurring in the future.
Tom, Isn't this sort of a fancier version of the picPET?
On Tue, 25 Feb 2025 09:11:13 -0800, Tom Van Baak via time-nuts time-nuts@lists.febo.com wrote:
Cam,
I have a similar requirement: synchronized timestamps from multiple
devices possibly at multiple locations.
My solution, like yours, is to use a 80 MHz microcontroller with N GPIO
pins, each with a capture counter. The difference is that I use N-1 of
the inputs (A, B, C, ...) for the signals I want to timestamp and 1 of
the inputs (G) for a 1PPS signal from a cheap GPS board. There's no
GPSDO, no OCXO, no EFC, no DAC. Each microcontroller runs from its own
cheap XO, none of which are calibrated.
So I get a stream of N readings with 12.5 ns resolution that are neither
accurate in frequency or time. It sounds like a bad design until you
realize that you can use the channel G data to measure the frequency and
phase error of the XO in real time, numerical corrections that you then
apply to readings from all channels before the user sees them. The
result is that all the timestamps are precisely synchronized to UTC. You
could call it a "software GPSDO", except is doesn't discipline an
oscillator, it disciplines the readings.
See if this simple design works for your application. I've been using
the technique for years. Note this also solves interrupt or pin latency
issues because the same timestamping h/w and s/w is used for the signal
inputs as the GPS/1PPS input.
/tvb
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com