[time-nuts] Ublox 6T receiver, noisy PPS.
Tom Van Baak
tvb at LeapSecond.com
Thu Jan 22 06:52:46 EST 2015
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.
----- Original Message -----
From: "Azelio Boriani" <azelio.boriani at gmail.com>
To: "Discussion of precise time and frequency measurement" <time-nuts at 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, <dan at irtelemetrics.com> wrote:
>> 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! :)
>> > 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. >
More information about the time-nuts