Time stamping with GPS 1PPS and FPGA

[kazam]

Hi,

My application requires me to time stamp messages with accurate UTC time. Required accuracy is +/- 30ns. Payload is handled by an FPGA and then put in a FIFO for further processing together with the time stamp.
The local oscillator on the PCB is a 20MHz +/-25ppm crystal.
There is also a GPS receiver based on the MediaTek MT3333 chipset which claims 10ns RMS error on the 1PPS signal:
http://www.gtop-tech.com/product-detail.php?id=7

Right now this is done in an naive way, the 1PPS positive flank resets a counter in the FPGA that runs at 40MHz. I get too much jitter though, roughly 200ns.

So my thought is to have a portion of the FPGA run at 100MHz and have a digital PLL align with the 1PPS similar to this:
https://www.fpgarelated.com/showarticle/991.php

I also read this paper which seemed relevant:
https://www.researchgate.net/publication/4283871_A_Digital_Circuit_for_Jitter_Reduction_of_GPS-disciplined_1-pps_Synchronization_Signals

Any thoughts on this?

/K

[Andreas]

Hello,

I think the experts for this question are more on the time-nuts forum.

https://www.febo.com/pipermail/time-nuts/

with best regards

Andreas

[kazam]

Very interesting stuff, thank you.

Yes, I think it's likely that the GPS has it's own granularity due to some internal clock frequency.

But as I understand it a TDC won't solve that problem, it's just a way to give a binary representation of the time delay between two pulse with very high resolution. I need to actually generate my own 100MHz reference clock and then synchronize this with the 1PPS "on average" to even out that sawtooth pattern. I guess the Nutt method mentioned in one of your links could be used to measure, very accurately, the time between two 1PPS pulses and then this in turn could be the input to a DPLL FPGA block.

I will have to investigate further.

[hamster_nz]

Very interesting stuff, thank you.

Yes, I think it's likely that the GPS has it's own granularity due to some internal clock frequency.

But as I understand it a TDC won't solve that problem, it's just a way to give a binary representation of the time delay between two pulse with very high resolution. I need to actually generate my own 100MHz reference clock and then synchronize this with the 1PPS "on average" to even out that sawtooth pattern. I guess the Nutt method mentioned in one of your links could be used to measure, very accurately, the time between two 1PPS pulses and then this in turn could be the input to a DPLL FPGA block.

I will have to investigate further.

If you want a hand at all, I've got PmodGPS and a few FPGA boards around, and am quite interested in the topic.

Unless you are using complex and/or underhanded tricks (like crawling the phase of a PLL) you won't be able to generate a 100MHz reference clock, but you could make a 100MHz phase accumulator based design that would generate a lower speed clock (e.g. 10MHz clock), or should be able to timestamp events to within a few 10s of ns.

[hamster_nz]

I had a play with my Basys3 and PmodGPS, and there is at least five or six bits of randomness (50 counts or so) in the count of 100MHz cycles between the PPS leading edges.

That might give an error of +/- 250ns towards the end of the second. It would be pretty hard to reliably timestamp at better than 0.5us using a setup like that.

I took a short video in case you want to do your own analysis of the data.



VHDL code:

Code: [Select]

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

-- Uncomment the following library declaration if instantiating
-- any Xilinx leaf cells in this code.
--library UNISIM;
--use UNISIM.VComponents.all;

entity gpsdo is
    Port ( clk_100MHz : in STD_LOGIC;
           JA        : in std_logic_vector( 7 downto 0);
           leds       : out std_logic_vector(15 downto 0) := (others => '0');
           segments   : out std_logic_vector( 6 downto 0) := (others => '1');
           anodes     : out std_logic_vector( 3 downto 0) := (others => '1')
           );
end gpsdo;

architecture Behavioral of gpsdo is
    signal count              : unsigned (27 downto 0);
    signal cycles_last_second : unsigned (27 downto 0);
    signal pps                : std_logic := '0';
    signal last_pps           : std_logic := '0';
begin

    leds <= std_logic_vector(cycles_last_second(15 downto 0));
   
process(clk_100MHz)
    begin
        if rising_edge(clk_100MHz) then
            if pps = '1' and last_pps = '0' then
                cycles_last_second <= count+1;
                count <= (others => '0');
            else
                count <= count + 1;
            end if;
            last_pps <= pps;
            ------------------------------
            -- single stage synchronizers
            ------------------------------
            pps      <= JA(3);
           
        end if;
    end process;
end Behavioral;


[kazam]

Hi,

Yes, that's pretty much what I see as well. The 1PPS coming from the GPS is most likely synchronized with some internal clock of the GPS which leads to the typical sawtooth error pattern.

But the 1PPS is 10ns RMS accurate on average. So if you measure for long enough and have your own internal 1PPS in the FPGA then you can get an accurate number of pulses in 1 second and just use that counter to time stamp the data. It's also possible to use four clocks with 90 degree phase shift I suppose for even finer resolution. And the TDC techniques mentioned above are just a very helpful tool when it comes to measuring extremely accurate time delays.

But I strongly suggest you read this paper as it really outlines the whole approach and suggests a solution:
https://www.researchgate.net/publication/4283871_A_Digital_Circuit_for_Jitter_Reduction_of_GPS-disciplined_1-pps_Synchronization_Signals

