Re: OT: sound speed depends on frequency on mars

On 2/09/2024 2:32 am, john larkin wrote:

On Mon, 2 Sep 2024 01:24:18 +1000, Bill Sloman <bill.sloman@ieee.org>
wrote:
 

On 2/09/2024 12:27 am, john larkin wrote:

On Sun, 1 Sep 2024 15:34:13 +1000, Bill Sloman <bill.sloman@ieee.org>
wrote:
>

Meander-line sections connected by loading coils could be interesting.
One product that I'm considering now is a programmable delay line, and
that idea might help.

>
Like the MC100EP195?
>
https://www.onsemi.com/pdf/datasheet/mc100ep195-d.pdf
>
You do seem to spend a lot of time re-inventing the wheel, and
congratulating yourself on the originality of your re-invented concepts.

>
I've tested that part. It's expensive, drifty, and has an insane
amount of jitter. It's funny that its resolution is "about 10 ps"

 Monotonicity is TBD! It should say "Fat Chance."
 Our ramp delay generators are absolutely monotonic.
 

>
It's resolution is about 10psec, because that's the - temperature
dependent - delay through individual delay elements. If you want it to
be more precise, you have to control the part's temperature, or
re-calibrate every few minutes. That's what I was planning to do when I
contemplated using it, and figured that I could get it done within a
millisecond - which did call for a fast A/D. Which one I can't remember
because it was back in 1998.

 Temperature control, and periodic recalibration, are not practical in
a sensible instrument. What do you do if the customer makes a trigger
when you're in the middle of calibrating? Blow up their laser?
 We calibrate delay generators in production test, and they work fine
after that.
 

>
The RMS random clock jitter is specified on page 10 of the data sheet,
and it's around 1psec which pretty standard for ECL parts - not remotely
insane.
>

 I measured a lot more. And the horrible delay tempco is essentially
jitter, as far as a customer is concerned.
  

The nice thing about ECL is that it doesn't mess up it's power rails in
the way that CMOS and TTL do, which does get rid of one jitter source.
>
I once got rid of some nasty sub-nanosecond jitter on a TTL clock by
generating it in ECL (run between 0V and -4.5V) and getting it
out of an ECL-to-TTL converter.
>
I had expected the ECL-to-TTL converter to be equally susceptible to
noise on the +5V rail, but I was happy to find out that I was wrong.

 The Moto ECL-TTL converters, like the 10H125 or the ELT21, were slow
and expensive and had ghastly jitter. The Arizona Microtek part is
better but still pretty bad.

As far as I can remember I used a regular Philips 100K ECL-to-TTL converter, and it obviously didn't have ghastly jitter. I was careful about power rail decoupling, and a ham-fisted half-wit could probably have managed to introduce significant jitter. Ran van Dongen, who had designed the original almost-all-TTL system, was neither ham-fisted nor a half-wit, if a bit less ECL-aware than he should have been. He rather liked what I came up with. I mostly used Motorola ECinPS parts which hadn't been around when he had designed the original system
ECL is a low volume product, so it isn't cheap, but when you need it it is worth the money.

An LVDS line receiver is cheap and hugely better.

But it doesn't produce a TTL output.

Inventing stuff is fun, but nobody sane does it when they don't have to.

 I never claimed to be sane. Sane is boring. I do claim to design and
sell a lot of electronics.

When in fact you evolve and sell a certain amount of electronics for niche markets. Your forays into higher volume markets don't seem to have done well. You are insane enough to think this gives you some kind of authority.
--
Bill Sloman, Sydney