really slow PLL...

[Lasse Langwadt Christensen]

torsdag den 21. juli 2022 kl. 01.21.08 UTC+2 skrev John Larkin:

Suppose I have several rackmount boxes and each has a BNC connector on
the back. Each of them has an open-drain mosfet, a weak pullup, and a
lowpass filtered schmitt gate back into our FPGA.

I can daisy-chain several boxes with BNC cables and tees.

Each box has a 40 MHz VCXO and I want to phase-lock them, or at least
time-align them to always be the same within a few microseconds,
longterm.

I could call one the leader (not \"master\") and make the others
followers (not \"slaves\") and have the leader make an active low pulse
maybe once a second.

why so slow?

A follower would use her (not \"his\") clock to
measure the incoming period and tweak its local VCXO in the right
direction. That should work.

it\'ll only make the run at at the same speed, not time aligned

 

[bitrex]

On 7/21/2022 1:21 PM, Martin Brown wrote:

On 21/07/2022 16:31, John Walliker wrote:
On Thursday, 21 July 2022 at 15:42:40 UTC+1, bitrex wrote:
On 7/21/2022 10:21 AM, Lasse Langwadt Christensen wrote:
torsdag den 21. juli 2022 kl. 16.04.42 UTC+2 skrev bitrex:
On 7/21/2022 7:06 AM, Martin Brown wrote:
On 21/07/2022 01:22, John Larkin wrote:
On Wed, 20 Jul 2022 19:32:20 -0400, Phil Hobbs
pcdhSpamM...@electrooptical.net> wrote:

John Larkin wrote:


Suppose I have several rackmount boxes and each has a BNC
connector on
the back. Each of them has an open-drain mosfet, a weak pullup,
and a
lowpass filtered schmitt gate back into our FPGA.

I can daisy-chain several boxes with BNC cables and tees.

Each box has a 40 MHz VCXO and I want to phase-lock them, or at
least
time-align them to always be the same within a few microseconds,
longterm.

I could call one the leader (not \"master\") and make the others
followers (not \"slaves\") and have the leader make an active low
pulse
maybe once a second. A follower would use her (not \"his\") clock to
measure the incoming period and tweak its local VCXO in the right
direction. That should work.

Don\'t GPS receivers lock their 10 MHz oscillators to a 1 PPS pulse
from the satellites?

My system should work from a 1 PPS GPS pulse too, all boxes as
followers.

The PLL algorithm might be interesting.


It\'s certainly possible. However, within whatever tiny loop
bandwidth
you wound up with, the lockers would still have

20 log(40e6) = 152 dB

higher phase noise than the lockee.

GPS has that problem too.


It would be interesting to do the math to see whether it\'s
possible to
generate a concensus lock for the group: if you get everybody close
enough, just sum their sine wave outputs and lock each one of
them to
that, with some bit of AC coupling or something so that they
don\'t all
wander together off to the edge of the tuning range.

Maybe have one doing the locking with a phase shifter and the
others
with VCOs, or something like that.

Definitely a partly-baked idea, but surely one could do better than
152 dB!

Cheers

Phil Hobbs

Each box is basically a multichannel power supply, but channels
can be
programmed to do stuff in timed sequences. I want different box
outputs to time align within, say, one millisecond longterm once
programs are kicked off together. So, many microseconds of
equivalent
RMS phase noise is OK as long as we stay time aligned longterm.

You really need to define longterm before the problem becomes well
posed. Do you mean hours, days, weeks or months of runtime?

Yeah I don\'t quite get it, either. My rack of synthesizers can each
play
one voice of the Maple Leaf Rag via MIDI and they all stay synced
together really well, at least over a timespan of several
minutes.

but they are anot free runnign are they? they are all reacting to midi

There\'s a system clock in each one surely but they don\'t try to sync
their system clocks, they receive an instruction \"do X for Y ms\" and
their processor figures out how long Y ms is, and does it for that long.

It is literally good enough for rock & roll, but whether it\'s good
enough for power supply sequencing IDK, there is gonna be some latency.

HP used to have GPIB on their power supplies, I\'ve never used it but I
expect it wasn\'t really useful for tight synchronization.

The Group Execute Trigger command does allow quite tight synchronisation
between different GPIB devices.

GPIB flat out on a good day could manage 1Mbyte/s but in real world
situations with interconnect cabling you would be lucky to get 500kb/s.
It\'s best feature was that it ran at the maximum speed the receiving
device could handle (assuming that the controller was fast enough).

Synchronisation to a GET command would be probably be better than 1us
but would depend on the decoding time in each individual box. Some GPIB
devices were rather pedestrian at accepting commands.

IEEE488 was good in its day but a bit long in the tooth now. Still on
some test equipment in service today and was provided as standard on NEC
9801 PC\'s in Japan although hardly ever used by their customers.

The cables and connectors could only be described as a bit clunky!
They really didn\'t get on with metal swarf being around but were OK in
clean dry electronics/physics labs - much less so in chemistry ones...

I feel like there wasn\'t really a good relatively inexpensive standard
for interfacing PC peripherals until USB. Serial and parallel were slow
(occasionally some devices supported ECP, I remember having to enable it
in the BIOS sometimes), and external SCSI wasn\'t really well-suited to
anything but external disk drives.

I don\'t think you could hot-swap IEE-488 either but it seems like it was
pretty fast and more amenable to a wide class of devices than SCSI, but
just didn\'t seem to catch on outside the test equipment realm.

 

[bitrex]

On 7/21/2022 1:41 PM, bitrex wrote:

On 7/21/2022 1:21 PM, Martin Brown wrote:
On 21/07/2022 16:31, John Walliker wrote:
On Thursday, 21 July 2022 at 15:42:40 UTC+1, bitrex wrote:
On 7/21/2022 10:21 AM, Lasse Langwadt Christensen wrote:
torsdag den 21. juli 2022 kl. 16.04.42 UTC+2 skrev bitrex:
On 7/21/2022 7:06 AM, Martin Brown wrote:
On 21/07/2022 01:22, John Larkin wrote:
On Wed, 20 Jul 2022 19:32:20 -0400, Phil Hobbs
pcdhSpamM...@electrooptical.net> wrote:

John Larkin wrote:


Suppose I have several rackmount boxes and each has a BNC
connector on
the back. Each of them has an open-drain mosfet, a weak
pullup, and a
lowpass filtered schmitt gate back into our FPGA.

I can daisy-chain several boxes with BNC cables and tees.

Each box has a 40 MHz VCXO and I want to phase-lock them, or
at least
time-align them to always be the same within a few microseconds,
longterm.

I could call one the leader (not \"master\") and make the others
followers (not \"slaves\") and have the leader make an active
low pulse
maybe once a second. A follower would use her (not \"his\")
clock to
measure the incoming period and tweak its local VCXO in the right
direction. That should work.

Don\'t GPS receivers lock their 10 MHz oscillators to a 1 PPS
pulse
from the satellites?

My system should work from a 1 PPS GPS pulse too, all boxes as
followers.

The PLL algorithm might be interesting.


It\'s certainly possible. However, within whatever tiny loop
bandwidth
you wound up with, the lockers would still have

20 log(40e6) = 152 dB

higher phase noise than the lockee.

GPS has that problem too.


It would be interesting to do the math to see whether it\'s
possible to
generate a concensus lock for the group: if you get everybody
close
enough, just sum their sine wave outputs and lock each one of
them to
that, with some bit of AC coupling or something so that they
don\'t all
wander together off to the edge of the tuning range.

Maybe have one doing the locking with a phase shifter and the
others
with VCOs, or something like that.

Definitely a partly-baked idea, but surely one could do better
than
152 dB!

Cheers

Phil Hobbs

Each box is basically a multichannel power supply, but channels
can be
programmed to do stuff in timed sequences. I want different box
outputs to time align within, say, one millisecond longterm once
programs are kicked off together. So, many microseconds of
equivalent
RMS phase noise is OK as long as we stay time aligned longterm.

You really need to define longterm before the problem becomes well
posed. Do you mean hours, days, weeks or months of runtime?

Yeah I don\'t quite get it, either. My rack of synthesizers can
each play
one voice of the Maple Leaf Rag via MIDI and they all stay synced
together really well, at least over a timespan of several
minutes.

but they are anot free runnign are they? they are all reacting to midi

There\'s a system clock in each one surely but they don\'t try to sync
their system clocks, they receive an instruction \"do X for Y ms\" and
their processor figures out how long Y ms is, and does it for that
long.

It is literally good enough for rock & roll, but whether it\'s good
enough for power supply sequencing IDK, there is gonna be some latency.

HP used to have GPIB on their power supplies, I\'ve never used it but I
expect it wasn\'t really useful for tight synchronization.

The Group Execute Trigger command does allow quite tight synchronisation
between different GPIB devices.

GPIB flat out on a good day could manage 1Mbyte/s but in real world
situations with interconnect cabling you would be lucky to get
500kb/s. It\'s best feature was that it ran at the maximum speed the
receiving device could handle (assuming that the controller was fast
enough).

Synchronisation to a GET command would be probably be better than 1us
but would depend on the decoding time in each individual box. Some
GPIB devices were rather pedestrian at accepting commands.

IEEE488 was good in its day but a bit long in the tooth now. Still on
some test equipment in service today and was provided as standard on
NEC 9801 PC\'s in Japan although hardly ever used by their customers.

The cables and connectors could only be described as a bit clunky!
They really didn\'t get on with metal swarf being around but were OK in
clean dry electronics/physics labs - much less so in chemistry ones...


I feel like there wasn\'t really a good relatively inexpensive standard
for interfacing PC peripherals until USB.

Oops I forgot about AppleTalk. I remember helping some students get
their Mac SEs on the Internet (email and FTP and maybe some basic web
browsing I can\'t recall) via some kind of Ethernet to AppleTalk adapter,
it wasn\'t uncommon in the mid 90s for college students to be using
hand-me-down Macs from the 80s, but I couldn\'t for the life of me now
remember how I did it.

 

[Lasse Langwadt Christensen]

torsdag den 21. juli 2022 kl. 19.45.26 UTC+2 skrev bitrex:

On 7/21/2022 1:41 PM, bitrex wrote:
On 7/21/2022 1:21 PM, Martin Brown wrote:
On 21/07/2022 16:31, John Walliker wrote:
On Thursday, 21 July 2022 at 15:42:40 UTC+1, bitrex wrote:
On 7/21/2022 10:21 AM, Lasse Langwadt Christensen wrote:
torsdag den 21. juli 2022 kl. 16.04.42 UTC+2 skrev bitrex:
On 7/21/2022 7:06 AM, Martin Brown wrote:
On 21/07/2022 01:22, John Larkin wrote:
On Wed, 20 Jul 2022 19:32:20 -0400, Phil Hobbs
pcdhSpamM...@electrooptical.net> wrote:

John Larkin wrote:


Suppose I have several rackmount boxes and each has a BNC
connector on
the back. Each of them has an open-drain mosfet, a weak
pullup, and a
lowpass filtered schmitt gate back into our FPGA.

I can daisy-chain several boxes with BNC cables and tees.

Each box has a 40 MHz VCXO and I want to phase-lock them, or
at least
time-align them to always be the same within a few microseconds,
longterm.

I could call one the leader (not \"master\") and make the others
followers (not \"slaves\") and have the leader make an active
low pulse
maybe once a second. A follower would use her (not \"his\")
clock to
measure the incoming period and tweak its local VCXO in the right
direction. That should work.

Don\'t GPS receivers lock their 10 MHz oscillators to a 1 PPS
pulse
from the satellites?

My system should work from a 1 PPS GPS pulse too, all boxes as
followers.

The PLL algorithm might be interesting.


It\'s certainly possible. However, within whatever tiny loop
bandwidth
you wound up with, the lockers would still have

20 log(40e6) = 152 dB

higher phase noise than the lockee.

GPS has that problem too.


It would be interesting to do the math to see whether it\'s
possible to
generate a concensus lock for the group: if you get everybody
close
enough, just sum their sine wave outputs and lock each one of
them to
that, with some bit of AC coupling or something so that they
don\'t all
wander together off to the edge of the tuning range.

Maybe have one doing the locking with a phase shifter and the
others
with VCOs, or something like that.

Definitely a partly-baked idea, but surely one could do better
than
152 dB!

Cheers

Phil Hobbs

Each box is basically a multichannel power supply, but channels
can be
programmed to do stuff in timed sequences. I want different box
outputs to time align within, say, one millisecond longterm once
programs are kicked off together. So, many microseconds of
equivalent
RMS phase noise is OK as long as we stay time aligned longterm.

You really need to define longterm before the problem becomes well
posed. Do you mean hours, days, weeks or months of runtime?

Yeah I don\'t quite get it, either. My rack of synthesizers can
each play
one voice of the Maple Leaf Rag via MIDI and they all stay synced
together really well, at least over a timespan of several
minutes.

but they are anot free runnign are they? they are all reacting to midi

There\'s a system clock in each one surely but they don\'t try to sync
their system clocks, they receive an instruction \"do X for Y ms\" and
their processor figures out how long Y ms is, and does it for that
long.

It is literally good enough for rock & roll, but whether it\'s good
enough for power supply sequencing IDK, there is gonna be some latency.

HP used to have GPIB on their power supplies, I\'ve never used it but I
expect it wasn\'t really useful for tight synchronization.

The Group Execute Trigger command does allow quite tight synchronisation
between different GPIB devices.

GPIB flat out on a good day could manage 1Mbyte/s but in real world
situations with interconnect cabling you would be lucky to get
500kb/s. It\'s best feature was that it ran at the maximum speed the
receiving device could handle (assuming that the controller was fast
enough).

Synchronisation to a GET command would be probably be better than 1us
but would depend on the decoding time in each individual box. Some
GPIB devices were rather pedestrian at accepting commands.

IEEE488 was good in its day but a bit long in the tooth now. Still on
some test equipment in service today and was provided as standard on
NEC 9801 PC\'s in Japan although hardly ever used by their customers.

The cables and connectors could only be described as a bit clunky!
They really didn\'t get on with metal swarf being around but were OK in
clean dry electronics/physics labs - much less so in chemistry ones...


I feel like there wasn\'t really a good relatively inexpensive standard
for interfacing PC peripherals until USB.
Oops I forgot about AppleTalk. I remember helping some students get
their Mac SEs on the Internet (email and FTP and maybe some basic web
browsing I can\'t recall) via some kind of Ethernet to AppleTalk adapter,
it wasn\'t uncommon in the mid 90s for college students to be using
hand-me-down Macs from the 80s, but I couldn\'t for the life of me now
remember how I did it.

afaik Apple talk was just a serialport with an RS422 transceiver instead of RS232

 

[bitrex]

On 7/21/2022 2:01 PM, Lasse Langwadt Christensen wrote:

torsdag den 21. juli 2022 kl. 19.45.26 UTC+2 skrev bitrex:
On 7/21/2022 1:41 PM, bitrex wrote:
On 7/21/2022 1:21 PM, Martin Brown wrote:
On 21/07/2022 16:31, John Walliker wrote:
On Thursday, 21 July 2022 at 15:42:40 UTC+1, bitrex wrote:
On 7/21/2022 10:21 AM, Lasse Langwadt Christensen wrote:
torsdag den 21. juli 2022 kl. 16.04.42 UTC+2 skrev bitrex:
On 7/21/2022 7:06 AM, Martin Brown wrote:
On 21/07/2022 01:22, John Larkin wrote:
On Wed, 20 Jul 2022 19:32:20 -0400, Phil Hobbs
pcdhSpamM...@electrooptical.net> wrote:

John Larkin wrote:


Suppose I have several rackmount boxes and each has a BNC
connector on
the back. Each of them has an open-drain mosfet, a weak
pullup, and a
lowpass filtered schmitt gate back into our FPGA.

I can daisy-chain several boxes with BNC cables and tees.

Each box has a 40 MHz VCXO and I want to phase-lock them, or
at least
time-align them to always be the same within a few microseconds,
longterm.

I could call one the leader (not \"master\") and make the others
followers (not \"slaves\") and have the leader make an active
low pulse
maybe once a second. A follower would use her (not \"his\")
clock to
measure the incoming period and tweak its local VCXO in the right
direction. That should work.

Don\'t GPS receivers lock their 10 MHz oscillators to a 1 PPS
pulse
from the satellites?

My system should work from a 1 PPS GPS pulse too, all boxes as
followers.

The PLL algorithm might be interesting.


It\'s certainly possible. However, within whatever tiny loop
bandwidth
you wound up with, the lockers would still have

20 log(40e6) = 152 dB

higher phase noise than the lockee.

GPS has that problem too.


It would be interesting to do the math to see whether it\'s
possible to
generate a concensus lock for the group: if you get everybody
close
enough, just sum their sine wave outputs and lock each one of
them to
that, with some bit of AC coupling or something so that they
don\'t all
wander together off to the edge of the tuning range.

Maybe have one doing the locking with a phase shifter and the
others
with VCOs, or something like that.

Definitely a partly-baked idea, but surely one could do better
than
152 dB!

Cheers

Phil Hobbs

Each box is basically a multichannel power supply, but channels
can be
programmed to do stuff in timed sequences. I want different box
outputs to time align within, say, one millisecond longterm once
programs are kicked off together. So, many microseconds of
equivalent
RMS phase noise is OK as long as we stay time aligned longterm.

You really need to define longterm before the problem becomes well
posed. Do you mean hours, days, weeks or months of runtime?

Yeah I don\'t quite get it, either. My rack of synthesizers can
each play
one voice of the Maple Leaf Rag via MIDI and they all stay synced
together really well, at least over a timespan of several
minutes.

but they are anot free runnign are they? they are all reacting to midi

There\'s a system clock in each one surely but they don\'t try to sync
their system clocks, they receive an instruction \"do X for Y ms\" and
their processor figures out how long Y ms is, and does it for that
long.

It is literally good enough for rock & roll, but whether it\'s good
enough for power supply sequencing IDK, there is gonna be some latency.

HP used to have GPIB on their power supplies, I\'ve never used it but I
expect it wasn\'t really useful for tight synchronization.

The Group Execute Trigger command does allow quite tight synchronisation
between different GPIB devices.

GPIB flat out on a good day could manage 1Mbyte/s but in real world
situations with interconnect cabling you would be lucky to get
500kb/s. It\'s best feature was that it ran at the maximum speed the
receiving device could handle (assuming that the controller was fast
enough).

Synchronisation to a GET command would be probably be better than 1us
but would depend on the decoding time in each individual box. Some
GPIB devices were rather pedestrian at accepting commands.

IEEE488 was good in its day but a bit long in the tooth now. Still on
some test equipment in service today and was provided as standard on
NEC 9801 PC\'s in Japan although hardly ever used by their customers.

The cables and connectors could only be described as a bit clunky!
They really didn\'t get on with metal swarf being around but were OK in
clean dry electronics/physics labs - much less so in chemistry ones...


I feel like there wasn\'t really a good relatively inexpensive standard
for interfacing PC peripherals until USB.
Oops I forgot about AppleTalk. I remember helping some students get
their Mac SEs on the Internet (email and FTP and maybe some basic web
browsing I can\'t recall) via some kind of Ethernet to AppleTalk adapter,
it wasn\'t uncommon in the mid 90s for college students to be using
hand-me-down Macs from the 80s, but I couldn\'t for the life of me now
remember how I did it.

afaik Apple talk was just a serialport with an RS422 transceiver instead of RS232

Sounds right, for the physical layer. On the data link layer it was
smarter than a raw serial port though, IIRC for simple configurations of
peripherals it configured itself.

 

[Jan Panteltje]

On a sunny day (Thu, 21 Jul 2022 14:52:44 +0200) it happened Gerhard Hoffmann
<dk4xp@arcor.de> wrote in <tbbi6s$ghm7$1@solani.org>:

Am 21.07.22 um 13:19 schrieb jlarkin@highlandsniptechnology.com:


Where does the 10 MHz come from?

Choise of implementer. One local clock generator is needed.
This clock determines short term stabiity and phase noise.

My Lucent KS24361 uses 5 MHz MTI-260 double ovens; for
redundancy/holdover it has a 2nd unit with another crystal
oven without a receiver.

The redundancy units were really hard to sell without the
receiver; that\'s why I have 20 of these MTI-260, got a good
price.

They were new old stock built by HP/Agilent for Lucent as
replacement parts. They have never been on a telecom tower
in China like most of those one gets on ebay.

I have expanded the Lucent to 10 MHZ and with a distribution
amplifier:

http://www.hoffmann-hochfrequenz.de/downloads/DoubDist.pdf

cheers, Gerhard

I have a 10 MHz rubidium reference from ebay (used)
I think John has one too, he inspired me to buy one

http://panteltje.com/pub/FPGA_board_with_25MHz_VCXO_locked_to_rubidium_10MHz_reference_IMG_3724.GIF
http://panteltje.com/pub/GPS_L1_locked_to_rubidium_reference_test_setup_IMG_3733.GIF
The rubidium reference is on its side on the loft.
It is not true GPS receivers are mostly software
http://lea.hamradio.si/~s53mv/navsats/theory.html
some counters will do, when GPS started not so much super computahs around..
I\'v played some with it, including doing it in software only:
http://michelebavaro.blogspot.nl/2012/04/spring-news-in-gnss-and-sdr-domain.html

 

[Jan Panteltje]

On a sunny day (Thu, 21 Jul 2022 12:35:52 -0400) it happened bitrex
<user@example.net> wrote in <JffCK.582999$X_i.553981@fx18.iad>:

Sounds good

It\'s actually useful to me to type and discuss this sort of thing.
Ideas evolve at their own rates.


I\'m just sayin there\'s also a standard (uh oh!) dating back to the 50s
for synchronizing equipment using time-code:

https://en.wikipedia.org/wiki/IRIG_timecode

up to 10,000 pulses per second. I understand now that there\'s no
facility to program or sequence one box from the others they each run
their own \"script\" from memory.

Yea, used it every day back then audio-video sync

 

[bitrex]

On 7/21/2022 2:29 PM, Jan Panteltje wrote:

On a sunny day (Thu, 21 Jul 2022 12:35:52 -0400) it happened bitrex
user@example.net> wrote in <JffCK.582999$X_i.553981@fx18.iad>:


Sounds good

It\'s actually useful to me to type and discuss this sort of thing.
Ideas evolve at their own rates.


I\'m just sayin there\'s also a standard (uh oh!) dating back to the 50s
for synchronizing equipment using time-code:

https://en.wikipedia.org/wiki/IRIG_timecode

up to 10,000 pulses per second. I understand now that there\'s no
facility to program or sequence one box from the others they each run
their own \"script\" from memory.

Yea, used it every day back then audio-video sync

\"The Dollar stuff was the first stuff I really produced, after being in
Yes in 1982, and by that time I had a rig. Very few people had rigs back
then, but I had one and it consisted of a Roland TR808 and a set of
Simmons drum modules.

Dave Simmons had modified my TR808 and put on a set of triggers so that
the kick drum from the 808 would also trigger the Simmons kick drum. On
top of that, I had a Roland sequencer. I\'ve forgotten what serial number
it was, but I\'ve still got it somewhere. It had four buttons — \'A\', \'B\',
\'C\' and \'D\'. You put lists of notes in it and it played the list of
notes. You sent a trigger to it.

I used to use the cowbell from the 808 as a trigger — you sent it and it
would play through the list of notes. So you might put four \'G\'s and an
\'A\' and a \'B\', and however you played it, it would loop that list of
notes. That sequencer was hooked up to a Minimoog that had CV and Gate
on it.

And with that rig I thee wed! You know, those CV/Gate things were much
tighter than MIDI. They were spot bollock on! Spot on. Much better feel
than just your normal MIDI rig these days.\"

<https://www.soundonsound.com/people/trevor-horn>

 

[Cydrome Leader]

jlarkin@highlandsniptechnology.com wrote:

On Thu, 21 Jul 2022 07:43:18 +0200, Gerhard Hoffmann <dk4xp@arcor.de
wrote:

Am 21.07.22 um 01:20 schrieb John Larkin:


Suppose I have several rackmount boxes and each has a BNC connector on
the back. Each of them has an open-drain mosfet, a weak pullup, and a
lowpass filtered schmitt gate back into our FPGA.

I can daisy-chain several boxes with BNC cables and tees.

Each box has a 40 MHz VCXO and I want to phase-lock them, or at least
time-align them to always be the same within a few microseconds,
longterm.

I have a backburner project of locking 16 MTI-260 oscillators
slooowy to another one, and when they are in sync, combine
them with an array of Wilkinsons. That should have a nice
effect on phase noise by averaging over 16.
The CPLD has enough resources to implement that as a delay
locked loop with 1 pps, but low hanging fruit first.


I could call one the leader (not \"master\") and make the others
followers (not \"slaves\") and have the leader make an active low pulse
maybe once a second. A follower would use her (not \"his\") clock to
measure the incoming period and tweak its local VCXO in the right
direction. That should work.

Don\'t GPS receivers lock their 10 MHz oscillators to a 1 PPS pulse
from the satellites?

No. There is no 1PPS pulse from the sat nor the need for exactly 10 MHz.
The sats transmit a pseudo noise sequence that is
aligned to the second of their local clock source.
The GPS receiver knows the polynomial and runs a local copy of
the polynomial. It knows by cross correlation if the local
pseudo noise is the same as that of the sat and therefore knows
the start of the second. Usually that won\'t be the case.
Then the receiver delays its own polynomial by omitting a
clock to the shift register that generates it and tries again.
Sooner or later it will fit.

Where does the 10 MHz come from?

https://en.wikipedia.org/wiki/GPS_disciplined_oscillator

 

[Don Y]

On 7/21/2022 10:41 AM, bitrex wrote:

The cables and connectors could only be described as a bit clunky!
They really didn\'t get on with metal swarf being around but were OK in clean
dry electronics/physics labs - much less so in chemistry ones...

I feel like there wasn\'t really a good relatively inexpensive standard for
interfacing PC peripherals until USB. Serial and parallel were slow
(occasionally some devices supported ECP, I remember having to enable it in the
BIOS sometimes), and external SCSI wasn\'t really well-suited to anything but
external disk drives.

That\'s sort of like claiming there really wasn\'t a good, relatively
inexpensive standard for browsing distributed resources across The Internet
(gopher, anyone?)

Hardware costs have shrunk to the point where things that were science fiction
a decade ago are commonplace, nowadays. (who\'d have thought of wirelessly
connecting a mouse/keyboard to a PC -- or PHONE! -- decades ago?)

SCSI has always supported more than \"just external disk drives\". I used
5380\'s as \"message passing coprocessors\" in a design decades ago. Skip
the cost of the cables and connectors and just run a ribbon between cards,
driven by 5380\'s on each.

SCSI\'s problem as a universal interconnect comes from those cabling costs
along with the dearth of devices that embraced SCSI. Other than disk,
tape and scanners, SCSI was a dead-end -- and only suitable for intermachine
communication at very short ranges. Running 8 (or 16 or 32) data conductors
is costly in terms of cabling, connector *and* silicon. (there\'s a reason
it\'s USB and not UPB!)

Who\'s gonna embrace something that has a small potential market?

I don\'t think you could hot-swap IEE-488 either but it seems like it was pretty
fast and more amenable to a wide class of devices than SCSI, but just didn\'t
seem to catch on outside the test equipment realm.

 

[Clifford Heath]

On 21/7/22 22:52, Gerhard Hoffmann wrote:

Am 21.07.22 um 13:19 schrieb jlarkin@highlandsniptechnology.com:

Where does the 10 MHz come from?

Choise of implementer. One local clock generator is needed.
This clock determines short term stabiity and phase noise.

Exactly. It\'s weird really, since the GPS P code bit rate is 10.23Mbps,
meaning the PRNG shift registers are being clocked with 10.23MHz.
Perhaps the phase noise of the 10.23MHz clock isn\'t that critial...

At that rate, a 1-bit misalignment is 30m of distance. To get better
accuracy you need a polyphase clock, and the correlation would move a
shift register\'s clock to a clock which is forwards or back in phase
from its current clock, rather than just skipping or adding clock pulses.

The Apollo ranging system used a bit rate around 1Mbps, but could
resolve down to about 1m, or approximately 1 degrees of clock phase. If
GPS could do that, it would be accurate to 10cm.

So anyhow, folk love their \"GPSDO\" 10MHz clock outputs often without
really questioning the actual phase noise coming from the internal
oscillator which synthesizes that output, and which ultimately isn\'t
even the clock that\'s being used to recover the signals.

Clifford Heath.

 

[Don Y]

On 7/21/2022 8:31 AM, John Walliker wrote:

On Thursday, 21 July 2022 at 15:42:40 UTC+1, bitrex wrote:
HP used to have GPIB on their power supplies, I\'ve never used it but I
expect it wasn\'t really useful for tight synchronization.

The Group Execute Trigger command does allow quite tight synchronisation
between different GPIB devices.

If you\'re rolling your own PROPRIETARY protocol, you can design the
stack so that really tight (limited by hardware layer) latencies
are possible. E.g., if your protocol KNOWS that a \"sync\" will
be \"coming along shortly\", the code can take steps to minimize the time
required to detect and respond to that.

 

[Don Y]

On 7/21/2022 7:04 AM, bitrex wrote:

You really need to define longterm before the problem becomes well posed. Do
you mean hours, days, weeks or months of runtime?

Yeah I don\'t quite get it, either. My rack of synthesizers can each play one
voice of the Maple Leaf Rag via MIDI and they all stay synced together really

How is \"really well\" defined? In the domain of human auditory perception?

well, at least over a timespan of several minutes...superficially at least it
sounds like he wants a sequencer.

Can you disconnect the controller and have them continue playing (from stored
sequence) AND retain that synchornization \"indefinitely\"?

Using the nuts & bolts system clock for synchronization of \"user tasks\" also
makes me uncomfortable, if the device behavior only need to align to the
millisecond why not trigger them using some simple network protocol and let
their hardware figure out how long a millisecond is independently. Do the
timings of these boxes need to be tighter than the Maple Leaf Rag?

Providing (and distributing) individual \"events\" on a shared medium suffers
from scaling problems. How do you tag them so that the intended clients
know which events are of significance to them?

Folks can understand how to consult a single time reference WITHIN a device.
Admittedly, there can be skew in those references due to the frequency at
which the reference is updated as well as consulted (and, the time it
takes individual clients to \"process\" that information).

Bolting on a mechanism that allows the time references on different
nodes to act AS IF a single reference addresses the distribution of that
reference separately from the reference\'s internal consumers.

How frequently you resync those references depends on how much variation
you can encounter in the individual local timebases (even OCXOs have
tolerances) and how much slip the \"application\" can tolerate. You
can choose to address the absolute time reference (it is now XXX:XX)
and/or the rate of time passage (it has been X time units since event Y).

If your MIDI instrument is told to emit a particular note/sound at
\"beat #564\", doesn\'t it depend on having some notion of WHEN beat #0
occurred and how long each beat is? How long will that \"rate\" be
observed by its hardware (osc) along with those of its peers?

One pass-time at KCP was to \"read\" \"Row, Row, Row Your Boat\" into a
group of machines. Then, twiddle the pitch of each and have them
replay the text from internal memory, in a \"round\". Of course, it
was damn near impossible to get the *rate* controls at the same
setting (potentiometers) so it wasn\'t long before the \"singers\"
drifted far enough apart that it sounded like an angry mob!
(rhubarb, rhubarb, rhubarb).

But, there was never a need for such synchronization (beyond novelty)
so there were no design measures put in place to ensure it would be
repeatable and trackable.

 

[Don Y]

On 7/21/2022 7:12 AM, bitrex wrote:

On 7/21/2022 4:33 AM, John Walliker wrote:
If you have an ethernet interface to each unit then Precision Time Protocol
should do exactly what you want.
https://en.wikipedia.org/wiki/Precision_Time_Protocol
John

Yeah, that sounds like the ticket to me also. Trying to use each box\'s system
clock for purposes of keeping \"user-space\" tasks in sync across boxes makes me
uncomfortable, sounds like a srs hack.

How else would you synchronize events generated (or DETECTED!) across boxes?
Run a separate wire for each event?

If you need to tightly synchronize events between physically separate hardware
why not use a standard designed for the task rather than some roll-your-own shit

Because standards try to address ALL POSSIBLE users of a particular
feature/mechanism.

Done \"as intended\", PTP requires timestamping hardware in the NIC to note
when the packets actually hit (or come off) the wire. With a good deal of
care, you can get sub-microsecond synchronization between nodes. But, swap
the switch or let network traffic change significantly (e.g., unconstrained)
and all bets are off.

If all you are trying to do is synchronize some notion of time across
devices, why take on all the overhead of an NIC, network stack,
PTP protocol, etc. JUST for that?

How tightly must the time references be synchronized? How tightly must
they REMAIN synchronized (local oscillators drift at different rates)?

OTOH, if those mechanisms are already present/needed in your product/design,
then bolting PTP on top can make sense.

But, *how* you do that is your own decision -- if you don\'t need to
\"play nice\" with other vendors\' products, then why take on the cost
of doing so? (why so many oddball \"serial port\" connectors and
implementations, over the years? wasn\'t there ONE standard??)

[As to the \"hack\", you underestimate how powerful the notion of
just being able to say \"do this at t=X\" is in designing a box!]

The biggest downside with shared resources -- esp ones that are
as crucial as this -- is sorting out how to handle the situation
when that resource fails or is unavailable. E.g., PTP allows
a new master to be elected. Fine. But, implicit in that is the
fact that the old master is now \"not functional\"... can you
continue to operate under those conditions?

 

[bitrex]

On 7/21/2022 9:04 PM, Don Y wrote:

On 7/21/2022 7:04 AM, bitrex wrote:
You really need to define longterm before the problem becomes well
posed. Do you mean hours, days, weeks or months of runtime?

Yeah I don\'t quite get it, either. My rack of synthesizers can each
play one voice of the Maple Leaf Rag via MIDI and they all stay synced
together really

How is \"really well\" defined?  In the domain of human auditory perception?

well, at least over a timespan of several minutes...superficially at
least it sounds like he wants a sequencer.

Can you disconnect the controller and have them continue playing (from
stored
sequence) AND retain that synchornization \"indefinitely\"?

Using the nuts & bolts system clock for synchronization of \"user
tasks\" also makes me uncomfortable, if the device behavior only need
to align to the millisecond why not trigger them using some simple
network protocol and let their hardware figure out how long a
millisecond is independently. Do the timings of these boxes need to be
tighter than the Maple Leaf Rag?

Providing (and distributing) individual \"events\" on a shared medium suffers
from scaling problems.  How do you tag them so that the intended clients
know which events are of significance to them?

His machine\'s sequences are all programmed individual to a given box,
there\'s no provision for controlling one from the others directly other
than telling one to start its program and providing some kind of master
sync, whatever it is.

The way this would be handled in the music-world analogy is something
like MIDI timecode, it\'s not unusual for individual machines to have
their own sequencers and want to gang events together in that realm, either.

<https://en.wikipedia.org/wiki/MIDI_timecode>

The resolution of the timecode doesn\'t automatically imply the timing
resolution, given a \"start\" command and the clock any good-quality
device will be able to interpolate between quarter-frames to know when
it should fire an event, if its internal sequencer has finer granularity
than that.

I mentioned elsewhere that there\'s a more general-purpose sync standard
that\'s been around a long time:

<https://en.wikipedia.org/wiki/IRIG_timecode>

 

[Don Y]

On 7/21/2022 6:19 PM, bitrex wrote:

On 7/21/2022 9:04 PM, Don Y wrote:
On 7/21/2022 7:04 AM, bitrex wrote:
You really need to define longterm before the problem becomes well posed.
Do you mean hours, days, weeks or months of runtime?

Yeah I don\'t quite get it, either. My rack of synthesizers can each play one
voice of the Maple Leaf Rag via MIDI and they all stay synced together really

How is \"really well\" defined? In the domain of human auditory perception?

well, at least over a timespan of several minutes...superficially at least
it sounds like he wants a sequencer.

Can you disconnect the controller and have them continue playing (from stored
sequence) AND retain that synchornization \"indefinitely\"?

Using the nuts & bolts system clock for synchronization of \"user tasks\" also
makes me uncomfortable, if the device behavior only need to align to the
millisecond why not trigger them using some simple network protocol and let
their hardware figure out how long a millisecond is independently. Do the
timings of these boxes need to be tighter than the Maple Leaf Rag?

Providing (and distributing) individual \"events\" on a shared medium suffers
from scaling problems. How do you tag them so that the intended clients
know which events are of significance to them?

His machine\'s sequences are all programmed individual to a given box, there\'s
no provision for controlling one from the others directly other than telling
one to start its program and providing some kind of master sync, whatever it is.

But there is still a need to deploy that \"program\" (sequence).

Is there an inherent limit to the time spanned by such a (future)
definition? Why not sync them on the assembly line and then
forget about it? (Ans: because there would be intolerable
drift in references)

The way this would be handled in the music-world analogy is something like MIDI
timecode, it\'s not unusual for individual machines to have their own sequencers
and want to gang events together in that realm, either.

https://en.wikipedia.org/wiki/MIDI_timecode

The resolution of the timecode doesn\'t automatically imply the timing
resolution, given a \"start\" command and the clock any good-quality device will
be able to interpolate between quarter-frames to know when it should fire an
event, if its internal sequencer has finer granularity than that.

Of course. I\'ve been designing \"clocks\" (timepieces) for decades that
only display time to nothing better than 100Hz -- yet rely on the mains
frequency to discipline the local oscillator over the long run (days).

But, (decorative) timepieces only have to deal with synchronization
on the scale of human perception. And, while mains power is available
(as a reference frequency), there is no slippage between timepieces.
The problem of spanning outages is where the real engineering comes
into play; how much will the current timepiece\'s XTAL drift wrt
other timepieces in the absence of that line frequency reference?
(timepieces can\'t talk to each other so any skew that occurs during
an outage is \"baked in\" thereafter)

I mentioned elsewhere that there\'s a more general-purpose sync standard that\'s
been around a long time:

IMO, there\'s no need to transfer time information. You need a reference
point (in time) and then a reference *rate*.

The rate needs to be broadcast (\"shared\") often enough that slip can
be noticed and corrected -- before it becomes \"significant\" (for whatever
value of \"significant\" is pertinent).

The reference point can be indicated in-band by a double-pulse
(i.e., first pulse occurs at the intended \"rate\" point, in time;
presence of another pulse within some delta thereafter means
\"that rate pulse was also a reference point\").

Of course, if you are a stickler for detail, you\'d need some way of
addressing difference in transport delays (likely not significant
within a single rack but of interest when devices are hundreds of
meters apart!)

 

[Clifford Heath]

On 22/7/22 03:10, Phil Hobbs wrote:

Gerhard Hoffmann wrote:
Am 21.07.22 um 16:15 schrieb Phil Hobbs:

I wonder if there\'s an advantage to using the closure phase for an
array that large.  With 17 oscillators you\'ve got 136 independent
phase differences, so maybe there\'s a way to get 22 dB instead of 12
dB improvement.

-v ?

what do you mean with closure phase? Where do the 22 dB come
from?

The idea was simply to have all 16 regulated to the be
synchronous and then feed them into a 16-to--1 Wilkinson
combiner. The phase noise should average out among the
16 units. Just as proof of concept. The MTI-260 are quite ok,
but with bleeding edge oscillators that could be interesting.
In the region where you just cannot improve an oscillator.

Cheers
Gerhard

Sure.  Thing is, that wastes a lot of information that you could maybe
use to get 10*log(136) = 21.3 dB improvement instead of 10*log(17) =
12.3 dB.  [136 = N(N-1)/2 when N = 17.]

Closure is a really cute idea, which I first came across in the context
of very long baseline interferometry (VLBI) radio telescopes.  See the
discussion from BEOS 3e here:

https://electrooptical.net/www/sed/closure.png>.

Interesting, thanks.

Some frequency synthesiser chips employ proprietary majick to reduce the
phase noise associated with integer divide/multiply ratios. Polyphase
oscillator and slipping by partial cycles I think. Perhaps they\'re doing
something like closure against the different clock phases?

Clifford Heath

 

[whit3rd]

On Thursday, July 21, 2022 at 10:30:47 AM UTC-7, lang...@fonz.dk wrote:

torsdag den 21. juli 2022 kl. 01.21.08 UTC+2 skrev John Larkin:
Suppose I have several rackmount boxes...
Each box has a 40 MHz VCXO and I want to phase-lock them, or at least
time-align them to always be the same within a few microseconds,
longterm.

I could call one the leader (not \"master\") and make the others
followers (not \"slaves\") and have the leader make an active low pulse
maybe once a second.

why so slow?
A follower would use her (not \"his\") clock to
measure the incoming period and tweak its local VCXO in the right
direction. That should work.

it\'ll only make the run at at the same speed, not time aligned

If you ever apply a command time setting once, and they have the same
speed, they will stay aligned. It\'d be an improvement over letting the
clocks drift for a second at a time, then correcting. I\'m not sure what
\'measure the incoming period\' has to do with it, though; just use an up/down
counter to compare leader to follower, and D/A the count to trim the VCO.

All it takes to sense a frequency difference is a counter. Negative
feedback nulls the difference.

 

[server]

On Fri, 22 Jul 2022 00:08:56 -0000 (UTC), Cydrome Leader
<presence@MUNGEpanix.com> wrote:

jlarkin@highlandsniptechnology.com wrote:
On Thu, 21 Jul 2022 07:43:18 +0200, Gerhard Hoffmann <dk4xp@arcor.de
wrote:

Am 21.07.22 um 01:20 schrieb John Larkin:


Suppose I have several rackmount boxes and each has a BNC connector on
the back. Each of them has an open-drain mosfet, a weak pullup, and a
lowpass filtered schmitt gate back into our FPGA.

I can daisy-chain several boxes with BNC cables and tees.

Each box has a 40 MHz VCXO and I want to phase-lock them, or at least
time-align them to always be the same within a few microseconds,
longterm.

I have a backburner project of locking 16 MTI-260 oscillators
slooowy to another one, and when they are in sync, combine
them with an array of Wilkinsons. That should have a nice
effect on phase noise by averaging over 16.
The CPLD has enough resources to implement that as a delay
locked loop with 1 pps, but low hanging fruit first.


I could call one the leader (not \"master\") and make the others
followers (not \"slaves\") and have the leader make an active low pulse
maybe once a second. A follower would use her (not \"his\") clock to
measure the incoming period and tweak its local VCXO in the right
direction. That should work.

Don\'t GPS receivers lock their 10 MHz oscillators to a 1 PPS pulse
from the satellites?

No. There is no 1PPS pulse from the sat nor the need for exactly 10 MHz.
The sats transmit a pseudo noise sequence that is
aligned to the second of their local clock source.
The GPS receiver knows the polynomial and runs a local copy of
the polynomial. It knows by cross correlation if the local
pseudo noise is the same as that of the sat and therefore knows
the start of the second. Usually that won\'t be the case.
Then the receiver delays its own polynomial by omitting a
clock to the shift register that generates it and tries again.
Sooner or later it will fit.

Where does the 10 MHz come from?

https://en.wikipedia.org/wiki/GPS_disciplined_oscillator

\"GPSDOs typically phase-align the internal flywheel oscillator to the
GPS signal by using dividers to generate a 1PPS signal from the
reference oscillator, then phase comparing this 1PPS signal to the
GPS-generated 1PPS signal and using the phase differences to control
the local oscillator frequency in small adjustments via the tracking
loop.\"

That\'s what I meant: the 10M xo is locked to the 1 PPS GPS output.

The GPS 1 PPS is perfect (by definition) long-term but terrible
short-term, so the XO or rubidium has to be very good itself, and the
loop has to be very slow. Big flywheel.

I\'ll be doing something similar, locking my 40 MHz clock to some 1 PPS
input, the difference being that I don\'t mind a few us of jitter, so I
can lock quick and crude.

 

[server]

On Thu, 21 Jul 2022 12:35:52 -0400, bitrex <user@example.net> wrote:

On 7/21/2022 12:09 PM, jlarkin@highlandsniptechnology.com wrote:
On Thu, 21 Jul 2022 11:36:01 -0400, bitrex <user@example.net> wrote:

On 7/21/2022 10:55 AM, jlarkin@highlandsniptechnology.com wrote:
On Thu, 21 Jul 2022 10:15:20 -0400, bitrex <user@example.net> wrote:

On 7/21/2022 10:12 AM, bitrex wrote:
On 7/21/2022 4:33 AM, John Walliker wrote:
On Thursday, 21 July 2022 at 07:49:43 UTC+1, whit3rd wrote:
On Wednesday, July 20, 2022 at 4:21:08 PM UTC-7, John Larkin wrote:
Suppose I have several rackmount boxes and each has a BNC connector on
the back. Each of them has an open-drain mosfet, a weak pullup, and a
lowpass filtered schmitt gate back into our FPGA.

I can daisy-chain several boxes with BNC cables and tees.

Each box has a 40 MHz VCXO and I want to phase-lock them, or at least
time-align them to always be the same within a few microseconds,
longterm.
If you can tolerate \'a few microseconds\' on a 40 MHz signal, that\'s
not a phase-lock
problem, it\'s a frequency-lock problem. Why not just run an up/down
counter
to generate a correction voltage for each non-leading VCO?

If you have an ethernet interface to each unit then Precision Time
Protocol
should do exactly what you want.
https://en.wikipedia.org/wiki/Precision_Time_Protocol
John

Yeah, that sounds like the ticket to me also. Trying to use each box\'s
system clock for purposes of keeping \"user-space\" tasks in sync across
boxes makes me uncomfortable, sounds like a srs hack.

At minimum it likely won\'t scale very well. Why implicitly discourage
one\'s customers from buying only a limited number of units

Time synchronization of programmable power supplies and loads is
precisely one selling feature that my customers want but nobody else
seems to make. It works fine in one box but I want to extend the
function to multiple boxes in a rack.

The controller in each box is a MicroZed and doesn\'t support the PTP
thing, and my customers may not be able top provide it anyhow. The 1
PPS thing works with just a BNC cable.

Besides, what I do is design things.



So if it works fine in one box why can\'t you just send some simple
packet data that says like OK box 4, run program 2 now for 1,084 ms.

If they\'re all already locked individually to GPS or whatever other
standard they know how long a ms is. There will be some overhead latency
but syncing a bunch of boxes within a ms doesn\'t seem unreasonable.

It\'s at least easier to ballpark how well a digital scheme like that
would scale on paper. The BNC scheme is analog, how do you know.

The BNC would be 1 PPS pulses. They could come from GPS if it\'s
available, or one of the boxes could output the 1 PPS and the others
would sync to that.

When we designed the box, we added two BNCs, open drain drivers with
weak pullups and schmitt receivers, connected into our FPGA. We didn\'t
know what they were for, but they turn out to be handy.
I see.

One is START RUNNING YOUR SEQUENCES NOW and the other is the 1 PPS
lock. That should work.

Each module has a sequencer table in its local fpga RAM, sort of a
primitive program with 5 opcodes. A table entry can write any other
register in the FPGA, ie do anything, and one command is WAIT UNTIL,
against the 1 MHz start counter.

Customers can write fairly simple SCPI script files to program events
in each module, load them up, and fire off a shot and keep the whole
experiment time synchronized forever.

Gotcha

All we want to do is revolutionize the power supply business.

Sounds good

It\'s actually useful to me to type and discuss this sort of thing.
Ideas evolve at their own rates.


I\'m just sayin there\'s also a standard (uh oh!) dating back to the 50s
for synchronizing equipment using time-code:

https://en.wikipedia.org/wiki/IRIG_timecode

up to 10,000 pulses per second. I understand now that there\'s no
facility to program or sequence one box from the others they each run
their own \"script\" from memory.

It would seem simpler to flip a switch to designate one box as the
master and have the others watch a timecode it sends out at a higher
resolution than the desired sync error. If the master then needs to
itself be synced to real-world time via a GPSDO then ah...well I guess
there should\'ve been a 3rd BNC :-(

There should be a third BNC, or a D9 or something. Synchronizing boxes
has et up all my general-puropse i/o\'s.