Friday, March 11, 2011

Fry day

Every day is (French) "fry" day when I eat lunch at McDonald's, LOL. Things for today:

1. Call the folks responsible for the ERP (Enterprise Resource Prevention) system to figure out why budget check on XMath isn't working. Ronnie Mackey left me a voicemail with their phone number 561-4357. Except that is actually the number of the Tallahassee office of the DEA. Calling the main EIT number instead & asking them to transfer me. I got someone's voicemail and left a message asking them to call me back. The requisition # in question is 0000093625.

2. Read journal articles on GPS timing, in preparation for writing paper. I printed out a bunch of articles on Wednesday; now I just need to find a more comfortable spot to sit & read them. I wonder if the library down the hall is open. Yes it is. Going to settle down there to read papers. Papers collected so far are:
  • Arceo-Miquel, Shmaliy, et al. (2009), "Optimal synchronization of local clocks by GPS 1PPS signals using predictive FIR filters;"
  • Banerjee, Suman, et al. (2007), "A study on the potentiality of the GPS timing receiver for real time applications;"
  • Berns, Burnett, et al. (2004), "GPS time synchronization in school-network cosmic ray detectors;"
  • Bullock, King, et al. (1997), "Test results and analysis of a low cost core GPS receiver for time transfer applications;"
  • Defraigne & Bruyninx (2007), "On the link between GPS pseudorange noise and day-boundary discontinuities in geodetic time transfer solutions;"
  • Ding & Wang (2008), "Time synchronisation error and calibration in integrated GPS/INS systems;"
  • Khan (2007), "Behavior of the GPS timing receivers in the presence of interference;"
  • Lewandowski & Thomas (1991), "GPS time transfer;"
  • Li, Wang, et al. (2009), "Time synchronization design based on FPGA in integrated GPS/INS system;"
  • Lombardi, Novick, et al. (2005), "Characterizing the performance of GPS disciplined oscillators with respect to UTC(NIST);"
  • Mumford (2003), "Relative timing characteristics of the one pulse per second (1PPS) output pulse of three GPS receivers;"
  • Shmaliy & Ibarra-Manzano (2010), "Recent advances in GPS-based clock estimation and steering;"
  • Skog & Händel (2010), "Time synchronization errors in GPS-aided inertial navigation systems."
3. Notes on the 1st paper (Arceo-Miquel, Shmaliy, et al., 2009). This is quite a bit beyond my present level of understanding of the field of time measurement. However, from it I learned the importance of the Allan deviation/variance for characterizing frequency stability of an oscillator. In this paper they had a cesium frequency reference (CsIII from Symmetricom) which they could use to measure the "true" time errors. In our lab, we don't have an atomic clock, so we have to make do with relative characterization (assuming the GPS has the specified accuracy). However, I requested a quote on the CsIII, to see if we might be able to afford it (maybe if the grant gets renewed). We actually got a quote on a couple of their Rubidium clocks a couple of years ago, and they were $16-19K. Symmetricom also has a chip-scale atomic clock which looks pretty interesting.

4. Some notes on the Allan deviation. Wikipedia & the 2nd paper (Banerjee & Suman) explain it pretty well. Basically, it is just the RMS difference between the average frequencies y of adjacent windows. It is plotted as a function of τ (tau), which is both the window size and the interval between the centers of adjacent windows. Let tk be the time point exactly between the adjacent windows, so then tτ and t+τ are the start time of the earlier window and the end time of the later window, respectively. Then, if x(t) denotes the cumulative phase of the measured oscillator at time t, then y(t) = τ -1[x(t+τ) − x(t)] is the average oscillator frequency for the window starting at time t, and a sample for the Allan deviation is then y(t) − y(t) = τ -1[x(tτ) - 2x(tk) + x(t+τ)]. Just average the square of these samples over a long run (as an estimator of the mean squared deviation), divide by 2 (not quite sure why), and you have σy2(τ), which is the Allan variance. Take the square root of this, and you have the Allan deviation. In our case, we may use any integer values of τ from 1 (sec.) through half the size of the run. So we could plot this. However, because the GPS is sometimes losing time lock, if we did this, we would be conflating the oscillator frequency instabilities with the instability due to the GPS losses. To untangle this, it would be nice to do a long run when we have plenty of satellites in range throughout - but this will probably require setting up the experiment on the roof. :(

5. Some notes on the integer-millisecond glitches seen during our 10-day run:
  • 1 second - 175
  • 2 secs. - 280
  • 5 s. - 3
  • 6s - 13
  • 7 - 5
  • 12 - 2
  • 13 - 1
  • 22 - 1
  • 24 - 1
It's too hard to read the raw array... Modifying the code to display stats in a readable form. I need to write some code to systematically correlate these events with things that may be going on in the GPS.

6. Started adding code to my "gps-plot.sce" SciLab script to try to correct for extra PPS pulses. Last time I had repaired these by hand, but that was a pain. I think I can correct most of them automatically. That is done now - they were all corrected automatically.

No comments:

Post a Comment