Electronics-Related.com
Forums

really slow PLL

Started by John Larkin July 20, 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.. `._.-(,_..'--(,_..'`-.;.'
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.
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
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
Am 23.07.22 um 08:35 schrieb Clifford Heath:
> On 23/7/22 02:02, Don wrote: >> &nbsp;&nbsp;&nbsp;&nbsp; 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
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
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.
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
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
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