Check current jitter from GPS based time source. - Page 1
Forum section: electronics / general

author: SpottedDick
author_rank: Regular Contributor
timestamp: July 12, 2025, 02:05:48 pm
content: Hi All,Currently running a GPS based time server using GPSD and chronyc. I'm using a neo-6M module and thinking of updating to a LEA-6T. Before I do, does anyone know how to check the "jitter" on the time source?The Neo module is made for mobile GPS, while the Lea is made for static. The difference should be that (once the Lea has surveyed its location) the Lea should show a much more stable time signal, but I'm not sure how to check this.Thanks.

author: fourfathom
author_rank: Super Contributor
timestamp: July 12, 2025, 02:37:21 pm
content: I suppose you can compare the PPS signals with a scope... I had two $100 NEO GPS modules and a $5 Chinese GPS module, so I connected a GPS antenna to an amplified splitter, using three of the splitter outputs to feed the GPS modules. NEO #1 was the scope trigger, with NEO #2 and the $5 module feeding scope channels 1 and 2. The antenna only had a partial view of the sky (trees), but the NEOs had slightly better jitter. Other comparisons indicated that the two NEOs drifted rather independently, so I assume the average drift is about half that shown in my plot below (yellow trace is the NEO). This test was only over a few hours -- I just wanted a quick look, not a definitive measurement.

author: nctnico
author_rank: Super Contributor
timestamp: July 12, 2025, 03:09:28 pm
content: Checking the 1PPS isn't going to help as the 1PPS output wanders around like crazy on these modules.A better way is to compare the phases of the 10MHz output. But you'll need a reference. A cheap option is to use a third GPSDO which is designed for a fixed location. Then do two 48 hour comparisons with the other GPSDOs (3 cornered hat comparison). The mobile one could drift a bit more. But it is also possible none of the GPSDOs under test support fixed location mode. On the uBlox modules the location teach in period can range from a couple of minutes to hours. Depending on how tight the boundaries are set. But if these aren't set at all, the GPSDO will lock quickly and probably have the same performance.

author: SpottedDick
author_rank: Regular Contributor
timestamp: July 12, 2025, 03:42:12 pm
content: You've confused me a bit with this answer, as I'm looking to test the Jitter on a mobile unit Vs a static unit, while your answer goes off on different comparisons.QuoteYeah, I wasn't actually planning on going this route. I would have thought something like the CPU clock would be accurate enough to show *approximate* jitter and something would be built to show this, however I don't see anything like this in gpsd.

author: nctnico
author_rank: Super Contributor
timestamp: July 12, 2025, 03:55:12 pm
content: Quote from: SpottedDick on July 12, 2025, 03:42:12 pmIf you have one watch, you know what time it is. With two watches, you don't. Only with 3 watches (or more) you can be sure.IOW: for both GPDSO modules you don't know the performance. The uBlox modules need to be configured for static location operation. Just plugging in a different module isn't going to be enough; the firmware initialising the module has to detect the module and enable static location.So if you have a known-good, static location GPSDO, you can compare the performance of the uBlox modules against a reference and see if using a different module gives any improvement.

author: SpottedDick
author_rank: Regular Contributor
timestamp: July 12, 2025, 04:20:10 pm
content: Thanks for the responses NCT.Again, the new module will be static and is configured as such.However, that's not related to the question I'm asking.Pretend you only have the one GPS module. Do any of the GPS tools calculate jitter in relation to one of the time clocks already on the PC.I am very aware that the time sources on the computer are not accurate. The goal will be to look at the difference of this value between the original and new static GPS source and see if there is a difference.The total jitter should be less with the static source, regardless of the actual accuracy of the jitter measurement value.Also, "IOW" returns Isle Of Wight" on Google, which I'm guessing is not what this means

