GPSDO/GNSSDO project: STM32G4 + u-blox ZED-F9T + TDC7200
Hello everyone,
back in April I asked about a 100 MHz GNSSDO for mobile use [0]. As
nothing COTS seemed to be available, I've since started developing a
prototype based. I finally – been busy with work – got the design to
sth. work sharing and am looking for feedback. The following is
cross-posted on the EEVblog forum [1]:
I'm in need of a GNSSDO for accurate time synchronization of moving
vehicles distributed over a few (dozen) square km. I've been
professionally using the James Miller (G3RUH) Ministd [2], Jackson Labs
LC_XO [3], and SRS FS740 [4], but none of these deliver satisfactory
results when used on the move. That's certainly not a flaw of these
devices, because presumably they were not designed with a non-stationary
use case in mind. Therefore, I decided to build a suitable GNSSDO
myself. This is not a low-cost project. Development priorities are
performance, simplicity, and value for money in that order.
I have positive experience with the u-blox ZED-F9P RTK [5] GNSS
receivers. As the F9P can achieve <5cm position accuracy with RTK
correction data, its timing receiver sibling (ZED-F9T) should enable
sub-nanosecond timing accuracy. The F9T supports differential timing [6]
via the same correction data used for RTK positioning. I'm not aware of
any other GNSS timing receivers supporting this feature. The F9T also
exhibits excellent Allan deviation (~5e-11 @ 10s) [7]. Therefore, the
F9T is the center piece of my design, relying on the RCB-F9T [8] board
for prototyping.
Design aspects/goals:
- ZED-F9T timing GNSS receiver with RTK correction data
- 10 MHz OCXO as local reference oscillator (special OCXOs with low
g-sensitivity for non-stationary use exist) - TDC7200 for ~50 ps measurement of GNSS timepulse vs. OCXO
- STM32 32-bit timer capture (~6ns resolution) to resolve
aliasing/ambiguity of TDC measurement - <10ns relative accuracy within 10 km radius while on the move
(preferably <1ns) - stabilized pulse output derived from OCXO (not directly from GNSS
receiver) - configurable pulse properties (not only 1PPS) with fine-tunable
delay (~200ps resolution via STM32G4x4 high resolution timers) - integrated distribution amplifier for 10 MHz and 1PPS outputs
(capable of driving 50 Ohm loads) - part and manufacturing costs preferably <500€ per device (excl. OCXO)
My architecture is inspired (among others) by Matthias Welwarsky's "DIY
GPSDO project w/ STM32, TDC7200" [9]. However, I hope to improve on
these aspects:
- Minimize digital processing of OCXO output. Feed 10 MHz directly to
TDC7200 without division via 74HC390 to minimize temperature
dependence [10]. - Only use low-jitter clock ICs (e.g., LMK1C110x for fanout). No
74-type components, which AFAIK do not have jitter or phase noise specs. - Active 1 Hz low-pass filter after tuning DAC to a) minimize noise
(from supply, voltage reference, and DAC) fed to OCXO control
voltage input and to b) enable finer than 16-bit tuning resolution
via PWM. Assuming a 2 ppm tuning range, 16 bit yields 30 ppt
frequency tuning resolution. At 10 seconds, that's already 300 ps,
which is higher than the TDC7200's ~50 ps resolution. Hence, a finer
tuning resolution may come in handy, of course depending on the
actual stability of OCXO and GNSS.
My next step is to build a prototype PCB to put my ideas to the test.
I've devised the preliminary architecture and put it into a schematic.
The layout is in progress.
I've attached the schematic and would appreciate constructive feedback,
prior to having it produced.
Thanks and best regards,
Carsten
[0]
https://febo.com/pipermail/time-nuts_lists.febo.com/2022-April/105583.html
[1]
https://www.eevblog.com/forum/projects/gpsdognssdo-stm32g4-u-blox-zed-f9t-tdc7200/
[2] http://www.jrmiller.online/projects/ministd/manual.pdf
[3] https://www.jackson-labs.com/index.php/products/lc_xo
[4] https://www.thinksrs.com/products/fs740.html
[5] https://en.wikipedia.org/wiki/Real-time_kinematic_positioning
[6]
https://content.u-blox.com/sites/default/files/ZED-F9T-00B_DataSheet_UBX-18053713.pdf#page=6
[7]
https://hamsci.org/sites/default/files/publications/2020_TAPR_DCC/N8UR_GPS_Evaluation_August2020.pdf#page=25
[8] https://www.u-blox.com/en/product/rcb-f9t-timing-board
[9]
https://www.eevblog.com/forum/projects/diy-gpsdo-project-w-stm32-tdc7200/
[10]
https://www.eevblog.com/forum/projects/diy-gpsdo-project-w-stm32-tdc7200/msg2921634/#msg2921634
Hi Carsten,
I think the F9T relies on being in fixed position for the TIMING it's specs.
Perhaps Bob kb8tq, could provide more input to that aspec.
BILL WB6BNQ
On 8/5/2022 12:38 PM, Carsten Andrich via time-nuts wrote:
Hello everyone,
back in April I asked about a 100 MHz GNSSDO for mobile use [0]. As
nothing COTS seemed to be available, I've since started developing a
prototype based. I finally – been busy with work – got the design to
sth. work sharing and am looking for feedback. The following is
cross-posted on the EEVblog forum [1]:
I'm in need of a GNSSDO for accurate time synchronization of moving
vehicles distributed over a few (dozen) square km. I've been
professionally using the James Miller (G3RUH) Ministd [2], Jackson
Labs LC_XO [3], and SRS FS740 [4], but none of these deliver
satisfactory results when used on the move. That's certainly not a
flaw of these devices, because presumably they were not designed with
a non-stationary use case in mind. Therefore, I decided to build a
suitable GNSSDO myself. This is not a low-cost project. Development
priorities are performance, simplicity, and value for money in that
order.
I have positive experience with the u-blox ZED-F9P RTK [5] GNSS
receivers. As the F9P can achieve <5cm position accuracy with RTK
correction data, its timing receiver sibling (ZED-F9T) should enable
sub-nanosecond timing accuracy. The F9T supports differential timing
[6] via the same correction data used for RTK positioning. I'm not
aware of any other GNSS timing receivers supporting this feature. The
F9T also exhibits excellent Allan deviation (~5e-11 @ 10s) [7].
Therefore, the F9T is the center piece of my design, relying on the
RCB-F9T [8] board for prototyping.
Design aspects/goals:
* ZED-F9T timing GNSS receiver with RTK correction data
* 10 MHz OCXO as local reference oscillator (special OCXOs with low
g-sensitivity for non-stationary use exist)
* TDC7200 for ~50 ps measurement of GNSS timepulse vs. OCXO
* STM32 32-bit timer capture (~6ns resolution) to resolve
aliasing/ambiguity of TDC measurement
* <10ns relative accuracy within 10 km radius while on the move
(preferably <1ns)
* stabilized pulse output derived from OCXO (not directly from GNSS
receiver)
* configurable pulse properties (not only 1PPS) with fine-tunable
delay (~200ps resolution via STM32G4x4 high resolution timers)
* integrated distribution amplifier for 10 MHz and 1PPS outputs
(capable of driving 50 Ohm loads)
* part and manufacturing costs preferably <500€ per device (excl. OCXO)
My architecture is inspired (among others) by Matthias Welwarsky's
"DIY GPSDO project w/ STM32, TDC7200" [9]. However, I hope to improve
on these aspects:
* Minimize digital processing of OCXO output. Feed 10 MHz directly to
TDC7200 without division via 74HC390 to minimize temperature
dependence [10].
* Only use low-jitter clock ICs (e.g., LMK1C110x for fanout). No
74-type components, which AFAIK do not have jitter or phase noise
specs.
* Active 1 Hz low-pass filter after tuning DAC to a) minimize noise
(from supply, voltage reference, and DAC) fed to OCXO control
voltage input and to b) enable finer than 16-bit tuning resolution
via PWM. Assuming a 2 ppm tuning range, 16 bit yields 30 ppt
frequency tuning resolution. At 10 seconds, that's already 300 ps,
which is higher than the TDC7200's ~50 ps resolution. Hence, a finer
tuning resolution may come in handy, of course depending on the
actual stability of OCXO and GNSS.
My next step is to build a prototype PCB to put my ideas to the test.
I've devised the preliminary architecture and put it into a schematic.
The layout is in progress.
I've attached the schematic and would appreciate constructive
feedback, prior to having it produced.
Thanks and best regards,
Carsten
[0]
https://febo.com/pipermail/time-nuts_lists.febo.com/2022-April/105583.html
[1]
https://www.eevblog.com/forum/projects/gpsdognssdo-stm32g4-u-blox-zed-f9t-tdc7200/
[2] http://www.jrmiller.online/projects/ministd/manual.pdf
[3] https://www.jackson-labs.com/index.php/products/lc_xo
[4] https://www.thinksrs.com/products/fs740.html
[5] https://en.wikipedia.org/wiki/Real-time_kinematic_positioning
[6]
https://content.u-blox.com/sites/default/files/ZED-F9T-00B_DataSheet_UBX-18053713.pdf#page=6
[7]
https://hamsci.org/sites/default/files/publications/2020_TAPR_DCC/N8UR_GPS_Evaluation_August2020.pdf#page=25
[8] https://www.u-blox.com/en/product/rcb-f9t-timing-board
[9]
https://www.eevblog.com/forum/projects/diy-gpsdo-project-w-stm32-tdc7200/
[10]
https://www.eevblog.com/forum/projects/diy-gpsdo-project-w-stm32-tdc7200/msg2921634/#msg2921634
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
Not that I like spending a lot of money but for $300 or less Gepetto Electronics sells a pretty good 10 MHz GPSO "https://www.tindie.com/products/nsayer/gps-disciplined-ocxo/". I've had one for about 5 years, very accurate and trouble free! Maybe not as fun as building your own but just putting it out there.
Les, N1SV
On 08/05/2022 3:38 PM Carsten Andrich via time-nuts time-nuts@lists.febo.com wrote:
Hello everyone,
back in April I asked about a 100 MHz GNSSDO for mobile use [0]. As
nothing COTS seemed to be available, I've since started developing a
prototype based. I finally – been busy with work – got the design to
sth. work sharing and am looking for feedback. The following is
cross-posted on the EEVblog forum [1]:
I'm in need of a GNSSDO for accurate time synchronization of moving
vehicles distributed over a few (dozen) square km. I've been
professionally using the James Miller (G3RUH) Ministd [2], Jackson Labs
LC_XO [3], and SRS FS740 [4], but none of these deliver satisfactory
results when used on the move. That's certainly not a flaw of these
devices, because presumably they were not designed with a non-stationary
use case in mind. Therefore, I decided to build a suitable GNSSDO
myself. This is not a low-cost project. Development priorities are
performance, simplicity, and value for money in that order.
I have positive experience with the u-blox ZED-F9P RTK [5] GNSS
receivers. As the F9P can achieve <5cm position accuracy with RTK
correction data, its timing receiver sibling (ZED-F9T) should enable
sub-nanosecond timing accuracy. The F9T supports differential timing [6]
via the same correction data used for RTK positioning. I'm not aware of
any other GNSS timing receivers supporting this feature. The F9T also
exhibits excellent Allan deviation (~5e-11 @ 10s) [7]. Therefore, the
F9T is the center piece of my design, relying on the RCB-F9T [8] board
for prototyping.
Design aspects/goals:
- ZED-F9T timing GNSS receiver with RTK correction data
- 10 MHz OCXO as local reference oscillator (special OCXOs with low
g-sensitivity for non-stationary use exist) - TDC7200 for ~50 ps measurement of GNSS timepulse vs. OCXO
- STM32 32-bit timer capture (~6ns resolution) to resolve
aliasing/ambiguity of TDC measurement - <10ns relative accuracy within 10 km radius while on the move
(preferably <1ns) - stabilized pulse output derived from OCXO (not directly from GNSS
receiver) - configurable pulse properties (not only 1PPS) with fine-tunable
delay (~200ps resolution via STM32G4x4 high resolution timers) - integrated distribution amplifier for 10 MHz and 1PPS outputs
(capable of driving 50 Ohm loads) - part and manufacturing costs preferably <500€ per device (excl. OCXO)
My architecture is inspired (among others) by Matthias Welwarsky's "DIY
GPSDO project w/ STM32, TDC7200" [9]. However, I hope to improve on
these aspects:
- Minimize digital processing of OCXO output. Feed 10 MHz directly to
TDC7200 without division via 74HC390 to minimize temperature
dependence [10]. - Only use low-jitter clock ICs (e.g., LMK1C110x for fanout). No
74-type components, which AFAIK do not have jitter or phase noise specs. - Active 1 Hz low-pass filter after tuning DAC to a) minimize noise
(from supply, voltage reference, and DAC) fed to OCXO control
voltage input and to b) enable finer than 16-bit tuning resolution
via PWM. Assuming a 2 ppm tuning range, 16 bit yields 30 ppt
frequency tuning resolution. At 10 seconds, that's already 300 ps,
which is higher than the TDC7200's ~50 ps resolution. Hence, a finer
tuning resolution may come in handy, of course depending on the
actual stability of OCXO and GNSS.
My next step is to build a prototype PCB to put my ideas to the test.
I've devised the preliminary architecture and put it into a schematic.
The layout is in progress.
I've attached the schematic and would appreciate constructive feedback,
prior to having it produced.
Thanks and best regards,
Carsten
[0]
https://febo.com/pipermail/time-nuts_lists.febo.com/2022-April/105583.html
[1]
https://www.eevblog.com/forum/projects/gpsdognssdo-stm32g4-u-blox-zed-f9t-tdc7200/
[2] http://www.jrmiller.online/projects/ministd/manual.pdf
[3] https://www.jackson-labs.com/index.php/products/lc_xo
[4] https://www.thinksrs.com/products/fs740.html
[5] https://en.wikipedia.org/wiki/Real-time_kinematic_positioning
[6]
https://content.u-blox.com/sites/default/files/ZED-F9T-00B_DataSheet_UBX-18053713.pdf#page=6
[7]
https://hamsci.org/sites/default/files/publications/2020_TAPR_DCC/N8UR_GPS_Evaluation_August2020.pdf#page=25
[8] https://www.u-blox.com/en/product/rcb-f9t-timing-board
[9]
https://www.eevblog.com/forum/projects/diy-gpsdo-project-w-stm32-tdc7200/
[10]
https://www.eevblog.com/forum/projects/diy-gpsdo-project-w-stm32-tdc7200/msg2921634/#msg2921634
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
Hi
Actually John would be the better one to check with since his paper is referenced
as the source of the data :) :): :). My plots of these parts just show up here on
the list ….
The ADEV you get is much better than the “timing” spec on these parts. Indeed
that spec is typically a bit vague in terms of just what it actually is referring to. In
the case of the F9T it certainly isn’t spec’ing 1x10^-11 level ADEV.
Just what this or that device does in a moving environment is very much a “try
it and see” sort of thing. There are simply to many variables to come up with a
single magic number. Moving on a train across a flat / wide open field with 360
degree sky view to within 10 degrees of the horizon is very different than driving
a motorbike through the typical urban canyon with very limited sky view. Doing
either one at 50 degrees north is different than doing it at the equator. Drones
have different issues than backpacks…… it goes on and on and on ….
With the F9x’s and a “GPS only” design, you have a limited number of sat’s
to use. That makes everything more difficult. A “multi-GNSS” approach is an
alternative, it brings with it a variety of issues.
As many have found, dealing with OCXO’s in changing environments is a bit
exciting. They most certainly do go in a variety of settings. Something around
99% live in a fixed / bench sort of install. The spec sheet data on a catalog part
is inevitably talking about a very stable situation. Performance is always degraded
if things like shock / vibration / acceleration / temperature change are involved.
Without a target accuracy spec on the device, there really is no way to know if
this or that approach is going to work. Is this a time source? Is it just a frequency
reference? What is the target accuracy in the real world? What is the “vehicle”
and what are its characteristics?
Lots and lots of rabbit holes to chase down …. ( and we never even made it
to the problematic filter on the DAC …).
Bob
On Aug 5, 2022, at 2:43 PM, WB6BNQ via time-nuts time-nuts@lists.febo.com wrote:
Hi Carsten,
I think the F9T relies on being in fixed position for the TIMING it's specs.
Perhaps Bob kb8tq, could provide more input to that aspec.
BILL WB6BNQ
On 8/5/2022 12:38 PM, Carsten Andrich via time-nuts wrote:
Hello everyone,
back in April I asked about a 100 MHz GNSSDO for mobile use [0]. As nothing COTS seemed to be available, I've since started developing a prototype based. I finally – been busy with work – got the design to sth. work sharing and am looking for feedback. The following is cross-posted on the EEVblog forum [1]:
I'm in need of a GNSSDO for accurate time synchronization of moving vehicles distributed over a few (dozen) square km. I've been professionally using the James Miller (G3RUH) Ministd [2], Jackson Labs LC_XO [3], and SRS FS740 [4], but none of these deliver satisfactory results when used on the move. That's certainly not a flaw of these devices, because presumably they were not designed with a non-stationary use case in mind. Therefore, I decided to build a suitable GNSSDO myself. This is not a low-cost project. Development priorities are performance, simplicity, and value for money in that order.
I have positive experience with the u-blox ZED-F9P RTK [5] GNSS receivers. As the F9P can achieve <5cm position accuracy with RTK correction data, its timing receiver sibling (ZED-F9T) should enable sub-nanosecond timing accuracy. The F9T supports differential timing [6] via the same correction data used for RTK positioning. I'm not aware of any other GNSS timing receivers supporting this feature. The F9T also exhibits excellent Allan deviation (~5e-11 @ 10s) [7]. Therefore, the F9T is the center piece of my design, relying on the RCB-F9T [8] board for prototyping.
Design aspects/goals:
- ZED-F9T timing GNSS receiver with RTK correction data
- 10 MHz OCXO as local reference oscillator (special OCXOs with low
g-sensitivity for non-stationary use exist) - TDC7200 for ~50 ps measurement of GNSS timepulse vs. OCXO
- STM32 32-bit timer capture (~6ns resolution) to resolve
aliasing/ambiguity of TDC measurement - <10ns relative accuracy within 10 km radius while on the move
(preferably <1ns) - stabilized pulse output derived from OCXO (not directly from GNSS
receiver) - configurable pulse properties (not only 1PPS) with fine-tunable
delay (~200ps resolution via STM32G4x4 high resolution timers) - integrated distribution amplifier for 10 MHz and 1PPS outputs
(capable of driving 50 Ohm loads) - part and manufacturing costs preferably <500€ per device (excl. OCXO)
My architecture is inspired (among others) by Matthias Welwarsky's "DIY GPSDO project w/ STM32, TDC7200" [9]. However, I hope to improve on these aspects:
- Minimize digital processing of OCXO output. Feed 10 MHz directly to
TDC7200 without division via 74HC390 to minimize temperature
dependence [10]. - Only use low-jitter clock ICs (e.g., LMK1C110x for fanout). No
74-type components, which AFAIK do not have jitter or phase noise specs. - Active 1 Hz low-pass filter after tuning DAC to a) minimize noise
(from supply, voltage reference, and DAC) fed to OCXO control
voltage input and to b) enable finer than 16-bit tuning resolution
via PWM. Assuming a 2 ppm tuning range, 16 bit yields 30 ppt
frequency tuning resolution. At 10 seconds, that's already 300 ps,
which is higher than the TDC7200's ~50 ps resolution. Hence, a finer
tuning resolution may come in handy, of course depending on the
actual stability of OCXO and GNSS.
My next step is to build a prototype PCB to put my ideas to the test. I've devised the preliminary architecture and put it into a schematic. The layout is in progress.
I've attached the schematic and would appreciate constructive feedback, prior to having it produced.
Thanks and best regards,
Carsten
[0] https://febo.com/pipermail/time-nuts_lists.febo.com/2022-April/105583.html
[1] https://www.eevblog.com/forum/projects/gpsdognssdo-stm32g4-u-blox-zed-f9t-tdc7200/
[2] http://www.jrmiller.online/projects/ministd/manual.pdf
[3] https://www.jackson-labs.com/index.php/products/lc_xo
[4] https://www.thinksrs.com/products/fs740.html
[5] https://en.wikipedia.org/wiki/Real-time_kinematic_positioning
[6] https://content.u-blox.com/sites/default/files/ZED-F9T-00B_DataSheet_UBX-18053713.pdf#page=6
[7] https://hamsci.org/sites/default/files/publications/2020_TAPR_DCC/N8UR_GPS_Evaluation_August2020.pdf#page=25
[8] https://www.u-blox.com/en/product/rcb-f9t-timing-board
[9] https://www.eevblog.com/forum/projects/diy-gpsdo-project-w-stm32-tdc7200/
[10] https://www.eevblog.com/forum/projects/diy-gpsdo-project-w-stm32-tdc7200/msg2921634/#msg2921634
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 Bob,
On 06.08.22 18:50, Bob kb8tq via time-nuts wrote:
As many have found, dealing with OCXO’s in changing environments is a bit
exciting. They most certainly do go in a variety of settings. Something around
99% live in a fixed / bench sort of install. The spec sheet data on a catalog part
is inevitably talking about a very stable situation. Performance is always degraded
if things like shock / vibration / acceleration / temperature change are involved.
For my prototype I just picked a readily available, not too expensive
OCXO. If the prototype works out, of course an OCXO with low
g-sensitivity is due for the next iteration. Specialized 10/100 MHz
OCXOs with <0.2 ppb/g sensitivity on the worst axis are available, but
not exactly cheap.
Without a target accuracy spec on the device, there really is no way to know if
this or that approach is going to work. Is this a time source? Is it just a frequency
reference? What is the target accuracy in the real world? What is the “vehicle”
and what are its characteristics
I require time (and therefore implied frequency) synchronization with
<10 ns accuracy. 1 ns would be preferred, as I already reached that for
stationary applications with SRS FS740s. My use case is coherent
sampling for spatially distributed software-defined radios and
millimeter wave frequency converters. The vehicle is primarily a car,
but may also be airborne.
and we never even made it
to the problematic filter on the DAC
Could you elaborate on that, please?
Thanks and best regards,
Carsten
Hi
On Aug 7, 2022, at 6:08 AM, Carsten Andrich via time-nuts time-nuts@lists.febo.com wrote:
Hi Bob,
On 06.08.22 18:50, Bob kb8tq via time-nuts wrote:
As many have found, dealing with OCXO’s in changing environments is a bit
exciting. They most certainly do go in a variety of settings. Something around
99% live in a fixed / bench sort of install. The spec sheet data on a catalog part
is inevitably talking about a very stable situation. Performance is always degraded
if things like shock / vibration / acceleration / temperature change are involved.
For my prototype I just picked a readily available, not too expensive OCXO. If the prototype works out, of course an OCXO with low g-sensitivity is due for the next iteration. Specialized 10/100 MHz OCXOs with <0.2 ppb/g sensitivity on the worst axis are available, but not exactly cheap.
There are devices out there with much lower G sensitivities.
Without a target accuracy spec on the device, there really is no way to know if
this or that approach is going to work. Is this a time source? Is it just a frequency
reference? What is the target accuracy in the real world? What is the “vehicle”
and what are its characteristics
I require time (and therefore implied frequency) synchronization with <10 ns accuracy. 1 ns would be preferred, as I already reached that for stationary applications with SRS FS740s. My use case is coherent sampling for spatially distributed software-defined radios and millimeter wave frequency converters. The vehicle is primarily a car, but may also be airborne.
If your cars are in an urban area, even getting 10 ns ( let alone 1 ns) will be difficult,
That’s regardless of the GPS used. Vibration is likely to be a pretty big deal in an
airborne application. This is one of the reasons various outfits make vibration
compensated oscillators.
Static compensation is a different animal than full up vibration compensation. If you
(slowly) tip the OCXO over and it shifts < 0.x ppm then it passes. Put it on a vibe
table and shake it at 10 Hz and you likely get a very different result.
and we never even made it
to the problematic filter on the DAC
Could you elaborate on that, please?
A 1 Hz filter implies a certain amount of time delay. That time delay gives you in
loop phase shift. That phase shift will result in peaking in the noise. This is not
what you want in a GPSDO ….
Bob
Thanks and best regards,
Carsten
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
Hi Bob,
On 07.08.22 22:54, Bob kb8tq wrote:
For my prototype I just picked a readily available, not too expensive
OCXO. If the prototype works out, of course an OCXO with low
g-sensitivity is due for the next iteration. Specialized 10/100 MHz
OCXOs with <0.2 ppb/g sensitivity on the worst axis are available,
but not exactly cheap.
There are devices out there with much lower G sensitivities.
What I've found goes down to ~0.05 ppb/g per axis, but these sensitivity
levels are prohibitively expensive or come in large, non-SMD/THT
packages due to mechanical decoupling. If you know of anything better or
particular vendors, let me know.
If your cars are in an urban area, even getting 10 ns ( let alone 1 ns) will be difficult,
That’s regardless of the GPS used. Vibration is likely to be a pretty big deal in an
airborne application. This is one of the reasons various outfits make vibration
compensated oscillators.
I've used the ZED-F9P RTK in what qualifies as urban areas in central
Europe (i.e., no skyscraper street canyons). Their performance is good,
as far as I can tell without a 20k€ INS unit. For accurate heading
information we use two F9Ps per vehicle with antennas placed along the
central car axis. As the baseline length between the antennas is fixed
regardless of the car's movement, the baseline can serve as an indicator
for position accuracy. With the antennas 1.6 m apart (~8 wavelengths at
1.5 GHz), I'd expect substantial impact of multi-path propagation of the
GNSS signal, which likely is the predominant error source in an urban
environment.
See attached CCDF for results. 90% is below 3 cm and 98% below 30 cm.
Translated into propagation delays that's 98% below 1 ns. Since the
F9P's RTK fixes are 4-dimensional (position + time), I'd assume that
the F9T's multi-path induced time error should be proportional to the
F9P's position error. Only measurements will tell whether or not that
assumption turns out to be true.
and we never even made it
to the problematic filter on the DAC
Could you elaborate on that, please?
A 1 Hz filter implies a certain amount of time delay. That time delay gives you in
loop phase shift. That phase shift will result in peaking in the noise. This is not
what you want in a GPSDO ….
Before I drew the schematic, I've simulated the filter using TI's PSpice
model of the OPA189 (results attached; simulated DAC output at 2V bias +
1mV AC). It exhibits a 45° phase shift at 0.5 Hz. I've attached a new
group delay plot. It peaks at ~0.5 Hz and ~0.27 seconds. Presumably
negligible for control loop time constants >10 sec.
Regardless, as far as I understand it, the phase shift issue you refer
to applies to fully analog loop filters. A digital control loop can
account for and compensate the loop filter's transfer function, as far
as I can recall from my control theory lectures.
Thanks and best regards,
Carsten
Hi
On Aug 8, 2022, at 5:39 AM, Carsten Andrich carsten.andrich@tu-ilmenau.de wrote:
Hi Bob,
On 07.08.22 22:54, Bob kb8tq wrote:
For my prototype I just picked a readily available, not too expensive OCXO. If the prototype works out, of course an OCXO with low g-sensitivity is due for the next iteration. Specialized 10/100 MHz OCXOs with <0.2 ppb/g sensitivity on the worst axis are available, but not exactly cheap.
There are devices out there with much lower G sensitivities.
What I've found goes down to ~0.05 ppb/g per axis, but these sensitivity levels are prohibitively expensive or come in large, non-SMD/THT packages due to mechanical decoupling. If you know of anything better or particular vendors, let me know.
Is something over $5K per unit / minimum order of a hundred “in budget” for this application?
If your cars are in an urban area, even getting 10 ns ( let alone 1 ns) will be difficult,
That’s regardless of the GPS used. Vibration is likely to be a pretty big deal in an
airborne application. This is one of the reasons various outfits make vibration
compensated oscillators.
I've used the ZED-F9P RTK in what qualifies as urban areas in central Europe (i.e., no skyscraper street canyons). Their performance is good, as far as I can tell without a 20k€ INS unit. For accurate heading information we use two F9Ps per vehicle with antennas placed along the central car axis. As the baseline length between the antennas is fixed regardless of the car's movement, the baseline can serve as an indicator for position accuracy. With the antennas 1.6 m apart (~8 wavelengths at 1.5 GHz), I'd expect substantial impact of multi-path propagation of the GNSS signal, which likely is the predominant error source in an urban environment.
See attached CCDF for results. 90% is below 3 cm and 98% below 30 cm. Translated into propagation delays that's 98% below 1 ns. Since the F9P's RTK fixes are 4-dimensional (position + time), I'd assume that the F9T's multi-path induced time error should be proportional to the F9P's position error. Only measurements will tell whether or not that assumption turns out to be true.
Time error and position error are only somewhat related. The time error is very likley
to be worse that what you are guessing from the position.
and we never even made it
to the problematic filter on the DAC
Could you elaborate on that, please?
A 1 Hz filter implies a certain amount of time delay. That time delay gives you in
loop phase shift. That phase shift will result in peaking in the noise. This is not
what you want in a GPSDO ….
Before I drew the schematic, I've simulated the filter using TI's PSpice model of the OPA189 (results attached; simulated DAC output at 2V bias + 1mV AC). It exhibits a 45° phase shift at 0.5 Hz. I've attached a new group delay plot. It peaks at ~0.5 Hz and ~0.27 seconds. Presumably negligible for control loop time constants >10 sec.
Unless your oscillator is degraded in some way by this noise ( = it has a massive tuning
sensitivity ) there is no advantage to doing this. An octave tuning range VCO would have
issues. An OCXO with ppm or tenth ppm sort of tuning range … not so much.
Yes, it does depend on the phase noise level of your OCXO. If you are after something
with a phase noise level of < -160 dbc / Hz at 10 Hz then we are right back to talking
about a very high level of vibration compensation.
Regardless, as far as I understand it, the phase shift issue you refer to applies to fully analog loop filters. A digital control loop can account for and compensate the loop filter's transfer function, as far as I can recall from my control theory lectures.
Control loops don’t care if they are analog or digital. Delay / phase shift still does the
same thing. There is no magic that allows you to “go into what’s past” and eliminate
a delay.
Bob
Thanks and best regards,
Carsten
<220808_ZED-F9P_baseline_length_error_CCDF.png><220808_active_lpf_group_delay.png><220801_opa189_lpf_freq_response.png>
Hi Bob,
On 08.08.22 17:58, Bob kb8tq wrote:
Is something over $5K per unit / minimum order of a hundred “in budget” for this application?
No thanks :D
See attached CCDF for results. 90% is below 3 cm and 98% below 30 cm. Translated into propagation delays that's 98% below 1 ns. Since the F9P's RTK fixes are 4-dimensional (position + time), I'd assume that the F9T's multi-path induced time error should be proportional to the F9P's position error. Only measurements will tell whether or not that assumption turns out to be true.
Time error and position error are only somewhat related. The time error is very likley
to be worse that what you are guessing from the position.
How did you come to that conclusion? If you have some sources on that
topic, please share. I've skimmed through the potentially relevant
sections of [1,2] and couldn't find anything, but it's possible I missed
sth. ESA's navipedia has some information on time transfer techniques
[3], which specifies carrier phase timing uncertainty as <500 ps, based
on this paper [4]. None of the sources I've found consider time transfer
on the move.
AFAIK, determining accurate time at the GNSS receiver boils down to
correcting the received time by propagation delay (kinda like [5]) and
adequate multi-path filtering. Based on the receiver's accurate location
(via RTK) the range to the satellite and therefore the propagation delay
can be determined. For differential timing using a reference station,
most errors (sat. ephemerides, sat. clock offset and drift, atmospheric
distortion) simply cancel out. My use case requires only relative
synchronization within a confined area. The absolute time error compared
to TAI is irrelevant.
Admittedly, I'm just theorizing here. I will measure the ZED-F9Ts'
non-stationary performance and report back (in a couple of months).
Unless your oscillator is degraded in some way by this noise ( = it has a massive tuning
sensitivity ) there is no advantage to doing this. An octave tuning range VCO would have
issues. An OCXO with ppm or tenth ppm sort of tuning range … not so much.
Yes, it does depend on the phase noise level of your OCXO. If you are after something
with a phase noise level of < -160 dbc / Hz at 10 Hz then we are right back to talking
about a very high level of vibration compensation.
I haven't computed/simulated at which offset (if ever) my DAC's
unfiltered output noise becomes measurable over the OCXO's undisciplined
phase noise. My rationale was to low pass filter the DAC output as close
to the carrier as control time constants permit to minimize the overall
noise power fed to the OCXO. I still see no downside to this approach.
What's you suggestion? A higher cut off frequency (which)? No filter at all?
Control loops don’t care if they are analog or digital. Delay / phase shift still does the
same thing. There is no magic that allows you to “go into what’s past” and eliminate
a delay.
Absolutely, but that wasn't my point. Typical analog PLL ICs run their
phase detectors (PD) at high frequencies (e.g., 104 MHz for the
ADF4002). While some can operate the PD at a lower frequency, the only
(reasonable) way to get down to a few (k)Hz is the loop filter. However,
regardless of the loop filter bandwidth, the PLL will still try to steer
the oscillator at its full bandwidth. In combination with the loop
filter's phase response, this causes a knee in noise PSD, because the
charge pump's output signal has significant power spectral density in
the loop filter's transition band.
On the other hand, a DAC can generate an arbitrary signal with
negligible power in the filter's transition band. The required signal
bandwidth depends only on the time constant of the digitally implemented
control loop. With a 1PPS from the GNSS receiver, any time constant
below 1 s seems unrealistic. Of course, the filter's group delay limits
the responsiveness of the control loop, but this dead time can be
accounted for. That is what I meant with my previous remark.
Best regards,
Carsten
[1] "GNSS – Global Navigation Satellite Systems" by Hofmann-Wellenhof,
Lichtenegger, Wasle
[2] "Understanding GPS/GNSS" by Kaplan, Hegarty
[3]
https://gssc.esa.int/navipedia/index.php/GPS_Time_and_Frequency_Transfer_Techniques
[4] https://tf.nist.gov/general/pdf/1424.pdf
[5] https://gssc.esa.int/navipedia/index.php/Emission_Time_Computation
I've updated the schematic. Added an IMU (TDK InvenSense IIM-42652 on a
separate breakout board) and pushed the active low-pass filter cutoff
frequency to 10 Hz. Also preliminarily finished the layout. BOM is still
open, so maybe a few capacitor/resistor footprints will change (to
minimize assembly costs by picking parts without setup cost), but apart
from that I consider the prototype design finalized. Will let it sit for
a few days to review everything with some distance.
I don't want to flood your inboxes with attachments. You can find
updated schematic, layout, and 3D renderings in the EEVblog thread:
https://www.eevblog.com/forum/projects/gpsdognssdo-stm32g4-u-blox-zed-f9t-tdc7200/msg4351894/#msg4351894
Best regards,
Carsten
On 05.08.22 21:38, Carsten Andrich via time-nuts wrote:
Hello everyone,
back in April I asked about a 100 MHz GNSSDO for mobile use [0]. As
nothing COTS seemed to be available, I've since started developing a
prototype based. I finally – been busy with work – got the design to
sth. work sharing and am looking for feedback. The following is
cross-posted on the EEVblog forum [1]:
I'm in need of a GNSSDO for accurate time synchronization of moving
vehicles distributed over a few (dozen) square km. I've been
professionally using the James Miller (G3RUH) Ministd [2], Jackson
Labs LC_XO [3], and SRS FS740 [4], but none of these deliver
satisfactory results when used on the move. That's certainly not a
flaw of these devices, because presumably they were not designed with
a non-stationary use case in mind. Therefore, I decided to build a
suitable GNSSDO myself. This is not a low-cost project. Development
priorities are performance, simplicity, and value for money in that
order.
I have positive experience with the u-blox ZED-F9P RTK [5] GNSS
receivers. As the F9P can achieve <5cm position accuracy with RTK
correction data, its timing receiver sibling (ZED-F9T) should enable
sub-nanosecond timing accuracy. The F9T supports differential timing
[6] via the same correction data used for RTK positioning. I'm not
aware of any other GNSS timing receivers supporting this feature. The
F9T also exhibits excellent Allan deviation (~5e-11 @ 10s) [7].
Therefore, the F9T is the center piece of my design, relying on the
RCB-F9T [8] board for prototyping.
Design aspects/goals:
* ZED-F9T timing GNSS receiver with RTK correction data
* 10 MHz OCXO as local reference oscillator (special OCXOs with low
g-sensitivity for non-stationary use exist)
* TDC7200 for ~50 ps measurement of GNSS timepulse vs. OCXO
* STM32 32-bit timer capture (~6ns resolution) to resolve
aliasing/ambiguity of TDC measurement
* <10ns relative accuracy within 10 km radius while on the move
(preferably <1ns)
* stabilized pulse output derived from OCXO (not directly from GNSS
receiver)
* configurable pulse properties (not only 1PPS) with fine-tunable
delay (~200ps resolution via STM32G4x4 high resolution timers)
* integrated distribution amplifier for 10 MHz and 1PPS outputs
(capable of driving 50 Ohm loads)
* part and manufacturing costs preferably <500€ per device (excl. OCXO)
My architecture is inspired (among others) by Matthias Welwarsky's
"DIY GPSDO project w/ STM32, TDC7200" [9]. However, I hope to improve
on these aspects:
* Minimize digital processing of OCXO output. Feed 10 MHz directly to
TDC7200 without division via 74HC390 to minimize temperature
dependence [10].
* Only use low-jitter clock ICs (e.g., LMK1C110x for fanout). No
74-type components, which AFAIK do not have jitter or phase noise
specs.
* Active 1 Hz low-pass filter after tuning DAC to a) minimize noise
(from supply, voltage reference, and DAC) fed to OCXO control
voltage input and to b) enable finer than 16-bit tuning resolution
via PWM. Assuming a 2 ppm tuning range, 16 bit yields 30 ppt
frequency tuning resolution. At 10 seconds, that's already 300 ps,
which is higher than the TDC7200's ~50 ps resolution. Hence, a finer
tuning resolution may come in handy, of course depending on the
actual stability of OCXO and GNSS.
My next step is to build a prototype PCB to put my ideas to the test.
I've devised the preliminary architecture and put it into a schematic.
The layout is in progress.
I've attached the schematic and would appreciate constructive
feedback, prior to having it produced.
Thanks and best regards,
Carsten
[0]
https://febo.com/pipermail/time-nuts_lists.febo.com/2022-April/105583.html
[1]
https://www.eevblog.com/forum/projects/gpsdognssdo-stm32g4-u-blox-zed-f9t-tdc7200/
[2] http://www.jrmiller.online/projects/ministd/manual.pdf
[3] https://www.jackson-labs.com/index.php/products/lc_xo
[4] https://www.thinksrs.com/products/fs740.html
[5] https://en.wikipedia.org/wiki/Real-time_kinematic_positioning
[6]
https://content.u-blox.com/sites/default/files/ZED-F9T-00B_DataSheet_UBX-18053713.pdf#page=6
[7]
https://hamsci.org/sites/default/files/publications/2020_TAPR_DCC/N8UR_GPS_Evaluation_August2020.pdf#page=25
[8] https://www.u-blox.com/en/product/rcb-f9t-timing-board
[9]
https://www.eevblog.com/forum/projects/diy-gpsdo-project-w-stm32-tdc7200/
[10]
https://www.eevblog.com/forum/projects/diy-gpsdo-project-w-stm32-tdc7200/msg2921634/#msg2921634
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com