Re: [time-nuts] Cheap jitter measurements

[Lars Walenius]

I would say my implementation is simpler than Nick’s:
https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/?all
 . It is just an Arduino+ two HCMOS and a few passive components.
>From the beginning Nick copied my interpolator. Later he added a FET that 
>might act as a constant current generator but I doubt it works very well. At 
>least the variance of the FET’s are to large. The temperature stability is not 
>that good either. So far I have not seen any tests of this. The Elektor GPS by 
>Joost Breed copied Nick’s interpolator and a graph from that shows large 
>non-linearities as I can see.
My simple interpolator that I linearize in software is not perfect but able to 
get down to about 1ns linearity by setting min-max and a square term. By using 
Tom Van Baak’s PICDIV 26 it is fairly easy to set the linearity. Information is 
in the instruction found on EEVblog. In the last pages I also enclosed ADEV, 
TDEV and a frequency plot direct from Timelab that works very well with the 
controller. ADEV at 1s is 8E-10.
Also I don’t think Nick sends out the ns direct (absolutely not linearized) on 
the serial port as I do. As I said before this works very well with timelab.
After a lot of testing I also thinks both my hardware and software is robust.
Otherwise I would recommend the TAPR-TICC that I nowadays use more than my 
5370. Good resolution and much lower power dissipation.
Lars

>From: Attila Kinali
Sent: den 3 april 2018 21:04

On Tue, 3 Apr 2018 10:47:37 -0700
"Gary E. Miller"  wrote:

>> What would you guys suggest as the cheapest way to see jitter down to
>> around 1 nano second?

Look at Nick Sayers GPSDO and his interpolator. You wont get any
cheaper than that. Next best thing is to use a TDC7200 like in
the TICC.

Of course, you will need a standard that is stable enough on the
time scales you are looking at. Which is for short taus (<100s)
a good OCXO and for 1s to 10ks an Rb, and beyond that a Cs beam
standard or hydrogen maser.

Attila Kinali

--
The bad part of Zurich is where the degenerates
throw DARK chocolate at you.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Furuno GT-87

[Lars Walenius]

So the orange is the second to second timestamp difference minus 1s, or the 
period time measured every second minus 1s. As the period is very close to 1s 
the frequency difference just will be the negative value so what the graph 
shows is the same as eg Stable 32’s frequency data for 1s but negative. As in 
e.g. http://www.leapsecond.com/pages/tbolt-8d/ . Also the orange line for me 
more seems to be the difference between adjacent ”saw tooth correction data” + 
some hardware noise as the edges of the PPS is very dependent on the TCXO 
frequency for two successive edges.

The gray line seems to be more interesting as it is what I in Stable 32 believe 
is called phase data.

Would be interesting to know how Furano calculates “accuracy”.

See forward for more data from the GPS and GLONASS comparison. Don´t remember 
to have seen anything of that from someone else!
Thanks Lars




Från: time-nuts  för Mark Sims 
Skickat: Sunday, March 18, 2018 1:43:03 AM
Till: time-nuts@febo.com
Ämne: [time-nuts] Furuno GT-87

The TICC reference is a HP-5071A cesium beam oscillator with high performance 
tube.  The GT-87 is connected to the TICC channel B input.  The TICC is running 
in timestamp mode.

The orange plot is the Time Interval Error of the 1PPS signal... the difference 
between 1 second and the measured 1PPS.

The grey plot is the accumulated phase error for channel B.

I just finished the measurement of the GT87 running on GLONASS sats only.   The 
PPS span was still in the +/-4 ns range with a couple of points +/- 6 ns.   
However the ADEV measurements on the 1PPS were 3 (at tau-100 secs) to 5 times 
higher. (at tau=1 seconds).   I am typically tracking 5-8 GLONASS sats.

The GT87 sends an "accuracy" value.  In GLONASS only mode the GT87 reports an 
accuracy of 12 ns.  With GPS enabled it tends to say 5-6 ns,  but I have seen 
it as low as 2 ns.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Furuno GT-87

[Lars Walenius]

Thanks Marks,



Just a question about what reference you used for the TICC?



Another question is about the orange and gray scale with respective 8 and 22ns 
span. The orange says TIEb and the gray PHchB. What are they? You talk about 
+-4ns over 24hours but what are the 22ns span when?



Best regards

Lars




Från: time-nuts  för Mark Sims 
Skickat: Friday, March 16, 2018 1:14:25 AM
Till: time-nuts@febo.com
Ämne: [time-nuts] Furuno GT-87

Bob Darlington shipped me a GT-8736 to test.   It is a small, Motorola M12 
format GPS receiver with a claim to fame of +/- 1.7 ns sawtooth error.   I was 
unable to test it until recently because my M12 to Adafruit adapter board was 
fab'd with holes drilled too small for the 2x5 pin 0.05" M12 pin header.   I 
got in some headers and bodged one onto the top of the adapter board and used a 
cable (from Adafruit) to interconnect the two boards.

Besides the M12 binary format the GT87 can also talk Furuno ESIP format.   Lady 
Heather now fully supports ESIP data (basically just NMEA with some custom 
sentences,  similar to Furuno's PFEC protocol (which Heather also supports)... 
why Furuno  felt they needed Yet Another Protocol is beyond me).  ESIP mode 
provides better control and monitoring than the Motorola mode.   Oh, and don't 
believe/do anything you might read about putting the G87 into PFEC mode... it 
effectively bricks the unit and puts it into some unknown binary language.

The G87 supports GPS and GLONASS (with Galileo supposedly on the way) and SBAS. 
  I typically track over 22 satellites.The thing is very sensitive.   I 
disconnected the antenna from the 3" MMCX to BNC antenna pigtail I was using 
and could still track some satellites indoors.

Anyway, I connected the 1PPS output to a TAPR TICC and did some measurements.   
It's rather impressive.  The span of the 1PPS was around +/- 4 nsec over 24 
hours.  ADEV is in the mid E-13's at 10,000 seconds.  It should make for a 
rather nice GPSDO.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] ublox NEO-M8T improved by insulated chamber?

[Lars Walenius]

Hi all,



If I look on the NIST database for the last days it seems to be a daily 
variation of about 8-10ns. Could this be for the same reason as Ole’s 
variation? Is the daily variations due to not perfect ionosphere correction? 
Can you get much better than the data in the NIST database for an ordinary 
timing receiver like the LEA-6T?



https://www.nist.gov/pml/time-and-frequency-division/services/gps-data-archive



Another question: If You have an error in the surveyed position of say 3meters 
and you receive all of the available satellites in all directions how much will 
this really affect your timing?



Sorry for all the silly questions.



Lars






Från: time-nuts  för Bob Camp 
Skickat: Tuesday, November 7, 2017 8:21:44 PM
Till: Discussion of precise time and frequency measurement
Ämne: Re: [time-nuts] ublox NEO-M8T improved by insulated chamber?

Hi

If you go back into the NIST evaluations of various receiver modules ….. they 
don’t always
work best with the correct coordinates. Some have guessed there are residual 
math errors
in the devices. Others suggest the “radio side” may be at fault.  Indeed 
varying susceptibility
to multipath *might* be the answer.

Bob

> On Nov 7, 2017, at 2:12 PM, Ole Petter Ronningen  
> wrote:
>
> Yes, I thought so too - but on the same antenna I have a couple of L1/L2
> continously logging survey receivers; the position accuracy should be
> within 5-10 mm. Unless I've messed something up with coordinate systems,
> the position the UBlox thinks it has should be pretty good.
>
> Ole
>
> On Tue, Nov 7, 2017 at 5:43 PM, Jean-Louis Oneto  wrote:
>
>> Hi Ole,
>> I think that the long term undulation are caused by a (small) error in
>> geodetic position of the antenna. The period should be a sidereal day
>> (23:56...)
>> Have a good day,
>> Jean-Louis
>>
>>
>>
>> Envoyé depuis mon appareil mobile Samsung.
>>
>>  Message d'origine 
>> De : Ole Petter Ronningen 
>> Date :07/11/2017  15:15  (GMT+01:00)
>> A : Discussion of precise time and frequency measurement <
>> time-nuts@febo.com>
>> Objet : Re: [time-nuts] ublox NEO-M8T improved by insulated chamber?
>>
>> Hi all
>>
>> Attached is a 24 hour plot of PPS out from a UBlox 6T against a hydrogen
>> maser. From 00:00 the bare receiver board was inside a polystyrene box
>> where it has soaked for many months, at 16:00 I removed the box exposing
>> the board to the airflow in the room, including AC. The box was left off
>> for the rest of the day.
>>
>> The green trace is temperature in the lab. The "long term undulation" in
>> phase is normal, although I do not know the precise cause (multipath or
>> something else. I am reasonably sure it is not related to temperature in
>> the lab.
>>
>> [image: Inline image 1])
>>
>> Ole
>>
>> On Sat, Nov 4, 2017 at 6:06 PM, Denny Page  wrote:
>>
>>> [I hate finding unsent email in my folder :-]
>>>
>>> Others may disagree, but I doubt that the type of small temperature
>>> variation you are referring to has any meaningful effect on tracking.
>> While
>>> the datasheet for the M8T says that there can be "significant impact" to
>>> the specifications at “extreme operating temperatures,” it gives the
>>> operating temperature as -40 to +85 C. Simply said, if you can stand to
>> be
>>> in the same room/space with it, I think you are fine.
>>>
>>> Of much greater interest would be the antenna and it’s placement. I’m
>>> afraid I can’t specifically recommend a “good” antenna, but perhaps
>> others
>>> on the list can. For my EVK-M8T, I’m using the antenna that came with the
>>> kit and it works very well. I haven’t tested other antennas with the M8T
>> at
>>> this time, but I do have a number of other devices with antennas that
>> work
>>> well. I also have a few antennas that work poorly with all the devices,
>>> including the ones with which they came. Unfortunately pretty much all of
>>> them lack sufficient identification markings to identify
>> manufacture/model
>>> info.
>>>
>>> Regarding placement, I’ve found that in a restricted area even a few
>>> inches can have a significant impact on the average number of satellites
>>> and signal level. In my case, it’s associated with the single building
>>> structure, but it sounds your case is even more restrictive. Although it
>>> can be a very lengthy process, performing antenna surveys may help
>> improve
>>> your situation. For each location, you need to monitor the number of
>>> satellites and signal level for 24 hours or more before determining the
>>> relative merit of that location. Repeat… and repeat.. and repeat.
>>> Determining the very best location for the antenna will likely require as
>>> many antenna surveys as you have patience for. :)
>>>
>>> Hope this helps.
>>>
>>> Denny
>>>
>>>
 On Nov 02, 2017, at 18:54, MLewis  

Re: [time-nuts] Weird GPSDO behavior - update

[Lars Walenius]

Hello,

If I look on the one hour plot it look like it goes in hold mode due to zero 
used satellites. If my assumption that the light blue graph in the bottom is 
satellites it sees no satellites during about a minute and after that it 
selects a fast time constant. From the TIC offset and DAC changes, a time 
constant of 10-20 secs seems reasonable if it is a PI-loop with a low pass 
filter on the TIC value.

So nothing strange except the jump of the DAC value in hold mode. As always you 
really want to know what the firmware does.

As the satellite constellation is the same every 23h56min I guess it could be 
zero usable satellites every day at about 8am for several days.

Lars


Från: Skip Withrow
Skickat: den 4 oktober 2017 03:17
Till: time-nuts
Ämne: [time-nuts] Weird GPSDO behavior - update

Hello Time-Nuts,

Well, I think I know a little more about my GPSDO problem, but
probably have more questions now than before.  Thanks for all the
replies to the first post with thoughts and suggestions.

I first tried restarting Lady Heather and doing a cold boot on the
NTGS50AA (then entering the same disciplining values). Same behavior.

I let it run over the weekend and the same behavior happened on
Saturday and Sunday morning.

So, yesterday (Monday morning) I changed the gain to the gain of the
oscillator (.0072Hz/V), damping to 1.2, and time constant to 900s.  On
the attached PRS10-2 plot you can see that it quickly settled.  This
morning, it looks like all is well from the plot (about an hour before
the furnace kicks in at the right of the plot).  HOWEVER, when the
plot is expanded there is still funny business going on with the DAC
control voltage at the same time of day.  I just think the changed
parameters limit the disturbance.  The expanded plot is the attached
PRS10-1.

At this point I'm beginning to think that the NTGS50AA is the issue,
but there are lots of questions left.

1. There are various version of the NTBW50AA/NTGS50AA GPS/operating
firmware.  Mine is 10.3 and I notice that it has the LH 'ro'
designation (as does the 10.4 version).  The 10.5 version does not
give the LH ro notice.  Maybe it behaves better with the disciplining?
 I will have to give a 10.5 a try.

2. Why does the glitch occur at 8am in the morning?  Will have to try
powering the NTGS50AA up at different times and see it the glitch
moves around.

3. Which disciplining parameters are affected by this glitch and which are not?

4. Have other people seen this same behavior?  Does it happen on
Thunderbolts too?

I'll update again when I have more data.

Regards,
Skip Withrow

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Weird GPSDO behavior

[Lars Walenius]

