On Thu, 19 May 2022 20:57:51 +0100, Martin Brown <'''newspam'''@nonad.co.uk> 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.If you have a lot of ideas, one will be the one you use now and the rest are exercizes in thinking, but not wasted. Unless you think that thinking is always painful hence should be minimized. Your proposal of send it three>times and vote best out of three being amongst them.It's not a bad suggestion to a poorly defined problem with, apparently, limited logic resources.> >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.Well, I don't hire (or keep) people who are hostile to ideas. Maybe you prefer them.> >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.You have that *EXACTLY* backwards. A reasonable period of confusion and reconsideration is greatly beneficial to design. Wedge-heads hate uncertainty so latch on to the first, usually textbook conventional, architecture they can find, and implement klunkiness. 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.Half the value is inventing something original that the competitors haven't already made unprofitable. No, 5x the value. Good engineers routinely implement a specified idea with constraints, first pass if they are really good. Implementing dumb ideas is, well, dumb. -- 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
Error correction in short packet.
Started by ●May 18, 2022
Reply by ●May 19, 20222022-05-19
Reply by ●May 19, 20222022-05-19
On Thu, 19 May 2022 12:24:46 -0700 (PDT), whit3rd <whit3rd@gmail.com> wrote:>On Thursday, May 19, 2022 at 8:03:55 AM UTC-7, jla...@highlandsniptechnology.com wrote: >> On Thu, 19 May 2022 07:40:45 -0700 (PDT), Lasse Langwadt Christensen >> <lang...@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 > >> Of course, some people are hostile to ideas. Their career path is more >> McDonalds than electronic design. > >Again with the goofy personality theories! Everyone is hostile to ideas >for a few minutes in the evening, when it's time to sleep.Really? I never noticed that.> >That's normal, and has nothing to do with a career path. > >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. -- 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 19, 20222022-05-19
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.) 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. 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. 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 19, 20222022-05-19
On 5/19/2022 12:57 PM, Martin Brown wrote:>>> 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.The problem is that folks don't want to answer the question posed. They all seem to think the person posing it doesn't understand HIS OWN PROBLEM SPACE and must rely on *them* to explore it on his behalf. Or, they are incredibly under-challenged in their own work and rely on others for mental stimulation. Assume the person is competent as an engineer, but may lack "experience" in a technology that he has an inkling MAY help him with his problem. No one bothered to ask the NATURE of the 14 byte messages! Maybe the OP is a total idiot and has been sending "DATUM_RECEIVED" and encountering DATuM_RECEIVED (1 bit error) DBTUM_RECEIVED (2 bit error) Maybe there is no "NOT RECEIVED" message and that condition is indicated by the *absence* of a message in a particular timeframe. etc. Not very likely, so why bother to inquire? Yet, there may be changes that *could* be made to the message content (or frequency) that would benefit the OP. Shouldn't the OP be asked to provide further details, there? (rolls eyes) Or, maybe suggest a different transmission medium! Or... Ans: Assume the OP has the skillset (or constraints) to know what he can/can't get away with in his application. And, is EXPLORING the idea of using an ECC to reduce his susceptibility to errors corrupting the transmission. "Valid" (IMO) comments and questions would then pertain to *qualifying* any solution you might want to suggest. E.g., "What is the nature of the noise source". Or, indicating some minimum set of requirements that must be met for your suggestion (or the OPs query) to be feasible. E.g., had the OP only had room for a single byte addition to the message, then correcting two errors is not possible WITHIN THAT SINGLE MESSAGE FRAME (because you can only indicate 2^8 "conditions" with a single additional byte and there are 1+112+(112*111)/2 possible "conditions" in which a message can be received with 2 or fewer errors (assuming exactly 112 bits are actually received -- what if he only gets 110? Or, 104?) OTOH, a 2-byte ECC can easily cover that number so *suggests* a code MAY exist (whether or not it is practical to the OP is a different issue). The exact distribution of errors (and how errors manifest) *in* the data stream is then the important issue.>>> 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.But the OP has specified a SPECIFIC problem. Whether that will solve HIS "greater" problem is, presumably, something that HE can sort out. Or, can pose additional queries to gather the information he needs to make that resolution. Why do folks think they need to know the whole problem in order to contribute to a specific request? Gotta wonder what life was like for these people growing up: "Mary has 6 apples. She gives two to Francine. How many apples does Mary now have?" "Why apples and not bananas? Why only two? Why not split them evenly? Why Francine? What about Bruce, Francine's brother? And, are you sure Francine can eat apples? Or, that she actually wants them? Maybe she'd rather have that nice pink ribbon that Mary is wearing in her hair? Are you sure the apples are ripe? I thought Mary and Francine weren't on speaking terms after that incident in the playground..." <rolls eyes> Must be dreadful engineers.>> 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.Competence usually weeds out "goofy" ideas. Only fools would entertain them (and, they'd only "entertain" them "for ENTERTAINMENT value". And, you wouldn't want to employ folks who can't sort these ideas out before passing from grey matter to vocal tract! An idea that is outside the box isn't goofy, it's just unconventional. THOSE ideas can cause people to think in different directions towards a *possibly* practical solution. But, goofy is just plain goofy.
Reply by ●May 19, 20222022-05-19
On Thu, 19 May 2022 14:58:41 -0700, Don Y <blockedofcourse@foo.invalid> wrote:>On 5/19/2022 12:57 PM, Martin Brown wrote: >>>> 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. > >The problem is that folks don't want to answer the question posed. They >all seem to think the person posing it doesn't understand HIS OWN PROBLEM >SPACE and must rely on *them* to explore it on his behalf.My customers often don't know what they actually need... but they think they do.> >Or, they are incredibly under-challenged in their own work and rely on >others for mental stimulation.Sometimes customers don't know what electronics and signal processing can do for them.> >Assume the person is competent as an engineer, but may lack "experience" >in a technology that he has an inkling MAY help him with his problem.Sometimes experience is the worst teacher.> >No one bothered to ask the NATURE of the 14 byte messages! Maybe the OP >is a total idiot and has been sending "DATUM_RECEIVED" and encountering > DATuM_RECEIVED (1 bit error) > DBTUM_RECEIVED (2 bit error) >Maybe there is no "NOT RECEIVED" message and that condition is indicated >by the *absence* of a message in a particular timeframe. etc. > >Not very likely, so why bother to inquire? Yet, there may be changes >that *could* be made to the message content (or frequency) that would >benefit the OP. Shouldn't the OP be asked to provide further details, >there? (rolls eyes) > >Or, maybe suggest a different transmission medium! > >Or... > >Ans: Assume the OP has the skillset (or constraints) to know what he >can/can't get away with in his application. And, is EXPLORING the idea >of using an ECC to reduce his susceptibility to errors corrupting the >transmission. > >"Valid" (IMO) comments and questions would then pertain to *qualifying* >any solution you might want to suggest. E.g., "What is the nature of >the noise source". Or, indicating some minimum set of requirements >that must be met for your suggestion (or the OPs query) to be feasible. > >E.g., had the OP only had room for a single byte addition to the >message, then correcting two errors is not possible WITHIN THAT >SINGLE MESSAGE FRAME (because you can only indicate 2^8 "conditions" >with a single additional byte and there are 1+112+(112*111)/2 possible >"conditions" in which a message can be received with 2 or fewer errors >(assuming exactly 112 bits are actually received -- what if he only gets >110? Or, 104?) > >OTOH, a 2-byte ECC can easily cover that number so *suggests* a code MAY >exist (whether or not it is practical to the OP is a different issue). > >The exact distribution of errors (and how errors manifest) *in* the >data stream is then the important issue. > >>>> 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. > >But the OP has specified a SPECIFIC problem. Whether that will solve HIS >"greater" problem is, presumably, something that HE can sort out. > >Or, can pose additional queries to gather the information he needs to >make that resolution. > >Why do folks think they need to know the whole problem in order to >contribute to a specific request? Gotta wonder what life was like >for these people growing up: > >"Mary has 6 apples. She gives two to Francine. How many apples does >Mary now have?" > >"Why apples and not bananas? Why only two? Why not split them >evenly? Why Francine? What about Bruce, Francine's brother? And, >are you sure Francine can eat apples? Or, that she actually wants >them? Maybe she'd rather have that nice pink ribbon that Mary is >wearing in her hair? Are you sure the apples are ripe? I thought >Mary and Francine weren't on speaking terms after that incident in >the playground..." > ><rolls eyes> > >Must be dreadful engineers. > >>> 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. > >Competence usually weeds out "goofy" ideas. Only fools would entertain >them (and, they'd only "entertain" them "for ENTERTAINMENT value". And, >you wouldn't want to employ folks who can't sort these ideas out before >passing from grey matter to vocal tract!All wrong. I prefer to employ people who don't censor themselves, who aren't afraid of possibilities.> >An idea that is outside the box isn't goofy, it's just unconventional. >THOSE ideas can cause people to think in different directions towards >a *possibly* practical solution. > >But, goofy is just plain goofy.One of the guidelines to good brainstorming is to not separate serious from goofy from outright jokes. It works. The solution space is huge, and good ideas might be hiding behind silly ones. -- 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 19, 20222022-05-19
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. 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 -- 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 19, 20222022-05-19
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 HobbsWe 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
Reply by ●May 19, 20222022-05-19
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 -- 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 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.
Reply by ●May 20, 20222022-05-20
On 2022-05-18, Clive Arthur <clive@nowaytoday.co.uk> wrote:> Hi all > > I have serial data in 14 byte packets on which I'd like to detect and > correct errors. Two bit errors would be nice. I can put 2 extra EDC > bytes on the end to make a 16 byte packet. > > I don't have the resources for Reed-Solomon. I could use a 16 bit CRC, > these are easy to generate with a small/moderate LUT. > > In the past, I've used a CRC16 for single bit error detection and > correction on a longer packet, but I didn't do the error detection part. > Errors were very rare, time was not critical, and I understand that > this was simply done by changing each message bit in turn then > recalculating the CRC till it all worked out. That's far to slow for my > current needs. > > If I'm lucky, a 16 bit CRC might be able to detect and correct 2 bit > errors in 14 bytes (112 * 111 possibilities?), but is there a way of > quickly finding out which bits are wrong?a look-up table. how much resources do you have? -- Jasen.
