Re: [time-nuts] HP 59309A Clock runs, sets via GPIB, but no GPIB output?

[Paul Berger]

On 2016-10-06 4:56 PM, Bob wrote:

I'd like to ask the HP 59309A owners on time-nuts if the following symptoms 
sound familiar, and if so, what would the fix be?

o New-to-me HP 59309A clock.
o Late build, 1985 date code on many parts.
o I replaced the big 1900 uF electrolytic before plugging it in.
o Visual inspection very clean, no corrosion, no battery.
o 12v reads 13.1v, 5v reads 5.3v, -2v reads -2.9v.
o Front panel switches and buttons all work as expected.
o Internal and external osc. both work as expected.
o Internal "format" switch set to  i.e. comma, cal, no space.
o GPIB works to *set* the time, using Prologix Ethernet adapter.
o Prologix Ethernet adapter attached directly to the clock, no cables.
o Python code to set via GPIB attached below.
o Setting time via GPIB always works, tried many times.
o Reading time has never worked.  All I get is lots of ASCII 
444...
o Reading with Prologix ++read command
o Switches set to 1100010 i.e. Listen, ADDR 2 for normal operation
o Tried switches as 010 i.e. Talk Only, also resulted in continuous 
444...
o Tried very long delays between every GPIB command, no change.
o Tried removing top cover and running a fan to bring entire clock to 21C, no 
change.
o Tried gently reseating the four boards and three socketed PROMS, no change.

Thanks to TVB for hp59309.c sample Windows Prologix USB code.  I based the 
Python Ethernet code on TVB, to read from the clock he sends command C and then 
++read.  When I do that all I get are a zillion 0x34 '4' characters.

Seems strange that all the GPIB commands work.  I tried R reset, P pause T 
resume D day H hour M minute S second manually and they all work just fine.  I 
have never been able to read anything reasonable though.

As to the Prologix Ethernet adapter, I believe it is working OK electrically as 
I have been using it for weeks at a time reading PPS time intervals from a 
trusty HP 5334B counter, the adapter has read hundreds of thousands times from 
the 5334B.

Is there a trick to using the Prologix to read from the 59309A?

I did notice that the 59309A has at least one trick - in TVB's code where he 
reads the Prologix settings and only writes them if they need to be changed, 
that is actually required(!).  Just writing them every time seems to put the 
adapter into a strange state.

Page 4-2 of the 59309A manual seems to imply that the "Output State Machine" generates 
the GPIB output messages, using input from the "Data Memory".  AFAICT, those two 
functional blocks are the only ones that are not working for me.

I think A4U18 ROM is OK as it handles GPIB command decoding and R P T D H M S 
commands all work.

A5U15 appears to do the ASCII encoding for SP, CR, LF, ", : so it may or may 
not be OK.

A5U2 is described as "STATE MACHINE ROM (A5U2). This 4K ROM controls the operation 
of the circuits that develop the talk output of the 59309A."  Has anyone experienced 
failure of this ROM, and do the symptoms match what I'm seeing?

This is a lovely clock, and while I can't actually think of a reason to *need* 
the GPIB time output, I'd still like to fix it.

Cheers,

Bob Marinelli






___
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.
I have two of these clock both working, however I have never tried to 
read one with anything like a Prologix adapter I have only used mine 
with HP computer of a similar vintage, however as long as the adapter 
adheres to the handshake timing it should be ok.  I was going to say 
that the -2 seemed excessively high, but I just checked one of mine and 
it is -3V and works fine.  Since it display fine my guess would be that 
the problem area would be at the right end of sheet  2 of the A5 board.  
Yes it is possible for ROMs to go bad, but I have not experienced it 
personally.   Since your adapter is reading something that would suggest 
it is handshaking on the GPIB bus, but the fact that it seems to run 
away might suggest that the send sequence does not terminate correctly, 
in the mode you say you have it set for it should send a string of 18 
characters including the terminating CR LF and then stop, however in 
talk only mode there will likely not be a big break between strings.


 If you set it to talk always you should see the RAM addresses cycling 
and on the input side it should alternate between addresses coming from 
the A4 side and addresses coming from the state machine ROM.  If you had 
a logic analyzer you could monitor the inputs and outputs of the RAM as 
well as the addresses as it cycles through loading and reading out the 
addresses.  On page  5-9 there is a table of the state machine ROM 
contents note addresses are in octal, you could remove U1 and U3 and 
then supply your own TTL level addresses to the ROM to see if you get 
the correct bits out or it A7 is 

Re: [time-nuts] Measure GPSDO stability with minimum resources?

[Magnus Danielson]

Hi,

On 10/06/2016 08:38 PM, Bob Camp wrote:

Hi

One very simple experiment:

Take a HP that has been off power for a year or so. Fire it up and watch it’s 
predictions
of holdover accuracy. Many of them will go through a “zero” time estimate at 
one or
two days. At three or four days they are struggling to hit spec (10us). The 
reason is
pretty simple. The OCXO warmed up and went through an inflection (reversal in 
direction).
They estimated across the inflection, got zero and passed that on ….


Indeed. The Z3801A does a least-square fit and then tries to maintain 
that. If done at the wrong time it will be wildly off. I don't remember 
the details, but I think I recall that you can trigger the 
re-calibration routine which is what you want to do to drive it in the 
right direction.


Least-square fitting isn't all that magic and doesn't really require 
lots of memory, if you do it properly. You just need the oscillator to 
heat up and settle before you attempt to do anything involving long 
time-constants. Usually it's not the core algorithms, but the heuristics 
that needs to work well.


Cheers,
Magnus


Bob


On Oct 6, 2016, at 1:32 PM, Bob Stewart  wrote:

said: "The somewhat amazing holdover estimates on the HP units are one example of 
this problem. It does not take much testing to quickly realize that they are far more 
often wrong than right on a unit that has been on power for less than a few weeks."
Thank you Bob.  These two sentences clear it all up.  Silly me thinking that 
the HP units could actually project aging from minimum data.  I can sample 
every hour and always have the past 24 hours to look at.  In fact, it might 
even be better to have multiple days in the queue and take a simple average for 
projection.  Naivety has been my biggest foe in this project.

Bob
 -
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

 From: Bob Camp 
To: Discussion of precise time and frequency measurement 
Sent: Thursday, October 6, 2016 12:24 PM
Subject: Re: [time-nuts] Measure GPSDO stability with minimum resources?

Hi

As normally used, the term “aging” means the long term drift in the frequency 
of an OCXO.
It is independent of the temperature effects and things like retrace, warmup, 
and voltage
stability. It is rare that there is any impact on the aging of a properly 
designed OCXO from
drift of the oven temperature.

Any time you try to estimate (or measure) aging on an OCXO, you will have a 
hard time
separating it from the other things that affect the frequency of the 
oscillator. The somewhat
amazing holdover estimates on the HP units are one example of this problem. It 
does not
take much testing to quickly realize that they are far more often wrong than 
right on a unit
that has been on power for less than a few weeks.

Bob


