Re: [time-nuts] GPSDO and holdover
I mentioned to Tom that I had seen the xgps program duplicate a lot of its satellites when I missed a PPS. I noticed my GPSDO go into holdover so I quickly brought up xgsp and noticed it happening again. This screen showed a few times intermixed with a normal screen. I have no idea whether it's a bug in xgps or due to something coming from the Adafruit, but it's interesting, nonetheless. http://www.evoria.net/Adafruit/Holdover.png Bob - AE6RV From: Paul tic-...@bodosom.net To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Friday, April 25, 2014 1:20 PM Subject: Re: [time-nuts] GPSDO and holdover On Tue, Apr 22, 2014 at 9:57 PM, Tom Van Baak t...@leapsecond.com wrote: I have noticed skipped 1PPS on the Adafruit GPS also. I've always assumed this could happen but as a result of RF signal loss not a glitch in the gps. So I've started recording event timestamp deltas using the Linux kernel PPS interface. I read assert events (e.g. 1398449188.001000242#1741672) and compute timestamp and event deltas. If the t delta is .9 something horrible must have happened and if it's 1 some didn't happen assuming the event count delta is always 1. I wonder if this is a reasonable approach or if I'm being lazily optimistic. I just started (and I haven't added a join with the valid fix indicator yet) but I've had two missing pulses in the last 24 hours. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO and holdover
I have noticed skipped 1PPS on the Adafruit GPS also. I've always assumed this could happen but as a result of RF signal loss not a glitch in the gps. So I've started recording event timestamp deltas To be clear, we are not talking about a system-wide GPS problem here; the satellites are fine. All my other GPS receivers are fine. It's just one particular GPS receiver board that Bob, and now Bob and I, are questioning. using the Linux kernel PPS interface. I read assert events (e.g. 1398449188.001000242#1741672) and compute timestamp and event deltas. If the t delta is .9 something horrible must have happened and if it's 1 some didn't happen assuming the event count delta is always 1. I wonder if this is a reasonable approach or if I'm being lazily optimistic. I just started (and I haven't added a join with the valid fix indicator yet) but I've had two missing pulses in the last 24 hours. Sure, that's reasonable. I'm using a 53132 TIC to compare my house atomic 1PPS (start) against the Adafruit GPS 1PPS (stop) and so no timestamping is even necessary: the readings themselves tell you if there is a missed pulse. For example, you get TI readings like 0.000nn for hours or days and then once in a while you get a 1.000nn or 2.000nn, indicating a missed pulse. After Bob Stewart's first mention of the Adafruit Ultimate GPS board, I dug out mine and collected 30 days of data to see if I could duplicate or understand his measurements. As usual, a simple and quick test has turned into something more complicated and perplexing. I'll share some results maybe next week. The test is now multiple GPS boards, antennas, and counters. /tvb ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO and holdover
On Tue, Apr 22, 2014 at 9:57 PM, Tom Van Baak t...@leapsecond.com wrote: I have noticed skipped 1PPS on the Adafruit GPS also. I've always assumed this could happen but as a result of RF signal loss not a glitch in the gps. So I've started recording event timestamp deltas using the Linux kernel PPS interface. I read assert events (e.g. 1398449188.001000242#1741672) and compute timestamp and event deltas. If the t delta is .9 something horrible must have happened and if it's 1 some didn't happen assuming the event count delta is always 1. I wonder if this is a reasonable approach or if I'm being lazily optimistic. I just started (and I haven't added a join with the valid fix indicator yet) but I've had two missing pulses in the last 24 hours. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO and holdover
Some timing GPS units (eg Oncore UT) can be set to omit 1PPS pulses if no satellites are being tracked, or if the RAIM alarm limit is exceeded. Dave On 4/25/2014 10:20 AM, Paul wrote: On Tue, Apr 22, 2014 at 9:57 PM, Tom Van Baakt...@leapsecond.com wrote: I have noticed skipped 1PPS on the Adafruit GPS also. I've always assumed this could happen but as a result of RF signal loss not a glitch in the gps. So I've started recording event timestamp deltas using the Linux kernel PPS interface. I read assert events (e.g. 1398449188.001000242#1741672) and compute timestamp and event deltas. If the t delta is .9 something horrible must have happened and if it's 1 some didn't happen assuming the event count delta is always 1. I wonder if this is a reasonable approach or if I'm being lazily optimistic. I just started (and I haven't added a join with the valid fix indicator yet) but I've had two missing pulses in the last 24 hours. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. -- Clear Stream Technologies ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO and holdover
Hi Bob S, I have noticed skipped 1PPS on the Adafruit GPS also. Some days are clean, other days miss a few samples. I have not explained it yet. I plan to run two GPS boards and two counters to narrow down the cause. In any event, IMHO, a GPSDO should not go crazy if glitches like this occur. I don't think it should go into holdover for one missed sample, or even a few missed samples. But then you need to define what holdover is. I mean, by some definition a GPSDO is in holdover between every second. I do not think there is any standard. Just conventions: some documented, some not. It's attention to a dozen little details like this that separate a quick hack GPSDO from a quality one. You'll also face a number of design issues at startup, and coming out of holdover. Lastly, you get to choose between it being an ideal time standard vs. an ideal frequency standard. /tvb p.s. Please fix your address book. The correct email for the list is time-nuts@febo.com - Original Message - From: Bob Stewart To: time-nuts-ow...@febo.com Sent: Tuesday, April 22, 2014 6:03 PM Subject: GPSDO and holdover I hope I haven't asked this before, but is there a standard way of deciding to go into holdover mode? I'm still wrapping up code for this Adafruit, and as I've posted before: every now and then it skips a PPS. I'm trying to decide whether to allow a free pass (if not followed by another skip within some timeframe) or to immediately stop processing any further PPS pulses until I decide based on some criteria that they're reliable. Bob - AE6RV ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO and holdover
Hi Tom, Thanks for confirming that these lost PPS pulses are happening to someone else! I've looked through my interrupt code several times to see if I'm missing something. Please let me know if you find anything for sure. I've been thinking of saving the values for the satellites at each tick to see if it's related to AOS/LOS, but there's been too much else to do. I've already faced most of the points you make, and yeah, the decision on whether to have ideal time or ideal frequency has been a difficult one. But, there's only so much I can do with a nav receiver. I'll address it when a timing receiver goes in. I think I'll go ahead and loosen up my definition of what holdover is, as a strict interpretation seems to cause more damage than it prevents. Bob From: Tom Van Baak t...@leapsecond.com To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Tuesday, April 22, 2014 8:57 PM Subject: Re: [time-nuts] GPSDO and holdover Hi Bob S, I have noticed skipped 1PPS on the Adafruit GPS also. Some days are clean, other days miss a few samples. I have not explained it yet. I plan to run two GPS boards and two counters to narrow down the cause. In any event, IMHO, a GPSDO should not go crazy if glitches like this occur. I don't think it should go into holdover for one missed sample, or even a few missed samples. But then you need to define what holdover is. I mean, by some definition a GPSDO is in holdover between every second. I do not think there is any standard. Just conventions: some documented, some not. It's attention to a dozen little details like this that separate a quick hack GPSDO from a quality one. You'll also face a number of design issues at startup, and coming out of holdover. Lastly, you get to choose between it being an ideal time standard vs. an ideal frequency standard. /tvb p.s. Please fix your address book. The correct email for the list is time-nuts@febo.com - Original Message - From: Bob Stewart To: time-nuts-ow...@febo.com Sent: Tuesday, April 22, 2014 6:03 PM Subject: GPSDO and holdover I hope I haven't asked this before, but is there a standard way of deciding to go into holdover mode? I'm still wrapping up code for this Adafruit, and as I've posted before: every now and then it skips a PPS. I'm trying to decide whether to allow a free pass (if not followed by another skip within some timeframe) or to immediately stop processing any further PPS pulses until I decide based on some criteria that they're reliable. Bob - AE6RV ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPSDO and holdover
On Tue, Apr 22, 2014 at 6:57 PM, Tom Van Baak t...@leapsecond.com wrote: I do not think there is any standard. Just conventions: some documented, some not. It's attention to a dozen little details like this that separate a quick hack GPSDO from a quality one. You'll also face a number of design issues at startup, and coming out of holdover. Lastly, you get to choose between it being an ideal time standard vs. an ideal frequency standard. The simplest thing, I think is to use the GPS' serial data stream to decide if you are in holdover or not. There will be a status message that says if the GPS is producing valid output. The details depend on the GPS but most have something to describe the number of GPS satellites in view and something about each of them. -- Chris Albertson Redondo Beach, California ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
