Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

The bug starts here.


tech / sci.electronics.design / Re: really slow PLL

SubjectAuthor
* really slow PLLJohn Larkin
+* Re: really slow PLLPhil Hobbs
|`* Re: really slow PLLJohn Larkin
| +* Re: really slow PLLPhil Hobbs
| |`* Re: really slow PLLjlarkin
| | `* Re: really slow PLLPhil Hobbs
| |  +* Re: really slow PLLjlarkin
| |  |`* Re: really slow PLLPhil Hobbs
| |  | `- Re: really slow PLLjlarkin
| |  `* Re: really slow PLLLes Cargill
| |   `- Re: really slow PLLJohn Larkin
| +* Re: really slow PLLbitrex
| |+- Re: really slow PLLjlarkin
| |`* Re: really slow PLLLes Cargill
| | `* Re: really slow PLLLasse Langwadt Christensen
| |  +- Re: really slow PLLbitrex
| |  `- Re: really slow PLLLes Cargill
| `* Re: really slow PLLMartin Brown
|  +* Re: really slow PLLjlarkin
|  |`* Re: really slow PLLMartin Brown
|  | `- Re: really slow PLLjlarkin
|  +* Re: really slow PLLPhil Hobbs
|  |`- Re: really slow PLLjlarkin
|  `* Re: really slow PLLbitrex
|   +* Re: really slow PLLLasse Langwadt Christensen
|   |`* Re: really slow PLLbitrex
|   | `* Re: really slow PLLJohn Walliker
|   |  +* Re: really slow PLLMartin Brown
|   |  |+* Re: really slow PLLbitrex
|   |  ||+* Re: really slow PLLbitrex
|   |  |||`* Re: really slow PLLLasse Langwadt Christensen
|   |  ||| `- Re: really slow PLLbitrex
|   |  ||+- Re: really slow PLLDon Y
|   |  ||`* Re: really slow PLLMartin Brown
|   |  || `* Re: really slow PLLDon Y
|   |  ||  `* Re: really slow PLLJohn Walliker
|   |  ||   `- Re: really slow PLLDon Y
|   |  |`* Re: really slow PLLJohn Larkin
|   |  | `* Re: really slow PLLMartin Brown
|   |  |  `- Re: really slow PLLPhil Hobbs
|   |  `- Re: really slow PLLDon Y
|   +* Re: really slow PLLPhil Hobbs
|   |`* Re: really slow PLLbitrex
|   | `* Re: really slow PLLPhil Hobbs
|   |  `* Re: really slow PLLjlarkin
|   |   `* Re: really slow PLLLes Cargill
|   |    `* Re: really slow PLLjlarkin
|   |     `* Re: really slow PLLLes Cargill
|   |      +* Re: really slow PLLjlarkin
|   |      |`- Re: really slow PLLLes Cargill
|   |      `* Re: really slow PLLDon
|   |       `- Re: really slow PLLLes Cargill
|   `* Re: really slow PLLDon Y
|    +* Re: really slow PLLbitrex
|    |`- Re: really slow PLLDon Y
|    +* Re: really slow PLLDon
|    |`* Re: really slow PLLDon Y
|    | `* Re: really slow PLLDon
|    |  `* Re: really slow PLLDon Y
|    |   +* Re: really slow PLLDon
|    |   |`* Re: really slow PLLDon Y
|    |   | `* Re: really slow PLLDon
|    |   |  +- Re: really slow PLLDon Y
|    |   |  `* Re: really slow PLLClifford Heath
|    |   |   `- Re: really slow PLLGerhard Hoffmann
|    |   `* Re: really slow PLLLasse Langwadt Christensen
|    |    `* Re: really slow PLLJoe Gwinn
|    |     `* Re: really slow PLLDon Y
|    |      `* Re: really slow PLLLasse Langwadt Christensen
|    |       `* Re: really slow PLLDon Y
|    |        `* Re: really slow PLLLasse Langwadt Christensen
|    |         `* Re: really slow PLLDon Y
|    |          `- Re: really slow PLLDon Y
|    `* Re: really slow PLLjlarkin
|     +- Re: really slow PLLJan Panteltje
|     `* Re: really slow PLLJohn Walliker
|      +- Re: really slow PLLDon Y
|      `- Re: really slow PLLClifford Heath
+- Re: really slow PLLJan Panteltje
+* Re: really slow PLLGerhard Hoffmann
|`* Re: really slow PLLjlarkin
| +* Re: really slow PLLGerhard Hoffmann
| |+* Re: really slow PLLPhil Hobbs
| ||`* Re: really slow PLLGerhard Hoffmann
| || `* Re: really slow PLLPhil Hobbs
| ||  `* Re: really slow PLLClifford Heath
| ||   `* Re: really slow PLLMartin Brown
| ||    `* Re: really slow PLLPhil Hobbs
| ||     `* Re: really slow PLLJoe Gwinn
| ||      `* Re: really slow PLLGerhard Hoffmann
| ||       +* Re: really slow PLLJoe Gwinn
| ||       |+* Re: really slow PLLGerhard Hoffmann
| ||       ||`* Re: really slow PLLJoe Gwinn
| ||       || `* Re: really slow PLLPhil Hobbs
| ||       ||  `- Re: really slow PLLGerhard Hoffmann
| ||       |`* Re: really slow PLLPhil Hobbs
| ||       | `* Re: really slow PLLJoe Gwinn
| ||       |  `* Re: really slow PLLPhil Hobbs
| ||       |   `- Re: really slow PLLGerhard Hoffmann
| ||       `* Re: really slow PLLPhil Hobbs
| ||        +* Re: really slow PLLjlarkin
| ||        `* Re: really slow PLLMartin Brown
| |+- Re: really slow PLLJan Panteltje
| |`- Re: really slow PLLClifford Heath
| `* Re: really slow PLLCydrome Leader
+* Re: really slow PLLwhit3rd
+- Re: really slow PLLClive Arthur
+* Re: really slow PLLLasse Langwadt Christensen
+- Re: really slow PLLLes Cargill
+- Re: really slow PLLjlarkin
`- Re: really slow PLLJasen Betts

Pages:1234567
Re: really slow PLL

<uBdCK.53073$mY1.11490@fx01.iad>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=101907&group=sci.electronics.design#101907

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx01.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: really slow PLL
Content-Language: en-US
Newsgroups: sci.electronics.design
References: <qd2hdhhs6bnndjs4likrvlq9jt6q5deebo@4ax.com>
<daf0c8cf-07ea-241b-2e4e-bfe2bbaa6f63@electrooptical.net>
<pq5hdh9oeleu54rljjk3r1bk3vfgj9dni0@4ax.com> <tbbbvk$pta$1@gioia.aioe.org>
<T1dCK.48233$vd2.40244@fx39.iad>
<d3f52888-9988-4c6f-bf55-25cc748dc3a1n@googlegroups.com>
From: use...@example.net (bitrex)
In-Reply-To: <d3f52888-9988-4c6f-bf55-25cc748dc3a1n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 90
Message-ID: <uBdCK.53073$mY1.11490@fx01.iad>
X-Complaints-To: abuse@frugalusenet.com
NNTP-Posting-Date: Thu, 21 Jul 2022 14:42:34 UTC
Organization: frugalusenet - www.frugalusenet.com
Date: Thu, 21 Jul 2022 10:42:33 -0400
X-Received-Bytes: 4660
 by: bitrex - Thu, 21 Jul 2022 14:42 UTC

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.

Re: really slow PLL

