DIY GPSDO project w/ STM32, TDC7200

[thinkfat]

Thanks a lot for the encouraging words. The saving grace: I'll initially not need a lot of different messages. I just need to configure the receiver to output a 128PPS signal and then parse the TP messages as they come in for sawtooth correction. 

[iMo]

FYI - I've been using this lib:
https://github.com/loginov-rocks/UbxGps

This works without any library:

Code: [Select]

// setting NEO-7 1PPS freq
// an example only, provided as-is
// stm32duino on BluePill by iMo 01/2020

#define GPS_SERIAL  Serial1

// Send an UBLOX packet to the NEO receiver - change 1PPS to ppsfreq Hz
void ubloxsetPPS(uint32_t ppsfreq)
{
    // CFG-GNSS packet
    uint8_t packet[] = {
        0xB5, // sync char 1
        0x62, // sync char 2
        0x06, // class
        0x31, // id
        0x20, // length
        0x00, // length

        // LSB----->MSB

        0x00, 0x01,
        0x00, 0x00,
        0x0F, 0x00,               // antenna delay 15ns (3m)
        0x00, 0x00,               // RF group delay
        0x01, 0x00, 0x00, 0x00,   // 1Hz when not locked

       // 0x00, 0x1B, 0xB7, 0x00, // when locked 12MHz 1PPS example

        (ppsfreq & 0xFF),
        ((ppsfreq >> 8) & 0xFF),
        ((ppsfreq >> 16) & 0xFF),
        ((ppsfreq >> 24) & 0xFF),

        0x00, 0x00, 0x00, 0x80,   // duty cycle 50%
        0x00, 0x00, 0x00, 0x80,   // duty cycle 50%
        0x00, 0x00, 0x00, 0x00,   // user time-pulse delay
        0x6F, 0x00, 0x00, 0x00,   // config flags

        0x00, // CK_A dummy
        0x00  // CK_B dummy
    };

    sendUbxPacket_crc(packet, sizeof(packet));
}

// Send the packet specified to the receiver
void sendUbxPacket_crc(uint8_t *packet, uint8_t len)
{
    uint8_t ck_a = 0;
    uint8_t ck_b = 0;

    for (uint8_t i = 2; i < len-2; i++) {
        ck_a += packet[i];
        ck_b += ck_a;
    }

    packet[len-2] = ck_a;
    packet[len-1] = ck_b;

    for (uint8_t i = 0; i < len; i++) {
        GPS_SERIAL.write(packet[i]);
    }

}


[thinkfat]

FYI - I've been using this lib:
https://github.com/loginov-rocks/UbxGps

Eeek! No, thanks. That is hideous. Poking bytes into a C++ object with (char*). Nope, not on my watch. texaspyro's coding style is maybe a bit on the odd side, but at least he's sane.

This works without any library:

Code: [Select]

// setting NEO-7 1PPS freq
// an example only, provided as-is
// stm32duino on BluePill by iMo 01/2020

#define GPS_SERIAL  Serial1

// Send an UBLOX packet to the NEO receiver - change 1PPS to ppsfreq Hz
void ubloxsetPPS(uint32_t ppsfreq)
{
    // CFG-GNSS packet
    uint8_t packet[] = {
        0xB5, // sync char 1
        0x62, // sync char 2
        0x06, // class
        0x31, // id
        0x20, // length
        0x00, // length

        // LSB----->MSB

        0x00, 0x01,
        0x00, 0x00,
        0x0F, 0x00,               // antenna delay 15ns (3m)
        0x00, 0x00,               // RF group delay
        0x01, 0x00, 0x00, 0x00,   // 1Hz when not locked

       // 0x00, 0x1B, 0xB7, 0x00, // when locked 12MHz 1PPS example

        (ppsfreq & 0xFF),
        ((ppsfreq >> 8) & 0xFF),
        ((ppsfreq >> 16) & 0xFF),
        ((ppsfreq >> 24) & 0xFF),

        0x00, 0x00, 0x00, 0x80,   // duty cycle 50%
        0x00, 0x00, 0x00, 0x80,   // duty cycle 50%
        0x00, 0x00, 0x00, 0x00,   // user time-pulse delay
        0x6F, 0x00, 0x00, 0x00,   // config flags

        0x00, // CK_A dummy
        0x00  // CK_B dummy
    };

    sendUbxPacket_crc(packet, sizeof(packet));
}

