Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

System going down in 5 minutes.


tech / sci.electronics.design / Re: Error correction in short packet.

SubjectAuthor
* Error correction in short packet.Clive Arthur
+* Re: Error correction in short packet.jlarkin
|+* Re: Error correction in short packet.Lasse Langwadt Christensen
||+* Re: Error correction in short packet.John Walliker
|||+* Re: Error correction in short packet.John Larkin
||||`- Re: Error correction in short packet.whit3rd
|||`- Re: Error correction in short packet.Gerhard Hoffmann
||`- Re: Error correction in short packet.Martin Brown
|`* Re: Error correction in short packet.David Eather
| `* Re: Error correction in short packet.John Larkin
|  +* Re: Error correction in short packet.Martin Brown
|  |+* Re: Error correction in short packet.Clive Arthur
|  ||`- Re: Error correction in short packet.Martin Brown
|  |`- Re: Error correction in short packet.Don Y
|  `* Re: Error correction in short packet.David Eather
|   `* Re: Error correction in short packet.John S
|    `- Re: Error correction in short packet.David Eather
+* Re:Error correction in short packet.Martin Rid
|`- Re: Error correction in short packet.Clive Arthur
+- Re: Error correction in short packet.Don Y
+* Re: Error correction in short packet.Sylvia Else
|`* Re: Error correction in short packet.Clive Arthur
| +- Re: Error correction in short packet.Martin Brown
| `* Re: Error correction in short packet.Keegan Major
|  +* Re: Error correction in short packet.jlarkin
|  |`* Re: Error correction in short packet.Lasse Langwadt Christensen
|  | `* Re: Error correction in short packet.jlarkin
|  |  +* Re: Error correction in short packet.Jeroen Belleman
|  |  |+* Re: Error correction in short packet.jlarkin
|  |  ||+- Re: Error correction in short packet.Phil Hobbs
|  |  ||`- Re: Error correction in short packet.Jeroen Belleman
|  |  |`* Re: Error correction in short packet.Martin Brown
|  |  | +- Re: Error correction in short packet.John Larkin
|  |  | +* Re: Error correction in short packet.Phil Hobbs
|  |  | |+* Re: Error correction in short packet.John Larkin
|  |  | ||+* Re: Error correction in short packet.Phil Hobbs
|  |  | |||`* Re: Error correction in short packet.John Larkin
|  |  | ||| `* Re: Error correction in short packet.Phil Hobbs
|  |  | |||  `* Re: Error correction in short packet.John Larkin
|  |  | |||   `- Re: Error correction in short packet.Phil Hobbs
|  |  | ||`* Re: Error correction in short packet.whit3rd
|  |  | || `- Re: Error correction in short packet.Martin Brown
|  |  | |`- Re: Error correction in short packet.marty
|  |  | `* Re: Error correction in short packet.Don Y
|  |  |  `- Re: Error correction in short packet.John Larkin
|  |  `* Re: Error correction in short packet.whit3rd
|  |   +* Re: Error correction in short packet.John Larkin
|  |   |`* Re: Error correction in short packet.whit3rd
|  |   | +* Re: Error correction in short packet.jlarkin
|  |   | |`* Re: Error correction in short packet.whit3rd
|  |   | | `* Re: Error correction in short packet.jlarkin
|  |   | |  +* Re: Error correction in short packet.whit3rd
|  |   | |  |`* Re: Error correction in short packet.Flyguy
|  |   | |  | `- Re: Error correction in short packet.Flyguy
|  |   | |  `* Re: Error correction in short packet.Phil Hobbs
|  |   | |   `* Re: Error correction in short packet.jlarkin
|  |   | |    `- Re: Error correction in short packet.whit3rd
|  |   | `* Re: Error correction in short packet.Phil Hobbs
|  |   |  `* Re: Error correction in short packet.jlarkin
|  |   |   `* Re: Error correction in short packet.Lasse Langwadt Christensen
|  |   |    `* Re: Error correction in short packet.jlarkin
|  |   |     `- Re: Error correction in short packet.Phil Hobbs
|  |   `* Re: Error correction in short packet.Don Y
|  |    `* Re: Error correction in short packet.jlarkin
|  |     `* Re: Error correction in short packet.boB
|  |      `* Re: Error correction in short packet.jlarkin
|  |       `* Re: Error correction in short packet.boB
|  |        `- Re: Error correction in short packet.jlarkin
|  `- Re: Error correction in short packet.Cydrome Leader
+* Re: Error correction in short packet.Jasen Betts
|`* Re: Error correction in short packet.Jasen Betts
| `- Re: Error correction in short packet.Clive Arthur
`- Re: Error correction in short packet.David Eather

Pages:123
Re: Error correction in short packet.

<fnnc8hdplj84j2d7n1o5mioif6i0m2cc9v@4ax.com>

 copy mid

https://www.novabbs.com/tech/article-flat.php?id=97160&group=sci.electronics.design#97160

 copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!nntp.supernews.com!news.supernews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 19 May 2022 10:17:15 -0500
From: jlar...@highlandsniptechnology.com
Newsgroups: sci.electronics.design
Subject: Re: Error correction in short packet.
Date: Thu, 19 May 2022 08:17:18 -0700
Message-ID: <fnnc8hdplj84j2d7n1o5mioif6i0m2cc9v@4ax.com>
References: <t634rq$8ml$1@dont-email.me> <jelrp6F66fiU1@mid.individual.net> <t650re$76f$1@dont-email.me> <t65etp$boo$1@gioia.aioe.org> <nalc8ht3kb9euvbqgskvknklakc0oakkpb@4ax.com> <69e5ec0a-ba86-4e49-aafb-f8a65998ef4cn@googlegroups.com> <ksmc8hpu9r3f9d9l6i0id6p1888oajvc59@4ax.com> <t65mrr$bup$1@gioia.aioe.org>
X-Newsreader: Forte Agent 3.1/32.783
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 62
X-Trace: sv3-KPpqzk7oYlpcSml1AUfv3r7NG9cng0VSQCd7z5JoL/xYH6Z1Ez5HNJ+SHlojs/XjLbOB3zmiWNv+D8F!KZYDNGaCB0RC18Fyk7IiDdCTv0tZb3Hx2+byzUKhaRjKOyP0HOmJ+UYenrvBVTPBIlTsHQHaAhNK!pYTD1Q==
X-Complaints-To: www.supernews.com/docs/abuse.html
X-DMCA-Complaints-To: www.supernews.com/docs/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 3522
 by: jlar...@highlandsniptechnology.com - Thu, 19 May 2022 15:17 UTC

On Thu, 19 May 2022 17:14:02 +0200, Jeroen Belleman
<jeroen@nospam.please> 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.
>>
>> Of course, some people are hostile to ideas. Their career path is more
>> McDonalds than electronic design.
>>
>
>Goofy ideas aren't really welcome if they upset a sizable fraction
>of effort already invested.

Economists call that the Sunk Cost Fallacy.

Ideas are cheap. Realizing them is costly.
>You'll want to be selective.

Sometimes an idea can wipe out a million dollar investment but have a
shorter path to done. Managers don't like that situation.

--

Anybody can count to one.

- Robert Widlar

Re: Error correction in short packet.

<e6d2b835-e57d-8fca-f50b-48489d36c9bd@electrooptical.net>

 copy mid

