Re: [time-nuts] Raspberry PI 3 NTP server with GPS time data.

[Nick Sayer via time-nuts]

In my own experience, using the PA6H (AdaFruit) with GPSD as an NTP source 
doesn’t work. By contrast, the PPS using the kernel module PPS timestamp driver 
works exceptionally well.

The issue with gpsd with this module is that the time reported in the NMEA 
sentences always has 0s for the sub-second digits of the time, but the 
sentences aren’t synchronized to the second or anything, so they’re all over 
the place. In principle, the sentences and PPS in concert gives you accurate 
time, but so far as I can tell, NTP isn’t plumbed to get *just* the seconds 
from NMEA and merge that with PPS to make a single source.

What that meant for me was that it was far more reliable to “bootstrap” ntpd 
using external servers and use only the kernel based PPS stuff to sync to GPS.

My own config is

pool us.pool.ntp.org iburst prefer

server 127.127.22.0
fudge 127.127.22.0 refid PPS
fudge 127.127.22.0 flag3 1 # enable kernel PLL/FLL clock discipline

At start, the PPS is ignored until NTPD gets a lock on an external server. At 
that point, it switches over to using PPS and becomes stratum 1. The result is 
as good an NTP server as you’re going to get with a Raspberry Pi (given it’s 
using a USB based Ethernet controller and the rest of the limitations of the 
platform).


> On Apr 24, 2016, at 4:15 PM, Chris Albertson  
> wrote:
> 
> Did you see the notice on the adafruit 2324 web page that reads "Does
> not work with the Pi 3 at this time".
> 
> OK assume they have fixed the problem...
> 
> Try using the #20 reference clock.  It works with any generic GPS that
> outputs NMEA sentences and PPS.  Set the Flag1 to enable PPS.
> 
> What you have now is TWO clocks, one is the GPS via "gpsd" and the
> shared memory and the other is the PPS and I bet they don't exactly
> match.  Better to have one reference clock and that is the
> 127.127.20.0 type clack.
> 
> What is happening is that the NMEA standard only requires the NMEA
> sentences to be output during the second to which they apply.  So the
> time is only accurate to within a second. Compared to any other clock
> the NMEA-only GPS can be very poor.
> 
> GPS is one of the best reference clocks for NTP.  I'd use it as a
> first choice unless for some reason you can't (for example you have no
> way to install an antenna.)
> 
> 
> On Sun, Apr 24, 2016 at 11:51 AM, jan hugo prins  wrote:
>> Hi,
>> 
>> To get a more stable NTP source into our production network I have
>> started exprerimenting with a Raspberry PI 3 with a GPS head. GPS data
>> is coming in fine, but the time is jumping around like a wild horse. The
>> result is that the only thing I get out of this experiment so far is a
>> more stable PPS signal in my NTP config but after some time both the GPS
>> time and the PPS are marked a false ticker and the only thing left is
>> the external reference clocks from outside our own network.
>> 
>> Parts used:
>> Raspberry PI 3
>> Adafruit GPS head: ADA-2324
>> External GPS antenna with 5 meter cable.
>> 
>> My NTP config looks like this:
>> 
>> logfile /var/log/ntpd.log
>> logconfig = all
>> driftfile /var/lib/ntp/ntp.drift
>> statsdir /var/log/ntpstats/
>> statistics loopstats peerstats clockstats
>> filegen loopstats file loopstats type day enable
>> filegen peerstats file peerstats type day enable
>> filegen clockstats file clockstats type day enable
>> server 127.127.22.0 minpoll 4 maxpoll 4 prefer
>> fudge 127.127.22.0 refid PPS flag3 1
>> server 127.127.28.0 minpoll 4 maxpoll 4 iburst
>> fudge 127.127.28.0 refid GPS time1 +0.550 flag1 1 stratum 4
>> server ntp0.nl.uu.net
>> server chime6.surfnet.nl
>> server chime5.surfnet.nl
>> server ntp1.virtu.nl
>> 
>> Now I got the idea that I might be able to use a DCF77 receiver to get a
>> stable timesource, but on the other hand, if the cause of my problem is
>> internal to the Raspberry PI setup then I might have exactly the same
>> problem with the DCF77 receiver.
>> 
>> The average on the NTP clocksource is close to 0.
>> root@raspberrypi:/var/log/ntpstats# cat peerstats |grep 127.127.28.0
>> |awk '{print $5}'| tail -n 1500 | awk 'NR == 1 { max=$1; min=$1; sum=0 }
>> { if ($1>max) max=$1; if ($1> %d\tMax: %d\tAverage: %f\n", min, max, sum/NR}'
>> Min: 0Max: 0Average: 0.001101
>> 
>> Could anyone give me some advice on how to get this working? Or is my
>> idea to use a GPS clock to create a stable NTP setup the wrong way to go?
>> 
>> Thanks for any advice.
>> Jan Hugo Prins
>> 
>> 
>> ___
>> 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.
> 
> 
> 
> -- 
> 
> Chris Albertson
> Redondo Beach, California
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to 

[time-nuts] Oncore battery

[Joseph Gray]

Can anyone recommend a rechargeable lithium coin cell that is a direct
replacement for the ones that come on some Oncore receivers? Something
I can order from Mouser or Digikey, if possible.

Joe Gray
W5JG
___
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] RG6 or LMR400 for GPS Antenna (Symmetricom 58532A and T-bolt)

[Ryan Stasel]

All,

So, went digging into my crawlspace just now, and found my RG6 that I thought 
was Belden. It’s actually Coleman 92003, which isn’t quad shield, but has a 
spec sheet that actually shows attenuation at 1500Mhz!

https://www.platt.com/CutSheets/Coleman%20Cable/92003.pdf

Interesting that there seems to be a “hump” between 1200 and 1500Mhz, as the 
attenuation jumps quite a bit, whereas it’s relatively flat between 700 and 
1200Mhz. Then another bump above 2200Mhz, which is what this cable is rated to.

It’s sun resistant, which is good.

Anyone see any reason to not use this, and instead use some generic Quad 
Shield? It is gas injected, which supposedly improves it’s susceptibility to 
crushing, or other deformation of the insulator… but I can’t say I’ve seen this 
actually shown anywhere (I guess because it’s HDPE rather than LDPE insulator).

Thanks again everyone for all the input! It’s been pretty great to read this 
thread… even if it’s a bit “academic”. =P

-Ryan Stasel

On Apr 23, 2016, at 7:26 AM, billriches 
> wrote:

RG6 for CCTV has copper shield and solid conductor.
RG6 for CATV has aluminum shield and solid conductor.
73,

Bill, WA2DVU
Cape May

-Original Message-
From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Ryan Stasel
Sent: Friday, April 22, 2016 5:09 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] RG6 or LMR400 for GPS Antenna (Symmetricom 58532A and 
T-bolt)

Paul,

LOL! So, along those lines… one other question, since I can’t find my belden, 
I’ll be buying some coax. Anyone have any opinions about RG6 for CCTV vs CATV? 
My understanding is the CCTV version always has a solid copper center conductor 
(which in my mind would mean less voltage loss for the DC power going to the 
antenna), or I’m still overthinking it and should just go with standard RG6?

Thanks!

-Ryan Stasel

On Apr 21, 2016, at 13:04 , paul swed 
> wrote:

Ryan a slight heads up.
Time Nuts is not about time accuracy as many people assume.
Its actually about the time we all waste looking for what we know we have.
We just measure that time accurately.
I do not use anti seize. Nothing against it just one more glob of
stuff to deal with.
If you use the heat shrink and it seals your done for my 2 cents.
Paul
WB8TSL

On Thu, Apr 21, 2016 at 1:07 PM, Ryan Stasel 
> wrote:

All,

Really awesome answers, thanks!

For the sealing question, it was more of a “should I bother with
something like anti-seize” or the like on the actual thread-thread N
interface. The actual connector crimp, was planning on just using a
couple layers of the heat-shrink with adhesive. That is all going to
be internal to the mast anyway, so direct weather contact should be
minimal. It’s also on the side of my chimney, that gets very little
to no direct sun, so UV exposure should be minimal. But good note on that 
regard.