If I look on the TIC graph it looks like something happen at about + or - 
500ns. Could it be that the software change algoritm? Like a ”Jam Sync”. Seems 
like it tries to get the TIC to zero quick by changing the DAC. Maybe it thinks 
it gets enough close in frequency and stops and goes back to the PI-loop with 
2 secs time constant? As the frequency seems to be off 0.7ppb the excursion 
to about 6-7 us with a 2sec PI-loop make sense and it takes about a day to 
get back in phase (to + or - 500 ns and a new cycle begins).

If the above is correct the parameters for the PI-loop work but not for the 
other ”algoritm” that has a factor of 100 wrong oscillator sensitivity.

Changing to another time constant might give another cycle different from a 
day?? But will not solve the problem I guess.

Best Regards
Lars


From: Skip Withrow
Sent: den 28 september 2017 22:25
To: time-nuts
Subject: [time-nuts] Weird GPSDO behavior

Hello Time-Nuts,

I have a NTGS50AA GPSDO (close cousin to the NTBW50AA and Thunderbolt)
with the OCXO removed and a SRS PRS-10 rubidium oscillator in its
place.  I have been running Lady Heather 5.0 and have changed the
damping, gain, and time constant to give me a 20,000 second time
constant with a damping of .6.  I have attached a Lady Heather screen
shot of the weird behavior.  You can see that my GPS antenna is in a
very none ideal location (window on the west side of the building).

Once per day (about 8am) something disturbs the system.  So, the GPSDO
spends much of its time recovering and never gives me anywhere near
the performance that this system is capable of.  I would think that it
is not the PRS-10 as it has no knowledge of time.  I would also think
that it is not the GPS system or receiver, since the GPS constellation
repeats twice per day.

Kind of the two things that I am left with are a glitch by the power
company every morning (there is some large industrial machinery across
the street (but then I would kind of expect glitches at 8am and 5pm),
and perhaps Lady Heather doing something funny.  This system has been
running for quite some time, I have not tried restarting Lady Heather
yet.

Anybody seen anything like this, or have any good ideas?

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Weird GPSDO behavior

[Lars Walenius]

If I look on the TIC graph it looks like something happen at about + or - 
500ns. Could it be that the software change algoritm? Like a ”Jam Sync”. Seems 
like it tries to get the TIC to zero quick by changing the DAC. Maybe it thinks 
it gets enough close in frequency and stops and goes back to the PI-loop with 
2 secs time constant? As the frequency seems to be off 0.7ppb the excursion 
to about 6-7 us with a 2sec PI-loop make sense and it takes about a day to 
get back in phase (to + or - 500 ns and a new cycle begins).

If the above is correct the parameters for the PI-loop work but not for the 
other ”algoritm” that has a factor of 100 wrong oscillator sensitivity.

Changing to another time constant might give another cycle different from a 
day?? But will not solve the problem I guess.

Best Regards
Lars


Från: Skip Withrow
Skickat: den 28 september 2017 22:25
Till: time-nuts
Ämne: [time-nuts] Weird GPSDO behavior

Hello Time-Nuts,

I have a NTGS50AA GPSDO (close cousin to the NTBW50AA and Thunderbolt)
with the OCXO removed and a SRS PRS-10 rubidium oscillator in its
place.  I have been running Lady Heather 5.0 and have changed the
damping, gain, and time constant to give me a 20,000 second time
constant with a damping of .6.  I have attached a Lady Heather screen
shot of the weird behavior.  You can see that my GPS antenna is in a
very none ideal location (window on the west side of the building).

Once per day (about 8am) something disturbs the system.  So, the GPSDO
spends much of its time recovering and never gives me anywhere near
the performance that this system is capable of.  I would think that it
is not the PRS-10 as it has no knowledge of time.  I would also think
that it is not the GPS system or receiver, since the GPS constellation
repeats twice per day.

Kind of the two things that I am left with are a glitch by the power
company every morning (there is some large industrial machinery across
the street (but then I would kind of expect glitches at 8am and 5pm),
and perhaps Lady Heather doing something funny.  This system has been
running for quite some time, I have not tried restarting Lady Heather
yet.

Anybody seen anything like this, or have any good ideas?

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Excel logarithmic function (was Thermal impact on OCXO)

[Lars Walenius]

Hi Scott.

Here is a textfile with data for the 10 years (As in the graph 2001-2011).

Also the ln(bt+1) fit, as Magnus said, has the derivate b/(b*t+1) that with b*t 
>>1 is 1/t. But my data has the aging between 1 and 10 years more like 
1/sqrt(t) If I just have a brief look on the aging graph.

Lars

Från: Scott Stobbe<mailto:scott.j.sto...@gmail.com>
Skickat: den 19 november 2016 04:11

Hi Lars,

I agree with you, that if there is data out there, it isn't easy to find,
many thanks for sharing!

Fitting to the full model had limited improvements, the b coefficient was
quite large making it essentially equal to the ln(x) function you fitted in
excel. It is attached as "Lars_FitToMil55310.png".

So on further thought, the B term can't model a device aging even faster
than it should shortly after infancy. In the two extreme cases either B is
large and (Bt)>>1 so the be B term ends up just being an additive bias, or
B is small, and ln(x) is linearized (or slowed down) during the first bit
of time.

You can approximated the MIL 55310 between two points in time as

f(t2) - f(t1) = Aln(t2/t1)

A = ( f(t2) - f(t1) )/ln(t2/t1)

Looking at some of your plots it looks like between the end of year 1 and
year 10 you age from 20 ppb to 65 ppb,

A ~ 20

The next plot "Lars_ForceAcoef", is a fit with the A coefficient forced to
be 2 and 20. The 20 doesn't end-up fitting well on this time scale.

Looking at the data a little more, I wondered if the first 10 day are going
through some behavior that isn't representative of long-term aging, like
warm-up, retrace (I'm sure bob could name half a dozen more examples). So
the next two plots are fits of the 4 data points after day10, and seem to
fit well, "Lars_FitAfterDay10.png", "Lars_1Year.png".

If you are willing to share the next month, we can add that to the fit.

Cheers,

On Fri, Nov 18, 2016 at 1:26 PM, Lars Walenius <lars.walen...@hotmail.com>
wrote:
>
> Hopefully someone can find the correct a and b for a*ln(bt+1) with
stable32 or matlab for this data set:
> Days ppb
> 2   2
> 4   3.5
> 7   4.65
> 8   5.05
> 9   5.22
> 12 6.11
> 13 6.19
> 25 7.26
> 32 7.92

daysppb
2   2
4   3.5
7   4.65
8   5.05
9   5.22
12  6.11
13  6.19
25  7.26
32  7.92
33  8.15
39  8.42
46  8.92
46  9.18
47  9.02
54  9.51
60  9.78
74  10.45
83  11.36
92  11.78
97  12.08
110 12.8
128 13.6
158 14.7
193 15.9
224 16.9
254 18
284 19.01
314 20
343 21.1
375 22.3
417 23.7
445 24.8
476 25.7
515 26.7
545 27.7
586 28.8
615 29.4
646 30.2
672 30.7
703 31.4
743 32.2
787 33.5
826 34.6
861 35.3
904 36.2
940 37
976 37.7
101038.5
104639.1
107239.5
108138.3
112438.6
116339.6
120140.5
123941.2
128542.2
132043
135743.6
139844.4
143245
146745.7
150146.3
153447.1
156047.7
159748.4
162848.9
165949.3
168749.9
171850.35
174850.7
177951.2
180951.5
185052
188652.6
191453
194753.45
198453.9
201954.3
204554.5
207154.7
211655.11
213254.97
216555.27
219855.63
223056
226556.5
230957
234657.4
238957.85
243458.35
247358.7
251359
255059.3
258759.65
262560
266460.35
269660.6
272960.85
276461.15
279661.4
282961.6
286361.85
289862.1
293562.4
297262.8
300763.12
304363.47
307863.73
311464.05
314964.3
318464.5
322464.75
325964.96
329565.23
333265.54
336865.82
340666.09
344166.33
348266.55
351966.72
356367.01
360467.22
364767.59
369268.02
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Excel logarithmic function (was Thermal impact on OCXO)

[Lars Walenius]

Bob,
I have to ask about the B-term. In the paper that Scott started this with I see 
that B was 4.45. But if I understand you correct Bt<1 even at 30days is normal? 
That would mean a B of <0.033?

Lars

>Bob wrote:
>In a conventional fit situation, you have < 30 days worth of data and the 
>“time constant”
is > 30 days. Put another way bt <= 1 in the normal case. It is only when you 
go out to years
that bt gets large.

Bob

>> On Nov 18, 2016, at 9:58 PM, Scott Stobbe <scott.j.sto...@gmail.com> wrote:
>
> Hi Lars,
>
> I agree with you, that if there is data out there, it isn't easy to find,
> many thanks for sharing!
>
> Fitting to the full model had limited improvements, the b coefficient was
> quite large making it essentially equal to the ln(x) function you fitted in
> excel. It is attached as "Lars_FitToMil55310.png".
>
> So on further thought, the B term can't model a device aging even faster
> than it should shortly after infancy. In the two extreme cases either B is
> large and (Bt)>>1 so the be B term ends up just being an additive bias, or
> B is small, and ln(x) is linearized (or slowed down) during the first bit
> of time.
>
> You can approximated the MIL 55310 between two points in time as
>
> f(t2) - f(t1) = Aln(t2/t1)
>
> A = ( f(t2) - f(t1) )/ln(t2/t1)
>
> Looking at some of your plots it looks like between the end of year 1 and
> year 10 you age from 20 ppb to 65 ppb,
>
> A ~ 20
>
> The next plot "Lars_ForceAcoef", is a fit with the A coefficient forced to
> be 2 and 20. The 20 doesn't end-up fitting well on this time scale.
>
> Looking at the data a little more, I wondered if the first 10 day are going
> through some behavior that isn't representative of long-term aging, like
> warm-up, retrace (I'm sure bob could name half a dozen more examples). So
> the next two plots are fits of the 4 data points after day10, and seem to
> fit well, "Lars_FitAfterDay10.png", "Lars_1Year.png".
>
> If you are willing to share the next month, we can add that to the fit.
>
> Cheers,
>
> On Fri, Nov 18, 2016 at 1:26 PM, Lars Walenius <lars.walen...@hotmail.com>
> wrote:
>>
>> Hopefully someone can find the correct a and b for a*ln(bt+1) with
> stable32 or matlab for this data set:
>> Days ppb
>> 2   2
>> 4   3.5
>> 7   4.65
>> 8   5.05
>> 9   5.22
>> 12 6.11
>> 13 6.19
>> 25 7.26
>> 32 7.92
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Thermal impact on OCXO

[Lars Walenius]

Thanks Azelio,

I have also thought that the EFC range probably says something. The datasheet 
for the OFC4834 says EFC range +-0.4ppm and that that should be enough for 15 
years. The OFC MC834, I have seems very similar, but without EFC. So my 68ppm 
drift is well within the +-400ppb

Lars

>From: Azelio Boriani
>Sent: den 19 november 2016 02:01
>One starting point to figure out the 10 years aging can be the
datasheet of an OCXO:
MTI240: per year, 3.0E-7, in 10 years must be less than 30.0E-7
MTI220: per year, 1.0E-6, in 10 years < 10.0E-6
Bliley NV26R: 17 years, 5.0E-6
OSA8663: per year, 3.0E-8, in 10 years < 30.0E-8

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Thermal impact on OCXO

[Lars Walenius]

Hi Bob,

I was afraid that the answer should be like this (smile).

One paper from MTI that probably confirms that aging prediction is difficult:

http://www.mti-milliren.com/MTIPapers/Ext_Aging_Perf_Results.pdf

Lars


From: Bob Camp<mailto:kb...@n1k.org>
Sent: den 19 november 2016 00:23

Hi
> On Nov 18, 2016, at 1:31 PM, Lars Walenius <lars.walen...@hotmail.com> wrote:
>
> Hi Bob (and all others),
>
> I agree to all your points but am curious to your comment: ”that OCXO is 
> aging a lot for one that has been on that long”.
> As I have only done this test and seen no other test of OCXO´s powered over 
> at least ten years, I have no idea what is reasonable. I also guess I will 
> not do another test of an OCXO powered and measured over ten years again.
>
> Could you give some examples what is reasonable for aging after ten years? 
> Maybe others have data? I have searched internet and it isn´t easy to find 
> long-term data on OCXO’s (at least for me).

The only people I know of that have the gear and the interest to run a number 
of OCXO’s are oscillator manufacturers. They also track parts
in the field by various methods. The data takes real effort to collect and thus 
is “part of our IP”.

Bob

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Thermal impact on OCXO

[Lars Walenius]

Hi Bob (and all others),

I agree to all your points but am curious to your comment: ”that OCXO is aging 
a lot for one that has been on that long”.
As I have only done this test and seen no other test of OCXO´s powered over at 
least ten years, I have no idea what is reasonable. I also guess I will not do 
another test of an OCXO powered and measured over ten years again.

Could you give some examples what is reasonable for aging after ten years? 
Maybe others have data? I have searched internet and it isn´t easy to find 
long-term data on OCXO’s (at least for me).

This oscillator drifted about 60ppm between 1month on to ten years on . Do 
others have figures what is reasonable over this time span?

For point 1: Is it possible from the aging curve to have some ideas what is 
going on??

Lars

>Från: Bob Camp<mailto:kb...@n1k.org>
>Skickat: den 17 november 2016 01:03
>Hi

>Your data demonstrates a couple of things:

>1) There are a number of different things going on with that OCXO and some 
>things are a lot less predictable than others.
>2) Oscillators do drop rate while on power.
>3) Oscillators that age a lot are easier to model (yes, that OCXO is aging a 
>lot for one that has been on that long).

>Bob

>> On Nov 16, 2016, at 2:41 PM, Lars Walenius <lars.walen...@hotmail.com> wrote:
>>
>> FWIW. Between 2001 and 2011 I run a 5MHz OCXO (in a box). It is a 2x3inch 
>> type without EFC marked OFC MC834X4-009W with date code 97. Probably it was 
>> from some base station testing and it had been sitting in my shelf since 98. 
>> The OCXO were battery backed but at two occasions (2004 and 2007) we had 
>> power fails that drained the battery as can be seen in the graph.
>>
>> Just out of curiosity I yesterday put just the first thirty days (like in 
>> the pdf mentioned below) and let Excel calculate the logarithmic function. 
>> If I extrapolate that to 10 years it seems that the drift would be 6E-13/day 
>> but as can be seen in the aging graph it was more like ten times higher.
>>
>> Some days ago I started the OCXO again after it had been on the shelf for 
>> more than 4 years. Enclosed is a graph for the first 7 days. After six and 
>> half days it seems to be a jump of about 1.5E-10 and as I have no indication 
>> of anything else I believe it is from the OCXO.
>>
>> /Lars

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Excel logarithmic function (was Thermal impact on OCXO)

[Lars Walenius]

Bob wrote:
>As mentioned earlier in this thread. The function that has been used in 
>several posts
>isn’t the right log function. The proper fit is to ln(bt+1)

You are absolutely right. It was my mistake to use the ln(t) in the graph. As 
that was what I know in Excel and I don´t have Stable32 or MatLab. In Excel I 
actually double checked that (a*ln(bt+1)) with b 5 to 1000 gave about the same 
as (a*ln(t)) for my data set (only the offset was largely different).

Hopefully someone can find the correct a and b for a*ln(bt+1) with stable32 or 
matlab for this data set:
Days ppb
2   2
4   3.5
7   4.65
8   5.05
9   5.22
12 6.11
13 6.19
25 7.26
32 7.92

It would also be interesting if I could get the drift after 10 years to see if 
it is about 6E-13/day as with the ln(t).


Peter wrote:
>> I'm not very good with Excel, but this curve-fitting function sounds very
>> useful.  Could you please tell me how it's done?

In the graph I only right-clicked the curve and selected ”add trendline” here I 
checked the logarithmic and show equation.

Lars

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Thermal impact on OCXO

[Lars Walenius]

Many thanks to Dan!

A question: About what temperature span has it been during these runs? Or do 
you have the temperature coefficient? Seems that the yellow line has about 
50ppt due to temperature.

For the orange it seems to me to have about 6E-12/day aging, is that high? 
Compared to the Tbolts Tom showed they seems to be very good. (Hope Tom will 
publish temperature data soon)

Lars


Från: Bob Stewart
Skickat: den 7 november 2016 22:41

My friend and mentor Dan Kemppainen's posts apparently aren't making it to the 
list so I thought I'd forward this one.
Bob

 Forwarded Message 
Subject: Re: Thermal impact on OCXO
Date: Sun, 06 Nov 2016 12:00:23 -0500
From: d...@irtelemetrics.com


For what it's worth, Some data from a few of Bob's units:

This is the EFC data for 4 separate units over the last 1120 Hours.
Since the EFC ranges are different for some of the oscillators, the EFC
value has been converted to uHz for each unit. The uHz is more
meaningful to me on the same graph.

Interestingly the Grey and Yellow traces exhibit quite a bit of wander,
but a linear best fit puts them nearly flat. Although basically
meaningless numbers the linear fit is at 8e-14 and 3e-15 in this graph.
Now, these units do exhibit a somewhat high correlation between
temperature and DAC change, but that data isn't handy right now. It's
sort of buried here, as these are long term graphs.

The Green trace looks pretty nice, even if you consider the 1.3e-12 per
day drift. This unit has basically no correlation between DAC and
temperature.

The orange trace, well lets just say this oscillator may get replaced
someday. It exhibits both exhibits a high DAC to temperature
correlation, and long term drift. It just won't settle down.

As best as I can determine from these units the temperature dependence
and long term drift is mostly from the oscillator. The long term drift
of the EFC appears to be minimal as does the thermal drift of the EFC
circuit. However as Bob Camp and others have pointed out is is not
trivial to measure such things, so take my conclusions with a grain of salt.


Dan








___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Thermal impact on OCXO

[Lars Walenius]

FWIW. Between 2001 and 2011 I run a 5MHz OCXO (in a box). It is a 2x3inch type 
without EFC marked OFC MC834X4-009W with date code 97. Probably it was from 
some base station testing and it had been sitting in my shelf since 98. The 
OCXO were battery backed but at two occasions (2004 and 2007) we had power 
fails that drained the battery as can be seen in the graph.

Just out of curiosity I yesterday put just the first thirty days (like in the 
pdf mentioned below) and let Excel calculate the logarithmic function. If I 
extrapolate that to 10 years it seems that the drift would be 6E-13/day but as 
can be seen in the aging graph it was more like ten times higher.

Some days ago I started the OCXO again after it had been on the shelf for more 
than 4 years. Enclosed is a graph for the first 7 days. After six and half days 
it seems to be a jump of about 1.5E-10 and as I have no indication of anything 
else I believe it is from the OCXO.

/Lars

>On Mon, Nov 7, 2016 at 10:34 AM, Scott Stobbe 
>wrote:

> Here is a sample data point taken from http://tycho.usno.navy.mil/ptt
> i/1987papers/Vol%2019_16.pdf; the first that showed up on a google search.
>
>  Year   Aging [PPB]  dF/dt [PPT/Day]
> 1   180.51   63.884
> 2   196.6531.93
> 5  218   12.769
> 9   231.69   7.0934
>10   234.156.384
>25255.5   2.5535
>
> If you have a set of coefficients you believe to be representative of your
> OCXO, we can give those a go.
>
>

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Thunderbolt spurs on 10MHz output at 100Hz and 200Hz from signal.

[Lars Walenius]

What is the specification for the Spectrum analyzer? They don´t tend to be 
useful for OCXO measurments so is this especially good? Or is it only the 
Analyzer phase noise we see?



Lars



Från: David C. Partridge
Skickat: den 18 september 2016 14:43
Till: 'Bruce Griffiths'; 'Discussion of 
precise time and frequency measurement'
Ämne: Re: [time-nuts] Thunderbolt spurs on 10MHz output at 100Hz and 200Hz from 
signal.



I've just redone the measurement without the external attenuator and with 10dB 
attenuation set internally to the analyser.

The results are attached.

Dave

-Original Message-
From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Bruce Griffiths
Sent: 18 September 2016 12:52
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Thunderbolt spurs on 10MHz output at 100Hz and 200Hz 
from signal.

The signal level is also very low.
Brue

On Sunday, 18 September 2016 11:47 PM, Magnus Danielson 
 wrote:


 The phase-noise still looks fairly high. How do you measure this?

Cheers,
Magnus

On 09/18/2016 01:27 PM, David C. Partridge wrote:
> Now that's interesting I just re-ran the measurement, and got a quite 
> different result which is attached.  The spurs have GONE.
>
> My only guess right now is that the E4406A power supply is getting quieter as 
> it has been on for longer (I've only had it powered for short periods before 
> now).
>
> Dave
>
> -Original Message-
> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of
> Magnus Danielson
> Sent: 18 September 2016 11:56
> To: time-nuts@febo.com
> Cc: mag...@rubidium.se
> Subject: Re: [time-nuts] Thunderbolt spurs on 10MHz output at 100Hz and 200Hz 
> from signal.
>
> Hi,
>
> On 09/18/2016 12:26 PM, David C. Partridge wrote:
>> The local power is 50Hz, so I can understand the 100Hz spurs, but I
>> don't quite "get" where the 200Hz spurs are coming from.  Or is that
>> just BAU harmonics?
>
> Consider full-wave rectification of 50 Hz, the power consumption load
> on the capacitor after the rectifier creates an inverse sawtooth wave
> of
> 100 Hz, and sawtooth waveshape have both even and odd harmonics.
>
> While much of this is regulated out in the next step, some of it makes it 
> though.
>
> Cheers,
> Magnus
>
>>
>>
>> Thanks
>>
>> Dave
>>
>>
>>
>> ___
>> time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>>
> ___
> time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
>
>
> ___
> time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to 
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.



___
time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to 
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] A new take on the all-hardware GPSDO concept

