DIY GPSDO project w/ STM32, TDC7200

[bingo600]

http://www.efos3.com/index.html

Magnus just got a "home maser"  too 

/Bingo

[thinkfat]

When printing the data into the .csv file put the #ublox messages at the end of a line such we not need to mess with excel's filter
Fingers crossed with your first lock!

I keep forgetting that you are not blessed by the powers of 'grep' 😁

[thinkfat]

It locks! 

Took a while of fiddling with Lars' control loop code because my TIC delivers picoseconds rather than nanoseconds. I've thrown out a lot of code, too, the whole linearization stuff for the ADC TIC is not needed, and most of the code for changing and saving parameters, warm up handling, hold mode, temperature compensation etc. I'll have to reimplement later when I do the console command interface. It's really stripped down to the bare minimum PI loop, DAC handling.

And immediately I start to wonder about the merit of having a PLL in a design that will not output a 1PPS signal and thus has no requirement for a fixed phase relation to the GPS, let alone UTC. Getting a phase lock is much more demanding that trimming the frequency so that the oscillator stops drifting. Especially since the input to the control loop is a phase error while the output is a frequency correction.

[iMo]

The oscillator stops drifting when phase error is constant. How did you define phase lock?

[thinkfat]

The oscillator stops drifting when phase error is constant. How did you define phase lock?

If you look at Lars' code, phase lock is defined by means of "TIC_Offset", with "TIC_Value - TIC_Offset" being the error input for the P_term of the PI loop. This steers the phase of the input towards a specific TIC_Value, i.e. towards a specific phase difference between the 1PPS and the oscillator signal. That's what I'd call "phase lock".

An alternative could be to do mainly frequency locking, i.e. steering the "diff_ns", which describes the frequency error, towards 0.

[iMo]

So your tic_offset is 1000ns and tic_value is say from 500ns to 1500ns. Thus "phase lock" will happen when abs(tic_value-tic_offset)<epsilon?

[thinkfat]

So your tic_offset is 1000ns and tic_value is say from 500ns to 1500ns. Thus "phase lock" will happen when abs(tic_value-tic_offset)<epsilon?

Yep, that's pretty much it. Lars' code defines something like a "hunting" mode, during which there is no filtering applied to tic_value. This makes the loop very reactive and quickly steers it towards tic_offset, however the result is a lof of DAC movement. The switchover to "locked" mode is defined by "abs(tic_value-tic_offset)<epsilon" for a certain time (5 times TC). But the only thing that changes when a "lock" is achieved is the filter constant for tic_value, which is then set to e.g. TC/2. This slows down the loop response and instead of violent frequency changes you get slow up and down movements.

However, the target is always to minimize "tic_value - tic_offset". This isn't really productive if you only care about frequency stability. A FLL should have an advantage here.

[iMo]

Does the NeoM8T allow to set 10 messages per second (and 10Hz 1PPS) where you get the sawtooth correction data as well?
FLL means you are measuring the frequency and adjust the DAC. How would you measure frequency with say 10uHz resolution?

[thinkfat]

Frequency is the time derivative of phase. The TIC gives me phase difference in picoseconds and "phase[t] - phase[t-1]" is the frequency difference in ps/s, if I'm not mistaken.

So if I use, instead of "tic_value - tic_offset", "diff_ns", or rather "diff_ps" in my case, as the error value in the PI loop, I should get a FLL instead of a PLL.

[thinkfat]

Dataset of around 44000 measurements, including the "hunting" phase at the beginning. Lock achieved at about 5000s, usable values start at 6000s, I think.

Mostly debug relevant output, I am still debugging the PI loop.

TC: 1000s

First column: raw TOF from the TDC in picoseconds
2nd column: filtered TOF, scaled to 1ns. Take this with a grain of salt, the output is through a quite crude float-to-string function and probably has some rounding error.
3rd column: diff_ps, low-pass filtered with a time constant of 16 seconds
4th column: raw DAC values
5th column: lock counter, starts counting when the locking criteria are met. When it reaches 5000, the TOF filter time constant is set to 500.

DAC LSB: 4e-9 / 65536

Note that I didn't yet qualify the true pulling range of the LPRO. I'm just assuming 4e-9, could be something else, but it's in the same ballpark.

[iMo]

Using only 200p-p lsb units off your 16bit DAC. Boring
MADEV 2.2e-13 at 10k seconds.

Your competitor
PS: they use an additional "ultra low noise 10MHz Crystal Filter Oscillator".

[thinkfat]

Frequency is the time derivative of phase. The TIC gives me phase difference in picoseconds and "phase[t] - phase[t-1]" is the frequency difference in ps/s, if I'm not mistaken.

So if I use, instead of "tic_value - tic_offset", "diff_ns", or rather "diff_ps" in my case, as the error value in the PI loop, I should get a FLL instead of a PLL.

Thought about the idea some more - ain't gonna work. Yes, I get the frequency difference by looking at the phase derivative, but I can only measure phase with finite precision and also there's numeric limitations. It's impossible to lock the frequency by just looking at "diff_ps". It will always drift. I need the phase lock as am anchor point.

However, I can still use diff_ps as a differential term in the control loop. I'm going to experiment with that (PID instead of PI controller).

[iMo]

I think diff_ps is too noisy to be useful as the D in the PID.

[thinkfat]

I think diff_ps is too noisy to be useful as the D in the PID.

Indeed. I think it'd be better to go for a "classic" PID approach where D is the error derivative. It might also be interesting to work with different gains for the D term, to help it converge faster while it acquires lock.

I also understood now the reason why it converges so slowly towards the phase setpoint: For convergence, it must first eliminate the frequency offset, i.e. it must first center the DAC around the proper setting. But since the control loop doesn't "know" that, it just keeps steering phase towards 1µs. But to align the frequency, it has to allow for a large phase shift first. Instead if constantly tries to adjust the phase towards the setpoint. It will eventually reach the setpoint, but it takes quite a while, especially for longer TC.

[thinkfat]

The attached graphs are to illustrate the behavior. Look at especially the TIC values, diff_ns and Raw DAC graphs

The DAC starts out at around 33200, while the correct setting for frequency alignment is around 32200. The TIC graph consequently goes into a downward slope caused by the frequency offset.

The control loop tries to counter that movement, notice all the small upwards movements back towards the setpoint. The system is following at first, but since the DAC excursions point away from the "good" value, it goes back into a downward trend away from the setpoint again. This continues until the DAC output finally reaches the "good" value. From this point on, frequency is aligned and you will see DAC excursions up and down while the phase is shifting slowly towards 1µs.

This could be improved by introducing a "frequency search" at the beginning, with the control loop only looking at diff_ns to bring the DAC near frequency alignment. Once diff_ns (filtered, of course) stays within a certain range, strategy could be switched to phase locking.

[iMo]

There is the PII loop as well, it could be it fits this scenario better. I have the C source somewhere, but it basically integrates twice in series.

PS: aka PIID, or PI2D

[iMo]

I would not mimic Lars' code with your design. You may do all in double precision to be on the safe side with math. Also Lars is using a low pass in the DAC with much lower BW (yours DAC low pass is 147Hz, btw). Start with a PI regulator off a standard library and tune it for your system. It could be you have to smooth the TIC measurements first, and then pass the result to the PI loop (with say 10-100secs period).

PS: As I wrote above your NEO can output messages at 10Hz afaik, with 10Hz 1PPS you may achieve better statistics, imho.

PPS: from 5000secs up in your above data the DAC changes are max 1LSB, it could be the 16bit DAC resolution is still too "coarse"..

[thinkfat]

I would not mimic Lars' code with your design. You may do all in double precision to be on the safe side with math. Also Lars is using a low pass in the DAC with much lower BW (yours DAC low pass is 147Hz, btw). Start with a PI regulator off a standard library and tune it for your system. It could be you have to smooth the TIC measurements first, and then pass the result to the PI loop (with say 10-100secs period). With average 40ps/sec drift of your rubidium the DAC's value changes should be rather smallish too.

PS: As I wrote above your NEO outputs data at 10Hz afaik, with 10Hz 1PPS you may achieve better statistics, imho.

That's exactly what I'm doing now. For the first test I have just taken Lars' PI loop and also the averaging filters, but I noticed quickly that there are e.g. terms in the averaging filter that didn't seem to have much merit, and then I looked at the PI loop computation itself and it seemed a little odd and it was a bit hard to match it with what you get from control theory textbooks. Frankly, I didn't understand it and since Lars' is no longer with us I cannot ask. Not a good starting point for experiments.

Now I've implemented a "textbook" PID control loop, using this formula from the wikipedia page:


It's nice because I get to set the time constant for the integrator (T_i) directly in seconds. Now I need to figure out a proper gain and boundaries for the anti wind-up of the integrator. This type of controller needs a bias term, which I have set to the middle of the DAC range for now, and the integrator is what adjust for frequency offset. So the anti wind-up has to be chosen with some sense to not have a huge overshoot if you start from a large phase error and at the same time deal with LPRO's that are not well calibrated. My own one I have carefully set to 10MHz with the C-Field bias pot, looks like I'm still a little off from center position but it's not a huge amount and the integrator is coping with it.

I've also switched to using "double" instead of "float" and the "remainder" trick.

PS: if the DAC range is too coarse, I can solve that in the analog output stage. I have a second OP that I could use to create a virtual ground to bias the output amplifier. I've meanwhile checked the pull range of the LPRO, it's indeed 4ppb rather than the 3ppb advertised in the user manual.

PPS: DAC low-pass filter - there's a 100 / 10nF RC low-pass at the OP output. That matches with the 147Hz.

[iMo]

I have a second OP that I could use to create a virtual ground to bias the output amplifier.

You may offset the middle of the DAC around the expected 10MHz, and set the opamp gain to -10 for example, thus you get +/- 0.25V around a set point, with 16bit resolution (7.6uV per LSB, the area where TC and noise start to matter, btw).

PPS: DAC low-pass filter - there's a 100 / 10nF RC low-pass at the OP output. That matches with the 147Hz.

Look at the above simulation (off the LPRO EXT C input schematics), the 147Hz comes rather from the internal RC stuff.

[thinkfat]

I have a second OP that I could use to create a virtual ground to bias the output amplifier.

You may offset the middle of the DAC around the expected 10MHz, and set the opamp gain to -10 for example, thus you get +/- 0.25V around a set point, with 16bit resolution (7.6uV per LSB, the area where TC and noise start to matter, btw).

PPS: DAC low-pass filter - there's a 100 / 10nF RC low-pass at the OP output. That matches with the 147Hz.

Look at the above simulation (off the LPRO EXT C input schematics), the 147Hz comes rather from the internal RC stuff.

Hm. The DAC LSB is, as I mentioned, 4ppb / 65536, that's about 6e-14, or 60ppq. That's the minimum disturbance it can cause. It's also roughly 76µV in the current setup. Should I really worry? I'd say there are other disturbance sources that are in the same ballpark. Not sure the overall noise level of the whole thing justifies that change.

[thinkfat]

I have a second OP that I could use to create a virtual ground to bias the output amplifier.

You may offset the middle of the DAC around the expected 10MHz, and set the opamp gain to -10 for example, thus you get +/- 0.25V around a set point, with 16bit resolution (7.6uV per LSB, the area where TC and noise start to matter, btw).

PPS: DAC low-pass filter - there's a 100 / 10nF RC low-pass at the OP output. That matches with the 147Hz.

Look at the above simulation (off the LPRO EXT C input schematics), the 147Hz comes rather from the internal RC stuff.

Hm. The DAC LSB is, as I mentioned, 4ppb / 65536, that's about 6e-14, or 60ppq. That's the minimum disturbance it can cause. It's also roughly 76µV in the current setup. Should I really worry? I'd say there are other disturbance sources that are in the same ballpark. Not sure the overall noise level of the whole thing justifies that change.

I think I've worked all the necessary corrections into the hardware design now. The layout is done, I'll launch the PCB soon. I've added provisions to limit the DAC pulling range, too. Thinking about it, I did put a lot of effort into getting a clean output, with separate analog ground, point-of-load regulators for the DAC and the output amplifier etc. It'd be a shame to stop there without at least providing means to tune the performance.

Another aspect I've been working on is the control loop. I've been reading up on PLL design and especially on using a PID controller for a PLL. One interesting aspect is that the models always contain a frequency component in the error term. So I'm experimenting with using the diff_ps (of course filtered) as an additional input. Not in the sense of a derivative term, but when calculating the error input. It definitely helps the loop converge faster, at the same time it adds some short-term fluctuations which mess a little with the Sigma for small Tau (1Hz).

Man, there are really a lot of knobs to twiddle. It's a neverending game.

[iMo]

What kind of low-pass filtering of the TIC output do you use?

[thinkfat]

What kind of low-pass filtering of the TIC output do you use?

Sliding window average, I think. I've more or less reused Lars' code here. In pseudo-C it is:
tic_filtered += (tic_measured * time_constant - tic_filtered) / time_constant
It's updated with every new measurement, once per second. tic_filtered is scaled by time_constant, preserving the bits added by the averaging.
time_constant is in the 100 seconds range.

[iMo]

tic_filtered += (tic_measured * time_constant - tic_filtered) / time_constant

That is somehow modified EMA (exp moving average):

tic_filtered = tic_filtered + alpha * (tic_measured - tic_filtered),

alpha = 1.0 - exp(-1.0/fs/tau), where "fs" is the sampling frequency [Hz], and "tau" is the time constant [sec].

You may get "alpha" for a specific -3db corner frequency "f3db":

omega3db = f3db * pi/(fs/2),

alpha = cos(omega3db) - 1 + sqrt(cos(omega3db)^2 - 4*cos(omega3db) + 3)

https://dsp.stackexchange.com/questions/40462/exponential-moving-average-cut-off-frequency

[thinkfat]

It's a MMA, if you look at the step response. Wikipedia says MMA is EMA with alpha = 1/N.
See this octave/matlab script:

Code: [Select]

#
# Step response of Lars' low-pass filter
#

clf;
format long;
hold off;

tc = 10;
acc = 0;

# lars
for i=1:5*tc
acc = acc + (1 * tc - acc) / tc;
y(i) = acc / tc;
end

# mma
acc = 0;
for i=1:5*tc
acc = ( acc * (tc-1) + 1) / tc;
y2(i) = acc;
end

plot(y);
hold on;
plot(y2);
plot(y2-y);
grid on;