[time-nuts] Re: GPSDO/GNSSDO project: STM32G4 + u-blox ZED-F9T + TDC7200

[Carsten Andrich]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 220808_ZED-F9P_baseline_length_error_CCDF.png
Type: image/png
Size: 36832 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20220808/b51ab371/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 220808_active_lpf_group_delay.png
Type: image/png
Size: 29238 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20220808/b51ab371/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 220801_opa189_lpf_freq_response.png
Type: image/png
Size: 102598 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20220808/b51ab371/attachment-0002.png>