We were going to have a phone meeting with Sachin this morning at 10 am, but we pushed it back to tomorrow.
My latest data run has been going for the last 10 days, so I decided to finally stop it so we could process it. The file size (with a few small initial aborted runs trimmed off) is 383 MB.
The reformatted (line-per-record) data file is 108 MB. Apparently, there were 0 serial data errors in the entire run! (Hooray!)
Now reading the new big data set into SciLab. OK, took a while but that's done.
The initial wander graph has a number of big discontinuities - probably extra PPS pulses.
The first one is definitely an extra PPS pulse, after only about 1 million (rather than 10 million) cycles. Fixed the current data file by hand, and modified the firmware so that in the future, PPS events that do not arrive within +/-1% of the expected time will be ignored & not reported to the server.
The other big discontinuities were also caused by extra PPS pulses, as expected. Fixed them by hand.
Next, there were a few hundred small transient glitches, always of particular sizes: Usually 10,000 (1 ms), but occasionally 20,000 (2 ms), or 200,000 (20 ms). One was 400,000 (40 ms). Most of them only lasted a second, but there were occasional ones of larger sizes, up to 10 or 20 seconds. There was one that was almost 100 seconds long. All discrepancies larger than 1,000 were accounted for by these transient glitches.
I wrote code to automatically repair glitches of the duration and apparent sizes I found (fixes the in-memory vectors in SciLab only; the glitches are still there in the data files).
However, it is somewhat of a mystery exactly what is causing these glitches. The fact that they are all exactly by small multiples of 1 or 10 milliseconds is telling. Since they are not powers of 2, they are unlikely to be problems with the input capture circuit.
More likely, they reflect some kind of temporary adjustments being made to the GPS unit's internal clock by its firmware. This is corroborated by the fact that the glitches I looked at seemed to all coincide exactly with situations where the TRAIM was temporarily in an alarm condition (with all satellites marked invalid). I probably should do a more thorough (or automated) check to make sure that some event like this accounts for each of the glitches, but I haven't done that yet....
Meanwhile, with the glitches repaired algorithmically, we get output like we expected, based on our previous tests. Below is the cumulative phase wander (in 100-ns cycles) over the course of the entire big 10-day run, with TRAIM accuracy in nanoseconds (x10) superimposed.
The overall graph is U-shaped due to a gradual increase in OCXO frequency over the course of the run. We can see that the remaining excursions away from the baseline curve are generally fairly brief (at most a few hours) and coincide with times at which the TRAIM accuracy is nulled out.
And below is the relative frequency drift over the run, plotted in Hz above the nominal frequency of 10MHz. This plot uses a 1-hour window size for smoothing (time-averaging) the frequency measurements (with no smoothing, we'd only see integer values of Hz, almost all in the range 12-14). The sharp spikes correspond entirely (or almost entirely) to the start or end of excursions, times at which either the GPS clock is drifting at an anomalous frequency because it has just lost time lock & hasn't realized it yet, or at which the GPS clock has snapped back into phase after regaining time lock.
This graph confirms that the OCXO frequency drift over multi-day scales is within its specification (according to the OCXO datasheet) of 1 ppb per day. @10MHz, 1 ppb/day = 10 mHz/day = 0.1 Hz/10 days, whereas we actually observed less than 0.05 Hz cumulative upwards frequency drift over the entire 10-day period. (Not counting the spikes of course, which are the fault of the GPS, not the OCXO.)
Anyway, this data is sufficient for a preliminary paper on the GPS time alignment; the plots just need to be prettied up a bit. Maybe add a few zooms on interesting sections.
Ray says maybe for 1st version of system we shouldn't worry about interpolating over the GPS outages - instead just throw away data during those times.
Ray says we should maybe put emphasis on a journal article rather than a conference paper. He says look at the other GPS papers we have to see what journals they were in. Mike needs to check to make sure SPIE doesn't forbid republishing results in a journal.
Ray asked me to call somebody (was it Ronnie Mackey?) about the budget check problem on the XMath, but I forgot to do it before 5 pm. Will try again tomorrow.
No comments:
Post a Comment