fredag den 20. maj 2022 kl. 18.46.50 UTC+2 skrev jla...@highlandsniptechnology.com:> On Fri, 20 May 2022 12:11:23 -0400, Phil Hobbs > <pcdhSpamM...@electrooptical.net> wrote: > > >whit3rd wrote: > >> On Thursday, May 19, 2022 at 1:59:08 PM UTC-7, John Larkin wrote: > >>> On Thu, 19 May 2022 12:24:46 -0700 (PDT), whit3rd <whi...@gmail.com> > >>> wrote: > >>>> On Thursday, May 19, 2022 at 8:03:55 AM UTC-7, jla...@highlandsniptechnology.com wrote: > >> > >> > >>>>> Of course, some people are hostile to ideas. > >> > >>>> No sane conscious mind is 'hostile to ideas' in any more general sense; that > >>>> would be pathological, like being hostile to one's own body parts. > >> > >>> Oh, lots of people are reflexively hostile to new or unconventional > >>> ideas. Those personalities poison brainstorming sessions. > >> > >> For those of us who haven't experienced poisoned brainstorming sessions, > >> describe the 'hostility'. I have grey hair, but cannot recall ever meeting > >> someone who was 'hostile to ideas' in general. > >> > > > >You've lived a sheltered life. Back in my early days at IBM Research, I > >was in the Manufacturing Research department. It was pretty much a > >gizmo-builder's paradise--an apparently endless series of hard, > >interesting, and economically important problems that needed custom > >instruments to solve, pleasant and very smart colleagues, smart and > >patient management, and very few budget constraints. A pal of mine from > >back then, the estimable Clayton Williams (now flourishing at BYU) > >needed a new lock-in amplifier. He was thinking out loud one day, "It's > >stupid to buy just one. I probably don't need five, so let's order > >two." Two shiny new lock-ins arrived in a few days. If he had needed > >five, five would have come instead. > > > >We were entirely self-governed--our budget came out of a big pot at > >Corporate, so the folks we were nominally serving couldn't really tell > >us what to do. Not that doing stuff randomly was encouraged, you > >understand, but we didn't have the product divisions cracking any whips > >that we had to care about. As I said, a great place to build gizmos. > > > >While the customers couldn't tell us what to do, there was a certain > >contingent of folks who seemed to resent this--apparently they were > >happier being able to make vendors dance to their tune. Thus they chose > >to throw rocks and tell the folks trying to do stuff that it would never > >work, that progress was unacceptable, that the instrument concept was > >all wrong, and so on and so forth. Those folks, you absolutely had to > >keep out of the planning stage of the project, or they'd trash you to > >their management and often succeed in killing the effort. > > > >There were also folks who wanted to swoop in once the project was on > >rails and steal the credit. There was even a select demographic that > >habitually did both. > > > >When IBM had its near-death experience in 1992, all those folks were > >gone, which was great, but so of course were the lush budgets, which > >wasn't that great. My time at IBM was like the perfect 21-year > >vacation--I was excited to start and excited to leave (as well as scared). > > > >Cheers > > > >Phil Hobbs > It's interesting that none of the giant tube companies were long-term > successful in semiconductors. Garage shops killed GE, RCA, Motorola, > Sylvania, and many others.the semiconductor division of Motorola became ON semiconductor in 1999, they are still a 30000 employee company ...
Error correction in short packet.
Started by ●May 18, 2022
Reply by ●May 20, 20222022-05-20
Reply by ●May 20, 20222022-05-20
On Thu, 19 May 2022 22:01:59 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:>John Larkin wrote: >> 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. ;( >>> > >> 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 >> >I've had good luck with the 150 kHz ones too, with Schottky catch diodes >to prevent current spikes from PN diode recovery. They do tend to need >chunky inductors to handle all those voltseconds. > >Cheers > >Phil HobbsWhen people make mosfet substrate diodes, they tend to make them step-recovery diodes. There must be some semi fab reason for that. Adding an external schottky catch diode to a spikey synchronous switcher doesn't seem to help. This is textbook: https://www.dropbox.com/s/jfqojg9pvrlz7xu/SwitcherRise.JPG?raw=1 Bottom fet turns off, reverse conducts, and then snaps. -- 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
Reply by ●May 20, 20222022-05-20
John Larkin wrote:> On Thu, 19 May 2022 22:01:59 -0400, Phil Hobbs > <pcdhSpamMeSenseless@electrooptical.net> wrote: > >> John Larkin wrote: >>> 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. ;( >>>> >> >>> 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 >>> >> I've had good luck with the 150 kHz ones too, with Schottky catch diodes >> to prevent current spikes from PN diode recovery. They do tend to need >> chunky inductors to handle all those voltseconds. >> >> Cheers >> >> Phil Hobbs > > When people make mosfet substrate diodes, they tend to make them > step-recovery diodes. There must be some semi fab reason for that. > > Adding an external schottky catch diode to a spikey synchronous > switcher doesn't seem to help.The extra 5 nH in series with it isn't a bad RF choke when you've got subpicosecond edges. It might be interesting to try a small amount of inductance in the ground lead (returning all the voltage dividers and sync pins and so on to that point so as not to dump spikies into the chip). With the output reservoir cap and catch diode returned to real ground, one might be able to give the diode time to work.> > This is textbook: > > https://www.dropbox.com/s/jfqojg9pvrlz7xu/SwitcherRise.JPG?raw=1 > > Bottom fet turns off, reverse conducts, and then snaps.Yeah, the LMR23630 has, like, 600 ps edges. It didn't cause problems until I ran the +13 -> -12 inverting buck off its output. (Going straight from +24 to -12 is asking a lot of a cute little SOT23 integrated buck switcher.) Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
Reply by ●May 20, 20222022-05-20
On Fri, 20 May 2022 11:41:10 -0700 (PDT), Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:>fredag den 20. maj 2022 kl. 18.46.50 UTC+2 skrev jla...@highlandsniptechnology.com: >> On Fri, 20 May 2022 12:11:23 -0400, Phil Hobbs >> <pcdhSpamM...@electrooptical.net> wrote: >> >> >whit3rd wrote: >> >> On Thursday, May 19, 2022 at 1:59:08 PM UTC-7, John Larkin wrote: >> >>> On Thu, 19 May 2022 12:24:46 -0700 (PDT), whit3rd <whi...@gmail.com> >> >>> wrote: >> >>>> On Thursday, May 19, 2022 at 8:03:55 AM UTC-7, jla...@highlandsniptechnology.com wrote: >> >> >> >> >> >>>>> Of course, some people are hostile to ideas. >> >> >> >>>> No sane conscious mind is 'hostile to ideas' in any more general sense; that >> >>>> would be pathological, like being hostile to one's own body parts. >> >> >> >>> Oh, lots of people are reflexively hostile to new or unconventional >> >>> ideas. Those personalities poison brainstorming sessions. >> >> >> >> For those of us who haven't experienced poisoned brainstorming sessions, >> >> describe the 'hostility'. I have grey hair, but cannot recall ever meeting >> >> someone who was 'hostile to ideas' in general. >> >> >> > >> >You've lived a sheltered life. Back in my early days at IBM Research, I >> >was in the Manufacturing Research department. It was pretty much a >> >gizmo-builder's paradise--an apparently endless series of hard, >> >interesting, and economically important problems that needed custom >> >instruments to solve, pleasant and very smart colleagues, smart and >> >patient management, and very few budget constraints. A pal of mine from >> >back then, the estimable Clayton Williams (now flourishing at BYU) >> >needed a new lock-in amplifier. He was thinking out loud one day, "It's >> >stupid to buy just one. I probably don't need five, so let's order >> >two." Two shiny new lock-ins arrived in a few days. If he had needed >> >five, five would have come instead. >> > >> >We were entirely self-governed--our budget came out of a big pot at >> >Corporate, so the folks we were nominally serving couldn't really tell >> >us what to do. Not that doing stuff randomly was encouraged, you >> >understand, but we didn't have the product divisions cracking any whips >> >that we had to care about. As I said, a great place to build gizmos. >> > >> >While the customers couldn't tell us what to do, there was a certain >> >contingent of folks who seemed to resent this--apparently they were >> >happier being able to make vendors dance to their tune. Thus they chose >> >to throw rocks and tell the folks trying to do stuff that it would never >> >work, that progress was unacceptable, that the instrument concept was >> >all wrong, and so on and so forth. Those folks, you absolutely had to >> >keep out of the planning stage of the project, or they'd trash you to >> >their management and often succeed in killing the effort. >> > >> >There were also folks who wanted to swoop in once the project was on >> >rails and steal the credit. There was even a select demographic that >> >habitually did both. >> > >> >When IBM had its near-death experience in 1992, all those folks were >> >gone, which was great, but so of course were the lush budgets, which >> >wasn't that great. My time at IBM was like the perfect 21-year >> >vacation--I was excited to start and excited to leave (as well as scared). >> > >> >Cheers >> > >> >Phil Hobbs >> It's interesting that none of the giant tube companies were long-term >> successful in semiconductors. Garage shops killed GE, RCA, Motorola, >> Sylvania, and many others. > >the semiconductor division of Motorola became ON semiconductor in 1999, they are still a 30000 employee company ...Sort of like HP spinning off Agilent spinning off Keysight. Management couldn't keep too many things in their heads at once. -- Anybody can count to one. - Robert Widlar
Reply by ●May 20, 20222022-05-20
On Fri, 20 May 2022 10:58:45 -0700 (PDT), whit3rd <whit3rd@gmail.com> wrote:>On Friday, May 20, 2022 at 7:28:54 AM UTC-7, jla...@highlandsniptechnology.com wrote: >> On Thu, 19 May 2022 20:38:24 -0700 (PDT), whit3rd <whi...@gmail.com> >> wrote: >> >> >On Thursday, May 19, 2022 at 1:59:08 PM UTC-7, John Larkin wrote: > >> >> Oh, lots of people are reflexively hostile to new or unconventional >> >> ideas. Those personalities poison brainstorming sessions. >> > >> >For those of us who haven't experienced poisoned brainstorming sessions, >> >describe the 'hostility'. > >> Some people, especially ones with grey hair, immediately find fault >> with ideas instead of riffing on them. That intimidates some >> contributors, especially young ones. Sometimes they have sufficient >> gravity that they kill a promising discussion. > >Swift fault analysis isn't hostility, it is effective argument.It is hostility and it kills ideas in their infancy. "Argument" says it all. Right and wrong is a zero-sum game, or usually less than zero. -- Anybody can count to one. - Robert Widlar
Reply by ●May 21, 20222022-05-21
On Friday, May 20, 2022 at 6:14:08 PM UTC-7, jla...@highlandsniptechnology.com wrote:> On Fri, 20 May 2022 10:58:45 -0700 (PDT), whit3rd <whi...@gmail.com> > wrote: > > >On Friday, May 20, 2022 at 7:28:54 AM UTC-7, jla...@highlandsniptechnology.com wrote:> >> Some people, especially ones with grey hair, immediately find fault > >> with ideas instead of riffing on them. That intimidates some > >> contributors, especially young ones. Sometimes they have sufficient > >> gravity that they kill a promising discussion.> >Swift fault analysis isn't hostility, it is effective argument.> It is hostility and it kills ideas in their infancy. "Argument" says > it all. Right and wrong is a zero-sum game, or usually less than zero.No, the term for a negative-sum argument is 'sophistry'. Sophistries are not valid arguments. Valid arguments are VALUABLE contributions. Some folk are timid, will prefer small incremental changes (that's a good strategy against uncerainty). Some folk are conservative, will reject novel, untried approaches (that's useful if you have a time or material budget). Some folk are insightful, will foresee an awkward or impossible step in advance. So, an immediate finding of fault can have lots of causes, none of which are 'hostile to ideas' in nature. And, occasionally (Boeing's 737Max comes to mind) a NO is the right design answer; why delay putting it on the table?
Reply by ●May 21, 20222022-05-21
On Friday, May 20, 2022 at 8:17:35 PM UTC-7, whit3rd wrote:> On Friday, May 20, 2022 at 6:14:08 PM UTC-7, jla...@highlandsniptechnology.com wrote: > > On Fri, 20 May 2022 10:58:45 -0700 (PDT), whit3rd <whi...@gmail.com> > > wrote: > > > > >On Friday, May 20, 2022 at 7:28:54 AM UTC-7, jla...@highlandsniptechnology.com wrote: > > > >> Some people, especially ones with grey hair, immediately find fault > > >> with ideas instead of riffing on them. That intimidates some > > >> contributors, especially young ones. Sometimes they have sufficient > > >> gravity that they kill a promising discussion. > > > >Swift fault analysis isn't hostility, it is effective argument. > > > It is hostility and it kills ideas in their infancy. "Argument" says > > it all. Right and wrong is a zero-sum game, or usually less than zero. > No, the term for a negative-sum argument is 'sophistry'. > Sophistries are not valid arguments. > Valid arguments are VALUABLE contributions. > > Some folk are timid, will prefer small incremental changes (that's > a good strategy against uncerainty). > > Some folk are conservative, will reject novel, untried approaches (that's > useful if you have a time or material budget). > > Some folk are insightful, will foresee an awkward or impossible step > in advance. > > So, an immediate finding of fault can have lots of causes, none of which > are 'hostile to ideas' in nature. And, occasionally (Boeing's 737Max comes to mind) > a NO is the right design answer; why delay putting it on the table?I vote for Golay codes. Here is a short writeup: https://en.wikipedia.org/wiki/Binary_Golay_code
Reply by ●May 21, 20222022-05-21
On Friday, May 20, 2022 at 9:01:12 PM UTC-7, Flyguy wrote:> On Friday, May 20, 2022 at 8:17:35 PM UTC-7, whit3rd wrote: > > On Friday, May 20, 2022 at 6:14:08 PM UTC-7, jla...@highlandsniptechnology.com wrote: > > > On Fri, 20 May 2022 10:58:45 -0700 (PDT), whit3rd <whi...@gmail.com> > > > wrote: > > > > > > >On Friday, May 20, 2022 at 7:28:54 AM UTC-7, jla...@highlandsniptechnology.com wrote: > > > > > >> Some people, especially ones with grey hair, immediately find fault > > > >> with ideas instead of riffing on them. That intimidates some > > > >> contributors, especially young ones. Sometimes they have sufficient > > > >> gravity that they kill a promising discussion. > > > > > >Swift fault analysis isn't hostility, it is effective argument. > > > > > It is hostility and it kills ideas in their infancy. "Argument" says > > > it all. Right and wrong is a zero-sum game, or usually less than zero. > > No, the term for a negative-sum argument is 'sophistry'. > > Sophistries are not valid arguments. > > Valid arguments are VALUABLE contributions. > > > > Some folk are timid, will prefer small incremental changes (that's > > a good strategy against uncerainty). > > > > Some folk are conservative, will reject novel, untried approaches (that's > > useful if you have a time or material budget). > > > > Some folk are insightful, will foresee an awkward or impossible step > > in advance. > > > > So, an immediate finding of fault can have lots of causes, none of which > > are 'hostile to ideas' in nature. And, occasionally (Boeing's 737Max comes to mind) > > a NO is the right design answer; why delay putting it on the table? > I vote for Golay codes. Here is a short writeup: > https://en.wikipedia.org/wiki/Binary_Golay_codeAnd here is the actual code to implement it: https://github.com/pkdoshinji/Golay/blob/master/Golay.py
Reply by ●May 21, 20222022-05-21
jlarkin@highlandsniptechnology.com wrote:> On Fri, 20 May 2022 11:41:10 -0700 (PDT), Lasse Langwadt Christensen > <langwadt@fonz.dk> wrote: > >> fredag den 20. maj 2022 kl. 18.46.50 UTC+2 skrev jla...@highlandsniptechnology.com: >>> On Fri, 20 May 2022 12:11:23 -0400, Phil Hobbs >>> <pcdhSpamM...@electrooptical.net> wrote: >>> >>>> whit3rd wrote: >>>>> On Thursday, May 19, 2022 at 1:59:08 PM UTC-7, John Larkin wrote: >>>>>> On Thu, 19 May 2022 12:24:46 -0700 (PDT), whit3rd <whi...@gmail.com> >>>>>> wrote: >>>>>>> On Thursday, May 19, 2022 at 8:03:55 AM UTC-7, jla...@highlandsniptechnology.com wrote: >>>>> >>>>> >>>>>>>> Of course, some people are hostile to ideas. >>>>> >>>>>>> No sane conscious mind is 'hostile to ideas' in any more general sense; that >>>>>>> would be pathological, like being hostile to one's own body parts. >>>>> >>>>>> Oh, lots of people are reflexively hostile to new or unconventional >>>>>> ideas. Those personalities poison brainstorming sessions. >>>>> >>>>> For those of us who haven't experienced poisoned brainstorming sessions, >>>>> describe the 'hostility'. I have grey hair, but cannot recall ever meeting >>>>> someone who was 'hostile to ideas' in general. >>>>> >>>> >>>> You've lived a sheltered life. Back in my early days at IBM Research, I >>>> was in the Manufacturing Research department. It was pretty much a >>>> gizmo-builder's paradise--an apparently endless series of hard, >>>> interesting, and economically important problems that needed custom >>>> instruments to solve, pleasant and very smart colleagues, smart and >>>> patient management, and very few budget constraints. A pal of mine from >>>> back then, the estimable Clayton Williams (now flourishing at BYU) >>>> needed a new lock-in amplifier. He was thinking out loud one day, "It's >>>> stupid to buy just one. I probably don't need five, so let's order >>>> two." Two shiny new lock-ins arrived in a few days. If he had needed >>>> five, five would have come instead. >>>> >>>> We were entirely self-governed--our budget came out of a big pot at >>>> Corporate, so the folks we were nominally serving couldn't really tell >>>> us what to do. Not that doing stuff randomly was encouraged, you >>>> understand, but we didn't have the product divisions cracking any whips >>>> that we had to care about. As I said, a great place to build gizmos. >>>> >>>> While the customers couldn't tell us what to do, there was a certain >>>> contingent of folks who seemed to resent this--apparently they were >>>> happier being able to make vendors dance to their tune. Thus they chose >>>> to throw rocks and tell the folks trying to do stuff that it would never >>>> work, that progress was unacceptable, that the instrument concept was >>>> all wrong, and so on and so forth. Those folks, you absolutely had to >>>> keep out of the planning stage of the project, or they'd trash you to >>>> their management and often succeed in killing the effort. >>>> >>>> There were also folks who wanted to swoop in once the project was on >>>> rails and steal the credit. There was even a select demographic that >>>> habitually did both. >>>> >>>> When IBM had its near-death experience in 1992, all those folks were >>>> gone, which was great, but so of course were the lush budgets, which >>>> wasn't that great. My time at IBM was like the perfect 21-year >>>> vacation--I was excited to start and excited to leave (as well as scared). >>>> >>>> Cheers >>>> >>>> Phil Hobbs >>> It's interesting that none of the giant tube companies were long-term >>> successful in semiconductors. Garage shops killed GE, RCA, Motorola, >>> Sylvania, and many others. >> >> the semiconductor division of Motorola became ON semiconductor in 1999, they are still a 30000 employee company ... > > Sort of like HP spinning off Agilent spinning off Keysight. Management > couldn't keep too many things in their heads at once. > > >That's the classical problem with conglomerates. Cheers Phil Hobbs
Reply by ●May 22, 20222022-05-22
jlarkin@highlandsniptechnology.com wrote:> On Fri, 20 May 2022 10:58:45 -0700 (PDT), whit3rd <whit3rd@gmail.com> > wrote: > >> On Friday, May 20, 2022 at 7:28:54 AM UTC-7, jla...@highlandsniptechnology.com wrote: >>> On Thu, 19 May 2022 20:38:24 -0700 (PDT), whit3rd <whi...@gmail.com> >>> wrote: >>> >>>> On Thursday, May 19, 2022 at 1:59:08 PM UTC-7, John Larkin wrote: >> >>>>> Oh, lots of people are reflexively hostile to new or unconventional >>>>> ideas. Those personalities poison brainstorming sessions. >>>> >>>> For those of us who haven't experienced poisoned brainstorming sessions, >>>> describe the 'hostility'. >> >>> Some people, especially ones with grey hair, immediately find fault >>> with ideas instead of riffing on them. That intimidates some >>> contributors, especially young ones. Sometimes they have sufficient >>> gravity that they kill a promising discussion. >> >> Swift fault analysis isn't hostility, it is effective argument. > > It is hostility and it kills ideas in their infancy. "Argument" says > it all. Right and wrong is a zero-sum game, or usually less than zero.There's a bit of a semantic thicket here. I don't expect to agree with w3 about much of anything, but here's a possibly-useful point: unfortunately, popular discourse has lost the distinction between an argument and a quarrel. Properly speaking, an argument is a connected line of reasoning, by intention valid, that attempts to establish some proposition. It has to be able to withstand challenges to its validity and its premises, delivered without animosity. Arguing in that sense is great fun and leads to improved understanding on everybody's part--maybe you get convinced, or maybe you don't, but in any case it challenges you to clarify your ideas and articulate them better. It's a win either way, and oh, by the way, it's terrific fun when done well. Quarrelling, on the other hand, is a lose--it convinces no one, it isn't fun, it hardens attitudes, and it leaves bad feelings. W3 overlooks the key idea-generating process ahead of the rational arguments, but the eventual winnowing-out process does need to occur at some point. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
