[time-nuts] Measuring ADEV using TBolt-Tic tester

ws at Yahoo warrensjmail-one at yahoo.com
Thu Oct 13 10:11:22 UTC 2011


I know very little about the HP58503A. Any chance it is using the old 6 
channel Oncore GPS engine?
If it is like the Oncore I tested long ago, that noise was about a decade or 
so higher than the Tbolt's phase noise.

Not sure what you can call single-shot resolution. The data is reported with 
Pico second  resolution.
The cycle to cycle max phase varation, If there is not a satellite change at 
the same time, is around  0.4ns  max error.
With the very high resolution that is output, averaging  provides a lot of 
benefit.
The noise of the Tbolt's freq (PPT) output data measured about ten times 
lower than it's phase output data at 1 sec.
How it does it is anyone guess, but looks to be some sort of high speed 
averaging going on, taken over a one second time interval.

ws

*****************
----- Original Message ----- 
From: "Azelio Boriani" <azelio.boriani at screen.it


> Your work is very interesting, now I wonder what is the Tbolt
> single-shot resolution? Does the Tbolt use the analog interpolator
> method? I don't have the Tbolt, I have an HP58503A at work as the only
> reference.
>
**********************
> On 10/13/11, WarrenS <warrensjmail-one at yahoo.com> wrote:
>>
>> John wrote:
>>>I'm curious where you got the noise data for the TBolt GPS engine
>>
>>
>> Besides the measured ADEV plot I posted at
>> http://www.febo.com/pipermail/time-nuts/attachments/20111007/48d1ab68/attachment-0001.gif
>>
>> Attached is another way I've measured Phase noise of the Tbolt, to
>> optimizing its antenna system.
>> This LH plot shows a total phase noise (GPS, + TBolt + Osc) of 0.087 ns 
>> RMS
>> reading to reading variation at one second update, over a time period of 
>> 26
>> minutes using a one second disiplined loop.  This is the same as 0.87 
>> e-10
>> RMS freq noise if using a 1 second time base.
>>
>>
>> On this test, I set the Tbolt's Time Constant to 1 second and its damping 
>> to
>> 10.  (The Dac gain must be set right on to work right)
>> This causes the Tbolt's discipline loop to correct any phase error due to
>> noise on the very next 1 sec update by stepping the Oscillator's 
>> frequency.
>> This Is an easy way to measure the reading to reading phase difference 
>> using
>> just LadyHeather.
>> The data can also be interpreted.as the average RMS frequency variation 
>> over
>> 1 second, which is approximately equal to the ADEV value at a tau of one
>> second (1e-10).
>>
>> example: If the first phase reading where zero and the next one is +1ns 
>> then
>> the control loop will change the Osc freq by way of its EFC, by 1e-9 so 
>> that
>> the very next phase difference is  zero again. This makes it into a 1 sec
>> delayed TPLL (Tight Phase Lock Loop).
>>
>> I ran this same test on John's Online Tbolt. Its phase noise measured 
>> 0.13
>> ns RMS.
>> Most of the difference was caused by satellites switching during the 
>> test.
>> Each switch causes a ns or so noise spike when the number of satellites
>> changed.
>> I also tried several other test including using just one bird with no
>> switching. That was more than twice as noisy depending on which satellite
>> bird I selected.
>>
>> I'd like to see what the Phase noise is of other Tbolts using this same
>> method, especially when using a good choke ring antenna that has a good 
>> sky
>> view.
>>
>> ws
>>
>> ****************
>> ws at Yahoo wrote:
>>
>> The noise data is my measured values which I do several different ways. 
>> Some
>> of which are:
>>
>> The GPS engine value was calculated from measuring the UNFILTERED RMS 
>> noise
>> of the freq plot data using LadyHeather, backed up by the independent way 
>> of
>> looking at the  UNFILTERED 1 sec ADEV values obtained when plotting the 
>> ADEV
>> from that data using an external low noise osc.
>> The other proof that the data is unfiltered was done by black box testing 
>> of
>> small near instantaneous freq changes of 1e-10 and measuring and how long 
>> it
>> took the Tbolt plot to settle to the new freq value using different 
>> filter
>> setting.
>> The answer is that it knows the correct freq (within it's nose limits) in
>> the next 1 sec sample period when the filter is turned off.
>>
>> As for the ns phase noise that is the RMS Phase noise value from LH using 
>> a
>> good LPRO osc with it's Time constant set to many hrs.  (Phase correction 
>> TC
>> was 100K sec). The RMS noise value is very insensitive to the filter 
>> setting
>> up to 1000 seconds because most of the phase noise is slower than 1000
>> seconds.
>>
>> As far as the 4 to 10 ns day to day USNO data , that has nothing to do 
>> with
>> sub ns short term noise which I generally limit to more like a few 
>> minutes
>> of sampel time, and if there is a satellite change during the test run, 
>> then
>> I start the test over because I'm looking at GPS engine noise and not the
>> GPS noise causes by changing satellites etc.
>>
>> As far as the 4 to 10 ns over a two day period, that agrees pretty well 
>> with
>> what I see some times on a bad day.
>> On a good day I can get more like 2 to 3 ns, with a 500 sec filter, on a 
>> bad
>> day up to 5 or 6 ns.
>> For some periods lasting up to 5 to 6 hrs, I've seen numbers as low as 
>> 1.5
>> ns RMS.
>>
>> ws
>>
>> ******************
>> From: "John Ackermann N8UR"
>>
>> In that test I was just capturing the ADEV table from the TSC-5120 so 
>> don't
>> have raw phase data.
>>
>> I'm curious where you got the noise data for the TBolt gps engine --  
>> that's
>> far better than I've seen quoted before.  The Trimble data sheet that I
>> found specs the system PPS accuracy at 20 nanoseconds one sigma; they 
>> don't
>> separately spec the GPS engine.  (The data sheet for the current 
>> Thunderbolt
>> E data sheet says 15 nanoseconds.)
>>
>> The USNO says that their filtered, linear fit time transfer measurements
>> over a two day period, over the entire constellation, have an RMS 
>> residual
>> of 4 to 10 nanoseconds without SA 
>> (http://tycho.usno.navy.mil/gpstt.html).
>> That may not be apples-to-apples methodology, but it implies that
>> sub-nanosecond results may be difficult to obtain.
>>
>> John
>> ----
>>
>
>
> 




More information about the time-nuts mailing list