lid=7082 (which I believe is a somewhat similar Rb design) estimates that the lifetime of that unit doubles when baseplate temperature is reduced from 60 C to 40 C (MTBF: 243k hours => 591k hours). Note that 243k hours is about 28 years.

It gives an indication of processor/FPGA resources consumed, and can be used to estimate "margin" in a utilization review.

I am not sure if the SV6 has a "sawtooth" error message giving a good estimate on how wrong the current 1PPS pulse is/was. However improving the 1PPS output accuracy and jitter could for some uses be a useful mod. -- Björn > On 25/07/12 23:36, Ed Palmer wrote: >> Take another look at flea bay.

Yes, that setup can give you a rough estimate of the counter's noise floor. > > I can't give you specific numbers but one danger with this sort of test is that the input and the timebase are artificially locked together (i.e. fixed phase relationship) through the common reference.

Any estimate under 500 ns is questionable with that hardware. The firmware seems to be quite happy reporting numbers well below that. Bob On Nov 11, 2012, at 1:36 PM, Doug Parker wrote: > > > > Hi, > > I've got a Z3805 from one of the Chineese sources and had problems with the HP 11801 oscillator which came with it.

I'm pretty sure LH estimates the temperature coefficient in a rather inelegant way: Seems based on the graph / display window, and affected by filtering (RMS is affected by display filtering too) I've been doing measurements this past week, and posted the first set of results here: http://spaceclock.tumblr.com/post/38439854001/ As you can see, with minimal

Or if you were experimenting with your KF implementation, where you were comparing filter output (i.e. estimate of where it "should be") and tracking loop output (i.e. "where it is") would you see any discontinuity.

Let ntpd run for a few hours; use ntpq -c rv to check frequency for convergence, and offset for convergence towards zero; once those values start changing in the opposite direction, ntpd is disciplining the clock, and the values should start oscillating around its best estimates. -- Take care. Thanks, Brian Inglis

This is due to the way the GPS epoch is calculated inside the 2100 : the DATUM engineers estimated the future leap second insertions to determine GPS epochs, which was not a so good idea... Our N024 GPS board inserted insteas of the ACE board corrects this bug, as well as offering high GPS sensitivity and fast startup.

I estimate my antenna’s actual height at about +5 m high and the gps indicates -17 m. My question is will this adversely influence the accuracy of the gpsdo output?  Would there be any benefit to adjust this manually via the scpi commands?