On Oct 6, 2016, at 1:11 PM, Chris Albertson  wrote:

Wouldn't "aging" be the change in the temperature v. frequncy graph over
time?  It is hard to hold temperture constant so maybe record the
function at several different times.

This is one big advantage of using a microprocessor inside the GPSDO, It
can log internal data to either a SD card or use a USB link to a PC to be
recored in log files.  Even my "simple as possible" GPSDO push data to a
PC over USB.  It is easy to glue a temperature sensor to "whatever" and
log it

On Wed, Oct 5, 2016 at 10:14 PM, Hal Murray  wrote:



j99har...@gmail.com said:

Unless the oscillator is still warming up, 5 minutes or even 60 is way

too

short a time to look at aging. For aging, you will want to look at the
change in DAC values over several days at least.


I think it's worse than that.  You have to hold the temperature constant,
and
maybe even the power supply voltage.  A probe on the crystal can might
allow
you to correct for temperature.




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





--

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.



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

Re: [time-nuts] Need Time Help

[Alberto di Bene]

On 10/6/2016 8:10 PM, Wes wrote:


Although I personally ceased pursuing this activity many years ago, there remain
some of us, who are not Luddites, but still believe that "Deep Search Decoding"
is a questionable practice, no matter how it is rationalized.



"Deep Search Decoding" of the JT modes is exactly equivalent to the mental deep 
search
of common call signs done by the CW addicts when receiving just a partial call 
sign, trying
to figure who could be that operator, examining in their brain the list of the 
most probable
persons active in CW EME...Nothing more, nothing less...

But this is a discussion best suited for the Moon-Net list, where it happened 
umpteen times...

73  Alberto  I2PHD




___
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] HP 59309A Clock runs, sets via GPIB, but no GPIB output?

[Bob]

I'd like to ask the HP 59309A owners on time-nuts if the following symptoms 
sound familiar, and if so, what would the fix be?

o New-to-me HP 59309A clock.
o Late build, 1985 date code on many parts.
o I replaced the big 1900 uF electrolytic before plugging it in.
o Visual inspection very clean, no corrosion, no battery.
o 12v reads 13.1v, 5v reads 5.3v, -2v reads -2.9v.
o Front panel switches and buttons all work as expected.
o Internal and external osc. both work as expected.
o Internal "format" switch set to  i.e. comma, cal, no space.
o GPIB works to *set* the time, using Prologix Ethernet adapter.
o Prologix Ethernet adapter attached directly to the clock, no cables.
o Python code to set via GPIB attached below.
o Setting time via GPIB always works, tried many times.
o Reading time has never worked.  All I get is lots of ASCII 
444...
o Reading with Prologix ++read command
o Switches set to 1100010 i.e. Listen, ADDR 2 for normal operation
o Tried switches as 010 i.e. Talk Only, also resulted in continuous 
444...
o Tried very long delays between every GPIB command, no change.
o Tried removing top cover and running a fan to bring entire clock to 21C, no 
change.
o Tried gently reseating the four boards and three socketed PROMS, no change.

Thanks to TVB for hp59309.c sample Windows Prologix USB code.  I based the 
Python Ethernet code on TVB, to read from the clock he sends command C and then 
++read.  When I do that all I get are a zillion 0x34 '4' characters.

Seems strange that all the GPIB commands work.  I tried R reset, P pause T 
resume D day H hour M minute S second manually and they all work just fine.  I 
have never been able to read anything reasonable though.

As to the Prologix Ethernet adapter, I believe it is working OK electrically as 
I have been using it for weeks at a time reading PPS time intervals from a 
trusty HP 5334B counter, the adapter has read hundreds of thousands times from 
the 5334B.

Is there a trick to using the Prologix to read from the 59309A?

I did notice that the 59309A has at least one trick - in TVB's code where he 
reads the Prologix settings and only writes them if they need to be changed, 
that is actually required(!).  Just writing them every time seems to put the 
adapter into a strange state.

Page 4-2 of the 59309A manual seems to imply that the "Output State Machine" 
generates the GPIB output messages, using input from the "Data Memory".  
AFAICT, those two functional blocks are the only ones that are not working for 
me.

I think A4U18 ROM is OK as it handles GPIB command decoding and R P T D H M S 
commands all work.

A5U15 appears to do the ASCII encoding for SP, CR, LF, ", : so it may or may 
not be OK.

A5U2 is described as "STATE MACHINE ROM (A5U2). This 4K ROM controls the 
operation of the circuits that develop the talk output of the 59309A."  Has 
anyone experienced failure of this ROM, and do the symptoms match what I'm 
seeing?

This is a lovely clock, and while I can't actually think of a reason to *need* 
the GPIB time output, I'd still like to fix it.

Cheers,

Bob Marinelli

#!/usr/bin/python
# Initialize HP 59309A GPIB clock to local time
# Thanks to TVB for http://www.leapsecond.com/tools/hp59309a.c
# For UTC, use datetime.utcnow instead of datetime.now

import datetime, socket, string, sys, time

# IP address of Prologix Controller 
host = "192.168.20.7"

# GPIB address of HP 59309A clock
addr = "2"

# Read one line from Prologix
def gpib_read(s):
  buf = ""
  while (1):
c = s.recv(1)
if not c:
  print "Connection closed"
  sys.exit(1)
if c == '\n':
  return buf
if c != '\r':
  buf = buf+c

# Send one command and EOL to Prologix
def gpib_send(s, cmd):
  s.send(cmd+"\n")

# Send one GPIB command and return reply
def gpib_query(s, cmd):
  gpib_send(s, cmd)
  gpib_send(s, "++read")
  return gpib_read(s)

# Send Prologix command and return reply
def prologix_query(s, cmd):
  gpib_send(s, cmd)
  return gpib_read(s)

prologix_cfg = [
  ("++savecfg", "0"),# do not update eeprom
  ("++mode","1"),# device=0 controller=1
  ("++auto","0"),# automatic read-after-write
  ("++eoi", "0"),# disable EOI
  ("++eos", "3"),# 0=CR+LF 1=CR 2=LF 3=none
  ("++read_tmo_ms", "1000"), # set read timeout (milliseconds)
  ("++addr",addr)# user-supplied gpib address
] 

# Initialize Prologix, only change as needed
def prologix_init(s):
  for cmd, val in prologix_cfg:
old = prologix_query(s, cmd)
if old != val:
  gpib_send(s, cmd + " " + val)

# Quiesce Prologix
def prologix_done(s):
  gpib_send(s, "++loc")
  gpib_send(s, "++mode 0")

if __name__ == "__main__":
  s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
  s.settimeout(2)
 
  # Connect to Prologix on port 1234
  try :
s.connect((host, 1234))
  except :
print "Unable to connect to", host
sys.exit(1)

  # Confirm we are talking to 

Re: [time-nuts] GPSDO Sigma Tau at large observation times

[Tom Van Baak]

