Time stamping with GPS 1PPS and FPGA - Page 1
Forum section: electronics / general

author: kazam
author_rank: Regular Contributor
timestamp: June 04, 2017, 10:14:50 am
content: 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=7Right 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.phpI 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_SignalsAny thoughts on this?/K

author: Andreas
author_rank: Super Contributor
timestamp: June 04, 2017, 10:35:48 am
content: Hello,I think the experts for this question are more on the time-nuts forum.https://www.febo.com/pipermail/time-nuts/with best regardsAndreas

author: kazam
author_rank: Regular Contributor
timestamp: June 04, 2017, 10:41:30 pm
content: 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.

author: hamster_nz
author_rank: Super Contributor
timestamp: June 04, 2017, 11:27:09 pm
content: Quote from: kazam on June 04, 2017, 10:41:30 pmIf 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.

author: hamster_nz
author_rank: Super Contributor
timestamp: June 05, 2017, 05:03:17 am
content: 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: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 isPort ( 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 issignal count : unsigned (27 downto 0);signal cycles_last_second : unsigned (27 downto 0);signal pps : std_logic := '0';signal last_pps : std_logic := '0';beginleds <= std_logic_vector(cycles_last_second(15 downto 0));process(clk_100MHz)beginif rising_edge(clk_100MHz) thenif pps = '1' and last_pps = '0' thencycles_last_second <= count+1;count <= (others => '0');elsecount <= count + 1;end if;last_pps <= pps;-------------------------------- single stage synchronizers------------------------------pps <= JA(3);end if;end process;end Behavioral;

author: kazam
author_rank: Regular Contributor
timestamp: June 05, 2017, 09:22:34 am
content: 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_SignalsI 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

author: branadic
author_rank: Super Contributor
timestamp: June 05, 2017, 09:39:27 am
content: You might want to take a look on TICChttps://www.febo.com/pages/TICC/. Not FPGA based, but time stamped data anyway.

author: kazam
author_rank: Regular Contributor
timestamp: June 05, 2017, 11:21:16 am
content: 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.Quote from: branadic on June 05, 2017, 09:39:27 am

author: Kleinstein
author_rank: Super Contributor
timestamp: June 05, 2017, 11:50:08 am
content: 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.

author: hamster_nz
author_rank: Super Contributor
timestamp: June 05, 2017, 11:37:30 pm
content: Quote from: Kleinstein on June 05, 2017, 11:50:08 amThe 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.

author: kazam
author_rank: Regular Contributor
timestamp: June 06, 2017, 01:20:08 am
content: Excellent idea. I will definitely keep this in mind.Quote from: hamster_nz on June 05, 2017, 11:37:30 pm

author: kazam
author_rank: Regular Contributor
timestamp: June 18, 2017, 08:25:47 pm
content: 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!

author: texaspyro
author_rank: Super Contributor
timestamp: June 21, 2017, 06:13:59 am
content: 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.

author: cdev
author_rank: Super Contributor
timestamp: June 24, 2017, 07:07:50 pm
content: The NavSpark Mini looks like an unusual value.https://navspark.mybigcommerce.com/navspark-mini-uart-to-usb-adapterArticle on NavSpark Minihttp://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 CPUthat they run on, and you can program it.

author: texaspyro
author_rank: Super Contributor
timestamp: June 24, 2017, 08:32:52 pm
content: Quote from: cdev on June 24, 2017, 07:07:50 pmYes, 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.

author: cdev
author_rank: Super Contributor
timestamp: June 24, 2017, 11:21:13 pm
content: 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.

author: texaspyro
author_rank: Super Contributor
timestamp: July 05, 2017, 01:52:44 am
content: Quote from: cdev on June 24, 2017, 11:21:13 pmI 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.

author: texaspyro
author_rank: Super Contributor
timestamp: July 05, 2017, 01:56:06 am
content: Quote from: evb149 on June 24, 2017, 11:40:12 pmI 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.

author: cdev
author_rank: Super Contributor
timestamp: July 05, 2017, 05:11:20 pm
content: 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"