Hi
> On Dec 12, 2014, at 8:52 AM, Tim Shoppa <tsho...@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 <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. _______________________________________________ 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.