[Lars Walenius]

Hi Nick,

Jim Millers design is very clever and as I see can give results as good as a 
digital approach but it has the same limitations:
The GPS jitter and the oscillator jitter in combination with the loop bandwidth.

The only ADEV I have seen for the Miller GPSDO is this one  
http://www.leapsecond.com/pages/gpsdo/  .
Can anyone point me to other tests?

The ADEV I see on leapsecond.com indicates for me a time constant of around 
200seconds. That is what you get with a OCXO range of 0.25ppm. You don´t need 
to have a large RC-filter. The original R1-C1 time constant with 16 seconds 
time constant will work as long as the internal oscillator in the Jupiter-T is 
at least some Hz away from a multiple of 10kHz. If that is true the sawtooth 
out of the Jupiter will have enough high frequency to be easily filtered by the 
RC. This is of course a risk. See for example: 
https://www.febo.com/pipermail/time-nuts/2005-August/019106.html . If you get a 
hanging bridge you have at least as much trouble as a non sawtooth corrected 
GPSDO and probably much worse as the RC filter is only 16s. In the digital 
approach the prefilter may filter away the hanging bridge (in best case).

As I understand the Miller GPSDO with a OCXO with a 0.25ppm range and 10kHz 
into an XOR phase detector and 16s RC will be very similar to a digital 
approach with a TIC (Time interval counter ) with +-25us range followed by a 
prefilter with time constant 16s and a loop with just the P-term with a time 
constant of 200secs. As it has no I-term it will have slightly less noise but 
the output phase will drift as soon as the OCXO drifts (as a FLL). The 
resolution of the XOR phase detector (TIC) will be limited by the noise but as 
0.1mV is 1ns the resolution can be seen as better than 1ns is my conclusion. A 
problem might be that the output of the XOR drifts with the 5V supply but this 
can be seen as the same problem as the DAC drift in a digital approach.

My conclusion (without testing) is that the Jupiter-T 10kHz is very good but 
not better than the sawtooth corrected outputs from M12 or LEA6T receivers. 
That is the ADEV can be approximated by 1E-9/Tau (1E-12 at 1000s) in good 
conditions.

My experience with the Venus838-T is only 2 weeks but disappointing. This can 
also be guessed from the datasheet ADEV curve, that I guess is sawtooth 
corrected values as it starts at 3E-9 at 1s, but is only 1E-11 at 1000s a 
factor 10 worse than I get with the LEA-6T with the same antenna and setup. If 
anyone have ADEV-MDEV curves to share I would be glad to see what can be 
achieved with the venus838-T. My conclusion is also that sawtooth correction is 
useless on my 838-T.

Lars


>Nick wrote:

>Jim Miller's 10 kHz GPSDO that’s been referenced here has either solved this 
>problem, or the 10 kHz output of the >Jupiter is substantially better than the 
>Venus’ 10 MHz output, or the design doesn’t give the results time-nuts expect 
>>from a GPSDO. Which of those applies?


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Jim Miller simple GPSDO

[Lars Walenius]

Interesting. Maybe not the optimum oscillator for a GPSDO.

Lars


>Från: Tim Shoppa<mailto:tsho...@gmail.com>
Skickat: den 14 september 2016 14:39


There are special "wide-pull-range" VCXO's where a 10MHz unit will indeed
have sensitivity of 600Hz/V or more. e.g.
http://www5.epsondevice.com/en/products/vcxo_standard/vg4231ca.html

I don't know exactly what Epson does inside that particular unit, but a
trick to get wide pull range with discrete circuits is to put two or more
crystals in parallel.

Tim N3QE

>>On Wed, Sep 14, 2016 at 4:40 AM, Lars Walenius <lars.walen...@hotmail.com>
wrote:

> The VCXO sensitivity given is strange as it indicates a far to wide span
> so I guessed 30ppm and if it is higher it still needs the damping from
> R2-C2.
> For the OCXO I used the figures given. With 2Hz per volt and 8 Volt span
> you have 16Hz of span. 16Hz divided with 10MHz is 1.6ppm (parts per
> million) can also be said as 1.6us/s.
>
> Lars
>

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Jim Miller simple GPSDO

[Lars Walenius]

The VCXO sensitivity given is strange as it indicates a far to wide span so I 
guessed 30ppm and if it is higher it still needs the damping from R2-C2.
For the OCXO I used the figures given. With 2Hz per volt and 8 Volt span you 
have 16Hz of span. 16Hz divided with 10MHz is 1.6ppm (parts per million) can 
also be said as 1.6us/s.

