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

Fri Dec 12 09:20:45 EST 2014

Hi

> On Dec 12, 2014, at 8:52 AM, Tim Shoppa <tshoppa at gmail.com> wrote:
> 
> 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.

Which is the reason I split this part of it off from the main thread. There are most certainly reasons why you would use low noise / low temp chef. / low aging references. Digging into that is not a bad thing and I’m in no way knocking that part of it. 

Bob

> 
> 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.
>> 
> _______________________________________________
> 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.