https://www.novabbs.com/tech/article-flat.php?id=97163&group=sci.electronics.design#97163

 copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!nntp.supernews.com!news.supernews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 19 May 2022 10:48:40 -0500
Subject: Re: Error correction in short packet.
Newsgroups: sci.electronics.design
References: <t634rq$8ml$1@dont-email.me> <jelrp6F66fiU1@mid.individual.net>
<t650re$76f$1@dont-email.me> <t65etp$boo$1@gioia.aioe.org>
<nalc8ht3kb9euvbqgskvknklakc0oakkpb@4ax.com>
<69e5ec0a-ba86-4e49-aafb-f8a65998ef4cn@googlegroups.com>
<ksmc8hpu9r3f9d9l6i0id6p1888oajvc59@4ax.com> <t65mrr$bup$1@gioia.aioe.org>
<fnnc8hdplj84j2d7n1o5mioif6i0m2cc9v@4ax.com>
From: pcdhSpam...@electrooptical.net (Phil Hobbs)
Message-ID: <e6d2b835-e57d-8fca-f50b-48489d36c9bd@electrooptical.net>
Date: Thu, 19 May 2022 11:48:39 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.0
MIME-Version: 1.0
In-Reply-To: <fnnc8hdplj84j2d7n1o5mioif6i0m2cc9v@4ax.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 78
X-Trace: sv3-uu91ES5KiXA3J0Ma8bYEb1LNLzTin045Jt5zVdVCk3LaLR5z5xLRI9zCJ1vbOAAkkpvbLbVUwG9hiEp!zVGjPrGAnQwDmfFNIimtTBNVjSh5e9i9YIAVBmGd4E8T3YAt5ftmOxUJFSAVMxVoShb6qkHki3kP!eta33ZSUsMWRpn7vXWXj2sw=
X-Complaints-To: www.supernews.com/docs/abuse.html
X-DMCA-Complaints-To: www.supernews.com/docs/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 4400
 by: Phil Hobbs - Thu, 19 May 2022 15:48 UTC

jlarkin@highlandsniptechnology.com wrote:
> On Thu, 19 May 2022 17:14:02 +0200, Jeroen Belleman
> <jeroen@nospam.please> 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.
>>>
>>> Of course, some people are hostile to ideas. Their career path is more
>>> McDonalds than electronic design.
>>>
>>
>> Goofy ideas aren't really welcome if they upset a sizable fraction
>> of effort already invested.
>
> Economists call that the Sunk Cost Fallacy.
>
> Ideas are cheap. Realizing them is costly.
>> You'll want to be selective.
>
> Sometimes an idea can wipe out a million dollar investment but have a
> shorter path to done. Managers don't like that situation.

Good ones will laugh and take the short cut (after checking it
carefully, of course). They'll also listen more carefully to the person
that came up with it. ;)

Since the budget will already have been approved, they might continue
along both paths for a bit, to build confidence in the new approach
before committing fully to it.

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

Re: Error correction in short packet.

<t65sj5$19h4$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/tech/article-flat.php?id=97167&group=sci.electronics.design#97167

 copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!aioe.org!1opkGzcI0JwP/0UL+E/Duw.user.46.165.242.91.POSTED!not-for-mail
From: jer...@nospam.please (Jeroen Belleman)
Newsgroups: sci.electronics.design
Subject: Re: Error correction in short packet.
Date: Thu, 19 May 2022 18:51:48 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t65sj5$19h4$1@gioia.aioe.org>
References: <t634rq$8ml$1@dont-email.me> <jelrp6F66fiU1@mid.individual.net> <t650re$76f$1@dont-email.me> <t65etp$boo$1@gioia.aioe.org> <nalc8ht3kb9euvbqgskvknklakc0oakkpb@4ax.com> <69e5ec0a-ba86-4e49-aafb-f8a65998ef4cn@googlegroups.com> <ksmc8hpu9r3f9d9l6i0id6p1888oajvc59@4ax.com> <t65mrr$bup$1@gioia.aioe.org> <fnnc8hdplj84j2d7n1o5mioif6i0m2cc9v@4ax.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="42532"; posting-host="1opkGzcI0JwP/0UL+E/Duw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
X-Notice: Filtered by postfilter v. 0.9.2
 by: Jeroen Belleman - Thu, 19 May 2022 16:51 UTC

On 2022-05-19 17:17, jlarkin@highlandsniptechnology.com wrote:
> On Thu, 19 May 2022 17:14:02 +0200, Jeroen Belleman
> <jeroen@nospam.please> 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.
>>>
>>> Of course, some people are hostile to ideas. Their career path is more
>>> McDonalds than electronic design.
>>>
>>
>> Goofy ideas aren't really welcome if they upset a sizable fraction
>> of effort already invested.
>
> Economists call that the Sunk Cost Fallacy.
>
> Ideas are cheap. Realizing them is costly.
>> You'll want to be selective.
>
> Sometimes an idea can wipe out a million dollar investment but have a
> shorter path to done. Managers don't like that situation.
>

Everything is easy for those who don't have to do the work
themselves. I certainly include economists in that lot. The
sunk costs are needed to get intimate with the problem to be
solved.

I think it's the guy who has to do the work who should get
to choose which idea is best.

Jeroen Belleman

Re: Error correction in short packet.

<t661g6$p79$1@reader1.panix.com>

 copy mid

https://www.novabbs.com/tech/article-flat.php?id=97182&group=sci.electronics.design#97182

 copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!panix!.POSTED.panix2.panix.com!not-for-mail
From: prese...@MUNGEpanix.com (Cydrome Leader)
Newsgroups: sci.electronics.design
Subject: Re: Error correction in short packet.
Date: Thu, 19 May 2022 18:15:35 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <t661g6$p79$1@reader1.panix.com>
References: <t634rq$8ml$1@dont-email.me> <jelrp6F66fiU1@mid.individual.net> <t650re$76f$1@dont-email.me> <t65etp$boo$1@gioia.aioe.org>
Injection-Date: Thu, 19 May 2022 18:15:35 -0000 (UTC)
Injection-Info: reader1.panix.com; posting-host="panix2.panix.com:166.84.1.2";
logging-data="25833"; mail-complaints-to="abuse@panix.com"
User-Agent: tin/2.6.0-20210823 ("Coleburn") (NetBSD/9.2 (amd64))
 by: Cydrome Leader - Thu, 19 May 2022 18:15 UTC

Keegan Major <keegan.major@hotmail.com> wrote:
> Clive Arthur <clive@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?

The original post listed the constraints, but they were lost over the
serial link, and there was no error correction.

I agreed though it didn't seem like any real question was being asked in
the first place.

Re: Error correction in short packet.

<1ec74d6b-3824-460c-bc0c-cd58098cb8aan@googlegroups.com>

 copy mid

https://www.novabbs.com/tech/article-flat.php?id=97185&group=sci.electronics.design#97185

 copy link   Newsgroups: sci.electronics.design
