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.
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.
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:
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;
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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"