I also have a need for a really stable 1PPS signal. I have this now which might not be up to par:
http://www.synreference.net/freqref/gnss-locked-ref/item/10-mhz-self-calibrating-general-lab-use-simulcast-48

[branadic]

You might want to take a look on TICC https://www.febo.com/pages/TICC/. Not FPGA based, but time stamped data anyway.

[kazam]

Thanks, interesting but not applicable in this application since accuracy is much better than needed but I have on the other hand several thousand messages per second that need time stamping.

I have a first draft ready for the DPLL solution on the FPGA, as in the papaer, so will report back if it works.

You might want to take a look on TICC https://www.febo.com/pages/TICC/. Not FPGA based, but time stamped data anyway.

[Kleinstein]

The problem has two parts to it:
The first one is getting a stable fast (e.g. 10 MHz) clock synchronized to the GPS 1 PPS signal. This would be some kind of PLL - either fully digital or maybe as a GPS disciplined oscillator with a VCXO or similar.

The second in than time-stamping the external signals. With something like a 30 ns required accuracy and thus something like 10 ns resolution, this is relatively straight forward in an PLL or maybe even a µC. There is no yet a need for those special tricks for sub ns resolution. One might use a few of the very basic ones, like using 2 phase shifted clocks ar a short delay line with maybe 5 taps.

[hamster_nz]

The problem has two parts to it:

The problem could be made a bit simpler.....

- Timestamp the events of interest with the cycle count from the FPGA.
- Timestamp the GPS PPS edges with the cycle count from the FPGA.

Once data is collected, then the PPS timestamps could be inspected to give FPGA cycle count to GPS time conversion.

It should be more accurate as you can use PPS information from in the future as well as that from the past, so max uncertainty will be in the middle of the second, not just before the next PPS pulse is seen.

[kazam]

Excellent idea. I will definitely keep this in mind.

The problem has two parts to it:

The problem could be made a bit simpler.....

- Timestamp the events of interest with the cycle count from the FPGA.
- Timestamp the GPS PPS edges with the cycle count from the FPGA.

Once data is collected, then the PPS timestamps could be inspected to give FPGA cycle count to GPS time conversion.

It should be more accurate as you can use PPS information from in the future as well as that from the past, so max uncertainty will be in the middle of the second, not just before the next PPS pulse is seen.

[kazam]

I have a solution for this now. I just reset the counter every PPS and then keep track how many pulses are between edges. Linear interpolation gives time in nanoseconds between UTC seconds. Division directly in FPGA. It works good enough!

[texaspyro]

Take a look at the Venus GPS timing receivers.  They have a 120 MHz clock and their PPS jitter is on the order of 6 ns.  Navspark and Nick Sayer on Tindie have them.  Nick's is pin compatible with the Adafruit Ultimate GPS.   Otherwise, use the 1PPS from a GPSDO.  The GPSDO firmware takes care of filtering out the GPS 1PPS jitter.  The Trimble Thunderbolt GPSDO locks the GPS clock to the OCXO and this architecture does not produce any sawtooth jitter.

[cdev]

The NavSpark Mini looks like an unusual value.

https://navspark.mybigcommerce.com/navspark-mini-uart-to-usb-adapter

Article on NavSpark Mini


http://www.cnx-software.com/2016/01/20/getting-started-with-navspark-mini-gps-module/

This is significantly different than the usual GPS modules you see because the NavSpark boards - even the "free" (+$10 shipping) NavSpark Mini GPS come with a "free" 32 bit Leon3 Sparc CPU
that they run on, and you can program it.

 

[texaspyro]

The NavSpark Mini looks like an unusual value.

Yes,  the processor is basically a rather powerful general purpose micro with one of the on-board peripherals being a GNSS receiver.   It is a Venus GNSS receiver.  They sell a larger version of the Mini with lots more pins and also (I think) the bare CPU chip.  You can buy six of the Mini's for $36.  They are pretty decent tiny little GNSS receivers.   The larger board is around $20.

Note that the open-source firmware does not include support for the timing receiver optimized functions.  Like most GPS receiver makers, they really jack up the price for those.

Lady Heather works well with the Navspark devices.

[cdev]

The GPS itself is not open source.

Wondering how accurate the Navspark Mini is when used for timing, with the usual free running oscillator/stairstepping/sawtooth problem.. and whether it would be possible to apply heating/cooling to make a sort of poor man's TCXO.

[texaspyro]

Wondering how accurate the Navspark Mini is when used for timing, with the usual free running oscillator/stairstepping/sawtooth problem.. and whether it would be possible to apply heating/cooling to make a sort of poor man's TCXO.

I have both the Mini and the timing versions.   When my equipment frees up I'll try connectong each version (fed by a common antenna) to a TAPR TICC (2 channels with 60 ps resolution, referenced to a 5071A cesium beam oscillator) and see how they compare.

[texaspyro]

It is also interesting to know what it does when it has a signal impairment, what the free running etc. is like or if it just stops the PPS and other output(s) after X time or whatever.

I don't remember what the Navspark units do but a lot of the better GPS receivers can be programmed to either block the 1PPS or keep it when the GPS loses lock.   Some devices immediately drop the 1PPS when the signal goes away and others let it freewheel for a while.

[cdev]

Texaspyro. Yes, i would be very interested in seeing how well it does.


The accuracy in the specs is stated as "atomic clock synchronized P1PPS time reference pulse with +/-10nsec accuracy"