X-Received: by 2002:a05:622a:3cf:b0:2f3:ec70:4e72 with SMTP id k15-20020a05622a03cf00b002f3ec704e72mr5166156qtx.61.1652988287130;
Thu, 19 May 2022 12:24:47 -0700 (PDT)
X-Received: by 2002:a81:980c:0:b0:2f8:be8d:5100 with SMTP id
p12-20020a81980c000000b002f8be8d5100mr6600776ywg.52.1652988286963; Thu, 19
May 2022 12:24:46 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: sci.electronics.design
Date: Thu, 19 May 2022 12:24:46 -0700 (PDT)
In-Reply-To: <ksmc8hpu9r3f9d9l6i0id6p1888oajvc59@4ax.com>
Injection-Info: google-groups.googlegroups.com; posting-host=209.221.140.126; posting-account=vKQm_QoAAADOaDCYsqOFDAW8NJ8sFHoE
NNTP-Posting-Host: 209.221.140.126
References: <t634rq$8ml$1@dont-email.me> <jelrp6F66fiU1@mid.individual.net>
<t650re$76f$1@dont-email.me> <t65etp$boo$1@gioia.aioe.org>
<nalc8ht3kb9euvbqgskvknklakc0oakkpb@4ax.com> <69e5ec0a-ba86-4e49-aafb-f8a65998ef4cn@googlegroups.com>
<ksmc8hpu9r3f9d9l6i0id6p1888oajvc59@4ax.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <1ec74d6b-3824-460c-bc0c-cd58098cb8aan@googlegroups.com>
Subject: Re: Error correction in short packet.
From: whit...@gmail.com (whit3rd)
Injection-Date: Thu, 19 May 2022 19:24:47 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2148
 by: whit3rd - Thu, 19 May 2022 19:24 UTC

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.

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.

Re: Error correction in short packet.

<t667g0$gi8$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/tech/article-flat.php?id=97189&group=sci.electronics.design#97189

 copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!aioe.org!41edQ3YjPRN8eZ1dw7PDcA.user.46.165.242.75.POSTED!not-for-mail
From: '''newsp...@nonad.co.uk (Martin Brown)
Newsgroups: sci.electronics.design
Subject: Re: Error correction in short packet.
Date: Thu, 19 May 2022 20:57:51 +0100
Organization: Aioe.org NNTP Server
Message-ID: <t667g0$gi8$1@gioia.aioe.org>
References: <t634rq$8ml$1@dont-email.me> <jelrp6F66fiU1@mid.individual.net>
<t650re$76f$1@dont-email.me> <t65etp$boo$1@gioia.aioe.org>
<nalc8ht3kb9euvbqgskvknklakc0oakkpb@4ax.com>
<69e5ec0a-ba86-4e49-aafb-f8a65998ef4cn@googlegroups.com>
<ksmc8hpu9r3f9d9l6i0id6p1888oajvc59@4ax.com> <t65mrr$bup$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="16968"; posting-host="41edQ3YjPRN8eZ1dw7PDcA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Content-Language: en-GB
X-Notice: Filtered by postfilter v. 0.9.2
 by: Martin Brown - Thu, 19 May 2022 19:57 UTC

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.

--
Regards,
Martin Brown

Re: Error correction in short packet.

<9mad8hdlr3gg1i7fslia410oo9178v8v6s@4ax.com>

 copy mid

https://www.novabbs.com/tech/article-flat.php?id=97196&group=sci.electronics.design#97196

 copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!nntp.supernews.com!news.supernews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 19 May 2022 15:56:23 -0500
From: jlar...@highland_atwork_technology.com (John Larkin)
Newsgroups: sci.electronics.design
Subject: Re: Error correction in short packet.
Date: Thu, 19 May 2022 13:56:23 -0700
Organization: Highland Tech
Reply-To: xx@yy.com
Message-ID: <9mad8hdlr3gg1i7fslia410oo9178v8v6s@4ax.com>
References: <t634rq$8ml$1@dont-email.me> <jelrp6F66fiU1@mid.individual.net> <t650re$76f$1@dont-email.me> <t65etp$boo$1@gioia.aioe.org> <nalc8ht3kb9euvbqgskvknklakc0oakkpb@4ax.com> <69e5ec0a-ba86-4e49-aafb-f8a65998ef4cn@googlegroups.com> <ksmc8hpu9r3f9d9l6i0id6p1888oajvc59@4ax.com> <t65mrr$bup$1@gioia.aioe.org> <t667g0$gi8$1@gioia.aioe.org>
X-Newsreader: Forte Agent 3.1/32.783
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 106
X-Trace: sv3-pIPfgEutQ/2t6EYkImlEBKPpvRElKT+cJOgyWDUGk5zd5f6IZgk/tGAD+IA1GsXmD0SuPlS0ViDP9fR!/ebFcbMF0w4rbZfnDXJG22CQqJEyQ8LIgIE2DWb9T46o2O9zKRUYAUxJmYbBFYFuaSJ/YMSikHD+!jimG+g==
X-Complaints-To: www.supernews.com/docs/abuse.html
X-DMCA-Complaints-To: www.supernews.com/docs/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 5457
 by: John Larkin - Thu, 19 May 2022 20:56 UTC

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

Re: Error correction in short packet.

<6obd8hhujlsh1d0au056t33hbpog7ut4gu@4ax.com>

 copy mid

https://www.novabbs.com/tech/article-flat.php?id=97198&group=sci.electronics.design#97198

 copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!nntp.supernews.com!news.supernews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 19 May 2022 15:58:56 -0500
From: jlar...@highland_atwork_technology.com (John Larkin)
Newsgroups: sci.electronics.design
Subject: Re: Error correction in short packet.
Date: Thu, 19 May 2022 13:58:56 -0700
Organization: Highland Tech
Reply-To: xx@yy.com
Message-ID: <6obd8hhujlsh1d0au056t33hbpog7ut4gu@4ax.com>
References: <t634rq$8ml$1@dont-email.me> <jelrp6F66fiU1@mid.individual.net> <t650re$76f$1@dont-email.me> <t65etp$boo$1@gioia.aioe.org> <nalc8ht3kb9euvbqgskvknklakc0oakkpb@4ax.com> <69e5ec0a-ba86-4e49-aafb-f8a65998ef4cn@googlegroups.com> <ksmc8hpu9r3f9d9l6i0id6p1888oajvc59@4ax.com> <1ec74d6b-3824-460c-bc0c-cd58098cb8aan@googlegroups.com>
X-Newsreader: Forte Agent 3.1/32.783
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 32
X-Trace: sv3-6NhlaUG7ENCMw9ns1OduYWORPx3+dQQT/X3mhyTxpMjcEI3enO46VnQFHpMjP6jzKFiamtkRJibLwZv!AC7UGduNeOtar0KpLVl1pRmdyvOxxzxvhim5g/KHskkOH0+L6G4oR9G5U/bK65YGP5glDGrEqhGf!Aazi/A==
X-Complaints-To: www.supernews.com/docs/abuse.html
X-DMCA-Complaints-To: www.supernews.com/docs/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 2634
 by: John Larkin - Thu, 19 May 2022 20:58 UTC

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

Re: Error correction in short packet.

<7c35a0c1-4c7a-e2f2-d6f8-8df6aaa9636e@electrooptical.net>

 copy mid

https://www.novabbs.com/tech/article-flat.php?id=97200&group=sci.electronics.design#97200

 copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: pcdhSpam...@electrooptical.net (Phil Hobbs)
Newsgroups: sci.electronics.design
Subject: Re: Error correction in short packet.
Date: Thu, 19 May 2022 17:10:04 -0400
Organization: A noiseless patient Spider
Lines: 112
Message-ID: <7c35a0c1-4c7a-e2f2-d6f8-8df6aaa9636e@electrooptical.net>
References: <t634rq$8ml$1@dont-email.me> <jelrp6F66fiU1@mid.individual.net>
<t650re$76f$1@dont-email.me> <t65etp$boo$1@gioia.aioe.org>
<nalc8ht3kb9euvbqgskvknklakc0oakkpb@4ax.com>
<69e5ec0a-ba86-4e49-aafb-f8a65998ef4cn@googlegroups.com>
<ksmc8hpu9r3f9d9l6i0id6p1888oajvc59@4ax.com> <t65mrr$bup$1@gioia.aioe.org>
<t667g0$gi8$1@gioia.aioe.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="e3797059a575467e5368d02dd010e850";
logging-data="16091"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+qWLLxwXjt3ZD85aTxwdkL"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.0
Cancel-Lock: sha1:fN4a/u0hC2A4mqRAln8vHRtstMU=
In-Reply-To: <t667g0$gi8$1@gioia.aioe.org>
 by: Phil Hobbs - Thu, 19 May 2022 21:10 UTC

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

Re: Error correction in short packet.

<t66eio$81o$1@dont-email.me>

 copy mid

https://www.novabbs.com/tech/article-flat.php?id=97205&group=sci.electronics.design#97205

 copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: blockedo...@foo.invalid (Don Y)
Newsgroups: sci.electronics.design
Subject: Re: Error correction in short packet.
Date: Thu, 19 May 2022 14:58:41 -0700
Organization: A noiseless patient Spider
Lines: 114
Message-ID: <t66eio$81o$1@dont-email.me>
References: <t634rq$8ml$1@dont-email.me> <jelrp6F66fiU1@mid.individual.net>
<t650re$76f$1@dont-email.me> <t65etp$boo$1@gioia.aioe.org>
<nalc8ht3kb9euvbqgskvknklakc0oakkpb@4ax.com>
<69e5ec0a-ba86-4e49-aafb-f8a65998ef4cn@googlegroups.com>
<ksmc8hpu9r3f9d9l6i0id6p1888oajvc59@4ax.com> <t65mrr$bup$1@gioia.aioe.org>
<t667g0$gi8$1@gioia.aioe.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 19 May 2022 21:58:49 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="aa343c9a4b693c96437eb2de260e2439";
logging-data="8248"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+0Oo/GH8l/gtoNeYxpz2L5"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.1.1
Cancel-Lock: sha1:mV9M7NrCXKnBIeWcjOpjICxACn8=
In-Reply-To: <t667g0$gi8$1@gioia.aioe.org>
Content-Language: en-US
 by: Don Y - Thu, 19 May 2022 21:58 UTC

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.

Re: Error correction in short packet.

<jmgd8hh6svfl3v2scs41tuqgtp2mp70apc@4ax.com>

 copy mid

https://www.novabbs.com/tech/article-flat.php?id=97206&group=sci.electronics.design#97206

 copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!nntp.club.cc.cmu.edu!45.76.7.193.MISMATCH!3.us.feeder.erje.net!feeder.erje.net!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!nntp.supernews.com!news.supernews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 19 May 2022 17:31:10 -0500
From: jlar...@highland_atwork_technology.com (John Larkin)
Newsgroups: sci.electronics.design
Subject: Re: Error correction in short packet.
Date: Thu, 19 May 2022 15:31:10 -0700
Organization: Highland Tech
Reply-To: xx@yy.com
Message-ID: <jmgd8hh6svfl3v2scs41tuqgtp2mp70apc@4ax.com>
References: <t634rq$8ml$1@dont-email.me> <jelrp6F66fiU1@mid.individual.net> <t650re$76f$1@dont-email.me> <t65etp$boo$1@gioia.aioe.org> <nalc8ht3kb9euvbqgskvknklakc0oakkpb@4ax.com> <69e5ec0a-ba86-4e49-aafb-f8a65998ef4cn@googlegroups.com> <ksmc8hpu9r3f9d9l6i0id6p1888oajvc59@4ax.com> <t65mrr$bup$1@gioia.aioe.org> <t667g0$gi8$1@gioia.aioe.org> <7c35a0c1-4c7a-e2f2-d6f8-8df6aaa9636e@electrooptical.net>
X-Newsreader: Forte Agent 3.1/32.783
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 120
X-Trace: sv3-qqR028Bcf9vW34QrPRXLGh4DB1tSzXgZay8PomL1YhofY8B4mlNaPFUG22MaeKgVvcYktkSwdLZlmYT!xK9hjD3tCUd19w4cAgi03WgbRyGP9goLqFW2WYsE6p0KLulzgvCLa1mDM9ADwMJMD9AS6k0we+pq!Bx1ANg==
X-Complaints-To: www.supernews.com/docs/abuse.html
X-DMCA-Complaints-To: www.supernews.com/docs/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 6692
 by: John Larkin - Thu, 19 May 2022 22:31 UTC

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.

--

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

Re: Error correction in short packet.

<r9hd8hpt4ifmipr4ivqul1lf890k0hoskm@4ax.com>

 copy mid

https://www.novabbs.com/tech/article-flat.php?id=97207&group=sci.electronics.design#97207

 copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!nntp.supernews.com!news.supernews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 19 May 2022 17:39:12 -0500
From: jlar...@highland_atwork_technology.com (John Larkin)
Newsgroups: sci.electronics.design
Subject: Re: Error correction in short packet.
Date: Thu, 19 May 2022 15:39:12 -0700
Organization: Highland Tech
Reply-To: xx@yy.com
Message-ID: <r9hd8hpt4ifmipr4ivqul1lf890k0hoskm@4ax.com>
References: <t634rq$8ml$1@dont-email.me> <jelrp6F66fiU1@mid.individual.net> <t650re$76f$1@dont-email.me> <t65etp$boo$1@gioia.aioe.org> <nalc8ht3kb9euvbqgskvknklakc0oakkpb@4ax.com> <69e5ec0a-ba86-4e49-aafb-f8a65998ef4cn@googlegroups.com> <ksmc8hpu9r3f9d9l6i0id6p1888oajvc59@4ax.com> <t65mrr$bup$1@gioia.aioe.org> <t667g0$gi8$1@gioia.aioe.org> <t66eio$81o$1@dont-email.me>
X-Newsreader: Forte Agent 3.1/32.783
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 147
X-Trace: sv3-gRZknGg0fijfzM1SQMqmZOr972FVVDBgUWH9CqRCWSSu51sNeM9V3fk30vhU1jfv0dU3ZiascinGL/+!6AfvZHfb7qOY6gElX0HnYNuHBvlr7G4wTs0CIUhSY9TvqqkPxmip4OUEGGFVW3HfS8dltnkFQBMi!KG1jSw==
X-Complaints-To: www.supernews.com/docs/abuse.html
X-DMCA-Complaints-To: www.supernews.com/docs/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 7376
 by: John Larkin - Thu, 19 May 2022 22:39 UTC

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

Re: Error correction in short packet.

<d6078414-9523-808f-5f33-c5ac4bd7419a@electrooptical.net>

 copy mid

https://www.novabbs.com/tech/article-flat.php?id=97209&group=sci.electronics.design#97209

 copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: pcdhSpam...@electrooptical.net (Phil Hobbs)
Newsgroups: sci.electronics.design
Subject: Re: Error correction in short packet.
Date: Thu, 19 May 2022 19:12:20 -0400
Organization: A noiseless patient Spider
Lines: 176
Message-ID: <d6078414-9523-808f-5f33-c5ac4bd7419a@electrooptical.net>
References: <t634rq$8ml$1@dont-email.me> <jelrp6F66fiU1@mid.individual.net>
<t650re$76f$1@dont-email.me> <t65etp$boo$1@gioia.aioe.org>
<nalc8ht3kb9euvbqgskvknklakc0oakkpb@4ax.com>
<69e5ec0a-ba86-4e49-aafb-f8a65998ef4cn@googlegroups.com>
<ksmc8hpu9r3f9d9l6i0id6p1888oajvc59@4ax.com> <t65mrr$bup$1@gioia.aioe.org>
<t667g0$gi8$1@gioia.aioe.org>
<7c35a0c1-4c7a-e2f2-d6f8-8df6aaa9636e@electrooptical.net>
<jmgd8hh6svfl3v2scs41tuqgtp2mp70apc@4ax.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="2591faee05f723dc3a31e813d8dc4948";
logging-data="4568"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18mM34ThpT8qkYCBIVcAhz2"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.0
Cancel-Lock: sha1:9OJxsPjIUUUduxnIxzXhw+q+iDM=
In-Reply-To: <jmgd8hh6svfl3v2scs41tuqgtp2mp70apc@4ax.com>
 by: Phil Hobbs - Thu, 19 May 2022 23:12 UTC

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

Re: Error correction in short packet.

<1uld8h1jt26r8vphkhqf0o0gh64ikt2vcf@4ax.com>

 copy mid

https://www.novabbs.com/tech/article-flat.php?id=97210&group=sci.electronics.design#97210

 copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!nntp.supernews.com!news.supernews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 19 May 2022 19:05:42 -0500
From: jlar...@highland_atwork_technology.com (John Larkin)
Newsgroups: sci.electronics.design
Subject: Re: Error correction in short packet.
Date: Thu, 19 May 2022 17:05:42 -0700
Organization: Highland Tech
Reply-To: xx@yy.com
Message-ID: <1uld8h1jt26r8vphkhqf0o0gh64ikt2vcf@4ax.com>
References: <jelrp6F66fiU1@mid.individual.net> <t650re$76f$1@dont-email.me> <t65etp$boo$1@gioia.aioe.org> <nalc8ht3kb9euvbqgskvknklakc0oakkpb@4ax.com> <69e5ec0a-ba86-4e49-aafb-f8a65998ef4cn@googlegroups.com> <ksmc8hpu9r3f9d9l6i0id6p1888oajvc59@4ax.com> <t65mrr$bup$1@gioia.aioe.org> <t667g0$gi8$1@gioia.aioe.org> <7c35a0c1-4c7a-e2f2-d6f8-8df6aaa9636e@electrooptical.net> <jmgd8hh6svfl3v2scs41tuqgtp2mp70apc@4ax.com> <d6078414-9523-808f-5f33-c5ac4bd7419a@electrooptical.net>
X-Newsreader: Forte Agent 3.1/32.783
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 189
X-Trace: sv3-WqZ20LFT+xPN3yf9Xws7xNny+6mhRHb8X0nSSqeWLlOLq/NiNunISzzPf6W2EwRJUTi7r972Ke7cQZz!uDRJO1ZN6RW6KVnmssLMcXTmyl6asuU5DfQw8DxC4aQrFjOz30MVD8Nw5MDl9s222WA4gdama8pF!KcKrTQ==
X-Complaints-To: www.supernews.com/docs/abuse.html
X-DMCA-Complaints-To: www.supernews.com/docs/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 9941
 by: John Larkin - Fri, 20 May 2022 00:05 UTC

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


Click here to read the complete article
Re: Error correction in short packet.

<t66sqp$1nd8$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/tech/article-flat.php?id=97216&group=sci.electronics.design#97216

 copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!aioe.org!jYLSlS28AEjwMFqK5/gJCw.user.46.165.242.75.POSTED!not-for-mail
From: pcdhSpam...@electrooptical.net (Phil Hobbs)
Newsgroups: sci.electronics.design
Subject: Re: Error correction in short packet.
Date: Thu, 19 May 2022 22:01:59 -0400
Organization: Aioe.org NNTP Server
Message-ID: <t66sqp$1nd8$1@gioia.aioe.org>
References: <jelrp6F66fiU1@mid.individual.net> <t650re$76f$1@dont-email.me>
<t65etp$boo$1@gioia.aioe.org> <nalc8ht3kb9euvbqgskvknklakc0oakkpb@4ax.com>
<69e5ec0a-ba86-4e49-aafb-f8a65998ef4cn@googlegroups.com>
<ksmc8hpu9r3f9d9l6i0id6p1888oajvc59@4ax.com> <t65mrr$bup$1@gioia.aioe.org>
<t667g0$gi8$1@gioia.aioe.org>
<7c35a0c1-4c7a-e2f2-d6f8-8df6aaa9636e@electrooptical.net>
<jmgd8hh6svfl3v2scs41tuqgtp2mp70apc@4ax.com>
<d6078414-9523-808f-5f33-c5ac4bd7419a@electrooptical.net>
<1uld8h1jt26r8vphkhqf0o0gh64ikt2vcf@4ax.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="56744"; posting-host="jYLSlS28AEjwMFqK5/gJCw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.0
X-Notice: Filtered by postfilter v. 0.9.2
 by: Phil Hobbs - Fri, 20 May 2022 02:01 UTC

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. ;(
>>


Click here to read the complete article
Re: Error correction in short packet.

<565f4388-8e3e-4f93-add6-0db4e9e25d5bn@googlegroups.com>

 copy mid

https://www.novabbs.com/tech/article-flat.php?id=97227&group=sci.electronics.design#97227

 copy link   Newsgroups: sci.electronics.design
X-Received: by 2002:a05:620a:371d:b0:6a0:237c:abb with SMTP id de29-20020a05620a371d00b006a0237c0abbmr5090306qkb.685.1653017905128;
Thu, 19 May 2022 20:38:25 -0700 (PDT)
X-Received: by 2002:a0d:ed41:0:b0:2ff:2f40:3d7b with SMTP id
w62-20020a0ded41000000b002ff2f403d7bmr8263166ywe.143.1653017904918; Thu, 19
May 2022 20:38:24 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: sci.electronics.design
Date: Thu, 19 May 2022 20:38:24 -0700 (PDT)
In-Reply-To: <6obd8hhujlsh1d0au056t33hbpog7ut4gu@4ax.com>
Injection-Info: google-groups.googlegroups.com; posting-host=209.221.140.126; posting-account=vKQm_QoAAADOaDCYsqOFDAW8NJ8sFHoE
NNTP-Posting-Host: 209.221.140.126
References: <t634rq$8ml$1@dont-email.me> <jelrp6F66fiU1@mid.individual.net>
<t650re$76f$1@dont-email.me> <t65etp$boo$1@gioia.aioe.org>
<nalc8ht3kb9euvbqgskvknklakc0oakkpb@4ax.com> <69e5ec0a-ba86-4e49-aafb-f8a65998ef4cn@googlegroups.com>
<ksmc8hpu9r3f9d9l6i0id6p1888oajvc59@4ax.com> <1ec74d6b-3824-460c-bc0c-cd58098cb8aan@googlegroups.com>
<6obd8hhujlsh1d0au056t33hbpog7ut4gu@4ax.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <565f4388-8e3e-4f93-add6-0db4e9e25d5bn@googlegroups.com>
Subject: Re: Error correction in short packet.
From: whit...@gmail.com (whit3rd)
Injection-Date: Fri, 20 May 2022 03:38:25 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2238
 by: whit3rd - Fri, 20 May 2022 03:38 UTC

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.

Re: Error correction in short packet.

<16f0bd6173585d80$16$3266748$c2465acb@news.newsdemon.com>

 copy mid

https://www.novabbs.com/tech/article-flat.php?id=97229&group=sci.electronics.design#97229

 copy link   Newsgroups: sci.electronics.design
Date: Fri, 20 May 2022 16:48:06 +1000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0
Subject: Re: Error correction in short packet.
Content-Language: en-US
Newsgroups: sci.electronics.design
References: <t634rq$8ml$1@dont-email.me> <tq7a8htn5hae97crdtj6lep2dnlop2ag5s@4ax.com> <16f0525496e050be$77$3423140$c2965a1b@news.newsdemon.com> <ckta8h9etghmhefrmops0bufpaemai5b6a@4ax.com>
From: eatREMOV...@tpg.com.au (David Eather)
In-Reply-To: <ckta8h9etghmhefrmops0bufpaemai5b6a@4ax.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 56
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!feeder1.feed.usenet.farm!feed.usenet.farm!feeder.usenetexpress.com!tr1.eu1.usenetexpress.com!news.newsdemon.com!not-for-mail
NNTP-Posting-Date: Fri, 20 May 2022 06:48:09 +0000
X-Received-Bytes: 2889
Organization: NewsDemon - www.newsdemon.com
X-Complaints-To: abuse@newsdemon.com
Message-ID: <16f0bd6173585d80$16$3266748$c2465acb@news.newsdemon.com>
 by: David Eather - Fri, 20 May 2022 06:48 UTC

On 19/05/2022 8:46 am, John Larkin wrote:
> On Thu, 19 May 2022 08:06:25 +1000, David Eather
> <eatREMOVEher@tpg.com.au> wrote:
>
>> On 19/05/2022 2:32 am, jlarkin@highlandsniptechnology.com wrote:
>>> On Wed, 18 May 2022 16:54:32 +0100, 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?
>>>>
>>>> Or maybe a completely different approach? This has to be done on the
>>>> fly, and multi-kilobyte LUTs or thousands of clock cycles are out of the
>>>> question.
>>>
>>>
>>> Send it three times and compare.
>>>
>>>
>>>
>>
>>
>> you didn't read the 2 byte limit he said he had? The answer is it can't
>> be done with the constraints he has specified.
>
> He specified a packet length limit, but didn't say he couldn't send it
> multiple times.
>
> I'm trying to be helpful, you are trying to be obnoxious. Do whatever
> you are best at.
>

I'm being helpful - if he had such a limit on packet size he probably
has a limit on how much he can send. What he wants is not possible with
the limits he has described. It is helpful to let him know he has to
reassess his limits rather than just assume he can do what you want -
and there are more efficient ways than just send it three times.

you were just being noise.

Re: Error correction in short packet.

<t67cqn$tn0$2@gonzo.revmaps.no-ip.org>

 copy mid

https://www.novabbs.com/tech/article-flat.php?id=97231&group=sci.electronics.design#97231

 copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx07.iad.POSTED!not-for-mail
From: use...@revmaps.no-ip.org (Jasen Betts)
Newsgroups: sci.electronics.design
Subject: Re: Error correction in short packet.
Organization: JJ's own news server
Message-ID: <t67cqn$tn0$2@gonzo.revmaps.no-ip.org>
References: <t634rq$8ml$1@dont-email.me>
Injection-Date: Fri, 20 May 2022 06:35:03 -0000 (UTC)
Injection-Info: gonzo.revmaps.no-ip.org; posting-host="localhost:127.0.0.1";
logging-data="30432"; mail-complaints-to="usenet@gonzo.revmaps.no-ip.org"
User-Agent: slrn/1.0.3 (Linux)
X-Face: ?)Aw4rXwN5u0~$nqKj`xPz>xHCwgi^q+^?Ri*+R(&uv2=E1Q0Zk(>h!~o2ID@6{uf8s;a
+M[5[U[QT7xFN%^gR"=tuJw%TXXR'Fp~W;(T"1(739R%m0Yyyv*gkGoPA.$b,D.w:z+<'"=-lVT?6
{T?=R^:W5g|E2#EhjKCa+nt":4b}dU7GYB*HBxn&Td$@f%.kl^:7X8rQWd[NTc"P"u6nkisze/Q;8
"9Z{peQF,w)7UjV$c|RO/mQW/NMgWfr5*$-Z%u46"/00mx-,\R'fLPe.)^
Lines: 26
X-Complaints-To: https://www.astraweb.com/aup
NNTP-Posting-Date: Fri, 20 May 2022 07:00:53 UTC
Date: Fri, 20 May 2022 06:35:03 -0000 (UTC)
X-Received-Bytes: 2063
 by: Jasen Betts - Fri, 20 May 2022 06:35 UTC

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.

Re: Error correction in short packet.

<16f0c0892e1e501c$152$3317172$c2665aeb@news.newsdemon.com>

 copy mid

https://www.novabbs.com/tech/article-flat.php?id=97234&group=sci.electronics.design#97234

 copy link   Newsgroups: sci.electronics.design
Date: Fri, 20 May 2022 17:45:55 +1000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0
Subject: Re: Error correction in short packet.
Content-Language: en-US
Newsgroups: sci.electronics.design
References: <t634rq$8ml$1@dont-email.me>
From: eatREMOV...@tpg.com.au (David Eather)
In-Reply-To: <t634rq$8ml$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 47
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!feeder.usenetexpress.com!tr1.eu1.usenetexpress.com!news.newsdemon.com!not-for-mail
NNTP-Posting-Date: Fri, 20 May 2022 07:45:58 +0000
X-Received-Bytes: 2643
X-Complaints-To: abuse@newsdemon.com
Organization: NewsDemon - www.newsdemon.com
Message-ID: <16f0c0892e1e501c$152$3317172$c2665aeb@news.newsdemon.com>
 by: David Eather - Fri, 20 May 2022 07:45 UTC

On 19/05/2022 1:54 am, Clive Arthur 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?
>
> Or maybe a completely different approach? This has to be done on the
> fly, and multi-kilobyte LUTs or thousands of clock cycles are out of the
> question.
>
this one shouldn't be thousands of compute cycles and only a small look
up table or maybe even none.

This one is out of the box: take the 14 bytes and append to bytes of a
known pattern 0x00 or 0xFF will work as well as anything else. Use a
128-bit (16 bytes) encryption algorithm and send that. On the receiving
end, decrypt. If the last two bytes are the same as the two you added
then all good.

if not then you have to brute force the data. All possible single bit
errors, all 2 bit errors etc until you get the answer or run out of
time. The good news is that this will pick up multiple bit errors

99.8% of all possible 1 bit errors - 128 in total
87.6% of all possible 2 bit errors - 8128 in total

each and every bit error has a ((2^16)-1)/2^16 chance to be detected.
that is a 99.999% chance.

Since you are not using the encryption algorithm as a cryptographic
device but just a randomizing device you can probably chop it length
down in half to double its speed.

Re: Error correction in short packet.

<koIhK.935$tLd9.637@fx98.iad>

 copy mid

https://www.novabbs.com/tech/article-flat.php?id=97237&group=sci.electronics.design#97237

 copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!feeder1.feed.usenet.farm!feed.usenet.farm!peer02.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx98.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Subject: Re: Error correction in short packet.
Content-Language: en-US
Newsgroups: sci.electronics.design
References: <t634rq$8ml$1@dont-email.me> <jelrp6F66fiU1@mid.individual.net>
<t650re$76f$1@dont-email.me> <t65etp$boo$1@gioia.aioe.org>
<nalc8ht3kb9euvbqgskvknklakc0oakkpb@4ax.com>
<69e5ec0a-ba86-4e49-aafb-f8a65998ef4cn@googlegroups.com>
<ksmc8hpu9r3f9d9l6i0id6p1888oajvc59@4ax.com> <t65mrr$bup$1@gioia.aioe.org>
<t667g0$gi8$1@gioia.aioe.org>
<7c35a0c1-4c7a-e2f2-d6f8-8df6aaa9636e@electrooptical.net>
From: mar...@invalid.net (marty)
In-Reply-To: <7c35a0c1-4c7a-e2f2-d6f8-8df6aaa9636e@electrooptical.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 112
Message-ID: <koIhK.935$tLd9.637@fx98.iad>
X-Complaints-To: abuse@blocknews.net
NNTP-Posting-Date: Fri, 20 May 2022 08:34:24 UTC
Organization: blocknews - www.blocknews.net
Date: Fri, 20 May 2022 18:34:24 +1000
X-Received-Bytes: 5852
 by: marty - Fri, 20 May 2022 08:34 UTC

On 20/5/22 07:10, Phil Hobbs 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.)
>
> 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
>
archived

--
Marty

Re: Error correction in short packet.

<t67sue$7pl$1@gonzo.revmaps.no-ip.org>

 copy mid

https://www.novabbs.com/tech/article-flat.php?id=97258&group=sci.electronics.design#97258

 copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!peer02.ams4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx33.iad.POSTED!not-for-mail
From: use...@revmaps.no-ip.org (Jasen Betts)
Newsgroups: sci.electronics.design
Subject: Re: Error correction in short packet.
Organization: JJ's own news server
Message-ID: <t67sue$7pl$1@gonzo.revmaps.no-ip.org>
References: <t634rq$8ml$1@dont-email.me>
<t67cqn$tn0$2@gonzo.revmaps.no-ip.org>
Injection-Date: Fri, 20 May 2022 11:10:06 -0000 (UTC)
Injection-Info: gonzo.revmaps.no-ip.org; posting-host="localhost:127.0.0.1";
logging-data="7989"; mail-complaints-to="usenet@gonzo.revmaps.no-ip.org"
User-Agent: slrn/1.0.3 (Linux)
X-Face: ?)Aw4rXwN5u0~$nqKj`xPz>xHCwgi^q+^?Ri*+R(&uv2=E1Q0Zk(>h!~o2ID@6{uf8s;a
+M[5[U[QT7xFN%^gR"=tuJw%TXXR'Fp~W;(T"1(739R%m0Yyyv*gkGoPA.$b,D.w:z+<'"=-lVT?6
{T?=R^:W5g|E2#EhjKCa+nt":4b}dU7GYB*HBxn&Td$@f%.kl^:7X8rQWd[NTc"P"u6nkisze/Q;8
"9Z{peQF,w)7UjV$c|RO/mQW/NMgWfr5*$-Z%u46"/00mx-,\R'fLPe.)^
Lines: 62
X-Complaints-To: https://www.astraweb.com/aup
NNTP-Posting-Date: Fri, 20 May 2022 11:30:51 UTC
Date: Fri, 20 May 2022 11:10:06 -0000 (UTC)
X-Received-Bytes: 3692
 by: Jasen Betts - Fri, 20 May 2022 11:10 UTC

On 2022-05-20, Jasen Betts <usenet@revmaps.no-ip.org> wrote:
> 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?

Actually no there's 128 bits so there's 128 single bit errors and
127*128/2 two bit errors, and one zero-bit error possibility that all
need to be dealt with.

total 8257 cases

> a look-up table. how much resources do you have?

You say in another message less than several kilobytes.

create a CRC to single-bit error table (use a hash table, because it's
O(1) for lookups)

Now you can explit the fact that CRC is a linear code, so the CRC for
bits m and n wrong is the XOR of the crcs for bit m wrong and the crc
of bit n wrong, (the CRC for all bits correct is of course zero after
feeding the data and CRC into the CRC algorithm.)

If you get a non-zero CRC on a packet look it up in the table

If you don't find a match speculativly xor it with the first CRC in
the table then look up the result, if it's not found, try xoring the
next instead.

CRC might not be the best hash to use for this task, you want
something that gives distinct codes for all 1 and 2 bit errors, I
haven't checked if CRC-16 has that property.

there's 341376 three bit errors, so it's probably not going to be
possible to even detect them using CRC-16.

Using a 15 bit CRC code (or other linear hash code) in combination
with a parity bit should make 3 bit errors detectable however.

This should be do-able in 4000 or so instuction steps - not vastly worse
than the CRC computation itself - especially if you can get perfect
hashing in your LUT.

--
Jasen.

Re: Error correction in short packet.

<t683mf$imi$1@dont-email.me>

 copy mid

https://www.novabbs.com/tech/article-flat.php?id=97260&group=sci.electronics.design#97260

 copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cli...@nowaytoday.co.uk (Clive Arthur)
Newsgroups: sci.electronics.design
Subject: Re: Error correction in short packet.
Date: Fri, 20 May 2022 14:05:17 +0100
Organization: A noiseless patient Spider
Lines: 49
Message-ID: <t683mf$imi$1@dont-email.me>
References: <t634rq$8ml$1@dont-email.me>
<t67cqn$tn0$2@gonzo.revmaps.no-ip.org> <t67sue$7pl$1@gonzo.revmaps.no-ip.org>
Reply-To: clive@nowaytoday.co.uk
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 20 May 2022 13:05:19 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="baf68f800e33b03042a61e1b9954802b";
logging-data="19154"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19uPGhffhD3ZAnYFXCdCs+sQRmp2lbBbzM="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Cancel-Lock: sha1:/wco/SvmtsxRZCpXGdsmhnZZw80=
In-Reply-To: <t67sue$7pl$1@gonzo.revmaps.no-ip.org>
Content-Language: en-GB
 by: Clive Arthur - Fri, 20 May 2022 13:05 UTC

On 20/05/2022 12:10, Jasen Betts wrote:

<snip>
>
> Actually no there's 128 bits so there's 128 single bit errors and
> 127*128/2 two bit errors, and one zero-bit error possibility that all
> need to be dealt with.
>
> total 8257 cases
>
>> a look-up table. how much resources do you have?
>
> You say in another message less than several kilobytes.
>
> create a CRC to single-bit error table (use a hash table, because it's
> O(1) for lookups)
>
> Now you can explit the fact that CRC is a linear code, so the CRC for
> bits m and n wrong is the XOR of the crcs for bit m wrong and the crc
> of bit n wrong, (the CRC for all bits correct is of course zero after
> feeding the data and CRC into the CRC algorithm.)
>
> If you get a non-zero CRC on a packet look it up in the table
>
> If you don't find a match speculativly xor it with the first CRC in
> the table then look up the result, if it's not found, try xoring the
> next instead.
>
> CRC might not be the best hash to use for this task, you want
> something that gives distinct codes for all 1 and 2 bit errors, I
> haven't checked if CRC-16 has that property.
>
> there's 341376 three bit errors, so it's probably not going to be
> possible to even detect them using CRC-16.
>
> Using a 15 bit CRC code (or other linear hash code) in combination
> with a parity bit should make 3 bit errors detectable however.
>
> This should be do-able in 4000 or so instuction steps - not vastly worse
> than the CRC computation itself - especially if you can get perfect
> hashing in your LUT.
>
Thank you, that's very useful. Just one point - my CRC calculation uses
a 512 byte LUT and is done on-the-fly taking only a few instructions for
each byte.

--
Cheers
Clive

Re: Error correction in short packet.

<129f8htibk2av1ahnes57gb0bhbh9dphrf@4ax.com>

 copy mid

https://www.novabbs.com/tech/article-flat.php?id=97263&group=sci.electronics.design#97263

 copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!nntp.supernews.com!news.supernews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 20 May 2022 09:28:41 -0500
From: jlar...@highlandsniptechnology.com
Newsgroups: sci.electronics.design
Subject: Re: Error correction in short packet.
Date: Fri, 20 May 2022 07:28:44 -0700
Message-ID: <129f8htibk2av1ahnes57gb0bhbh9dphrf@4ax.com>
References: <t634rq$8ml$1@dont-email.me> <jelrp6F66fiU1@mid.individual.net> <t650re$76f$1@dont-email.me> <t65etp$boo$1@gioia.aioe.org> <nalc8ht3kb9euvbqgskvknklakc0oakkpb@4ax.com> <69e5ec0a-ba86-4e49-aafb-f8a65998ef4cn@googlegroups.com> <ksmc8hpu9r3f9d9l6i0id6p1888oajvc59@4ax.com> <1ec74d6b-3824-460c-bc0c-cd58098cb8aan@googlegroups.com> <6obd8hhujlsh1d0au056t33hbpog7ut4gu@4ax.com> <565f4388-8e3e-4f93-add6-0db4e9e25d5bn@googlegroups.com>
X-Newsreader: Forte Agent 3.1/32.783
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 42
X-Trace: sv3-5jYvqbseHEA1YS+HwTjtVVePM7q2MGJ0q+Q5vNdx5GYbZT7nKACzekAQC7lQfPFsnXZBx1elolA1Vge!uDcxZRmSJqkjSoL1B19c0wKcXd3OgLGpG8DMwF9sErIkHjuO5bEXL6hURJMGtwXaUS/IR9T4Hhxs!fCy15A==
X-Complaints-To: www.supernews.com/docs/abuse.html
X-DMCA-Complaints-To: www.supernews.com/docs/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 2796
 by: jlar...@highlandsniptechnology.com - Fri, 20 May 2022 14:28 UTC

On Thu, 19 May 2022 20:38:24 -0700 (PDT), whit3rd <whit3rd@gmail.com>
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'.

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.

I have to be careful that my status doesn't make people assume that
I'm right; I don't want to be the poison.

I have grey hair, but cannot recall ever meeting
>someone who was 'hostile to ideas' in general.

Sounds like you haven't brainstormed a lot.

--

Anybody can count to one.

- Robert Widlar

Re: Error correction in short packet.

<57702034-46a4-344b-7759-563d031745e1@electrooptical.net>

 copy mid

https://www.novabbs.com/tech/article-flat.php?id=97268&group=sci.electronics.design#97268

 copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!rocksolid2!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: pcdhSpam...@electrooptical.net (Phil Hobbs)
Newsgroups: sci.electronics.design
Subject: Re: Error correction in short packet.
Date: Fri, 20 May 2022 12:11:23 -0400
Organization: A noiseless patient Spider
Lines: 70
Message-ID: <57702034-46a4-344b-7759-563d031745e1@electrooptical.net>
References: <t634rq$8ml$1@dont-email.me> <jelrp6F66fiU1@mid.individual.net>
<t650re$76f$1@dont-email.me> <t65etp$boo$1@gioia.aioe.org>
<nalc8ht3kb9euvbqgskvknklakc0oakkpb@4ax.com>
<69e5ec0a-ba86-4e49-aafb-f8a65998ef4cn@googlegroups.com>
<ksmc8hpu9r3f9d9l6i0id6p1888oajvc59@4ax.com>
<1ec74d6b-3824-460c-bc0c-cd58098cb8aan@googlegroups.com>
<6obd8hhujlsh1d0au056t33hbpog7ut4gu@4ax.com>
<565f4388-8e3e-4f93-add6-0db4e9e25d5bn@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="d2f365a7aaf3d54e53ed96972b30925b";
logging-data="10067"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX195OpgZ9QqpiT4XDRLr0JEK"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.0
Cancel-Lock: sha1:hPdfVSAIImRMAOR6EmZ8vf5pkdU=
In-Reply-To: <565f4388-8e3e-4f93-add6-0db4e9e25d5bn@googlegroups.com>
 by: Phil Hobbs - Fri, 20 May 2022 16:11 UTC

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

--
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

Re: Error correction in short packet.

<k8hf8hhr3drq1obhng2b0cq3m6b2mutuj0@4ax.com>

 copy mid

https://www.novabbs.com/tech/article-flat.php?id=97274&group=sci.electronics.design#97274

 copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!nntp.supernews.com!news.supernews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 20 May 2022 11:46:38 -0500
From: jlar...@highlandsniptechnology.com
Newsgroups: sci.electronics.design
Subject: Re: Error correction in short packet.
Date: Fri, 20 May 2022 09:46:41 -0700
Message-ID: <k8hf8hhr3drq1obhng2b0cq3m6b2mutuj0@4ax.com>
References: <jelrp6F66fiU1@mid.individual.net> <t650re$76f$1@dont-email.me> <t65etp$boo$1@gioia.aioe.org> <nalc8ht3kb9euvbqgskvknklakc0oakkpb@4ax.com> <69e5ec0a-ba86-4e49-aafb-f8a65998ef4cn@googlegroups.com> <ksmc8hpu9r3f9d9l6i0id6p1888oajvc59@4ax.com> <1ec74d6b-3824-460c-bc0c-cd58098cb8aan@googlegroups.com> <6obd8hhujlsh1d0au056t33hbpog7ut4gu@4ax.com> <565f4388-8e3e-4f93-add6-0db4e9e25d5bn@googlegroups.com> <57702034-46a4-344b-7759-563d031745e1@electrooptical.net>
X-Newsreader: Forte Agent 3.1/32.783
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 77
X-Trace: sv3-bm9EDqrJp6Ew25a2uKblpFL+oF0wOlcRnjembJk4xjO1KPFakW4ZmqP8sWIShFMjaW3JIwO01exSXvI!Y91JJEQqFX1vFfiXhxP5/AI6FzCRcElSnzNqZsgCvGhkHRut7nPyZLnQe1Uyw3gP3I2kjbCMTnNy!/Kblig==
X-Complaints-To: www.supernews.com/docs/abuse.html
X-DMCA-Complaints-To: www.supernews.com/docs/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 4901
 by: jlar...@highlandsniptechnology.com - Fri, 20 May 2022 16:46 UTC

On Fri, 20 May 2022 12:11:23 -0400, Phil Hobbs
<pcdhSpamMeSenseless@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.

Efinix will be interesting to watch, against Xilinx and Altera.

--

Anybody can count to one.

- Robert Widlar

Pages:123
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor