• Re: really slow PLL

    From Phil Hobbs@21:1/5 to John Larkin on Wed Jul 20 19:32:20 2022
    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.

    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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to All on Wed Jul 20 16:20:57 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to John Larkin on Wed Jul 20 20:28:35 2022
    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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to pcdhSpamMeSenseless@electrooptical. on Wed Jul 20 17:22:49 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From bitrex@21:1/5 to John Larkin on Wed Jul 20 21:49:32 2022
    On 7/20/2022 8:22 PM, 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.

    It sounds like you're looking for a protocol like DMX if what you want
    is to trigger sequences of events across boxes to within a millisecond,
    I don't understand what this lock-the-40 MHz across boxes is about.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to bitrex on Wed Jul 20 19:35:13 2022
    On Wed, 20 Jul 2022 21:49:32 -0400, bitrex <user@example.net> wrote:

    On 7/20/2022 8:22 PM, 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.

    It sounds like you're looking for a protocol like DMX if what you want
    is to trigger sequences of events across boxes to within a millisecond,
    I don't understand what this lock-the-40 MHz across boxes is about.

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



    Each box runs a bunch of timed processes. If they are triggered to
    start together, I don't want their timings to drift apart. Locking
    their clocks works.

    My loop will also lock my boxes to a 1 PPS GPS source, so we can
    synchronize within a bigger system.

    It's easy to explain 1 PPS pulses on BNC connectors.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to pcdhSpamMeSenseless@electrooptical. on Wed Jul 20 19:28:25 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gerhard Hoffmann@21:1/5 to All on Thu Jul 21 07:43:18 2022
    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.

    One needs at least reception of 4 sats to get a set of (x, y, z,
    t) that fits together, usually more. Once one has a lock to
    one sat, it is possible to get the data of the current
    constellation of all sats. That helps to speed up the lock
    to the others by providing a guess of a better starting point
    for the search.

    There is still a long way from synced polynomials to a good fix,
    for example removal of the Faraday effect by comparing the
    flight time difference for sats on different frequency bands.

    95% of a GPS receiver is software. The 1PPS out of a typical
    GPS receiver used to be only a port bit of the CPU, synchronous
    to the second only in the very long run.

    If the receiver delivers a nice 10 MHz, the CPU has better
    information to adjust it.

    Gerhard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jan Panteltje@21:1/5 to jlarkin@highland_atwork_technology. on Thu Jul 21 05:24:55 2022
    On a sunny day (Wed, 20 Jul 2022 16:20:57 -0700) it happened John Larkin <jlarkin@highland_atwork_technology.com> wrote in <qd2hdhhs6bnndjs4likrvlq9jt6q5deebo@4ax.com>:



    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.

    So why not use a RGB 24 bit 0xffffff master clock board that drives all slave modules
    those then need no local oscillator.
    For event 'sync' sent a DC step every now and then on the same
    coax and filter it out at the slave sides, to make the slaves jump to action.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From whit3rd@21:1/5 to John Larkin on Wed Jul 20 23:49:40 2022
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Walliker@21:1/5 to All on Thu Jul 21 01:33:22 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to John Larkin on Thu Jul 21 12:06:26 2022
    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.

    --
    Regards,
    Martin Brown

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Clive Arthur@21:1/5 to John Larkin on Thu Jul 21 12:29:10 2022
    On 21/07/2022 00:20, 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.

    Each box has a 40.0something MHz oscillator. Some simple logic triggers
    on the 1 second GPS pulse and allows 40 million of these clocks through
    to the rest of the circuit, then waits for the next pulse, rinse and repeat.

    Of course, this will only work in circumstances where it's ok to stop
    for a few cycles every second.

    --
    Cheers
    Clive

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to '''newspam'''@nonad.co.uk on Thu Jul 21 04:42:07 2022
    On Thu, 21 Jul 2022 12:06:26 +0100, Martin Brown
    <'''newspam'''@nonad.co.uk> 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)

    I wouldn't expect my VCXO to be more than 10 PPM off at the start of
    the lock request. So I can walk it to within 1 PPM, namely 1
    microsecond error, in at most 10 seconds using 1 PPM jogs. If the osc
    were 50 PPM off, it would take 50 seconds to catch up to the external
    pulse.



    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.

    Yes, I don't want to measure period once a second. I want to compare
    time alignment forever after receiving the first 1 pps pulse.

    It's actually simple: first received pulse, start a mod 40 million
    counter. Every time it rolls over, do an early/late compare to the 1
    PPS input, and jog the 40 MHz VCXO 1 PPM in the right direction.

    The compare is a dflop, d is the msb of the counter, clock is the 1
    PPS input. Occasional metastability is fine; it indicates success.

    It doesn't even need to be a 40 million counter. Something a fraction
    of that will do. 10,000 maybe.

    Maybe the counter can just free-run, never get initialized. Gotta do
    the math on that after I wake up.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to All on Thu Jul 21 04:19:14 2022
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to All on Thu Jul 21 04:17:14 2022
    On Wed, 20 Jul 2022 23:49:40 -0700 (PDT), whit3rd <whit3rd@gmail.com>
    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?

    It's actually a time lock problem. If a follower box starts up and
    sees its first 1 PPS input, it can thereafter declare 1 PPS internal
    events, based on its local VCO, and then do successive early/late
    comparisons to the external pulses. And trim its VCXO accordingly.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gerhard Hoffmann@21:1/5 to All on Thu Jul 21 14:52:44 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to Martin Brown on Thu Jul 21 09:36:31 2022
    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'. ;)

    The tradeoffs are sort of different when you have a $3 CPLD watching
    things rather than a student.

    Cheers

    Phil Hobbs
    (who didn't work that cheap even back when he was a student)

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to jlarkin@highlandsniptechnology.com on Thu Jul 21 09:27:39 2022
    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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From bitrex@21:1/5 to John Walliker on Thu Jul 21 10:12:54 2022
    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.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From bitrex@21:1/5 to Martin Brown on Thu Jul 21 10:04:35 2022
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From bitrex@21:1/5 to bitrex on Thu Jul 21 10:15:20 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to Gerhard Hoffmann on Thu Jul 21 10:15:49 2022
    Gerhard Hoffmann wrote:
    Am 21.07.22 um 13:19 schrieb jlarkin@highlandsniptechnology.com:


    Where does the 10 MHz come from?

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

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

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Thu Jul 21 07:21:21 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to bitrex on Thu Jul 21 10:26:07 2022
    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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From bitrex@21:1/5 to Lasse Langwadt Christensen on Thu Jul 21 10:42:33 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to pcdhSpamMeSenseless@electrooptical. on Thu Jul 21 07:43:48 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to pcdhSpamMeSenseless@electrooptical. on Thu Jul 21 07:47:08 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to bitrex on Thu Jul 21 07:55:41 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to jlarkin@highlandsniptechnology.com on Thu Jul 21 11:11:56 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From bitrex@21:1/5 to jlarkin@highlandsniptechnology.com on Thu Jul 21 11:36:01 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From bitrex@21:1/5 to Phil Hobbs on Thu Jul 21 11:22:23 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Walliker@21:1/5 to bitrex on Thu Jul 21 08:31:02 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to bitrex on Thu Jul 21 11:42:28 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to pcdhSpamMeSenseless@electrooptical. on Thu Jul 21 08:44:34 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gerhard Hoffmann@21:1/5 to All on Thu Jul 21 17:53:29 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to pcdhSpamMeSenseless@electrooptical. on Thu Jul 21 08:53:19 2022
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to bitrex on Thu Jul 21 09:09:01 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From bitrex@21:1/5 to jlarkin@highlandsniptechnology.com on Thu Jul 21 12:35:52 2022
    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 :-(

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to Gerhard Hoffmann on Thu Jul 21 13:10:22 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to John Walliker on Thu Jul 21 18:21:51 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Thu Jul 21 10:30:44 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From bitrex@21:1/5 to Martin Brown on Thu Jul 21 13:41:50 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From bitrex@21:1/5 to bitrex on Thu Jul 21 13:45:19 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Thu Jul 21 11:01:28 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From bitrex@21:1/5 to Lasse Langwadt Christensen on Thu Jul 21 14:10:37 2022
    On 7/21/2022 2:01 PM, Lasse Langwadt Christensen wrote:
    torsdag den 21. juli 2022 kl. 19.45.26 UTC+2 skrev bitrex:
    On 7/21/2022 1:41 PM, bitrex wrote:
    On 7/21/2022 1:21 PM, Martin Brown wrote:
    On 21/07/2022 16:31, John Walliker wrote:
    On Thursday, 21 July 2022 at 15:42:40 UTC+1, bitrex wrote:
    On 7/21/2022 10:21 AM, Lasse Langwadt Christensen wrote:
    torsdag den 21. juli 2022 kl. 16.04.42 UTC+2 skrev bitrex:
    On 7/21/2022 7:06 AM, Martin Brown wrote:
    On 21/07/2022 01:22, John Larkin wrote:
    On Wed, 20 Jul 2022 19:32:20 -0400, Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    John Larkin wrote:


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

    I can daisy-chain several boxes with BNC cables and tees. >>>>>>>>>>>>
    Each box has a 40 MHz VCXO and I want to phase-lock them, or >>>>>>>>>>>> at least
    time-align them to always be the same within a few microseconds, >>>>>>>>>>>> longterm.

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

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

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

    The PLL algorithm might be interesting.


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

    20 log(40e6) = 152 dB

    higher phase noise than the lockee.

    GPS has that problem too.


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

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

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

    Cheers

    Phil Hobbs

    Each box is basically a multichannel power supply, but channels >>>>>>>>>> can be
    programmed to do stuff in timed sequences. I want different box >>>>>>>>>> outputs to time align within, say, one millisecond longterm once >>>>>>>>>> programs are kicked off together. So, many microseconds of >>>>>>>>>> equivalent
    RMS phase noise is OK as long as we stay time aligned longterm. >>>>>>>>>
    You really need to define longterm before the problem becomes well >>>>>>>>> posed. Do you mean hours, days, weeks or months of runtime?

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

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

    It is literally good enough for rock & roll, but whether it's good >>>>>> enough for power supply sequencing IDK, there is gonna be some latency. >>>>>>
    HP used to have GPIB on their power supplies, I've never used it but I >>>>>> expect it wasn't really useful for tight synchronization.

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

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

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

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

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

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

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



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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jan Panteltje@21:1/5 to dk4xp@arcor.de on Thu Jul 21 18:29:46 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jan Panteltje@21:1/5 to user@example.net on Thu Jul 21 18:29:46 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From bitrex@21:1/5 to Jan Panteltje on Thu Jul 21 14:47:09 2022
    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>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Cydrome Leader@21:1/5 to jlarkin@highlandsniptechnology.com on Fri Jul 22 00:08:56 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to bitrex on Thu Jul 21 17:44:29 2022
    On 7/21/2022 10:41 AM, bitrex wrote:
    The cables and connectors could only be described as a bit clunky!
    They really didn't get on with metal swarf being around but were OK in clean >> dry electronics/physics labs - much less so in chemistry ones...

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

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

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

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

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

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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to John Walliker on Thu Jul 21 17:46:29 2022
    On 7/21/2022 8:31 AM, John Walliker wrote:
    On Thursday, 21 July 2022 at 15:42:40 UTC+1, bitrex wrote:
    HP used to have GPIB on their power supplies, I've never used it but I
    expect it wasn't really useful for tight synchronization.

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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Clifford Heath@21:1/5 to Gerhard Hoffmann on Fri Jul 22 10:45:16 2022
    On 21/7/22 22:52, Gerhard Hoffmann wrote:
    Am 21.07.22 um 13:19 schrieb jlarkin@highlandsniptechnology.com:

    Where does the 10 MHz come from?

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

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

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

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

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

    Clifford Heath.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to bitrex on Thu Jul 21 18:04:22 2022
    On 7/21/2022 7:04 AM, bitrex wrote:
    You really need to define longterm before the problem becomes well posed. Do >> you mean hours, days, weeks or months of runtime?

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

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

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

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

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

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

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

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

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

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

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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From bitrex@21:1/5 to Don Y on Thu Jul 21 21:19:48 2022
    On 7/21/2022 9:04 PM, Don Y wrote:
    On 7/21/2022 7:04 AM, bitrex wrote:
    You really need to define longterm before the problem becomes well
    posed. Do you mean hours, days, weeks or months of runtime?

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

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

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

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

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

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


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

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

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

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

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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to bitrex on Thu Jul 21 18:15:43 2022
    On 7/21/2022 7:12 AM, bitrex wrote:
    On 7/21/2022 4:33 AM, John Walliker wrote:
    If you have an ethernet interface to each unit then Precision Time Protocol >> should do exactly what you want.
    https://en.wikipedia.org/wiki/Precision_Time_Protocol
    John

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

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

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

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

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

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

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

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

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

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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to bitrex on Thu Jul 21 18:56:27 2022
    On 7/21/2022 6:19 PM, bitrex wrote:
    On 7/21/2022 9:04 PM, Don Y wrote:
    On 7/21/2022 7:04 AM, bitrex wrote:
    You really need to define longterm before the problem becomes well posed. >>>> Do you mean hours, days, weeks or months of runtime?

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

    How is "really well" defined? In the domain of human auditory perception? >>
    well, at least over a timespan of several minutes...superficially at least >>> it sounds like he wants a sequencer.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From whit3rd@21:1/5 to lang...@fonz.dk on Thu Jul 21 19:45:00 2022
    On Thursday, July 21, 2022 at 10:30:47 AM UTC-7, lang...@fonz.dk wrote:
    torsdag den 21. juli 2022 kl. 01.21.08 UTC+2 skrev John Larkin:
    Suppose I have several rackmount boxes...
    Each box has a 40 MHz VCXO and I want to phase-lock them, or at least time-align them to always be the same within a few microseconds,
    longterm.

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

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

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

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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to presence@MUNGEpanix.com on Thu Jul 21 19:47:11 2022
    On Fri, 22 Jul 2022 00:08:56 -0000 (UTC), Cydrome Leader <presence@MUNGEpanix.com> wrote:

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

    Am 21.07.22 um 01:20 schrieb John Larkin:


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

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

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

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


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

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

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

    Where does the 10 MHz come from?

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

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

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

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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Clifford Heath@21:1/5 to Phil Hobbs on Fri Jul 22 12:44:09 2022
    On 22/7/22 03:10, Phil Hobbs wrote:
    Gerhard Hoffmann wrote:
    Am 21.07.22 um 16:15 schrieb Phil Hobbs:

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

    -v ?

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

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

    Cheers
    Gerhard

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

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

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

    Interesting, thanks.

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

    Clifford Heath

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to bitrex on Thu Jul 21 20:02:46 2022
    On Thu, 21 Jul 2022 12:35:52 -0400, bitrex <user@example.net> wrote:

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

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

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

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

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

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

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

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

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

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

    Besides, what I do is design things.



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

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

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

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

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

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

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

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

    Gotcha

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

    Sounds good

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


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

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

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

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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to langwadt@fonz.dk on Thu Jul 21 20:11:43 2022
    On Thu, 21 Jul 2022 10:30:44 -0700 (PDT), Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

    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?

    The design intended the outputs to be relay drivers with debounced schmitt-trigger inputs. So they are fairly slow. And lots of people
    have a 1 PPS GPS thing.


    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


    No, I can really time align long-term, after the first accepted 1 PPS
    pulse. I've presented that in another post. One BNC locks the
    timebases and the other starts sequences, all together.

    It's only a power supply, so we don't need absolute timing to
    nanoseconds. Switchers alone add microsecond or even millisecond-scale uncertainty to the analog outputs.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don@21:1/5 to Don Y on Fri Jul 22 03:58:32 2022
    Don Y wrote:
    bitrex wrote:

    <snip>

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

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

    In this case, isn't "really well" defined as an absence of sour note(s)?

    Danke,

    --
    Don, KB7RPU, https://www.qsl.net/kb7rpu
    There was a young lady named Bright Whose speed was far faster than light;
    She set out one day In a relative way And returned on the previous night.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Don on Thu Jul 21 21:54:40 2022
    On 7/21/2022 8:58 PM, Don wrote:
    Don Y wrote:
    bitrex wrote:

    <snip>

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

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

    In this case, isn't "really well" defined as an absence of sour note(s)?

    That assumes the synthesis uses the same clock as timing. I think the discussion here has been wrt durations/intervals.

    How sensitive are *your* ears to noticing small differences in pitch,
    absence a comparative reference? Can you discern a difference of a few
    cents ("perfect pitch")?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Cydrome Leader@21:1/5 to jlarkin@highlandsniptechnology.com on Fri Jul 22 06:20:58 2022
    jlarkin@highlandsniptechnology.com wrote:
    On Fri, 22 Jul 2022 00:08:56 -0000 (UTC), Cydrome Leader <presence@MUNGEpanix.com> wrote:

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

    Am 21.07.22 um 01:20 schrieb John Larkin:


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

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

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

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


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

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

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

    Where does the 10 MHz come from?

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

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

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

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

    GPS timing isn't completely perfect in reality. Antennas blow off roofs, contractors cut cables etc. Even losing sync for a minute is sort of a big deal. As you mentioned, jitter is the real problem. There are tradeoffs to making a flywheel thats too heavy so to speak.

    For really fussy stuff, one might have multiple GPS receivers and a quorum
    of local 10Mhz oscillators. In fact, 10Mhz is a dinosaur relic for modern
    stuff too. We've got racks of 10Mhz oscillators and equipment to monitor
    any phase shift between local oscillators and GPS sources. It's all going
    to the dumpster when somebody finally notices it's been powered down and forgotten about.

    Fairly accurate nS resolution timing is possible in computers these days,
    with the right tricks.

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

    Do you have to worry about fun issues like an the timestamp of a signal
    being received before it was even transmitted between pieces of equipment?

    I like the toggle switches on the USNO hydrogen masers:

    https://www.cnmoc.usff.navy.mil/Organization/United-States-Naval-Observatory/Precise-Time-Department/The-USNO-Master-Clock/The-USNO-Master-Clock/

    They were originally made by some weird company called Sigma Tau. Somehow, Microchip owns them now. New models have a new paint job, but still look
    like they might be a transit case for a Dalek.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to Clifford Heath on Fri Jul 22 08:51:59 2022
    On 22/07/2022 03:44, Clifford Heath wrote:
    On 22/7/22 03:10, Phil Hobbs wrote:
    Gerhard Hoffmann wrote:
    Am 21.07.22 um 16:15 schrieb Phil Hobbs:

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

    -v ?

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

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

    Cheers
    Gerhard

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

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

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

    Interesting, thanks.

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

    Quite probably - it has been known for a long time in radio astronomy
    first derived by Jennison in 1958 at Jodrell Bank for 3 antennae. This
    is the original ground breaking paper for anyone interested

    https://articles.adsabs.harvard.edu//full/1958MNRAS.118..276J/0000276.000.html

    (easier to understand versions exist today). WIki isn't bad:

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

    It allows you to get a good phase observable uncontaminated by the phase
    error at each node for every distinct subset of 3 nodes. There is a corresponding closure amplitude for distinct subsets of 4 nodes.

    Obviously the bigger N is the more useful observables you can get which
    is why the big dish telescopes sometimes stay on target and in the loop
    for perhaps longer than they really ought to in deteriorating weather.

    This book reviews most of the classical tricks used in VLBI and
    interferometry from the period when they had just become routine:

    Indirect Imaging: Measurement and Processing for Indirect Imaging
    Editor-J. A. Roberts
    0 ratings by Goodreads
    ISBN 10: 0521262828 / ISBN 13: 9780521262828
    Published by Cambridge University Press, 1984

    --
    Regards,
    Martin Brown

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gerhard Hoffmann@21:1/5 to All on Fri Jul 22 10:37:53 2022
    Am 22.07.22 um 04:47 schrieb jlarkin@highlandsniptechnology.com:

    Where does the 10 MHz come from?

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

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

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

    No. The 1pps is asserted when the CPU thinks it's closest to
    the "right" clockcycle. It could be off by half a cycle.
    There is no need for 10 MHz, one could have chosen a nice
    multiple of the desired baud rate.

    The 1pps does not control the clock, its the huge state vector
    in the CPU that does. 1pps is only an approximation, that's why
    it's so bad in the short term.

    Locking an oscillator via 1pps is only done when there is
    nothing better available, outside the GPS box.

    < http://www.leapsecond.com/pages/m12/sawtooth.htm >

    Cheers, Gerhard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to bitrex on Fri Jul 22 10:36:02 2022
    On 21/07/2022 18:41, bitrex wrote:
    On 7/21/2022 1:21 PM, Martin Brown wrote:

    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.

    There were bidirectional parallel ports that could run fairly quick.
    A parallel port interface for a CD drive was just about doable on a bog standard PC parallel port.

    SCSI was quite good for external bulk data devices like scanners too.
    It's disadvantage was cost.

    I recall early versions of USB 1.x very unfondly. ISTR the acronym was originally take to be Unusable Serial Bus (cf Firewire implementations).
    It slowly improved with successive Doze versions to become merely
    Unstable Serial Bus. Firewire easily left it standing.

    https://en.wikipedia.org/wiki/IEEE_1394#Comparison_with_USB

    USB eventually won out by being cheaper. Much like VHS vs Betamax - the superior technology was effectively sidelined by popularity of the
    rival. Even today there are USB peripherals that never come back when a
    PC goes into sleep mode without being unplugged and plugged in again.

    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.

    GPIB and HPIB was fairly common on desktop computers in the early 80's.

    HP and Commodore used it for their external disk drives. We hacked an
    interface for the Commodore hard disk drive but the HP harddrive blinded
    the bus analysers of the day and by the time we had hacked it cheaper
    options were already available. It survived as a niche instrumentation
    bus until the turn of the century and is possibly still used by some.
    The instruments using it still being pretty good kit.

    Token ring WAN over cheap twisted pairs took over for a while in my neck
    of the woods before truly fast Ethernet really got going.
    (it was an academic predecessor of IBM's token ring offering)

    Early fast ethernet distribution was on expensive thick heavy coax cable
    marked up with where to tap into them. The cost difference for wiring up
    was enormous. Physically manhandling the cable was a PITA.

    --
    Regards,
    Martin Brown

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to jlarkin@highlandsniptechnology.com on Fri Jul 22 10:24:04 2022
    On 21/07/2022 12:42, jlarkin@highlandsniptechnology.com wrote:
    On Thu, 21 Jul 2022 12:06:26 +0100, Martin Brown
    <'''newspam'''@nonad.co.uk> wrote:

    On 21/07/2022 01:22, John Larkin wrote:

    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)

    I wouldn't expect my VCXO to be more than 10 PPM off at the start of
    the lock request. So I can walk it to within 1 PPM, namely 1
    microsecond error, in at most 10 seconds using 1 PPM jogs. If the osc
    were 50 PPM off, it would take 50 seconds to catch up to the external
    pulse.

    You would have lower systematic error after lockin if you made the
    adjustments by reading the full width counter as a two's compliment
    number when the synch pulse arrives (and using a 2^N counter).

    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.

    Yes, I don't want to measure period once a second. I want to compare
    time alignment forever after receiving the first 1 pps pulse.

    It's actually simple: first received pulse, start a mod 40 million
    counter. Every time it rolls over, do an early/late compare to the 1
    PPS input, and jog the 40 MHz VCXO 1 PPM in the right direction.

    The compare is a dflop, d is the msb of the counter, clock is the 1
    PPS input. Occasional metastability is fine; it indicates success.

    It doesn't even need to be a 40 million counter. Something a fraction
    of that will do. 10,000 maybe.

    Unless you are very wedded to base 10 it might well work better to use a hardware 16 or 24 bit counter and allow it to free run. The master clock
    time pulses could be at some suitable power of 2^N x 0.1us.

    Under software control you could even do quick corrections in the first
    second to get the basic frequency of all clocks approximately right.

    The master could produce a set of pulses that were 1/16s, 1/8s, 1/4s,
    1/2, 1s long at the outset. That would speed up the lock in time.

    Maybe the counter can just free-run, never get initialized. Gotta do
    the math on that after I wake up.

    If you want to get the clocks on the various boxes as close to in synch
    as possible then it makes sense to correct any errors quickly.

    Power of 2 steps decreasing to some floor level being most favourable.

    --
    Regards,
    Martin Brown

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Martin Brown on Fri Jul 22 03:23:56 2022
    On 7/22/2022 2:36 AM, Martin Brown wrote:
    On 21/07/2022 18:41, bitrex wrote:
    On 7/21/2022 1:21 PM, Martin Brown wrote:

    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.

    There were bidirectional parallel ports that could run fairly quick.
    A parallel port interface for a CD drive was just about doable on a bog standard PC parallel port.

    But old ports (without queues) were a bitch for the processor to service.

    SCSI was quite good for external bulk data devices like scanners too. It's disadvantage was cost.

    And cable length. Aside from differential (even costlier), you were
    stuck to "arm's reach". At least serial and USB can be pushed to
    longer lengths (despite limitations of their respective standards).

    Token ring WAN over cheap twisted pairs took over for a while in my neck of the
    woods before truly fast Ethernet really got going.
    (it was an academic predecessor of IBM's token ring offering)

    IBM's suffered from the same sort of costs as SCSI with their big,
    klunky connectors.

    Early fast ethernet distribution was on expensive thick heavy coax cable marked
    up with where to tap into them. The cost difference for wiring up was enormous.
    Physically manhandling the cable was a PITA.

    Ah, yes. "Orange hose" and vampire taps. I suspect one could make a pretty little structure (think: Lincoln Logs) out of lengths of that! A likely factor in its lack of ubiquity.

    I rely on network connectivity for an increasing number of appliances, now. Scanners (direct network connections or USB to SBC host), disks (iSCSI), printers (direct network connections or dedicated print server appliance), other computers, etc.

    But, all of the T/TX technologies make cabling a PITA. Every cable has to travel all the way to a switch, even if some other networked device is
    nearby (e.g., 10Base2 would tolerate device insertion with just a short
    length of coax -- though the entire network was disrupted in the process!)
    I have thick bundles of CAT5e affixed to the undersides of my workbenches
    as the cables from each device (on or under the bench) join the bundle
    as it travels to the east or west switch. Add a new device? Ugh!

    IMO, most interfaces fall down (in practical terms) when it comes to the choice of connector. Either too cheap (flimsy) or too costly. The RJ45/8P8C wins in terms of cost... but is a nuisance when the locking tab inevitably breaks off (even if "guarded"): "Great! Now I either repair the cable or replace it!"

    And, inevitably, connectors require a bit of "fiddling" to ensure oriented correctly and mated well. How many times do you discover a bent pin on a
    HD SCSI cable only because the interface refuses to run properly? (and
    trying to repair said pin is essentially impossible).

    And, of course, the wide choice of "standards" (SCSI cables being among the worst for lack of uniformity: Old Sun, Apple, SCSI, SCSI2, SCSI3, VHDCI,
    etc.)

    The ideal connector wouldn't have a top or bottom (etc.) Something like
    a phone plug where all you have to do is line up plug to hole and jam
    it home. Considering most connectors reside on the backs of equipment, expecting the user to be able to VIEW the mate while attempting to connect
    is wishful thinking!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Walliker@21:1/5 to Don Y on Fri Jul 22 05:12:40 2022
    On Friday, 22 July 2022 at 11:24:11 UTC+1, Don Y wrote:
    On 7/22/2022 2:36 AM, Martin Brown wrote:
    On 21/07/2022 18:41, bitrex wrote:
    On 7/21/2022 1:21 PM, Martin Brown wrote:

    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.

    There were bidirectional parallel ports that could run fairly quick.
    A parallel port interface for a CD drive was just about doable on a bog standard PC parallel port.
    But old ports (without queues) were a bitch for the processor to service.
    SCSI was quite good for external bulk data devices like scanners too. It's disadvantage was cost.
    And cable length. Aside from differential (even costlier), you were
    stuck to "arm's reach". At least serial and USB can be pushed to
    longer lengths (despite limitations of their respective standards).
    Token ring WAN over cheap twisted pairs took over for a while in my neck of the
    woods before truly fast Ethernet really got going.
    (it was an academic predecessor of IBM's token ring offering)
    IBM's suffered from the same sort of costs as SCSI with their big,
    klunky connectors.
    Early fast ethernet distribution was on expensive thick heavy coax cable marked
    up with where to tap into them. The cost difference for wiring up was enormous.
    Physically manhandling the cable was a PITA.
    Ah, yes. "Orange hose" and vampire taps. I suspect one could make a pretty little structure (think: Lincoln Logs) out of lengths of that! A likely factor
    in its lack of ubiquity.

    I rely on network connectivity for an increasing number of appliances, now. Scanners (direct network connections or USB to SBC host), disks (iSCSI), printers (direct network connections or dedicated print server appliance), other computers, etc.

    But, all of the T/TX technologies make cabling a PITA. Every cable has to travel all the way to a switch, even if some other networked device is
    nearby (e.g., 10Base2 would tolerate device insertion with just a short length of coax -- though the entire network was disrupted in the process!)
    I have thick bundles of CAT5e affixed to the undersides of my workbenches
    as the cables from each device (on or under the bench) join the bundle
    as it travels to the east or west switch. Add a new device? Ugh!

    IMO, most interfaces fall down (in practical terms) when it comes to the choice
    of connector. Either too cheap (flimsy) or too costly. The RJ45/8P8C wins in terms of cost... but is a nuisance when the locking tab inevitably breaks off (even if "guarded"): "Great! Now I either repair the cable or replace it!"

    And, inevitably, connectors require a bit of "fiddling" to ensure oriented correctly and mated well. How many times do you discover a bent pin on a
    HD SCSI cable only because the interface refuses to run properly? (and
    trying to repair said pin is essentially impossible).

    And, of course, the wide choice of "standards" (SCSI cables being among the worst for lack of uniformity: Old Sun, Apple, SCSI, SCSI2, SCSI3, VHDCI, etc.)

    The ideal connector wouldn't have a top or bottom (etc.) Something like
    a phone plug where all you have to do is line up plug to hole and jam
    it home. Considering most connectors reside on the backs of equipment, expecting the user to be able to VIEW the mate while attempting to connect
    is wishful thinking!
    Yes, I discovered the perils of blind plugging when I tried to plug something in deep inside a rack cabinet. My finger discovered an unguarded fan and it initially felt like an electric shock. I pulled my arm back so fast I hit my face
    and got a nosebleed!
    John

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to Martin Brown on Fri Jul 22 09:03:16 2022
    Martin Brown wrote:
    On 22/07/2022 03:44, Clifford Heath wrote:
    On 22/7/22 03:10, Phil Hobbs wrote:
    Gerhard Hoffmann wrote:
    Am 21.07.22 um 16:15 schrieb Phil Hobbs:

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

    -v ?

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

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

    Cheers
    Gerhard

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

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

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

    Interesting, thanks.

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

    Quite probably - it has been known for a long time in radio astronomy
    first derived by Jennison in 1958 at Jodrell Bank for 3 antennae. This
    is the original ground breaking paper for anyone interested

    https://articles.adsabs.harvard.edu//full/1958MNRAS.118..276J/0000276.000.html


    (easier to understand versions exist today). WIki isn't bad:

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

    It allows you to get a good phase observable uncontaminated by the phase error at each node for every distinct subset of 3 nodes. There is a corresponding closure amplitude for distinct subsets of 4 nodes.

    Obviously the bigger N is the more useful observables you can get which
    is why the big dish telescopes sometimes stay on target and in the loop
    for perhaps longer than they really ought to in deteriorating weather.

    This book reviews most of the classical tricks used in VLBI and interferometry from the period when they had just become routine:

    Indirect Imaging: Measurement and Processing for Indirect Imaging
    Editor-J. A. Roberts
     0 ratings by Goodreads
    ISBN 10: 0521262828 / ISBN 13: 9780521262828
    Published by Cambridge University Press, 1984


    The real power comes from the number of independent observables from N instruments going like N**2, so that you win SNR like N**2 instead of N.

    Quite a startling improvement for moderate-to-large N!

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to John Walliker on Fri Jul 22 07:06:14 2022
    On 7/22/2022 5:12 AM, John Walliker wrote:
    Yes, I discovered the perils of blind plugging when I tried to plug something in deep inside a rack cabinet. My finger discovered an unguarded fan and it initially felt like an electric shock. I pulled my arm back so fast I hit my face
    and got a nosebleed!

    Too funny! :>

    I had a similar experience groping for the right place to plug
    a device and happened upon an exposed bus bar. Only 12V (at 100A)
    but sufficient to vaporize the leads on the device I was plugging!

    And, cause me to retract my arm in utmost haste -- whacking
    my elbow in the process.

    Moral of story: shut down power before making changes (even
    if that sequence takes a fair bit of time to complete!)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don@21:1/5 to Don Y on Fri Jul 22 14:17:36 2022
    Don Y wrote:
    Don wrote:
    Don Y wrote:
    bitrex wrote:

    <snip>

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

    How is "really well" defined? In the domain of human auditory perception? >>
    In this case, isn't "really well" defined as an absence of sour note(s)?

    That assumes the synthesis uses the same clock as timing. I think the discussion here has been wrt durations/intervals.

    How sensitive are *your* ears to noticing small differences in pitch,
    absence a comparative reference? Can you discern a difference of a few
    cents ("perfect pitch")?

    Can't everyone's ears (except perhaps the autistic tone-deaf and such)
    hear a sour note relative to the preceding note? Do you need to name a
    note (perfect pitch) in order to hear its sourness?
    It's all but impossible for me personally to ignore the sourness of cringeworthy, awkward note(s). Sour notes make me want to get out of
    earshot.

    Danke,

    --
    Don, KB7RPU, https://www.qsl.net/kb7rpu
    There was a young lady named Bright Whose speed was far faster than light;
    She set out one day In a relative way And returned on the previous night.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to '''newspam'''@nonad.co.uk on Fri Jul 22 07:28:20 2022
    On Fri, 22 Jul 2022 10:24:04 +0100, Martin Brown
    <'''newspam'''@nonad.co.uk> wrote:

    On 21/07/2022 12:42, jlarkin@highlandsniptechnology.com wrote:
    On Thu, 21 Jul 2022 12:06:26 +0100, Martin Brown
    <'''newspam'''@nonad.co.uk> wrote:

    On 21/07/2022 01:22, John Larkin wrote:

    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)

    I wouldn't expect my VCXO to be more than 10 PPM off at the start of
    the lock request. So I can walk it to within 1 PPM, namely 1
    microsecond error, in at most 10 seconds using 1 PPM jogs. If the osc
    were 50 PPM off, it would take 50 seconds to catch up to the external
    pulse.

    You would have lower systematic error after lockin if you made the >adjustments by reading the full width counter as a two's compliment
    number when the synch pulse arrives (and using a 2^N counter).

    Yes, it could evaluate the magnitude of the time error and close a
    classic almost-analog control loop. The plant is already an integrator
    so it could be a simple proportional loop.


    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.

    Yes, I don't want to measure period once a second. I want to compare
    time alignment forever after receiving the first 1 pps pulse.

    It's actually simple: first received pulse, start a mod 40 million
    counter. Every time it rolls over, do an early/late compare to the 1
    PPS input, and jog the 40 MHz VCXO 1 PPM in the right direction.

    The compare is a dflop, d is the msb of the counter, clock is the 1
    PPS input. Occasional metastability is fine; it indicates success.

    It doesn't even need to be a 40 million counter. Something a fraction
    of that will do. 10,000 maybe.

    Unless you are very wedded to base 10 it might well work better to use a >hardware 16 or 24 bit counter and allow it to free run. The master clock
    time pulses could be at some suitable power of 2^N x 0.1us.


    My xo is 40 MHz and 1 PPS is convenient, GPS compatible.



    Under software control you could even do quick corrections in the first >second to get the basic frequency of all clocks approximately right.

    The loop will be software, once an FPGA provides the measurements. All
    the VCXOs will park, open-loop before we try to lock, at some
    calibrated nominally correct frequency, not many PPM off absolute.


    The master could produce a set of pulses that were 1/16s, 1/8s, 1/4s,
    1/2, 1s long at the outset. That would speed up the lock in time.

    Maybe the counter can just free-run, never get initialized. Gotta do
    the math on that after I wake up.

    If you want to get the clocks on the various boxes as close to in synch
    as possible then it makes sense to correct any errors quickly.

    Power of 2 steps decreasing to some floor level being most favourable.

    It's only a power supply!

    If it takes 10 seconds to achieve dither-lock, starting 10 PPM out,
    the worst time error is still way under a millisecond.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Don on Fri Jul 22 07:46:20 2022
    On 7/22/2022 7:17 AM, Don wrote:
    Don Y wrote:
    Don wrote:
    Don Y wrote:
    bitrex wrote:

    <snip>

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

    How is "really well" defined? In the domain of human auditory perception? >>>
    In this case, isn't "really well" defined as an absence of sour note(s)?

    That assumes the synthesis uses the same clock as timing. I think the
    discussion here has been wrt durations/intervals.

    How sensitive are *your* ears to noticing small differences in pitch,
    absence a comparative reference? Can you discern a difference of a few
    cents ("perfect pitch")?

    Can't everyone's ears (except perhaps the autistic tone-deaf and such)
    hear a sour note relative to the preceding note? Do you need to name a
    note (perfect pitch) in order to hear its sourness?

    Perfect pitch is more than just "naming a note".

    It's all but impossible for me personally to ignore the sourness of cringeworthy, awkward note(s). Sour notes make me want to get out of
    earshot.

    How "sour" does the note have to be before it is perceptible, as such.
    A cent? Two? Fifty? A semitone?? (about a 25 cents is typical for
    the average, non-musician, listener to be able to detect -- without
    context; i.e., if the "previous note" was similarly sour, your estimation
    of the correctness of the following note can perceive both as correct...
    like singing in an entirely different *key*!)

    <https://neurosciencenews.com/pitch-detection-music-21087/>

    This is a reference note (middle C) followed by the same note "soured"
    by 12 cents:

    <https://en.wikipedia.org/wiki/File:Sines_12_cent_difference.wav>

    Chances are, you can't tell the difference hearing them
    in sequence. If you heard just *one*, you'd not be able to tell if it
    was correct, or not. The third sound sample plays both simultaneously
    so you can hear them beating against each other -- the difference then
    becomes very noticeable!

    Here's *one* cent difference:

    <https://en.wikipedia.org/wiki/File:Sines_1_cent_difference.wav>

    And 24 cents (about the point of "normal" perception):

    <https://en.wikipedia.org/wiki/File:Sines_24_cent_difference.wav>

    If your device's *timing* was off by 0.05%, would that be consequential?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don@21:1/5 to Don Y on Fri Jul 22 15:07:33 2022
    Don Y wrote:
    Don wrote:
    Don Y wrote:
    Don wrote:
    Don Y wrote:
    bitrex wrote:

    <snip>

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

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

    In this case, isn't "really well" defined as an absence of sour note(s)? >>>
    That assumes the synthesis uses the same clock as timing. I think the
    discussion here has been wrt durations/intervals.

    How sensitive are *your* ears to noticing small differences in pitch,
    absence a comparative reference? Can you discern a difference of a few
    cents ("perfect pitch")?

    Can't everyone's ears (except perhaps the autistic tone-deaf and such)
    hear a sour note relative to the preceding note? Do you need to name a
    note (perfect pitch) in order to hear its sourness?

    Perfect pitch is more than just "naming a note".

    It's all but impossible for me personally to ignore the sourness of
    cringeworthy, awkward note(s). Sour notes make me want to get out of
    earshot.

    How "sour" does the note have to be before it is perceptible, as such.
    A cent? Two? Fifty? A semitone?? (about a 25 cents is typical for
    the average, non-musician, listener to be able to detect -- without
    context; i.e., if the "previous note" was similarly sour, your estimation
    of the correctness of the following note can perceive both as correct...
    like singing in an entirely different *key*!)

    <https://neurosciencenews.com/pitch-detection-music-21087/>

    This is a reference note (middle C) followed by the same note "soured"
    by 12 cents:

    <https://en.wikipedia.org/wiki/File:Sines_12_cent_difference.wav>
    Here's *one* cent difference:

    <https://en.wikipedia.org/wiki/File:Sines_1_cent_difference.wav>

    And 24 cents (about the point of "normal" perception):

    <https://en.wikipedia.org/wiki/File:Sines_24_cent_difference.wav>

    If your device's *timing* was off by 0.05%, would that be consequential?

    Very interesting information. Thank you.
    It's easy for me to hear the one cent difference, how about you? My
    audio perception comes in handy when it's time to tune a keyboard. Some-
    times musicians purposefully vary tones by a few cents in order to
    produce vibrato.

    In regards to your 0.05% device timing question, the answer is: it
    depends. A 0.05% device timing variance in my Power Bank Keepalive:

    https://crcomp.net/mp3mod/index.php

    for instance, is inconsequential.

    Danke,

    --
    Don, KB7RPU, https://www.qsl.net/kb7rpu
    There was a young lady named Bright Whose speed was far faster than light;
    She set out one day In a relative way And returned on the previous night.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to presence@MUNGEpanix.com on Fri Jul 22 08:26:35 2022
    On Fri, 22 Jul 2022 06:20:58 -0000 (UTC), Cydrome Leader <presence@MUNGEpanix.com> wrote:

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

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

    Am 21.07.22 um 01:20 schrieb John Larkin:


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

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

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

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


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

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

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

    Where does the 10 MHz come from?

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

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

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

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

    GPS timing isn't completely perfect in reality. Antennas blow off roofs, >contractors cut cables etc. Even losing sync for a minute is sort of a big >deal. As you mentioned, jitter is the real problem. There are tradeoffs to >making a flywheel thats too heavy so to speak.

    For really fussy stuff, one might have multiple GPS receivers and a quorum
    of local 10Mhz oscillators. In fact, 10Mhz is a dinosaur relic for modern >stuff too. We've got racks of 10Mhz oscillators and equipment to monitor
    any phase shift between local oscillators and GPS sources. It's all going
    to the dumpster when somebody finally notices it's been powered down and >forgotten about.

    Fairly accurate nS resolution timing is possible in computers these days, >with the right tricks.

    I triggered a scope from a very good ovenized XO and looked at the
    rising edge of a rubidium. The edge looked solid, as if it was
    internal triggered. Checking every 20 minutes or so, it ws slowly
    creeping across the screen, at 5 ns/cm.


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

    Do you have to worry about fun issues like an the timestamp of a signal
    being received before it was even transmitted between pieces of equipment?

    It a multi-channel power supply!


    I like the toggle switches on the USNO hydrogen masers:

    https://www.cnmoc.usff.navy.mil/Organization/United-States-Naval-Observatory/Precise-Time-Department/The-USNO-Master-Clock/The-USNO-Master-Clock/

    They were originally made by some weird company called Sigma Tau. Somehow, >Microchip owns them now. New models have a new paint job, but still look
    like they might be a transit case for a Dalek.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Don on Fri Jul 22 08:25:33 2022
    On 7/22/2022 8:07 AM, Don wrote:
    Don Y wrote:
    Don wrote:
    Don Y wrote:
    Don wrote:
    Don Y wrote:
    bitrex wrote:

    <snip>

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

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

    In this case, isn't "really well" defined as an absence of sour note(s)? >>>>
    That assumes the synthesis uses the same clock as timing. I think the >>>> discussion here has been wrt durations/intervals.

    How sensitive are *your* ears to noticing small differences in pitch,
    absence a comparative reference? Can you discern a difference of a few >>>> cents ("perfect pitch")?

    Can't everyone's ears (except perhaps the autistic tone-deaf and such)
    hear a sour note relative to the preceding note? Do you need to name a
    note (perfect pitch) in order to hear its sourness?

    Perfect pitch is more than just "naming a note".

    It's all but impossible for me personally to ignore the sourness of >>> cringeworthy, awkward note(s). Sour notes make me want to get out of
    earshot.

    How "sour" does the note have to be before it is perceptible, as such.
    A cent? Two? Fifty? A semitone?? (about a 25 cents is typical for
    the average, non-musician, listener to be able to detect -- without
    context; i.e., if the "previous note" was similarly sour, your estimation
    of the correctness of the following note can perceive both as correct...
    like singing in an entirely different *key*!)

    <https://neurosciencenews.com/pitch-detection-music-21087/>

    This is a reference note (middle C) followed by the same note "soured"
    by 12 cents:

    <https://en.wikipedia.org/wiki/File:Sines_12_cent_difference.wav>
    Here's *one* cent difference:

    <https://en.wikipedia.org/wiki/File:Sines_1_cent_difference.wav>

    And 24 cents (about the point of "normal" perception):

    <https://en.wikipedia.org/wiki/File:Sines_24_cent_difference.wav>

    If your device's *timing* was off by 0.05%, would that be consequential?

    Very interesting information. Thank you.
    It's easy for me to hear the one cent difference, how about you? My audio perception comes in handy when it's time to tune a keyboard. Some- times musicians purposefully vary tones by a few cents in order to
    produce vibrato.

    Could you hear a middle C "soured" by one cent when it follows a
    (correct) C-sharp immediately preceding it? Or, vice versa?

    *I* can't. My threshold is closer to 10 cents and rely on electronic
    devices when tuning instruments.

    And, if every note was "off key" by 10 cents, I'd not recognize the
    tony.

    In regards to your 0.05% device timing question, the answer is: it
    depends. A 0.05% device timing variance in my Power Bank Keepalive:

    https://crcomp.net/mp3mod/index.php

    for instance, is inconsequential.

    In the context of this thread, it likely has an impact. A cent is
    about 500PPM (though in the frequency domain)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to All on Fri Jul 22 08:29:16 2022
    On Fri, 22 Jul 2022 10:37:53 +0200, Gerhard Hoffmann <dk4xp@arcor.de>
    wrote:

    Am 22.07.22 um 04:47 schrieb jlarkin@highlandsniptechnology.com:

    Where does the 10 MHz come from?

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

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

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

    No. The 1pps is asserted when the CPU thinks it's closest to
    the "right" clockcycle. It could be off by half a cycle.
    There is no need for 10 MHz, one could have chosen a nice
    multiple of the desired baud rate.


    Our GPS receivers output 1 PPS and 10 MHz. Argue with Wikipedia.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to blockedofcourse@foo.invalid on Fri Jul 22 09:01:52 2022
    On Thu, 21 Jul 2022 18:04:22 -0700, Don Y
    <blockedofcourse@foo.invalid> wrote:

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

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

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

    Sound travels about a foot per millisecond, so we are used to multiple
    time delays. A marching band sounds coordinated to us.

    I am thinking about vision a lot lately too. Each eye acquires a
    differently scaled image that changes constantly. There are
    millisecond-level changes in focus and parallax. I can put my glasses
    on, or not, and magnification surely changes. Somehow a brain acquires
    two images and distorts them in real time so that all the bits align.

    One has much better resolution using two eyes than either alone can
    provide.

    Nice trick. Sound must work like that to, extensive post-processing of
    acquired inputs. Probably time shifting parts of the spectrum, or
    something more complex, multiple cross-correlations.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don@21:1/5 to Don Y on Fri Jul 22 16:02:30 2022
    Don Y wrote:
    Don wrote:
    Don Y wrote:
    Don wrote:
    Don Y wrote:
    Don wrote:
    Don Y wrote:
    bitrex wrote:

    <snip>

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

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

    In this case, isn't "really well" defined as an absence of sour note(s)? >>>>>
    That assumes the synthesis uses the same clock as timing. I think the >>>>> discussion here has been wrt durations/intervals.

    How sensitive are *your* ears to noticing small differences in pitch, >>>>> absence a comparative reference? Can you discern a difference of a few >>>>> cents ("perfect pitch")?

    Can't everyone's ears (except perhaps the autistic tone-deaf and such) >>>> hear a sour note relative to the preceding note? Do you need to name a >>>> note (perfect pitch) in order to hear its sourness?

    Perfect pitch is more than just "naming a note".

    It's all but impossible for me personally to ignore the sourness of >>>> cringeworthy, awkward note(s). Sour notes make me want to get out of
    earshot.

    How "sour" does the note have to be before it is perceptible, as such.
    A cent? Two? Fifty? A semitone?? (about a 25 cents is typical for
    the average, non-musician, listener to be able to detect -- without
    context; i.e., if the "previous note" was similarly sour, your estimation >>> of the correctness of the following note can perceive both as correct... >>> like singing in an entirely different *key*!)

    <https://neurosciencenews.com/pitch-detection-music-21087/>

    This is a reference note (middle C) followed by the same note "soured"
    by 12 cents:

    <https://en.wikipedia.org/wiki/File:Sines_12_cent_difference.wav>
    Here's *one* cent difference:

    <https://en.wikipedia.org/wiki/File:Sines_1_cent_difference.wav>

    And 24 cents (about the point of "normal" perception):

    <https://en.wikipedia.org/wiki/File:Sines_24_cent_difference.wav>

    If your device's *timing* was off by 0.05%, would that be consequential?

    Very interesting information. Thank you.
    It's easy for me to hear the one cent difference, how about you? My
    audio perception comes in handy when it's time to tune a keyboard. Some-
    times musicians purposefully vary tones by a few cents in order to
    produce vibrato.

    Could you hear a middle C "soured" by one cent when it follows a
    (correct) C-sharp immediately preceding it? Or, vice versa?

    *I* can't. My threshold is closer to 10 cents and rely on electronic
    devices when tuning instruments.

    And, if every note was "off key" by 10 cents, I'd not recognize the
    tony.

    In regards to your 0.05% device timing question, the answer is: it
    depends. A 0.05% device timing variance in my Power Bank Keepalive:

    https://crcomp.net/mp3mod/index.php

    for instance, is inconsequential.

    In the context of this thread, it likely has an impact. A cent is
    about 500PPM (though in the frequency domain)

    Your question about a one cent following note difference perception is interesting. And, it needs to be followed up by me, so to speak. :)
    For some unknown reason, the only thing to truly satisfy me is to
    tune instruments by ear.

    Danke,

    --
    Don, KB7RPU, https://www.qsl.net/kb7rpu
    There was a young lady named Bright Whose speed was far faster than light;
    She set out one day In a relative way And returned on the previous night.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Cydrome Leader@21:1/5 to jlarkin@highlandsniptechnology.com on Fri Jul 22 16:41:40 2022
    jlarkin@highlandsniptechnology.com wrote:
    On Fri, 22 Jul 2022 06:20:58 -0000 (UTC), Cydrome Leader <presence@MUNGEpanix.com> wrote:

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

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

    Am 21.07.22 um 01:20 schrieb John Larkin:


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

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

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

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


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

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

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

    Where does the 10 MHz come from?

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

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

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

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

    GPS timing isn't completely perfect in reality. Antennas blow off roofs, >>contractors cut cables etc. Even losing sync for a minute is sort of a big >>deal. As you mentioned, jitter is the real problem. There are tradeoffs to >>making a flywheel thats too heavy so to speak.

    For really fussy stuff, one might have multiple GPS receivers and a quorum >>of local 10Mhz oscillators. In fact, 10Mhz is a dinosaur relic for modern >>stuff too. We've got racks of 10Mhz oscillators and equipment to monitor >>any phase shift between local oscillators and GPS sources. It's all going >>to the dumpster when somebody finally notices it's been powered down and >>forgotten about.

    Fairly accurate nS resolution timing is possible in computers these days, >>with the right tricks.

    I triggered a scope from a very good ovenized XO and looked at the
    rising edge of a rubidium. The edge looked solid, as if it was
    internal triggered. Checking every 20 minutes or so, it ws slowly
    creeping across the screen, at 5 ns/cm.

    I believe they somehow pair the rubidium clocks with another quartz
    crystal, even in those new tiny physics modules. I've not had a chance to
    tear apart a rubidium clock yet, or the ovenized stuff. They come in
    little metal boxes, that remind me of TV tuners.

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

    Do you have to worry about fun issues like an the timestamp of a signal >>being received before it was even transmitted between pieces of equipment?

    It a multi-channel power supply!

    You were also asking about timestamping in other posts. Not entirely sure
    what you're upto in the end, but it might be interesting.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Cydrome Leader@21:1/5 to jlarkin@highlandsniptechnology.com on Fri Jul 22 16:54:07 2022
    jlarkin@highlandsniptechnology.com wrote:
    On Fri, 22 Jul 2022 10:37:53 +0200, Gerhard Hoffmann <dk4xp@arcor.de>
    wrote:

    Am 22.07.22 um 04:47 schrieb jlarkin@highlandsniptechnology.com:

    Where does the 10 MHz come from?

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

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

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

    No. The 1pps is asserted when the CPU thinks it's closest to
    the "right" clockcycle. It could be off by half a cycle.
    There is no need for 10 MHz, one could have chosen a nice
    multiple of the desired baud rate.


    Our GPS receivers output 1 PPS and 10 MHz. Argue with Wikipedia.

    What he's trying to say is it may not be perfect 10 million cycles between every 1PPS pulse. For most stuff, this is good enough. For the metrology
    folks, using strong words like exactly or in this case "locked" will
    always cause an argument.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jan Panteltje@21:1/5 to jlarkin@highlandsniptechnology.com on Fri Jul 22 16:36:14 2022
    On a sunny day (Fri, 22 Jul 2022 09:01:52 -0700) it happened jlarkin@highlandsniptechnology.com wrote in <vnhldhh5vjech8rgksjrmss5djbgfndtqj@4ax.com>:

    On Thu, 21 Jul 2022 18:04:22 -0700, Don Y
    <blockedofcourse@foo.invalid> wrote:

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

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

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

    Sound travels about a foot per millisecond, so we are used to multiple
    time delays. A marching band sounds coordinated to us.

    I am thinking about vision a lot lately too. Each eye acquires a
    differently scaled image that changes constantly. There are
    millisecond-level changes in focus and parallax. I can put my glasses
    on, or not, and magnification surely changes. Somehow a brain acquires
    two images and distorts them in real time so that all the bits align.

    One has much better resolution using two eyes than either alone can
    provide.

    Nice trick. Sound must work like that to, extensive post-processing of >acquired inputs. Probably time shifting parts of the spectrum, or
    something more complex, multiple cross-correlations.

    Yes vision is a very interesting thing, been working on that for most of my life (TV etc)
    As I am not from this planet as you likely guessed I can see things from sound only
    But today it got even weeder...
    I had the TV on, switched it off, sat on the bench relaxing with eyes closed all of the sudden I visualized a field of purple I think it was flowers...
    Very bright and strong..
    switched on the TV and there is was : same field.
    Still puzzled, only thing on was the sat receiver (connected via HDMI to the TV)
    but TV was off.
    I have tried some processing sound to vision but I think we need a neural net copy from the brain's visual part.
    RF to vision?
    Work on the 4G tower here ended at 6 PM today, at about 5 my 4G signal was back at 100%
    was depending on signal from a far away tower for the last 3 or 4 days,,, dropped when it rained..
    but.. being impatient .. had checked on the ad dropped in my mailbox for fiber connection..
    checked out their site, not bad and just as expensive but much faster than 4 G and no data limit..
    but may take month before they are at my house installing stuff.,.
    fiber as backup not a bad idea... not very portable though.

    As to depend on GPS or GLONASS or what have you these days for professional test equipment
    seems a no-no to me, often there is no coverage,

    And as to connections, BNC sucks.
    Ethernet cable connectors suck too but you can do a whole lot with those connections
    and protocols and you can get good time signals from the net.
    I have a Casio radio watch accurate to the second.. sure you can jam that 77.5 kHz too
    but so far it has always worked here, what do you US guys use? WWVB?
    Automatic summer-winter time switch too

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Walliker@21:1/5 to jla...@highlandsniptechnology.com on Fri Jul 22 10:03:37 2022
    On Friday, 22 July 2022 at 17:02:04 UTC+1, jla...@highlandsniptechnology.com wrote:
    On Thu, 21 Jul 2022 18:04:22 -0700, Don Y
    <blocked...@foo.invalid> wrote:

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

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

    How is "really well" defined? In the domain of human auditory perception? Sound travels about a foot per millisecond, so we are used to multiple
    time delays. A marching band sounds coordinated to us.

    I am thinking about vision a lot lately too. Each eye acquires a
    differently scaled image that changes constantly. There are
    millisecond-level changes in focus and parallax. I can put my glasses
    on, or not, and magnification surely changes. Somehow a brain acquires
    two images and distorts them in real time so that all the bits align.

    One has much better resolution using two eyes than either alone can
    provide.

    Nice trick. Sound must work like that to, extensive post-processing of acquired inputs. Probably time shifting parts of the spectrum, or
    something more complex, multiple cross-correlations.

    There is cross-correlation between left and right ears in the brainstem which is involved in determining the direction of sound sources. Detectable time differences are remarkably small. (I would have to look it up to give a number.)
    John

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Fri Jul 22 10:54:30 2022
    fredag den 22. juli 2022 kl. 16.46.36 UTC+2 skrev Don Y:
    On 7/22/2022 7:17 AM, Don wrote:
    Don Y wrote:
    Don wrote:
    Don Y wrote:
    bitrex wrote:

    <snip>

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

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

    In this case, isn't "really well" defined as an absence of sour note(s)? >>
    That assumes the synthesis uses the same clock as timing. I think the
    discussion here has been wrt durations/intervals.

    How sensitive are *your* ears to noticing small differences in pitch,
    absence a comparative reference? Can you discern a difference of a few
    cents ("perfect pitch")?

    Can't everyone's ears (except perhaps the autistic tone-deaf and such)
    hear a sour note relative to the preceding note? Do you need to name a
    note (perfect pitch) in order to hear its sourness?
    Perfect pitch is more than just "naming a note".
    It's all but impossible for me personally to ignore the sourness of cringeworthy, awkward note(s). Sour notes make me want to get out of earshot.
    How "sour" does the note have to be before it is perceptible, as such.
    A cent? Two? Fifty? A semitone?? (about a 25 cents is typical for
    the average, non-musician, listener to be able to detect -- without
    context; i.e., if the "previous note" was similarly sour, your estimation
    of the correctness of the following note can perceive both as correct...
    like singing in an entirely different *key*!)

    <https://neurosciencenews.com/pitch-detection-music-21087/>

    This is a reference note (middle C) followed by the same note "soured"
    by 12 cents:

    <https://en.wikipedia.org/wiki/File:Sines_12_cent_difference.wav>

    Chances are, you can't tell the difference hearing them
    in sequence. If you heard just *one*, you'd not be able to tell if it
    was correct, or not. The third sound sample plays both simultaneously
    so you can hear them beating against each other -- the difference then becomes very noticeable!

    Here's *one* cent difference:

    <https://en.wikipedia.org/wiki/File:Sines_1_cent_difference.wav>

    And 24 cents (about the point of "normal" perception):

    <https://en.wikipedia.org/wiki/File:Sines_24_cent_difference.wav>

    If your device's *timing* was off by 0.05%, would that be consequential?

    https://youtu.be/AFaRIW-wZlw?t=54

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to '''newspam'''@nonad.co.uk on Fri Jul 22 11:21:16 2022
    On Thu, 21 Jul 2022 18:21:51 +0100, Martin Brown
    <'''newspam'''@nonad.co.uk> 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.

    Ever read the actual 488 spec? There is a state diagram that could
    wreck your sleep for a week.

    488 has a hardware "accepted" line, but for some reason SCPI in other
    contexts is send-and-pray.

    488 is rare on new instruments, which are ethernet and USB. A Rigol
    scope makes a great USB power supply for fans and charging phones.



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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to presence@MUNGEpanix.com on Fri Jul 22 12:07:07 2022
    On Fri, 22 Jul 2022 16:54:07 -0000 (UTC), Cydrome Leader <presence@MUNGEpanix.com> wrote:

    jlarkin@highlandsniptechnology.com wrote:
    On Fri, 22 Jul 2022 10:37:53 +0200, Gerhard Hoffmann <dk4xp@arcor.de>
    wrote:

    Am 22.07.22 um 04:47 schrieb jlarkin@highlandsniptechnology.com:

    Where does the 10 MHz come from?

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

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

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

    No. The 1pps is asserted when the CPU thinks it's closest to
    the "right" clockcycle. It could be off by half a cycle.
    There is no need for 10 MHz, one could have chosen a nice
    multiple of the desired baud rate.


    Our GPS receivers output 1 PPS and 10 MHz. Argue with Wikipedia.

    What he's trying to say is it may not be perfect 10 million cycles between >every 1PPS pulse. For most stuff, this is good enough. For the metrology >folks, using strong words like exactly or in this case "locked" will
    always cause an argument.

    No, the 1 PPS is sometimes generated by uP code, and sometimes jumps
    back and forth around ticks of some other clock. It's like a rubidium,
    ugly and nasty but long-term average excellent. I get the impression
    that a GPS box that outputs 10 MHz, gets the 10M by locking to the 1
    PPS.

    The nasty 1 PPS is the bottom line of the GPS frequency standard.

    Real stability on less-than-weeks time frames comes from the flywheel
    effect of a very good 10 MHz oscillator and a very slow control loop.

    Which is my problem, absolutely time locking a bunch of 40 MHz
    oscillators from a 1 PPS pulse generated by, essentially, a relay
    driver.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to presence@MUNGEpanix.com on Fri Jul 22 11:42:06 2022
    On Fri, 22 Jul 2022 16:41:40 -0000 (UTC), Cydrome Leader <presence@MUNGEpanix.com> wrote:

    jlarkin@highlandsniptechnology.com wrote:
    On Fri, 22 Jul 2022 06:20:58 -0000 (UTC), Cydrome Leader
    <presence@MUNGEpanix.com> wrote:

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

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

    Am 21.07.22 um 01:20 schrieb John Larkin:


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

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

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

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


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

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

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

    Where does the 10 MHz come from?

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

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

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

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

    GPS timing isn't completely perfect in reality. Antennas blow off roofs, >>>contractors cut cables etc. Even losing sync for a minute is sort of a big >>>deal. As you mentioned, jitter is the real problem. There are tradeoffs to >>>making a flywheel thats too heavy so to speak.

    For really fussy stuff, one might have multiple GPS receivers and a quorum >>>of local 10Mhz oscillators. In fact, 10Mhz is a dinosaur relic for modern >>>stuff too. We've got racks of 10Mhz oscillators and equipment to monitor >>>any phase shift between local oscillators and GPS sources. It's all going >>>to the dumpster when somebody finally notices it's been powered down and >>>forgotten about.

    Fairly accurate nS resolution timing is possible in computers these days, >>>with the right tricks.

    I triggered a scope from a very good ovenized XO and looked at the
    rising edge of a rubidium. The edge looked solid, as if it was
    internal triggered. Checking every 20 minutes or so, it ws slowly
    creeping across the screen, at 5 ns/cm.

    I believe they somehow pair the rubidium clocks with another quartz
    crystal, even in those new tiny physics modules. I've not had a chance to >tear apart a rubidium clock yet, or the ovenized stuff. They come in
    little metal boxes, that remind me of TV tuners.

    The rubidium physics/optics is noisy and nasty short-term. It usually disciplines a very good VCO or VCOCXO. I have a schematic somewhere
    around here; I'll look for it.


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

    Do you have to worry about fun issues like an the timestamp of a signal >>>being received before it was even transmitted between pieces of equipment? >>
    It a multi-channel power supply!

    You were also asking about timestamping in other posts. Not entirely sure >what you're upto in the end, but it might be interesting.

    Trying to get multiple power supplies and loads to act together so
    people can run, say, a modestly complex power sequence and load test
    on some gear and loop that for days or weeks and stay coordinated.
    Each box has 8 plugins, which naturally share the same timebase, but I
    want to extend time coordination to multiple boxes. So, time lock
    their XOs long-term, and start all the individual sequencers
    simultaneously.

    My customers complain about how nasty it is to organize a heap of
    purchased ac and dc supplies and dummy loads and relay drivers, to
    millisecond resolution, with a mess of weird interfaces.

    Here's the basic idea. It's still evolving.

    https://www.dropbox.com/s/5byvlk8uh9n23e3/P940_PD14np.pdf?dl=0

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to langwadt@fonz.dk on Fri Jul 22 16:01:13 2022
    On Fri, 22 Jul 2022 10:54:30 -0700 (PDT), Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

    fredag den 22. juli 2022 kl. 16.46.36 UTC+2 skrev Don Y:
    On 7/22/2022 7:17 AM, Don wrote:
    Don Y wrote:
    Don wrote:
    Don Y wrote:
    bitrex wrote:

    <snip>

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

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

    In this case, isn't "really well" defined as an absence of sour note(s)? >> >>
    That assumes the synthesis uses the same clock as timing. I think the
    discussion here has been wrt durations/intervals.

    How sensitive are *your* ears to noticing small differences in pitch,
    absence a comparative reference? Can you discern a difference of a few
    cents ("perfect pitch")?

    Can't everyone's ears (except perhaps the autistic tone-deaf and such)
    hear a sour note relative to the preceding note? Do you need to name a
    note (perfect pitch) in order to hear its sourness?
    Perfect pitch is more than just "naming a note".
    It's all but impossible for me personally to ignore the sourness of
    cringeworthy, awkward note(s). Sour notes make me want to get out of
    earshot.
    How "sour" does the note have to be before it is perceptible, as such.
    A cent? Two? Fifty? A semitone?? (about a 25 cents is typical for
    the average, non-musician, listener to be able to detect -- without
    context; i.e., if the "previous note" was similarly sour, your estimation
    of the correctness of the following note can perceive both as correct...
    like singing in an entirely different *key*!)

    <https://neurosciencenews.com/pitch-detection-music-21087/>

    This is a reference note (middle C) followed by the same note "soured"
    by 12 cents:

    <https://en.wikipedia.org/wiki/File:Sines_12_cent_difference.wav>

    Chances are, you can't tell the difference hearing them
    in sequence. If you heard just *one*, you'd not be able to tell if it
    was correct, or not. The third sound sample plays both simultaneously
    so you can hear them beating against each other -- the difference then
    becomes very noticeable!

    Here's *one* cent difference:

    <https://en.wikipedia.org/wiki/File:Sines_1_cent_difference.wav>

    And 24 cents (about the point of "normal" perception):

    <https://en.wikipedia.org/wiki/File:Sines_24_cent_difference.wav>

    If your device's *timing* was off by 0.05%, would that be consequential?

    https://youtu.be/AFaRIW-wZlw?t=54

    My recollection is the for a chorus to be in unison, all the singers
    must be within twenty milliseconds of one another.

    This is discussed a lot in the computer music literature.

    Joe Gwinn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to All on Fri Jul 22 16:36:56 2022
    On Thu, 21 Jul 2022 04:17:14 -0700, jlarkin@highlandsniptechnology.com
    wrote:

    On Wed, 20 Jul 2022 23:49:40 -0700 (PDT), whit3rd <whit3rd@gmail.com>
    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?

    It's actually a time lock problem. If a follower box starts up and
    sees its first 1 PPS input, it can thereafter declare 1 PPS internal
    events, based on its local VCO, and then do successive early/late
    comparisons to the external pulses. And trim its VCXO accordingly.

    Yes, exactly. And the drift between two reasonably good clocks is
    slow, so the correction need not and should not be all that fast.

    What I've done in real applications is to periodically measure the
    offset between when the external 1PPS is predicted to happen and when
    it actually does, and adjust the VCO frequency such that in say 50
    seconds of roughly linear convergence they will coincide (and keep on
    going). The process is repeated every few seconds (exact interval not important as it is measured).

    This is roughly the algorithm a helmsman uses while steering a
    sailboat, where effect is very much delayed from action.

    In many computer systems it is quite difficult to do anything on a
    strict time mark, but easy to measure that actual elapsed time, using
    the actual clock that is being steered - it all still converges, so
    long as one doesn't try too hard.

    So, in your example, the local clock would come from a 40 MHz VCO of
    good manufacture (probably needs to be a TCXO of some sort). The 40
    MHz output would be fed to a divider that puts out a 1PPS pulse train.

    During initialization, when the first external 1PPS leading edge is
    received, reset the divider, and start counting 40 MHz cycles. Maybe
    wait for things to stabilize.

    Thereafter, measure signed offset between external and internal 1PPS
    leading edges, and compute how much change (plus or minus) in current
    VCO frequency is required for zero offset to occur in say 50 seconds
    (make this time-to-zero an adjustable parameter), and change the VCO
    control voltage accordingly.

    A few seconds later (also an adjustable parameter), repeat the above
    adjustment process, again looking 50 seconds into the future from now.
    Repeat forever.

    Steering to within one microsecond should be easy. Any number of
    units can be following this external 1PPS signal without knowing that
    one another even exist.

    Beware of one thing: The 1PPS coax output from many GPS receivers is
    designed to drive a 50-ohm *resistor*, not a 50-ohm transmission line.
    You may need a 3dB pad right at the GPS Receiver chassis between 1PPS
    output and coaxial cable to get sharp leading edges at the far end of
    the coaxial cable. The classic symptom of trouble is when an o'scope
    cannot sync reliably to the 1PPS.

    Also, I'd lose the BNC connectors. Threaded connectors like SMA, TNC,
    and Type N are far better.

    Or use shielded twisted pair to carry the 1PPS pulses. This would
    work better over a backplane.

    Joe Gwinn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to John Walliker on Fri Jul 22 13:44:05 2022
    On 7/22/2022 10:03 AM, John Walliker wrote:
    There is cross-correlation between left and right ears in the brainstem which is involved in determining the direction of sound sources. Detectable time differences are remarkably small. (I would have to look it up to give a number.)

    Direction (as well as elevation) is primarily determined by time differences (Interaural Time Differences -- ITDs) and intensity differences (IIDs) as
    the head casts an auditory "shadow" on the "far" ear. The shadow attenuates higher frequencies, more. So, the brain localizes different types of sound (frequency ranges) with different mechanisms (low frequencies exhibit less attenuation but have longer periods in which to detect phase differences, etc.)

    [There's considerable study on this in improving detection of emergency
    vehicle "sirens" by altering the content of said siren to facilitate
    this human process]

    The "wearer's" <grin> pinnae further shape the frequency response so
    each *individual* can further refine their notion of left/right, front/back, up/down. This is highly "wearer specific", though.

    Additionally, the presence of reflective surfaces gives multipath information to the listener; one perceives sound differently in open space than in
    an enclosed room. For repetitive sounds, you can often find folks turning or tilting their heads to better localize the source.

    You can manipulate the sounds delivered to each ear (via headphones) and simulate the direction of a source, to some degree. I use this "spatializer" effect to differentiate between different message types delivered to a
    user -- a female voice off to the left might issue reminders while a
    male voice to the right issues error messages -- both while a "chosen voice" dead ahad provides primary narration.

    ["Voices" can also be replaced by "annunciators". So, a chime off to
    one side can be "registered" as having a particular meaning without
    drawing the user's attention away from the narrative. Empirically,
    it seems that folks can remember said events, even if one-shots,
    more than they can remember sequences of sound that is otherwise devoid
    of message]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don@21:1/5 to Joe Gwinn on Fri Jul 22 21:38:39 2022
    Joe Gwinn wrote:

    <snip>

    Also, I'd lose the BNC connectors. Threaded connectors like SMA, TNC,
    and Type N are far better.

    Or use shielded twisted pair to carry the 1PPS pulses. This would
    work better over a backplane.

    This is good advice. Even though the lazy guy within me never truly
    gives up his fight to take the easy way out with BNC.
    Twisted pair (TP) sounds even easier than BNC. So, what's the
    "catch" with TP? Where's the "gotcha" to make TP harder than BNC?

    Danke,

    --
    Don, KB7RPU, https://www.qsl.net/kb7rpu
    There was a young lady named Bright Whose speed was far faster than light;
    She set out one day In a relative way And returned on the previous night.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Joe Gwinn on Fri Jul 22 14:43:51 2022
    On 7/22/2022 1:01 PM, Joe Gwinn wrote:
    On Fri, 22 Jul 2022 10:54:30 -0700 (PDT), Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

    If your device's *timing* was off by 0.05%, would that be consequential?

    https://youtu.be/AFaRIW-wZlw?t=54

    Note context of post...

    My recollection is the for a chorus to be in unison, all the singers
    must be within twenty milliseconds of one another.

    This is discussed a lot in the computer music literature.

    Things get "painful" at about 50ms. I suspect your brain tries to
    consider them as different events instead of indistinguishable.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Don on Fri Jul 22 14:46:01 2022
    On 7/22/2022 9:02 AM, Don wrote:
    Don Y wrote:

    In the context of this thread, it likely has an impact. A cent is
    about 500PPM (though in the frequency domain)

    Your question about a one cent following note difference perception is interesting. And, it needs to be followed up by me, so to speak. :)
    For some unknown reason, the only thing to truly satisfy me is to
    tune instruments by ear.

    You're lucky if you can do so -- to the extent the artist(s) trust(s)
    your results.

    I simply want "correct" -- by whatever expedient gets me there, quickest!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to Don on Fri Jul 22 18:14:56 2022
    On Fri, 22 Jul 2022 21:38:39 -0000 (UTC), "Don" <g@crcomp.net> wrote:

    Joe Gwinn wrote:

    <snip>

    Also, I'd lose the BNC connectors. Threaded connectors like SMA, TNC,
    and Type N are far better.

    Or use shielded twisted pair to carry the 1PPS pulses. This would
    work better over a backplane.

    This is good advice. Even though the lazy guy within me never truly
    gives up his fight to take the easy way out with BNC.
    Twisted pair (TP) sounds even easier than BNC. So, what's the
    "catch" with TP? Where's the "gotcha" to make TP harder than BNC?

    Depends on what you are trying to do.

    For nanosecond edges, coax is pretty useful, but short range and often mechanically awkward.

    For microsecond edges at 1000 meters, RS422 over shielded twisted pair
    is pretty good.

    For bus length links, LVDS or the like.

    And so on. And there is always optical links.

    Joe Gwinn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Fri Jul 22 16:52:46 2022
    fredag den 22. juli 2022 kl. 23.44.07 UTC+2 skrev Don Y:
    On 7/22/2022 1:01 PM, Joe Gwinn wrote:
    On Fri, 22 Jul 2022 10:54:30 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:

    If your device's *timing* was off by 0.05%, would that be consequential? >>
    https://youtu.be/AFaRIW-wZlw?t=54
    Note context of post...
    My recollection is the for a chorus to be in unison, all the singers
    must be within twenty milliseconds of one another.

    This is discussed a lot in the computer music literature.
    Things get "painful" at about 50ms. I suspect your brain tries to
    consider them as different events instead of indistinguishable.

    afaiu the limit for a phone system is >25ms round trip before you need echo canceling

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Lasse Langwadt Christensen on Fri Jul 22 17:10:30 2022
    On 7/22/2022 4:52 PM, Lasse Langwadt Christensen wrote:
    fredag den 22. juli 2022 kl. 23.44.07 UTC+2 skrev Don Y:
    On 7/22/2022 1:01 PM, Joe Gwinn wrote:
    On Fri, 22 Jul 2022 10:54:30 -0700 (PDT), Lasse Langwadt Christensen
    <lang...@fonz.dk> wrote:

    If your device's *timing* was off by 0.05%, would that be consequential? >>>>
    https://youtu.be/AFaRIW-wZlw?t=54
    Note context of post...
    My recollection is the for a chorus to be in unison, all the singers
    must be within twenty milliseconds of one another.

    This is discussed a lot in the computer music literature.
    Things get "painful" at about 50ms. I suspect your brain tries to
    consider them as different events instead of indistinguishable.

    afaiu the limit for a phone system is >25ms round trip before you need echo canceling

    Yes, but that addresses quality. A phone is still usable with
    noticeable echo, esp if the echo is many dB down.

    It seems like the brain has some (temporal) threshold beyond which it
    can no longer treat things as being concurrent and starts a new "recognition process" (so to speak) to deal with the "other" event.

    E.g., audible feedback on a keypress that is "too late" is more than
    just annoying; it impacts how you interact with that device.

    Audio out of sync with video also has an oversized impact on
    your tolerance for the information channel(s). (*Why* do we care if
    the lips are out of sync with the sound? It's more than just
    irritating...)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Fri Jul 22 17:24:32 2022
    lørdag den 23. juli 2022 kl. 02.10.41 UTC+2 skrev Don Y:
    On 7/22/2022 4:52 PM, Lasse Langwadt Christensen wrote:
    fredag den 22. juli 2022 kl. 23.44.07 UTC+2 skrev Don Y:
    On 7/22/2022 1:01 PM, Joe Gwinn wrote:
    On Fri, 22 Jul 2022 10:54:30 -0700 (PDT), Lasse Langwadt Christensen
    <lang...@fonz.dk> wrote:

    If your device's *timing* was off by 0.05%, would that be consequential?

    https://youtu.be/AFaRIW-wZlw?t=54
    Note context of post...
    My recollection is the for a chorus to be in unison, all the singers
    must be within twenty milliseconds of one another.

    This is discussed a lot in the computer music literature.
    Things get "painful" at about 50ms. I suspect your brain tries to
    consider them as different events instead of indistinguishable.

    afaiu the limit for a phone system is >25ms round trip before you need echo canceling
    Yes, but that addresses quality. A phone is still usable with
    noticeable echo, esp if the echo is many dB down.

    sure, but it seems that below ~25ms it is not noticable

    It seems like the brain has some (temporal) threshold beyond which it
    can no longer treat things as being concurrent and starts a new "recognition process" (so to speak) to deal with the "other" event.

    at big concerts with speaker towers for the people far away from the stage those speakers gets delayed so they are 10-15ms behind the sound from the stage
    giving the illusion that all the sound is from the main Pa at the stage


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Fri Jul 22 17:16:00 2022
    fredag den 22. juli 2022 kl. 22.37.08 UTC+2 skrev Joe Gwinn:
    On Thu, 21 Jul 2022 04:17:14 -0700, jla...@highlandsniptechnology.com
    wrote:

    On Wed, 20 Jul 2022 23:49:40 -0700 (PDT), whit3rd <whi...@gmail.com>
    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?

    It's actually a time lock problem. If a follower box starts up and
    sees its first 1 PPS input, it can thereafter declare 1 PPS internal >events, based on its local VCO, and then do successive early/late >comparisons to the external pulses. And trim its VCXO accordingly.

    Yes, exactly. And the drift between two reasonably good clocks is
    slow, so the correction need not and should not be all that fast.

    What I've done in real applications is to periodically measure the
    offset between when the external 1PPS is predicted to happen and when
    it actually does, and adjust the VCO frequency such that in say 50
    seconds of roughly linear convergence they will coincide (and keep on
    going). The process is repeated every few seconds (exact interval not important as it is measured).

    This is roughly the algorithm a helmsman uses while steering a
    sailboat, where effect is very much delayed from action.

    In many computer systems it is quite difficult to do anything on a
    strict time mark, but easy to measure that actual elapsed time, using
    the actual clock that is being steered - it all still converges, so
    long as one doesn't try too hard.

    So, in your example, the local clock would come from a 40 MHz VCO of
    good manufacture (probably needs to be a TCXO of some sort). The 40
    MHz output would be fed to a divider that puts out a 1PPS pulse train.

    During initialization, when the first external 1PPS leading edge is
    received, reset the divider, and start counting 40 MHz cycles. Maybe
    wait for things to stabilize.

    Thereafter, measure signed offset between external and internal 1PPS
    leading edges, and compute how much change (plus or minus) in current
    VCO frequency is required for zero offset to occur in say 50 seconds
    (make this time-to-zero an adjustable parameter), and change the VCO
    control voltage accordingly.

    A few seconds later (also an adjustable parameter), repeat the above adjustment process, again looking 50 seconds into the future from now.
    Repeat forever.


    isn't that kind how NTP works?, speeding up or slowing down over some period
    to sync time with the server without big jumps and always increasing (except possibly at start up)

    come to think of it, some closed loop servo systems (and step generators) for things like CNC machine work similarly
    at a fixed interval, say a few kHz, current target and actual position is compared, from that (usually with a PI loop)
    the speed of the motor (or frequency of steps) is set so the position will hit the next target at the next timer tick

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to Joe Gwinn on Fri Jul 22 21:12:31 2022
    Joe Gwinn wrote:
    On Fri, 22 Jul 2022 21:38:39 -0000 (UTC), "Don" <g@crcomp.net> wrote:

    Joe Gwinn wrote:

    <snip>

    Also, I'd lose the BNC connectors. Threaded connectors like SMA, TNC,
    and Type N are far better.

    Or use shielded twisted pair to carry the 1PPS pulses. This would
    work better over a backplane.

    This is good advice. Even though the lazy guy within me never truly
    gives up his fight to take the easy way out with BNC.
    Twisted pair (TP) sounds even easier than BNC. So, what's the
    "catch" with TP? Where's the "gotcha" to make TP harder than BNC?

    Depends on what you are trying to do.

    For nanosecond edges, coax is pretty useful, but short range and often mechanically awkward.

    For microsecond edges at 1000 meters, RS422 over shielded twisted pair
    is pretty good.

    For bus length links, LVDS or the like.

    And so on. And there is always optical links.

    Joe Gwinn


    BNCs are the bomb, as long as you aren't putting 500 of them in series,
    as with the old 10base2 coax Ethernet.

    TNCs are a very small niche, and N connectors belong only on spectrum analyzers.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Don Y on Fri Jul 22 18:18:51 2022
    On 7/22/2022 6:16 PM, Don Y wrote:
    On 7/22/2022 5:24 PM, Lasse Langwadt Christensen wrote:
    at big concerts with speaker towers for the people far away from the stage >> those speakers gets delayed so they are 10-15ms behind the sound from the stage
    giving the illusion that all the sound is from the main Pa at the stage

    I was near the close-in towers off stage left:

    <http://3.bp.blogspot.com/-syHkjhoSSr8/VeV32eq-8EI/AAAAAAABw1w/ippl8bx8kKE/s1600/Grateful%2BDead%2Blive%2Bin%2BRaceway%2BPark%252C%2B1977%2B%252816%2529.jpg>

    Shot from a different viewpoint: <http://media.gettyimages.com/photos/more-than-125000-rock-fans-from-down-the-road-and-across-the-nation-picture-id127330716>

    The fence is made from "semi" trailers to give an idea of scale.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to Lasse Langwadt Christensen on Fri Jul 22 18:16:27 2022
    On 7/22/2022 5:24 PM, Lasse Langwadt Christensen wrote:
    lørdag den 23. juli 2022 kl. 02.10.41 UTC+2 skrev Don Y:
    On 7/22/2022 4:52 PM, Lasse Langwadt Christensen wrote:
    fredag den 22. juli 2022 kl. 23.44.07 UTC+2 skrev Don Y:
    On 7/22/2022 1:01 PM, Joe Gwinn wrote:
    On Fri, 22 Jul 2022 10:54:30 -0700 (PDT), Lasse Langwadt Christensen >>>>> <lang...@fonz.dk> wrote:

    If your device's *timing* was off by 0.05%, would that be consequential?

    https://youtu.be/AFaRIW-wZlw?t=54
    Note context of post...
    My recollection is the for a chorus to be in unison, all the singers >>>>> must be within twenty milliseconds of one another.

    This is discussed a lot in the computer music literature.
    Things get "painful" at about 50ms. I suspect your brain tries to
    consider them as different events instead of indistinguishable.

    afaiu the limit for a phone system is >25ms round trip before you need echo canceling
    Yes, but that addresses quality. A phone is still usable with
    noticeable echo, esp if the echo is many dB down.

    sure, but it seems that below ~25ms it is not noticable

    It seems like the brain has some (temporal) threshold beyond which it
    can no longer treat things as being concurrent and starts a new "recognition >> process" (so to speak) to deal with the "other" event.

    at big concerts with speaker towers for the people far away from the stage those speakers gets delayed so they are 10-15ms behind the sound from the stage
    giving the illusion that all the sound is from the main Pa at the stage

    I was near the close-in towers off stage left:

    <http://3.bp.blogspot.com/-syHkjhoSSr8/VeV32eq-8EI/AAAAAAABw1w/ippl8bx8kKE/s1600/Grateful%2BDead%2Blive%2Bin%2BRaceway%2BPark%252C%2B1977%2B%252816%2529.jpg>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Les Cargill@21:1/5 to Phil Hobbs on Fri Jul 22 20:54:49 2022
    Phil Hobbs wrote:
    jlarkin@highlandsniptechnology.com wrote:
    <snip>

    It dithers around the setpoint but nobody notices.


    That's what lowpass filters are for.

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


    Well, yeah - it's naturally constrained. When I jack the temp target on
    the A/C here, it take 30-45 seconds to turn everything off.


    Tim used to be a lot of fun and put up with much. FWIW rbj showed up
    on Reddit and lasted a couple days.

    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.


    You're just doing trust falls with slew rate limiting. :) There's
    probably a PhD paper somewhere with a madman low-pass filtering the
    output of a bangbang with a lowpass.

    Kinda like... the .047 uf cap in the tone circuit on a Telecaster :)
    It's there to limit damage.

    Cheers

    Phil Hobbs


    --
    Les Cargill

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Les Cargill@21:1/5 to John Larkin on Fri Jul 22 20:39:25 2022
    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.


    "Her" clock is not necessarily as stable as the 1PPS. How quickly does
    it need to converge? Is this just a "make it a wee bit better" thing or
    do you have a specific jitter spectrum in mind?

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


    "... and the other is a
    time-locked loop in the 1023 bit code space domain with the goal of
    tracking both the code and carrier phases for that signal."

    http://www.gpsinformation.net/main/gpslock.htm

    That sounds suspiciously like what I did ( in software ) for a
    terrestrial radio system once. The FPGA gave me a few bits of tuning
    data and it was a state machine. I *think* the output was a
    counter-delta value back to the FPGA. That was in the long ago.

    I put trimpots in the management plane , put those in a GUI
    and let the FPGA guy tune it. He was ecstatic and it beat
    him running back and forth.

    He tested it over coax; never did understand why this was needed at all
    unless you were over air/free space. The analog PLLs should have handled
    it. I think the RF amps we were using were pretty awful and not being
    run in a very linear range. System leaned heavily on some bandlimiting
    ( SAW ) filters.


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


    A second is a long time. GPS is a couple of nanoseconds per day
    to a few msec. Yer average computer will go off to see the wizard and
    back in a day.


    The PLL algorithm might be interesting.


    It felt more like a "goalie" algorithm than a PLL. But it did show
    a measurable improvement. It's not really even an algorithm. It's a
    "bang bang" controller. Nine pound hammer in software.

    --
    Les Cargill

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Fri Jul 22 19:09:07 2022
    lørdag den 23. juli 2022 kl. 03.57.33 UTC+2 skrev Les Cargill:
    bitrex wrote:
    On 7/20/2022 8:22 PM, 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.

    It sounds like you're looking for a protocol like DMX if what you want
    is to trigger sequences of events across boxes to within a millisecond,
    I don't understand what this lock-the-40 MHz across boxes is about.

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




    DMX for this is like hunting deer with an artillery piece. DMX is for
    the big-ass risk scenarios in distributed topologies; this is a lot
    less profound.

    ? it's a 250kbit uart on RS485, hardly rocket surgery

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Les Cargill@21:1/5 to bitrex on Fri Jul 22 20:57:27 2022
    bitrex wrote:
    On 7/20/2022 8:22 PM, 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.

    It sounds like you're looking for a protocol like DMX if what you want
    is to trigger sequences of events across boxes to within a millisecond,
    I don't understand what this lock-the-40 MHz across boxes is about.

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




    DMX for this is like hunting deer with an artillery piece. DMX is for
    the big-ass risk scenarios in distributed topologies; this is a lot
    less profound.

    --
    Les Cargill

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Les Cargill@21:1/5 to jlarkin@highlandsniptechnology.com on Fri Jul 22 21:10:35 2022
    jlarkin@highlandsniptechnology.com wrote:
    On Thu, 21 Jul 2022 11:42:28 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:
    <snip>
    Phil Hobbs

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


    Engineering is composition. Composition is the thin edge of the musical
    wedge. Musicianship is different; it's pattern identification. As is composition but in a different way. But it is all the same thing.

    It all depends on which wall you prefer to have your back against.

    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?

    Over where they MATLAB.

    --
    Les Cargill

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From bitrex@21:1/5 to Lasse Langwadt Christensen on Fri Jul 22 22:51:47 2022
    On 7/22/2022 10:09 PM, Lasse Langwadt Christensen wrote:
    lørdag den 23. juli 2022 kl. 03.57.33 UTC+2 skrev Les Cargill:
    bitrex wrote:
    On 7/20/2022 8:22 PM, 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.

    It sounds like you're looking for a protocol like DMX if what you want
    is to trigger sequences of events across boxes to within a millisecond,
    I don't understand what this lock-the-40 MHz across boxes is about.

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




    DMX for this is like hunting deer with an artillery piece. DMX is for
    the big-ass risk scenarios in distributed topologies; this is a lot
    less profound.

    ? it's a 250kbit uart on RS485, hardly rocket surgery


    Right, it's glorified MIDI.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don@21:1/5 to Phil Hobbs on Sat Jul 23 03:58:28 2022
    Phil Hobbs wrote:
    Joe Gwinn wrote:
    Don wrote:
    Joe Gwinn wrote:

    <snip>

    Also, I'd lose the BNC connectors. Threaded connectors like SMA, TNC, >>>> and Type N are far better.

    Or use shielded twisted pair to carry the 1PPS pulses. This would
    work better over a backplane.

    This is good advice. Even though the lazy guy within me never truly
    gives up his fight to take the easy way out with BNC.
    Twisted pair (TP) sounds even easier than BNC. So, what's the
    "catch" with TP? Where's the "gotcha" to make TP harder than BNC?

    Depends on what you are trying to do.

    For nanosecond edges, coax is pretty useful, but short range and often
    mechanically awkward.

    For microsecond edges at 1000 meters, RS422 over shielded twisted pair
    is pretty good.

    For bus length links, LVDS or the like.

    And so on. And there is always optical links.

    Joe Gwinn


    BNCs are the bomb, as long as you aren't putting 500 of them in series,
    as with the old 10base2 coax Ethernet.

    TNCs are a very small niche, and N connectors belong only on spectrum analyzers.

    The lazy guy within me always tries to use an N connector to BNC
    adapter on my boat anchor spectrum analyzer. He convinces himself he's
    only interested in frequencies less than 2 GHz, so, what's the harm?

    High performance WiFi antennas also use N connectors to squeeze out
    every last iota of performance. You need a DIY N connector to reverse-
    polarity SMA to connect such antennas to consumer WiFi devices.

    Danke,

    --
    Don.......My cat's )\._.,--....,'``. https://crcomp.net/reviews.php telltale tall tail /, _.. \ _\ (`._ ,.
    tells tall tales.. `._.-(,_..'--(,_..'`-.;.'

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From whit3rd@21:1/5 to Don on Fri Jul 22 21:07:32 2022
    On Friday, July 22, 2022 at 2:38:45 PM UTC-7, Don wrote:
    Joe Gwinn wrote:

    <snip>
    Also, I'd lose the BNC connectors. Threaded connectors like SMA, TNC,
    and Type N are far better.

    Or use shielded twisted pair to carry the 1PPS pulses.

    Twisted pair (TP) sounds even easier than BNC. So, what's the
    "catch" with TP? Where's the "gotcha" to make TP harder than BNC?

    Biggest 'gotcha' is the lack of good shielded TP connectors. I had only UHF-style twisted pair shielded connectors last time I wanted some, and
    that's a polarity-insensitive connector. We applied paint markings
    to get it straight.

    MiniDIN 3 (don't trust the shield connector) was what Apple used for their LocalTalk/Appletalk hardware, and of course there are microphone connectors (big 'uns))
    but for cheap 'uns, RJ--11 (6P4C and use the second pair) wasn't good (I needed to
    pass significant current) and Lemo offerings were... neither inexpensive nor locally stocked.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Clifford Heath@21:1/5 to Don on Sat Jul 23 16:35:12 2022
    On 23/7/22 02:02, Don wrote:
    For some unknown reason, the only thing to truly satisfy me is to
    tune instruments by ear.
    Many instruments (including all stringed instruments) exhibit
    inharmonicity. In the case of strings the harmonics are progressively
    sharper than the numerical frequency multiples. So to produce an
    even-tempered tuning requires balancing the matching of fundamentals
    with the harmonics. It's not an exact science.

    Piano's are "stretch tuned" by as much as two semitones between the
    bottom octave and the top one, and professional pianists have personal preferences for more or less stretching.

    You could program an electronic tuner to do this of course, but you
    can't easily tell it how much stretching you'd like.

    Clifford Heath

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Clifford Heath@21:1/5 to John Walliker on Sat Jul 23 16:42:03 2022
    On 23/7/22 03:03, John Walliker wrote:
    There is cross-correlation between left and right ears in the brainstem which is involved in determining the direction of sound sources. Detectable time differences are remarkably small. (I would have to look it up to give a number.)

    It seems like a chip-based cross-correlator would be pretty trivial.
    A pair of bucket-brigade lines running parallel but in opposite
    directions, and a correlator at each node. Frequency response of each correlator would be based on the delta-wavelength of one bucket in the
    chains.

    You could read out the relative directions of all sound sources by
    looking at the left-right correlation histogram

    CH

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gerhard Hoffmann@21:1/5 to All on Sat Jul 23 10:11:57 2022
    Am 23.07.22 um 08:35 schrieb Clifford Heath:
    On 23/7/22 02:02, Don wrote:
         For some unknown reason, the only thing to truly satisfy me is to >> tune instruments by ear.
    Many instruments (including all stringed instruments) exhibit
    inharmonicity. In the case of strings the harmonics are progressively
    sharper than the numerical frequency multiples. So to produce an even-tempered tuning requires balancing the matching of fundamentals
    with the harmonics. It's not an exact science.

    Piano's are "stretch tuned" by as much as two semitones between the
    bottom octave and the top one, and professional pianists have personal preferences for more or less stretching.

    You could program an electronic tuner to do this of course, but you
    can't easily tell it how much stretching you'd like.

    Most seem to like a lot. Remember WhiteSnake's text (in Kittens got claws):

    "with her g string tuned to A" !


    Gerhard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to John Larkin on Sat Jul 23 09:41:32 2022
    On 22/07/2022 19:21, John Larkin wrote:
    On Thu, 21 Jul 2022 18:21:51 +0100, Martin Brown
    <'''newspam'''@nonad.co.uk> wrote:

    On 21/07/2022 16:31, John Walliker wrote:

    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.

    Ever read the actual 488 spec? There is a state diagram that could
    wreck your sleep for a week.

    I've implemented it on several chipsets including Motorola 68488, Intel
    8292 and TI 9914. We even implemented full pass control between peer controllers and our own bus analyser to capture bus transactions (which
    after a redesign could not be blinded by HP's IFC tricks).

    Later we reworked things for IEEE488.2 in the early 1990's but I dropped
    out of that game not long afterwards to go and work in Japan. Ethernet
    had made significant inroads into the instrument market by then.

    488 has a hardware "accepted" line, but for some reason SCPI in other contexts is send-and-pray.

    And the accepted line makes sure the slowest thing on the bus gets the
    message which is why it tended to slow down as longer cables and more
    kit was added. It tolerated much longer cables than the official
    standard permitted with only modest loss of speed.

    488 is rare on new instruments, which are ethernet and USB. A Rigol
    scope makes a great USB power supply for fans and charging phones.

    It surprises me that it is still present on *any* modern instruments.
    I expected it to survive on useful legacy kit until about now though.

    Plenty of labs will have good working kit that still uses that interface
    and it is plenty fast enough for a lot of ordinary lab use.

    --
    Regards,
    Martin Brown

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to All on Sat Jul 23 03:25:32 2022
    On Fri, 22 Jul 2022 21:10:35 -0500, Les Cargill <lcargil99@gmail.com>
    wrote:

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

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


    Engineering is composition. Composition is the thin edge of the musical >wedge. Musicianship is different; it's pattern identification. As is >composition but in a different way. But it is all the same thing.

    It all depends on which wall you prefer to have your back against.

    I've always wondered about musicians. They have to play a piece
    hundreds of times to get it right. Some have surely performed
    something thousands of times. Don't they get bored? Apparently not.

    I design something, finish, and then want to design something entirely different.

    It depends on boredom thresholds.


    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?

    Over where they MATLAB.

    SCPI is send-and-forget. There is some query you can send to ask if
    the last command worked. And you can have an error queue that you can interrogate now and then for historical forensics.

    I told the customer that damn the specs, every command is going to
    reply with data, an error message, or "OK". They agree.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to Martin Brown on Sat Jul 23 12:12:10 2022
    Martin Brown wrote:
    On 22/07/2022 19:21, John Larkin wrote:
    On Thu, 21 Jul 2022 18:21:51 +0100, Martin Brown
    <'''newspam'''@nonad.co.uk> wrote:

    On 21/07/2022 16:31, John Walliker wrote:

    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.

    Ever read the actual 488 spec? There is a state diagram that could
    wreck your sleep for a week.

    I've implemented it on several chipsets including Motorola 68488, Intel
    8292 and TI 9914. We even implemented full pass control between peer controllers and our own bus analyser to capture bus transactions (which
    after a redesign could not be blinded by HP's IFC tricks).

    Later we reworked things for IEEE488.2 in the early 1990's but I dropped
    out of that game not long afterwards to go and work in Japan. Ethernet
    had made significant inroads into the instrument market by then.

    488 has a hardware "accepted" line, but for some reason SCPI in other
    contexts is send-and-pray.

    And the accepted line makes sure the slowest thing on the bus gets the message which is why it tended to slow down as longer cables and more
    kit was added. It tolerated much longer cables than the official
    standard permitted with only modest loss of speed.

    488 is rare on new instruments, which are ethernet and USB. A Rigol
    scope makes a great USB power supply for fans and charging phones.

    It surprises me that it is still present on *any* modern instruments.
    I expected it to survive on useful legacy kit until about now though.

    Plenty of labs will have good working kit that still uses that interface
    and it is plenty fast enough for a lot of ordinary lab use.


    Plus you can get GPIB-Ethernet adapters for fairly cheap. We use one
    made by the estimable Abdul at Prologix, which works pretty well--we've
    used as many as three instruments with it at a time--two scopes and a
    spectrum analyzer. Did it just yesterday, in fact.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to Don on Sat Jul 23 12:17:15 2022
    Don wrote:
    Phil Hobbs wrote:
    Joe Gwinn wrote:
    Don wrote:
    Joe Gwinn wrote:

    <snip>

    Also, I'd lose the BNC connectors. Threaded connectors like SMA, TNC, >>>>> and Type N are far better.

    Or use shielded twisted pair to carry the 1PPS pulses. This would
    work better over a backplane.

    This is good advice. Even though the lazy guy within me never truly
    gives up his fight to take the easy way out with BNC.
    Twisted pair (TP) sounds even easier than BNC. So, what's the
    "catch" with TP? Where's the "gotcha" to make TP harder than BNC?

    Depends on what you are trying to do.

    For nanosecond edges, coax is pretty useful, but short range and often
    mechanically awkward.

    For microsecond edges at 1000 meters, RS422 over shielded twisted pair
    is pretty good.

    For bus length links, LVDS or the like.

    And so on. And there is always optical links.

    Joe Gwinn


    BNCs are the bomb, as long as you aren't putting 500 of them in series,
    as with the old 10base2 coax Ethernet.

    TNCs are a very small niche, and N connectors belong only on spectrum
    analyzers.

    The lazy guy within me always tries to use an N connector to BNC
    adapter on my boat anchor spectrum analyzer. He convinces himself he's
    only interested in frequencies less than 2 GHz, so, what's the harm?

    High performance WiFi antennas also use N connectors to squeeze out
    every last iota of performance. You need a DIY N connector to reverse- polarity SMA to connect such antennas to consumer WiFi devices.

    Danke,


    N connectors are almost identical to BNCs internally--in fact you can
    mate an N male to a BNC female very nicely.

    I use SMA for everything above about 2 GHz anyway. (Some of my test
    gear uses expensive K (2.8 mm) or very expensive V (2.4 mm) connectors,
    but those all have SMA adapters on the front.)

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to langwadt@fonz.dk on Sat Jul 23 15:00:26 2022
    On Fri, 22 Jul 2022 17:16:00 -0700 (PDT), Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:

    fredag den 22. juli 2022 kl. 22.37.08 UTC+2 skrev Joe Gwinn:
    On Thu, 21 Jul 2022 04:17:14 -0700, jla...@highlandsniptechnology.com
    wrote:

    On Wed, 20 Jul 2022 23:49:40 -0700 (PDT), whit3rd <whi...@gmail.com>
    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?

    It's actually a time lock problem. If a follower box starts up and
    sees its first 1 PPS input, it can thereafter declare 1 PPS internal
    events, based on its local VCO, and then do successive early/late
    comparisons to the external pulses. And trim its VCXO accordingly.

    Yes, exactly. And the drift between two reasonably good clocks is
    slow, so the correction need not and should not be all that fast.

    What I've done in real applications is to periodically measure the
    offset between when the external 1PPS is predicted to happen and when
    it actually does, and adjust the VCO frequency such that in say 50
    seconds of roughly linear convergence they will coincide (and keep on
    going). The process is repeated every few seconds (exact interval not
    important as it is measured).

    This is roughly the algorithm a helmsman uses while steering a
    sailboat, where effect is very much delayed from action.

    In many computer systems it is quite difficult to do anything on a
    strict time mark, but easy to measure that actual elapsed time, using
    the actual clock that is being steered - it all still converges, so
    long as one doesn't try too hard.

    So, in your example, the local clock would come from a 40 MHz VCO of
    good manufacture (probably needs to be a TCXO of some sort). The 40
    MHz output would be fed to a divider that puts out a 1PPS pulse train.

    During initialization, when the first external 1PPS leading edge is
    received, reset the divider, and start counting 40 MHz cycles. Maybe
    wait for things to stabilize.

    Thereafter, measure signed offset between external and internal 1PPS
    leading edges, and compute how much change (plus or minus) in current
    VCO frequency is required for zero offset to occur in say 50 seconds
    (make this time-to-zero an adjustable parameter), and change the VCO
    control voltage accordingly.

    A few seconds later (also an adjustable parameter), repeat the above
    adjustment process, again looking 50 seconds into the future from now.
    Repeat forever.


    isn't that kind how NTP works?, speeding up or slowing down over some period >to sync time with the server without big jumps and always increasing (except possibly at start up)

    Yes. This is exactly how part of NTP works, in particular the FLL
    (Frequency Lock Loop). Battle-tested. That's where I got the idea.
    NTP was developed in the early 1980s, shortly after Ethernet made such
    a thing useful.

    This kind of thing is extensively discussed on Time Nuts.


    come to think of it, some closed loop servo systems (and step generators) for things like CNC machine work similarly
    at a fixed interval, say a few kHz, current target and actual position is compared, from that (usually with a PI loop)
    the speed of the motor (or frequency of steps) is set so the position will hit the next target at the next timer tick.

    Yep.

    I forgot to mention one thing, a way to speed initialization up:

    The external 1PPS pulse-train is taken as gospel. If one counts local
    40 MHz oscillator cycles between any adjacent pair of 1PPS events, one
    will get a very accurate measurement of the local oscillator signal
    frequency. Knowing that it is supposed to be 40 MHz, one can compute
    how far off correct (as a ratio) that local oscillator is from truth.
    This can be used to jump far closer starting frequency to correct
    without waiting for convergence to get there.

    Joe Gwinn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Sat Jul 23 14:05:01 2022
    lørdag den 23. juli 2022 kl. 21.00.37 UTC+2 skrev Joe Gwinn:
    On Fri, 22 Jul 2022 17:16:00 -0700 (PDT), Lasse Langwadt Christensen <lang...@fonz.dk> wrote:

    fredag den 22. juli 2022 kl. 22.37.08 UTC+2 skrev Joe Gwinn:
    On Thu, 21 Jul 2022 04:17:14 -0700, jla...@highlandsniptechnology.com
    wrote:

    On Wed, 20 Jul 2022 23:49:40 -0700 (PDT), whit3rd <whi...@gmail.com>
    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?

    It's actually a time lock problem. If a follower box starts up and
    sees its first 1 PPS input, it can thereafter declare 1 PPS internal
    events, based on its local VCO, and then do successive early/late
    comparisons to the external pulses. And trim its VCXO accordingly.

    Yes, exactly. And the drift between two reasonably good clocks is
    slow, so the correction need not and should not be all that fast.

    What I've done in real applications is to periodically measure the
    offset between when the external 1PPS is predicted to happen and when
    it actually does, and adjust the VCO frequency such that in say 50
    seconds of roughly linear convergence they will coincide (and keep on
    going). The process is repeated every few seconds (exact interval not
    important as it is measured).

    This is roughly the algorithm a helmsman uses while steering a
    sailboat, where effect is very much delayed from action.

    In many computer systems it is quite difficult to do anything on a
    strict time mark, but easy to measure that actual elapsed time, using
    the actual clock that is being steered - it all still converges, so
    long as one doesn't try too hard.

    So, in your example, the local clock would come from a 40 MHz VCO of
    good manufacture (probably needs to be a TCXO of some sort). The 40
    MHz output would be fed to a divider that puts out a 1PPS pulse train.

    During initialization, when the first external 1PPS leading edge is
    received, reset the divider, and start counting 40 MHz cycles. Maybe
    wait for things to stabilize.

    Thereafter, measure signed offset between external and internal 1PPS
    leading edges, and compute how much change (plus or minus) in current
    VCO frequency is required for zero offset to occur in say 50 seconds
    (make this time-to-zero an adjustable parameter), and change the VCO
    control voltage accordingly.

    A few seconds later (also an adjustable parameter), repeat the above
    adjustment process, again looking 50 seconds into the future from now.
    Repeat forever.


    isn't that kind how NTP works?, speeding up or slowing down over some period
    to sync time with the server without big jumps and always increasing (except possibly at start up)

    Yes. This is exactly how part of NTP works, in particular the FLL
    (Frequency Lock Loop). Battle-tested. That's where I got the idea.
    NTP was developed in the early 1980s, shortly after Ethernet made such
    a thing useful.

    This kind of thing is extensively discussed on Time Nuts.


    come to think of it, some closed loop servo systems (and step generators) for things like CNC machine work similarly
    at a fixed interval, say a few kHz, current target and actual position is compared, from that (usually with a PI loop)
    the speed of the motor (or frequency of steps) is set so the position will hit the next target at the next timer tick.

    Yep.

    I forgot to mention one thing, a way to speed initialization up:

    The external 1PPS pulse-train is taken as gospel. If one counts local
    40 MHz oscillator cycles between any adjacent pair of 1PPS events, one
    will get a very accurate measurement of the local oscillator signal frequency. Knowing that it is supposed to be 40 MHz, one can compute
    how far off correct (as a ratio) that local oscillator is from truth.
    This can be used to jump far closer starting frequency to correct
    without waiting for convergence to get there.

    yeh, get an initial guess and then switch to a slow correction so any jitter on the 1pps
    gets "filtered"

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Clifford Heath@21:1/5 to Joe Gwinn on Sun Jul 24 08:40:28 2022
    On 24/7/22 05:00, Joe Gwinn wrote:
    I forgot to mention one thing, a way to speed initialization up:

    The external 1PPS pulse-train is taken as gospel. If one counts local
    40 MHz oscillator cycles between any adjacent pair of 1PPS events, one
    will get a very accurate measurement of the local oscillator signal frequency. Knowing that it is supposed to be 40 MHz, one can compute
    how far off correct (as a ratio) that local oscillator is from truth.
    This can be used to jump far closer starting frequency to correct
    without waiting for convergence to get there.

    This initial measurement stands alone, not refining a previous body of measurement knowledge, so it's reasonable to set the gain high. Human perception does this a lot. If you hear two sounds a certain interval
    apart, your hearing is pre-primed to expect a third at exactly the same interval. If the third comes slightly early or slightly late, slightly
    quieter or slightly louder, we jump to conclusions very quickly about
    what's happening. Very rapid model-forming, and adapting new sensations
    to refine the model. Very necessary for a prey animal!

    Is there a name for this idea in filter terminology?

    Clifford Heath

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to no_spam@please.net on Sat Jul 23 19:08:54 2022
    On Sun, 24 Jul 2022 08:40:28 +1000, Clifford Heath
    <no_spam@please.net> wrote:

    On 24/7/22 05:00, Joe Gwinn wrote:
    I forgot to mention one thing, a way to speed initialization up:

    The external 1PPS pulse-train is taken as gospel. If one counts local
    40 MHz oscillator cycles between any adjacent pair of 1PPS events, one
    will get a very accurate measurement of the local oscillator signal
    frequency. Knowing that it is supposed to be 40 MHz, one can compute
    how far off correct (as a ratio) that local oscillator is from truth.
    This can be used to jump far closer starting frequency to correct
    without waiting for convergence to get there.

    This initial measurement stands alone, not refining a previous body of >measurement knowledge, so it's reasonable to set the gain high. Human >perception does this a lot. If you hear two sounds a certain interval
    apart, your hearing is pre-primed to expect a third at exactly the same >interval. If the third comes slightly early or slightly late, slightly >quieter or slightly louder, we jump to conclusions very quickly about
    what's happening. Very rapid model-forming, and adapting new sensations
    to refine the model. Very necessary for a prey animal!

    Is there a name for this idea in filter terminology?

    There are two answers, depending on which field you mean, biology or electronics.

    In biology, it has been long known that the brain creates a model of
    the world, and keys on deviations between prediction and actual. But
    this isn't just for expected rhythm, it's far more general and
    flexible than that.

    With the speedup algorithm I mentioned earlier, the mechanism is
    designed with considerable domain knowledge in hand. The primary
    driver is to achieve robustness despite the imperfections of real
    clocks et al. The continuous look-ahead algorithm is not flummoxed by non-stationary and/or non-Gaussian probability-distributions, et al.
    But it's more in the nature of a control system than a filter per se.

    Joe Gwinn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Clifford Heath@21:1/5 to Joe Gwinn on Sun Jul 24 16:46:15 2022
    On 24/7/22 09:08, Joe Gwinn wrote:
    On Sun, 24 Jul 2022 08:40:28 +1000, Clifford Heath
    <no_spam@please.net> wrote:

    On 24/7/22 05:00, Joe Gwinn wrote:
    I forgot to mention one thing, a way to speed initialization up:

    The external 1PPS pulse-train is taken as gospel. If one counts local
    40 MHz oscillator cycles between any adjacent pair of 1PPS events, one
    will get a very accurate measurement of the local oscillator signal
    frequency. Knowing that it is supposed to be 40 MHz, one can compute
    how far off correct (as a ratio) that local oscillator is from truth.
    This can be used to jump far closer starting frequency to correct
    without waiting for convergence to get there.

    This initial measurement stands alone, not refining a previous body of
    measurement knowledge, so it's reasonable to set the gain high. Human
    perception does this a lot. If you hear two sounds a certain interval
    apart, your hearing is pre-primed to expect a third at exactly the same
    interval. If the third comes slightly early or slightly late, slightly
    quieter or slightly louder, we jump to conclusions very quickly about
    what's happening. Very rapid model-forming, and adapting new sensations
    to refine the model. Very necessary for a prey animal!

    Is there a name for this idea in filter terminology?

    There are two answers, depending on which field you mean, biology or electronics.

    In biology, it has been long known that the brain creates a model of
    the world, and keys on deviations between prediction and actual. But
    this isn't just for expected rhythm, it's far more general and
    flexible than that.

    With the speedup algorithm I mentioned earlier, the mechanism is
    designed with considerable domain knowledge in hand. The primary
    driver is to achieve robustness despite the imperfections of real
    clocks et al. The continuous look-ahead algorithm is not flummoxed by non-stationary and/or non-Gaussian probability-distributions, et al.


    But it's more in the nature of a control system than a filter per se.

    A control system also models the plant, measures deviations from the prediction, before it applies a loop filter to decide the corrective step.

    That's the filter I'm referring to. It's just the same pronciple with
    the human system as when synchronising two clocks.

    Clifford Heath

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jan Panteltje@21:1/5 to no_spam@please.net on Sun Jul 24 08:58:10 2022
    On a sunny day (Sun, 24 Jul 2022 08:40:28 +1000) it happened Clifford Heath <no_spam@please.net> wrote in <1704967e2e98d7c6$38$2251891$26dd2c6e@news.thecubenet.com>:

    On 24/7/22 05:00, Joe Gwinn wrote:
    I forgot to mention one thing, a way to speed initialization up:

    The external 1PPS pulse-train is taken as gospel. If one counts local
    40 MHz oscillator cycles between any adjacent pair of 1PPS events, one
    will get a very accurate measurement of the local oscillator signal
    frequency. Knowing that it is supposed to be 40 MHz, one can compute
    how far off correct (as a ratio) that local oscillator is from truth.
    This can be used to jump far closer starting frequency to correct
    without waiting for convergence to get there.

    This initial measurement stands alone, not refining a previous body of >measurement knowledge, so it's reasonable to set the gain high. Human >perception does this a lot. If you hear two sounds a certain interval
    apart, your hearing is pre-primed to expect a third at exactly the same >interval. If the third comes slightly early or slightly late, slightly >quieter or slightly louder, we jump to conclusions very quickly about
    what's happening. Very rapid model-forming, and adapting new sensations
    to refine the model. Very necessary for a prey animal!

    Is there a name for this idea in filter terminology?

    No sure, but this is related to 'the alien problem' from cryptography.
    It goes like:
    Alien comes to earh, wants to take all knowledge humans have back home.
    So he gets Encyclopedia Britannica, but it is too heavy and does not fit in his flying saucer.
    So he writes the text out as an ASCII hex number and does 1 / that number. then he takes a stick and puts a mark on it in that ratio
    and takes the stick back home.

    To say 3 ticks is all you need to convey all information in the universe
    given time has no granularity.
    The stick in that example does of course have, limited by size of atoms etc, But does time have granularity?

    I use this all the time.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to pNaonStpealmtje@yahoo.com on Sun Jul 24 12:09:21 2022
    On Sun, 24 Jul 2022 08:58:10 GMT, Jan Panteltje
    <pNaonStpealmtje@yahoo.com> wrote:

    On a sunny day (Sun, 24 Jul 2022 08:40:28 +1000) it happened Clifford Heath ><no_spam@please.net> wrote in ><1704967e2e98d7c6$38$2251891$26dd2c6e@news.thecubenet.com>:

    On 24/7/22 05:00, Joe Gwinn wrote:
    I forgot to mention one thing, a way to speed initialization up:

    The external 1PPS pulse-train is taken as gospel. If one counts local
    40 MHz oscillator cycles between any adjacent pair of 1PPS events, one
    will get a very accurate measurement of the local oscillator signal
    frequency. Knowing that it is supposed to be 40 MHz, one can compute
    how far off correct (as a ratio) that local oscillator is from truth.
    This can be used to jump far closer starting frequency to correct
    without waiting for convergence to get there.

    This initial measurement stands alone, not refining a previous body of >>measurement knowledge, so it's reasonable to set the gain high. Human >>perception does this a lot. If you hear two sounds a certain interval >>apart, your hearing is pre-primed to expect a third at exactly the same >>interval. If the third comes slightly early or slightly late, slightly >>quieter or slightly louder, we jump to conclusions very quickly about >>what's happening. Very rapid model-forming, and adapting new sensations
    to refine the model. Very necessary for a prey animal!

    Is there a name for this idea in filter terminology?

    No sure, but this is related to 'the alien problem' from cryptography.
    It goes like:
    Alien comes to earh, wants to take all knowledge humans have back home.
    So he gets Encyclopedia Britannica, but it is too heavy and does not fit in his flying saucer.
    So he writes the text out as an ASCII hex number and does 1 / that number. >then he takes a stick and puts a mark on it in that ratio
    and takes the stick back home.

    To say 3 ticks is all you need to convey all information in the universe >given time has no granularity.
    The stick in that example does of course have, limited by size of atoms etc, >But does time have granularity?

    I use this all the time.

    Time is thought to have a granularity of sorts, about 10^-43 seconds,
    which is a Planck Unit.

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

    Joe Gwinn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jan Panteltje@21:1/5 to joegwinn@comcast.net on Sun Jul 24 16:53:04 2022
    On a sunny day (Sun, 24 Jul 2022 12:09:21 -0400) it happened Joe Gwinn <joegwinn@comcast.net> wrote in <ugrqdhp9ldssd95u39nik1n6th9bktbs41@4ax.com>:

    On Sun, 24 Jul 2022 08:58:10 GMT, Jan Panteltje
    <pNaonStpealmtje@yahoo.com> wrote:

    On a sunny day (Sun, 24 Jul 2022 08:40:28 +1000) it happened Clifford Heath >><no_spam@please.net> wrote in >><1704967e2e98d7c6$38$2251891$26dd2c6e@news.thecubenet.com>:

    On 24/7/22 05:00, Joe Gwinn wrote:
    I forgot to mention one thing, a way to speed initialization up:

    The external 1PPS pulse-train is taken as gospel. If one counts local >>>> 40 MHz oscillator cycles between any adjacent pair of 1PPS events, one >>>> will get a very accurate measurement of the local oscillator signal
    frequency. Knowing that it is supposed to be 40 MHz, one can compute
    how far off correct (as a ratio) that local oscillator is from truth.
    This can be used to jump far closer starting frequency to correct
    without waiting for convergence to get there.

    This initial measurement stands alone, not refining a previous body of >>>measurement knowledge, so it's reasonable to set the gain high. Human >>>perception does this a lot. If you hear two sounds a certain interval >>>apart, your hearing is pre-primed to expect a third at exactly the same >>>interval. If the third comes slightly early or slightly late, slightly >>>quieter or slightly louder, we jump to conclusions very quickly about >>>what's happening. Very rapid model-forming, and adapting new sensations >>>to refine the model. Very necessary for a prey animal!

    Is there a name for this idea in filter terminology?

    No sure, but this is related to 'the alien problem' from cryptography.
    It goes like:
    Alien comes to earh, wants to take all knowledge humans have back home.
    So he gets Encyclopedia Britannica, but it is too heavy and does not fit in his flying saucer.
    So he writes the text out as an ASCII hex number and does 1 / that number. >>then he takes a stick and puts a mark on it in that ratio
    and takes the stick back home.

    To say 3 ticks is all you need to convey all information in the universe >>given time has no granularity.
    The stick in that example does of course have, limited by size of atoms etc, >>But does time have granularity?

    I use this all the time.

    Time is thought to have a granularity of sorts, about 10^-43 seconds,
    which is a Planck Unit.

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

    Sure but there is a problem, if you scroll down on that site you find the sentence
    "the Planck time is the time required for light to travel the distance of 1 Planck length in a vacuum".
    That leads to a circular reasoning, as traveling half a Planck length would take half the time...
    Just before that the text goes into Planck length, and says in some theories with more dimensions
    that length is smaller than the fundamental Planck length
    So much twenty-first century physics assumptions...
    Start of big bang start of time, obvious bull.
    Maybe there are a zillion bangs like there are a zillion stars and something that formed those over time.
    Measurement limits like saying length in feet or whatever ...
    But sure, what we can measure, being made of matter, probably has a limit.
    Wait till they figure out gravity.. I still like Le Sage's model as it provides a MECHANISM for gravity.
    Now they are stuck looking for dark matter..

    Very interesting, physics, BTW.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to no_spam@please.net on Sun Jul 24 12:15:27 2022
    On Sun, 24 Jul 2022 16:46:15 +1000, Clifford Heath
    <no_spam@please.net> wrote:

    On 24/7/22 09:08, Joe Gwinn wrote:
    On Sun, 24 Jul 2022 08:40:28 +1000, Clifford Heath
    <no_spam@please.net> wrote:

    On 24/7/22 05:00, Joe Gwinn wrote:
    I forgot to mention one thing, a way to speed initialization up:

    The external 1PPS pulse-train is taken as gospel. If one counts local >>>> 40 MHz oscillator cycles between any adjacent pair of 1PPS events, one >>>> will get a very accurate measurement of the local oscillator signal
    frequency. Knowing that it is supposed to be 40 MHz, one can compute
    how far off correct (as a ratio) that local oscillator is from truth.
    This can be used to jump far closer starting frequency to correct
    without waiting for convergence to get there.

    This initial measurement stands alone, not refining a previous body of
    measurement knowledge, so it's reasonable to set the gain high. Human
    perception does this a lot. If you hear two sounds a certain interval
    apart, your hearing is pre-primed to expect a third at exactly the same
    interval. If the third comes slightly early or slightly late, slightly
    quieter or slightly louder, we jump to conclusions very quickly about
    what's happening. Very rapid model-forming, and adapting new sensations
    to refine the model. Very necessary for a prey animal!

    Is there a name for this idea in filter terminology?

    There are two answers, depending on which field you mean, biology or
    electronics.

    In biology, it has been long known that the brain creates a model of
    the world, and keys on deviations between prediction and actual. But
    this isn't just for expected rhythm, it's far more general and
    flexible than that.

    With the speedup algorithm I mentioned earlier, the mechanism is
    designed with considerable domain knowledge in hand. The primary
    driver is to achieve robustness despite the imperfections of real
    clocks et al. The continuous look-ahead algorithm is not flummoxed by
    non-stationary and/or non-Gaussian probability-distributions, et al.


    But it's more in the nature of a control system than a filter per se.

    A control system also models the plant, measures deviations from the >prediction, before it applies a loop filter to decide the corrective step.

    That's the filter I'm referring to. It's just the same principle with
    the human system as when synchronising two clocks.

    Well, yes, but we're being a bit pedantic here. The problem is that
    the word "filter" can have multiple meanings. Like the low-pass loop
    filter in a PLL or FLL. In the algorithm described earlier, the FLL
    loop filter is implicit in the choice of look-ahead and cycle times.

    Joe Gwinn

    Joe Gwinn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to pNaonStpealmtje@yahoo.com on Sun Jul 24 14:17:22 2022
    On Sun, 24 Jul 2022 16:53:04 GMT, Jan Panteltje
    <pNaonStpealmtje@yahoo.com> wrote:

    On a sunny day (Sun, 24 Jul 2022 12:09:21 -0400) it happened Joe Gwinn ><joegwinn@comcast.net> wrote in <ugrqdhp9ldssd95u39nik1n6th9bktbs41@4ax.com>:

    On Sun, 24 Jul 2022 08:58:10 GMT, Jan Panteltje
    <pNaonStpealmtje@yahoo.com> wrote:

    On a sunny day (Sun, 24 Jul 2022 08:40:28 +1000) it happened Clifford Heath >>><no_spam@please.net> wrote in >>><1704967e2e98d7c6$38$2251891$26dd2c6e@news.thecubenet.com>:

    On 24/7/22 05:00, Joe Gwinn wrote:
    I forgot to mention one thing, a way to speed initialization up:

    The external 1PPS pulse-train is taken as gospel. If one counts local >>>>> 40 MHz oscillator cycles between any adjacent pair of 1PPS events, one >>>>> will get a very accurate measurement of the local oscillator signal
    frequency. Knowing that it is supposed to be 40 MHz, one can compute >>>>> how far off correct (as a ratio) that local oscillator is from truth. >>>>> This can be used to jump far closer starting frequency to correct
    without waiting for convergence to get there.

    This initial measurement stands alone, not refining a previous body of >>>>measurement knowledge, so it's reasonable to set the gain high. Human >>>>perception does this a lot. If you hear two sounds a certain interval >>>>apart, your hearing is pre-primed to expect a third at exactly the same >>>>interval. If the third comes slightly early or slightly late, slightly >>>>quieter or slightly louder, we jump to conclusions very quickly about >>>>what's happening. Very rapid model-forming, and adapting new sensations >>>>to refine the model. Very necessary for a prey animal!

    Is there a name for this idea in filter terminology?

    No sure, but this is related to 'the alien problem' from cryptography.
    It goes like:
    Alien comes to earh, wants to take all knowledge humans have back home. >>>So he gets Encyclopedia Britannica, but it is too heavy and does not fit in his flying saucer.
    So he writes the text out as an ASCII hex number and does 1 / that number. >>>then he takes a stick and puts a mark on it in that ratio
    and takes the stick back home.

    To say 3 ticks is all you need to convey all information in the universe >>>given time has no granularity.
    The stick in that example does of course have, limited by size of atoms etc, >>>But does time have granularity?

    I use this all the time.

    Time is thought to have a granularity of sorts, about 10^-43 seconds,
    which is a Planck Unit.

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

    Sure but there is a problem, if you scroll down on that site you find the sentence
    "the Planck time is the time required for light to travel the distance of 1 Planck length in a vacuum".
    That leads to a circular reasoning, as traveling half a Planck length would take half the time...
    Just before that the text goes into Planck length, and says in some theories with more dimensions
    that length is smaller than the fundamental Planck length

    Well, with Planck Units, all these things are true at the same time,
    and nobody knows if one causes another, or if all flow from a
    currently unknown common cause. Or something.

    I don't think that one can in fact move by less than a Planck length,
    so in that case it is unclear if the limit is on time or on distance,
    both, or something unobvious.


    So much twenty-first century physics assumptions...
    Start of big bang start of time, obvious bull.
    Maybe there are a zillion bangs like there are a zillion stars and something that formed those over time.
    Measurement limits like saying length in feet or whatever ...
    But sure, what we can measure, being made of matter, probably has a limit. >Wait till they figure out gravity.. I still like Le Sage's model as it provides a MECHANISM for gravity.
    Now they are stuck looking for dark matter..

    All that mess is the best humans have come up with so far. Stay
    tuned.


    Very interesting, physics, BTW.

    Not to mention weird.


    Joe Gwinn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to jlarkin@highland_atwork_technology. on Sun Jul 24 13:32:15 2022
    On Wed, 20 Jul 2022 16:20:57 -0700, John Larkin <jlarkin@highland_atwork_technology.com> 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.

    The ultimate way to do this would be to measure the phase of the xo at
    every rise of the 1 pps input, to nanosecond or picosecond resolution.
    That wouldn't be hard, but it would be overkill for the requirement to time-align power supplies.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jasen Betts@21:1/5 to John Larkin on Mon Jul 25 12:26:11 2022
    On 2022-07-20, John Larkin <jlarkin@highland_atwork_technology.com> 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 only need a consensus, put the 40 mhz from the crystal onto the
    BNC though some resistor, they'll sort it out, like a table full of metronoms.

    If you have control loops all over the place pulling in different
    directions maybe not so much.

    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?

    mostlky no.

    --
    Jasen.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to pcdhSpamMeSenseless@electrooptical. on Mon Jul 25 12:31:40 2022
    On Fri, 22 Jul 2022 09:03:16 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    Martin Brown wrote:
    On 22/07/2022 03:44, Clifford Heath wrote:
    On 22/7/22 03:10, Phil Hobbs wrote:
    Gerhard Hoffmann wrote:
    Am 21.07.22 um 16:15 schrieb Phil Hobbs:

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

    -v ?

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

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

    Cheers
    Gerhard

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

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

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

    Interesting, thanks.

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

    Quite probably - it has been known for a long time in radio astronomy
    first derived by Jennison in 1958 at Jodrell Bank for 3 antennae. This
    is the original ground breaking paper for anyone interested

    <https://articles.adsabs.harvard.edu//full/1958MNRAS.118..276J/0000276.000.html >


    (easier to understand versions exist today). WIki isn't bad:

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

    It allows you to get a good phase observable uncontaminated by the phase
    error at each node for every distinct subset of 3 nodes. There is a
    corresponding closure amplitude for distinct subsets of 4 nodes.

    Obviously the bigger N is the more useful observables you can get which
    is why the big dish telescopes sometimes stay on target and in the loop
    for perhaps longer than they really ought to in deteriorating weather.

    This book reviews most of the classical tricks used in VLBI and
    interferometry from the period when they had just become routine:

    Indirect Imaging: Measurement and Processing for Indirect Imaging
    Editor-J. A. Roberts
    0 ratings by Goodreads
    ISBN 10: 0521262828 / ISBN 13: 9780521262828
    Published by Cambridge University Press, 1984


    This proved hard to get:
    . <https://www.amazon.com/Indirect-Imaging-Measurement-Processing/dp/0521262828>

    The real power comes from the number of independent observables from N >instruments going like N**2, so that you win SNR like N**2 instead of N.

    Quite a startling improvement for moderate-to-large N!

    All very interesting. I've been digging, and came across a very
    interesting article, which happens to be open-access, which is all too uncommon.

    "A geometric view of closure phases in interferometry", DOI: <https://doi.org/10.1017/pasa.2022.6>

    .<https://www.cambridge.org/core/journals/publications-of-the-astronomical-society-of-australia/article/geometric-view-of-closure-phases-in-interferometry/5E8A5A8D58A2FC72ADFA0587347C4DA7>


    I'm still digesting it, but basically deducing the underlying geometry
    allowed for some significant improvements.

    Joe Gwinn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gerhard Hoffmann@21:1/5 to All on Mon Jul 25 20:51:18 2022
    Am 25.07.22 um 18:31 schrieb Joe Gwinn:
    On Fri, 22 Jul 2022 09:03:16 -0400, Phil Hobbs

    "A geometric view of closure phases in interferometry", DOI: <https://doi.org/10.1017/pasa.2022.6>

    .<https://www.cambridge.org/core/journals/publications-of-the-astronomical-society-of-australia/article/geometric-view-of-closure-phases-in-interferometry/5E8A5A8D58A2FC72ADFA0587347C4DA7>


    I'm still digesting it, but basically deducing the underlying geometry allowed for some significant improvements.

    I have not yet digested it, but can I assume that it won't help
    me to create a carrier that is phase noise wise better than
    averaged over 16 oscillators created equally bad?

    More suitable for post-processing after-the-fact?

    U. Rohde has the math for n injection locked oscillators in one
    of his books, but the formulas probably fall apart when you have
    to insert hard numbers for real oscillators you can buy, or build.
    Methinks he is more into multiple coupled resonators.

    cheers,
    Gerhard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to All on Mon Jul 25 11:59:42 2022
    On Fri, 22 Jul 2022 20:54:49 -0500, Les Cargill <lcargil99@gmail.com>
    wrote:

    Phil Hobbs wrote:
    jlarkin@highlandsniptechnology.com wrote:
    <snip>

    It dithers around the setpoint but nobody notices.


    That's what lowpass filters are for.

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


    Well, yeah - it's naturally constrained. When I jack the temp target on
    the A/C here, it take 30-45 seconds to turn everything off.


    Tim used to be a lot of fun and put up with much. FWIW rbj showed up
    on Reddit and lasted a couple days.

    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.


    You're just doing trust falls with slew rate limiting. :) There's
    probably a PhD paper somewhere with a madman low-pass filtering the
    output of a bangbang with a lowpass.

    We made a lot of timing modules for a big laser facility. We get a
    155.52 MHz fiber data stream and lock a local VCO to that, with jitter
    a couple of picoseconds. The phase detector, actually a time detector,
    is an ECL d-flop in a bangbang loop.

    The lowpass has switchable bandwidth, acquisition mode and track mode, something like 8 KHz and 2 KHz.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to All on Mon Jul 25 15:49:42 2022
    On Mon, 25 Jul 2022 20:51:18 +0200, Gerhard Hoffmann <dk4xp@arcor.de>
    wrote:

    Am 25.07.22 um 18:31 schrieb Joe Gwinn:
    On Fri, 22 Jul 2022 09:03:16 -0400, Phil Hobbs

    "A geometric view of closure phases in interferometry", DOI:
    <https://doi.org/10.1017/pasa.2022.6>

    .<https://www.cambridge.org/core/journals/publications-of-the-astronomical-society-of-australia/article/geometric-view-of-closure-phases-in-interferometry/5E8A5A8D58A2FC72ADFA0587347C4DA7>


    I'm still digesting it, but basically deducing the underlying geometry
    allowed for some significant improvements.

    I have not yet digested it, but can I assume that it won't help
    me to create a carrier that is phase noise wise better than
    averaged over 16 oscillators created equally bad?

    As you suspect, no, it won't. Only better oscillators will help.


    More suitable for post-processing after-the-fact?

    The big advantage of closure-phase methods is that one can recover the
    emission distribution of a very distant source by interferometry,
    while ignoring various practical imperfections of radio/optical
    telescope interferometers.

    This works because the closure / kernel phase is an inherent property
    of the source that is not affected by those practical imperfections.

    This is how we image distant quasars and the event horizon of
    billion-sun black holes at the center of some galaxies.


    U. Rohde has the math for n injection locked oscillators in one
    of his books, but the formulas probably fall apart when you have
    to insert hard numbers for real oscillators you can buy, or build.
    Methinks he is more into multiple coupled resonators.

    Yes. The classic is a room full of pendulum clocks slipping into
    synchrony. Discovered in 1666 by Christiaan Huygens, who invented of
    the pendulum clock in 1657.

    The only math needed is differential equations, developed a few years
    later, in 1671. U. Rohde was a bit late to the party.


    Joe Gwinn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to All on Mon Jul 25 16:27:43 2022
    On Mon, 25 Jul 2022 22:16:42 +0200, Gerhard Hoffmann <dk4xp@arcor.de>
    wrote:

    Am 25.07.22 um 21:49 schrieb Joe Gwinn:

    I have not yet digested it, but can I assume that it won't help
    me to create a carrier that is phase noise wise better than
    averaged over 16 oscillators created equally bad?

    As you suspect, no, it won't. Only better oscillators will help.

    Or even more oscillators to average. :-)

    Yes, but the improvement is 5 dB per factor of ten oscillator count.
    Longer integration times may be easier.

    Low-noise oscillator design is a career.

    Joe Gwinn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gerhard Hoffmann@21:1/5 to All on Mon Jul 25 22:16:42 2022
    Am 25.07.22 um 21:49 schrieb Joe Gwinn:

    I have not yet digested it, but can I assume that it won't help
    me to create a carrier that is phase noise wise better than
    averaged over 16 oscillators created equally bad?

    As you suspect, no, it won't. Only better oscillators will help.

    Or even more oscillators to average. :-)

    Cheers, Gerhard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to Gerhard Hoffmann on Tue Jul 26 08:05:49 2022
    Gerhard Hoffmann wrote:
    Am 25.07.22 um 18:31 schrieb Joe Gwinn:
    On Fri, 22 Jul 2022 09:03:16 -0400, Phil Hobbs

    "A geometric view of closure phases in interferometry", DOI:
    <https://doi.org/10.1017/pasa.2022.6>

    .<https://www.cambridge.org/core/journals/publications-of-the-astronomical-society-of-australia/article/geometric-view-of-closure-phases-in-interferometry/5E8A5A8D58A2FC72ADFA0587347C4DA7>



    I'm still digesting it, but basically deducing the underlying geometry
    allowed for some significant improvements.

    I have not yet digested it, but can I assume that it won't help
    me to create a carrier that is phase noise wise better than
    averaged over 16 oscillators created equally bad?

    More suitable for post-processing after-the-fact?

    U. Rohde has the math for n injection locked oscillators in one
    of his books, but the formulas probably fall apart when you have
    to insert hard numbers for real oscillators you can buy, or build.
    Methinks he is more into multiple coupled resonators.

    cheers,
    Gerhard

    I'm not sure--as I say, I haven't got a properly-thought-out scheme, but
    it seems as though it ought to be possible to combine the measurements
    to produce N-1 oscillator signals, each one N times quieter, so that
    averaging _those_ would get you to the N(N-1)/2 level.

    It probably needs a whole lot of phase shifters or weighted summers
    (like a Wilkinson with attenuators), so it may well not be a win from a total-hardware POV. Seems like it would be worth a bit of thought, though.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to Joe Gwinn on Tue Jul 26 08:42:07 2022
    Joe Gwinn wrote:
    On Mon, 25 Jul 2022 22:16:42 +0200, Gerhard Hoffmann <dk4xp@arcor.de>
    wrote:

    Am 25.07.22 um 21:49 schrieb Joe Gwinn:

    I have not yet digested it, but can I assume that it won't help
    me to create a carrier that is phase noise wise better than
    averaged over 16 oscillators created equally bad?

    As you suspect, no, it won't. Only better oscillators will help.

    Or even more oscillators to average. :-)

    Yes, but the improvement is 5 dB per factor of ten oscillator count.
    Longer integration times may be easier.

    Low-noise oscillator design is a career.

    Joe Gwinn


    Nah, even the simple averaging case you win SNR like N, so it's 10 dB
    per decade.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to Joe Gwinn on Tue Jul 26 08:40:45 2022
    Joe Gwinn wrote:
    On Mon, 25 Jul 2022 20:51:18 +0200, Gerhard Hoffmann <dk4xp@arcor.de>
    wrote:

    Am 25.07.22 um 18:31 schrieb Joe Gwinn:
    On Fri, 22 Jul 2022 09:03:16 -0400, Phil Hobbs

    "A geometric view of closure phases in interferometry", DOI:
    <https://doi.org/10.1017/pasa.2022.6>

    .<https://www.cambridge.org/core/journals/publications-of-the-astronomical-society-of-australia/article/geometric-view-of-closure-phases-in-interferometry/5E8A5A8D58A2FC72ADFA0587347C4DA7>


    I'm still digesting it, but basically deducing the underlying geometry
    allowed for some significant improvements.

    I have not yet digested it, but can I assume that it won't help
    me to create a carrier that is phase noise wise better than
    averaged over 16 oscillators created equally bad?

    As you suspect, no, it won't. Only better oscillators will help.

    As Kipling might say, "Not so, but far otherwise."

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gerhard Hoffmann@21:1/5 to As I on Tue Jul 26 15:31:08 2022
    Am 26.07.22 um 14:42 schrieb Phil Hobbs:
    Joe Gwinn wrote:

    Yes, but the improvement is 5 dB per factor of ten oscillator count.
    Longer integration times may be easier.

    Low-noise oscillator design is a career.

    Joe Gwinn


    Nah, even the simple averaging case you win SNR like N, so it's 10 dB
    per decade.

    3 dB per doubling the # of oscs.

    So, it will probably be 2 groups of 8 for my cross-correlating Timepod :-).
    As I wrote, the 5.0 MHz MTI-260 were relatively cheap.

    Cheers

    Gerhard, DK4XP

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to pcdhSpamMeSenseless@electrooptical. on Tue Jul 26 07:07:51 2022
    On Tue, 26 Jul 2022 08:05:49 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    Gerhard Hoffmann wrote:
    Am 25.07.22 um 18:31 schrieb Joe Gwinn:
    On Fri, 22 Jul 2022 09:03:16 -0400, Phil Hobbs

    "A geometric view of closure phases in interferometry", DOI:
    <https://doi.org/10.1017/pasa.2022.6>

    .<https://www.cambridge.org/core/journals/publications-of-the-astronomical-society-of-australia/article/geometric-view-of-closure-phases-in-interferometry/5E8A5A8D58A2FC72ADFA0587347C4DA7>



    I'm still digesting it, but basically deducing the underlying geometry
    allowed for some significant improvements.

    I have not yet digested it, but can I assume that it won't help
    me to create a carrier that is phase noise wise better than
    averaged over 16 oscillators created equally bad?

    More suitable for post-processing after-the-fact?

    U. Rohde has the math for n injection locked oscillators in one
    of his books, but the formulas probably fall apart when you have
    to insert hard numbers for real oscillators you can buy, or build.
    Methinks he is more into multiple coupled resonators.

    cheers,
    Gerhard

    I'm not sure--as I say, I haven't got a properly-thought-out scheme, but
    it seems as though it ought to be possible to combine the measurements
    to produce N-1 oscillator signals, each one N times quieter, so that >averaging _those_ would get you to the N(N-1)/2 level.

    It probably needs a whole lot of phase shifters or weighted summers
    (like a Wilkinson with attenuators), so it may well not be a win from a >total-hardware POV. Seems like it would be worth a bit of thought, though.

    Cheers

    Phil Hobbs

    Imagine a single circuit/pcb that has N crystal oscillator circuits,
    injection locked and summed, in an oven.

    XOs near one another, namely in the same room, like to injection lock.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to jlarkin@highlandsniptechnology.com on Tue Jul 26 11:03:15 2022
    jlarkin@highlandsniptechnology.com wrote:
    On Tue, 26 Jul 2022 08:05:49 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    Gerhard Hoffmann wrote:
    Am 25.07.22 um 18:31 schrieb Joe Gwinn:
    On Fri, 22 Jul 2022 09:03:16 -0400, Phil Hobbs

    "A geometric view of closure phases in interferometry", DOI:
    <https://doi.org/10.1017/pasa.2022.6>

    .<https://www.cambridge.org/core/journals/publications-of-the-astronomical-society-of-australia/article/geometric-view-of-closure-phases-in-interferometry/5E8A5A8D58A2FC72ADFA0587347C4DA7>



    I'm still digesting it, but basically deducing the underlying geometry >>>> allowed for some significant improvements.

    I have not yet digested it, but can I assume that it won't help
    me to create a carrier that is phase noise wise better than
    averaged over 16 oscillators created equally bad?

    More suitable for post-processing after-the-fact?

    U. Rohde has the math for n injection locked oscillators in one
    of his books, but the formulas probably fall apart when you have
    to insert hard numbers for real oscillators you can buy, or build.
    Methinks he is more into multiple coupled resonators.

    cheers,
    Gerhard

    I'm not sure--as I say, I haven't got a properly-thought-out scheme, but
    it seems as though it ought to be possible to combine the measurements
    to produce N-1 oscillator signals, each one N times quieter, so that
    averaging _those_ would get you to the N(N-1)/2 level.

    It probably needs a whole lot of phase shifters or weighted summers
    (like a Wilkinson with attenuators), so it may well not be a win from a
    total-hardware POV. Seems like it would be worth a bit of thought, though. >>
    Cheers

    Phil Hobbs

    Imagine a single circuit/pcb that has N crystal oscillator circuits, injection locked and summed, in an oven.

    XOs near one another, namely in the same room, like to injection lock.

    Sure. That only gets you 10*log(N), though, AFAICT. Looking at it from
    a phase noise POV, you win improved <delta phi> like sqrt(N), just as
    you gain lower <delta V> by parallelling JFETs.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to pcdhSpamMeSenseless@electrooptical. on Tue Jul 26 19:18:03 2022
    On Tue, 26 Jul 2022 08:40:45 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    Joe Gwinn wrote:
    On Mon, 25 Jul 2022 20:51:18 +0200, Gerhard Hoffmann <dk4xp@arcor.de>
    wrote:

    Am 25.07.22 um 18:31 schrieb Joe Gwinn:
    On Fri, 22 Jul 2022 09:03:16 -0400, Phil Hobbs

    "A geometric view of closure phases in interferometry", DOI:
    <https://doi.org/10.1017/pasa.2022.6>

    .<https://www.cambridge.org/core/journals/publications-of-the-astronomical-society-of-australia/article/geometric-view-of-closure-phases-in-interferometry/5E8A5A8D58A2FC72ADFA0587347C4DA7>


    I'm still digesting it, but basically deducing the underlying geometry >>>> allowed for some significant improvements.

    I have not yet digested it, but can I assume that it won't help
    me to create a carrier that is phase noise wise better than
    averaged over 16 oscillators created equally bad?

    As you suspect, no, it won't. Only better oscillators will help.

    As Kipling might say, "Not so, but far otherwise."

    Well, for phase noise test sets, the rule is that noise reduces as
    10Log10[ Sqrt[N] ], or simply 5Log10[N], where N is the number of
    correlations performed, where what's being correlated is
    data-collection runs with a specified data-collection window
    durations. These windows can be over time or over devices, which
    should be equivalent in the noise floor.

    So, getting to very low PN levels this way soon becomes impractical,
    and by far the best approach is to use a better oscillator. State of
    the art these days is a noise floor at around -170 dBc/Hz at 10 MHz.
    As always, 1/f^a noise can be a big problem, and it doesn't average
    out all that well.

    We may be talking about different things.


    Joe Gwinn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Les Cargill@21:1/5 to Lasse Langwadt Christensen on Tue Jul 26 19:49:19 2022
    Lasse Langwadt Christensen wrote:
    lørdag den 23. juli 2022 kl. 03.57.33 UTC+2 skrev Les Cargill:
    bitrex wrote:
    On 7/20/2022 8:22 PM, 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.

    It sounds like you're looking for a protocol like DMX if what you want
    is to trigger sequences of events across boxes to within a millisecond,
    I don't understand what this lock-the-40 MHz across boxes is about.

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




    DMX for this is like hunting deer with an artillery piece. DMX is for
    the big-ass risk scenarios in distributed topologies; this is a lot
    less profound.

    ? it's a 250kbit uart on RS485, hardly rocket surgery


    That's the physical layer; DMX is pretty holistic. I dunno - maybe
    there's a COTS DMX doohickey that can be pressed into service.

    --
    Les Cargill

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Les Cargill@21:1/5 to jlarkin@highlandsniptechnology.com on Tue Jul 26 19:56:53 2022
    jlarkin@highlandsniptechnology.com wrote:
    On Fri, 22 Jul 2022 21:10:35 -0500, Les Cargill <lcargil99@gmail.com>
    wrote:

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

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


    Engineering is composition. Composition is the thin edge of the musical
    wedge. Musicianship is different; it's pattern identification. As is
    composition but in a different way. But it is all the same thing.

    It all depends on which wall you prefer to have your back against.

    I've always wondered about musicians. They have to play a piece
    hundreds of times to get it right.

    Some do; some don't. Session players from back when studio time
    was the dominant cost probably played the parts on a song you later
    heard on the radio on the first take.

    Some have surely performed
    something thousands of times. Don't they get bored? Apparently not.


    There's too broad a spectrum to generalize. Some forms are better for
    people with mild forms of OCD.

    I design something, finish, and then want to design something entirely different.

    It depends on boredom thresholds.


    Much does.


    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?

    Over where they MATLAB.

    SCPI is send-and-forget. There is some query you can send to ask if
    the last command worked. And you can have an error queue that you can interrogate now and then for historical forensics.

    I told the customer that damn the specs, every command is going to
    reply with data, an error message, or "OK". They agree.



    And there you go turning a perfectly good full duplex channel into a
    half duplex walkie-talkie channel :)

    It'll be fast enough.

    --
    Les Cargill

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to Joe Gwinn on Tue Jul 26 22:34:31 2022
    Joe Gwinn wrote:
    On Tue, 26 Jul 2022 08:40:45 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    Joe Gwinn wrote:
    On Mon, 25 Jul 2022 20:51:18 +0200, Gerhard Hoffmann <dk4xp@arcor.de>
    wrote:

    Am 25.07.22 um 18:31 schrieb Joe Gwinn:
    On Fri, 22 Jul 2022 09:03:16 -0400, Phil Hobbs

    "A geometric view of closure phases in interferometry", DOI:
    <https://doi.org/10.1017/pasa.2022.6>

    .<https://www.cambridge.org/core/journals/publications-of-the-astronomical-society-of-australia/article/geometric-view-of-closure-phases-in-interferometry/5E8A5A8D58A2FC72ADFA0587347C4DA7>


    I'm still digesting it, but basically deducing the underlying geometry >>>>> allowed for some significant improvements.

    I have not yet digested it, but can I assume that it won't help
    me to create a carrier that is phase noise wise better than
    averaged over 16 oscillators created equally bad?

    As you suspect, no, it won't. Only better oscillators will help.

    As Kipling might say, "Not so, but far otherwise."

    Well, for phase noise test sets, the rule is that noise reduces as
    10Log10[ Sqrt[N] ], or simply 5Log10[N], where N is the number of correlations performed, where what's being correlated is
    data-collection runs with a specified data-collection window
    durations. These windows can be over time or over devices, which
    should be equivalent in the noise floor.

    Interesting. With phase-locked sources, when you simply average the
    signals directly, the flatband amplitude and phase noise amplitudes go
    down like sqrt(N), i.e. the noise power goes as 1/N. It's just like
    additive noise.

    Inside the loop BW, things are no doubt more complicated.

    There are other situations such as OTDR where the amplitude dependence
    is sqrt(sqrt(N)), but that's on account of electrical power going as the
    square of optical power.


    So, getting to very low PN levels this way soon becomes impractical,
    and by far the best approach is to use a better oscillator. State of
    the art these days is a noise floor at around -170 dBc/Hz at 10 MHz.
    As always, 1/f^a noise can be a big problem, and it doesn't average
    out all that well.

    We may be talking about different things.

    I expect so!

    Cheers

    Phil Hobbs



    Joe Gwinn



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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anthony William Sloman@21:1/5 to Phil Hobbs on Tue Jul 26 23:21:18 2022
    On Wednesday, July 27, 2022 at 12:34:40 PM UTC+10, Phil Hobbs wrote:
    Joe Gwinn wrote:
    On Tue, 26 Jul 2022 08:40:45 -0400, Phil Hobbs <pcdhSpamM...@electrooptical.net> wrote:

    Joe Gwinn wrote:
    On Mon, 25 Jul 2022 20:51:18 +0200, Gerhard Hoffmann <dk...@arcor.de> >>> wrote:

    Am 25.07.22 um 18:31 schrieb Joe Gwinn:
    On Fri, 22 Jul 2022 09:03:16 -0400, Phil Hobbs

    "A geometric view of closure phases in interferometry", DOI:
    <https://doi.org/10.1017/pasa.2022.6>

    .<https://www.cambridge.org/core/journals/publications-of-the-astronomical-society-of-australia/article/geometric-view-of-closure-phases-in-interferometry/5E8A5A8D58A2FC72ADFA0587347C4DA7>


    I'm still digesting it, but basically deducing the underlying geometry >>>>> allowed for some significant improvements.

    I have not yet digested it, but can I assume that it won't help
    me to create a carrier that is phase noise wise better than
    averaged over 16 oscillators created equally bad?

    As you suspect, no, it won't. Only better oscillators will help.

    As Kipling might say, "Not so, but far otherwise."

    This might be the better oscillator.

    https://spectrum.ieee.org/for-precision-the-sapphire-clock-outshines-even-the-best-atomic-clocks?utm_campaign=post-teaser&utm_content=7190c3vu

    It's a big lump of sapphire in a pool of liquid helium. Long term stability isn't wonderful, but short term stability is uniquely good.

    " The team is re-engineering the device to work at 50 K by increasing the concentration of magnetic impurities in the crystal without introducing additional losses. That's a temperature that liquid nitrogen can't quite get to, but it's way easier than 6
    K. "

    Apparently the Australian Air Force has two of the 6K devices for their radar network. Probably beyond John Larkin's budget.

    --
    Bill Sloman, Sydney

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to Phil Hobbs on Wed Jul 27 09:36:49 2022
    On 26/07/2022 13:05, Phil Hobbs wrote:
    Gerhard Hoffmann wrote:
    Am 25.07.22 um 18:31 schrieb Joe Gwinn:
    On Fri, 22 Jul 2022 09:03:16 -0400, Phil Hobbs

    "A geometric view of closure phases in interferometry", DOI:
    <https://doi.org/10.1017/pasa.2022.6>

    .<https://www.cambridge.org/core/journals/publications-of-the-astronomical-society-of-australia/article/geometric-view-of-closure-phases-in-interferometry/5E8A5A8D58A2FC72ADFA0587347C4DA7>

    I'm still digesting it, but basically deducing the underlying geometry
    allowed for some significant improvements.

    I have not yet digested it, but can I assume that it won't help
    me to create a carrier that is phase noise wise better than
    averaged over 16 oscillators created equally bad?

    More suitable for post-processing after-the-fact?

    U. Rohde has the math for n injection locked oscillators in one
    of his books, but the formulas probably fall apart when you have
    to insert hard numbers for real oscillators you can buy, or build.
    Methinks he is more into multiple coupled resonators.

    Entrainment of weakly coupled oscillators at frequencies near to each
    other can be quite strong (a problem if you don't want that to happen).

    I'm not sure--as I say, I haven't got a properly-thought-out scheme, but
    it seems as though it ought to be possible to combine the measurements
    to produce N-1 oscillator signals, each one N times quieter, so that averaging _those_ would get you to the N(N-1)/2 level.

    I think the catch is that to do that you would have to provide hardware
    to compute the cross correlation of every pair of oscillators so that correlator complexity goes up as N(N-1)/2 too. I can't immediately see a
    way to exploit this to get a better average oscillator though.

    It probably needs a whole lot of phase shifters or weighted summers
    (like a Wilkinson with attenuators), so it may well not be a win from a total-hardware POV.  Seems like it would be worth a bit of thought, though.

    VLBI typically disciplines a hydrogen maser using some other long term
    stable centralised terrestrial time source. Getting it just a little bit
    wrong just makes the white light fringe much harder to find later. Local
    clock short term stability stability is the key to it working well.

    I expect they are a lot better at it by now. In my day it involved
    moving around furniture van loads of tweaked VHS video tape cassettes
    from the big dishes to the correlator centres.


    --
    Regards,
    Martin Brown

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to All on Wed Jul 27 01:54:12 2022
    On Tue, 26 Jul 2022 19:56:53 -0500, Les Cargill <lcargil99@gmail.com>
    wrote:

    jlarkin@highlandsniptechnology.com wrote:
    On Fri, 22 Jul 2022 21:10:35 -0500, Les Cargill <lcargil99@gmail.com>
    wrote:

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

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


    Engineering is composition. Composition is the thin edge of the musical
    wedge. Musicianship is different; it's pattern identification. As is
    composition but in a different way. But it is all the same thing.

    It all depends on which wall you prefer to have your back against.

    I've always wondered about musicians. They have to play a piece
    hundreds of times to get it right.

    Some do; some don't. Session players from back when studio time
    was the dominant cost probably played the parts on a song you later
    heard on the radio on the first take.

    Some have surely performed
    something thousands of times. Don't they get bored? Apparently not.


    There's too broad a spectrum to generalize. Some forms are better for
    people with mild forms of OCD.

    I design something, finish, and then want to design something entirely
    different.

    It depends on boredom thresholds.


    Much does.


    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?

    Over where they MATLAB.

    SCPI is send-and-forget. There is some query you can send to ask if
    the last command worked. And you can have an error queue that you can
    interrogate now and then for historical forensics.

    I told the customer that damn the specs, every command is going to
    reply with data, an error message, or "OK". They agree.



    And there you go turning a perfectly good full duplex channel into a
    half duplex walkie-talkie channel :)

    It'll be fast enough.

    One might feel a little silly, having sent 14,000 commands to a box
    and then discovering that the power strip is off.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gerhard Hoffmann@21:1/5 to All on Wed Jul 27 11:13:50 2022
    Am 27.07.22 um 08:21 schrieb Anthony William Sloman:
    On Wednesday, July 27, 2022 at 12:34:40 PM UTC+10, Phil Hobbs wrote:
    Joe Gwinn wrote:

    As you suspect, no, it won't. Only better oscillators will help.

    As far as crystals go, we have reached the end.


    This might be the better oscillator.

    https://spectrum.ieee.org/for-precision-the-sapphire-clock-outshines-even-the-best-atomic-clocks?utm_campaign=post-teaser&utm_content=7190c3vu

    It's a big lump of sapphire in a pool of liquid helium. Long term stability isn't wonderful, but short term stability is uniquely good.

    " The team is re-engineering the device to work at 50 K by increasing the concentration of magnetic impurities in the crystal without introducing additional losses. That's a temperature that liquid nitrogen can't quite get to, but it's way easier than
    6 K."

    Apparently the Australian Air Force has two of the 6K devices for their radar network. Probably beyond John Larkin's budget.


    More on this:

    < https://scholar.google.de/scholar?q=poseidon+sapphire+oscillator&hl=de&as_sdt=0&as_vis=1&oi=scholart
    >

    IIRC, Poseidon Scientific Inst. , a spin-off from that
    Australian univ belongs to the Microchip timing empire now.



    < https://sci-hub.mksa.top/10.1109/FREQ.1995.483927 >

    (shorten that ridiculous filenme)
    Driscoll seems to be everywhere it is interesting.

    < http://rubiola.org/ >
    The entire web site is most interesting,
    Alone the reference section!
    In this context:

    < http://rubiola.org/pdf-articles/journal/2019-UFFC--TDDS-Sapphire.pdf >

    < http://rubiola.org/pdf-articles/journal/2016-JPCS-8FSM--Sapphire.pdf >

    and so on.
    He is also into optical oscillators .


    cheers, Gerhard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gerhard Hoffmann@21:1/5 to All on Wed Jul 27 12:12:42 2022
    Am 27.07.22 um 10:36 schrieb Martin Brown:
    On 26/07/2022 13:05, Phil Hobbs wrote:
    Gerhard Hoffmann wrote:
    Am 25.07.22 um 18:31 schrieb Joe Gwinn:
    On Fri, 22 Jul 2022 09:03:16 -0400, Phil Hobbs


    Entrainment of weakly coupled oscillators at frequencies near to each
    other can be quite strong (a problem if you don't want that to happen).

    But I want to lock them to the same frequency and phase anyway
    with dedicated slooow PLLs. Injection locking would just
    take away some control over the corner frequencies of the PLLs.
    As long as the corners a low enough that is not a desaster.
    Say below 0.5 Hz.

    I did not see that the 2 Morion MV89A oscillators I use as a
    cross corr reference talk to each other. The double oven and
    the hermetically soldered box probably help. And there is a
    frequency doubler to the output.


    I think the catch is that to do that you would have to provide hardware
    to compute the cross correlation of every pair of oscillators so that correlator complexity goes up as N(N-1)/2 too. I can't immediately see a
    way to exploit this to get a better average oscillator though.

    My Timepod can do the 3 cornered hat only. Since 2 corners are
    already reserved for the X-Band extension, I cannot remove the
    noise of the reference by cross correlation via the 2
    independent oscillators.

    But then, the X-Band sources are not that wonderful. It's not
    necessary to swim faster than the sharc, It's enough to swim
    faster than your neighbour.

    BUT IT'S STILL FOR THE SPORTS!


    Cheers,
    Gerhard, DK4XP

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jasen Betts@21:1/5 to whit3rd@gmail.com on Wed Jul 27 12:23:46 2022
    On 2022-07-23, whit3rd <whit3rd@gmail.com> wrote:
    On Friday, July 22, 2022 at 2:38:45 PM UTC-7, Don wrote:
    Joe Gwinn wrote:

    <snip>
    Also, I'd lose the BNC connectors. Threaded connectors like SMA, TNC,
    and Type N are far better.

    Or use shielded twisted pair to carry the 1PPS pulses.

    Twisted pair (TP) sounds even easier than BNC. So, what's the
    "catch" with TP? Where's the "gotcha" to make TP harder than BNC?

    Biggest 'gotcha' is the lack of good shielded TP connectors. I had only UHF-style twisted pair shielded connectors last time I wanted some, and that's a polarity-insensitive connector. We applied paint markings
    to get it straight.

    MiniDIN 3 (don't trust the shield connector) was what Apple used for their LocalTalk/Appletalk hardware,

    SVHS ran a higher bandwidth, unbalanced, over the 4 pin version.
    localtalk was only a few hundered kilobaud.

    Shileded pair conectors are fairly common now, USB, HDMI, SATA all give multiple shielded pairs. (SATA is actully untwisted). Oh shit! I
    forgot "RJ45" is also used for STP.

    --




    Jasen.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to Martin Brown on Wed Jul 27 10:13:21 2022
    Martin Brown wrote:
    On 26/07/2022 13:05, Phil Hobbs wrote:
    Gerhard Hoffmann wrote:
    Am 25.07.22 um 18:31 schrieb Joe Gwinn:
    On Fri, 22 Jul 2022 09:03:16 -0400, Phil Hobbs

    "A geometric view of closure phases in interferometry", DOI:
    <https://doi.org/10.1017/pasa.2022.6>

    .<https://www.cambridge.org/core/journals/publications-of-the-astronomical-society-of-australia/article/geometric-view-of-closure-phases-in-interferometry/5E8A5A8D58A2FC72ADFA0587347C4DA7>

    I'm still digesting it, but basically deducing the underlying geometry >>>> allowed for some significant improvements.

    I have not yet digested it, but can I assume that it won't help
    me to create a carrier that is phase noise wise better than
    averaged over 16 oscillators created equally bad?

    More suitable for post-processing after-the-fact?

    U. Rohde has the math for n injection locked oscillators in one
    of his books, but the formulas probably fall apart when you have
    to insert hard numbers for real oscillators you can buy, or build.
    Methinks he is more into multiple coupled resonators.

    Entrainment of weakly coupled oscillators at frequencies near to each
    other can be quite strong (a problem if you don't want that to happen).

    I'm not sure--as I say, I haven't got a properly-thought-out scheme,
    but it seems as though it ought to be possible to combine the
    measurements to produce N-1 oscillator signals, each one N times
    quieter, so that averaging _those_ would get you to the N(N-1)/2 level.

    I think the catch is that to do that you would have to provide hardware
    to compute the cross correlation of every pair of oscillators so that correlator complexity goes up as N(N-1)/2 too. I can't immediately see a
    way to exploit this to get a better average oscillator though.

    It probably needs a whole lot of phase shifters or weighted summers
    (like a Wilkinson with attenuators), so it may well not be a win from
    a total-hardware POV.  Seems like it would be worth a bit of thought,
    though.

    VLBI typically disciplines a hydrogen maser using some other long term
    stable centralised terrestrial time source. Getting it just a little bit wrong just makes the white light fringe much harder to find later. Local clock short term stability stability is the key to it working well.

    I expect they  are a lot better at it by now. In my day it involved
    moving around furniture van loads of tweaked VHS video tape cassettes
    from the big dishes to the correlator centres.

    As the wise man said, "Never underestimate the bandwidth of a truck full
    of tapes."

    Also, variously, a 747 full of tapes, CDs, DVDs, MicroSDs, etc. A
    747-load of 256-GB MicroSDs is about
    256e12 B * 113,400 kg / 0.25 g = 1.16E+23 bytes.

    Six of them would be over 1 Avogadro.

    Of course reading them out in less than the lifetime of the universe
    would take quite a few boxes--it would need a bandwidth of
    1.16E+23 / 3.156e+7 / 15e+9 = 245 kB/s just to do that.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to pcdhSpamMeSenseless@electrooptical. on Wed Jul 27 07:07:09 2022
    On Tue, 26 Jul 2022 11:03:15 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    jlarkin@highlandsniptechnology.com wrote:
    On Tue, 26 Jul 2022 08:05:49 -0400, Phil Hobbs
    <pcdhSpamMeSenseless@electrooptical.net> wrote:

    Gerhard Hoffmann wrote:
    Am 25.07.22 um 18:31 schrieb Joe Gwinn:
    On Fri, 22 Jul 2022 09:03:16 -0400, Phil Hobbs

    "A geometric view of closure phases in interferometry", DOI:
    <https://doi.org/10.1017/pasa.2022.6>

    .<https://www.cambridge.org/core/journals/publications-of-the-astronomical-society-of-australia/article/geometric-view-of-closure-phases-in-interferometry/5E8A5A8D58A2FC72ADFA0587347C4DA7>



    I'm still digesting it, but basically deducing the underlying geometry >>>>> allowed for some significant improvements.

    I have not yet digested it, but can I assume that it won't help
    me to create a carrier that is phase noise wise better than
    averaged over 16 oscillators created equally bad?

    More suitable for post-processing after-the-fact?

    U. Rohde has the math for n injection locked oscillators in one
    of his books, but the formulas probably fall apart when you have
    to insert hard numbers for real oscillators you can buy, or build.
    Methinks he is more into multiple coupled resonators.

    cheers,
    Gerhard

    I'm not sure--as I say, I haven't got a properly-thought-out scheme, but >>> it seems as though it ought to be possible to combine the measurements
    to produce N-1 oscillator signals, each one N times quieter, so that
    averaging _those_ would get you to the N(N-1)/2 level.

    It probably needs a whole lot of phase shifters or weighted summers
    (like a Wilkinson with attenuators), so it may well not be a win from a
    total-hardware POV. Seems like it would be worth a bit of thought, though. >>>
    Cheers

    Phil Hobbs

    Imagine a single circuit/pcb that has N crystal oscillator circuits,
    injection locked and summed, in an oven.

    XOs near one another, namely in the same room, like to injection lock.

    Sure. That only gets you 10*log(N), though, AFAICT. Looking at it from
    a phase noise POV, you win improved <delta phi> like sqrt(N), just as
    you gain lower <delta V> by parallelling JFETs.

    Cheers

    Phil Hobbs

    I'm beyond my pay grade here, but summing jfets can be done with an
    ideal isolated n-port summer and the s/n improvement indeed goes as
    sqrt(n). But injection locking 10 oscillators is different. Each one
    pulls towards the mean of the other nine. They herd one another.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to jlarkin@highlandsniptechnology.com on Wed Jul 27 10:29:44 2022
    jlarkin@highlandsniptechnology.com wrote:
    On Tue, 26 Jul 2022 11:03:15 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    jlarkin@highlandsniptechnology.com wrote:
    On Tue, 26 Jul 2022 08:05:49 -0400, Phil Hobbs
    <pcdhSpamMeSenseless@electrooptical.net> wrote:

    Gerhard Hoffmann wrote:
    Am 25.07.22 um 18:31 schrieb Joe Gwinn:
    On Fri, 22 Jul 2022 09:03:16 -0400, Phil Hobbs

    "A geometric view of closure phases in interferometry", DOI:
    <https://doi.org/10.1017/pasa.2022.6>

    .<https://www.cambridge.org/core/journals/publications-of-the-astronomical-society-of-australia/article/geometric-view-of-closure-phases-in-interferometry/5E8A5A8D58A2FC72ADFA0587347C4DA7>



    I'm still digesting it, but basically deducing the underlying geometry >>>>>> allowed for some significant improvements.

    I have not yet digested it, but can I assume that it won't help
    me to create a carrier that is phase noise wise better than
    averaged over 16 oscillators created equally bad?

    More suitable for post-processing after-the-fact?

    U. Rohde has the math for n injection locked oscillators in one
    of his books, but the formulas probably fall apart when you have
    to insert hard numbers for real oscillators you can buy, or build.
    Methinks he is more into multiple coupled resonators.

    cheers,
    Gerhard

    I'm not sure--as I say, I haven't got a properly-thought-out scheme, but >>>> it seems as though it ought to be possible to combine the measurements >>>> to produce N-1 oscillator signals, each one N times quieter, so that
    averaging _those_ would get you to the N(N-1)/2 level.

    It probably needs a whole lot of phase shifters or weighted summers
    (like a Wilkinson with attenuators), so it may well not be a win from a >>>> total-hardware POV. Seems like it would be worth a bit of thought, though.

    Cheers

    Phil Hobbs

    Imagine a single circuit/pcb that has N crystal oscillator circuits,
    injection locked and summed, in an oven.

    XOs near one another, namely in the same room, like to injection lock.

    Sure. That only gets you 10*log(N), though, AFAICT. Looking at it from
    a phase noise POV, you win improved <delta phi> like sqrt(N), just as
    you gain lower <delta V> by parallelling JFETs.

    Cheers

    Phil Hobbs

    I'm beyond my pay grade here, but summing jfets can be done with an
    ideal isolated n-port summer and the s/n improvement indeed goes as
    sqrt(n). But injection locking 10 oscillators is different. Each one
    pulls towards the mean of the other nine. They herd one another.


    Yup. Inside the locking bandwidth, it's probably possible to make the
    phases chaotic at some level, so the close-in noise might even be worse.

    Outside that, though, as long as the peak phase error is smallish, both amplitude and phase noise look additive, so the usual theorems apply.

    For small epsilon,

    sin(t + epsilon) = sin t cos epsilon + cos t sin epsilon

    ~= sin t + epsilon*cos t, (1)

    so

    (sin(t) + sin(t + epsilon))/2 ~=

    sin t + (epsilon / 2) cos t. (2)


    Using (1) backwards,

    (sin(t) + sin(t + epsilon))/2 ~= sin(t + epsilon / 2).

    With N different epsilons, you have a random phasor sum, which winds up
    with an average phase error going like 1/sqrt(N).

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jlarkin@highlandsniptechnology.com@21:1/5 to pcdhSpamMeSenseless@electrooptical. on Wed Jul 27 08:00:18 2022
    On Wed, 27 Jul 2022 10:29:44 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    jlarkin@highlandsniptechnology.com wrote:
    On Tue, 26 Jul 2022 11:03:15 -0400, Phil Hobbs
    <pcdhSpamMeSenseless@electrooptical.net> wrote:

    jlarkin@highlandsniptechnology.com wrote:
    On Tue, 26 Jul 2022 08:05:49 -0400, Phil Hobbs
    <pcdhSpamMeSenseless@electrooptical.net> wrote:

    Gerhard Hoffmann wrote:
    Am 25.07.22 um 18:31 schrieb Joe Gwinn:
    On Fri, 22 Jul 2022 09:03:16 -0400, Phil Hobbs

    "A geometric view of closure phases in interferometry", DOI:
    <https://doi.org/10.1017/pasa.2022.6>

    .<https://www.cambridge.org/core/journals/publications-of-the-astronomical-society-of-australia/article/geometric-view-of-closure-phases-in-interferometry/5E8A5A8D58A2FC72ADFA0587347C4DA7>



    I'm still digesting it, but basically deducing the underlying geometry >>>>>>> allowed for some significant improvements.

    I have not yet digested it, but can I assume that it won't help
    me to create a carrier that is phase noise wise better than
    averaged over 16 oscillators created equally bad?

    More suitable for post-processing after-the-fact?

    U. Rohde has the math for n injection locked oscillators in one
    of his books, but the formulas probably fall apart when you have
    to insert hard numbers for real oscillators you can buy, or build. >>>>>> Methinks he is more into multiple coupled resonators.

    cheers,
    Gerhard

    I'm not sure--as I say, I haven't got a properly-thought-out scheme, but >>>>> it seems as though it ought to be possible to combine the measurements >>>>> to produce N-1 oscillator signals, each one N times quieter, so that >>>>> averaging _those_ would get you to the N(N-1)/2 level.

    It probably needs a whole lot of phase shifters or weighted summers
    (like a Wilkinson with attenuators), so it may well not be a win from a >>>>> total-hardware POV. Seems like it would be worth a bit of thought, though.

    Cheers

    Phil Hobbs

    Imagine a single circuit/pcb that has N crystal oscillator circuits,
    injection locked and summed, in an oven.

    XOs near one another, namely in the same room, like to injection lock.

    Sure. That only gets you 10*log(N), though, AFAICT. Looking at it from >>> a phase noise POV, you win improved <delta phi> like sqrt(N), just as
    you gain lower <delta V> by parallelling JFETs.

    Cheers

    Phil Hobbs

    I'm beyond my pay grade here, but summing jfets can be done with an
    ideal isolated n-port summer and the s/n improvement indeed goes as
    sqrt(n). But injection locking 10 oscillators is different. Each one
    pulls towards the mean of the other nine. They herd one another.


    Yup. Inside the locking bandwidth, it's probably possible to make the
    phases chaotic at some level, so the close-in noise might even be worse.

    Outside that, though, as long as the peak phase error is smallish, both >amplitude and phase noise look additive, so the usual theorems apply.

    For small epsilon,

    sin(t + epsilon) = sin t cos epsilon + cos t sin epsilon

    ~= sin t + epsilon*cos t, (1)

    so

    (sin(t) + sin(t + epsilon))/2 ~=

    sin t + (epsilon / 2) cos t. (2)


    Using (1) backwards,

    (sin(t) + sin(t + epsilon))/2 ~= sin(t + epsilon / 2).

    With N different epsilons, you have a random phasor sum, which winds up
    with an average phase error going like 1/sqrt(N).

    Cheers

    Phil Hobbs

    Of course the summing follows the usual linear equations AFTER the
    oscillators are locked. But the things being summed are changed by the
    phase locking, not independent sources any more.

    If one oscillator is the big outlier, it gets all nine others pounding
    on it to get in sync. Injection locking is fundamentally nonlinear.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gerhard Hoffmann@21:1/5 to All on Wed Jul 27 18:13:39 2022
    Am 27.07.22 um 16:13 schrieb Phil Hobbs:

    I expect they  are a lot better at it by now. In my day it involved
    moving around furniture van loads of tweaked VHS video tape cassettes
    from the big dishes to the correlator centres.

    As the wise man said, "Never underestimate the bandwidth of a truck full
    of tapes."

    That was Andy Tanenbaum, either in his book "Structured Computer
    Organisation" or in a guest lecture i saw at TU Berlin.
    I was seldom more impressed by a prof.

    He announced the "Free Univerity Compiler Kit", from the
    Free Univerity Amsterdam. :-)


    Gerhard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jan Panteltje@21:1/5 to dk4xp@arcor.de on Wed Jul 27 15:58:50 2022
    On a sunny day (Wed, 27 Jul 2022 12:12:42 +0200) it happened Gerhard Hoffmann <dk4xp@arcor.de> wrote in <tbr32q$qg7c$1@solani.org>:

    Am 27.07.22 um 10:36 schrieb Martin Brown:
    On 26/07/2022 13:05, Phil Hobbs wrote:
    Gerhard Hoffmann wrote:
    Am 25.07.22 um 18:31 schrieb Joe Gwinn:
    On Fri, 22 Jul 2022 09:03:16 -0400, Phil Hobbs


    Entrainment of weakly coupled oscillators at frequencies near to each
    other can be quite strong (a problem if you don't want that to happen).

    But I want to lock them to the same frequency and phase anyway
    with dedicated slooow PLLs. Injection locking would just
    take away some control over the corner frequencies of the PLLs.
    As long as the corners a low enough that is not a desaster.
    Say below 0.5 Hz.

    No idea what you are doing, but in the old days of Ampex broadcast videotape recorders there were several loops on top of each other to get the color carrier to nano seconds precision in playback
    1) slow one capstan tape speed
    2) 4 head rotating scanning head to get the signal from tape
    3) AMTEC (Automatic Time Element Compensator) a variable delay to get the video to micro second correct phase
    4) Colortec a vaiable delay to sync the playback 4.43 MHz playback color carrier to the studio precision reference
    all this so they could cross-fade and edit and use effects, and people's TVs would sync. and display color.

    Old tech...
    Slow PLL was not the way it worked,
    From tape speed variations to nano second precision.
    google Ampex AMTEC and Ampex Colortec
    sixties and seventies

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gerhard Hoffmann@21:1/5 to All on Wed Jul 27 18:19:08 2022
    Am 27.07.22 um 18:13 schrieb Gerhard Hoffmann:

    He announced the "Free Univerity Compiler Kit", from the
    Free Univerity Amsterdam.  :-)

    :gs/Univerity/University/

    I hate that keyboard.


    Gerhard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gerhard Hoffmann@21:1/5 to All on Wed Jul 27 18:34:34 2022
    Am 27.07.22 um 17:00 schrieb jlarkin@highlandsniptechnology.com:

    Of course the summing follows the usual linear equations AFTER the oscillators are locked. But the things being summed are changed by the
    phase locking, not independent sources any more.

    If one oscillator is the big outlier, it gets all nine others pounding
    on it to get in sync. Injection locking is fundamentally nonlinear.

    No, they all follow the Lucent GPS timing receiver and its own MTI-260
    oven by a dedicated PLL in my case

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to Gerhard Hoffmann on Wed Jul 27 12:54:53 2022
    Gerhard Hoffmann wrote:
    Am 27.07.22 um 16:13 schrieb Phil Hobbs:

    I expect they  are a lot better at it by now. In my day it involved
    moving around furniture van loads of tweaked VHS video tape cassettes
    from the big dishes to the correlator centres.

    As the wise man said, "Never underestimate the bandwidth of a truck
    full of tapes."

    That was Andy Tanenbaum, either in his book "Structured Computer Organisation" or in a guest lecture i saw at TU Berlin.
    I was seldom more impressed by a prof.

    He announced the "Free Univerity Compiler Kit", from the
    Free Univerity Amsterdam.  :-)

    Well, after all, it's more prestigious than the South Holland Institute
    of Technology.

    Cheers

    Phil Hobbs

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don@21:1/5 to Les Cargill on Wed Jul 27 16:50:16 2022
    Les Cargill wrote:
    jlarkin@highlandsniptechnology.com wrote:
    Les Cargill wrote:
    jlarkin@highlandsniptechnology.com wrote:
    Phil Hobbs wrote:
    <snip>
    Phil Hobbs

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

    Engineering is composition. Composition is the thin edge of the musical
    wedge. Musicianship is different; it's pattern identification. As is
    composition but in a different way. But it is all the same thing.

    It all depends on which wall you prefer to have your back against.

    I've always wondered about musicians. They have to play a piece
    hundreds of times to get it right.

    Some do; some don't. Session players from back when studio time
    was the dominant cost probably played the parts on a song you later
    heard on the radio on the first take.

    Some have surely performed
    something thousands of times. Don't they get bored? Apparently not.


    There's too broad a spectrum to generalize. Some forms are better for
    people with mild forms of OCD.

    I design something, finish, and then want to design something entirely
    different.

    It depends on boredom thresholds.


    Much does.

    <snip>

    My much older, late partner used to play saxophone in High School in the
    1950s. He belonged to an Illinois union and said you had to sight read
    sheet music to join the union.
    It was the big band era. To keep costs down, the band's core, of say
    six musicians, would tour and then hire local union musicians for a one
    night stand in order to fill out the big band.

    There's a Muscle Shoals studio interview somewhere out on the Inet. In
    it one of the sessions players talks about how he played by ear - at
    first. Until someone told him he needed to wise-up and learn how to
    sight read in order to earn the easiest money.

    My church's two volume songbook contains 634 songs. And a different mix
    is played each weekend. It's best to simply sight read the songs, as
    needed.

    Humble symphony orchestras work it about the same. Part-time musicians
    pick up their sheet music a day or two before a concert. There's simply
    not enough available time to "play a piece hundreds of times to get it
    right."

    Danke,

    --
    Don, KB7RPU, https://www.qsl.net/kb7rpu
    There was a young lady named Bright Whose speed was far faster than light;
    She set out one day In a relative way And returned on the previous night.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to jlarkin@highlandsniptechnology.com on Wed Jul 27 12:51:38 2022
    jlarkin@highlandsniptechnology.com wrote:
    On Wed, 27 Jul 2022 10:29:44 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    jlarkin@highlandsniptechnology.com wrote:
    On Tue, 26 Jul 2022 11:03:15 -0400, Phil Hobbs
    <pcdhSpamMeSenseless@electrooptical.net> wrote:

    jlarkin@highlandsniptechnology.com wrote:
    On Tue, 26 Jul 2022 08:05:49 -0400, Phil Hobbs
    <pcdhSpamMeSenseless@electrooptical.net> wrote:

    Gerhard Hoffmann wrote:
    Am 25.07.22 um 18:31 schrieb Joe Gwinn:
    On Fri, 22 Jul 2022 09:03:16 -0400, Phil Hobbs

    "A geometric view of closure phases in interferometry", DOI:
    <https://doi.org/10.1017/pasa.2022.6>

    .<https://www.cambridge.org/core/journals/publications-of-the-astronomical-society-of-australia/article/geometric-view-of-closure-phases-in-interferometry/5E8A5A8D58A2FC72ADFA0587347C4DA7>



    I'm still digesting it, but basically deducing the underlying geometry >>>>>>>> allowed for some significant improvements.

    I have not yet digested it, but can I assume that it won't help
    me to create a carrier that is phase noise wise better than
    averaged over 16 oscillators created equally bad?

    More suitable for post-processing after-the-fact?

    U. Rohde has the math for n injection locked oscillators in one
    of his books, but the formulas probably fall apart when you have >>>>>>> to insert hard numbers for real oscillators you can buy, or build. >>>>>>> Methinks he is more into multiple coupled resonators.

    cheers,
    Gerhard

    I'm not sure--as I say, I haven't got a properly-thought-out scheme, but >>>>>> it seems as though it ought to be possible to combine the measurements >>>>>> to produce N-1 oscillator signals, each one N times quieter, so that >>>>>> averaging _those_ would get you to the N(N-1)/2 level.

    It probably needs a whole lot of phase shifters or weighted summers >>>>>> (like a Wilkinson with attenuators), so it may well not be a win from a >>>>>> total-hardware POV. Seems like it would be worth a bit of thought, though.

    Cheers

    Phil Hobbs

    Imagine a single circuit/pcb that has N crystal oscillator circuits, >>>>> injection locked and summed, in an oven.

    XOs near one another, namely in the same room, like to injection lock. >>>>
    Sure. That only gets you 10*log(N), though, AFAICT. Looking at it from >>>> a phase noise POV, you win improved <delta phi> like sqrt(N), just as
    you gain lower <delta V> by parallelling JFETs.

    Cheers

    Phil Hobbs

    I'm beyond my pay grade here, but summing jfets can be done with an
    ideal isolated n-port summer and the s/n improvement indeed goes as
    sqrt(n). But injection locking 10 oscillators is different. Each one
    pulls towards the mean of the other nine. They herd one another.


    Yup. Inside the locking bandwidth, it's probably possible to make the
    phases chaotic at some level, so the close-in noise might even be worse.

    Outside that, though, as long as the peak phase error is smallish, both
    amplitude and phase noise look additive, so the usual theorems apply.

    For small epsilon,

    sin(t + epsilon) = sin t cos epsilon + cos t sin epsilon

    ~= sin t + epsilon*cos t, (1)

    so

    (sin(t) + sin(t + epsilon))/2 ~=

    sin t + (epsilon / 2) cos t. (2)


    Using (1) backwards,

    (sin(t) + sin(t + epsilon))/2 ~= sin(t + epsilon / 2).

    With N different epsilons, you have a random phasor sum, which winds up
    with an average phase error going like 1/sqrt(N).



    Of course the summing follows the usual linear equations AFTER the oscillators are locked. But the things being summed are changed by the
    phase locking, not independent sources any more.

    Well outside the lock bandwidth, they'd be pretty well independent, I
    should think.

    If one oscillator is the big outlier, it gets all nine others pounding
    on it to get in sync. Injection locking is fundamentally nonlinear.

    Yes, and the math is very pretty, as I remember--all sorts of
    bifurcations and strange attractors and limit cycles and stuff. It gets
    more boring with weaker coupling, which is usually all you need.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Larkin@21:1/5 to pcdhSpamMeSenseless@electrooptical. on Wed Jul 27 10:14:20 2022
    On Wed, 27 Jul 2022 10:13:21 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    Martin Brown wrote:
    On 26/07/2022 13:05, Phil Hobbs wrote:
    Gerhard Hoffmann wrote:
    Am 25.07.22 um 18:31 schrieb Joe Gwinn:
    On Fri, 22 Jul 2022 09:03:16 -0400, Phil Hobbs

    "A geometric view of closure phases in interferometry", DOI:
    <https://doi.org/10.1017/pasa.2022.6>

    .<https://www.cambridge.org/core/journals/publications-of-the-astronomical-society-of-australia/article/geometric-view-of-closure-phases-in-interferometry/5E8A5A8D58A2FC72ADFA0587347C4DA7>

    I'm still digesting it, but basically deducing the underlying geometry >>>>> allowed for some significant improvements.

    I have not yet digested it, but can I assume that it won't help
    me to create a carrier that is phase noise wise better than
    averaged over 16 oscillators created equally bad?

    More suitable for post-processing after-the-fact?

    U. Rohde has the math for n injection locked oscillators in one
    of his books, but the formulas probably fall apart when you have
    to insert hard numbers for real oscillators you can buy, or build.
    Methinks he is more into multiple coupled resonators.

    Entrainment of weakly coupled oscillators at frequencies near to each
    other can be quite strong (a problem if you don't want that to happen).

    I'm not sure--as I say, I haven't got a properly-thought-out scheme,
    but it seems as though it ought to be possible to combine the
    measurements to produce N-1 oscillator signals, each one N times
    quieter, so that averaging _those_ would get you to the N(N-1)/2 level.

    I think the catch is that to do that you would have to provide hardware
    to compute the cross correlation of every pair of oscillators so that
    correlator complexity goes up as N(N-1)/2 too. I can't immediately see a
    way to exploit this to get a better average oscillator though.

    It probably needs a whole lot of phase shifters or weighted summers
    (like a Wilkinson with attenuators), so it may well not be a win from
    a total-hardware POV. Seems like it would be worth a bit of thought,
    though.

    VLBI typically disciplines a hydrogen maser using some other long term
    stable centralised terrestrial time source. Getting it just a little bit
    wrong just makes the white light fringe much harder to find later. Local
    clock short term stability stability is the key to it working well.

    I expect they are a lot better at it by now. In my day it involved
    moving around furniture van loads of tweaked VHS video tape cassettes
    from the big dishes to the correlator centres.

    As the wise man said, "Never underestimate the bandwidth of a truck full
    of tapes."

    Also, variously, a 747 full of tapes, CDs, DVDs, MicroSDs, etc. A
    747-load of 256-GB MicroSDs is about
    256e12 B * 113,400 kg / 0.25 g = 1.16E+23 bytes.

    Six of them would be over 1 Avogadro.

    Of course reading them out in less than the lifetime of the universe
    would take quite a few boxes--it would need a bandwidth of
    1.16E+23 / 3.156e+7 / 15e+9 = 245 kB/s just to do that.

    Cheers

    Phil Hobbs

    I suspected that I've been taking too many pictures.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to pcdhSpamMeSenseless@electrooptical. on Wed Jul 27 16:37:01 2022
    On Fri, 22 Jul 2022 21:12:31 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    Joe Gwinn wrote:
    On Fri, 22 Jul 2022 21:38:39 -0000 (UTC), "Don" <g@crcomp.net> wrote:

    Joe Gwinn wrote:

    <snip>

    Also, I'd lose the BNC connectors. Threaded connectors like SMA, TNC, >>>> and Type N are far better.

    Or use shielded twisted pair to carry the 1PPS pulses. This would
    work better over a backplane.

    This is good advice. Even though the lazy guy within me never truly
    gives up his fight to take the easy way out with BNC.
    Twisted pair (TP) sounds even easier than BNC. So, what's the
    "catch" with TP? Where's the "gotcha" to make TP harder than BNC?

    Depends on what you are trying to do.

    For nanosecond edges, coax is pretty useful, but short range and often
    mechanically awkward.

    For microsecond edges at 1000 meters, RS422 over shielded twisted pair
    is pretty good.

    For bus length links, LVDS or the like.

    And so on. And there is always optical links.

    Joe Gwinn


    BNCs are the bomb, as long as you aren't putting 500 of them in series,
    as with the old 10base2 coax Ethernet.

    TNCs are a very small niche, and N connectors belong only on spectrum >analyzers.

    The issue with BNCs in phase-critical radar timing systems is that the
    delay through a BNC can jump by a few picoseconds from mechanical
    rattling. If the signal traversing the BNC is subsequently multiplied
    up into the GHz, the angular phase shifts can become intolerable.
    Especially in a high-vibration environment.

    BNCs are also somewhat leaky, even in the precision grades.

    So, BNCs are usually forbidden except for test outputs. Only threaded
    coax connectors, or mechanically stable blind-mate, or the like are
    allowed.


    Joe Gwinn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Walliker@21:1/5 to Joe Gwinn on Wed Jul 27 14:18:34 2022
    On Wednesday, 27 July 2022 at 21:37:14 UTC+1, Joe Gwinn wrote:
    On Fri, 22 Jul 2022 21:12:31 -0400, Phil Hobbs <pcdhSpamM...@electrooptical.net> wrote:

    Joe Gwinn wrote:
    On Fri, 22 Jul 2022 21:38:39 -0000 (UTC), "Don" <g...@crcomp.net> wrote: >>
    Joe Gwinn wrote:

    <snip>

    Also, I'd lose the BNC connectors. Threaded connectors like SMA, TNC, >>>> and Type N are far better.

    Or use shielded twisted pair to carry the 1PPS pulses. This would
    work better over a backplane.

    This is good advice. Even though the lazy guy within me never truly
    gives up his fight to take the easy way out with BNC.
    Twisted pair (TP) sounds even easier than BNC. So, what's the
    "catch" with TP? Where's the "gotcha" to make TP harder than BNC?

    Depends on what you are trying to do.

    For nanosecond edges, coax is pretty useful, but short range and often
    mechanically awkward.

    For microsecond edges at 1000 meters, RS422 over shielded twisted pair
    is pretty good.

    For bus length links, LVDS or the like.

    And so on. And there is always optical links.

    Joe Gwinn


    BNCs are the bomb, as long as you aren't putting 500 of them in series,
    as with the old 10base2 coax Ethernet.

    TNCs are a very small niche, and N connectors belong only on spectrum >analyzers.

    The issue with BNCs in phase-critical radar timing systems is that the
    delay through a BNC can jump by a few picoseconds from mechanical
    rattling. If the signal traversing the BNC is subsequently multiplied
    up into the GHz, the angular phase shifts can become intolerable.
    Especially in a high-vibration environment.

    BNCs are also somewhat leaky, even in the precision grades.

    So, BNCs are usually forbidden except for test outputs. Only threaded
    coax connectors, or mechanically stable blind-mate, or the like are
    allowed.

    N connectors have their problems too. I discovered that if they are hand-tightened
    fairly gently they can introduce losses of 1 or 2 dB at about 1.2 or 1.3GHz.

    John

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil Hobbs@21:1/5 to Joe Gwinn on Wed Jul 27 17:22:03 2022
    Joe Gwinn wrote:
    On Fri, 22 Jul 2022 21:12:31 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    Joe Gwinn wrote:
    On Fri, 22 Jul 2022 21:38:39 -0000 (UTC), "Don" <g@crcomp.net> wrote:

    Joe Gwinn wrote:

    <snip>

    Also, I'd lose the BNC connectors. Threaded connectors like SMA, TNC, >>>>> and Type N are far better.

    Or use shielded twisted pair to carry the 1PPS pulses. This would
    work better over a backplane.

    This is good advice. Even though the lazy guy within me never truly
    gives up his fight to take the easy way out with BNC.
    Twisted pair (TP) sounds even easier than BNC. So, what's the
    "catch" with TP? Where's the "gotcha" to make TP harder than BNC?

    Depends on what you are trying to do.

    For nanosecond edges, coax is pretty useful, but short range and often
    mechanically awkward.

    For microsecond edges at 1000 meters, RS422 over shielded twisted pair
    is pretty good.

    For bus length links, LVDS or the like.

    And so on. And there is always optical links.

    Joe Gwinn


    BNCs are the bomb, as long as you aren't putting 500 of them in series,
    as with the old 10base2 coax Ethernet.

    TNCs are a very small niche, and N connectors belong only on spectrum
    analyzers.

    The issue with BNCs in phase-critical radar timing systems is that the
    delay through a BNC can jump by a few picoseconds from mechanical
    rattling. If the signal traversing the BNC is subsequently multiplied
    up into the GHz, the angular phase shifts can become intolerable.
    Especially in a high-vibration environment.

    BNCs are also somewhat leaky, even in the precision grades.

    So, BNCs are usually forbidden except for test outputs. Only threaded
    coax connectors, or mechanically stable blind-mate, or the like are
    allowed.


    Joe Gwinn


    For synthetic-aperture radars, I believe that--small phase transients
    are bad news. I had a similar experience long ago.

    When I was a grad student, back around 1985-6, I built a heterodyne interferometric scanning laser microscope.

    It had a 13-bit phase digitizer, which used a nulling technique to
    measure phase directly. There was an AM2504 successive-approximation
    register, driving an AD DAC80 12-bit DAC, driving a homemade linearized varactor phase shifter, with a MCL RPD-1 phase detector looking for a
    null. (All dead-bug construction.)

    One extra SAR cycle (with an external d-flop) made sure it was shooting
    for the stable null, making 13 bits in all. It ran at the 60-MHz IF,
    and pi phase was about 6000 LSBs, so 1 LSB was equivalent to

    dt = 1/(6000 * 60 MHz) = 2.8 ps.

    It had an associated calibrator, based on two 60-MHz crystal oscillators
    locked together with a divide-by-360 counter on each. The counters had
    (iirc) 11C90 10/11 prescalers, and one of them had the appropriate logic
    for a pulse-swallower. That way the two outputs could be phase shifted
    in exact 1-degree increments. A whole lot of attention was paid to
    shielding and isolation amps and so forth, because any leakage of one
    signal into the other above the -80 dB level would cause measurable
    phase whoopdedoos.

    Fortunately that was easy to verify by sitting on the pulse-swallowing
    button, which moved the frequency enough to see any spurs on the
    spectrum analyzer. (I borrowed an 8566A from another group for the
    purpose.)

    Calibrating the phase shifter with 1-degree steps made it easy to run a
    cubic spline through the data to 1-LSB accuracy. Linearizing the phase
    shifter meant that the conversion of 1 LSB to delta phase didn't vary
    much across the range--it was always around 3 ps.

    Jiggling coax cables during a measurement made for some very
    entertaining image artifacts there too.

    Cheers

    Phil Hobbs

    (Taking today off because it's so nice out, and because I can.)

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to jrwalliker@gmail.com on Wed Jul 27 19:16:34 2022
    On Wed, 27 Jul 2022 14:18:34 -0700 (PDT), John Walliker
    <jrwalliker@gmail.com> wrote:

    On Wednesday, 27 July 2022 at 21:37:14 UTC+1, Joe Gwinn wrote:
    On Fri, 22 Jul 2022 21:12:31 -0400, Phil Hobbs
    <pcdhSpamM...@electrooptical.net> wrote:

    Joe Gwinn wrote:
    On Fri, 22 Jul 2022 21:38:39 -0000 (UTC), "Don" <g...@crcomp.net> wrote: >> >>
    Joe Gwinn wrote:

    <snip>

    Also, I'd lose the BNC connectors. Threaded connectors like SMA, TNC, >> >>>> and Type N are far better.

    Or use shielded twisted pair to carry the 1PPS pulses. This would
    work better over a backplane.

    This is good advice. Even though the lazy guy within me never truly
    gives up his fight to take the easy way out with BNC.
    Twisted pair (TP) sounds even easier than BNC. So, what's the
    "catch" with TP? Where's the "gotcha" to make TP harder than BNC?

    Depends on what you are trying to do.

    For nanosecond edges, coax is pretty useful, but short range and often
    mechanically awkward.

    For microsecond edges at 1000 meters, RS422 over shielded twisted pair
    is pretty good.

    For bus length links, LVDS or the like.

    And so on. And there is always optical links.

    Joe Gwinn


    BNCs are the bomb, as long as you aren't putting 500 of them in series,
    as with the old 10base2 coax Ethernet.

    TNCs are a very small niche, and N connectors belong only on spectrum
    analyzers.

    The issue with BNCs in phase-critical radar timing systems is that the
    delay through a BNC can jump by a few picoseconds from mechanical
    rattling. If the signal traversing the BNC is subsequently multiplied
    up into the GHz, the angular phase shifts can become intolerable.
    Especially in a high-vibration environment.

    BNCs are also somewhat leaky, even in the precision grades.

    So, BNCs are usually forbidden except for test outputs. Only threaded
    coax connectors, or mechanically stable blind-mate, or the like are
    allowed.

    N connectors have their problems too. I discovered that if they are hand-tightened
    fairly gently they can introduce losses of 1 or 2 dB at about 1.2 or 1.3GHz.

    Yes, all threaded connectors need to torqued to the "inspection
    torque" value specified by the manufacturer, using a actual torque
    wrench.

    Joe Gwinn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to pcdhSpamMeSenseless@electrooptical. on Wed Jul 27 19:26:57 2022
    On Wed, 27 Jul 2022 17:22:03 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:

    Joe Gwinn wrote:
    On Fri, 22 Jul 2022 21:12:31 -0400, Phil Hobbs
    <pcdhSpamMeSenseless@electrooptical.net> wrote:

    Joe Gwinn wrote:
    On Fri, 22 Jul 2022 21:38:39 -0000 (UTC), "Don" <g@crcomp.net> wrote:

    Joe Gwinn wrote:

    <snip>

    Also, I'd lose the BNC connectors. Threaded connectors like SMA, TNC, >>>>>> and Type N are far better.

    Or use shielded twisted pair to carry the 1PPS pulses. This would >>>>>> work better over a backplane.

    This is good advice. Even though the lazy guy within me never truly
    gives up his fight to take the easy way out with BNC.
    Twisted pair (TP) sounds even easier than BNC. So, what's the
    "catch" with TP? Where's the "gotcha" to make TP harder than BNC?

    Depends on what you are trying to do.

    For nanosecond edges, coax is pretty useful, but short range and often >>>> mechanically awkward.

    For microsecond edges at 1000 meters, RS422 over shielded twisted pair >>>> is pretty good.

    For bus length links, LVDS or the like.

    And so on. And there is always optical links.

    Joe Gwinn


    BNCs are the bomb, as long as you aren't putting 500 of them in series,
    as with the old 10base2 coax Ethernet.

    TNCs are a very small niche, and N connectors belong only on spectrum
    analyzers.

    The issue with BNCs in phase-critical radar timing systems is that the
    delay through a BNC can jump by a few picoseconds from mechanical
    rattling. If the signal traversing the BNC is subsequently multiplied
    up into the GHz, the angular phase shifts can become intolerable.
    Especially in a high-vibration environment.

    BNCs are also somewhat leaky, even in the precision grades.

    So, BNCs are usually forbidden except for test outputs. Only threaded
    coax connectors, or mechanically stable blind-mate, or the like are
    allowed.


    Joe Gwinn


    For synthetic-aperture radars, I believe that--small phase transients
    are bad news. I had a similar experience long ago.

    When I was a grad student, back around 1985-6, I built a heterodyne >interferometric scanning laser microscope.

    It had a 13-bit phase digitizer, which used a nulling technique to
    measure phase directly. There was an AM2504 successive-approximation >register, driving an AD DAC80 12-bit DAC, driving a homemade linearized >varactor phase shifter, with a MCL RPD-1 phase detector looking for a
    null. (All dead-bug construction.)

    One extra SAR cycle (with an external d-flop) made sure it was shooting
    for the stable null, making 13 bits in all. It ran at the 60-MHz IF,
    and pi phase was about 6000 LSBs, so 1 LSB was equivalent to

    dt = 1/(6000 * 60 MHz) = 2.8 ps.

    It had an associated calibrator, based on two 60-MHz crystal oscillators >locked together with a divide-by-360 counter on each. The counters had >(iirc) 11C90 10/11 prescalers, and one of them had the appropriate logic
    for a pulse-swallower. That way the two outputs could be phase shifted
    in exact 1-degree increments. A whole lot of attention was paid to
    shielding and isolation amps and so forth, because any leakage of one
    signal into the other above the -80 dB level would cause measurable
    phase whoopdedoos.

    Oh yes. Must use only double-shielded or better coax - RG-58 need not
    apply.

    Also must worry about power-frequency ground loops driving large
    currents through the coax shield.


    Fortunately that was easy to verify by sitting on the pulse-swallowing >button, which moved the frequency enough to see any spurs on the
    spectrum analyzer. (I borrowed an 8566A from another group for the
    purpose.)

    Calibrating the phase shifter with 1-degree steps made it easy to run a
    cubic spline through the data to 1-LSB accuracy. Linearizing the phase >shifter meant that the conversion of 1 LSB to delta phase didn't vary
    much across the range--it was always around 3 ps.

    Jiggling coax cables during a measurement made for some very
    entertaining image artifacts there too.


    Yes, exactly the same kinds of things bedevil phased-array radars.


    Joe Gwinn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Les Cargill@21:1/5 to jlarkin@highlandsniptechnology.com on Wed Jul 27 19:44:21 2022
    jlarkin@highlandsniptechnology.com wrote:
    On Tue, 26 Jul 2022 19:56:53 -0500, Les Cargill <lcargil99@gmail.com>
    wrote:

    jlarkin@highlandsniptechnology.com wrote:
    On Fri, 22 Jul 2022 21:10:35 -0500, Les Cargill <lcargil99@gmail.com>
    wrote:

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

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


    Engineering is composition. Composition is the thin edge of the musical >>>> wedge. Musicianship is different; it's pattern identification. As is
    composition but in a different way. But it is all the same thing.

    It all depends on which wall you prefer to have your back against.

    I've always wondered about musicians. They have to play a piece
    hundreds of times to get it right.

    Some do; some don't. Session players from back when studio time
    was the dominant cost probably played the parts on a song you later
    heard on the radio on the first take.

    Some have surely performed
    something thousands of times. Don't they get bored? Apparently not.


    There's too broad a spectrum to generalize. Some forms are better for
    people with mild forms of OCD.

    I design something, finish, and then want to design something entirely
    different.

    It depends on boredom thresholds.


    Much does.


    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?

    Over where they MATLAB.

    SCPI is send-and-forget. There is some query you can send to ask if
    the last command worked. And you can have an error queue that you can
    interrogate now and then for historical forensics.

    I told the customer that damn the specs, every command is going to
    reply with data, an error message, or "OK". They agree.



    And there you go turning a perfectly good full duplex channel into a
    half duplex walkie-talkie channel :)

    It'll be fast enough.

    One might feel a little silly, having sent 14,000 commands to a box
    and then discovering that the power strip is off.



    There are a small eternity of approaches. Line turnarounds are one.

    --
    Les Cargill

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Les Cargill@21:1/5 to Don on Wed Jul 27 19:46:30 2022
    Don wrote:
    Les Cargill wrote:
    jlarkin@highlandsniptechnology.com wrote:
    Les Cargill wrote:
    jlarkin@highlandsniptechnology.com wrote:
    Phil Hobbs wrote:
    <snip>
    Phil Hobbs

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

    Engineering is composition. Composition is the thin edge of the musical >>>> wedge. Musicianship is different; it's pattern identification. As is
    composition but in a different way. But it is all the same thing.

    It all depends on which wall you prefer to have your back against.

    I've always wondered about musicians. They have to play a piece
    hundreds of times to get it right.

    Some do; some don't. Session players from back when studio time
    was the dominant cost probably played the parts on a song you later
    heard on the radio on the first take.

    Some have surely performed
    something thousands of times. Don't they get bored? Apparently not.


    There's too broad a spectrum to generalize. Some forms are better for
    people with mild forms of OCD.

    I design something, finish, and then want to design something entirely
    different.

    It depends on boredom thresholds.


    Much does.

    <snip>

    My much older, late partner used to play saxophone in High School in the 1950s. He belonged to an Illinois union and said you had to sight read
    sheet music to join the union.
    It was the big band era. To keep costs down, the band's core, of say
    six musicians, would tour and then hire local union musicians for a one
    night stand in order to fill out the big band.

    There's a Muscle Shoals studio interview somewhere out on the Inet. In
    it one of the sessions players talks about how he played by ear - at
    first. Until someone told him he needed to wise-up and learn how to
    sight read in order to earn the easiest money.

    My church's two volume songbook contains 634 songs. And a different mix
    is played each weekend. It's best to simply sight read the songs, as
    needed.

    Humble symphony orchestras work it about the same. Part-time musicians
    pick up their sheet music a day or two before a concert. There's simply
    not enough available time to "play a piece hundreds of times to get it right."


    Just so. I think of solo concert pianists as the people who woodshed
    the most. But they can probably produce a passable rendition on first
    read.

    Danke,


    --
    Les Cargill

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to Phil Hobbs on Thu Jul 28 09:10:54 2022
    On 27/07/2022 15:13, Phil Hobbs wrote:
    Martin Brown wrote:

    I expect they  are a lot better at it by now. In my day it involved
    moving around furniture van loads of tweaked VHS video tape cassettes
    from the big dishes to the correlator centres.

    As the wise man said, "Never underestimate the bandwidth of a truck full
    of tapes."

    It works well and was very cost effective.
    Tapes got reused after a while..

    Also, variously, a 747 full of tapes, CDs, DVDs, MicroSDs, etc.  A
    747-load of 256-GB MicroSDs is about
    256e12 B * 113,400 kg / 0.25 g = 1.16E+23 bytes.

    Six of them would be over 1 Avogadro.

    The recent black hole images were using about 5e15 bytes of data each.

    Disks and mass storage capacity generally have got a lot bigger. The
    plastic chips in Star Trek (original) look huge in comparison to sD.

    --
    Regards,
    Martin Brown

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)