[time-nuts] Erroneous R390 Post

[Perry Sandeen via time-nuts]

Yo Bubba Dudes!,
My R390 Non A upgrade to the TN list was an error.
Thanks to all who replied for pointing it out to me.
This shows that late nite posting for me is not wise.
Regards,
Perrier


___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

[time-nuts] HP 330B distortion analyzer: free + shipping

[Eric Scace]

Hi all —

   I know some folks have amazing knowledge and collections of previous 
generations of HP test gear.

   In cleaning out my father's lab, I uncovered an HP-330B distortion analyzer 
. It’s 
available for free to an interested Time Nut.  Please either pick-up in Boston 
by Jun 03, or reimburse me for shipping.

   I am moving to Boulder CO. If this doesn’t find a taker by Jun 3, sadly it 
will go to the city recycler.

   Thanks.

— Eric K3NA
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] Network Time Puzzle

[Peter Martinez via time-nuts]

Steve:

Many thanks for that link to  your paper on NTP 
http://leapsecond.com/ntp/NTP_Paper_Sommars_PTTI2017.pdf


I read the entire paper, not just figs 7 and 8, and it explains everything. 
I was beginning to doubt my own sanity because several authorities that I 
had consulted told me quite categorically that The Network would have no 
business looking at source port addresses within packets, and would have no 
reason to treat packets from some port addresses differently from packets 
from other port addresses.   I had in particular consulted a named person at 
one organisation which operates ntp servers in Colorado and Maryland.  I had 
spotted this effect first on ALL their servers and had not, at that time, 
seen it on any others, so I had good reason to ask them whether there could 
be something at their end which might be responsible.  "No there isn't - our 
servers are OK" I was told, but nothing more.


I could still make a valid point which could be of concern to writers of ntp 
client software.  If a client used a fixed, constant, local port address, we 
can assume that routers in the internet (or at least those which do 
implement this load-spreading technique) would route all ntp traffic - from 
client to server and back - via the same path each time, so there would be 
no spread in offset times seen by the client.  There might, of course, be 
some asymetry in the paths.  By contrast, a client that used a different 
local port address for each query might see a different route each time and 
there would be a spread in offset times of the same order as the spread in 
propagation times of the routes in use.


For example, I have seen, when querying servers in Colorado and Maryland 
from here (the UK), standard deviations in the derived offset, of about 
100usec when I use a fixed local port address, and about 3 msec when I use a 
port address which either increments by 1 for each query or is chosen as a 
random number between 49152 and 65535 each time.  I am not sure of the 
statistics, but I am not sure that randomizing the local port address has 
any useful advantages.


Just for amusement I implemented a process whereby my client program starts 
with a randomized port address, but keeps a record of the port number of the 
query which gives the lowest round-trip-time during this "search" phase, 
then switches to this fixed port address thereafter.  The offset thus 
achieved was always "better" than with any other random choice of fixed port 
address.  Maybe this is going too far!


Steve: Thanks again.  VERY useful.
Peter 



___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] GPS 1PPS, phase lock vs frequency lock, design

[Leo Bodnar]

Apologies, teletype did not let the picture through
http://www.leobodnar.com/files/2x%20ECOC%203v6.png

> I had half a dozen of 38.88MHz ones for tinkering.
> There is nothing exciting about them apart from a noisy LDO which has peaking 
> around 70kHz.
> Spurs are mine.
> Leo

___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] Network Time Puzzle

[Steven Sommars]

See figures 7 & 8 in
http://leapsecond.com/ntp/NTP_Paper_Sommars_PTTI2017.pdf

When a router forwards an NTP packet multiple potential egress links may
have equal cost.  In order to distribute the traffic across the egress
links the router can use the IP addresses and UDP source/destination port
numbers to select a link.  Doing this reduces the likelihood of
out-of-sequence packets.

Instead of having N x 1 Gbps links between two adjacent routers it is
preferable to have a single N Gbps link.  The latter may not be available
or cost effective.

Similar behavior can be found at network layer 2 for link aggregation
groups, see https://en.wikipedia.org/wiki/Link_aggregation .

Steve Sommars


On Sun, May 26, 2019 at 7:16 AM Peter Martinez via time-nuts <
time-nuts@lists.febo.com> wrote:

