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

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

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>

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.

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

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

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

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

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

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.

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

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"

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

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

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

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.