>> See also the examples here: http://leapsecond.com/pages/gpsdo/
> 
> Hi Tom, quick question: I've seen these plots before and they are very
> useful to know what to aim at for GPSDO performance. Am I right in
> thinking these were measured against a master - the page says " a very
> stable 10 MHz reference. " without more details (unless I missed it)

Hi Tim,

Yes, I think so. I can check, but if I say something like "a very stable 
reference" it usually means I picked something sufficiently accurate for the 
job. As a rule-of-thumb you want both your time/frequency comparator instrument 
and your time/frequency reference to be 10x better than the device you are 
testing. So to measure a typical GPSDO you want at least a rubidium, if not 
cesium or H-maser. But the key point is to always be aware of the limitations 
of your own test setup as they may affect the look of the ADEV plot. Using 
multiple comparators and references with N-corner hat techniques is often a 
useful trick.

If you want to get picky there are other factors hidden behind every ADEV plot. 
Often unstated is the bandwidth of the measurement and also the type of Allan 
statistic being used (ADEV, MDEV, HDEV, etc.). Temperature and airflow too: an 
ADEV plot may look different if it was created from data in a +/-0.1C lab vs. a 
+/-10 C lab. And with GPSDO, an ADEV plot can also be affected by the quality 
of your antenna, the quality of your sky-view, and especially, your latitude. 
So all these factors go into what the ADEV plot looks like.

BTW, one of my greatest surprises was the effect of still air on a plain TCXO. 
We call it "still", but it is nothing but stationary! The plots and two photos 
shows the massive difference a single sheet of TP makes: 
http://leapsecond.com/pages/LTE-Lite/


But back to your question. There's a good chance I used a TSC 5120 analyzer and 
a CH1-76 passive H-maser for all those GPSDO plots. This means all the data 
beyond about tau 1 s is fully trustable. The data nearer tau 0.1 s is likely 
distorted by a known short-term noise issue in that particular surplus maser.


And this brings up another point. Both Allan deviation (ADEV) and phase noise 
(PN) plots tend to cover a wide dynamic range. So in general no one reference 
is perfect both short-term and long-term, both close-in and far-out. For 
example, the typical cesium standard is good for long-term but not so good for 
short-term (a free-running high-quality quartz can be better). And my best ULN 
(ultra low noise) quartz standards have superb phase noise, but lousy ADEV. A 
good quartz will blow away GPS short- and mid-term; but GPS wins in the 
long-term. For short-term a free-running GPSDO is always better than a locked 
GPSDO. And so on.

All this is just a reminder that you constantly have to double check your 
assumptions. An ADEV or PN plot is merely the sum of all the noise in the 
"system": the DUT, the instrument, the REF noise, but also the room, weather, 
cables, wife/kids/pets, power lines, FM stations, etc. And that sum changes as 
you slide from the left to the right of the plots.

/tvb

___
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] Measure GPSDO stability with minimum resources?

[jimlux]

On 10/6/16 10:11 AM, Chris Albertson wrote:

Wouldn't "aging" be the change in the temperature v. frequncy graph over
time?  It is hard to hold temperture constant so maybe record the
function at several different times.

This is one big advantage of using a microprocessor inside the GPSDO, It
can log internal data to either a SD card or use a USB link to a PC to be
recored in log files.   Even my "simple as possible" GPSDO push data to a
PC over USB.   It is easy to glue a temperature sensor to "whatever" and
log it

In fact, many processors like the Freescale parts used on the Teensy 
have a temperature sensor built into them - sure it's the die temp, and 
it varies with processor loading, but it's better than nothing.



___
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] Need Time Help

[jimlux]

On 10/6/16 11:15 AM, William H. Fite wrote:

Indeed, Nick. And more than a little (usually) courteous one upmanship
couched in terms of being helpful by correcting all previous posters. This
gentlemanly "mine is bigger than yours" phenomenon is part of what makes
this group fun to read.



Except that here, the popular metrics (AVAR, Phase Noise, etc.) are 
"smaller is better" so the bragging rights go to the list member 
claiming 1E-16 over, say, the relatively feeble 1E-6.



When you get to those sorts of levels, too, it's a lot of attention to 
the details that lets you get there.


It's like GPS: getting 10 meter accuracy is easy
Getting 1 meter is tougher but still straightforward

But getting to centimeters, all of a sudden there's all these factors 
that are insignificant at the 10 meter level but all significant at the 
centimeter level: solid earth tides, ionospheric issues, multipath, etc.


And what's great about this group is that there are people on the list 
who have been bitten by probably every thing that can go wrong (not one 
person had ALL of them, but spanning the group) or could be speculated 
to go wrong.





On Thu, Oct 6, 2016 at 2:03 PM, Nick Sayer via time-nuts  wrote:

Hi

That’s very typical in a lot of forums. The OP tosses up a question and

then pretty much vanishes.

My observation is that roughly 80% of the “I have a question” threads

work that way.

I’ve never been able to figure out if it is an expectation that all

answers will arrive in an hour or two

or if the OP is simply reading along and sees no reason to providing

more information to the group.

Either way, I’m pretty sure that the focus of the answers is not all

that great a week after the last input.


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.







___
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] Need Time Help

[William H. Fite]

Very true, Tom! I stand corrected.

On Thu, Oct 6, 2016 at 2:50 PM, Tom Van Baak  wrote:

> Bill,
>
> Some of the key topics of this hobby are -- what did it cost, absolute
> time error, relative frequency instability, and phase noise. In these cases
> the goal of time nuts is always "mine is smaller than yours".
>
> /tvb
>
> - Original Message -
> From: "William H. Fite" 
> To: "Nick Sayer" ; "Discussion of precise time and
> frequency measurement" 
> Sent: Thursday, October 06, 2016 11:15 AM
> Subject: Re: [time-nuts] Need Time Help
>
>
> Indeed, Nick. And more than a little (usually) courteous one upmanship
> couched in terms of being helpful by correcting all previous posters. This
> gentlemanly "mine is bigger than yours" phenomenon is part of what makes
> this group fun to read.
>
> On Thu, Oct 6, 2016 at 2:03 PM, Nick Sayer via time-nuts <
> time-nuts@febo.com
> > wrote:
>
> > To be fair, this is at least partly because asking a relatively simple
> > question here routinely turns into a dissertation defense.
> >
> > > On Oct 6, 2016, at 3:45 AM, Bob Camp  wrote:
> > >
> > > Hi
> > >
> > > That’s very typical in a lot of forums. The OP tosses up a question and
> > then pretty much vanishes.
> > > My observation is that roughly 80% of the “I have a question” threads
> > work that way.
> > > I’ve never been able to figure out if it is an expectation that all
> > answers will arrive in an hour or two
> > > or if the OP is simply reading along and sees no reason to providing
> > more information to the group.
> > > Either way, I’m pretty sure that the focus of the answers is not all
> > that great a week after the last input.
> > >
> > > 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.
>



-- 
Intelligence has never been proof against stupidity.
___
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] Measure GPSDO stability with minimum resources?

[Tom Van Baak]

> I think it's worse than that.  You have to hold the temperature constant, and 