Pete, thank you very much for the info wrt the antenna and amp, and
also the fact the Trimble starter kit came with RG6. I’m going to see
what my seller wants for LMR400, but otherwise, I’ll just use RG6.
It’s certainly easier to handle. I did find some datasheets on the
stuff that Home despot (har har) sells (Southwire (
http://www.southwire.com/ProductCatalog/XTEInterfaceServlet?contentKey=prodcatsheetOEM80)).
I swear I have a box of Belden somewhere, but I can’t seem to find it.

Thanks again!

-Ryan Stasel

On Apr 21, 2016, at 06:02 , paul swed 
> wrote:

With respect to sealing. Everyone has a method.
I use what I learned in the Navy. I could see how well the
connections
held
up in the worst conditions sun cold heat wet humidity...
Layer of rubber tape
scotch kote
Layer of plastic tape
scotch kote
If done well the connector releases just fine even after 5 or more
years. I
want to say 10. But then woodpeckers have a way of shortening the
life of connectors and coax.
The approach is really layers and the top to deteriorate over time...
But as I say everyone has their own approach.
Regards
Paul
WB8TSL

On Wed, Apr 20, 2016 at 9:03 PM, Ryan Stasel 
>
wrote:

Bob/Paul,

Thanks. And there's the rub... Who knows what the specs are on "generic"
RG6 QS. I'll see what my seller wants for their LMR400, but
otherwise
yeah,
RG6 is just easier. I have both compression and crimp connectors
for it, including some RG6 N-connectors (yeah, they're probably for
LMR300, but they work).

Other question: any tips for the exterior N connection? I can
"weatherproof" the actual cable-connector crimp, but I'm curious if
anyone
bothers to "lube" the N connector to keep moisture from otherwise
seizing
it up.

Thanks!

Ryan Stasel
IT Operations Manager, SOJC
University of Oregon

Sent from my iPhone

On Apr 20, 2016, at 17:00, Bob Camp 

[time-nuts] Western Electric O-451A/U double-oven XO

[Eric Scace]

Hi —

   I have finally retrieved from my parents’ home my original time & frequency 
standards lab, to which will be added my more recent HP Z3805A. The assembly 
contains:
HP-113BR frequency divider/clock
homebrew WWVB receiver & frequency comparator, with its own internal OCXO 
standard, that my father and I built in 1979 to maintain calibration and 
otherwise measure the performance of its internal OCXO standard and of the 
following…
Western Electric O-451A/U double-oven frequency standard. As you will see from 
the photos, this unit was made for the US Coast Guard. The double-oven is on 
shock mounts and the power supply contains a dynamotor — signs of shipboard 
use, although I suspect it was part of a coastal radio station. We bypassed the 
dynamotor supply and installed a more modern supply.

   Unfortunately I never had any documentation for the O-451A/U unit. I wonder 
if anyone else has experience with this oscillator, or has any documentation. 
Since it hasn’t been operating in the last 30 years, I’d like to replace the 
electrolytic capacitors — but this would be much easier with documentation.

   A quick Internet search did not yield a reference manual. Given that this 
unit is serial number 11, I supposed I should not be too surprised.

   Any suggestions for finding reference manuals for the O-451A/U?

   Thanks.

— Eric







signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] Raspberry PI 3 NTP server with GPS time data.

[Chris Albertson]

Did you see the notice on the adafruit 2324 web page that reads "Does
not work with the Pi 3 at this time".

OK assume they have fixed the problem...

Try using the #20 reference clock.  It works with any generic GPS that
outputs NMEA sentences and PPS.  Set the Flag1 to enable PPS.

What you have now is TWO clocks, one is the GPS via "gpsd" and the
shared memory and the other is the PPS and I bet they don't exactly
match.  Better to have one reference clock and that is the
127.127.20.0 type clack.

What is happening is that the NMEA standard only requires the NMEA
sentences to be output during the second to which they apply.  So the
time is only accurate to within a second. Compared to any other clock
the NMEA-only GPS can be very poor.

GPS is one of the best reference clocks for NTP.  I'd use it as a
first choice unless for some reason you can't (for example you have no
way to install an antenna.)


