Wed., Nov. 30th

I'm hoping that Michael Dean & Juan Calderin will come in to the lab today and tell me that they are ready to try integrating their new timing edge-capture datapath into the system.  Emailed them to see.

Another thing I can work on today is preparing some slides with an overview of the current software design of the Python server, so the students can build their own visualization modules on top of it.

My overnight run of the GPS app is still running, currently at 75,900 seconds into the run.  I need to find my old Scilab analysis scripts (not to mention the Java file format-conversion app) and see what this data looks like.

Maybe instead of going through all that, I can just take some shortcuts to get a quick idea of what the time data is looking like.  In Cygwin, in the "/cygdrive/c/SHARED/Server Code" folder, I typed this command to extract just the PPSCNTR lines:

$ grep PPSCNTR node0.uart.trnscr > PPSCNTR.csv

Now, let's drag that file into an OpenOffice Calc window.  Ah, it truncated the import at 64K rows, but that's OK.  Oops, the last field, which is the main one of interest, still contains the NMEA checksums:

Tue Nov 29 17:55:33 2011 + 209 ms: < $PPSCNTR,0,0*58
Tue Nov 29 17:55:33 2011 + 212 ms: < $PPSCNTR,1,9999939*5A
Tue Nov 29 17:55:33 2011 + 214 ms: < $PPSCNTR,2,19999953*64
Tue Nov 29 17:55:33 2011 + 217 ms: < $PPSCNTR,3,29999966*60
...

So, let's use a Unix cut(1) command to get rid of those:

$ cut -d\* -f1 PPSCNTR.csv > PPSCNTR-trim.csv

That's better.  Now, we can add a spreadsheet column to compute the deltas.  Boy, that takes a while... OpenOffice is slow!  Had to kill the process.  Let's trim off a few lines from the end to avoid problems.  Now the valid data indices (PPS seconds) runs from 2 through 65529.  OK, based on the data, the average frequency over that interval is 10,000,012.8768.  Now we can plot the cumulative time wander relative to the average frequency as a baseline, as we've done previously:

Note we still have the usual large but brief phase glitches (off the chart), but other than these there is mostly just a pretty gradual drift, and no large divergences from this trajectory other than one noticeable discontinuity.  I don't know if we actually lost time lock at any point.  We can figure that out by looking at the PDMETRAIM figures.

Here is the self-reported accuracy from the TRAIM algorithm:

It looks like we actually lost time lock between about seconds 7,000 to 23,000.  At 7,000 is when the wander started drifting sharply upwards, then at 23,000 is a slight downwards dip to back in line with the background wander.  In the interim, was the POSHOLD mode controlling the time readings?  Bizarrely, looking in the middle of this range, it looks like there were plenty of satellites, but they were all being excluded!  Is the TRAIM algorithm broken?  Or, perhaps it's just that the signals are all getting reflected off of the nearby building and so the times are all way off?  Hard to say.

Number of satellites being received over the course of the run.

Perhaps we should set the limit of TRAIM to a larger value so that fewer satellites will be excluded?  Right now the limit is 100 ns.  Should we make it 200 ns?  Let's try that and then start another overnight run.

Looking at this graph, we can see that an unusually large number of satellites (perhaps all of them?) were eliminated by the TRAIM algorithm during the period where the self-assessed accuracy was 0.

TRAIM algorithm data.  Blue line: Self-assessed inaccuracy in seconds (left axis).
Red dots: Number of satellites eliminated by traim algorithm (right axis).

Note also that the more satellites are eliminated, generally the worse the accuracy is.  However, it's unclear in what direction the causality relation goes here.  When a lot of satellites are giving wild time readings, more of them are eliminated and so the accuracy is worse?  Or, is it that when more satellites are dropped from the calculations, there is less data to work from, and so the result of the calculation is more inaccurate?  Unclear.

Anyway, started a new run with the <traim_alarm> parameter set to 200 ns instead of 100 to see how this affects things.  At first glance, it seems like the accuracy is worse (perhaps b/c more satellites with wild readings, reflecting off Ware-Rhaney maybe, are being averaged into the calculations).  But anyway I'll leave it running overnight (or over the weekend, even) and analyze the data next time I'm in.