[time-nuts] Linear voltage regulator hints... --> WHY?

[Tim Shoppa]

I grew up in an industry where we called everything that was way
overspec'ed, "platinum-iridium xxx".

I think there is a broad interest in e.g. low-tempco engineering or
low-noise regulators and having some in the pocket designs that start with
jellybean discrete parts and occasional hi-spec parts where they actually
matter, is a great idea.

Tim N3QE

On Fri, Dec 12, 2014 at 8:09 AM, Bob Camp <kb8tq at n1k.org> wrote:
>
>
> > On Dec 12, 2014, at 12:28 AM, Charles Steinmetz <csteinmetz at yandex.com>
> wrote:
> >
> > Bob wrote:
> >
> >> Separate from the analysis of the voltage on the OCXO, there is another
> part to this:
> >> Ok, so why am I harping on the "need" for all this from a system
> standpoint ?
> >
> > We've been around this track a time or two before, me frustrated with
> your "make it just good enough" philosophy and you with my "always do the
> best you can" philosophy.  We're not likely to persuade each other, or even
> influence anybody else, but I think it is worth going around at least one
> more time.
> >
> >> 1) Adding stuff to a design that does not make it measurably better is
> simply a waste of money.
> >
> > Preliminary nit:  I agree that any "improvement" that does not make
> something measurably better is of no value.  Indeed, it is no improvement
> at all.  But you didn't mean literally "not measurably better" -- you meant
> "not better for the task at hand.”
>
> In the case at hand, the task is a GPSDO with a frequency vs temperature
> issue. The issue is coming from the OCXO and not the reference. Improving
> the reference will (in this case) have no impact on the problem.
>
> >  A digital caliper reading to 0.0001" is "measurably better" than a
> ruler graduated in 1/32 inch, although the difference is not important if
> one is measuring the thickness of a 2x4 for framing a house.  But some day
> you may want to measure something besides a 2x4....
> >
> > On to the substance:
> >
> > "Do the best you can" isn't necessarily about adding anything to a
> design.  It's about carefully determining an error budget and developing a
> design that meets the budget.  Of course, you can set the design goals for
> each subsystem so that the overall system should juuuust work if everything
> else is perfect, or so that the system should work under most conditions,
> or so you'll never have to consider whether that subsystem might be
> contributing anything significant to the system errors.  If the latter is
> no more difficult and no more expensive than either of the former, why
> WOULDN'T you design it that way?
>
>
> It is *rare* that an improvement does not impact cost or complexity. It
> most certainly is not the case in this situation.
>
> >  I was taught many years ago that "good thinking doesn't cost any more
> than bad thinking," and I have generally found that to be true.  Meaning,
> it is frequently the case that "the best you can do" is no more difficult
> and no more expensive than doing something less, it just takes better
> thinking and a more accurate analysis.  Whenever that is the case, which
> IME is very often, doing less is, IMO, a design fault.
> >
> > Most often, it's a matter of, "Why ground that capacitor there?  Over
> here would be better," or "Why use a noninverting amplifier?  If you use an
> inverting amplifier, the HF rolloff can continue beyond unity gain," or
> something similar.
> >
> > Note, also, that many of the people asking questions on the list do not
> seem to have a thorough design specification for their project, and may not
> even know what all they will use a gizmo for.  Settling for what a list
> pundit might think is "good enough" for the person's needs (e.g., residual
> phase noise floor ~ -150dB and reverse isolation of ~ 40dB for a buffer
> amplifier) may turn out to be inadequate when the person acquires some
> better oscillators and a DMTD setup and needs -175dB and 90dB.  If they do
> the best they can the first time, they may not have to re-do it later.
>
> But - rather than looking at the system and it’s needs, we spin off to
> “improvements”. Inevitably the result is a -175 db solution to a -145 db
> problem.
>
> >
> >> 2) Others read these threads and decide "maybe I need to do that..".
> >> 3) Still others look at this and decide "If I need to do that, I'm not
> even going to start". That's not good either.
> >
> > Again, neither one is a problem if doing the best one can is no more
> difficult and no more expensive than doing something less.
>
> Except that in the actual example case at hand it very much is more
> expensive and more difficult.
>
> >  If someone has already done the good thinking and suggests a workable
> approach, and all you have to do is a sanity check to implement the idea
> (perhaps even improving on the design), again -- why WOULDN'T you?
>
> That’s not what’s being done here. The example case is not following the
> course you are talking about at all.
>
> > There is always someone handy who is quick to point out all of the other
> ways to do things, so the person contemplating the project can evaluate the
> different approaches for himself.
> >
> > Sometimes, of course, going the next step up the "best you can" ladder
> involves an expensive part (e.g., silicon-on-sapphire semiconductors), or a
> much more complex design, or some use restriction (must be submerged in
> liquid nitrogen).  In that case, one must think very carefully about the
> error budget and determine if that step is really necessary.  But the vast
> majority of the time, we do not face that situation IME.
>
> For a very few people the limit may indeed be liquid helium. There is a
> *much* larger group who are turned off at a far lower cost or complexity
> point.
>
> >
> > The bottom line is:  There is no virtue in doing "just enough,"
> certainly not in the case of amateur projects that will not be manufactured
> in large numbers for slim profit (where every millipence must be saved, if
> the accountants are to be believed -- often, they shouldn't be, but that's
> another topic entirely).  Never apologize for doing better than "just
> enough," as long as doing so does not cause collateral problems.
> >
> > To me, that is the art of design -- knowing that the finished gizmo is
> the best I could make at the time and with the resources available.
> >
> > In philosophy-of-design circles, one sometimes hears that "a race car
> should be designed so that everything is totally spent as it crosses the
> finish line -- the engine should explode, the transmission should break,
> and all four tires should blow out simultaneously.  Anything that is still
> working was, by definition, overdesigned."  Aside from the obvious
> hyperbole, I think the underlying point is plain wrong.  I know I admire
> the designers, whoever they were, when someone pulls a submarine off the
> ocean floor after 70 years and the batteries still have a charge and the
> gauges and radios still work.
> >
> > Finally, one not-so-obvious point about amateur designs.  Sometimes,
> something is a true one-off -- there will never be another made to that
> design.  In that case, some design requirements can be relaxed.  You can
> use trimmer caps or resistors where you would prefer not to in a commercial
> design, for example, and you may use disfavored logic kludges to work
> around timing problems.  But then there are designs that you will publish
> or otherwise share -- and these, I suggest, need to be even more
> bulletproof than commercial designs, since you are not in control of the
> construction, parts choices, etc. that others who follow your lead will
> make.  Yes, you can make disclaimers and suggest where the sensitive bits
> are, but for the design to be truly useful to others, you need to pay
> attention to all that and design as many of the traps out as you possibly
> can -- which can be much harder than designing something to work properly
> when it is made in a factory under your supervision.
>
> The issue is not “do people go overboard”, of course they do. Everybody
> does. Turning that by it’s self into a virtue is a mistake. In 99.99% of
> the real world cases, cost and complexity will go up and reliability will
> thus go down. The result will not be better, it will be worse. The best
> design that achieves the goal is simplest design. That’s every bit as true
> in the basement as it is in volume production.
>
> Your comments do not address the other side of what I’ve been trying to
> convey:
>
> Going overboard with no analysis is *not* a good way to do any of this.
> Even after getting the system specs and design constraints for this
> example, we do not bring that into the discussion. We get into long (and
> very well written) defenses of complexity for it’s own sake. We don’t get
> into analysis. The takeaway to the casual reader is that complexity is the
> goal and that analysis is an un-important part of the process that only
> optional comes into it.  There are a *lot* of people reading the list who
> could execute a simple design. There are far fewer who can properly execute
> a very complex one. The focus on complexity for it’s own sake does have
> impact.
>
> ————————————
>
> Are we really that far apart - not really. We each are talking about two
> sides of the same coin. The real world is a messy place. Analysis often
> takes a back seat to the “fun of doing something”. That’s not to say it
> should though …
>
> Have Fun
>
> Bob
>
>
> >
> > Best regards,
> >
> > Charles
> >
> >
> >
> > _______________________________________________
> > time-nuts mailing list -- time-nuts at febo.com
> > To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> > and follow the instructions there.
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>