Hi I think I would add a few things to the logging list as well:
1) Filter state in the the controller (if it’s multi state). 2) EFC voltage, either directly with a DVM , or as a DAC setting. 3) Temperature, even as an once a minute output from a cheap USB temperature gizmo. That’s not to say that any of the above is likely to be a big issue in solving the current problem. You never know what will come up next … Bob > On Jan 22, 2015, at 6:52 AM, Tom Van Baak <t...@leapsecond.com> wrote: > > Dan, > > I echo what Azelio is saying. During the time when you are "evaluating" a GPS > receiver it is important to collect as much data as possible, just in case > you need to go back and correlate unusual events. I tend to turn on all > possible binary messages and collect tens or hundreds of MB. You never know > what you will uncover hidden in the data. > > But even collecting as little info as date, time, number of SV visible and > locked, signal strengths, and solution mode (3D, 2D, 0D) once a second is a > good enough summary for most purposes. I also log lat/lon/alt because if that > varies then you know you're no longer in position hold mode. > > You can confirm Azelio's prediction below by manually forcing it to 3D for a > while and see if that suddenly matches your "noisy" data. > > /tvb > > ----- Original Message ----- > From: "Azelio Boriani" <azelio.bori...@gmail.com> > To: "Discussion of precise time and frequency measurement" > <time-nuts@febo.com> > Sent: Thursday, January 22, 2015 3:03 AM > Subject: Re: [time-nuts] Ublox 6T receiver, noisy PPS. > > >> OK, my opinion is that the GPS was not in position hold mode during >> the noisy period. Maybe due to an internal error or whatever, the GPS >> quitted the position hold mode. Try to add to the software the ability >> to log the GPS actual status so that if this error will return you are >> able to see what happened to the GPS. In order to confirm (or not) my >> opinion, you can try to run a test where the GPS operates in the >> standard navigation mode and see if the wander is the same as the >> noisy period. >> >> On Thu, Jan 22, 2015 at 4:02 AM, <d...@irtelemetrics.com> wrote: >>> Hi, >>> >>> Yes, the log has Raw TIC phase, saw tooth correction, and corrected TIC >>> phase. Unfortunately I do not have another TIC available at the moment (It's >>> on the wish list!) Also, with the GPS and OCXO, it's the classic two clock >>> problem! ;) >>> >>> It took a bit to pull the data together for graphing. The two graphs show >>> 9000 seconds of recorded data, few days apart. One from the 'noisy' period >>> of time and the other from after the last survey. In the graphs the >>> corrected 'noisy' data has a peak to peak wander of about twice that (26nS) >>> of the corrected 'normal' wander (13nS). Other periods of time show wander a >>> bit worse. However I tried to pick some samples that had similar EFC DAC >>> movement, to try to keep the comparison even. >>> >>> The magenta trace is saw tooth correction, in ns. The blue trace is >>> uncorrected phase between the PPS and the HP10811. The yellow trace is >>> corrected phase. You will note that the GPSDO is setup for a 50nS phase >>> shift between the PPS and OXCO. >>> Additional things to note: I intentionally did not touch the system when >>> the noise started (Trying not to change anything). The only thing that was >>> done was the survey was started again. The HVAC system cycles here about >>> every 30 to 40 minutes, so this data includes several temp swings. It's been >>> about a month since the GPS was last power cycled. The 'noisy' period of >>> data lasted a few days, and ended with the survey. Until the noisy period of >>> data things have been running nicely since about last September. The antenna >>> has not been moved, but some snow was removed from the roof around the >>> antenna about a week before the 'noisy' period started. The HP10811 has been >>> aging at about 5e-12 per day... >>> My gut tells me something happened in the GPS, although I'm not sure what. >>> Maybe this is even normal for a GPS? My feeling is not, but you all know >>> this stuff better I do! :) >>> >>> >>> Thanks, >>> Dan >>> >>> >>> >>> >>> >>> >>>> So, your PPS wander is measured by the GPSDO internal TIC and the >>>> result is sawtooth corrected and usually gives 6ns, suddenly it went >>>> to 25ns. Well, the first move, IMO, is to connect an external TIC and >>>> track the GPS PPS against the GPSDO PPS and see whether, when you have >>>> the jump, it is recorded only by the internal TIC or not. You have a >>>> log file: what's in it? You said that the PPS was still getting >>>> corrections but what about the uncorrected PPS wander? Was it still >>>> the same after the jump? Can you share your log file with the data >>>> before and after the jump? I'm assuming the log file has the raw PPS >>>> measurements and the applied corrections listed every second. > >>> > > _______________________________________________ > 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.