<p6pidhpeh5efsh5ut6ec47v3unta38ald8@4ax.com>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=101908&group=sci.electronics.design#101908

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!aioe.org!news.mixmin.net!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!nntp.supernews.com!news.supernews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 21 Jul 2022 09:43:49 -0500
From: jlar...@highlandsniptechnology.com
Newsgroups: sci.electronics.design
Subject: Re: really slow PLL
Date: Thu, 21 Jul 2022 07:43:48 -0700
Message-ID: <p6pidhpeh5efsh5ut6ec47v3unta38ald8@4ax.com>
References: <qd2hdhhs6bnndjs4likrvlq9jt6q5deebo@4ax.com> <daf0c8cf-07ea-241b-2e4e-bfe2bbaa6f63@electrooptical.net> <pq5hdh9oeleu54rljjk3r1bk3vfgj9dni0@4ax.com> <8f21a4c4-bf22-2a5b-4355-ef5397fe86dc@electrooptical.net> <evdhdh9l1chbd0qh4et8cm2kt6hdmudufs@4ax.com> <2c736f29-6de2-32e7-d389-4b4c48b8600f@electrooptical.net>
X-Newsreader: Forte Agent 3.1/32.783
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 125
X-Trace: sv3-neRsgoKtlst7PXyYpbAF5gEERHPJLg6J40izdCzCkcZzeu70JujO6/hOfrGqpZ6UTv/rU+U9XlXYMNy!mWsBLZtfLBV0ic54t1vwtNZAv9myW7V8DOc+1Xl1n5ejNZ3DtsxYW+CSPD58zSrSzn8gzulNHaC7!+iky8w==
X-Complaints-To: www.supernews.com/docs/abuse.html
X-DMCA-Complaints-To: www.supernews.com/docs/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 6260
 by: jlar...@highlandsniptechnology.com - Thu, 21 Jul 2022 14:43 UTC

On Thu, 21 Jul 2022 09:27:39 -0400, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

>jlarkin@highlandsniptechnology.com wrote:
>> On Wed, 20 Jul 2022 20:28:35 -0400, Phil Hobbs
>> <pcdhSpamMeSenseless@electrooptical.net> wrote:
>>
>>> John Larkin wrote:
>>>> On Wed, 20 Jul 2022 19:32:20 -0400, Phil Hobbs
>>>> <pcdhSpamMeSenseless@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.
>>>>
>>>> If a follower is told to start locking, it could timestamp the first
>>>> incoming 1 PPS with a giant counter clocked by its local 40 MHz VCO.
>>>> If a later 1 PPS edge appears to arrive too soon, we could speed up
>>>> our VCXO by, say, 1 PPM, and vice versa. So longterm it walks into
>>>> alignment with the 1 PPS and eventually dithers a microsecond per
>>>> second. Noise on the coax gets fixed over time too.
>>>>
>>>> That's better than just measuring the 1 Hz period once a second,
>>>> tweaking the clock, and then throwing away that measurement. I want a
>>>> time lock, not a frequency lock.
>>>>
>>>
>>> Absolutely. The scary 152 dB number doesn't mean that doing something
>>> like that is automatically a bad idea.
>>>
>>> Being an old RF and ultrastable laser guy, though, it does make my ears
>>> perk up. ;)
>>>
>>> Cheers
>>>
>>> Phil Hobbs
>>
>> I like thermostats, single-bit-feedback control loops.
>>
>> We have a couple of boxes that do fan control based on interior
>> temperature. Once a second, if it's above the setpoint, ratchet fan
>> speed up some fixed amount, 1% maybe. If it's cooler than the
>> setpoint, step fan speed down. There's no acoustic drama and it's
>> perfectly stable.
>>
>> It dithers around the setpoint but nobody notices.
>>
>> This is immune to classic control theory so the concept annoys some
>> people but it works great.
>
>A real old time control guy like Tim Wescott would probably be a fan
>too--the great virtue of a bang-bang controller is that (as you say)
>it's highly resistant to variations in the _plant_.
>
>Your furnace doesn't go nuts when you have a Christmas party, even
>though all those people generate a lot of heat, and there's lots of
>opening and closing of doors and ovens.
>
>Cheers
>
>Phil Hobbs

My power supply box has 8 plugin modules of various types. Some don't
need much air but some really do. The two big fans are howlers at 48
volts.

Each module can present one bit to the motherboard software: I want
more air, or I don't. If any board wants more, ratchet the fans up a
bit. If none want more, jog the fans down.

Re: really slow PLL

<9kpidh99qveq7f4rv92p916ifaoc3ul77l@4ax.com>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=101910&group=sci.electronics.design#101910

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!paganini.bofh.team!weretis.net!feeder8.news.weretis.net!feeds.phibee-telecom.net!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!nntp.supernews.com!news.supernews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 21 Jul 2022 09:47:09 -0500
From: jlar...@highlandsniptechnology.com
Newsgroups: sci.electronics.design
Subject: Re: really slow PLL
Date: Thu, 21 Jul 2022 07:47:08 -0700
Message-ID: <9kpidh99qveq7f4rv92p916ifaoc3ul77l@4ax.com>
References: <qd2hdhhs6bnndjs4likrvlq9jt6q5deebo@4ax.com> <daf0c8cf-07ea-241b-2e4e-bfe2bbaa6f63@electrooptical.net> <pq5hdh9oeleu54rljjk3r1bk3vfgj9dni0@4ax.com> <tbbbvk$pta$1@gioia.aioe.org> <4bfb5c5a-33d0-e8e5-8b54-06503aeb8734@electrooptical.net>
X-Newsreader: Forte Agent 3.1/32.783
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Lines: 106
X-Trace: sv3-pR8Cr0MszIqx1m7J3taIViXaYzMogJNmMC4uXFkHpTW4b+52YXxOT8eiYhAY3MrPcIpSsW+BoR7XIUU!m7FMnzaUfCnyKJ2AAZqzLv+jPJemGhfkWIXPZANNB2bimAN1DI6zap/N9UGeazp2PAiZ32X2TFYn!j7y0ag==
X-Complaints-To: www.supernews.com/docs/abuse.html
X-DMCA-Complaints-To: www.supernews.com/docs/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 5875
 by: jlar...@highlandsniptechnology.com - Thu, 21 Jul 2022 14:47 UTC

On Thu, 21 Jul 2022 09:36:31 -0400, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

>Martin Brown wrote:
>> On 21/07/2022 01:22, John Larkin wrote:
>>> On Wed, 20 Jul 2022 19:32:20 -0400, Phil Hobbs
>>> <pcdhSpamMeSenseless@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?
>>
>>> If a follower is told to start locking, it could timestamp the first
>>> incoming 1 PPS with a giant counter clocked by its local 40 MHz VCO.
>>> If a later 1 PPS edge appears to arrive too soon, we could speed up
>>> our VCXO by, say, 1 PPM, and vice versa. So longterm it walks into
>>> alignment with the 1 PPS and eventually dithers a microsecond per
>>> second. Noise on the coax gets fixed over time too.
>>
>> Have a free running counter on each of the followers and use the value
>> of that after 1s, 10s, 100s to determine the correct tweak to apply
>> locally. Tweaks of 1ppm at a time is rather crude you should be able to
>> determine the right amount to tweak it by better than that.
>> (especially over longer timebases)
>>
>>> That's better than just measuring the 1 Hz period once a second,
>>> tweaking the clock, and then throwing away that measurement. I want a
>>> time lock, not a frequency lock.
>>
>> Then you probably want to measure the cumulative error over many
>> seconds. Each unit can work out how long it can free run without
>> exceeding tolerance once it has the rough and ready count from the first
>> second. After that you have a good idea of how many seconds you can free
>> run for without having any ambiguities from residual drift.
>>
>> This is an ancient trick from physics which avoids the smartest students
>> from having to laboriously count every pendulum swing when determining g
>> to maximum possible precision in a given time. It used to be (and
>> probably still is a favourite exam practical). Components needed are
>> very cheap and the whole thing is a good test of experimental technique.
>>
>
>It's not as efficient as 'dry labbing'. ;)

We cut our EE labs and went sailing or something, and faked all the
reports one night at the end of the semister. Of course we got As.

Re: really slow PLL