> Greetings, Time Nuts, from a new member.
>
> I have two old Windows XP laptops on which I can lock the timing to GPS,
> which means I can read the time at which things happen to a few
> microseconds.  I thought I would modify some of my old NTP software, both
> client and server, to make use of this and see how well the ntp system
> performs.
>
> It's all working fine, but in the course of trying to decide what to set
> for
> the "local port address", I discovered a strange effect.  If I set the
> local
> port address of my ntp client to one value (somewhere between 49152 and
> 65535 for example), then query an ntp server on the internet, then change
> the local port to another value and do it again, the Time Offset and Round
> Trip Delay readings come back different. Change the port back and the
> offset/delay values go back to the original.  Same on the other PC.  But
> ONLY on some distant servers.  Most of them don't show the effect.
>
> I have seen jumps of about 6.2msec in delay and 3.1msec in offset, but the
> offset might be positive or negative.  This leads me to think that this
> wierd effect is a propagation delay occuring in one of the two paths,
> either
> the path from me to the server or from the server back to me.  On some
> servers I have seen the delay jump by 12.4msec with no jump in the offset.
> This must be a 6.2 msec. delay in BOTH propagation delays.  In this case,
> four different values of local port address can give rise to 4 different
> delay/offset combinations.  A scatter plot of delay versus offset, with
> random port address, shows four dots in a diamond shape.  Different delay
> values give different-sized diamonds.  Routes with more than one such
> effect
> show even prettier patterns of superimposed diamonds.  The effect is
> stable
> over time, at least for the length of time (weeks) I have been studying it.
>
> If this is real (and I am fairly sure it's not a bug at my end or at the
> servers), then it will impact on the accuracy which can be achieved with
> NTP.  I ask myself "Why does the network do this?".  Is there a valid
> reason
> for it, or is it a side-effect of something else?  Has anyone else seen
> this
> effect?  Is there anyone out there reading this who could modify an NTP
> client program so that the loal port address can be changed manually, and
> see if this is a widespread feature of the internet.  If this effect
> didn't
> occur, NTP could be a lot better than it is now.
>
> Regards
> Peter Martinez G3PLX
>
>
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] GPS 1PPS, phase lock vs frequency lock, design

[Attila Kinali]

On Sat, 25 May 2019 00:51:46 + (UTC)
life speed via time-nuts  wrote:

> I want to discipline a 10 MHz OCXO with 1PPS from GPS.  Obviously not an 
> unusual application, but I need to understand the methodology as I will not 
> be buying a module but rather implementing the design with an FPGA, off-the-
> shelf GPS chip and a high-quality 10MHz DOCXO.
>
> One of the first questions I have:  is it possible to implement phase-lock 
> with a narrow digital PLL and DSP integrator/filter in the FPGA?  I suspect 
> some 1PPS disiplined OCXO implementations are merely controlled to the same 
> frequency, but not necessarily the same phase, depending on the details of 
> the implementation.

As you state that you are familiar with PLL design, I guess your confusion
comes from having a 1Hz signal and trying to use that for a "normal" phase
detector. While this is possible and can be done, it leads imediatly to
the problems you have stumbled upon. The canonical way to do it, is instead
measuring the arrival time of the PPS relative to a clock derived from the
10MHz. Ie you timestamp the PPS. Then you take the timestamp modulo 1 second
and substract from it the setpoint value (can be 0 or anything else that
makes your math easier), which then gives you the error or your control
loop. Having the error value, you now can apply the digital PLL knowledge
you have and design the loop filter.

There are of course a few complications of the system:

1) You need to apply the saw-tooh correction to the measured PPS timestamp.
Otherwise you get a spread in the order of 10ns and, much worse, "hanging
bridges"

2) The systems sampling clock is 1Hz, which is unusual to most people
who are used kHz or even MHz sampling rate digital loops. But the advantage
is that it's so slow, that you can do all the calculations with minimal
dead time, compared to the sampling period. Just keep in mind that
everything has to have a sub-Hz bandwidth.

3) To achieve a decent frequency stability and low noise OCXO output,
the DAC you use to control it needs to have at the very least 16bit
(mostly DNL, but INL shouldn't change too much or too quickly, otherwise
the loop becomes unstable). For one of my design, I calculated that
I would need ~23bit for the stability I wanted, which poses a problem
by itself. Luckily, having the DAC in the control loop simplifies things
quite a bit. Using a 16bit DAC (eg AD5560 or AD5683R, the latter would
be better suited for this application due to the LDAC pin) and using
a delta-sigma modulator (at least 2nd order, better 4-8th order) 
should give you enough resolution to work with.

Alternatively, a 1bit DAC using a high order delta-sigma modulator
and an external D-FF (don't use one in the FPGA as the jitter from
the FPGA would kill the resolution) would also work. Audio DACs
don't work for this application as they have too much low-frequency
noise (aka drift).

4) The filter after the DAC will require some good opamps. Even though
using chopper/autozero opamps is tempting, I'd rather go for low flicker
noise bipolar opamps (eg LT6018 or LTC6081, LT6010,...) as the loop will
compensate for the drift of the opamp (given it's not too big). 

5) The easiest way to timestamp PPS if you already have a FPGA is
using a ring oscillator based TDC. There is code out there that
works for Xilinx[1]. I have a port to Altera/Intel Cyclone4 lying
around if you are interested. This will give you a resolution in the
order of 100-200ps, which should be good enough for a GPSDO.
The second way would be to implement a time-to-amplitude converter
(the simplest, I am aware of, is the one in Nick Sayer's GPSDO[2]),
but that is already quite a bit more effort in the analog domain
than what a ring oscillator TDC would require.

> I need the output of two of these units I design to have to be phase
> coherent relative to each other.  Your knowledge, experience and scholarly
> references are welcome.

There is not much out there on refernces that I could send you. Most
of what I know I gathered from looking at other peoples GPSDOs and
reading what they have done. An outdated summary of that can be found
at [3]. Additional to this you will need good knowledge of digital PLL
design, for which I recommend having a look at the standard books
(e.g. Gardner[4] and Best[5]).

How well you can get the GPSDOs synchronized depends a bit on the effort
you spend on the receiver. Standard L1 receivers (of the same model
with the same firmware) will be better than 10ns if they are not too
far apart (a few 10km to maybe 100km). If you need better than 1ns, you
will need an L1/L2 receiver and have to manually calibrate the offset
of the receiver.

HTH

Attila Kinali


[1] https://ohwr.org/project/tdc-core/wikis/home
[2] https://hackaday.io/project/6872-gps-disciplined-xcxo
[3] https://attila.kinali.ch/blog/2016/02/07/gps-disciplined-oscillator
[4] "Phaselock Techniques", 3rd edition, 2015 by Floyd Gardner
[5] "Phase-locked 

[time-nuts] Network Time Puzzle

[Peter Martinez via time-nuts]

Greetings, Time Nuts, from a new member.

I have two old Windows XP laptops on which I can lock the timing to GPS, 
which means I can read the time at which things happen to a few 
microseconds.  I thought I would modify some of my old NTP software, both 
client and server, to make use of this and see how well the ntp system 
performs.


It's all working fine, but in the course of trying to decide what to set for 
the "local port address", I discovered a strange effect.  If I set the local 
port address of my ntp client to one value (somewhere between 49152 and 
65535 for example), then query an ntp server on the internet, then change 
the local port to another value and do it again, the Time Offset and Round 
Trip Delay readings come back different. Change the port back and the 
offset/delay values go back to the original.  Same on the other PC.  But 
ONLY on some distant servers.  Most of them don't show the effect.


I have seen jumps of about 6.2msec in delay and 3.1msec in offset, but the 
offset might be positive or negative.  This leads me to think that this 
wierd effect is a propagation delay occuring in one of the two paths, either 
the path from me to the server or from the server back to me.  On some 
servers I have seen the delay jump by 12.4msec with no jump in the offset. 
This must be a 6.2 msec. delay in BOTH propagation delays.  In this case, 
four different values of local port address can give rise to 4 different 
delay/offset combinations.  A scatter plot of delay versus offset, with 
random port address, shows four dots in a diamond shape.  Different delay 
values give different-sized diamonds.  Routes with more than one such effect 
show even prettier patterns of superimposed diamonds.  The effect is stable 
over time, at least for the length of time (weeks) I have been studying it.


If this is real (and I am fairly sure it's not a bug at my end or at the 
servers), then it will impact on the accuracy which can be achieved with 
NTP.  I ask myself "Why does the network do this?".  Is there a valid reason 
for it, or is it a side-effect of something else?  Has anyone else seen this 
effect?  Is there anyone out there reading this who could modify an NTP 
client program so that the loal port address can be changed manually, and 
see if this is a widespread feature of the internet.  If this effect didn't 
occur, NTP could be a lot better than it is now.


Regards
Peter Martinez G3PLX


___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

[time-nuts] R390 Non A Upgrade Info Wanted

[Perry Sandeen via time-nuts]

Yo Bubba Dudes!,
Uh being of unsound mind since I'm planning on moving 2,200 miles in the coming 
future..
Honest honey, this R 390 was just sitting there on ebay at such a low price, it 
uh just sorta, somehow err, followed me home.
So now that I have my 2nd one (and the first one is still untouched after 5 
years)
---Yes, please doctor adjust my meds---
Oh yes, where was I?  Ms. Pelosi? 

Ah yes! Now I remember.
I am in the process of digitizing the OEM R 390  2 part ski from Andy Morrer's 
site.  This will be a long time coming.  What I wanted to do is incorporate in 
the ski's is information of parts that are problematic.  Under-wattage 
resistors, leaky caps, parts to add or improve or any information of that 
nature. Or tips or tricks that I can add as annotations.  I will add an 
attribution list for those who contribute even if they are SK.  When done I'll 
make the BIT TIFF image available on several sites or from me.
For those who might not be familiar with the BIT type of image it is only black 
or white no matter what print size is chosen - no smearing.  So one can go to 
Kinko's and for $10 get a 24" X 48" print to put on the wall if needed.

So please send me any information you have whenever using an original email and 
I'll add it to a word file and eventually incorporate it into the final 
schematics

Regards,
Perrier



  





 
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.