On Thu, 19 May 2022 19:12:20 -0400, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

>John Larkin wrote:
>> On Thu, 19 May 2022 17:10:04 -0400, Phil Hobbs
>> <pcdhSpamMeSenseless@electrooptical.net> wrote:
>>
>>> Martin Brown wrote:
>>>> On 19/05/2022 16:14, Jeroen Belleman wrote:
>>>>> On 2022-05-19 17:03, jlarkin@highlandsniptechnology.com wrote:
>>>>>> On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen
>>>>>> <langwadt@fonz.dk> wrote:
>>>>>>
>>>>>>> torsdag den 19. maj 2022 kl. 16.36.23 UTC+2 skrev
>>>>>>> jla...@highlandsniptechnology.com:
>>>>>>>> On Thu, 19 May 2022 12:58:33 -0000 (UTC), Keegan Major
>>>>>>>> <keegan...@hotmail.com> wrote:
>>>>>>>>
>>>>>>>>> Clive Arthur <cl...@nowaytoday.co.uk> wrote:
>>>>>>>>>> On 19/05/2022 04:27, Sylvia Else wrote:
>>>>>>>>>>>
>>>>>>>>>>> Is your channel really that noisy that you cannot just discard bad
>>>>>>>>>>> packets?
>>>>>>>>>>
>>>>>>>>>> I don't have control over the transmission path, it may be noisy, it
>>>>>>>>>> may not - it's not a fixed installation. [snip...] I can't request a
>>>>>>>>>> resend, and sending multiple copies restricts bandwidth too much.
>>>>>>>>>
>>>>>>>>> Hmm, 17 messages in to the thread, and the group finally is told some
>>>>>>>>> of the critical unstated requirements that *should* have been part of
>>>>>>>>> the initial message, and would have avoided about 14 "can't you
>>>>>>>>> resend"
>>>>>>>>> or "can't you send multiple" messages.
>>>>>>>>>
>>>>>>>>> Don't you think this above should have been in your initial post so
>>>>>>>>> that the rest of us, who can't read your mind to divine unstated
>>>>>>>>> limitations, were appraised of some rather critical limitations?
>>>>>>>>>
>>>>>>>>>
>>>>>>>> It's normal here to get underspecified problems. Details usually
>>>>>>>> emerge, but some people do refuse to explain their top-secret
>>>>>>>> projects.
>>>>>>>
>>>>>>> https://xyproblem.info/
>>>>>>
>>>>>> Underspecified problems do encourage lots of lateral/goofy thinking.
>>>>
>>>> Almost all of which is completely wasted. Your proposal of send it three
>>>> times and vote best out of three being amongst them.
>>>>
>>>> There is just about enough space to do what the OP wants but whether or
>>>> not they have the mathematical sophistication and programming skills to
>>>> implement it quickly enough to be useful is still an open question.
>>>>
>>>>>> Of course, some people are hostile to ideas. Their career path is more
>>>>>> McDonalds than electronic design.
>>>>
>>>> You have that *EXACTLY* backwards.
>>>>
>>>> If you cannot adequately describe the exact problem that you are trying
>>>> to solve then you will spend vast amounts of effort solving the wrong
>>>> problem(s) again and again. I have seen it happen many times.
>>>>
>>>>> Goofy ideas aren't really welcome if they upset a sizable fraction
>>>>> of effort already invested. Ideas are cheap. Realizing them is costly.
>>>>> You'll want to be selective.
>>>>
>>>> +1
>>>>
>>>> Half the battle is specifying the problem and any hard constraints so
>>>> that proposed solutions will actually stand a chance of working on the
>>>> available hardware and quickly enough to be useful.
>>>>
>>>
>>> I'm way more in JL's camp, although not 100%. (I do more math than he
>>> does.)
>>
>> Yes, I work more by instinct and simulation. But my world is largely
>> nonlinear, where the math is basically impossible.
>>
>>>
>>> Of course you don't want to take the first thing that comes into your
>>> head and build that--nobody's advocating that here AFAICT. I've seen it
>>> a lot in the wild, though. In fact, one outfit I had to deal with (a CE
>>> in Orange County CA) kept ignoring advice that was backed up with
>>> detailed mathematical analysis and a _working_prototype_ of what they
>>> were supposed to build. (That transcutaneous blood glucose thing again.)
>>>
>>> They just trying things randomly until they ran through the client's
>>> money and then quit. One time when I pinged them about it, a bright lad
>>> smiled and said, "That's engineering!"
>>>
>>> Riiighhhtt.
>>>
>>> But a lot, a lot of people seem to have very little emotional tolerance
>>> for being in a state of uncertainty. I can't prove that, but over and
>>> over I've seen folks spend far too little time turning the problem over
>>> in their minds, talking at the white board, and so on, and just charging
>>> in and doing the first thing that seemed plausible.
>>
>> Yes. Uncertainty makes many people uncomfortable, so they lock down an
>> architecture as soon as they can. I've seen horrors.
>>
>>>
>>> That's super dumb. At the beginning of the process, you have to
>>> cultivate offbeat ideas, because (at least in the sort of gizmos I
>>> build) there's usually some way to do the task much better and/or
>>> cheaper than what's out there.
>>>
>>> In general you should spend something like 10% of the time figuring out
>>> what you should build, and the rest designing and building it. Skimping
>>> on the one very often leads to poor results on the other.
>>
>> Brainstorming and a period of confusion can often greatly simplify the
>> design, or add nifty features. It's well worth the tradeoff.
>>
>> Design is a partly emotional process, which lots of engineers don't
>> want to admit either.
>>
>
>One time long ago, I was in a two-day class for OS/2 Presentation
>Manager programming. (I did say it was long ago.) ;)
>
>At one point, the presenter (who was actually very good) asked us two
>questions: Is design an art or a science? What about debugging?
>
>Just about everyone said that design was a science and debugging was an
>art. That's backwards.
>
>A design is done when the designer says it's done, generally including a
>good long list of checks for performance, DRC, EMI, ROHS, MIL HDBK 217,
>ad nauseam. There are nearly always a ridiculously large number of
>different ways to do the job, if you count all the combinations. That
>makes it an art.
>
>On the other hand, troubleshooting is definitely a science. There's a
>problem someplace, because this item doesn't behave like the N previous
>ones that worked. You find it by applying critical tests and reasoning
>about them, and when the problem is found and fixed, everyone can agree
>that it's gone.
>
>Debugging first articles is a bit of both, because you often find design
>screwups (hopefully minor). In my world that often includes
>layout-dependent stuff such as how high a current can you run through
>your 12 GHz pHEMT or 45-GHz SiGe BJT before it becomes unstable.
>Swapping out jumpers for beads, tweaking current sources, that sort of
>stuff.
>
>In rare instances it's something really stupid such as upside-down power
>supplies on an op amp, but normally the first articles are shippable
>with maybe a roach wire or two.

After some years, we have evolved procedures that mostly prevent
getting V+ and V- swapped on opamps.

>
>We have had the occasional disaster, such as a small module with three
>SMPSes on it to make several rails from a +24V wall wart. The negative
>rails were made by an AOZ1282 async buck running off the output of an
>LMR23630 sync buck (+13 -> -12 and +24 ->+13, respectively).
>
>The A-O part is generally super well behaved, but the two together
>produced a _ridiculous_ selection of high harmonics of the LMR23630's
>2.15 MHz switching frequency. It was the stuff of nightmares--measuring
>one node produced a big peak at 182 MHz, and another one nearby had
>another peak at 121 MHz, selected by various incidental resonances.
>
>With that one, we just cut our losses. ;(
>
>Cheers
>
>Phil Hobbs

We recently had an LTM8078 "Silent Switcher" screaming at us in 400
MHz bursts at 2.5 MHz. The embarassing part was that the customer
discovered it. Oops.

A nice ancient National 50 KHz Simple Switcher fixed that, with a
board spin of course. And gigantic inductors.

https://www.dropbox.com/s/ah90qsi0007ymjv/Mon_Noise_2.jpg?raw=1

https://www.dropbox.com/s/9grk3iqwzifmw6w/Mon_Noise_LTM8078.jpg?raw=1

--

If a man will begin with certainties, he shall end with doubts,
but if he will be content to begin with doubts he shall end in certainties.
Francis Bacon