<6tpidh9jj9375ime66vfgr0uuonr42v7d6@4ax.com>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=101911&group=sci.electronics.design#101911

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border-2.nntp.ord.giganews.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!nntp.supernews.com!news.supernews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 21 Jul 2022 09:55:42 -0500
From: jlar...@highlandsniptechnology.com
Newsgroups: sci.electronics.design
Subject: Re: really slow PLL
Date: Thu, 21 Jul 2022 07:55:41 -0700
Message-ID: <6tpidh9jj9375ime66vfgr0uuonr42v7d6@4ax.com>
References: <qd2hdhhs6bnndjs4likrvlq9jt6q5deebo@4ax.com> <fb6d0d81-2d83-40aa-93ec-e8313f569653n@googlegroups.com> <f415cd82-40ba-412c-9226-b0bdf2385e7bn@googlegroups.com> <H9dCK.589973$5fVf.18746@fx09.iad> <YbdCK.589974$5fVf.167665@fx09.iad>
X-Newsreader: Forte Agent 3.1/32.783
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 45
X-Trace: sv3-mONlu9VVURnfnwMXd2u7/2tPydZ18HPP9ycBRgcZ9ZIRzchyIVrtr6XvZX4FSCh+Nlth8IYJMMd6Poe!JykmBvDSvLPfEJdpO5qlGuOCZ84MELoEAEE5F4LwdNKCqO10UEo5uHWobWaBaxUSDrxA630Dg5zU!rXWCRw==
X-Complaints-To: www.supernews.com/docs/abuse.html
X-DMCA-Complaints-To: www.supernews.com/docs/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 3234
 by: jlar...@highlandsniptechnology.com - Thu, 21 Jul 2022 14:55 UTC

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.

Re: really slow PLL

<ee412ac0-2f1b-b279-d7f6-120b05dfadac@electrooptical.net>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=101912&group=sci.electronics.design#101912

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border-2.nntp.ord.giganews.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!nntp.supernews.com!news.supernews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 21 Jul 2022 10:11:56 -0500
Subject: Re: really slow PLL
Newsgroups: sci.electronics.design
References: <qd2hdhhs6bnndjs4likrvlq9jt6q5deebo@4ax.com>
<daf0c8cf-07ea-241b-2e4e-bfe2bbaa6f63@electrooptical.net>
<pq5hdh9oeleu54rljjk3r1bk3vfgj9dni0@4ax.com>
<8f21a4c4-bf22-2a5b-4355-ef5397fe86dc@electrooptical.net>
<evdhdh9l1chbd0qh4et8cm2kt6hdmudufs@4ax.com>
<2c736f29-6de2-32e7-d389-4b4c48b8600f@electrooptical.net>
<p6pidhpeh5efsh5ut6ec47v3unta38ald8@4ax.com>
From: pcdhSpam...@electrooptical.net (Phil Hobbs)
Message-ID: <ee412ac0-2f1b-b279-d7f6-120b05dfadac@electrooptical.net>
Date: Thu, 21 Jul 2022 11:11:56 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.0
MIME-Version: 1.0
In-Reply-To: <p6pidhpeh5efsh5ut6ec47v3unta38ald8@4ax.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 146
X-Trace: sv3-XDCxdk6RKhCSxVPN+atk7asytl6BQAi++FEqBO8+MLvzDLz4pS4No6GGhL+Tw2zBF7ZPUMu2c/ojsVP!9P450dVCTpKTCnS06JbMXphH7T3ApRlFpiPRtpcgOXxy7ru/vVXnoeP6IjWaEpJ05i9mbdcJJUD+!UuIOp9GupNXuCczTwFo1dFmgyA==
X-Complaints-To: www.supernews.com/docs/abuse.html
X-DMCA-Complaints-To: www.supernews.com/docs/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 7210
 by: Phil Hobbs - Thu, 21 Jul 2022 15:11 UTC

jlarkin@highlandsniptechnology.com wrote:
> On Thu, 21 Jul 2022 09:27:39 -0400, Phil Hobbs
> <pcdhSpamMeSenseless@electrooptical.net> wrote:
>
>> jlarkin@highlandsniptechnology.com wrote:
>>> On Wed, 20 Jul 2022 20:28:35 -0400, Phil Hobbs
>>> <pcdhSpamMeSenseless@electrooptical.net> wrote:
>>>
>>>> John Larkin wrote:
>>>>> On Wed, 20 Jul 2022 19:32:20 -0400, Phil Hobbs
>>>>> <pcdhSpamMeSenseless@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.
>>>>>
>>>>> If a follower is told to start locking, it could timestamp the first
>>>>> incoming 1 PPS with a giant counter clocked by its local 40 MHz VCO.
>>>>> If a later 1 PPS edge appears to arrive too soon, we could speed up
>>>>> our VCXO by, say, 1 PPM, and vice versa. So longterm it walks into
>>>>> alignment with the 1 PPS and eventually dithers a microsecond per
>>>>> second. Noise on the coax gets fixed over time too.
>>>>>
>>>>> That's better than just measuring the 1 Hz period once a second,
>>>>> tweaking the clock, and then throwing away that measurement. I want a
>>>>> time lock, not a frequency lock.
>>>>>
>>>>
>>>> Absolutely. The scary 152 dB number doesn't mean that doing something
>>>> like that is automatically a bad idea.
>>>>
>>>> Being an old RF and ultrastable laser guy, though, it does make my ears
>>>> perk up. ;)
>>>>
>>>> Cheers
>>>>
>>>> Phil Hobbs
>>>
>>> I like thermostats, single-bit-feedback control loops.
>>>
>>> We have a couple of boxes that do fan control based on interior
>>> temperature. Once a second, if it's above the setpoint, ratchet fan
>>> speed up some fixed amount, 1% maybe. If it's cooler than the
>>> setpoint, step fan speed down. There's no acoustic drama and it's
>>> perfectly stable.
>>>
>>> It dithers around the setpoint but nobody notices.
>>>
>>> This is immune to classic control theory so the concept annoys some
>>> people but it works great.
>>
>> A real old time control guy like Tim Wescott would probably be a fan
>> too--the great virtue of a bang-bang controller is that (as you say)
>> it's highly resistant to variations in the _plant_.
>>
>> Your furnace doesn't go nuts when you have a Christmas party, even
>> though all those people generate a lot of heat, and there's lots of
>> opening and closing of doors and ovens.
>>
>> Cheers
>>
>> Phil Hobbs
>
> My power supply box has 8 plugin modules of various types. Some don't
> need much air but some really do. The two big fans are howlers at 48
> volts.
>
> Each module can present one bit to the motherboard software: I want
> more air, or I don't. If any board wants more, ratchet the fans up a
> bit. If none want more, jog the fans down.
>

Yup. We do the Class H supplies for our TEC driver boards like that--if
the linear amp rails, immediately jack up the supply by 0.5 V or so,
then gradually ramp it down again. We could use two ADC channels, of
course, but one comparator is simpler and works very well.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

Re: really slow PLL

<PaeCK.77418$Lx5.70440@fx02.iad>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=101913&group=sci.electronics.design#101913

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx02.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: really slow PLL
Content-Language: en-US
Newsgroups: sci.electronics.design
References: <qd2hdhhs6bnndjs4likrvlq9jt6q5deebo@4ax.com>
<daf0c8cf-07ea-241b-2e4e-bfe2bbaa6f63@electrooptical.net>
<pq5hdh9oeleu54rljjk3r1bk3vfgj9dni0@4ax.com> <tbbbvk$pta$1@gioia.aioe.org>
<T1dCK.48233$vd2.40244@fx39.iad>
<fef9280b-a7fb-b351-d65f-780d294f02a4@electrooptical.net>
From: use...@example.net (bitrex)
In-Reply-To: <fef9280b-a7fb-b351-d65f-780d294f02a4@electrooptical.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 97
Message-ID: <PaeCK.77418$Lx5.70440@fx02.iad>
X-Complaints-To: abuse@frugalusenet.com
NNTP-Posting-Date: Thu, 21 Jul 2022 15:22:23 UTC
Organization: frugalusenet - www.frugalusenet.com
Date: Thu, 21 Jul 2022 11:22:23 -0400
X-Received-Bytes: 4919
 by: bitrex - Thu, 21 Jul 2022 15:22 UTC