// Send the packet specified to the receiver
void sendUbxPacket_crc(uint8_t *packet, uint8_t len)
{
    uint8_t ck_a = 0;
    uint8_t ck_b = 0;

    for (uint8_t i = 2; i < len-2; i++) {
        ck_a += packet[i];
        ck_b += ck_a;
    }

    packet[len-2] = ck_a;
    packet[len-1] = ck_b;

    for (uint8_t i = 0; i < len; i++) {
        GPS_SERIAL.write(packet[i]);
    }

}


MUCH better

[iMo]

Also mind the output 1PPS frequency with NEOx modules is not corrupted (jittery phase) only when

1PPS_freq = 48MHz/N, where N=4,5,6... (N is an integer).

That means 10MHz is crappy.

[thinkfat]

Stuff is coming together. I can switch the receiver to ublox binary mode, configure the PPS output and start a self-survey. PPS signal is nice and steep, somewhere in the region of <4ns rise time. Here ends what my scope can resolve. I can also parse a couple of common messages, like, clock, nav, tp, svin, status, etc. I think that's enough for now.

With the TP message I should be able to perform sawtooth correction, but then of course I can forget about the 128PPS averaging. I'll probably try both and post some data.

PS: not convinced that 128PPS is a good idea, I took a look with the scope and I see very frequent 20ns jumps from pulse to pulse.

[iMo]

The NEOs 1PPS is not jitter free. See Lars' thread - the peak to peak jitter with 1PPS (1Hz) is perhaps 50ns.

PS: With NEO's 1PPS output you may see two effects:
1. the "GPS" related jitter, up to 50ns p-p at 1Hz (or similar with 128Hz), the NEO-M8 datasheet says the timing pulse accuracy is 30ns RMS
2. the 1PPS "frequency divider" jitter, when the output frequency is set such the N is not an integer, ie. for 10MHz output freq the N=4.8

[thinkfat]

First real world measurements, logfile attached. The measurement data has not changed format, it's just intermixed with log messages from the ublox parser.
You can just filter out all lines starting with '#' to have the raw measurements.

Conditions:

• 10MHz from the Siglent wavegen. This instrument is externally clocked from a GPSDO.
• 128PPS from the Ublox M8T
• 128 cycle averaging done by the TDC7200

You can see from the temperature compensation data that there wasn't much going on, pretty much thermal equilibrium, no large swings at least.

The phase measurement data shows at least three components, small jitter on top of larger oszillations on top of a very significant 4500 or so second cycle. My interpretation is that the large 4500s cycle is the GPSDO at work, the small jitter is the TDC7200 granularity and the system phase noise (wavegen, squarer, ...), the larger oszillation is from the Ublox GPS module.

[thinkfat]

Doing a bit of processing, attached find the 3rd column filtered through a very steep 1/200Hz high-pass. This very much eliminates the influence of the GPSDO (I assumed the time constant is 200s). The standard deviation of the resulting signal is in the range of 2.9ns. I think that's roughly what one can expect from the Ublox receiver. Note that the measurement was done after the GPS entered "Hold" mode.

[iMo]

From the first data set the p-p is 13.8ns, it may fit into the M8T's "time pulse jitter +/- 11ns".
 

[thinkfat]

I'm currently doing another test run, this time with the Ublox doing 1PPS output. Not doing sawtooth correction, the pattern is clearly visible if you plot the raw data. I'm logging from cold start of the system to have a comparison between the receiver in 3D mode while performing the self-survey, and in HOLD mode after the survey completes.

PS: decided to stop the test and implement sawtooth correction instead, I'm anyway logging the uncorrected ToF and so the difference will become immediately apparent.
PPS: see attached plot:

top left, uncorrected tof
bottom left, tof corrected for temperature and quantization error
top right, temperature correction in picoseconds
bottom right, internal temperature sensor of the STM32.

[iMo]

How did you correct for the quantization error?

PS: FYI - a guy with a hydrogen maser in his bedroom

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

[thinkfat]

How did you correct for the quantization error?

That's actually pretty simple. The TP message from the receiver tells you the quantization error in picoseconds for the next timepulse. So I just store the "qErr" and when the next 1PPS measurement is completed, I just subtract the stored value from the measurement.

[texaspyro]

That's actually pretty simple. The TP message from the receiver tells you the quantization error in picoseconds for the next timepulse. So I just store the "qErr" and when the next 1PPS measurement is completed, I just subtract the stored value from the measurement.

Well, that is not alway true.  Depending upon the receiver you either add/subtract the value to the previous/current/next PPS/phase measurement...  that's like 12 different possibilities.  Figuring out what the proper combination to use can be a pain in the ass.  Some wrong combinations can look a lot like the proper one.

