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.
really slow PLL
Started by ●July 20, 2022
Reply by ●July 21, 20222022-07-21
Reply by ●July 21, 20222022-07-21
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
Reply by ●July 21, 20222022-07-21
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.
Reply by ●July 21, 20222022-07-21
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
Reply by ●July 21, 20222022-07-21
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 HobbsA 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.
Reply by ●July 21, 20222022-07-21
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 HobbsMathematicians 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?
Reply by ●July 21, 20222022-07-21
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.> CheersGerhard
Reply by ●July 21, 20222022-07-21
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.
Reply by ●July 21, 20222022-07-21
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 :-(
Reply by ●July 21, 20222022-07-21
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 > GerhardSure. 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
