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 <kb...@n1k.org> wrote: > > > > On Dec 12, 2014, at 12:28 AM, Charles Steinmetz <csteinm...@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@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@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.