author: edpalmer42
author_rank: Super Contributor
timestamp: July 12, 2025, 05:22:52 pm
content: Quote from: nctnico on July 12, 2025, 03:09:28 pmBut that's part of what you want to measure. I've measured the period of the 1 PPS output of some GPS receivers and GPSDOs. My counter can make multiple measurements and calculate the mean and standard deviation of the measurements. People who know far more than I do about these things say that's not an adequate measurement, but I still like it. Older GPS receivers have a Std. Dev. of tens of nanoseconds with a range of up to 100 ns. Newer ones have a Std. Dev. less than 10 ns. with a range in the low tens of ns. GPSDOs have a Std. Dev. as low as 0.1 ns. and a range of less than 5 ns. I haven't measured any of the uBlox units.QuoteIt's not a good idea to compare two GPSDOs. Most of the jitter on a GPSDO comes from the RF connection through the air. This will be common to both receivers. It's better to compare a GPSDO to a stable reference. This could be a Rb standard or a decent quartz oscillator. This measurement doesn't take a long time so a quartz oscillator with aging of 1 PPB per day or better is adequate.But how do you measure the aging of a quartz oscillator? You use a GPSDO! It sounds like circuilar logic, but regardless of the amount of jitter on a GPSDO, the average frequency of a locked GPSDO will be 10 MHz (or whatever it's programmed for). You can use this signal as a reference to measure your OCXO against.If the OP is just using the text output as the reference, I don't know how these measurements relate to the printout. But I think you can configure an NTP server to use the 1 PPS output as the reference.

author: SpottedDick
author_rank: Regular Contributor
timestamp: July 12, 2025, 05:42:24 pm
content: Yes, the NTP server uses the 1PPS output to the DCD pin on the motherboard serial as a clock source. Linux has this built into the Kernel for exactly this purpose.

author: nctnico
author_rank: Super Contributor
timestamp: July 12, 2025, 06:02:47 pm
content: Quote from: SpottedDick on July 12, 2025, 04:20:10 pmThe PC hardware will not be able to measure jitter with a high enough resolution to what the 1PPS output is wandering about. In that respect you won't get any improvement from using a better GPSDO module.QuoteIOW= in other words.

author: SpottedDick
author_rank: Regular Contributor
timestamp: July 12, 2025, 06:05:01 pm
content: QuoteI mean, probably not, but I can still check it before and after. I don't mind wasting all 2 minutes of my time if it turns out to be fruitless!

author: edpalmer42
author_rank: Super Contributor
timestamp: July 12, 2025, 07:09:22 pm
content: Quote from: SpottedDick on July 12, 2025, 05:42:24 pmSo those tests are directly relevant to your situation. If you have a counter that can measure period to 1 ns or better and has a method to get the measurements into a computer, typically RS-232 or GPIB, you can collect the measurements and then import them into a spreadsheet for calculation even if your counter can't do the calculations internally.

author: nctnico
author_rank: Super Contributor
timestamp: July 12, 2025, 08:17:29 pm
content: Quote from: edpalmer42 on July 12, 2025, 05:22:52 pmA 1ppb quartz oscillator isn't going to work. With 86k seconds in a day, it can drift tens of microseconds away in 24 hours. You can't predict what it will do. Even a Rubidium clock isn't good enough. Without access to a Cesium clock (or better) the best way really is to compare GPDSOs amongst eachother because in the end you are testing against the same reference. Typically you'd see around +/-20ns of wander on the 10MHz output from a good GSPDO. A poorly performing GPSDO will show a lot more wander on the 10MHz output compared to others. Using 3 GPSDOs (two known good, one unknown) you can have a good ballpark whether the unknown one if performing OK (or not). The best way is to do this test over 48 hours because that gives you two full cycles of the GPS satellite orbits.But all of this is moot for syncing a PC RTC which is within tens of milli-seconds at best.