Hi Hal,

I concur. Here is a nice example for all of you:

http://leapsecond.com/pages/tbolt/TBolt-20a-043.gif

The image shows 20 new Trimble Thunderbolt's being tested for aging in my 
house. The daily temperature change was about 5 C. Horizontal scale is about 5 
days elapsed time. Vertical scale is some ppb or ppt in frequency. The actual 
numbers aren't important here.

What *is* instructive about the image is that it shows that "identical" 
oscillators can have very different tempco's and that oscillators can have very 
different aging rates. And to your point, it also demonstrates that in many 
cases an aging rate measurement can take many days before you know if it's just 
aging or if it's other effects (temperature, voltage, humidity, pressure, tilt, 
retrace, etc.).

One way to speed up the process is keep the ambient measurement constant as you 
suggest. Another way is to measure the temperature and then post-process the 
data for a fit of both temperature and aging. This is also one reason why many 
GPSDO, like the TBolt, have internal precision thermometers. It helps the user 
(or optionally the disciplining algorithm) distinguish thermal effects from 
aging effects.

Just a reminder -- what we usually mean by oscillator "aging" is the long-term 
secular drift in frequency over time due to physical effects within the 
oscillator. This systematic effect not only applies to quartz crystals, but 
also to a lesser degree: rubidium vapor, rubidium & cesium CSAC, and hydrogen 
maser clocks. By contrast, cesium beam and cesium fountain designs tend not to 
have aging effects.

Note also that aging rates are traditionally quoted in "per day" units, even 
though technically the units are seconds per second per second. For example, 
the aging spec for a 10811A quartz oscillator is 5e-10/day. This does *not* 
imply that it is or will be consistent day by day, nor that you are able to 
measure it within one day. For some oscillators it is not uncommon to have to 
collect a month of data before you have a clue what the daily aging rate is, 
how consistent it is, how predictable it is, and so on.

/tvb

- Original Message - 
From: "Hal Murray" 
To: "Discussion of precise time and frequency measurement" 
Cc: 
Sent: Wednesday, October 05, 2016 10:14 PM
Subject: Re: [time-nuts] Measure GPSDO stability with minimum resources?


> 
> j99har...@gmail.com said:
>> Unless the oscillator is still warming up, 5 minutes or even 60 is way too
>> short a time to look at aging. For aging, you will want to look at the
>> change in DAC values over several days at least. 
> 
> I think it's worse than that.  You have to hold the temperature constant, and 
> maybe even the power supply voltage.  A probe on the crystal can might allow 
> you to correct for temperature.
> 
___
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] Need Time Help

[Tom Van Baak]

Bill,

Some of the key topics of this hobby are -- what did it cost, absolute time 
error, relative frequency instability, and phase noise. In these cases the goal 
of time nuts is always "mine is smaller than yours".

/tvb

- Original Message - 
From: "William H. Fite" 
To: "Nick Sayer" ; "Discussion of precise time and frequency 
measurement" 
Sent: Thursday, October 06, 2016 11:15 AM
Subject: Re: [time-nuts] Need Time Help


Indeed, Nick. And more than a little (usually) courteous one upmanship
couched in terms of being helpful by correcting all previous posters. This
gentlemanly "mine is bigger than yours" phenomenon is part of what makes
this group fun to read.

On Thu, Oct 6, 2016 at 2:03 PM, Nick Sayer via time-nuts  wrote:

> To be fair, this is at least partly because asking a relatively simple
> question here routinely turns into a dissertation defense.
>
> > On Oct 6, 2016, at 3:45 AM, Bob Camp  wrote:
> >
> > Hi
> >
> > That’s very typical in a lot of forums. The OP tosses up a question and
> then pretty much vanishes.
> > My observation is that roughly 80% of the “I have a question” threads
> work that way.
> > I’ve never been able to figure out if it is an expectation that all
> answers will arrive in an hour or two
> > or if the OP is simply reading along and sees no reason to providing
> more information to the group.
> > Either way, I’m pretty sure that the focus of the answers is not all
> that great a week after the last input.
> >
> > 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] Need Time Help

[Bob Camp]

Hi

Often the dive into the fine details is all that is left without guidance from 
the OP. After a few days (here or elsewhere) it can get pretty deep ….

Bob


> On Oct 6, 2016, at 2:03 PM, Nick Sayer via time-nuts  
> wrote:
> 
> To be fair, this is at least partly because asking a relatively simple 
> question here routinely turns into a dissertation defense.
> 
>> On Oct 6, 2016, at 3:45 AM, Bob Camp  wrote:
>> 
>> Hi
>> 
>> That’s very typical in a lot of forums. The OP tosses up a question and then 
>> pretty much vanishes. 
>> My observation is that roughly 80% of the “I have a question” threads work 
>> that way. 
>> I’ve never been able to figure out if it is an expectation that all answers 
>> will arrive in an hour or two 
>> or if the OP is simply reading along and sees no reason to providing more 
>> information to the group.
>> Either way, I’m pretty sure that the focus of the answers is not all that 
>> great a week after the last input.  
>> 
>> 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.

___
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] Measure GPSDO stability with minimum resources?

[Bob Camp]

Hi

One very simple experiment:

Take a HP that has been off power for a year or so. Fire it up and watch it’s 
predictions 
of holdover accuracy. Many of them will go through a “zero” time estimate at 
one or 
two days. At three or four days they are struggling to hit spec (10us). The 
reason is 
pretty simple. The OCXO warmed up and went through an inflection (reversal in 
direction). 
They estimated across the inflection, got zero and passed that on ….

Bob

> On Oct 6, 2016, at 1:32 PM, Bob Stewart  wrote:
> 
> said: "The somewhat amazing holdover estimates on the HP units are one 
> example of this problem. It does not take much testing to quickly realize 
> that they are far more often wrong than right on a unit that has been on 
> power for less than a few weeks."
> Thank you Bob.  These two sentences clear it all up.  Silly me thinking that 
> the HP units could actually project aging from minimum data.  I can sample 
> every hour and always have the past 24 hours to look at.  In fact, it might 
> even be better to have multiple days in the queue and take a simple average 
> for projection.  Naivety has been my biggest foe in this project.
> 
> Bob
>  -
> AE6RV.com
> 
> GFS GPSDO list:
> groups.yahoo.com/neo/groups/GFS-GPSDOs/info
> 
>  From: Bob Camp 
> To: Discussion of precise time and frequency measurement  
> Sent: Thursday, October 6, 2016 12:24 PM
> Subject: Re: [time-nuts] Measure GPSDO stability with minimum resources?
> 
> Hi
> 
> As normally used, the term “aging” means the long term drift in the frequency 
> of an OCXO. 
> It is independent of the temperature effects and things like retrace, warmup, 
> and voltage
> stability. It is rare that there is any impact on the aging of a properly 
> designed OCXO from 
> drift of the oven temperature. 
> 
> Any time you try to estimate (or measure) aging on an OCXO, you will have a 
> hard time
> separating it from the other things that affect the frequency of the 
> oscillator. The somewhat
> amazing holdover estimates on the HP units are one example of this problem. 
> It does not
> take much testing to quickly realize that they are far more often wrong than 
> right on a unit
> that has been on power for less than a few weeks.
> 
> Bob
> 
>> On Oct 6, 2016, at 1:11 PM, Chris Albertson  
>> wrote:
>> 
>> Wouldn't "aging" be the change in the temperature v. frequncy graph over
>> time?  It is hard to hold temperture constant so maybe record the
>> function at several different times.
>> 
>> This is one big advantage of using a microprocessor inside the GPSDO, It
>> can log internal data to either a SD card or use a USB link to a PC to be
>> recored in log files.  Even my "simple as possible" GPSDO push data to a
>> PC over USB.  It is easy to glue a temperature sensor to "whatever" and
>> log it
>> 
>> On Wed, Oct 5, 2016 at 10:14 PM, Hal Murray  wrote:
>> 
>>> 
>>> j99har...@gmail.com said:
 Unless the oscillator is still warming up, 5 minutes or even 60 is way