On 7/21/2022 10:26 AM, Phil Hobbs wrote:
> bitrex wrote:
>> 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
>>>> <pcdhSpamMeSenseless@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...superficially at least it sounds like he wants a sequencer.
>>
>> 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?
>>
>>
> Given that it's so simple to do it right, why not do that?
>
> Cheers
>
> Phil Hobbs
>

If there's a way to get by letting each box synchronize to GPS on its
own and then using some simple network protocol to sequence them that's
what I'd do, yeah.

Trying to get their system clocks to sync up over a cable makes me
uncomfortable, why do they need to share info about their inner lives.

Re: really slow PLL

<57000d39-6c42-4a2c-8190-ee4445df57d4n@googlegroups.com>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=101915&group=sci.electronics.design#101915

  copy link   Newsgroups: sci.electronics.design
X-Received: by 2002:a05:622a:14d0:b0:318:9744:842b with SMTP id u16-20020a05622a14d000b003189744842bmr33670430qtx.147.1658417463235;
Thu, 21 Jul 2022 08:31:03 -0700 (PDT)
X-Received: by 2002:a81:f84:0:b0:31e:7004:5db with SMTP id 126-20020a810f84000000b0031e700405dbmr7440577ywp.394.1658417462957;
Thu, 21 Jul 2022 08:31:02 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: sci.electronics.design
Date: Thu, 21 Jul 2022 08:31:02 -0700 (PDT)
In-Reply-To: <uBdCK.53073$mY1.11490@fx01.iad>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:8b0:fb4e:0:8286:f2ff:fe6b:6c87;
posting-account=de11ZAoAAACBQRb2jWnaIkHYK2q9mRvs
NNTP-Posting-Host: 2001:8b0:fb4e:0:8286:f2ff:fe6b:6c87
References: <qd2hdhhs6bnndjs4likrvlq9jt6q5deebo@4ax.com> <daf0c8cf-07ea-241b-2e4e-bfe2bbaa6f63@electrooptical.net>
<pq5hdh9oeleu54rljjk3r1bk3vfgj9dni0@4ax.com> <tbbbvk$pta$1@gioia.aioe.org>
<T1dCK.48233$vd2.40244@fx39.iad> <d3f52888-9988-4c6f-bf55-25cc748dc3a1n@googlegroups.com>
<uBdCK.53073$mY1.11490@fx01.iad>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <57000d39-6c42-4a2c-8190-ee4445df57d4n@googlegroups.com>
Subject: Re: really slow PLL
From: jrwalli...@gmail.com (John Walliker)
Injection-Date: Thu, 21 Jul 2022 15:31:03 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 5476
 by: John Walliker - Thu, 21 Jul 2022 15:31 UTC

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.

John

Re: really slow PLL

<BneCK.57862$iR.43468@fx44.iad>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=101916&group=sci.electronics.design#101916

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx44.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: really slow PLL
Content-Language: en-US
Newsgroups: sci.electronics.design
References: <qd2hdhhs6bnndjs4likrvlq9jt6q5deebo@4ax.com>
<fb6d0d81-2d83-40aa-93ec-e8313f569653n@googlegroups.com>
<f415cd82-40ba-412c-9226-b0bdf2385e7bn@googlegroups.com>
<H9dCK.589973$5fVf.18746@fx09.iad> <YbdCK.589974$5fVf.167665@fx09.iad>
<6tpidh9jj9375ime66vfgr0uuonr42v7d6@4ax.com>
From: use...@example.net (bitrex)
In-Reply-To: <6tpidh9jj9375ime66vfgr0uuonr42v7d6@4ax.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 57
Message-ID: <BneCK.57862$iR.43468@fx44.iad>
X-Complaints-To: abuse@frugalusenet.com
NNTP-Posting-Date: Thu, 21 Jul 2022 15:36:01 UTC
Organization: frugalusenet - www.frugalusenet.com
Date: Thu, 21 Jul 2022 11:36:01 -0400
X-Received-Bytes: 3622
 by: bitrex - Thu, 21 Jul 2022 15:36 UTC

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.

Re: really slow PLL

<7e922c2e-daea-bb7d-660b-c03ff01c3c80@electrooptical.net>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=101917&group=sci.electronics.design#101917

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: pcdhSpam...@electrooptical.net (Phil Hobbs)
Newsgroups: sci.electronics.design
Subject: Re: really slow PLL
Date: Thu, 21 Jul 2022 11:42:28 -0400
Organization: A noiseless patient Spider
Lines: 110
Message-ID: <7e922c2e-daea-bb7d-660b-c03ff01c3c80@electrooptical.net>
References: <qd2hdhhs6bnndjs4likrvlq9jt6q5deebo@4ax.com>
<daf0c8cf-07ea-241b-2e4e-bfe2bbaa6f63@electrooptical.net>
<pq5hdh9oeleu54rljjk3r1bk3vfgj9dni0@4ax.com> <tbbbvk$pta$1@gioia.aioe.org>
<T1dCK.48233$vd2.40244@fx39.iad>
<fef9280b-a7fb-b351-d65f-780d294f02a4@electrooptical.net>
<PaeCK.77418$Lx5.70440@fx02.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: reader01.eternal-september.org; posting-host="6972dd019c9dcf99f6ee19f703e5b3d7";
logging-data="2589537"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/pewJzHqwuq6P0OyOvJmGZ"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.0
Cancel-Lock: sha1:FxFhqg94ALkrCySIt08pGQ8KgzA=
In-Reply-To: <PaeCK.77418$Lx5.70440@fx02.iad>
 by: Phil Hobbs - Thu, 21 Jul 2022 15:42 UTC

bitrex wrote:
> On 7/21/2022 10:26 AM, Phil Hobbs wrote:
>> bitrex wrote:
>>> 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
>>>>> <pcdhSpamMeSenseless@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...superficially at least it sounds like he wants a sequencer.
>>>
>>> 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?
>>>
>>>
>> Given that it's so simple to do it right, why not do that?
>>
>> Cheers
>>
>> Phil Hobbs
>>
>
> If there's a way to get by letting each box synchronize to GPS on its
> own and then using some simple network protocol to sequence them that's
> what I'd do, yeah.
>
> Trying to get their system clocks to sync up over a cable makes me
> uncomfortable, why do they need to share info about their inner lives.

And to think you went to art school.

Cheers

Phil Hobbs

Re: really slow PLL

<unsidh1on6gt01bol5k0b8ev9gv8rdb95d@4ax.com>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=101918&group=sci.electronics.design#101918

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border-2.nntp.ord.giganews.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!nntp.supernews.com!news.supernews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 21 Jul 2022 10:44:35 -0500
From: jlar...@highlandsniptechnology.com
Newsgroups: sci.electronics.design
Subject: Re: really slow PLL
Date: Thu, 21 Jul 2022 08:44:34 -0700
Message-ID: <unsidh1on6gt01bol5k0b8ev9gv8rdb95d@4ax.com>
References: <qd2hdhhs6bnndjs4likrvlq9jt6q5deebo@4ax.com> <daf0c8cf-07ea-241b-2e4e-bfe2bbaa6f63@electrooptical.net> <pq5hdh9oeleu54rljjk3r1bk3vfgj9dni0@4ax.com> <8f21a4c4-bf22-2a5b-4355-ef5397fe86dc@electrooptical.net> <evdhdh9l1chbd0qh4et8cm2kt6hdmudufs@4ax.com> <2c736f29-6de2-32e7-d389-4b4c48b8600f@electrooptical.net> <p6pidhpeh5efsh5ut6ec47v3unta38ald8@4ax.com> <ee412ac0-2f1b-b279-d7f6-120b05dfadac@electrooptical.net>
X-Newsreader: Forte Agent 3.1/32.783
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 147
X-Trace: sv3-qBsI5hdsDs7Oyg+51PysZvYPzP6yX8aEB0FO1Dl7c3zbS9IAzhAAnuc+6zRLAj8II5qGdOxauWn02cd!yAfALQBtaOxtbA3UltFIHnalwcwD45lG73kD+jVLBjpqykykVNoAYxiVXl5b3npvKXgmp7bAEHVC!oeY0yA==
X-Complaints-To: www.supernews.com/docs/abuse.html
X-DMCA-Complaints-To: www.supernews.com/docs/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 7465
 by: jlar...@highlandsniptechnology.com - Thu, 21 Jul 2022 15:44 UTC