Lars

>From: Bryan _
Sent: den 14 september 2016 03:59

>Lars:
Thank you very much, your explanation was very helpful. I unfortunately don't 
have a background in electronics other than at a hobbyist level, and really 
should just lurk in the back as many of the topics discussed are way above me, 
but I am learning . So forgive this obvious and perhaps dumb question but 
how are you calculating the oscillator spans, you reference the VCXO at around 
30ppm. I suspect this is because the VCXO has a sensitivity of 600-1000hz/v and 
the OCXO of 1.6ppm has a sensitivity of 2hz/v or 3.2/v at 8v. But how are you 
arriving at the ppm values?
-=Bryan=-

>> From: lars.walen...@hotmail.com
> To: time-nuts@febo.com
> Date: Tue, 13 Sep 2016 20:44:50 +
> Subject: Re: [time-nuts] Jim Miller simple GPSDO
>
> As I have understood it the change of VCXO gain is the reason that R2-C2 can 
> be omitted. With the VCXO with a large span the damping is needed otherwise 
> it will oscillate.
>
> The XOR phase detector has a range of 50us with 10kHz in.  The VCXO has maybe 
> a span of 30ppm (us/s) and with R1-C1 time constant of about 16seconds the 
> phase shift will be close to 180 degrees.
>
> With the OCXO with a span of 1.6ppm (us/s) the apparent time constant will be 
> about 32 (50/1.6) seconds and the 16 seconds time constant of the R1-C1 will 
> act more as a low pass filter at gain cross over with a phase shift much 
> below 90 degrees.
>
> Sorry for the bad explanation but what I try to say is: If the phase detector 
> range  divided with the VCXO span is larger than the R1-C1 time constant 
> R2-C2 can be omitted.
>
> This thread on EEVblog might be interesting for those that think of using the 
> Miller-style GPSDO:
> http://www.eevblog.com/forum/projects/my-u-blox-lea-6t-based-gpsdo-(very-scruffy-initial-breadboard-stage)/msg938013/#msg938013
>
> Lars
>
> >From: Bryan _
> >Sent: den 12 september 2016 10:49
>
> >Thank you for the reply.
> Yes, R1/R2/C1/C2 is what I was referencing. I was not sure as the values in 
> the schematic are referenced when using the C-MAC (now RAKON) VCXO. Further 
> into the material the author switched to a Isotemp 134-10 OCXO and used a DC 
> amplifier to compensate for the 0-8v for the EFC, but stated that R2 and C2 
> are not needed when using this OCXO. Not sure why they are omitted, is it 
> because of the DC amplifier or because of different specs of the OCXO?
> http://www.jrmiller.demon.co.uk/projects/ministd/dcamp.gif
>
> -=Bryan=-
>
> >> Date: Mon, 12 Sep 2016 01:25:53 -0700
> > From: wb6...@cox.net
> > To: time-nuts@febo.com
> > Subject: Re: [time-nuts] Jim Miller simple GPSDO
> >
> > Hi Bryan,
> >
> > No !  Assuming you mean R1/R2/C1/C2 of the Miller schematic, those
> > values are already set for the comparison frequency (10KHz) of the PLL
> > phase comparator (U2).
> >
> > BillWB6BNQ
> >
> >
> > Bryan _ wrote:
> >
> > >Hello:
> > >I have been following the Jim Miller simple GSDO build project at 
> > >http://www.jrmiller.demon.co.uk/projects/ministd/frqstd0.htm  I have a  
> > >few OCXO's kicking around, but wondering what would the appropriate 
> > >components be for for  R1,R2, C1, C2 to provide the PLL filter. I assume 
> > >the PLL filter needs to be designed to accommodate a specific oscillator 
> > >specifications, or maybe it doesn't really matter and can use the default 
> > >values in the schematic?.
> > >Was also considering using a picdiv instead of the 2- 74HC390, not sure if 
> > >that would be an advantage or disadvantage in terms of operating 
> > >performance?
> > >Cheers

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Lady Heather's Tbolt oscillator auto-tune function

[Lars Walenius]

Can anybody say more about the integrator term in the Tbolt? In the Arduino 
GPSDO I have, I use 1/TC/TC/damping and use damping = 2. I see Nick Sayer do 
the same but use damping 1.75. Simulations I have done in Excel seems to 
indicate that a damping in my sense of about 3 could be better to minimize 
overshoots.

Having looked at old data I have found on Time nuts seems to indicate that the 
Tbolt uses 1/TC/TC/damping/damping/2?

Lars

>Warren wrote:

>If you have a good antenna setup and a constant temperature environment:

>The way to get the lowest noise over short time periods on a TBolt is to set
the TC setting as high as you can (typically 500 to 1000+), and set the
Damping factor as fast as you can (typically 0.7 to 1).

>The reason is that the Tbolt has a simple basic PI phase lock loop
controller.
>The Proportional gain is a function of 1/TC and the Integrator gain is a
function of the damping.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Jim Miller simple GPSDO

[Lars Walenius]

As I have understood it the change of VCXO gain is the reason that R2-C2 can be 
omitted. With the VCXO with a large span the damping is needed otherwise it 
will oscillate.

The XOR phase detector has a range of 50us with 10kHz in.  The VCXO has maybe a 
span of 30ppm (us/s) and with R1-C1 time constant of about 16seconds the phase 
shift will be close to 180 degrees.

With the OCXO with a span of 1.6ppm (us/s) the apparent time constant will be 
about 32 (50/1.6) seconds and the 16 seconds time constant of the R1-C1 will 
act more as a low pass filter at gain cross over with a phase shift much below 
90 degrees.

Sorry for the bad explanation but what I try to say is: If the phase detector 
range  divided with the VCXO span is larger than the R1-C1 time constant R2-C2 
can be omitted.

This thread on EEVblog might be interesting for those that think of using the 
Miller-style GPSDO:
http://www.eevblog.com/forum/projects/my-u-blox-lea-6t-based-gpsdo-(very-scruffy-initial-breadboard-stage)/msg938013/#msg938013

Lars

>From: Bryan _
>Sent: den 12 september 2016 10:49

>Thank you for the reply.
Yes, R1/R2/C1/C2 is what I was referencing. I was not sure as the values in the 
schematic are referenced when using the C-MAC (now RAKON) VCXO. Further into 
the material the author switched to a Isotemp 134-10 OCXO and used a DC 
amplifier to compensate for the 0-8v for the EFC, but stated that R2 and C2 are 
not needed when using this OCXO. Not sure why they are omitted, is it because 
of the DC amplifier or because of different specs of the OCXO?
http://www.jrmiller.demon.co.uk/projects/ministd/dcamp.gif

-=Bryan=-

>> Date: Mon, 12 Sep 2016 01:25:53 -0700
> From: wb6...@cox.net
> To: time-nuts@febo.com
> Subject: Re: [time-nuts] Jim Miller simple GPSDO
>
> Hi Bryan,
>
> No !  Assuming you mean R1/R2/C1/C2 of the Miller schematic, those
> values are already set for the comparison frequency (10KHz) of the PLL
> phase comparator (U2).
>
> BillWB6BNQ
>
>
> Bryan _ wrote:
>
> >Hello:
> >I have been following the Jim Miller simple GSDO build project at 
> >http://www.jrmiller.demon.co.uk/projects/ministd/frqstd0.htm  I have a  few 
> >OCXO's kicking around, but wondering what would the appropriate components 
> >be for for  R1,R2, C1, C2 to provide the PLL filter. I assume the PLL filter 
> >needs to be designed to accommodate a specific oscillator specifications, or 
> >maybe it doesn't really matter and can use the default values in the 
> >schematic?.
> >Was also considering using a picdiv instead of the 2- 74HC390, not sure if 
> >that would be an advantage or disadvantage in terms of operating performance?
> >Cheers
> >
> >___
> >time-nuts mailing list -- time-nuts@febo.com
> >To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> >and follow the instructions there.
> >
> >
> >
>
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Tbolt issues

[Lars Walenius]

You are absolute right in that it is a that depends sort of things. 

Fast temperature changes might really be something that upsets a GPSDO 
especially if the time constant is long. 

By taking temperature data and multiply with your oscillators temperature 
coefficient you can do ADEV for the temperature dependence. Quite interesting 
especially with an HVAC or the sun shining on the GPSDO! Or you can simply take 
the maximum temperature shift x temperature coefficient for the same time as 
your GPSDO  time constant to estimate the frequency error you can have 
depending on the temperature. Of course that is also a that depend sort of 
thing but at least gives an indication. Say that you have for example a time 
constant of 1000secs and a temperature change of 2°C during 1000secs and a 
temperature coefficient of 5E-11/°C that will give you a change of 1E-10 and 
the loop will not manage to compensate for it in time.

Lars

>From: Bob
>Skickat: den 2 september 2016 22:00

>Since the measurement in the frequency domain is a "peak" measure, you need to 
>convert both to frequency error and to an absolute max. If you *do* care about 
>the one second per day (or 10 days) as some do, that is a different factor 
>than one second out of two minutes. Since the noise is likely not to be white 
>noise, the factor is one of those "that depends" sort of things. It includes 
>messy stuff like the room temperature changes and the control loop's response 
>to them. In some designs the response may be multi level. The temp transient 
>hits the voltage reference, DAC, and crystal in the OCXO at different times...

>Bob

>> On Sep 2, 2016, at 3:08 PM, Lars Walenius <lars.walen...@hotmail.com> wrote:
> 
> I might be completely wrong with my ”quick rule of thumb” (frequency 
> accuracy: 10x the worst ADEV at all Taus longer than the gate time). but my 
> assumptions are these:
> 
> 1. You have a GPSDO. (A free running oscillator as a rubidium or OCXO will 
> not work if that is what you call a ”normal” frequency standard).
> 2. The GPSDO design is such that the frequency error goes towards zero the 
> longer time you measure the frequency. Otherwise you can say nothing from the 
> ADEV to the absolute frequency error I think.
> 3. ADEV can be seen as the standard deviation of all differences in frequency 
> between two nearby frequency measurements (with no dead times) multiplied 
> with a small factor (sqrt 0.5).
> 4. Absolute frequency errors will at least be in the same range as the 
> differences if the long-term error is near zero.
> 5. It will always be larger frequency errors for shorter times. My assumption 
> is for example that at 100 seconds you have 30ppt frequency error that is 3ns 
> drift in 100seconds, If you plot that as straight line you will also have 
> 30ppt at all shorter ”gate times”. If the line isn´t straight you will always 
> find ”points” that has more than 30ppt frequency errors.
> 6. At least around the Taus similar to the time constant of the GPSDO 
> especially the GPS noise will give peak frequency errors compared to the 
> average that are quite high. A factor of ten may be very conservative but as 
> can be seen in the Tbolt measurements by TvB it is quite close. With OCXO and 
> Rb GPSDO´s that I have tried to optimize I have seen about this factor or 
> slightly less. With the DOT050 VCTCXO the ratio was even higher, up to 14 
> (ADEV 7E-11 1-100secs and 1E-9 max freq errors at 1 second gate time).
> 
> Lars
> 
>> From: Bob
>> Sent: den 2 september 2016 15:20
> 
>> The GPSDO might have an ADEV of 1 ppt at 1 sec and that rises to 30 ppt at 
>> 100 sec. It also might not, but let's use those numbers.
> 
>> ADEV is a standard deviation. You can get an idea of the magnitude of the 
>> change reading to reading from it. It does not give you a sign for that 
>> change. In the case above, it is a good bet that you see strings of 1 sec 
>> data with mostly the same sign.  They have to add up to the 30X larger 
>> number when tau gets to 100 sec.
> 
>> That creates a major problem if you just look at the 1 sec data. A "normal" 
>> frequency standard does not have a rise or bump like that in the ADEV plot. 
>> Thus the quick rule of thumb stuff falls apart. The correct way to do it 
>> will always be to work out what the noise process is and calculate based on 
>> it. That is not a popular thing to do 
> 
>> Bob
> 
>> On Sep 2, 2016, at 6:38 AM, Lars Walenius wrote:
>> 
>> Hello Bert,
>> 
>> For me your findings look very much the same as this:
>> http://www.leapsecond.com/pages/tbolt-8d/ 
>> At least for me I should say the (absolute) frequency accuracy for this 
>> Tbolt 

Re: [time-nuts] Tbolt issues

[Lars Walenius]

I might be completely wrong with my ”quick rule of thumb” (frequency accuracy: 
10x the worst ADEV at all Taus longer than the gate time). but my assumptions 
are these:

1. You have a GPSDO. (A free running oscillator as a rubidium or OCXO will not 
work if that is what you call a ”normal” frequency standard).
2. The GPSDO design is such that the frequency error goes towards zero the 
longer time you measure the frequency. Otherwise you can say nothing from the 
ADEV to the absolute frequency error I think.
3. ADEV can be seen as the standard deviation of all differences in frequency 
between two nearby frequency measurements (with no dead times) multiplied with 
a small factor (sqrt 0.5).
4. Absolute frequency errors will at least be in the same range as the 
differences if the long-term error is near zero.
5. It will always be larger frequency errors for shorter times. My assumption 
is for example that at 100 seconds you have 30ppt frequency error that is 3ns 
drift in 100seconds, If you plot that as straight line you will also have 30ppt 
at all shorter ”gate times”. If the line isn´t straight you will always find 
”points” that has more than 30ppt frequency errors.
6. At least around the Taus similar to the time constant of the GPSDO 
especially the GPS noise will give peak frequency errors compared to the 
average that are quite high. A factor of ten may be very conservative but as 
can be seen in the Tbolt measurements by TvB it is quite close. With OCXO and 
Rb GPSDO´s that I have tried to optimize I have seen about this factor or 
slightly less. With the DOT050 VCTCXO the ratio was even higher, up to 14 (ADEV 
7E-11 1-100secs and 1E-9 max freq errors at 1 second gate time).

Lars

>From: Bob
>Sent: den 2 september 2016 15:20

>The GPSDO might have an ADEV of 1 ppt at 1 sec and that rises to 30 ppt at 100 
>sec. It also might not, but let's use those numbers.

>ADEV is a standard deviation. You can get an idea of the magnitude of the 
>change reading to reading from it. It does not give you a sign for that 
>change. In the case above, it is a good bet that you see strings of 1 sec data 
>with mostly the same sign.  They have to add up to the 30X larger number when 
>tau gets to 100 sec.

>That creates a major problem if you just look at the 1 sec data. A "normal" 
>frequency standard does not have a rise or bump like that in the ADEV plot. 
>Thus the quick rule of thumb stuff falls apart. The correct way to do it will 
>always be to work out what the noise process is and calculate based on it. 
>That is not a popular thing to do ....

>Bob

> On Sep 2, 2016, at 6:38 AM, Lars Walenius wrote:
> 
> Hello Bert,
> 
> For me your findings look very much the same as this:
> http://www.leapsecond.com/pages/tbolt-8d/ 
> At least for me I should say the (absolute) frequency accuracy for this Tbolt 
> is not better than +-1E10 with 1 or 10 seconds gate times on a counter. Maybe 
> I am totally wrong as both Tom and Charles says that your Tbolt is bad.
> 
> As Bob Camp said we need a confidence interval. For me in this case it is 
> peak values if they occur more than a couple of times. Think of  voltmeters. 
> If it is out of spec say for only a couple of hours but it happens several 
> times say during a month or year and the voltmeters is not considered bad I 
> should say change the spec. If I were going to use the Tbolt as a reference 
> in a production environment with a 1 or 10 sec gate time I probably would set 
> the internal spec to 2E-10.
> 
> If I understand correct the Tracor 527E has a low pass filter with a time 
> constant of 1second so the 1 second frequency average data should be relevant.
> 
> As I am also interested in frequency accuracy with GPSDO´s used with 
> frequency counters, I have a maybe far to simplistic rule of accuracy: (10x 
> the worst ADEV at all Taus longer than the gate time). So for the Tbolt with 
> time constant of 100 seconds it is a hump of about 1E-11 at 100seconds so at 
> gate times shorter than 100seconds I expect to see excursions up to 1E-10. If 
> you set the time constant to 1000seconds and the OCXO in the Thunderbolt is 
> good to 2 to 3E-12 all the way 1-1000 seconds you probably don´t have 
> excursions higher than 2 to 3E-11 at 1-100 seconds gate times.
> 
> Lars
> 
> 
> Från: Bert Kehren via time-nuts
> Skickat: den 1 september 2016 19:09
> 
> We have been following the Tbolt power discussions but what I am missing is 
>  the main problem with Tbolts. All the power work will not improve the 
> frequency  performance of the unit because the frequency is constantly 
> changed 
> to correct  time. Tbolt is an excellent time device but not good for 
> frequency reference  past 1E-10. I noticed it when I bought it and compared 
> it with 
> my Tracor 527E on  the needle and 

Re: [time-nuts] Tbolt issues

[Lars Walenius]

Hello Tom,

What are the conditions for your charts? Are the Tbolts in locked condition or 
holdover? If locked what settings do you have for time constant and damping? Is 
it any other setting that is important?

For the frequency chart I see excursions up to +-3E-11 so not so far from the 
values that Bert gives and as I understand his TBolt might have a default 
setting of 100 seconds.

Lars


Från: Tom Van Baak
Skickat: den 1 september 2016 21:12


Hi Bert,

> because the frequency is constantly changed to correct  time.

A simple answer: you may have a bad TBolt. Was it part of the TAPR group buy, 
or did you buy it from eBay/China? If TAPR, you get a free replacement. Contact 
me off-list.

> Tbolt is an excellent time device but not good for frequency reference  past 
> 1E-10.

No, again it sounds like you have a bad TBolt. Or something is wrong (antenna? 
reception? time constant? environment? China resoldered parts?). I appreciate 
that Juerg did lots of testing -- do you happen to have his ADEV plot?

I'm willing to help you debug this.

(1) Attached is the ADEV of 8 random TBolts that I tested recently. How does 
this compare to yours? You can see mine are all under 2e-12 at 1 s and under 
4e-12 at 100 s. On a bad day during holdover it might climb to 1e-11 at 1000 s 
but when locked GPS disciplining takes over and keeps it down to 2 or 3e-12.

(2) For locked vs. unlocked TBolt ADEV, see 
http://www.leapsecond.com/pages/gpsdo/

(3) Also attached is a frequency plot showing the typical noise and wander, 
down at the 1e-11 level. How does this compare with yours?

Your claim of 1e-10 is order(s) of magnitude worse than the TBolts that I see. 
Something is wrong.

/tvb

- Original Message -
From: "Bert Kehren via time-nuts" 
To: 
Sent: Thursday, September 01, 2016 9:54 AM
Subject: [time-nuts] Tbolt issues


> We have been following the Tbolt power discussions but what I am missing is
> the main problem with Tbolts. All the power work will not improve the
> frequency  performance of the unit because the frequency is constantly changed
> to correct  time. Tbolt is an excellent time device but not good for
> frequency reference  past 1E-10. I noticed it when I bought it and compared 
> it with
> my Tracor 527E on  the needle and ever since used an Austron 2110 with a
> digital 100 sec. loop for  clean up. My Swiss partner Juerg has relied on an
> OSA F3 for Tbolt clean up but  continuous bad results on our work resulted in
> a detailed analysis using a  HP53132A counter and M100, FTS44060, two
> OSA8600's and one of the best FE405's.  The rsult is that the OSA F3 does not
> clean up the Tbolt and we see +-4E-11  changes and old data shows even some 
> +-8
> E-11 excursions. With the popularity of  the Tbolt an analog or digital
> clean up loop would make sense. We are working on  both, the analog because I
> saw similar behavior on the FE5680 and FE5650, we did  a GPSDO but do not plan
> on using those Rb's but focus on M100 and FRK.
> The collective expertise of time nuts could make a significant  contribution
> For power in critical applications we use the excellent work from Bern Kaa
> a friend for the last twenty years and well known because of his published
> work  in the European HAM community
> Bert Kehren
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Tbolt issues

[Lars Walenius]

Hello Bert,

For me your findings look very much the same as this:
http://www.leapsecond.com/pages/tbolt-8d/ 
At least for me I should say the (absolute) frequency accuracy for this Tbolt 
is not better than +-1E10 with 1 or 10 seconds gate times on a counter. Maybe I 
am totally wrong as both Tom and Charles says that your Tbolt is bad.

As Bob Camp said we need a confidence interval. For me in this case it is peak 
values if they occur more than a couple of times. Think of  voltmeters. If it 
is out of spec say for only a couple of hours but it happens several times say 
during a month or year and the voltmeters is not considered bad I should say 
change the spec. If I were going to use the Tbolt as a reference in a 
production environment with a 1 or 10 sec gate time I probably would set the 
internal spec to 2E-10.

If I understand correct the Tracor 527E has a low pass filter with a time 
constant of 1second so the 1 second frequency average data should be relevant.

As I am also interested in frequency accuracy with GPSDO´s used with frequency 
counters, I have a maybe far to simplistic rule of accuracy: (10x the worst 
ADEV at all Taus longer than the gate time). So for the Tbolt with time 
constant of 100 seconds it is a hump of about 1E-11 at 100seconds so at gate 
times shorter than 100seconds I expect to see excursions up to 1E-10. If you 
set the time constant to 1000seconds and the OCXO in the Thunderbolt is good to 
2 to 3E-12 all the way 1-1000 seconds you probably don´t have excursions higher 
than 2 to 3E-11 at 1-100 seconds gate times.

Lars


Från: Bert Kehren via time-nuts
Skickat: den 1 september 2016 19:09

We have been following the Tbolt power discussions but what I am missing is 
 the main problem with Tbolts. All the power work will not improve the 
frequency  performance of the unit because the frequency is constantly changed 
to correct  time. Tbolt is an excellent time device but not good for 
frequency reference  past 1E-10. I noticed it when I bought it and compared it 
with 
my Tracor 527E on  the needle and ever since used an Austron 2110 with a 
digital 100 sec. loop for  clean up. My Swiss partner Juerg has relied on an 
OSA F3 for Tbolt clean up but  continuous bad results on our work resulted in 
a detailed analysis using a  HP53132A counter and M100, FTS44060, two 
OSA8600's and one of the best FE405's.  The rsult is that the OSA F3 does not 
clean up the Tbolt and we see +-4E-11  changes and old data shows even some +-8 
E-11 excursions. With the popularity of  the Tbolt an analog or digital 
clean up loop would make sense. We are working on  both, the analog because I 
saw similar behavior on the FE5680 and FE5650, we did  a GPSDO but do not plan 
on using those Rb's but focus on M100 and FRK. 
The collective expertise of time nuts could make a significant  contribution
For power in critical applications we use the excellent work from Bern Kaa  
a friend for the last twenty years and well known because of his published 
work  in the European HAM community
Bert Kehren
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] GPSDO and PPS measurement precision

[Lars Walenius]

By the way: Have anyone compared the 30sec average from the Shera with a TI 
counter to see the real result?

Lars

Från: Lars Walenius<mailto:lars.walen...@hotmail.com>
Skickat: den 3 juni 2016 18:23
Till: Discussion of precise time and frequency 
measurement<mailto:time-nuts@febo.com>
Ämne: Re: [time-nuts] GPSDO and PPS measurement precision

Hej,

Using Tom van Baak´s GPSDO simulator is very informative as it can limit the 
TIC resolution.

Shera´s design is much more complicated than the 42ns resolution as it depends 
on the noise in the 24MHz oscillator. With an oscillator with enough noise 
during a 30 sec period it might be below 10ns eq. resolution all times? With a 
better oscillator it might have a ”hanging bridge” now and then.

Lars

Från: Attila Kinali<mailto:att...@kinali.ch>
Skickat: den 3 juni 2016 18:01
Till: Discussion of precise time and frequency 
measurement<mailto:time-nuts@febo.com>
Ämne: [time-nuts] GPSDO and PPS measurement precision

Moin,

With all the talk about GPSDOs going on in the last couple of months,
I started to wonder how much precision in the measurments is actually
needed. On one hand, we have the old GPSDO designs, like Shera's,
that offer a resolution in the 40ns range. On the other hand, we
have modern designs, that measure the PPS down to <100ps.

How much does the accuracy/stability improve using higher resolution?
Does anyone have data on that? If not, would someone be willing to
measure one of the better GPSDO's by artifically decreasing its
resolution in software and see what happends to the ADEV/MDEV/TDEV?

I am willing to give a hand with the data analysis, but I don't have
the equipment to do such a measurement.

Attila Kinali

--
It is upon moral qualities that a society is ultimately founded. All
the prosperity and technological sophistication in the world is of no
use without that foundation.
 -- Miss Matheson, The Diamond Age, Neil Stephenson
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] GPSDO and PPS measurement precision

[Lars Walenius]

Hej,

Using Tom van Baak´s GPSDO simulator is very informative as it can limit the 
TIC resolution.

Shera´s design is much more complicated than the 42ns resolution as it depends 
on the noise in the 24MHz oscillator. With an oscillator with enough noise 
during a 30 sec period it might be below 10ns eq. resolution all times? With a 
better oscillator it might have a ”hanging bridge” now and then.

Lars

Från: Attila Kinali
Skickat: den 3 juni 2016 18:01
Till: Discussion of precise time and frequency 
measurement
Ämne: [time-nuts] GPSDO and PPS measurement precision

Moin,

With all the talk about GPSDOs going on in the last couple of months,
I started to wonder how much precision in the measurments is actually
needed. On one hand, we have the old GPSDO designs, like Shera's,
that offer a resolution in the 40ns range. On the other hand, we
have modern designs, that measure the PPS down to <100ps.

How much does the accuracy/stability improve using higher resolution?
Does anyone have data on that? If not, would someone be willing to
measure one of the better GPSDO's by artifically decreasing its
resolution in software and see what happends to the ADEV/MDEV/TDEV?

I am willing to give a hand with the data analysis, but I don't have
the equipment to do such a measurement.

Attila Kinali

--
It is upon moral qualities that a society is ultimately founded. All
the prosperity and technological sophistication in the world is of no
use without that foundation.
 -- Miss Matheson, The Diamond Age, Neil Stephenson
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] More graphs: OCXO step, holdover recovery

[Lars Walenius]

Lars wrote:
>> What puzzles me is the large hump upwards in DACvalue. Anyone knows what is
>> the reason?

Hal wrote:
>My guess is poor filtering on the initial data when coming out of holdover, 
>probably complicated by inadequate testing and/or that case not being 
>important.
>
>I'm pretty sure there is at least one GPS data sheet that says to ignore the 
>first 3 samples.


But the large hump and small jump seems to come more than 15 minutes after 
holdover and at the same time after both holdovers. The first part after the 
holdover seems to be normal for a PI-loop is my assumption but the hump and 
jumps are not.

Lars



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Advise on building a DIY GPSDO?

[Lars Walenius]

Thanks Magnus and Charles,

Could you please explain a little more about this:

Charles wrote:
>>  Loop filters in commercial GPSDOs use algorithms that suppress
>> systematic ripple on the VCO control related to the comparison frequency.
Magnus wrote:
>It will be there, so you need to manage it one way or another.

What is the systematic ripple?
Is the comparison frequency normally 1Hz (1PPS)?
What is the algorithms used?
If I sample the difference between the PPS and the divided 10MHz output every 
second and have a third order loop driving a DAC will I get systematic errors?

Lars

Från: Magnus Danielson
Skickat: den 27 april 2016 10:02
Till: time-nuts@febo.com
Kopia: mag...@rubidium.se
Ämne: Re: [time-nuts] Advise on building a DIY GPSDO?



On 04/27/2016 01:12 AM, Charles Steinmetz wrote:
> Lars wrote:
>
>> I have wondered what is meant by a proper digital filter below?
>>
>> Is a proper digital filter something more than the LP-filter + PI-loop
>> I use in the DIY Arduino GPSDO?
>> What is used in commercial GPSDOs?
>
> The loops are substantially more sophisticated than a simple LP filter
> -- typically 3rd order or higher.

The lowpass-filter + PI-loop is third order.

>  Well-designed commercial GPSDOs also
> have several time constants so they can achieve basic lock using a wider
> loop, then narrow the loop in steps until it is fully narrow (unless S/N
> is low, in which case they may not reach full narrow and should set an
> alarm).

Some care needs to be taken in articulating the filter such that you do
not have to scale the state as you change the parameters. This is
however fairly simple for both the low-pass filter and integrator (which
hold state).

With some care you can articulate the P and I in the forms of equations
relating to the loop parameters you want and compensating for the
DAC/EFC control gain (exact value not important, but getting bandwidth
and damping in the right neightborhood is).

The heuristics about when changing parameters takes some learning. One
of the design criteria is to be able to always capture, but you also
want it to go as quick as possible. Finding a good balance can be
problematic. There is tricks to track-in quicker.

>  Loop filters in commercial GPSDOs use algorithms that suppress
> systematic ripple on the VCO control related to the comparison frequency.

It will be there, so you need to manage it one way or another.

> It is extremely unlikely that someone would stumble upon workable
> parameters for this sort of loop by trial and error.  One needs to
> measure and characterize the open-loop behavior, then carefully design
> the loop filter to achieve the desired result.

If you know what you are doing, you can get a good start using analysis,
knowing the damping and bandwidth you want. It always becomes a measure
and trim exercise.

Cheers,
Magnus
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Advise on building a DIY GPSDO?

[Lars Walenius]

Hello Charles and others

I have wondered what is meant by a proper digital filter below? Now I was 
reminded by the KS-24361 holdover graphs from Hal.

Is a proper digital filter something more than the LP-filter + PI-loop I use in 
the DIY Arduino GPSDO?
What is used in commercial GPSDO´s?

I am also quite sure that a home-built GPSDO will not "rival all comers," but 
you will learn a lot!

I also enclose an screen shoot from a two day run with my Arduino GPSDO in hold 
mode. This combination works well with about 1000-1500 secs of time constant 
and is an example that you need long time constants with good oscillators. It 
is also an example that you can learn a lot without expensive equipment. The 
TIC was linearized with a third order polynomial and data for linearization was 
gathered with the use of a PICDIV PD26 and processed in Excel. With the PD26 it 
is possible to have data with very accurate 200ns spacing together with the 1ns 
TIC.

BTW I saw that Nick Sayer now is using the ”Arduino” 1ns TIC in his open source 
GPSDO. His latest program also used a LP-filter+PI-loop what I could see.

Lars


Från: Charles Steinmetz
Skickat: den 5 april 2016 07:08
Till: Discussion of precise time and frequency 
measurement
Ämne: Re: [time-nuts] Advise on building a DIY GPSDO?

Don wrote:

>5.  Design a voltage tracking / filter to match the OCXO
>control requirements.
>6.  And, ...ta-dah;
>7.  You have a 10MHz, bench frequency standard that will
>rival all others

Not very likely.  The whole point of a GPSDO is for the frequency to
be controlled by the more stable source (OCXO or GPS) at all
integration times (tau).  But the OCXO will typically be more stable
than the GPS for tau less than several hundred seconds (see graph
below -- black line is GPS, brown line is a typical OCXO).  So, the
PLL needs to have a time constant of hundreds of seconds.  Such a PLL
filter cannot practicably be designed in the analog domain, so one
needs to design a digital filter with appropriate time constant and
damping.  Because of the very long time constant, it is almost
necessary for the filter to have more than one, switchable time
constants to avoid extremely long lock times.

Very few home builders are capable of designing a proper digital
filter suitable for this application (the counter-based loops of most
published DIY GPSDO designs are not proper digital filters).

So, no -- it is very unlikely that a home-built GPSDO will "rival all
comers," whether the builder designs his or her own circuit or uses
one of the many published circuits.

Best regards,

Charles


Graph below.  Note that a properly designed GPSDO would show
stability that follows the OCXO (brown line) at low tau, and the GPS
(black line) above the point where they intersect -- here, about 350
seconds.  Note that a loop filter with proper damping will NOT
exhibit a "hump" near the crossover (many GPSDOs do exhibit a
pronounced hump, betraying that their loop filters are not properly designed).
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] More graphs: OCXO step, holdover recovery

[Lars Walenius]

Thanks for the graphs.

Interesting to see the recovery from holdover on the KS-24361. What was the 
reason for holdover?

What puzzles me is the large hump upwards in DACvalue. Anyone knows what is the 
reason? Could it be that the loop changes time constant? Even after the second 
holdover a small jump is seen.
The downward peaks I guess is from correcting for the drift during holdover. 
Looks as a normal PI-loop?

Lars

Från: Hal Murray
Skickat: den 26 april 2016 13:03
Till: time-nuts@febo.com
Kopia: Hal Murray
Ämne: [time-nuts] More graphs: OCXO step, holdover recovery


An interesting step in the OCXO
  http://users.megapathdsl.net/~hmurray/time-nuts/HP-5334B-step-2016-Apr-23.pn
g

This is a from second HP5334B that has been running for months so the offset
will be different.


This is KS-24361 recovering from two holdover events of 12 or 13 minutes each:
  http://users.megapathdsl.net/~hmurray/time-nuts/GPSDO/KS-volt-2016-Apr-25.pn
g
  http://users.megapathdsl.net/~hmurray/time-nuts/GPSDO/KS-freq-2016-Apr-25.pn
g


--
These are my opinions.  I hate spam.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Cheap LEA-6T [was: Re: Precise Time transfer and relative position over ashort baseline]

[Lars Walenius]

The reason for the 2V out can be found in Gyros schematic in the eevblog 
thread. The problem is not the LEA module. The problem is that the LEA output 
is loaded with a diode (transistor BE) + 33ohm. Down in the eevblog thread a 
solution with a resistor between the LEA and the transistor base solves the 
problem and you get almost 3.3V out. Also it is  possible to add an external 
antenna as seen in the thread.
http://www.eevblog.com/forum/projects/ebay-u-blox-lea-6t-gps-module-teardown-and-initial-test/msg887853/#msg887853

See also: 
http://www.eevblog.com/forum/projects/ocxo-stable-reference-and-control-voltages/msg891318/#msg891318
 for some ADEV and MDEV curves for the LEA-6T with postprocessing of the 
sawtooth error.

Från: Mike Cook
Skickat: den 12 april 2016 13:03
Till: Discussion of precise time and frequency 
measurement
Ämne: Re: [time-nuts] Cheap LEA-6T [was: Re: Precise Time transfer and relative 
position over ashort baseline]

I tried one of these back in 2014 and found it not hitting specs. 2.16V on 1PPS 
instead of 3.3V. It died after a few months. Your milage may be better, but 
they are are old versions so there may be a systemic issue.


> Le 11 avr. 2016 à 20:47, Scott Newell  a écrit :
>
> At 11:46 AM 4/11/2016, Tom Van Baak wrote:
>> Another way might be to use single-channel common view GPS. I've not checked 
>> recently to see if 100 ps is possible over a 1 km baseline. If so that would 
>> be a less expensive solution. Someone should dig into the RINEX mode of the 
>> ublox 6T. It's on my list but the list is long.
>
> BTW, there are some LEA-6T modules (with patch antenna, compass, 1PPS led, 
> and USB connector) intended for drone autopilot use on eBay for around $30 
> shipped from China. (Search for "LEA-6T".) Mine showed up on the day of my 
> lightning strike, so I've barely played with it. It has the 6.something ROM, 
> connects to u-center, and appears to output the +/-10 ns sawtooth error 
> correction message and the RTKLIB compatible raw data.
>
> "Gyro" on thr eevblog forum reverse engineered part of the schematic:
>
> http://www.eevblog.com/forum/projects/ebay-u-blox-lea-6t-gps-module-teardown-and-initial-test/
>
>
> --
> newell  N5TNL
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

"The main function of a modern police force is filling in forms."
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] BG7TBL GPS Disciplined Source

[Lars Walenius]

Hi

If you are lucky the MV89 might be a very good OCXO and U-Blox makes very good 
GPS modules. The NEO-6M is not the best as it isn´t a timing module. But in 
your GPSDO the GPS module with an external antenna is not the limiting factor 
but more the controller and it´s limited resolution on the time measurement 
that is larger than the ripple from the GPS module. Also the software with FLL 
seems to limit the performance a lot. But with the long time constant the 
frequency accuracy, even with the offset due to the FLL, will be quite good.

U-blox own software uCenter have worked well for me.

Lars

Från: Gedas
Skickat: den 14 mars 2016 20:00
Till: Discussion of precise time and frequency 
measurement
Ämne: Re: [time-nuts] BG7TBL GPS Disciplined Source

Hi Hal, and TU for the reply. Tu also to everyone else with the very
helpful hints and info.  Following the advice of Joe I checked out the
EEV Blog site.very good information about the different variants of
this maker.  Turns out, because I have a model (date code) of 2014-12-09
that it corresponds to this revision and information:

custom board with surplus russianmorion mv89
OCXO. gps isu-blox
NEO-6M-0-001 .

Who would have guessed a Russian OCXO.  And, I guess the U-Blox is not
one of the better GPS units based on what Paul mentioned.  But I think
there is software out there that will let me at least monitor what my
unit is doing and how many birds it is receiving data from. I also have
the 8-port signal splitter which is nice as I can now run my reference
to all my various TE.

Oh well, it is what it is as I do not have the money to purchase a
different one. To answer your question I am using the supplied "hockey
puck" style antenna placed outside my basement window well, sitting on a
small wooden shelf, but close to ground level.  The antenna should have
a clear view from 90-280 degrees, from an elevation angle of 0-90
degrees.  Anything from West to North to East (~280-90 degrees) is
blocked by the house.  I guess my next step, as Bob suggested will be to
install some monitoring software to see how many birds I am able to see
on average.

Gedas, W8BYA

Gallery at http://w8bya.com
Light travels faster than sound
This is why some people appear bright until you hear them speak.

On 3/14/2016 12:55 AM, Hal Murray wrote:
> w8...@mchsi.com said:
>> This is where I really embarrass myself.sometime ago I purchased an
>> inexpensive 10 MHz GPS based reference source (BG7TBL GPS Disciplined
>> Source) for my various counters, transceivers, spectrum analyzers, etc  and
>> was wondering if it was a good purchase and if anyone else used a  similar
>> unit.  I guess in the end I am curious to know what the short &  long term
>> accuracy and stability of my unit may be?  I no longer have  access to any
>> accurate (known) frequency sources like I did while  employed and I do not
>> think I have the equipment here at home to measure  my unit myself.
> Long term accuracy will be very good - you are tracking GPS.
>
> You didn't say anything about your antenna.  That's probably the major
> contributor to your short term accuracy.
>
> Google found:
>http://www.eevblog.com/forum/testgear/bg7tbl-gpsdo-master-reference/
> Looks like there are various versions.
>
>

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] HP 5065A repair

[Lars Walenius]

Hi

Shouldn´t 5x10^-11 over 50C be 1x10^-12 / C? So with 2-4°C variation it is 
2-4x10^-12.

What about pressure variations for the HP5065 and other Rb´s? My LPRO have 
about 7x10^-14/mBar (hPa) so with 15-20mbar change, that can happen quite 
quick, it is also in the ^-12 range. The tempco for my LPRO is 7x10^-13/°C and 
drift in the high ^-14 per day so my GPSDO controller mostly fights the 
temperature and pressure variations I think. I like having a GPS disciplined Rb 
as I haven´t had to adjust it during the last years. Of course a OCXO based 
GPSDO will also stay on frequency. For me the Rb have been good when I have 
tested GPS modules and GPSDO´s just out of curiosity. In hold mode it have been 
useful to get the ADEV out to say 1 secs (low ^-13).

Lars

Från: Bob Camp
Skickat: den 14 mars 2016 02:01
Till: Discussion of precise time and frequency 
measurement
Ämne: Re: [time-nuts] HP 5065A repair

Hi

Some math:

5x10^-11 over 50C

You have 1x10^-13 / C

If you have pretty good HVAC you get 2C cycles. On a typical home system, you 
get 2X that or more.

Net is a bump at 2x10^-13 (or more).

That assumes no hysteresis. (Hint: there always is hysteresis).

That assumes you have no rate dependent effects. (… they almost always are 
present ..).

If you are at 10X the data sheet level, the bump is more like 2x10^-12 (or 
more). Either one will likely show up on a good test plot.

Can you take care of all this? Of course you can. Does modeling and correcting 
all this fall into the “quick and easy fix” category? Nope, not at all. The 
thread is about a request for a simple approach to an Rb setup. That sort of 
thing does not include fancy models and all sorts of corrections.

Bob



> On Mar 13, 2016, at 5:10 PM, Poul-Henning Kamp  wrote:
>
> 
> In message , cdel...@juno.com writes:
>
>> As far a tempco goes, unless your lab swings tens of degrees will you
>> really see it?
>
> Well, I do...
>
> My air-con is far from optimal, but it clearly makes a very obvious
> bump in my AVAR plots.
>
>
> --
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> p...@freebsd.org | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Conditioning Rubidium Oscillators

[Lars Walenius]

I read this but couldn´t understand why this is superior to the PI-loop with a 
pre-filter?

http://ptfinc.com/wp-content/uploads/2016/03/App_37_RubContol-Rubidium-Control-%E2%80%93-A-Different-Approach.pdf

Anybody can say why? Even if regression is very useful the limitation of the 
GPS and ionosphere will be the problem?How much better is it reasonable to get??

Lars


Från: GandalfG8--- via time-nuts
Skickat: den 3 mars 2016 22:00
Till: time-nuts@febo.com
Ämne: [time-nuts] Conditioning Rubidium Oscillators

I'm sure I won't be the only one receiving newsletters from Precise  Time
and Frequency Inc, but I thought it worth mentioning their latest  white
paper as it offers some thoughts on the conditioning of  rubidium standards via
RS232 control.

"Rubidium Control - A Different Approach" can be found here

http://ptfinc.com/resources/

A very basic registration is required but I've always found their mailings
to be interesting and informative whilst never being intrusive, and
there's always an unsubscribe option anyway.

Please not that I have no affiliation whatsoever, just passing on something
 I found interesting.

Regards

Nigel
GM8PZR




___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Another Arduino GPSDO

[Lars Walenius]

Eric Williams wrote:
I just saw Lars' postings on his design and thought I'd throw mine in since
I've been working on a similar low-end goal but doing it a different way.
 Not really an Arduino, either, but it's based on an AVR processor and
should be portable to an Arduino. 

Good to see someone else experimenting and sharing it (same for Bob Stewart!)  

Do you use the Arduino bootloader and environment (code)? 



I don't consider it a PLL because I have no way to measure phase
differences within a cycle.



I prefer to use time instead of phase as it is confusing to use phase with two 
different clock speeds (5MHz /1Hz). I also should say that it took me a while 
to figure out that Bob Stewart’s graphs showed a range of 100ns for an ADC 
range of about 400 (100-500). Maybe using both TIC value and ns scales would be 
good (or explained in a header or the file name).



I consider HP5328, 5334, 5335, 5370 etc counters in time interval mode to be 
very similar to my and your TIC or what Bob Camp recently named TDC. TIC is an 
acronym for Time Interval Counter and TDC Time to Digital Counter. In fact I 
used a 5328A as TIC in my first trials to do a GPSDO long ago.



Having a clock of 5 MHz and counter to 5000 for me is the same as a TIC range 
of 5000 with an input frequency of 1 kHz. Think of a counter in time interval 
mode with start from the 1PPS and stop from a 1 kHz (1ms) clock. It doesn´t 
matter if it is an analog integrator+ADC with 5000 “bits” (counts) or a digital 
counter with a 5MHz clock the resolution will be 200nsecs. In my Arduino GPSDO 
you will find two TIC´s, one analog and one digital. The analog has a clock of 
1MHz and a range of about 1000 (slightly less than 10bits) so the resolution is 
about 1ns and range 1uS. The other is like yours with a 5MHz clock to Timer 1. 
As I also count overflows the range is 500 (+-250) and up to 1sec (uses 
something like a modulo 500 in the program). This also gives a resolution 
of 200ns as yours.  I decided to have some overlap between the analog and 
digital TIC as the synchronization to the clock in the ATmega328 is a problem. 
This gives some margin between the ranges of the analog and digital TIC.



A note maybe more to those working with an analog TIC with a simple RC net: In 
my Arduino GPSDO the ADC value and ns is about the same. For low ADC values 
1LSB is about 0.88ns and for high values 1.12ns. The range I see from the ADC 
for 1000ns is 15-1005 (after fine trimming of the R). The relatively small 
deviation from 1ns/LSB is due to that I only use about 20% of the RC range due 
to the 1.1V ref instead of 5V ref.  From the beginning I used the 5V ref and 
about 600 out of the 1024 range. This gave a factor of 2.5 in resolution change 
over the range. For a normal deviation of +-10-100nS (depending on different 
GPS receivers) the TIC range is also a parameter for the linearity. With a 
1000ns TIC range the linearity around +-50ns from the midpoint is very good. A 
TIC range of 100nS +-50ns cover all of the range. But in a GPSDO the 
nonlinearity may not be a problem at all (especially if you correct for it). 
Most probably the nonlinearity only gives a small time offset as the values 
that are above the midpoint have a slight different gain to the ones below.



Lars
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] GPSDO simulation tool

[Lars Walenius]

Many thanks Tom for an excellent tool and also the data you have provided. You 
don´t happen to have data for a non sawtooth corrected M12?

Another question: how do you insert the options for ticres and dacbits? With 
“gpsim1 avg1=10 gps-mtk3339.txt  ocxo.dat  gpsdo.txt” I managed to get 
different prefiltering in the same way as you had in your graphs. But inserting 
dacbits=10 instead of avg1=10 gave an error for me.

Lars
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Another atomic clock question

[Lars Walenius]

Some clarifications on the ADC in the ATmega328 and how it is used in the 
Arduino GPSDO. 

The resolution is 10 bits but you can select Vref. In my Arduino GPSDO it is 
set to the internal Vref = 1.1V so 1LSB is 1.1mV. From the beginning I used 5V 
as Vref but if you plot the response from the RC-net you find that the useful 
ADC range is only a fraction if you want to have a reasonable linearity. In the 
beginning I used only 600 out of the 1024 but still the time per bit was more 
than a factor two different. If somebody want to experiment with other 
processors for theTIC, a Teensy with 16bit ADC´s is probably a good idea 
because you can use only part of the range but still have good resolution 
(noise is another thing that may be both good and bad in a GPSDO).  

According to the datasheet the minimum conversion time is 65uSec for the 
ATmega328 (ADC clock max 200 kHz and 13 clock cycles).

The discharge of the 1nF is not 1sec but 1mSec. If it was 1sec, 63% of the 
previous charge should be left and giving errors up to 63%. My assumption when 
designing the network was to have at least ten time constants of discharge 
before the next PPS. So a 100mSec time constant would be fine for that. The 
problem is that with a 1nF capacitor I would need 100Mohm as discharge 
resistor. To get 1.1mV (1nS) over 100Mohm you only need 11pA for example from 
the ADC input leakage current.  I decided for 1Mohm that gives 1mv for 1nA. 
This gives the TIC a drift of about 1ns per nA change. Remember I wished to 
keep the drift to maybe 1nSs for a couple of degrees room temp change so the 
drift of the leakage current needs to be below say 0.5nA per degree. My 
practical testing has showed that I have about 1.2ns drift for 5°C change and 
it seems consistent between different Arduinos I have.

The 1mSec time constant gives a discharge that directly after the pulse from 
the HC4046 ends is about 0.1% per uSec.  So for a 65uSec delay the drop is 
about 65nS for a 1000nS reading and 32uS for a 500ns reading. If the delay is 
exactly the same every time it should be possible to compensate for.

I have got indication that crosstalk between ADC channels may be a problem in 
the ATmega328 but with the single TIC and very slowly changing values on the 
other ADC channels I can´t say it is a problem for me. I also would encourage 
you to test both the Arduino dual TIC and using both halves of the HC390 
whatever I have said about risks. The HC390 is probably not a problem at all 
for the nS readings as you and Magnus says.

Lars





Chris wrote:
Let's see what is needed. 
The ADC is 10-bits so it can read to one part in 1024.  It's a 5 volt
full scale so we are only able to measure 5 millivolt increments 

The uP runs about 16 million instructions per second.  What if we wait
1000 instructions to read the ADC what will the error be?  The 1000
number is conservative by at least a factor of 10.  The discharge
resister has (assume) a one second time constant. 

The read delay would be 1000/16,000,000 or 63 uSec.  in that time the
voltage would have changed about  300 microvolts.  The change is about
15 times less then the DAC is able to measure.But because of the
conservative estimate it might 150 times to small to measure.   So
randomly delayed reads of the ADC will not matter.  That said I'm sure
we can do 100X better then the 63 uS estimate. 

On the other side, charging the cap.  Let's say I mis-measured a wire
and it is 1cm longer then I though.  The added delay adds a tiny delay
but this is not going to show up in a 10-bit ADC.  Same if the
propagation delay changes through the 74HC390 based variable loading
of other output pins or noise from the 78ls05 voltage regulator.  The
DAC is set up for 5 mV steps.  I just don't need to worry about errors
that are well under 0.5 mV.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Another atomic clock question

[Lars Walenius]

As I am a poor programmer and also lazy (includes hardware and software), I 
would like to ask the following question: How much better would a GPSDO like 
the Arduino GPSDO be with added sawtooth correction? 

Let’s say we assume the 1ns resolution TIC is perfect, no jitter from the uP 
and the DAC have a perfect frequency setting resolution of 1E-13. The receiver 
in my case is a M12 set in position hold mode after a survey and my measured 
ADEV starts at 2E-8 for 1sec and is 2E-11 at 1000secs. The MDEV is 2E-8 at 1sec 
and 2E-12 at 1000sec (very similar to what found on the leapsecond.com M12 
page). The oscillator is my “8663”-type OCXO that I have measured to have an 
ADEV just above 1E-12 over the range 1-1secs. Let’s say the oscillator is 
perfect at 2E-12 over 1-1secs.

The Arduino GPSDO control loop works as follows, as far as I understand, if set 
to a time constant =1000secs and damping =2 :

TIC value is pre-filtered similar to an RC filter with 250seconds time constant 
(I like to refer to analog RC-filters being an RF and analog engineer)


The filtered TIC value is divided by the time constant 1000 and adjusts the DAC 
proportional to this.


The filtered TIC value integrates the DAC value after dividing it by (time 
constant * time constant * damping) = (/1000/1000/2).


My explicit question is how much better the ADEV of the GPSDO oscillator output 
will be with sawtooth correction added in the software? Another question is how 
much better the ADEV will be if the TIC had a resolution of 0.1nsec instead? 
Maybe a third question could be if the DAC only had 1E-12 resolution?

Is some more important factors needed to be known to calculate this to a 
reasonable accuracy? e.g. room temperature variations of the M12. 

In my own measurements, with about the same conditions as above with a time 
constant of 1000s, I got an output ADEV of about 3E-12 at Tau 1000s measured 
with an HP5370 against an LPRO Rb (plot was attached to Arduino GPSDO thread 
Feb 12 2014). This value looks very similar to the combination of the 1PPS MDEV 
and OCXO ADEV. Is that just a coincidence?

Lars
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Another atomic clock question

[Lars Walenius]

I have quite often seen the simple D FF lead/lag phase comparator mentioned but 
not found any practical implementation in a GPSDO. Has anyone a schematic and 
hopefully real data? What is the performance? Is it better than a conventional 
GPSDO with a TIC+uP+DAC or is it only simpler?

Lars

On Fri, Mar 7, 2014 at 2:25 PM, Jim Miller j...@jtmiller.com wrote:
 I think the hardware delay line approach is the only solution for a simple
 D FF lead/lag phase comparator. It would be placed ahead of the FF.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Another atomic clock question

[Lars Walenius]

Chris, about using one Arduino for two GPSDO controllers:

Even if a microcontroller has lots of capacity I would recommend to use 
separate controllers for each oscillator. One of the reasons is what Tom van 
Baak said about using only one interrupt to avoid jitter and even if you 
trigger both channels from the same PPS and have just one interrupt you will 
have a problem that you can´t read two ADC´s at the same time.

Even the HC390 I wouldn´t use for two different oscillators to prevent 
crosstalk. Both the processor and HC390 is so cheap it isn´t worth the risk IMO.

Actually I would also recommend to put them in separate boxes even if it is 
more work  (and I´m lazy ) to get best performance.

Having two GPSDO´s that you can compare is very nice as long as you understand 
how they correlate , if that is not what you want to test. Of course you can 
also set one or both in hold mode to test them freerunning.


I have thought of connecting the M12 to the Arduino and if someone can help 
with code to get the sawtooth correction value into the Arduino and decoded I 
would be glad to have it.



Lars





From: Chris Albertson



On Wed, Mar 5, 2014 at 5:43 PM, Didier Juges shali...@gmail.com wrote:
 Tom and Bob,
 It is not obvious to me that it is easier to simply apply a correction in
 nS increments with a range as wide as 100nS. How is this done? Using
 switched delay lines or delay gates? 
Here is my plan for processing saw tooth data.  If it's not going to
work I'd rather hear about it now then a month from now after I've put
in some effort. 
This is going into Lars' Arduino based GPSDO.  Every second I read the
voltage on a TIC capacitor.  This tells by the phase in nanoseconds
between the PPS and the OCXO.  Then I add whatever the current GPS
sawtooth value is to whatever my TIC said.   I compare this to a set
point.  This is the phase error.  The OCXO is adjusted based on a
filtered version of this error. 
So in short, I don't correct even try to delay the pulse.  I don't see
any need to do that.  I measure the pulse and get a number in
nanoseconds.  then I use sawtooth to correct the number. 
It seems way-hard and with no purpose to correct the pulse and then
measure it.  Better to correct the measurement.  I think it is more
accurate too a delay could never be perfect. 
The controller has LOT of spare capacity so I don't see way I can't
add one of more TIC channels and a few more DACs  I should be able to
discipline an OCXO and my Rb  oscillator from the same GPS PPS input.
 The 74HC360 is only 1/2 used an Arduino has enough spare pins.  Any
one more 74HC4046 and some passive parts would be required to build a
dual channel GPSDO. 
It will be interesting to look at andompare the 10MHz outputs of two
oscillators that are being disciplined by the same controller and GPS
receiver.

-- 

Chris Albertson
Redondo Beach, California
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Arduino GPSDO with 1ns res TIC

[Lars Walenius]

Hi Magnus

You are correct in a way. The code  is more complicated than it should have 
been. 

The first row with comment “corr for time” is the I-term. 

The second row that integrates the frequency offset is the P-term and could 
have been just proportional to the time offset I understand now (I have thought 
of it before but totally forgot it). 

As I choosed to work with integers I have to scale the values to avoid 
truncation errors (that I still get with large time constants ☹. Probably it 
would be better to use floating point calculations.



Lars





Från: Magnus Danielson
Hej Lars,

Impressive build in all it's simplicity.
Your filtering equations look strange.
Rather than having a PI loop it looks like both the P and I branch 
integrates. I'm also unclear about the loop gain changes by the 
pre-filter averager.
Will have to look more at your code.
Cheers,
Magnus

On 12/02/14 23:10, Lars Walenius wrote:
 I have just changed all my Swedish comments in my source code and attached 
 it. I also copied the text to a Word-file so everybody can see it without 
 the Arduino Environment.
 The Control loop (“PI-loop”) is more or less just two lines that you find 
 approximately in the middle of the file (page 13 in Word-file). Check the two 
 lines with comment: Corr for time respectively Corr for frequency.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] TIC model

[Lars Walenius]

Hi Bruce




You are absolute right that it is wise to put some time in the estimation of 
such effects as asynchronous Clocks. An iteration between  thinking and 
building seems always to be necessary but we all have different capabilities 
for that. For the Arduino I came to an end with the interrupts as I am not good 
at uP´s.






The Arduino GPSDO has two interrupts. One is synchronous with the 10MHz and 
comes from timer1 overflows. The other is synchronous with the 1PPS. So it is 
three asynchronous clocks right now in the GPSDO controller.




As I understand my problem it is that an interrupt takes some time to execute 
and if you get the two interrupts to close you will have a problem with timing 
as you can´t execute both at the same time?




Of course the easy solution could be to have the needed resoulution higher than 
the time it takes to execute the interrupts but in the GPSDO I want a 
resolution of 200ns (5MHz Clock) and the shortest interrupt is 3us.




I would be glad if somebody (Chris?) could have a look in the Aduino GPSDO code 
to see if it possible to get rid of the uncertainty due to the interrupts from 
the timer1 overflow.




Another question: Does a PIC not need overflow interrupts to count say 500 
counts as I do in the Arduino?




Lars





From: Bruce Griffiths
Sent: ‎söndag‎ den ‎16‎ ‎februari‎ ‎2014 ‎20‎:‎14
To: time-nuts@febo.com





The response time to an external asynchronous interrupt is never 
deterministic.
The external interrupt has to be synchronous with the uP clock to avoid 
the non deterministic synchronisation delay.
Even when the external event is synchronous with the clock input to the 
uP and the uP uses a divider to produce its internal clock then there is 
the issue of divider phase shift.
This phase shift can lead to sampling the waveform before the peak 
across the sampling cap. This is far from ideal, its better to sample at 
or slightly after the peak when the sensitivity to timing variations is 
far smaller.
To complicate the issue further the time of occurrence of the peak is 
temperature dependent and the sampling switch on resistance is nonlinear 
so that peak delay varies with temperature and input signal amplitude.

Its generally quicker and cheaper to estimate the magnitude of such 
effects and make appropriate choices than just build a sequence of 
breadboards each of  which then needs to be extensively characterised.

Bruce

Chris Albertson wrote:
 You all are inventing problem.  Solve them AFTER you find a problem you
 can measure.   Interrupts are not an issue on a UP like the AVR because
 they are completely deterministic.  It don't matter the lenth of time as
 long as it is 100% deterministic and predictable.   On a multi-tasking OS
 running on a super scaler CPU you have unknowable latentcy but this is not
 the problem on a chip that does one machine cycle per clock cycle.


 On Sat, Feb 15, 2014 at 6:50 PM, Brian Lloydbr...@lloyd.com  wrote:


 On Sat, Feb 15, 2014 at 7:10 PM, Tom Van Baakt...@leapsecond.com  wrote:

  
 For Arduino and other less fortunate uC you can always use external chips
 to obtain optimal and jitter-free charge/discharge timing. I'm not that
 familiar with Atmel chips; could capture/compare be used instead of
 interrupts somehow?


 One should investigate the Propeller.

 --
 Brian Lloyd, WB6RQN/J79BPL
 706 Flightline Drive
 Spring Branch, TX 78070
 br...@lloyd.com
 +1.916.877.5067
 ___
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to
 https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
 and follow the instructions there.

  




___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] TIC model

[Lars Walenius]

Bob Stewart wrote:
 Tom tried to steer me to the PICTIC recently, and I sort of brushed him off, 
 because, quite frankly I didn't understand.  Now that I've really looked at 
 it, it's a much better idea than using a dsPIC33 and brute-forcing it.  But, 
 I don't really need everything the PICTIC offers so I started doing surgery, 
 and this is what I've come up with. 

 The nsVolts would feed one of the 10-bit ADC channels of the 18F2220 on the 
 VE2ZAZ board, and the 1PPS signal does the obvious.  I had no idea what to 
 use for the RC, so I used smaller and smaller values till LTSpiceIV showed a 
 large range over 360 degrees of phase.  I realize that's probably a bad 
 idea, but I have no point of reference, nor do I probably need the accuracy 
 that would otherwise imply. 

 The 1PPS input passes through the enabled tri-state buffers U2A and U2C to 
 charge the cap until the Q output from the D-flop is sent high from the 
 10MHz signal and disables U2C.  When the 1PPS goes low, the cap is 
 discharged and the D-FLop is reset.  In practice, the chips would be 74AC 
 types.  I could only find LTSpiceIV models for 74HCT chips.  LTSpice says 
 it's workable, but in practice, I don't know.  It might be finicky or 
 unstable.  Any comments would be welcome.

 http://www.evoria.net/AE6RV/TIC/TIC.png

 Bob - AE6RV



  Bruce Griffiths wrote:  
You should also include the effect of the A/D converter sampling 
capacitance and saampling switch series resistace in the model. Since 
the RC time constant of the sampling switch and associated sampling 
capacitor can be 1us or more (temparature and Vcc dependent) the voltage 
waveform at the sampling capacitor differs significantly from that 
predicted by your simple modeel.
Aside from the nonlinearity due to the non constant charging current the 
principle limitation on the resolution is due to the variable interrupt 
latency for ADCs where the conversion is triggered by software.
This problem can be avoided if the ADC conversion can be triggered 
directly by an external signal.
Bruce


What Bruce says is really important.


For the ATmega328 the datasheet says 14pF sampling capacitance and nothing 
about temperature coefficient.

It also specifies a series resistance 1..100k. So not very precise. If it is 
100k the time constant is 1400ns!

I have tested several boards and they seem to behave similar with my 1nF NPO 
capacitor. With a 47pF I guess it is more uncertain.


I also recommend you to test your model in the real world. I have used two good 
OCXOs and/or rubidiums with a small offset. Say 1E-9 offset that gives 1nS per 
sec. One of the channels have had a divider for example HC390s or the excellent 
PICDIVs from Tom Van Baak to output 1PPS.


I have also applied a heat gun near the circuit to test that the circuit 
doesn´t drift with temperature. A reasonable goal is to have less than 1LSB 
drift with a couple of degrees change. This test I have done with the same 
source for both 10MHz and 1PPS and a high reading from the ADC.


What Bruce says about interrupts is also worth to check in real life as 
“jitter” due to unexpected interrupts or different timing may give problem. In 
the Arduino GPSDO the timer1 overflow interrupt may delay the 1PPS interrupt 
about 3us and delay the ADC conversion 3us. This is not so critical as it 
sounds as the ADC input is not changing at this time. For me this jitter gives 
more problem with the timer1 Reading. This jitter is not so easy to to test as 
it in the Arduino GPSDO program only happens every 1024secs and if you are 
(un)lucky it may not be seen at all depending on startpoint of timer1 relative 
to the 1PPS.


Lars
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Arduino GPSDO with 1ns res TIC

[Lars Walenius]

 Chris wrote:

Från: Chris Albertson
Skickat: ‎torsdag‎ den ‎13‎ ‎februari‎ ‎2014 ‎07‎:‎31
Till: time-nuts@febo.com





 1) what connects to analog pins A1, A2, A3, A4, and A5.  The schematic
shows only A0 used for the TIC capacitor.





A1 and A2 is connected to temperature sensors like the LM35 or an NTC with 
pullup. Note that the program sets all ADC to read 0-1.1Volt. If you don´t use 
the temperature sensor it might be wise to put a pulldown of say 100kohm on the 
A1 and/or A2. On my board A2 goes to the 4x2 pinheader that is used for the 
external inputs of 10MHz, 1PPS, temperature (A2) and output of control voltage.

A3 and A4 is fed from 4 dipswitches each via 100k, 200k, 390k and 820 k from 
the +5Volt. On both A3 and A4 I have a 12kohm pulldown. So actually this makes 
a 4bit DAC.  This was a way to get 8 digital inputs from 2 pins. Probably an 
I/O expander would be a better choice in a commercial product (or another 
processor :) . This arrangement requires a fixed relationship between the +5V 
and +1.1V. If the board is only powered with USB it might be problem even if I 
haven´t seen this with my computers yet. The TIC also need a fixed relationship 
in the same way as the HC4046 is powered by +5V and the ADC has it´s internal 
+1.1V.

A5 is connected with a 20kohm pot + 82kohm resistor from the +5V if I remember 
correct. My intention was to have an input for different “DAC ranges” to be 
able to switch between different oscillator without changing a value in the 
program. It is not implemented in my program.


 One chance is that my Rb oscillator is controled via serial port, not a
 voltage.  So I'll want the program to use serial commands rather than a
 DAC.You say your unit is pressure sensitive, well there are cheap and
 very easy pressure sensors that are easy to use.
 It might be fun to see what I can do with a cheap $1 10Mhz crystal rather
 then using an OCXO.





I would select the best 10MHz oscillator you have. Even with a Rb it is 
possible to set low time constants to get quick loop response for test. With 
low time constants you will get more noise on the output frequency but that 
will mainly be because of the 1PPS jitter if you have a good oscillator. If you 
have a noisy oscillator it will only make it worse. Probably a cheap VCTCXO 
will give more noise than even a position type GPS receiver at time contants 
longer than 50 seconds. But if the best oscillator you have is a VCTCXO try it. 
One thing to remember, that my gpsdo shares with the Shera controller I think,  
is the narrow capture range of the TIC. My is even worse than Sheras as he uses 
a divide by 32 before the HC4046 and I use divide by 10 (I used divide by 100 
from the beginning and 10 times higher RC-net time contant that gave 10nS 
resolution). So it is important to manually adjust the frequency of the loop in 
hold mode before activating the loop. Using a working timer1 together with the 
TIC would give the possibility to a much wider capture range.


Changing the program to output a serial value to the Rb would be a great idea.


I think it is a good idea to first set the controller in hold mode and set the 
DAC values to mid, min and max and have a look on the TIC values and learn 
something from that before closing the loop (setting normal mode and fast 
locking).




Lars
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.