>>> too
 short a time to look at aging. For aging, you will want to look at the
 change in DAC values over several days at least.
>>> 
>>> I think it's worse than that.  You have to hold the temperature constant,
>>> and
>>> maybe even the power supply voltage.  A probe on the crystal can might
>>> allow
>>> you to correct for temperature.
>>> 
>>> 
>>> 
>>> 
>>> --
>>> 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.
>>> 
>> 
>> 
>> 
>> -- 
>> 
>> 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.
> 
> 
> 
> ___
> 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] Need Time Help

[William H. Fite]

Indeed, Nick. And more than a little (usually) courteous one upmanship
couched in terms of being helpful by correcting all previous posters. This
gentlemanly "mine is bigger than yours" phenomenon is part of what makes
this group fun to read.

On Thu, Oct 6, 2016 at 2:03 PM, Nick Sayer via time-nuts  wrote:

> To be fair, this is at least partly because asking a relatively simple
> question here routinely turns into a dissertation defense.
>
> > On Oct 6, 2016, at 3:45 AM, Bob Camp  wrote:
> >
> > Hi
> >
> > That’s very typical in a lot of forums. The OP tosses up a question and
> then pretty much vanishes.
> > My observation is that roughly 80% of the “I have a question” threads
> work that way.
> > I’ve never been able to figure out if it is an expectation that all
> answers will arrive in an hour or two
> > or if the OP is simply reading along and sees no reason to providing
> more information to the group.
> > Either way, I’m pretty sure that the focus of the answers is not all
> that great a week after the last input.
> >
> > 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.
>



-- 
Intelligence has never been proof against stupidity.
___
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] Need Time Help

[Wes]

On 10/5/2016 7:40 PM, Chris Albertson wrote:

There was a time when HAMs where the ones pushing radio technology
forward.  Maybe these guys are doing that and building a digital EME
network on VHF?  We don't know.
Actually, we do know.  Regarding my earlier comments, I believe at the time 
(mid-1970) those of us pursuing EME _were_ pushing the technology forward.

We can guess but typically when you start wanting precise time
synchronization it is because of something like TDMA (time division
multiple access) to a shared resource.
Not so.  What is now common is the use of "JT" modes.  JT modes have a number of 
variations but what they have in common is they were developed by Nobel Prize 
winner, Dr. Joe Taylor, who has freely given the software to the ham radio 
community.  See: http://physics.princeton.edu/pulsar/K1JT/JT65.pdf


Although I personally ceased pursuing this activity many years ago, there remain 
some of us, who are not Luddites, but still believe that "Deep Search Decoding" 
is a questionable practice, no matter how it is rationalized.


Nevertheless, the referenced paper should explain the need for precise 
timekeeping.

On Wed, Oct 5, 2016 at 9:47 AM, Wes  wrote:


If you are working "real" EME where you, and not a computer plus lookup
table, are coping the signals, none of these precise timing issues exist.

Wes  N7WS



___
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] Need Time Help

[Nick Sayer via time-nuts]

To be fair, this is at least partly because asking a relatively simple question 
here routinely turns into a dissertation defense.

> On Oct 6, 2016, at 3:45 AM, Bob Camp  wrote:
> 
> Hi
> 
> That’s very typical in a lot of forums. The OP tosses up a question and then 
> pretty much vanishes. 
> My observation is that roughly 80% of the “I have a question” threads work 
> that way. 
> I’ve never been able to figure out if it is an expectation that all answers 
> will arrive in an hour or two 
> or if the OP is simply reading along and sees no reason to providing more 
> information to the group.
> Either way, I’m pretty sure that the focus of the answers is not all that 
> great a week after the last input.  
> 
> 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] Measure GPSDO stability with minimum resources?

[Bob Stewart]

Hi Tim,
Thanks for the document.  I have been doing some 12 hour holdover tests.  But 
as I mentioned, the HP quick projections had fooled me into thinking there was 
some trick to this other than actually capturing the DAC over multiple days to 
get a real projection.
Bob
 -
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

  From: Tim Shoppa 
 To: Bob Stewart ; Discussion of precise time and frequency 
measurement  
 Sent: Thursday, October 6, 2016 12:37 PM
 Subject: Re: [time-nuts] Measure GPSDO stability with minimum resources?
   
The HP Smartclock app note will help you a lot:
http://leapsecond.com/hpan/an1279.pdf

There are lots of Z3801A EFC curves on the web for you to see what typical 
range of unit-to-unit variation is.
Of course to actually test holdover, you do that by opening the PLL loop 
(unhook GPS antenna) and letting the EFC extrapolation in your software run for 
a day (or whatever), watching the phase difference. Then you have to test that 
the system recovers back into phase lock smoothly after getting hooked back up.
Tim N3QE 
On Wed, Oct 5, 2016 at 1:37 PM, Bob Stewart  wrote:

For my GPSDO, I need to calculate the OCXO aging for holdover projection 
purposes as well as get some figure of merit for the recent past of the OCXO 
stability.  The latter is so that I can determine that the PLL has (or soon 
will have) a good lock.  I'm developing on a dfPIC33FJ128MC802, and I've used 
about 70% of the code space,  I could probably set aside 4K bytes of data space 
for this calculation. 

I have a rather primitive way of doing part of this, but I was hoping someone 
would steer me to something a bit better.

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.




   
___
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] Measure GPSDO stability with minimum resources?

[Bob Stewart]

said: "The somewhat amazing holdover estimates on the HP units are one example 
of this problem. It does not take much testing to quickly realize that they are 
far more often wrong than right on a unit that has been on power for less than 
a few weeks."
Thank you Bob.  These two sentences clear it all up.  Silly me thinking that 
the HP units could actually project aging from minimum data.  I can sample 
every hour and always have the past 24 hours to look at.  In fact, it might 
even be better to have multiple days in the queue and take a simple average for 
projection.  Naivety has been my biggest foe in this project.

