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

[Bob kb8tq]

Hi

> On Aug 8, 2022, at 5:39 AM, Carsten Andrich <carsten.andrich at 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>