author: edpalmer42
author_rank: Super Contributor
timestamp: July 12, 2025, 09:38:07 pm
content: Quote from: nctnico on July 12, 2025, 08:17:29 pmIf you need to measure for a day or two you're correct. But what are you measuring? Are you measuring the GPSDO for long-term frequency error or for short-term noise and jitter? Those are two very different measurements. The OP asked about short-term jitter.Testing GPSDOs against each other is deceptive. Let's say that you test a GPSDO against a Rb and see your +- 20 ns. of wander. That would be made up of RF path changes and the GPSDO itself. The identical RF changes will be seen by every GPSDO that's connected to the same antenna. When you compare them to each other, the RF changes will disappear and you'll only see the internal differences. This is deceptive because it doesn't represent the real-world performance that you can expect from the GPSDO. A worst-case example of this is to compare two of the same model to each other. They will react to the same RF signal in the same way and will have similar internal noise contributions. The differences between them will be very small and the performance will appear to be absolutely amazing! Here's an example of this kind of analysis:https://www.febo.com/pages/gpsdo_comparison/. In this case, the two Tbolts tracked each other very closely so when they were compared to each other they looked amazing. One of the Z3801s was noisier than the other so when they were compared, the noisy one degraded the result.In my previous message I said that most of the jitter comes from the RF path. On second thought, I realize that I have no idea if that's true. Does anyone know of a source where that was discussed? Maybe a textbook or a scientific paper? Preferably with pictures. I like pictures. I hate equations.

author: SpottedDick
author_rank: Regular Contributor
timestamp: July 12, 2025, 11:57:07 pm
content: I appreciate your input on this thread, but their surely must be a tool that looks at the system clock and what is being generated by a GPS source and calculates the jitter? I've I had any experience in this field at all I'd just go and write it.

author: edpalmer42
author_rank: Super Contributor
timestamp: July 13, 2025, 12:30:13 am
content: Quote from: SpottedDick on July 12, 2025, 11:57:07 pmYou had to go and open this can of worms, didn't you?It should be easy.Piece of cake.What could possibly go wrong?The problem is that we're talking about nanoseconds here. A computer doesn't care about nanoseconds and it REALLY doesn't care about serial ports (whether real or USB-derived). So it looks at a serial port whenever it gets around to it. Maybe now, maybe in a few microseconds - whatever. The port itself expects this and includes a buffer so that it can send or receive a small number of characters by itself. At some point, it will poke the CPU and say "Come deal with this". The CPU puts the request on its list of things to do and eventually takes care of it.The end result is that a computer is utterly incapable of answering your question by itself. By extension, it also suggests that your NTP server won't know or care if you upgrade your GPS receiver because it's already better than the computer. I don't know how deeply you can dive into gpsd. Can you dig down to the raw data and see what kind of increments the computer is recording? If the timestamps have a resolution of one microsecond, anything smaller than that will be invisible to the computer.

author: nctnico
author_rank: Super Contributor
timestamp: July 13, 2025, 09:05:43 am
content: Quote from: edpalmer42 on July 12, 2025, 09:38:07 pmYou really keep missing the point. The situation is that unless you have a Cesium clock, you have no good way to check whether a GPSDO works well long term. They can be close short term but wander far away for all kinds of reasons (configuration, firmware bugs) later on so doing a test over 48 hours is a good idea. As I wrote before, the way out is to make a 3 way comparison using 3 GPSDOs. If 3 GPSDOs agree within what is to be expected, then you can have a high amount of certainty the GPSDOs are functioning OK and the time & frequency they provide is accurate within spec. The key thing to understand here is that it is arelativemeasurement. Take your same model GPSDO check as an example: if they all agree, then they are likely OK. If one shows radically different results, then something is wrong.

author: edpalmer42
author_rank: Super Contributor
timestamp: July 13, 2025, 05:33:23 pm
content: Quote from: SpottedDick on July 12, 2025, 02:05:48 pmYou haven't told us much about your server software / hardware or application. How far down this rabbit hole do you want to go? Since you mentioned chronyc I'm assuming you're running Linux with the appropriate kernel patches - or are those mainstream now? PTP? NIC Timestamping? Is there anything special about your application? If you're willing to do a deep dive it looks like there are significant improvements that can be made on the server side. Whether that will push you to upgrade your GPS receiver remains to be seen.My needs are much more modest. I consider NTP to be a 'human level' protocol rather than 'machine level'. So all I do is run ntpd on windows with refclock29 to talk to my Trimble Thunderbolt. I don't even bother with the 1PPS.