Bob
 -
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

  From: Bob Camp 
 To: Discussion of precise time and frequency measurement  
 Sent: Thursday, October 6, 2016 12:24 PM
 Subject: Re: [time-nuts] Measure GPSDO stability with minimum resources?
   
Hi

As normally used, the term “aging” means the long term drift in the frequency 
of an OCXO. 
It is independent of the temperature effects and things like retrace, warmup, 
and voltage
stability. It is rare that there is any impact on the aging of a properly 
designed OCXO from 
drift of the oven temperature. 

Any time you try to estimate (or measure) aging on an OCXO, you will have a 
hard time
separating it from the other things that affect the frequency of the 
oscillator. The somewhat
amazing holdover estimates on the HP units are one example of this problem. It 
does not
take much testing to quickly realize that they are far more often wrong than 
right on a unit
that has been on power for less than a few weeks.

Bob

> On Oct 6, 2016, at 1:11 PM, Chris Albertson  wrote:
> 
> Wouldn't "aging" be the change in the temperature v. frequncy graph over
> time?      It is hard to hold temperture constant so maybe record the
> function at several different times.
> 
> This is one big advantage of using a microprocessor inside the GPSDO, It
> can log internal data to either a SD card or use a USB link to a PC to be
> recored in log files.  Even my "simple as possible" GPSDO push data to a
> PC over USB.  It is easy to glue a temperature sensor to "whatever" and
> log it
> 
> On Wed, Oct 5, 2016 at 10:14 PM, Hal Murray  wrote:
> 
>> 
>> j99har...@gmail.com said:
>>> Unless the oscillator is still warming up, 5 minutes or even 60 is way
>> too
>>> short a time to look at aging. For aging, you will want to look at the
>>> change in DAC values over several days at least.
>> 
>> I think it's worse than that.  You have to hold the temperature constant,
>> and
>> maybe even the power supply voltage.  A probe on the crystal can might
>> allow
>> you to correct for temperature.
>> 
>> 
>> 
>> 
>> --
>> 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.
>> 
> 
> 
> 
> -- 
> 
> 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.


   
___
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] Measure GPSDO stability with minimum resources?

[Tim Shoppa]

The HP Smartclock app note will help you a lot:

http://leapsecond.com/hpan/an1279.pdf

There are lots of Z3801A EFC curves on the web for you to see what typical
range of unit-to-unit variation is.

Of course to actually test holdover, you do that by opening the PLL loop
(unhook GPS antenna) and letting the EFC extrapolation in your software run
for a day (or whatever), watching the phase difference. Then you have to
test that the system recovers back into phase lock smoothly after getting
hooked back up.

Tim N3QE

On Wed, Oct 5, 2016 at 1:37 PM, Bob Stewart  wrote:

> For my GPSDO, I need to calculate the OCXO aging for holdover projection
> purposes as well as get some figure of merit for the recent past of the
> OCXO stability.  The latter is so that I can determine that the PLL has (or
> soon will have) a good lock.  I'm developing on a dfPIC33FJ128MC802, and
> I've used about 70% of the code space,  I could probably set aside 4K bytes
> of data space for this calculation.
>
> I have a rather primitive way of doing part of this, but I was hoping
> someone would steer me to something a bit better.
>
> 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.
>
___
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] Measure GPSDO stability with minimum resources?

[Bob Camp]

Hi

As normally used, the term “aging” means the long term drift in the frequency 
of an OCXO. 
It is independent of the temperature effects and things like retrace, warmup, 
and voltage
stability. It is rare that there is any impact on the aging of a properly 
designed OCXO from 
drift of the oven temperature. 

Any time you try to estimate (or measure) aging on an OCXO, you will have a 
hard time
separating it from the other things that affect the frequency of the 
oscillator. The somewhat
amazing holdover estimates on the HP units are one example of this problem. It 
does not
take much testing to quickly realize that they are far more often wrong than 
right on a unit
that has been on power for less than a few weeks.

Bob

> On Oct 6, 2016, at 1:11 PM, Chris Albertson  wrote:
> 
> Wouldn't "aging" be the change in the temperature v. frequncy graph over
> time?  It is hard to hold temperture constant so maybe record the
> function at several different times.
> 
> This is one big advantage of using a microprocessor inside the GPSDO, It
> can log internal data to either a SD card or use a USB link to a PC to be
> recored in log files.   Even my "simple as possible" GPSDO push data to a
> PC over USB.   It is easy to glue a temperature sensor to "whatever" and
> log it
> 
> On Wed, Oct 5, 2016 at 10:14 PM, Hal Murray  wrote:
> 
>> 
>> j99har...@gmail.com said:
>>> Unless the oscillator is still warming up, 5 minutes or even 60 is way
>> too
>>> short a time to look at aging. For aging, you will want to look at the
>>> change in DAC values over several days at least.
>> 
>> I think it's worse than that.  You have to hold the temperature constant,
>> and
>> maybe even the power supply voltage.  A probe on the crystal can might
>> allow
>> you to correct for temperature.
>> 
>> 
>> 
>> 
>> --
>> 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.
>> 
> 
> 
> 
> -- 
> 
> 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] ntp and asymmetric delays

[Bob Camp]

Hi


NTP can *not* detect “common mode” asymmetric delay. Having a local GPS does 
not count in this respect. What does count is an NTP client / server sitting in 
your
home trying to figure out what time it is only by hooking to the internet. To 
do this it must
do a few things:

1) Get a signal out through the (slow / long lag) upload channel on your modem.
2) Route that signal through the cable guy’s low capacity upstream network to 
one of his (at best) two 
or three gateways to your local empire.  These may or may not be in the same 
state you live in. 
3) Fly the signal over the backbone to whatever server is involved.
4) Fly a signal back over the backbone to possibly another set of gateways.
5) Route that signal through the cable guy’s high capacity downstream network.
6) Run it through the (quite fast / low lag) downstream channel on your modem. 

Steps 1,2,5 and 6 are common to every single server you try to access. If your 
modem has
an “upstream” lag of (say) 101 ms and a “downstream” lag of (say) 1 ms, every 
server you contact 
will have a round trip time of at least 102 ms. They *may* have more than this, 
but none will 
ever have less.

As the day progresses and various groups pop on and off the system in your 
state, the usage
of the upstream and downstream channels changes. It is not unreasonable to 
guess that both 
change as a percentage. If that guess is correct, your upstream varies by 
significantly more than 
your downstream. That will get into NTP’s loop correction stuff as well. 

You *might* ask, how about pings? Well, you *might* look into it and find that 
your 
local cable system recognizes pings at a very low level and preferentially 
routes them.
Yes, that’s hogwash and nobody would ever do it ….. except that’s the way it 
works 
here with my internet. The network can be completely dead and pings (along with 
other
ICMP traffic) will get through. Hmmm…..

You are indeed a guy with 5 watches to check against. The gotcha is that every 
single one
of them has been set fast or slow by the same amount. 

Bob