On Sun, Apr 24, 2016 at 11:51 AM, jan hugo prins  wrote:
> Hi,
>
> To get a more stable NTP source into our production network I have
> started exprerimenting with a Raspberry PI 3 with a GPS head. GPS data
> is coming in fine, but the time is jumping around like a wild horse. The
> result is that the only thing I get out of this experiment so far is a
> more stable PPS signal in my NTP config but after some time both the GPS
> time and the PPS are marked a false ticker and the only thing left is
> the external reference clocks from outside our own network.
>
> Parts used:
> Raspberry PI 3
> Adafruit GPS head: ADA-2324
> External GPS antenna with 5 meter cable.
>
> My NTP config looks like this:
>
> logfile /var/log/ntpd.log
> logconfig = all
> driftfile /var/lib/ntp/ntp.drift
> statsdir /var/log/ntpstats/
> statistics loopstats peerstats clockstats
> filegen loopstats file loopstats type day enable
> filegen peerstats file peerstats type day enable
> filegen clockstats file clockstats type day enable
> server 127.127.22.0 minpoll 4 maxpoll 4 prefer
> fudge 127.127.22.0 refid PPS flag3 1
> server 127.127.28.0 minpoll 4 maxpoll 4 iburst
> fudge 127.127.28.0 refid GPS time1 +0.550 flag1 1 stratum 4
> server ntp0.nl.uu.net
> server chime6.surfnet.nl
> server chime5.surfnet.nl
> server ntp1.virtu.nl
>
> Now I got the idea that I might be able to use a DCF77 receiver to get a
> stable timesource, but on the other hand, if the cause of my problem is
> internal to the Raspberry PI setup then I might have exactly the same
> problem with the DCF77 receiver.
>
> The average on the NTP clocksource is close to 0.
> root@raspberrypi:/var/log/ntpstats# cat peerstats |grep 127.127.28.0
> |awk '{print $5}'| tail -n 1500 | awk 'NR == 1 { max=$1; min=$1; sum=0 }
> { if ($1>max) max=$1; if ($1 %d\tMax: %d\tAverage: %f\n", min, max, sum/NR}'
> Min: 0Max: 0Average: 0.001101
>
> Could anyone give me some advice on how to get this working? Or is my
> idea to use a GPS clock to create a stable NTP setup the wrong way to go?
>
> Thanks for any advice.
> Jan Hugo Prins
>
>
> ___
> 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.



-- 

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.

Re: [time-nuts] Raspberry PI 3 NTP server with GPS time data.

[Artek Manuals]

Jan

IS the GPS antenna "outside" with a clear view of the sky say at least 
down to 20 degrees elevation or is it "inside" the building?


Dave


On 4/24/2016 2:51 PM, jan hugo prins wrote:

Hi,

To get a more stable NTP source into our production network I have
started exprerimenting with a Raspberry PI 3 with a GPS head. GPS data
is coming in fine, but the time is jumping around like a wild horse. The
result is that the only thing I get out of this experiment so far is a
more stable PPS signal in my NTP config but after some time both the GPS
time and the PPS are marked a false ticker and the only thing left is
the external reference clocks from outside our own network.

Parts used:
Raspberry PI 3
Adafruit GPS head: ADA-2324
External GPS antenna with 5 meter cable.

My NTP config looks like this:

logfile /var/log/ntpd.log
logconfig = all
driftfile /var/lib/ntp/ntp.drift
statsdir/var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
server 127.127.22.0 minpoll 4 maxpoll 4 prefer
fudge 127.127.22.0 refid PPS flag3 1
server 127.127.28.0 minpoll 4 maxpoll 4 iburst
fudge 127.127.28.0 refid GPS time1 +0.550 flag1 1 stratum 4
server ntp0.nl.uu.net
server chime6.surfnet.nl
server chime5.surfnet.nl
server ntp1.virtu.nl

Now I got the idea that I might be able to use a DCF77 receiver to get a
stable timesource, but on the other hand, if the cause of my problem is
internal to the Raspberry PI setup then I might have exactly the same
problem with the DCF77 receiver.

The average on the NTP clocksource is close to 0.
root@raspberrypi:/var/log/ntpstats# cat peerstats |grep 127.127.28.0
|awk '{print $5}'| tail -n 1500 | awk 'NR == 1 { max=$1; min=$1; sum=0 }
{ if ($1>max) max=$1; if ($1

[time-nuts] Raspberry PI 3 NTP server with GPS time data.

[jan hugo prins]

Hi,

To get a more stable NTP source into our production network I have
started exprerimenting with a Raspberry PI 3 with a GPS head. GPS data
is coming in fine, but the time is jumping around like a wild horse. The
result is that the only thing I get out of this experiment so far is a
more stable PPS signal in my NTP config but after some time both the GPS
time and the PPS are marked a false ticker and the only thing left is
the external reference clocks from outside our own network.

Parts used:
Raspberry PI 3
Adafruit GPS head: ADA-2324
External GPS antenna with 5 meter cable.

My NTP config looks like this:

logfile /var/log/ntpd.log
logconfig = all
driftfile /var/lib/ntp/ntp.drift
statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
server 127.127.22.0 minpoll 4 maxpoll 4 prefer
fudge 127.127.22.0 refid PPS flag3 1
server 127.127.28.0 minpoll 4 maxpoll 4 iburst
fudge 127.127.28.0 refid GPS time1 +0.550 flag1 1 stratum 4
server ntp0.nl.uu.net
server chime6.surfnet.nl
server chime5.surfnet.nl
server ntp1.virtu.nl

Now I got the idea that I might be able to use a DCF77 receiver to get a
stable timesource, but on the other hand, if the cause of my problem is
internal to the Raspberry PI setup then I might have exactly the same
problem with the DCF77 receiver.

The average on the NTP clocksource is close to 0.
root@raspberrypi:/var/log/ntpstats# cat peerstats |grep 127.127.28.0
|awk '{print $5}'| tail -n 1500 | awk 'NR == 1 { max=$1; min=$1; sum=0 }
{ if ($1>max) max=$1; if ($1

Re: [time-nuts] [Announce] Simulation software for powerlaw noise and PTP clock synchronization

[Magnus Danielson]

Hi,

On 04/19/2016 07:46 AM, Wolfgang Wallner wrote:

Hello Anders,


Do you get agreement between PLN time-series and calcluated ADEVs, as per
IEEE1139-2008 table B.2 ?


Yes, I explicitly cite IEEE1139-2008 table B.2 in my thesis. I will
write a more detailed reply with example data later when I get home.

If you would like to try out the noise generations of libPLN: I also
wrote a small command line utility for LibPLN, called PLN_Generator. You
can find it in the Demo/ directoy [1].


I tried [3] using python libraries colorednoise [1] (also based on
Kasdin) and allantools [2], but it gives ADEVs that are
systematically higher than predicted by theory. OTOH the calculated MDEVs
seem to fall on the line that theory predicts. Image here:
http://www.anderswallin.net/wp-content/uploads/2016/04/colorednoise-1.png


I have only used ADEV and AVAR so far, so I don't know about the
MDEV-behavior of my simulated noise. I will try out your allan tools
when I get home.

But the conversion between AVAR and power spectral density has been
quite confusing for me, see [2] for an example. I thought I had figured
it out at the end, but maybe I'm still wrong :)


It depends. If you noises is true power-noises only and straight 
additions of them, then mapping works. But this is not generically true, 
so in generic there is no mapping guaranteed to work.



On your libPLN page the time-series graph is called 'time deviation'
which
could be a bit confusing as there is also an ADEV-like statistic called
time deviation. Perhaps time-series or 'phase observations' or similar is
better?


Yes, I agree that the wording is very unfortunate. IEEE 1139 first calls
x(t) time fluctuations and time derivative, but later refers to it as
time deviation in the text.

I only realized quite late that there is a name conflict with another
statistic measure.

I guess the easiest solution would be to replace all occurrences of
'time deviation' with e.g. 'time derivative'.


No. Keep Time deviation separate from TDEV and you are fine.

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.

Re: [time-nuts] suitable statistics for measurements with gaps

[jimlux]

On 4/23/16 6:28 PM, Michael Wouters wrote:

The technique used for dealing with gaps is really about handling random
gaps in an otherwise uniformly sampled sequence. The idea is that you take
your sequence, pad it out with the missing data (tagging those points with
a NaN or whatever) and then when you're computing ADEV, if a data triplet
is missing a point(s), you simply drop it from the summation.
This works nicely for ADEV and TOTDEV but not so well for MDEV.

There are a couple of implementations of this around: allantools (Python)
and tftools (Matlab/Octave) are at least two on GitHub.



thanks for the links..
I'll take a look.  I work in both languages..


___
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] Calculated ADEV does not match expectation

[Wolfgang Wallner]

Hello Anders, hello timenuts,

This is in reply to the thread "[Announce] Simulation software for 
powerlaw noise and PTP clock synchronization" [1].
I have changed the mail subject as the discussion has moved quite far 
from the initial message.


[1] https://www.febo.com/pipermail/time-nuts/2016-April/097272.html


> Do you get agreement between PLN time-series and calcluated ADEVs, as
> per IEEE1139-2008 table B.2 ?
>
> I tried [3] using python libraries colorednoise [1] (also based on
> Kasdin) and allantools [2], but it gives ADEVs that are
> systematically higher than predicted by theory. OTOH the calculated
>  MDEVs seem to fall on the line that theory predicts. Image here:
> http://www.anderswallin.net/wp-content/uploads/2016/04
> /colorednoise-1.png


I think it might be the best to discuss this with an actual example.

I had a look at the image that you provided and tried to compute a noise 
sample which is similar, and analyze it with the tools I use.


I will split the discussion into three parts, so that it is easier to 
follow the individual steps:


1) Calculating expected values
2) Generating a PLN sample
3) Analyzing the sample and compare with expectation


1) Calculating expected values


As already mentioned in my earlier reply, I had quite some troubles 
figuring out how all the formulas in IEEE 1139 and the Kasdin/Walter 
paper work, and I'm still not too confident. If any of the following 
steps raise doubts, please point it out.


I guessed the following values based on your image:

Sampling frequency f_s = 1Hz.
This implies that the highest measured frequency can be f_h = 0.5Hz
Also, it implies that the distance between two measurements Tau_0 = 1s.
For the example, I chose to use FFM noise.
This means alpha = -1 (Power S_y(f) ~ f^alpha), and mu = 0 (AVAR(Tau) ~ 
Tau^mu).

From the top right figure I guess that S_y(10-3Hz) = 10^-19.5.

From IEEE 1139 Table B.2 we know that: S_y(f) = h_alpha * f^alpha

In our example this means that S_y(10^-3) = h_-1 * (10^-3)^-1, which 
implies that h_-1 = 10^-22.5.


From IEEE 1139 we also know that B = 2 ln(2) = 1.3863.

Thus, the expected AVAR(Tau) would be B * h_-1 * Tau^0 = 1.3863 * 
10^-22.5 = 4.3838 * 10^-23 for all Tau.
Using ADEV = Sqrt(AVAR) we get that the expected ADEV(Tau) = 9.9346 * 
10^-23 for all Tau.


The important values are thus:
h_-1 = 10^-22.5
ADEV(Tau) = 9.9346 * 10^-23

Judging from the lower left plot in your image, I guess that we agree here.


2) Generating a PLN sample