[thinkfat]

That's actually pretty simple. The TP message from the receiver tells you the quantization error in picoseconds for the next timepulse. So I just store the "qErr" and when the next 1PPS measurement is completed, I just subtract the stored value from the measurement.

Well, that is not alway true.  Depending upon the receiver you either add/subtract the value to the previous/current/next PPS/phase measurement...  that's like 12 different possibilities.  Figuring out what the proper combination to use can be a pain in the ass.  Some wrong combinations can look a lot like the proper one.

The relationship between the TP message and the time pulse is documented for the M8T.

[texaspyro]

The relationship between the TP message and the time pulse is documented for the M8T.

It's one of few that document it (or document it properly).

[thinkfat]

The relationship between the TP message and the time pulse is documented for the M8T.

It's one of few that document it (or document it properly).

Yep, their integration documents and firmware manual are really well done. I was able to design the small breakout board for the M8T looking into just one PDF and it worked right from the first revision. Moreover, the firmware behaves quite exactly as described in the documentation, which is a rare thing, too.

Also, I'm not trying to reimplement LadyHeather, for me it's enough if the thing works with just one particular GPS.

[iMo]

Would be interesting to see (after you finalize your GPSDO) how the quant_err correction helps when you do 500-1000secs PID loop averaging (ie. MADEV with and without).
It is my understanding the "sawtooth correction" and the "quantization error correction" is the same.

[thinkfat]

Would be interesting to see (after you finalize your GPSDO) how the quant_err correction helps when you do 500-1000secs PID loop averaging (ie. MADEV with and without).
It is my understanding the "sawtooth correction" and the "quantization error correction" is the same.

Yep, that's also my understanding. The "quantization error" reported by the receiver is the offset in picoseconds of the TIMEPULSE signal, which is aligned to the best fitting clock edge of the internal clock, to the true time mark calculated by the receiver. The "sawtooth" is the visual pattern that you get in the phase measurements if you compare the TIMEPULSE signal to a more stable reference source.

The expression of the quantization error in picoseconds is especially convenient since the correction then becomes a simple addition. You just need to figure out the sign correctly, i.e. understand what the receiver is actually reporting. In the ublox case, a negative qErr means the true timepulse is abs(qErr) earlier than the TIMEPULSE signal, that means you need to add abs(qErr) to the measurement. In other words, you just add -qErr to the measurement and you're set.

Anyway if you get the sign wrong, the effect is immediately visible in that the "sawtooth" gets much, much more pronounced instead of it disappearing.

[thinkfat]

Another interesting dataset, this is the future oscillator for the GPSDO, one of my LPRO-101 Rb standards.

As expected, a completely different picture, this is a free-running oscillator against the 1PPS signal from the Ublox receiver. The up- and down movement from the previous data sets, that were still using the GPSDO as the reference are gone. The measurements were started as soon as the Rb steering loop locked, so you can see it warming up and the curve gradually become more and more linear. It looks like there is still a slight curve after 12000 seconds.

[iMo]

It would drift 1 second in around 800 years

[thinkfat]

The result of one night of data logged. The mdev graph suggests I will be able to run with a TC of around 4000 seconds or so, if I'm not mistaken.

[iMo]

How are you going to control the LPRO's freq? Via EXT C-Field input? What is the LPRO's gain (in Hz/Volt)?

[thinkfat]

How are you going to control the LPRO's freq? Via EXT C-Field input? What is the LPRO's gain (in Hz/Volt)?

Yes, external C-Field input. The LPRO-101 has a trimming range of at least 3 ppb over 5V, or 0.006Hz/V. "At least" because I only have a vague statement in the LPRO user manual about the trimming range:

3.6.1 Greater Than ± 1E-9 Internal or External Control
The C-field control circuitry is designed to independently sum the contributions of the C-field
control potentiometer and the external C-field control signal. Each control signal gives greater than
±1.5E-9 frequency offset correction capability.
The external C-field control circuitry is designed so that with no voltage applied at J1-7, the
voltage will self bias to mid-range, or 2.5V.

If you look at the layout, the whole PCB is supposed to plug directly onto the front connector of the LPRO, running both from a single 24V power supply.

[thinkfat]

Alright, almost roasted the board. I hooked the reset line of the DAC up to the wrong power rail, VDDA instead of VDD, and the DAC pulled VDD up to over 4V. That could have been a costly mistake, but luckily everything still works. I can talk to the DAC and set the output level. Next will be the Opamp, and then I will connect the LPRO and can finally start implementing the actual control loop.

[iMo]

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!