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
really slow PLL
Started by ●July 20, 2022
Reply by ●July 21, 20222022-07-21
Reply by ●July 21, 20222022-07-21
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
Reply by ●July 21, 20222022-07-21
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.
Reply by ●July 21, 20222022-07-21
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.
Reply by ●July 21, 20222022-07-21
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
Reply by ●July 21, 20222022-07-21
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.
Reply by ●July 21, 20222022-07-21
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, GerhardI 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
Reply by ●July 21, 20222022-07-21
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
Reply by ●July 21, 20222022-07-21
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>
Reply by ●July 21, 20222022-07-21
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