The Kasdin/Walter PLN-generation approach starts with white noise, and 
applies filters to it. The standard variance Qd is an important 
configuration parameter.


The original paper gives a formula as follows:

Qd = h_alpha/[ 2 * (2 pi)^alpha * Tau_0^(alpha-1) ]

This formula leads to unexpected values when I use it with my 
implementation. However, the following modified version works as expected:


Qd = h_alpha/[ 2 * (2 pi)^alpha * Tau_0^(alpha+1) ]

The difference is the sign of the 1 at the end. I don't know if this is 
an error in the original paper, or if I have an error in my 
implementation and both errors compensate each other.


Using my modified formula, and the values for h_alpha and Tau_0 as 
stated above, I get


Qd = 9.9345 * 10^-23

As stated in my last mail, LibPLN comes with a small console application 
in its 'Demos' folder, which is called PLN_Generator.
PLN_Generator provides a simple interface to the most important parts of 
LibPLN, and can be used to easily genrate PLN samples:


./PLN_Generator --sampling-frequency 1Hz --pln-filter-method 
kasdin-walter --qd 9.9346E-23 --alpha -1 --kw-filter-length 100 
--number-of-samples 100 --output-filename 'ffm.txt' --verbose


This generates a file called 'ffm.txt', which contains 10^6 samples of 
Time Derivative values (or phase observations as you call it).

