[time-nuts] Ublox 6T receiver, noisy PPS.

[Bob Camp]

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 <tvb at 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.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:
>>>    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 at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.