On Thu, 21 Jul 2022 11:11:56 -0400, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

>jlarkin@highlandsniptechnology.com wrote:
>> On Thu, 21 Jul 2022 09:27:39 -0400, Phil Hobbs
>> <pcdhSpamMeSenseless@electrooptical.net> wrote:
>>
>>> jlarkin@highlandsniptechnology.com wrote:
>>>> On Wed, 20 Jul 2022 20:28:35 -0400, Phil Hobbs
>>>> <pcdhSpamMeSenseless@electrooptical.net> wrote:
>>>>
>>>>> John Larkin wrote:
>>>>>> On Wed, 20 Jul 2022 19:32:20 -0400, Phil Hobbs
>>>>>> <pcdhSpamMeSenseless@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.
>>>>>>
>>>>>> If a follower is told to start locking, it could timestamp the first
>>>>>> incoming 1 PPS with a giant counter clocked by its local 40 MHz VCO.
>>>>>> If a later 1 PPS edge appears to arrive too soon, we could speed up
>>>>>> our VCXO by, say, 1 PPM, and vice versa. So longterm it walks into
>>>>>> alignment with the 1 PPS and eventually dithers a microsecond per
>>>>>> second. Noise on the coax gets fixed over time too.
>>>>>>
>>>>>> That's better than just measuring the 1 Hz period once a second,
>>>>>> tweaking the clock, and then throwing away that measurement. I want a
>>>>>> time lock, not a frequency lock.
>>>>>>
>>>>>
>>>>> Absolutely. The scary 152 dB number doesn't mean that doing something
>>>>> like that is automatically a bad idea.
>>>>>
>>>>> Being an old RF and ultrastable laser guy, though, it does make my ears
>>>>> perk up. ;)
>>>>>
>>>>> Cheers
>>>>>
>>>>> Phil Hobbs
>>>>
>>>> I like thermostats, single-bit-feedback control loops.
>>>>
>>>> We have a couple of boxes that do fan control based on interior
>>>> temperature. Once a second, if it's above the setpoint, ratchet fan
>>>> speed up some fixed amount, 1% maybe. If it's cooler than the
>>>> setpoint, step fan speed down. There's no acoustic drama and it's
>>>> perfectly stable.
>>>>
>>>> It dithers around the setpoint but nobody notices.
>>>>
>>>> This is immune to classic control theory so the concept annoys some
>>>> people but it works great.
>>>
>>> A real old time control guy like Tim Wescott would probably be a fan
>>> too--the great virtue of a bang-bang controller is that (as you say)
>>> it's highly resistant to variations in the _plant_.
>>>
>>> Your furnace doesn't go nuts when you have a Christmas party, even
>>> though all those people generate a lot of heat, and there's lots of
>>> opening and closing of doors and ovens.
>>>
>>> Cheers
>>>
>>> Phil Hobbs
>>
>> My power supply box has 8 plugin modules of various types. Some don't
>> need much air but some really do. The two big fans are howlers at 48
>> volts.
>>
>> Each module can present one bit to the motherboard software: I want
>> more air, or I don't. If any board wants more, ratchet the fans up a
>> bit. If none want more, jog the fans down.
>>
>
>Yup. We do the Class H supplies for our TEC driver boards like that--if
>the linear amp rails, immediately jack up the supply by 0.5 V or so,
>then gradually ramp it down again. We could use two ADC channels, of
>course, but one comparator is simpler and works very well.
>
>Cheers
>
>Phil Hobbs

A TEC driver doesn't mind a little lag on its supply rail being
ratcheted up. My boards, as they heat up, also don't mind a little lag
in the air flow being modulated. The fan control slew time can be in
the ballpark of the thermal time constants.

Each board will have one or more temp sensors, and a resident cal
table in eeprom that has the temperature targets. Simple.

Re: really slow PLL

<5atidhpvjlcboca3b0m4tare67i9jgd1cj@4ax.com>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=101919&group=sci.electronics.design#101919

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border-2.nntp.ord.giganews.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!nntp.supernews.com!news.supernews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 21 Jul 2022 10:53:21 -0500
From: jlar...@highlandsniptechnology.com
Newsgroups: sci.electronics.design
Subject: Re: really slow PLL
Date: Thu, 21 Jul 2022 08:53:19 -0700
Message-ID: <5atidhpvjlcboca3b0m4tare67i9jgd1cj@4ax.com>
References: <qd2hdhhs6bnndjs4likrvlq9jt6q5deebo@4ax.com> <daf0c8cf-07ea-241b-2e4e-bfe2bbaa6f63@electrooptical.net> <pq5hdh9oeleu54rljjk3r1bk3vfgj9dni0@4ax.com> <tbbbvk$pta$1@gioia.aioe.org> <T1dCK.48233$vd2.40244@fx39.iad> <fef9280b-a7fb-b351-d65f-780d294f02a4@electrooptical.net> <PaeCK.77418$Lx5.70440@fx02.iad> <7e922c2e-daea-bb7d-660b-c03ff01c3c80@electrooptical.net>
X-Newsreader: Forte Agent 3.1/32.783
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Lines: 124
X-Trace: sv3-FVXGr4cSJpLyJl6LNxCxcIJOoEH24DjXEOYyYkKtnmlCNl9QRktVkDyq5uGjKpHXqB4kTajjl2y6UqQ!Aljxm19krC6PHXx6D+lRRx9XK7bD89D0Az6YCwnnaFWDEBguDYKTbjnpllg9wZ6zvpuYPEXOARxK!OziZQQ==
X-Complaints-To: www.supernews.com/docs/abuse.html
X-DMCA-Complaints-To: www.supernews.com/docs/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 6063
 by: jlar...@highlandsniptechnology.com - Thu, 21 Jul 2022 15:53 UTC

On Thu, 21 Jul 2022 11:42:28 -0400, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

>bitrex wrote:
>> On 7/21/2022 10:26 AM, Phil Hobbs wrote:
>>> bitrex wrote:
>>>> 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
>>>>>> <pcdhSpamMeSenseless@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...superficially at least it sounds like he wants a sequencer.
>>>>
>>>> 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?
>>>>
>>>>
>>> Given that it's so simple to do it right, why not do that?
>>>
>>> Cheers
>>>
>>> Phil Hobbs
>>>
>>
>> If there's a way to get by letting each box synchronize to GPS on its
>> own and then using some simple network protocol to sequence them that's
>> what I'd do, yeah.
>>
>> Trying to get their system clocks to sync up over a cable makes me
>> uncomfortable, why do they need to share info about their inner lives.
>
>And to think you went to art school.
>
>Cheers
>
>Phil Hobbs

Mathematicians often like music. In my experience, music fandom is
negatively correlated to engineering design skill. Different brain
structure or something.

One other thing I see a lot is undue respect for standards. As in "you
can't do that because it violates SCPI standards." Where are the SCPI
Police when you need them?

Re: really slow PLL

<tbbspp$golj$1@solani.org>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=101920&group=sci.electronics.design#101920

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!reader5.news.weretis.net!news.solani.org!.POSTED!not-for-mail
From: dk4...@arcor.de (Gerhard Hoffmann)
Newsgroups: sci.electronics.design
Subject: Re: really slow PLL
Date: Thu, 21 Jul 2022 17:53:29 +0200
Message-ID: <tbbspp$golj$1@solani.org>
References: <qd2hdhhs6bnndjs4likrvlq9jt6q5deebo@4ax.com>
<tbap1m$h0d7$1@solani.org> <4edidhp1j5athn19ro297m6lkm21nba4ck@4ax.com>
<tbbi6s$ghm7$1@solani.org>
<749c3c03-5765-9bfe-a6e6-6b9be06fc84d@electrooptical.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 21 Jul 2022 15:53:29 -0000 (UTC)
Injection-Info: solani.org;
logging-data="549555"; mail-complaints-to="abuse@news.solani.org"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.9.1
Cancel-Lock: sha1:0CvqCp3OwSDFBzqBwbGaSnECFec=
In-Reply-To: <749c3c03-5765-9bfe-a6e6-6b9be06fc84d@electrooptical.net>
X-User-ID: eJwFwQkBwDAIA0BL4wkBOYMW/xJ6BwuJoQfCsdi15OTvHefqqIfWkbQFTWrZIKiCr83LmvcBEnIQVQ==
Content-Language: en-US
 by: Gerhard Hoffmann - Thu, 21 Jul 2022 15:53 UTC

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

Re: really slow PLL

<qmtidh5aif9l2kq09oielks7hnp91hl84g@4ax.com>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=101921&group=sci.electronics.design#101921

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.mixmin.net!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!nntp.supernews.com!news.supernews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 21 Jul 2022 11:09:02 -0500
From: jlar...@highlandsniptechnology.com
Newsgroups: sci.electronics.design
Subject: Re: really slow PLL
Date: Thu, 21 Jul 2022 09:09:01 -0700
Message-ID: <qmtidh5aif9l2kq09oielks7hnp91hl84g@4ax.com>
References: <qd2hdhhs6bnndjs4likrvlq9jt6q5deebo@4ax.com> <fb6d0d81-2d83-40aa-93ec-e8313f569653n@googlegroups.com> <f415cd82-40ba-412c-9226-b0bdf2385e7bn@googlegroups.com> <H9dCK.589973$5fVf.18746@fx09.iad> <YbdCK.589974$5fVf.167665@fx09.iad> <6tpidh9jj9375ime66vfgr0uuonr42v7d6@4ax.com> <BneCK.57862$iR.43468@fx44.iad>
X-Newsreader: Forte Agent 3.1/32.783
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 85
X-Trace: sv3-c0kM2zkndZaOZmRMbfrYbNChJwr+A9q4Sg4hzQ9Ma6yBKOvD1q2aUEv1KHbwRKEMTdBGXnJKTn3LxvS!WbOC1K9bGFpb5aGwqIw2QGayUBuvuzqehbMvFzWZj1Dzpx8AbFy0BMZqbDtpQwXWY7TIoapfmvBj!Q58Guw==
X-Complaints-To: www.supernews.com/docs/abuse.html
X-DMCA-Complaints-To: www.supernews.com/docs/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 5109
 by: jlar...@highlandsniptechnology.com - Thu, 21 Jul 2022 16:09 UTC

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.

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.

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

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

Re: really slow PLL