The file is 35MB in size thus I haven't attached it to the mail.
But I have uploaded it into my Dropbox account, and you can find it here:

https://www.dropbox.com/s/k8tj1b0ywptat3z/ffm.txt?dl=0


3) Analyzing sample and compare with expectation


I have used my Matlab Scripts scripts to analyze this sample file.
Attached to the mail you can find the following images:

TimeDerivative.png: Plot of the time derivative over time (so basically 
the raw information that is contained in the sample file)


ADEV.png: Plot of the calculated ADEV and the expected values as 
calculated in Section 1


PSD.png: Plot of the calculated PSD and the expected values as given in 
section 1.

The PSD is plotted in dB, calculated as PSD_db = 10 log10( PSD )

I plan to publish my Matlab scripts as GPL, so that they can be used 
together with LibPLN. But I haven't done so yet, mostly because they are 
just ugly prototypes right now.


For the calculation of the Allan Deviation I use the script 

Re: [time-nuts] HP OCXO warmup graphs

[Bob Camp]

Hi

The conjecture has always been that all of the 5334B’s with 10544’s were a 
field 
swap out. Why would you do such a thing? That’s never been explained. One 
*might* wonder if the fact that the 5334B sells for about the price of a 10811 
and
few would notice a (lower value) 10544 is involved ….

Bob



> On Apr 24, 2016, at 12:28 AM, Richard (Rick) Karlquist 
>  wrote:
> 
> 
> 
> On 4/23/2016 6:27 PM, Bob Camp wrote:
>> Hi
>> 
>> The 5334 spanned the era when the 10811 was being introduced. I’ve never been
>> able to sort out exactly *what* was in each version as shipped and what got 
>> swapped
>> around by various techs over the years. I always *thought* the 10811 was
>> standard for the 5334B version. There are a lot of examples running around
>> with earlier 10544 OCXO’s ...
>> 
>> If only the project manager for the 5334B was here on the list …. :)
>> 
> 
> Well, here I am :-).  The 5334B standard oscillator (not the OCXO) was
> the same as the 5334A standard oscillator.  Which was IIRC an
> inexpensive crystal with an oscillator circuit using ECL line
> receivers.  I simply continued using it because I didn't have time to 
> redesign everything.  An ECL line receiver is not a low phase noise
> design and has an adverse contribution to tempco.  OTOH, it is fool
> proof.  The only optional oscillator ever available from the factory
> was the 10811, which was well established by 1987, and the 10544 was
> long gone.  10811's are guaranteed to work in any 10544 socket, mainly
> because they don't draw any more warmup power than a 47 ohm resistor.
> 10811 sockets are not guaranteed to be compatible with 10544
> oscillators.  However, they are certainly mechanically compatible.
> It's entirely possible that a 10544 might work in a 5334B, but the
> factory never shipped such a configuration.  Where would they
> get 10544's?
> 
> Rick Karlquist N6RK
> Project Manager HP 5334B
> ___
> 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 OCXO warmup graphs

[Hal Murray]

csteinm...@yandex.com said:
> And, of course, it's still a matter of interpretation.  I look at  your plot
> and say, Yep, it should be mostly sorted in a  month.  Someone else might
> look at it and say, Looks like 3 days to  me.  Based on your plot, what do
> you say? 

It still has ~1 more PPB to go before it gets back to where it was.

For my use, the long term drift was small relative to the daily temperature 
wobbles so I didn't pay much attention to it.


>From the specifications section of the Operating and Programming Manual:

Long Term (Aging Rate):
A. <5 x 10-10 per day after 24-hour warm-up when:
  1. oscillator off-time was less than 24 hours.
  2. oscillator again rate was <5 x 10-10 per day prior to turn off.
B. <5 x 10-10 per day in less than 30 days of continuous
operation for off-time greater than 24 hours.
C. <1 x 10-7 per year of continuous operation.

Warmup: Within <5 x 10-9 of final value (see below) 10 min.
after turn-on when:
1 oscillator is operated in a 25 C environment with 20 Vdc
  Oven Supply voltage applied.
2.  oscillator off time was less then 24 hours.
3.  oscillator aging rate was <5 x 10-10 per day prior to turn-off.
4.  Final value is defined as oscillator frequency 24 hours after
  turn-on.


The -10s and -7 and -9 above should be superscript.
In the manual, the - is missing in front of the 7.

The Technical Data blurb (16 pages) says:
  Aging Rate: < 5 x 10-10/day after 24 hour warm up.
(no constraints)
  Warm Up: Within 5 x 10-9 of final value in 20 minutes.

I didn't get a clean start so I can't check the 10 or 20 minute part.



-- 
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.

Re: [time-nuts] Agilent Data logger3 info request

[timeok]

Ok Thank you all you, I will try these solutions and I will  ask also to 
Keysight.

Luciano
www.timeok.it



On Sun 24/04/16 00:10 , jimlux  wrote:

> On 4/23/16 12:15 PM, DaveH wrote:
> > .csv (comma seperated values) is a text format, .gif (graphical
> interchange
> > format) is an image format.
> >
> > These are not interchangable.
> >
> > Your best bet would be to use MS Excel or the free open office
> spreadsheet,
> > import your values and use it to format and generate the graph.
> >
> 
> or Gnuplot (a bit tricky to get started with.. lots of options, but 
> there are tutorials on the web), or if you want something with a bit 
> more computation behind it: Octave is a open source Matlab-like with 
> reasonably ok plotting. And Matplotlib for Python/Scipy/Numpy is pretty 
> good.
> 
> My usual strategy is to try excel first, but if it doesn't give me 
> something useful "right away", then I stop struggling and fire up Octave 
> or SciPy, which give a LOT more control.
> 
> Or, if at work, where we have licenses, Matlab - Matlab has great 
> plotting, in general.
> 
> > Dave
> >
> >> -Original Message-
> >> From: time-nuts [time-nuts-boun...@febo.com] On Behalf
> >> Of tim...@timeok.it
> >> Sent: Saturday, April 23, 2016 07:16
> >> To: Discussion of precise time and frequency measurement;
> >> time-nuts@febo.com
> >> Subject: [time-nuts] Agilent Data logger3 info request
> >>
> >>
> >> I have an Agilent 34970A data logger. It use the "Bencklink
> >> Data Logger3" as software.
> >>
> >> I would like to capture the graph in a printable format
> >> instead the original .csv . A .gif will be good to be
> >> inserted in documents.
> >>
> >> Can some one help me?
> >>
> >> thanks ,
> >> Luciano
> >> www.timeok.it [1]
> >>
> >> Message sent via Atmail Open - http://atmail.org/ [2]
> >> ___
> >> time-nuts mailing list -- time-nuts@febo.com
> >> To unsubscribe, go to
> >> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts [3]
> >> 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 [4]
> > 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 [5]
> and follow the instructions there.
> 
> 
> 
> Links:
> --
> [1] http://webmail.timeok.it/parse.php?redirect=http://www.timeok.it
> [2] http://webmail.timeok.it/parse.php?redirect=http://atmail.org/
> [3]
> http://webmail.timeok.it/parse.php?redirect=https://www.febo.com/cgi-bin/ma
> ilman/listinfo/time-nuts[4]
> http://webmail.timeok.it/parse.php?redirect=https://www.febo.com/cgi-bin/ma
> ilman/listinfo/time-nuts[5]
> http://webmail.timeok.it/parse.php?redirect=https://www.febo.com/cgi-bin/ma
> ilman/listinfo/time-nuts
> 
Message sent via Atmail Open - http://atmail.org/
___
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] Convert ADEV specs to MDEV?

[Magnus Danielson]

Hi,

Well, there is differences in level, there is tables for it, so while on 
the large scale they are close, they are not the same.


Vernotte have a table of it in one of the PVAR articles for instance.

Cheers,
Magnus

On 04/23/2016 02:15 PM, Bob Camp wrote:

Hi

The intended purpose of MDEV was to supply a plot that looked the same as an 
ADEV
plot *except* for separating flicker phase. To the extent they succeeded, you 
can use
the same plot on either one. (and as long as flicker phase is not an issue). To 
the extent
they failed, you are stuck.

Bob


On Apr 23, 2016, at 12:58 AM, Magnus Danielson  
wrote:

Hi,

On 04/23/2016 02:54 AM, Stewart Cobb wrote:

TimeLab can show "mask" overlays on various plots. It comes with a set of
ADEV masks for cesium clocks, derived from the manufacturer's
specifications for those clocks.

Those masks don't show up on MDEV plots, because the manufacturers don't
provide MDEV specs.

For the mathematicians out there: is there a way to convert ADEV specs into
equivalent MDEV specs?

If not, does anyone have good measured MDEV data on any of the popular
cesium clocks?


The slopes of ADEV for the different noises can be converted to slopes in MDEV. 
It is the separation of white phase modulation and flicker phase modulation 
that doesn't go very well with ADEV, but works in MDEV, but if you ignore the 
flicker then you should be able to translate without too much difficulty.

Good luck!

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.


___
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 OCXO warmup graphs

[Charles Steinmetz]

Hal wrote:


I remember seeing comments that were roughly "it takes a month" and that
seemed like a long time.  This was a convenient opportunity to collect some
hard data.


And, of course, it's still a matter of interpretation.  I look at 
your plot and say, Yep, it should be mostly sorted in a 
month.  Someone else might look at it and say, Looks like 3 days to 
me.  Based on your plot, what do you say?


Also note that your oscillator was unplugged for a week or two, 
presumably after being on-power and in a stable location/environment 
for a long time.  This is pretty much the best case.  Most time-nuts 
buy oscillators of unknown provenance that have been off power for 
months to years, with (maybe) a brief power-up cycle to check them 
out by the seller, then shipped across the country or halfway around 
the world.  Many of those will take much longer to stabilize than 
yours looks like it's going to take.  (I hope you're still taking 
data -- it will be interesting to see if there are any surprise jumps 
or drifts before it settles down "for good," which happens more than 
occasionally.)


What do we mean by "unknown provenance"?  I've watched breakers 
remove oscillators from equipment and toss them ten feet into a big 
metal bin.  After sale at auction, the oscillators was poured out of 
the metal bin into a pickup bed and driven across town, where they 
were shoveled (literally, with a snow shovel) out of the truck bed 
onto a concrete floor.  One of the nicer-looking oscillators was 
photographed for an ebay ad, and when one sold a random oscillator 
was pulled from the pile and shipped to the winning bidder.  If a 
customer complained, they sent another random pull and when the first 
one was returned, it was tossed back on the pile.  And this is in the 
US -- I've heard *much* scarier stories about breakers in other countries.


Best regards,

Charles


___
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.