> On Oct 6, 2016, at 11:03 AM, Chris Albertson  
> wrote:
> 
> I still think NTP can detect asymmetric delays.  Only it can't know that is
> what it is detecting. What else generate those offset numbers?  Yes it
> could very well be that MRS is running slow but I doubt that is the case.
> And I really doubt your GPS' PPS is off  by even one microsecond.A good
> bet is that ALL the results we see is because the real-world communication
> path is different from the assumption NTP makes about communications paths.
> 
> In practice what NTP sees is all due to the Internet and not so much the
> reference clocks.   Your data shows this.  162.23.41.10  .MRS has different
> stat depending on who is looking at it. So those billboards are showing
> network stats not server stats. (but NTP can't know that for certain so it
> is obliged to call them server stats)
> 
> This is 2016.  Almost any reference clock you are likely to use will be
> pretty much dead-on, at least to within the precision that NTP works with.
> So anything those billboards say is really about the communications paths.
> But NTP has no theoretical right to assume the cause of what it sees.
> Theory and practice differs,   In theory NTP can not detect asymmetric
> delay but in practice that is about all it detects  Maybe I should say NTP
> detects asymmetric delay just like the speedometer in my car deters engine
> failure.
> 
> All that said, if the OP is still reading this it should be very good news
> for him because your data shows that NTP can give him his required accuracy
> even without a GPS if he has an Internet connection as good as yours
> 
> In fact what you are showing is that NTP using the Internet can beat GPS
> over USB to Winows. and can certainly beat any software the "jam sets" the
> clock.   All you need is your Internet connection, no aded hardware.
> 
> 
> 
> On Wed, Oct 5, 2016 at 5:14 AM, Magnus Danielson > wrote:
> 
>> 
>> 
>> On 10/05/2016 01:48 PM, Attila Kinali wrote:
>> 
>>> On Tue, 4 Oct 2016 18:05:16 -0700
>>> Chris Albertson  wrote:
>>> 
>>> The problem, I think with your Internet sync's NTP servers is you are only
 using one server S.  The most common practice is to use 3 to 5 with 5
 being
 about the right number.   If you get Ntp enough Internet servers to work
 with it can detect problem like asymmetric path lengths which I'm sure is
 you problem.
 
>>> 
>>> No they are correctly configured with 3 and 5 servers respectively.
>>> I singled out server S out, because i didn't want to clutter the argument
>>> with too many numbers and because S is common to both machines A and B
>>> and because it's very close in internet terms (with 4.5ms and 2ms
>>> respectively).
>>> 
>>> The full view of A is (the last line is B):
>>> 
>>> remote   refid  st t when 

Re: [time-nuts] Measure GPSDO stability with minimum resources?

[Chris Albertson]

Wouldn't "aging" be the change in the temperature v. frequncy graph over
time?  It is hard to hold temperture constant so maybe record the
function at several different times.

This is one big advantage of using a microprocessor inside the GPSDO, It
can log internal data to either a SD card or use a USB link to a PC to be
recored in log files.   Even my "simple as possible" GPSDO push data to a
PC over USB.   It is easy to glue a temperature sensor to "whatever" and
log it

On Wed, Oct 5, 2016 at 10:14 PM, Hal Murray  wrote:

>
> j99har...@gmail.com said:
> > Unless the oscillator is still warming up, 5 minutes or even 60 is way
> too
> > short a time to look at aging. For aging, you will want to look at the
> > change in DAC values over several days at least.
>
> I think it's worse than that.  You have to hold the temperature constant,
> and
> maybe even the power supply voltage.  A probe on the crystal can might
> allow
> you to correct for temperature.
>
>
>
>
> --
> 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.
>



-- 

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] ntp and asymmetric delays

[Chris Albertson]

I still think NTP can detect asymmetric delays.  Only it can't know that is
what it is detecting. What else generate those offset numbers?  Yes it
could very well be that MRS is running slow but I doubt that is the case.
And I really doubt your GPS' PPS is off  by even one microsecond.A good
bet is that ALL the results we see is because the real-world communication
path is different from the assumption NTP makes about communications paths.

In practice what NTP sees is all due to the Internet and not so much the
reference clocks.   Your data shows this.  162.23.41.10  .MRS has different
stat depending on who is looking at it. So those billboards are showing
network stats not server stats. (but NTP can't know that for certain so it
is obliged to call them server stats)

This is 2016.  Almost any reference clock you are likely to use will be
pretty much dead-on, at least to within the precision that NTP works with.
So anything those billboards say is really about the communications paths.
But NTP has no theoretical right to assume the cause of what it sees.
Theory and practice differs,   In theory NTP can not detect asymmetric
delay but in practice that is about all it detects  Maybe I should say NTP
detects asymmetric delay just like the speedometer in my car deters engine
failure.

All that said, if the OP is still reading this it should be very good news
for him because your data shows that NTP can give him his required accuracy
even without a GPS if he has an Internet connection as good as yours

In fact what you are showing is that NTP using the Internet can beat GPS
over USB to Winows. and can certainly beat any software the "jam sets" the
clock.   All you need is your Internet connection, no aded hardware.



On Wed, Oct 5, 2016 at 5:14 AM, Magnus Danielson  wrote:

>
>
> On 10/05/2016 01:48 PM, Attila Kinali wrote:
>
>> On Tue, 4 Oct 2016 18:05:16 -0700
>> Chris Albertson  wrote:
>>
>> The problem, I think with your Internet sync's NTP servers is you are only
>>> using one server S.  The most common practice is to use 3 to 5 with 5
>>> being
>>> about the right number.   If you get Ntp enough Internet servers to work
>>> with it can detect problem like asymmetric path lengths which I'm sure is
>>> you problem.
>>>
>>
>> No they are correctly configured with 3 and 5 servers respectively.
>> I singled out server S out, because i didn't want to clutter the argument
>> with too many numbers and because S is common to both machines A and B
>> and because it's very close in internet terms (with 4.5ms and 2ms
>> respectively).
>>
>> The full view of A is (the last line is B):
>>
>>  remote   refid  st t when poll reach   delay   offset
>> jitter
>> 
>> ==
>> +162.23.41.55.MRS.1 u  357 1024  3774.5550.198
>>  0.293
>> *162.23.41.10.MRS.1 u  318 1024  3774.403   -0.040
>>  0.123
>> -131.188.3.223   .PZF.1 u  548 1024  3779.524   -0.654
>>  0.039
>> +2001:67c:8:abcd .GPS1.   1 u   74 1024  373   12.1630.143
>>  0.168
>> -81.94.123.1785.158.25.74 2 u  297 1024  3770.985   -0.798
>>  0.158
>> -2a02:418:f022:: 162.23.41.10 2 u  792 1024  3770.649   -0.727
>>  2.120
>>
>> And the full view of B is:
>>  remote   refid  st t when poll reach   delay   offset
>> jitter
>> 
>> ==
>> *162.23.41.10.MRS.1 u  175 1024  3772.067   -0.033
>>  0.069
>> +195.186.1.101   195.186.150.242  2 u  504 1024  3771.317   -0.360
>>  0.086
>> +130.60.204.10   130.60.159.7 4 u  901 1024  3771.5390.932
>>  2.065
>>
>>
>> Note: 162.23.41.10 (the server S) is one of the three NTP servers run by
>> METAS
>> and fed by the official PPS of Switzerland.
>>
>>
>> And no, NTP cannot detect asymmetric network delays. They are completely
>> indisdinguishable from clock offsets. One can easily show that the
>> uncertainty in the network delay symmetry is the fundamental accuracy
>> limit of NTP. As the asymmetry is in general unbounded, the only guarantee
>> you have is that you are at most off by the RTT (aka delay) of the
>> reference.
>> (given the reference itself is accurate)
>>
>
> It is trivial to show that any two-way time-transfer mechanism, be it NTP,
> PTP, TWTFST, DTM TT or whatever, cannot unaided separate Time Error between
> two clocks from that of the asymmetry between them. The Round Trip Time
> (RTT) is however guaranteed unbiased under the assumption of no (major)
> frequency difference. PTP adds means by which intermediate nodes can
> provide delay estimations and thus allow cancellation of delay in those
> equipments, but it does not help for asymmetry in path, such as different
> fiber-lengths. Such delays needs to be calibrated.
>
> With lots of observations 

Re: [time-nuts] Need Time Help

[Bob Camp]

Hi

That’s very typical in a lot of forums. The OP tosses up a question and then 
pretty much vanishes. 
My observation is that roughly 80% of the “I have a question” threads work that 
way. 
I’ve never been able to figure out if it is an expectation that all answers 
will arrive in an hour or two 
or if the OP is simply reading along and sees no reason to providing more 
information to the group.
Either way, I’m pretty sure that the focus of the answers is not all that great 
a week after the last input.  

Bob


> On Oct 6, 2016, at 3:33 AM, Mike Cook  wrote:
> 
> Given the number of replies to the OP, most pointed but others drifting OT, 
> it is remarkable that there has been no comment or feedback from Larry. He 
> has slung his bottle and gone away it seems.  
> 
> 
>> Le 5 oct. 2016 à 23:58, Bob Camp  a écrit :
>> 
>> Hi
>> 
>> Given that this is for intermittent EME use, it’s not a system that has uber
>> reliability as a requirement. Once you get the antenna up in a reasonable 
>> location
>> a GPS is going to be pretty stable and reliable. If you have an EME array 
>> running, adding a GPS antenna to it probably not a big deal. 
>> 
>> If it *is* a big deal, run a GPSDO and then it’s no longer a problem. The KS
>> boxes still seem to be out there for < $100 ….
>> 
>> Bob
>> 
>>> On Oct 5, 2016, at 2:32 PM, Gary E. Miller  wrote:
>>> 
>>> Yo Bob!
>>> 
>>> On Wed, 5 Oct 2016 07:14:30 -0400
>>> Bob Camp  wrote:
>>> 
 If you buy a GPS receiver and get it set up for timing …. just use
 it. Then there is no need for NTP at all….
>>> 
>>> Assuming your GPS never farts and always has a good lock.  A pretty
>>> good assumption, but not a perfect one.
>>> 
>>> RGDS
>>> GARY
>>> ---
>>> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
>>> g...@rellim.com  Tel:+1 541 382 8588
>>> ___
>>> 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.
> 
> "The power of accurate observation is commonly called cynicism by those who 
> have not got it. »
> George Bernard Shaw
> 
> ___
> 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] Need Time Help

[Mike Cook]

Given the number of replies to the OP, most pointed but others drifting OT, it 
is remarkable that there has been no comment or feedback from Larry. He has 
slung his bottle and gone away it seems.  


> Le 5 oct. 2016 à 23:58, Bob Camp  a écrit :
> 
> Hi
> 
> Given that this is for intermittent EME use, it’s not a system that has uber
> reliability as a requirement. Once you get the antenna up in a reasonable 
> location
> a GPS is going to be pretty stable and reliable. If you have an EME array 
> running, adding a GPS antenna to it probably not a big deal. 
> 
> If it *is* a big deal, run a GPSDO and then it’s no longer a problem. The KS
> boxes still seem to be out there for < $100 ….
> 
> Bob
> 
>> On Oct 5, 2016, at 2:32 PM, Gary E. Miller  wrote:
>> 
>> Yo Bob!
>> 
>> On Wed, 5 Oct 2016 07:14:30 -0400
>> Bob Camp  wrote:
>> 
>>> If you buy a GPS receiver and get it set up for timing …. just use
>>> it. Then there is no need for NTP at all….
>> 
>> Assuming your GPS never farts and always has a good lock.  A pretty
>> good assumption, but not a perfect one.
>> 
>> RGDS
>> GARY
>> ---
>> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
>>  g...@rellim.com  Tel:+1 541 382 8588
>> ___
>> 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.

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

___
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] ADC sample voting algorithm?

[Angus]

Hi,

You may have already done this, but if you log the same pulses with a
counter or actual TDC IC you can view it and see how they compare with
your measurements. 
Then you can look at how to get them closer - or find that it's
actually correct and that's just where the pulse is at the time.

Angus.



On Wed, 5 Oct 2016 16:45:21 -0700, you wrote:

>This is tangentially on topic, I suppose. It’s for my GPSDO.
>
>I notice periodically that the phase measurements seem “noisy.” You can see 
>that over the course of several seconds the value doesn’t change, then it 
>jumps a bunch and then comes right back.
>
>My theory at the moment is that sampling the ADC multiple times in a row might 
>help, but then what’s the best way to (quickly) pick which sample to use?
>
>The mean would allow a bad sample undue influence.
>
>At the moment, I’ve coded taking 3 samples, averaging them and picking the 
>sample that is closest to the mean. If I’m right, and two of the samples 
>happen to be very close to each other and a third is an outlier, then that 
>seems like it would eliminate it.
>
>I guess what I want is the mode, but with 3 samples, that’s going to be poorly 
>defined (if at all).
>
>Anyone have any suggestions (besides a larger sample size)?
>___
>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] ADC sample voting algorithm?

[Poul-Henning Kamp]

In message <59ab451c-ca1b-4824-a953-4f0f28b66...@kfu.com>, Nick Sayer via 
time-nuts writes:

>My theory at the moment is that sampling the ADC multiple times in a row might 
>help, but then what’s the best way to (quickly) pick which sample to use?

If you are sampling for noise:  Always the median.


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

Re: [time-nuts] Need Time Help

[Hal Murray]

albertson.ch...@gmail.com said:
> The problem is harder then most people think. To avoid jumps in time either
> forward or backwards the software must be something that runs continuously
> and monitors your clock vs. one or more reference clocks.   Logically there
> is no other way. 

I think it depends upon what you mean by "software" and "runs continuously".

The usual way to avoid jumps is for the kernel to do all the work.  You tell 
it how much to adjust.  It tweaks the seconds per tick slightly, waits until 
the adjustment has finished, then undoes the tweak.  With that API, you don't 
need any user software running continuously.


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