<JffCK.582999$X_i.553981@fx18.iad>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=101922&group=sci.electronics.design#101922

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx18.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: really slow PLL
Content-Language: en-US
Newsgroups: sci.electronics.design
References: <qd2hdhhs6bnndjs4likrvlq9jt6q5deebo@4ax.com>
<fb6d0d81-2d83-40aa-93ec-e8313f569653n@googlegroups.com>
<f415cd82-40ba-412c-9226-b0bdf2385e7bn@googlegroups.com>
<H9dCK.589973$5fVf.18746@fx09.iad> <YbdCK.589974$5fVf.167665@fx09.iad>
<6tpidh9jj9375ime66vfgr0uuonr42v7d6@4ax.com> <BneCK.57862$iR.43468@fx44.iad>
<qmtidh5aif9l2kq09oielks7hnp91hl84g@4ax.com>
From: use...@example.net (bitrex)
In-Reply-To: <qmtidh5aif9l2kq09oielks7hnp91hl84g@4ax.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 106
Message-ID: <JffCK.582999$X_i.553981@fx18.iad>
X-Complaints-To: abuse@frugalusenet.com
NNTP-Posting-Date: Thu, 21 Jul 2022 16:35:53 UTC
Organization: frugalusenet - www.frugalusenet.com
Date: Thu, 21 Jul 2022 12:35:52 -0400
X-Received-Bytes: 5756
 by: bitrex - Thu, 21 Jul 2022 16:35 UTC

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 :-(

Re: really slow PLL

<e9f067f2-0482-e037-635a-1fe45f43849e@electrooptical.net>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=101926&group=sci.electronics.design#101926

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: pcdhSpam...@electrooptical.net (Phil Hobbs)
Newsgroups: sci.electronics.design
Subject: Re: really slow PLL
Date: Thu, 21 Jul 2022 13:10:22 -0400
Organization: A noiseless patient Spider
Lines: 57
Message-ID: <e9f067f2-0482-e037-635a-1fe45f43849e@electrooptical.net>
References: <qd2hdhhs6bnndjs4likrvlq9jt6q5deebo@4ax.com>
<tbap1m$h0d7$1@solani.org> <4edidhp1j5athn19ro297m6lkm21nba4ck@4ax.com>
<tbbi6s$ghm7$1@solani.org>
<749c3c03-5765-9bfe-a6e6-6b9be06fc84d@electrooptical.net>
<tbbspp$golj$1@solani.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: reader01.eternal-september.org; posting-host="6972dd019c9dcf99f6ee19f703e5b3d7";
logging-data="2633887"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+KU5WaQ2O/WzxMbHq5JrHu"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.0
Cancel-Lock: sha1:AdLVYRyRAPeDFNzatQluoM8Gs2U=
In-Reply-To: <tbbspp$golj$1@solani.org>
 by: Phil Hobbs - Thu, 21 Jul 2022 17:10 UTC

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

It's on P. 341 of BEOS 3e and P. 385 of BEOS 2e for those who have copies.

I don't have a scheme right handy, but it works at DC for measuring
noise by the correlation method, where N meters get you 20 log N - 6 dB
improvement.

It seems like it might be worth a bit of chasing, especially (as you
say) in the regime where any improvement becomes very difficult to get.
It would make an interesting paper if nobody's done it already.

Cheers

Phil Hobbs
--

Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

Re: really slow PLL

<tbc1vh$1dqi$2@gioia.aioe.org>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=101928&group=sci.electronics.design#101928

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!aioe.org!U54xAdP7pvGKboowhQIuJQ.user.46.165.242.75.POSTED!not-for-mail
From: '''newsp...@nonad.co.uk (Martin Brown)
Newsgroups: sci.electronics.design
Subject: Re: really slow PLL
Date: Thu, 21 Jul 2022 18:21:51 +0100
Organization: Aioe.org NNTP Server
Message-ID: <tbc1vh$1dqi$2@gioia.aioe.org>
References: <qd2hdhhs6bnndjs4likrvlq9jt6q5deebo@4ax.com>
<daf0c8cf-07ea-241b-2e4e-bfe2bbaa6f63@electrooptical.net>
<pq5hdh9oeleu54rljjk3r1bk3vfgj9dni0@4ax.com> <tbbbvk$pta$1@gioia.aioe.org>
<T1dCK.48233$vd2.40244@fx39.iad>
<d3f52888-9988-4c6f-bf55-25cc748dc3a1n@googlegroups.com>
<uBdCK.53073$mY1.11490@fx01.iad>
<57000d39-6c42-4a2c-8190-ee4445df57d4n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="46930"; posting-host="U54xAdP7pvGKboowhQIuJQ.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Content-Language: en-GB
X-Notice: Filtered by postfilter v. 0.9.2
 by: Martin Brown - Thu, 21 Jul 2022 17:21 UTC

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

--
Regards,
Martin Brown

Re: really slow PLL

<64e1baa2-ff15-4a92-90d8-50cc1f34a8e0n@googlegroups.com>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=101931&group=sci.electronics.design#101931

  copy link   Newsgroups: sci.electronics.design
X-Received: by 2002:a05:622a:11cb:b0:31f:e7e:3fb8 with SMTP id n11-20020a05622a11cb00b0031f0e7e3fb8mr3820074qtk.625.1658424644658;
Thu, 21 Jul 2022 10:30:44 -0700 (PDT)
X-Received: by 2002:a81:5d05:0:b0:31c:e010:fbc with SMTP id
r5-20020a815d05000000b0031ce0100fbcmr47569875ywb.381.1658424644425; Thu, 21
Jul 2022 10:30:44 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: sci.electronics.design
Date: Thu, 21 Jul 2022 10:30:44 -0700 (PDT)
In-Reply-To: <qd2hdhhs6bnndjs4likrvlq9jt6q5deebo@4ax.com>
Injection-Info: google-groups.googlegroups.com; posting-host=94.145.255.232; posting-account=mW5JKwkAAAAMyuWOVeLp8yffyAkVx0g7
NNTP-Posting-Host: 94.145.255.232
References: <qd2hdhhs6bnndjs4likrvlq9jt6q5deebo@4ax.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <64e1baa2-ff15-4a92-90d8-50cc1f34a8e0n@googlegroups.com>
Subject: Re: really slow PLL
From: langw...@fonz.dk (Lasse Langwadt Christensen)
Injection-Date: Thu, 21 Jul 2022 17:30:44 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2012
 by: Lasse Langwadt Chris - Thu, 21 Jul 2022 17:30 UTC

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

Re: really slow PLL

<ydgCK.195059$9j2.151333@fx33.iad>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=101933&group=sci.electronics.design#101933

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx33.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: really slow PLL
Content-Language: en-US
Newsgroups: sci.electronics.design
References: <qd2hdhhs6bnndjs4likrvlq9jt6q5deebo@4ax.com>
<daf0c8cf-07ea-241b-2e4e-bfe2bbaa6f63@electrooptical.net>
<pq5hdh9oeleu54rljjk3r1bk3vfgj9dni0@4ax.com> <tbbbvk$pta$1@gioia.aioe.org>
<T1dCK.48233$vd2.40244@fx39.iad>
<d3f52888-9988-4c6f-bf55-25cc748dc3a1n@googlegroups.com>
<uBdCK.53073$mY1.11490@fx01.iad>
<57000d39-6c42-4a2c-8190-ee4445df57d4n@googlegroups.com>
<tbc1vh$1dqi$2@gioia.aioe.org>
From: use...@example.net (bitrex)
In-Reply-To: <tbc1vh$1dqi$2@gioia.aioe.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 132
Message-ID: <ydgCK.195059$9j2.151333@fx33.iad>
X-Complaints-To: abuse@frugalusenet.com
NNTP-Posting-Date: Thu, 21 Jul 2022 17:41:50 UTC
Organization: frugalusenet - www.frugalusenet.com
Date: Thu, 21 Jul 2022 13:41:50 -0400
X-Received-Bytes: 6918
 by: bitrex - Thu, 21 Jul 2022 17:41 UTC

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.

Re: really slow PLL

<PggCK.58147$sZ1.12438@fx07.iad>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=101934&group=sci.electronics.design#101934

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx07.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: really slow PLL
Content-Language: en-US
Newsgroups: sci.electronics.design
References: <qd2hdhhs6bnndjs4likrvlq9jt6q5deebo@4ax.com>
<daf0c8cf-07ea-241b-2e4e-bfe2bbaa6f63@electrooptical.net>
<pq5hdh9oeleu54rljjk3r1bk3vfgj9dni0@4ax.com> <tbbbvk$pta$1@gioia.aioe.org>
<T1dCK.48233$vd2.40244@fx39.iad>
<d3f52888-9988-4c6f-bf55-25cc748dc3a1n@googlegroups.com>
<uBdCK.53073$mY1.11490@fx01.iad>
<57000d39-6c42-4a2c-8190-ee4445df57d4n@googlegroups.com>
<tbc1vh$1dqi$2@gioia.aioe.org> <ydgCK.195059$9j2.151333@fx33.iad>
From: use...@example.net (bitrex)
In-Reply-To: <ydgCK.195059$9j2.151333@fx33.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 139
Message-ID: <PggCK.58147$sZ1.12438@fx07.iad>
X-Complaints-To: abuse@frugalusenet.com
NNTP-Posting-Date: Thu, 21 Jul 2022 17:45:19 UTC
Organization: frugalusenet - www.frugalusenet.com
Date: Thu, 21 Jul 2022 13:45:19 -0400
X-Received-Bytes: 7131
 by: bitrex - Thu, 21 Jul 2022 17:45 UTC

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.

Re: really slow PLL

<02da1bf2-6083-4416-bb72-acad0e8c36ben@googlegroups.com>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=101936&group=sci.electronics.design#101936

  copy link   Newsgroups: sci.electronics.design
X-Received: by 2002:a05:620a:2890:b0:6b2:7363:1472 with SMTP id j16-20020a05620a289000b006b273631472mr30002547qkp.697.1658426488724;
Thu, 21 Jul 2022 11:01:28 -0700 (PDT)
X-Received: by 2002:a05:6902:18b:b0:66f:deff:5cbe with SMTP id
t11-20020a056902018b00b0066fdeff5cbemr33924402ybh.165.1658426488419; Thu, 21
Jul 2022 11:01:28 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: sci.electronics.design
Date: Thu, 21 Jul 2022 11:01:28 -0700 (PDT)
In-Reply-To: <PggCK.58147$sZ1.12438@fx07.iad>
Injection-Info: google-groups.googlegroups.com; posting-host=94.145.255.232; posting-account=mW5JKwkAAAAMyuWOVeLp8yffyAkVx0g7
NNTP-Posting-Host: 94.145.255.232
References: <qd2hdhhs6bnndjs4likrvlq9jt6q5deebo@4ax.com> <daf0c8cf-07ea-241b-2e4e-bfe2bbaa6f63@electrooptical.net>
<pq5hdh9oeleu54rljjk3r1bk3vfgj9dni0@4ax.com> <tbbbvk$pta$1@gioia.aioe.org>
<T1dCK.48233$vd2.40244@fx39.iad> <d3f52888-9988-4c6f-bf55-25cc748dc3a1n@googlegroups.com>
<uBdCK.53073$mY1.11490@fx01.iad> <57000d39-6c42-4a2c-8190-ee4445df57d4n@googlegroups.com>
<tbc1vh$1dqi$2@gioia.aioe.org> <ydgCK.195059$9j2.151333@fx33.iad> <PggCK.58147$sZ1.12438@fx07.iad>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <02da1bf2-6083-4416-bb72-acad0e8c36ben@googlegroups.com>
Subject: Re: really slow PLL
From: langw...@fonz.dk (Lasse Langwadt Christensen)
Injection-Date: Thu, 21 Jul 2022 18:01:28 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 8051
 by: Lasse Langwadt Chris - Thu, 21 Jul 2022 18:01 UTC

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.


Click here to read the complete article
Re: really slow PLL

<xEgCK.416473$ssF.95438@fx14.iad>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=101938&group=sci.electronics.design#101938

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx14.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: really slow PLL
Content-Language: en-US
Newsgroups: sci.electronics.design
References: <qd2hdhhs6bnndjs4likrvlq9jt6q5deebo@4ax.com>
<daf0c8cf-07ea-241b-2e4e-bfe2bbaa6f63@electrooptical.net>
<pq5hdh9oeleu54rljjk3r1bk3vfgj9dni0@4ax.com> <tbbbvk$pta$1@gioia.aioe.org>
<T1dCK.48233$vd2.40244@fx39.iad>
<d3f52888-9988-4c6f-bf55-25cc748dc3a1n@googlegroups.com>
<uBdCK.53073$mY1.11490@fx01.iad>
<57000d39-6c42-4a2c-8190-ee4445df57d4n@googlegroups.com>
<tbc1vh$1dqi$2@gioia.aioe.org> <ydgCK.195059$9j2.151333@fx33.iad>
<PggCK.58147$sZ1.12438@fx07.iad>
<02da1bf2-6083-4416-bb72-acad0e8c36ben@googlegroups.com>
From: use...@example.net (bitrex)
In-Reply-To: <02da1bf2-6083-4416-bb72-acad0e8c36ben@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 148
Message-ID: <xEgCK.416473$ssF.95438@fx14.iad>
X-Complaints-To: abuse@frugalusenet.com
NNTP-Posting-Date: Thu, 21 Jul 2022 18:10:37 UTC
Organization: frugalusenet - www.frugalusenet.com
Date: Thu, 21 Jul 2022 14:10:37 -0400
X-Received-Bytes: 7894
 by: bitrex - Thu, 21 Jul 2022 18:10 UTC

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


Click here to read the complete article
Re: really slow PLL

<tbc6if$2hlq9$2@dont-email.me>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=101942&group=sci.electronics.design#101942

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: pNaonStp...@yahoo.com (Jan Panteltje)
Newsgroups: sci.electronics.design
Subject: Re: really slow PLL
Date: Thu, 21 Jul 2022 18:29:46 GMT
Organization: A noiseless patient Spider
Lines: 42
Message-ID: <tbc6if$2hlq9$2@dont-email.me>
References: <qd2hdhhs6bnndjs4likrvlq9jt6q5deebo@4ax.com> <tbap1m$h0d7$1@solani.org> <4edidhp1j5athn19ro297m6lkm21nba4ck@4ax.com> <tbbi6s$ghm7$1@solani.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 21 Jul 2022 18:40:20 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="b6d152c22b8fa40370b05f83df7a23af";
logging-data="2676553"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18cYke4V6AcY4yx7lWge0jew5dYsc/NJv8="
User-Agent: NewsFleX-1.5.7.5 (Linux-2.6.37.6)
Cancel-Lock: sha1:j6IZVRCujWL4+UdlLeOaNYQ4FeA=
X-Newsreader-location: NewsFleX-1.5.7.5 (c) 'LIGHTSPEED' off line news reader for the Linux platform
NewsFleX homepage: http://www.panteltje.com/panteltje/newsflex/ and ftp download ftp://sunsite.unc.edu/pub/linux/system/news/readers/
 by: Jan Panteltje - Thu, 21 Jul 2022 18:29 UTC

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

Re: really slow PLL

<tbc6ik$2hlq9$3@dont-email.me>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=101943&group=sci.electronics.design#101943

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: pNaonStp...@yahoo.com (Jan Panteltje)
Newsgroups: sci.electronics.design
Subject: Re: really slow PLL
Date: Thu, 21 Jul 2022 18:29:46 GMT
Organization: A noiseless patient Spider
Lines: 20
Message-ID: <tbc6ik$2hlq9$3@dont-email.me>
References: <qd2hdhhs6bnndjs4likrvlq9jt6q5deebo@4ax.com> <fb6d0d81-2d83-40aa-93ec-e8313f569653n@googlegroups.com> <f415cd82-40ba-412c-9226-b0bdf2385e7bn@googlegroups.com> <H9dCK.589973$5fVf.18746@fx09.iad> <YbdCK.589974$5fVf.167665@fx09.iad> <6tpidh9jj9375ime66vfgr0uuonr42v7d6@4ax.com> <BneCK.57862$iR.43468@fx44.iad> <qmtidh5aif9l2kq09oielks7hnp91hl84g@4ax.com> <JffCK.582999$X_i.553981@fx18.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 21 Jul 2022 18:40:21 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="b6d152c22b8fa40370b05f83df7a23af";
logging-data="2676553"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/TKNizV8pG6qI6tnzdNP+bhw5PqMCt0jo="
User-Agent: NewsFleX-1.5.7.5 (Linux-2.6.37.6)
Cancel-Lock: sha1:N0xExN5+g+4PcfvR9pRAtQ37DdQ=
X-Newsreader-location: NewsFleX-1.5.7.5 (c) 'LIGHTSPEED' off line news reader for the Linux platform
NewsFleX homepage: http://www.panteltje.com/panteltje/newsflex/ and ftp download ftp://sunsite.unc.edu/pub/linux/system/news/readers/
 by: Jan Panteltje - Thu, 21 Jul 2022 18:29 UTC

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

Re: really slow PLL

<NahCK.583426$X_i.319027@fx18.iad>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=101945&group=sci.electronics.design#101945

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx18.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: really slow PLL
Content-Language: en-US
Newsgroups: sci.electronics.design
References: <qd2hdhhs6bnndjs4likrvlq9jt6q5deebo@4ax.com>
<fb6d0d81-2d83-40aa-93ec-e8313f569653n@googlegroups.com>
<f415cd82-40ba-412c-9226-b0bdf2385e7bn@googlegroups.com>
<H9dCK.589973$5fVf.18746@fx09.iad> <YbdCK.589974$5fVf.167665@fx09.iad>
<6tpidh9jj9375ime66vfgr0uuonr42v7d6@4ax.com> <BneCK.57862$iR.43468@fx44.iad>
<qmtidh5aif9l2kq09oielks7hnp91hl84g@4ax.com>
<JffCK.582999$X_i.553981@fx18.iad> <tbc6ik$2hlq9$3@dont-email.me>
From: use...@example.net (bitrex)
In-Reply-To: <tbc6ik$2hlq9$3@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 46
Message-ID: <NahCK.583426$X_i.319027@fx18.iad>
X-Complaints-To: abuse@frugalusenet.com
NNTP-Posting-Date: Thu, 21 Jul 2022 18:47:09 UTC
Organization: frugalusenet - www.frugalusenet.com
Date: Thu, 21 Jul 2022 14:47:09 -0400
X-Received-Bytes: 3070
 by: bitrex - Thu, 21 Jul 2022 18:47 UTC

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>

Re: really slow PLL

<tbcpqo$f7c$1@reader2.panix.com>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=101966&group=sci.electronics.design#101966

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!panix!.POSTED.panix3.panix.com!not-for-mail
From: prese...@MUNGEpanix.com (Cydrome Leader)
Newsgroups: sci.electronics.design
Subject: Re: really slow PLL
Date: Fri, 22 Jul 2022 00:08:56 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <tbcpqo$f7c$1@reader2.panix.com>
References: <qd2hdhhs6bnndjs4likrvlq9jt6q5deebo@4ax.com> <tbap1m$h0d7$1@solani.org> <4edidhp1j5athn19ro297m6lkm21nba4ck@4ax.com>
Injection-Date: Fri, 22 Jul 2022 00:08:56 -0000 (UTC)
Injection-Info: reader2.panix.com; posting-host="panix3.panix.com:166.84.1.3";
logging-data="15596"; mail-complaints-to="abuse@panix.com"
User-Agent: tin/2.6.0-20210823 ("Coleburn") (NetBSD/9.2 (amd64))
 by: Cydrome Leader - Fri, 22 Jul 2022 00:08 UTC

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


tech / sci.electronics.design / Re: really slow PLL

Pages:1234567
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor