DIY GPSDO project w/ STM32, TDC7200

[iMo]

Lars is doing with integers - therefore the MMA. You may do with simple EMA and double precision.
PS: I would try with cascading EMAs - two EMAs cascaded with shorter tau could have better effect than a single EMA with longer tau.
Also a rolling median works nice for eliminating outliers (in TIC output for example).

[thinkfat]

Some more data from yesterday.

integrator time constant: 4000s

First column: raw TOF from the TDC in picoseconds
2nd column: filtered TOF, scaled to 1ns.
3rd column: diff_ps, low-pass filtered with a time constant of 120 seconds (Lars' MMA)
4th column: raw DAC values
5th column: Smoothed DAC, Lars' MMA with 64 seconds time constant
6th column: P_term of the PI loop
7th column: I_term of the PI loop
8th column: lock counter, starts counting when the locking criteria are met.
9th column: loop state, 2 means "locked"

[thinkfat]

I've been doing some work on the software, mainly implementing the ideas I had floating in my head around improving the startup time until locking. I've come back to using the frequency drift information in diff_ps to first find a low drift DAC value for the PI loop to start from. So there's a first state in which a coarse frequency search happens until the drift is within a certain margin for 240 seconds.

This creates a pretty hefty offset in the phase error, so after finding a suitable zero state, it very aggressively steers the phase error down to zero, mainly by setting the loop gain very, very high. It's not actually "bang-bang", but it comes close for large phase errors. The main goal in this state is to allow the integrator of the PI loop to center the DAC more finely around the zero-drift value. If the phase error is small enough for an extended amount of time, the control loop moves to "locked" state, which sets the gain back to normal and switches to a larger filter time constant for the TIC measurements.

The advantage is mainly a faster time-to-lock and also, since the DAC is already well biased when the loop enters lock state, there's less initial turbulence and the system is usable more quickly.

I'll post data as soon as I can gather enough measurements.

[thinkfat]

Does the NeoM8T allow to set 10 messages per second (and 10Hz 1PPS) where you get the sawtooth correction data as well?

I've tried with 10Hz measurement rate and 10PPS. I loose coherence between the TP message and the 10PPS pulse, it seems. I've tried increasing the baud rate to the maximum the M8T supports, but I still get huge outliers. 5Hz seems to work fine, though.

[thinkfat]

There is an interesting regularity in the data. Every 4000 seconds or so, the phase jumps by 10ns. At first I though it's some GPS effect, but 10ns is suspiciously one 10MHz clock period. The TDC gets a 500kHz signal derived from the 10MHz clock, which has a much longer period, but of course it gets the same 10MHz as a reference clock for its cycle counter.

Any idea about how to counter that? It causes some unrest in the regulation because the control loop will of course try to reach 1µs phase offset again.

It is what limits the stability in the MDEV graph to around 2.5e-12 or thereabouts, for Tau=2000s.

[iMo]

There is an interesting regularity in the data. Every 4000 seconds or so, the phase jumps by 10ns. At first I though it's some GPS effect, but 10ns is suspiciously one 10MHz clock period.

10ns is period of 100MHz.

[thinkfat]

There is an interesting regularity in the data. Every 4000 seconds or so, the phase jumps by 10ns. At first I though it's some GPS effect, but 10ns is suspiciously one 10MHz clock period.

10ns is period of 100MHz.

 

[iMo]

Could it be math? Rounding? More than 15digits precision?
I would get rid of any integer math. Only double precision (15digits only).
Sometimes 64bit integer math is required, ie. (32bit * 32bit) / 32bit is not the same as 32bit * (32bit / 32bit) , etc.

[thinkfat]

Could it be math? Rounding? More than 15digits precision?
I would get rid of any integer math. Only double precision (15digits only).
Sometimes 64bit integer math is required, ie. (32bit * 32bit) / 32bit is not the same as 32bit * (32bit / 32bit) , etc.

I'll take a look at the TDC library again. They're doing some scaling tricks with shifting integers up and down to do fixed-point math (Q44.20). You mentioned though, you've used this library already. My own code is entirely converted to floating point now. I do use some "float", though. I should take a closer look and maybe switch everything to "double".

[iMo]

I was using the 7200 lib in a pretty noisy setup. Cannot confirm it works 100%.
Your setup is much better so you may discover even quite subtle bugs.
Make a version with double (55ps is well within 15digits) with straight datasheet math and compare against the integer math.
What is the clock of your stm32?

[thinkfat]

What is the clock of your stm32?

48MHz. Should be plenty MIPS.

[thinkfat]

I've meanwhile ordered a couple of OCXOs. The next project, which I have already started in the background, will be a GPSDO cape for the Beaglebone Black. Could be quite nice to run visualization directly on the platform, Lady Heather style.

[bingo600]

The next project, which I have already started in the background, will be a GPSDO cape for the Beaglebone Black. Could be quite nice to run visualization directly on the platform, Lady Heather style.

Why a BBB , and not a RasPi / Odroid or ??
Are you planning to use the PRU's for some realtime macic ?? 

/Bingo

[thinkfat]

I think I understand Lars' PI loop now. It's not weird, it's actually a quite clever optimization, though I'm not sure if he didn't make a mistake somewhere with scaling.

This is a standard PI computation in pseudo-C (loop time 1 second):

Code: [Select]

error = target - measurement;
Integrator += error;
P = error;
I = Integrator / TimeConstant;
dac_out = bias + ( P + I ) * gain;

The multiplication with gain is what scales the PI result to DAC units, bias is in DAC units by definition.

Now, Integrator and bias are the same thing and bias can be in fact become the integrator, by adding the following code after each loop:

Code: [Select]

bias += Integrator * gain / TimeConstant;
Integrator = 0;

So, after each loop you move the content of the integrator into bias and reset it to 0. Now, of course Integrator now doesn't sum anything any more, so, logically, this becomes:

Code: [Select]

error = target - measurement;
P = error;
I = error / TimeConstant;
dac_out = bias + ( P + I ) * gain;
bias += I * gain;

Now, dac_out is of course:

Code: [Select]

dac_out = bias + P * gain + I * gain;

That means you can rewrite the loop as follows:

Code: [Select]

error = target - measurement;
P = error * gain;
I = P / TimeConstant;
dac_out = bias + P + I;
bias += I;

And a final, clever optimization brings us to Lars' PI loop:

Code: [Select]

error = target - measurement;
P = error * gain;
I = P / TimeConstant;
bias += I;
dac_out = bias + P;

Really, Lars' was quite a smart guy.

PS: no, there's no scaling error in Lars' code.
PS2: edited for clarity

[thinkfat]

The next project, which I have already started in the background, will be a GPSDO cape for the Beaglebone Black. Could be quite nice to run visualization directly on the platform, Lady Heather style.

Why a BBB , and not a RasPi / Odroid or ??
Are you planning to use the PRU's for some realtime macic ?? 

/Bingo

No plans for the PRU, I just don't think it needs a power house (literally, the thing runs _hot_) like the RasPi to run a program that an STM32 can easily cope with. An ARM Cortex-A8 at 800MHz is plenty oversized already, and much more power conservative than a quad core 64bit A53.

[thinkfat]

Could it be math? Rounding? More than 15digits precision?
I would get rid of any integer math. Only double precision (15digits only).
Sometimes 64bit integer math is required, ie. (32bit * 32bit) / 32bit is not the same as 32bit * (32bit / 32bit) , etc.

I think I found something:


The pattern here looks suspicious. I think there's a numerical problem in the filtering of the raw DAC values. I've disconnected the temperature compensation for now to check if the effect goes away.

It's a MMA implemented in recursive form:

Code: [Select]

temp_filt = (31 * temp_filt + temp) / 32

temp_filt is just a 32bit signed int. I bet there's something overflowing, not properly rounding, something.

[thinkfat]

I'm probably looking at an environmental effect. During the night, without any disturbance, after the room had cooled, no more events. When I entered the room in the morning, I could immediately see a disturbance in the temperature sensor plot. Shortly after, the amplitude of DAC movement increased. The temperature sensor was only recorded without compensation being applied.

PS: the internal temperature sensor of the STM32 is rubbish. It is way too noisy and shows the power consumption of the chip more than anything else. I'm adding an MCP9800 to the new board.

[thinkfat]

Alright. Rev2 boards are go. I ordered 3 from Aisler, and decided to get adventurous on another two: I'll be trying JLCPCBs PCBA service. Of course they don't stock the majority of the parts I want, but they will assemble most of the passives, the STM32 and some SOT-23 diodes. Also, the TCL2272. I'll have to assemble the rest myself, they don't have any TSOP or MSOP parts in their library at all. I figure they lack the precision to place those?

[thinkfat]

plus

= 

PS: What I meant to say is, it doesn't make sense to do any performance evaluation or look for bugs in the software with this rag-tag setup. It's just too susceptible to all forms of disturbance. The light bulb is one of those LED filament lamps. There's not much in it electronically, but it seems to radiate quite a bit of noise at 100Hz, which is happily picked up by the wiring. I noticed a huge dip in phase error when I switched it on. Also, I noticed that the regulator output is way more quiet when nobody is in the room. But it's not temperature - there is almost no sign of any temperature dependence in the phase movement. But whenever I'm in the room, so is my smartphone...

[thinkfat]

So far, so good, however the next headscratcher is right around the corner. When I set the 1PPS input to an actual 1 second pulse signal, I get 4 clusters, spaced exactly 500ns. Confirmed with the scope, the signals are not properly locked. The phase shifts exactly 90 degrees every second. Might be some peculiarity of the instrument itself. I'll investigate that. I wanted to update the software of the Siglent anyway.

While waiting for the PCBs to arrive, I was meanwhile able to resolve this issue: Apparently, you need to manually sync the two channels. On the SDG2042X this is done through "Utility -> Output Setup -> EqPhase". After selecting this, the two channels are in phase.

EqPhase
Press Utility → Output Setup → EqPhase to align the phases of CH1 and CH2.
Choosing the menu will re-configure two channels and enable the generator to
output with specified frequency and start phase. For two signals whose
frequencies are the same or a multiple thereof, this operation will align their
phases.

[thinkfat]

The Rev2 PCBs arrived before the weekend and I've started populating the different sections. So far, the input circuit with reversed-polarity and overvoltage protection checks out OK and I've populated and tuned the sine-to-square circuitry.

Looks good so far, though probing the hot end of the inductor turned out to be a little difficult, the 1-2pF probe capacitance is enough to detune the tank. I ended up probing it indirectly, by reducing the input signal until it stopped working and then tuning the tank circuit until it worked again. I get a nice 50% duty cycle square wave from a 1Vpp sine input. I chose a fixed 0805-sized inductor with Q=75, seems to work out OK.

Tiny mishap: I changed the footprint of the 74AC04 to TSSOP-14 and forgot to order them. But I managed to fit the previous SSOP-14 version onto the board with some fiddling.

On the software side I spent some time working on the command interface and overall cleaning up. I'm running out of flash memory, though. I had to reimplement several standard functions like "strtod" because their library equivalents pull in waay to much stuff that isn't needed. Using double precision floating point math takes its toll, too.

[iMo]

I've been working with pic32MZEF these days - double precision FPU and 512kB sram, 2MB flash, 200MHz - just an idea for your 3rd board revision 
https://majenko.co.uk/product/chipkit-pro-mz

PS: another way how to tune sensitive LC circuits is to make a small "sensing coil", say 2-3turns 15-20mm dia. It loads the LC less than a direct coupling with a capacitor. And no problems with grounding. Keep 2-3cm off the LC.

[thinkfat]

I have some hope that I don't need to make another revision

But we know, in war truth dies first and in crisis, hope dies last 

[thinkfat]

OK, some first results with the new design: The input squarer is giving me a bit of a headache right now. The duty cycle of the output varies a lot with the input signal level. Not sure how much this affects the TDC, but the recommended duty cycle for the reference clock is 50%. I have more like, 60% at the moment. Apart from that it seems to behave well.

Schematic for the Sin2Square attached. I'm wondering if I should maybe change R15/R12 to something smaller, 10k maybe.

[iMo]

I would use the R6=50-100ohm as I recommended in past. And remove R14.
PS: the choice of the inductor is important. In ltpsice lib I can see 0805 10uH with 2ohm series and 980ohm parallel eq resistance. That would not work. On the other hand there is a 1210 one with 0.5ohm series and 19k parallel eq. resistance which simulates nice (and it will work fine). With properly tuned LC (and say 1Vpp input) you have to see "almost squared" rail-rail signal at the input of the HC14.