Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Simulations are like miniskirts, they show a lot and hide the essentials. -- Hubert Kirrman


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
Error correction in short packet.

<t634rq$8ml$1@dont-email.me>

 copy mid

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

 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: Error correction in short packet.
Date: Wed, 18 May 2022 16:54:32 +0100
Organization: A noiseless patient Spider
Lines: 27
Message-ID: <t634rq$8ml$1@dont-email.me>
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: Wed, 18 May 2022 15:54:34 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="f357577f622c081730de8ec21ffa9c94";
logging-data="8917"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18rnaEGmeTurj7P2ArtVE3MY2wXGaOdixk="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Cancel-Lock: sha1:ufxlZgUjeW/ypqL8XhUvWtDGw4s=
Content-Language: en-GB
 by: Clive Arthur - Wed, 18 May 2022 15:54 UTC

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.

--
Cheers
Clive

Re: Error correction in short packet.

<tq7a8htn5hae97crdtj6lep2dnlop2ag5s@4ax.com>

 copy mid

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

 copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.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: Wed, 18 May 2022 11:32:02 -0500
From: jlar...@highlandsniptechnology.com
Newsgroups: sci.electronics.design
Subject: Re: Error correction in short packet.
Date: Wed, 18 May 2022 09:32:05 -0700
Message-ID: <tq7a8htn5hae97crdtj6lep2dnlop2ag5s@4ax.com>
References: <t634rq$8ml$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: 38
X-Trace: sv3-7PqbWwElOmT9ULTyHEUsB/lTEUeHmXMqsGXViR/Z2WyREQkO43c5vNKYilVjIhtGHLOmHokIfqNxwNC!9RiVO2cDw0KyZFZUGJkIo78Ix0wrKZdSlgMjIktkJPqlA7HDdSOfTZB9xS/WlX7k+yEldCnoerf0!wZ7cYw==
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: 2282
 by: jlar...@highlandsniptechnology.com - Wed, 18 May 2022 16:32 UTC

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.

--

Anybody can count to one.

- Robert Widlar

Re: Error correction in short packet.

<898b4c0a-3ada-4e55-9ff9-8648894142c2n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: sci.electronics.design
X-Received: by 2002:a05:622a:1301:b0:2f3:af1d:aa57 with SMTP id v1-20020a05622a130100b002f3af1daa57mr566614qtk.257.1652892018896;
Wed, 18 May 2022 09:40:18 -0700 (PDT)
X-Received: by 2002:a25:874d:0:b0:64d:c470:c8aa with SMTP id
e13-20020a25874d000000b0064dc470c8aamr468004ybn.578.1652892014711; Wed, 18
May 2022 09:40:14 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.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: Wed, 18 May 2022 09:40:14 -0700 (PDT)
In-Reply-To: <tq7a8htn5hae97crdtj6lep2dnlop2ag5s@4ax.com>
Injection-Info: google-groups.googlegroups.com; posting-host=94.145.246.173; posting-account=mW5JKwkAAAAMyuWOVeLp8yffyAkVx0g7
NNTP-Posting-Host: 94.145.246.173
References: <t634rq$8ml$1@dont-email.me> <tq7a8htn5hae97crdtj6lep2dnlop2ag5s@4ax.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <898b4c0a-3ada-4e55-9ff9-8648894142c2n@googlegroups.com>
Subject: Re: Error correction in short packet.
From: langw...@fonz.dk (Lasse Langwadt Christensen)
Injection-Date: Wed, 18 May 2022 16:40:18 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2562
 by: Lasse Langwadt Chris - Wed, 18 May 2022 16:40 UTC

onsdag den 18. maj 2022 kl. 18.32.15 UTC+2 skrev jla...@highlandsniptechnology.com:
> On Wed, 18 May 2022 16:54:32 +0100, Clive Arthur
> <cl...@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.
but then you need three times the bandwidth which may not be an option

Re: Error correction in short packet.

<ceb6e07c-27ce-4e49-b841-bbc5309c8843n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: sci.electronics.design
X-Received: by 2002:ac8:59d3:0:b0:2f3:d7ee:2b54 with SMTP id f19-20020ac859d3000000b002f3d7ee2b54mr1006967qtf.290.1652898034013;
Wed, 18 May 2022 11:20:34 -0700 (PDT)
X-Received: by 2002:a25:a526:0:b0:64d:f6df:e417 with SMTP id
h35-20020a25a526000000b0064df6dfe417mr949187ybi.620.1652898033824; Wed, 18
May 2022 11:20:33 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.mixmin.net!news2.arglkargh.de!news.karotte.org!fu-berlin.de!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: sci.electronics.design
Date: Wed, 18 May 2022 11:20:33 -0700 (PDT)
In-Reply-To: <898b4c0a-3ada-4e55-9ff9-8648894142c2n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:8b0:7a1f:4433:1a85:f8:3928:1873;
posting-account=de11ZAoAAACBQRb2jWnaIkHYK2q9mRvs
NNTP-Posting-Host: 2001:8b0:7a1f:4433:1a85:f8:3928:1873
References: <t634rq$8ml$1@dont-email.me> <tq7a8htn5hae97crdtj6lep2dnlop2ag5s@4ax.com>
<898b4c0a-3ada-4e55-9ff9-8648894142c2n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <ceb6e07c-27ce-4e49-b841-bbc5309c8843n@googlegroups.com>
Subject: Re: Error correction in short packet.
From: jrwalli...@gmail.com (John Walliker)
Injection-Date: Wed, 18 May 2022 18:20:34 +0000
Content-Type: text/plain; charset="UTF-8"
 by: John Walliker - Wed, 18 May 2022 18:20 UTC

On Wednesday, 18 May 2022 at 17:40:22 UTC+1, lang...@fonz.dk wrote:
> onsdag den 18. maj 2022 kl. 18.32.15 UTC+2 skrev jla...@highlandsniptechnology.com:
> > On Wed, 18 May 2022 16:54:32 +0100, Clive Arthur
> > <cl...@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.
> but then you need three times the bandwidth which may not be an option

It may not be, but bandwidth is much cheaper than it used to be. I have some
international VPN links subject to fairly severe packet loss. Every packet
is sent four times by different routes and the first one to arrive intact gets
passed on and the others are discarded (if they ever arrive). This all works
very nicely at tens of Mbit/s. The improvement in performance is much
more than a factor of four when packet loss is severe and the waste is only a
factor of four when there is no packet loss.

Re:Error correction in short packet.

<t63dv6$f5c$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: martin_r...@verison.net (Martin Rid)
Newsgroups: sci.electronics.design
Subject: Re:Error correction in short packet.
Date: Wed, 18 May 2022 14:29:57 -0400 (EDT)
Organization: news.eternal-september.org
Lines: 12
Message-ID: <t63dv6$f5c$1@dont-email.me>
References: <t634rq$8ml$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 18 May 2022 18:29:58 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="1b181004e4a6f9c9fb11fd18156384b2";
logging-data="15532"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+cKwKkbXfT5Cfner5jvmbK"
Cancel-Lock: sha1:nY5gElK3MHzT+qfOo+XjZvQg8A4=
X-Newsreader: PiaoHong.Usenet.Client.Free:2.02
 by: Martin Rid - Wed, 18 May 2022 18:29 UTC

Clive Arthur <clive@nowaytoday.co.uk> Wrote in message:r
> Hi allI 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.-- CheersClive

Well Reed-Solomon would do what you want. Problem is the crc can
not fix the errors.

Cheers
--

----Android NewsGroup Reader----
https://piaohong.s3-us-west-2.amazonaws.com/usenet/index.html

Re: Error correction in short packet.

<vsga8h9f3r4eddlunq554df94klkqprndh@4ax.com>

 copy mid

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

 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: Wed, 18 May 2022 14:07:30 -0500
From: jlar...@highland_atwork_technology.com (John Larkin)
Newsgroups: sci.electronics.design
Subject: Re: Error correction in short packet.
Date: Wed, 18 May 2022 12:07:30 -0700
Organization: Highland Tech
Reply-To: xx@yy.com
Message-ID: <vsga8h9f3r4eddlunq554df94klkqprndh@4ax.com>
References: <t634rq$8ml$1@dont-email.me> <tq7a8htn5hae97crdtj6lep2dnlop2ag5s@4ax.com> <898b4c0a-3ada-4e55-9ff9-8648894142c2n@googlegroups.com> <ceb6e07c-27ce-4e49-b841-bbc5309c8843n@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: 49
X-Trace: sv3-trluOEzJEYBQyTCtS9gAkLW5pw+hzDW6A3KHXk5MWnjVusu0de4ID8p2ItbDc/fhZkH07TU9sjVN3Bb!8T4NqZ/p8oHxqGNfKrj8JYIJGzBrbHYUpk0RT2Ebcyua1xZSi09mndUfUzM7ze21ywUqWTWOBi0m!/PvXkQ==
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: 3674
 by: John Larkin - Wed, 18 May 2022 19:07 UTC

On Wed, 18 May 2022 11:20:33 -0700 (PDT), John Walliker
<jrwalliker@gmail.com> wrote:

>On Wednesday, 18 May 2022 at 17:40:22 UTC+1, lang...@fonz.dk wrote:
>> onsdag den 18. maj 2022 kl. 18.32.15 UTC+2 skrev jla...@highlandsniptechnology.com:
>> > On Wed, 18 May 2022 16:54:32 +0100, Clive Arthur
>> > <cl...@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.
>> but then you need three times the bandwidth which may not be an option
>
>It may not be, but bandwidth is much cheaper than it used to be. I have some
>international VPN links subject to fairly severe packet loss. Every packet
>is sent four times by different routes and the first one to arrive intact gets
>passed on and the others are discarded (if they ever arrive). This all works
>very nicely at tens of Mbit/s. The improvement in performance is much
>more than a factor of four when packet loss is severe and the waste is only a
>factor of four when there is no packet loss.

One could send three copies of the packet and majority-vote each bit.

--

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.

<t63jcf$p205$1@solani.org>

 copy mid

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

 copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!reader5.news.weretis.net!news.solani.org!.POSTED!not-for-mail
From: dk4...@arcor.de (Gerhard Hoffmann)
Newsgroups: sci.electronics.design
Subject: Re: Error correction in short packet.
Date: Wed, 18 May 2022 22:02:23 +0200
Message-ID: <t63jcf$p205$1@solani.org>
References: <t634rq$8ml$1@dont-email.me>
<tq7a8htn5hae97crdtj6lep2dnlop2ag5s@4ax.com>
<898b4c0a-3ada-4e55-9ff9-8648894142c2n@googlegroups.com>
<ceb6e07c-27ce-4e49-b841-bbc5309c8843n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 18 May 2022 20:02:23 -0000 (UTC)
Injection-Info: solani.org;
logging-data="821253"; mail-complaints-to="abuse@news.solani.org"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.8.1
Cancel-Lock: sha1:Oe4OA2Yj1P1mKbyW3vLKrxApP5s=
In-Reply-To: <ceb6e07c-27ce-4e49-b841-bbc5309c8843n@googlegroups.com>
Content-Language: en-US
X-User-ID: eJwFwQEBACAIA7BKR/iVOILaP4IbXaaeISr4+JQYMVg97z2FvQvQWFiC0XDPlJDh6Uw18wMI1g/d
 by: Gerhard Hoffmann - Wed, 18 May 2022 20:02 UTC

Am 18.05.22 um 20:20 schrieb John Walliker:

> It may not be, but bandwidth is much cheaper than it used to be. I have some
> international VPN links subject to fairly severe packet loss. Every packet
> is sent four times by different routes and the first one to arrive intact gets
> passed on and the others are discarded (if they ever arrive). This all works
> very nicely at tens of Mbit/s. The improvement in performance is much
> more than a factor of four when packet loss is severe and the waste is only a
> factor of four when there is no packet loss.

That works as long as there is a lot of channel capacity and as
long as at least some packets get though without error.

When barely a packet gets through without error, then it's time
for forward error correction. That is, sending it once with
enough redundancy.

cheers, Gerhard

Re: Error correction in short packet.

<t63npe$coa$1@dont-email.me>

 copy mid

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

 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: Wed, 18 May 2022 14:17:26 -0700
Organization: A noiseless patient Spider
Lines: 60
Message-ID: <t63npe$coa$1@dont-email.me>
References: <t634rq$8ml$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 18 May 2022 21:17:35 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="06ddadf6f5cd265bafdbf971e1bd0c92";
logging-data="13066"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18MB7SbeG2K58nRonMX8dC8"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.1.1
Cancel-Lock: sha1:Xj8cg4h3/hvd2nnzdvNVFGNawgg=
In-Reply-To: <t634rq$8ml$1@dont-email.me>
Content-Language: en-US
 by: Don Y - Wed, 18 May 2022 21:17 UTC

On 5/18/2022 8:54 AM, Clive Arthur wrote:
> 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.

Do you know the *nature* of the interference that is (potentially) corrupting
your transmission? Is it periodic? Burst-y? Or, does each bit-time have
an equal AND INDEPENDANT probability of encountering an error?

E.g., does one error event have any effect on the next bit datum?

(Wombats!)

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

As you are receiving the bit STREAM serially, compute the checksum/syndrome
similarly. Presumably you have enough storage (14 bytes) to hold an entire
completed message; a "correction cycle" (some number of clocks) can then
toggle the appropriate bits in the accumulator.

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

I worked on a project where the previous developer naively tried to improve
data integrity by storing three copies of a 16-byte quantity -- and hoping to
"compare them" to determine what the CORRECT value should be.

Of course, this only works as good as simple bit-wise parity (in general)
as two errors can conspire to convince you that THEY reflect the correct
value:
xxxxxxx1xxxxxxxx
yyyyyyy1yyyyyyyy
zzzzzzz0zzzzzzzz
in which each of the x, y and z represent correct values, in agreement with
the redundant copies. The third value being correct, the previous two
reflecting single bit errors in each.

Conclusion:
-------1--------
I.e., you can't correct *any* errors (of a certain type). You've wasted lots
of "check digits" (in this case, 256 bits of check digits on a 128 bit value!)
with little to show for it!

I'm wondering if you could just compute two *different* syndromes (i.e., two
different polynomials) over the same data and treat it as two single-bit
correcting codes. In which case, about 2 bytes of check digit overhead.
(112 bits is ~7b, +1 for parity yields 8 -- for each possible check digit)

But, I've not yet had my breakfast...

Re: Error correction in short packet.

<t63p86$1v6c$1@gioia.aioe.org>

 copy mid

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

 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: Wed, 18 May 2022 22:42:28 +0100
Organization: Aioe.org NNTP Server
Message-ID: <t63p86$1v6c$1@gioia.aioe.org>
References: <t634rq$8ml$1@dont-email.me>
<tq7a8htn5hae97crdtj6lep2dnlop2ag5s@4ax.com>
<898b4c0a-3ada-4e55-9ff9-8648894142c2n@googlegroups.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="64716"; 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
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-GB
 by: Martin Brown - Wed, 18 May 2022 21:42 UTC

On 18/05/2022 17:40, Lasse Langwadt Christensen wrote:
> onsdag den 18. maj 2022 kl. 18.32.15 UTC+2 skrev jla...@highlandsniptechnology.com:
>> On Wed, 18 May 2022 16:54:32 +0100, Clive Arthur
>> <cl...@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.

You don't have space to even reliably detect single bit errors without
making assumptions about the error rate (or hoping that it is only ever
a single bit error and enumerating every possibility).

Sending 256 bits of data with 16 of them for error checking in a perfect
world would allow you to decode the location of that single bit error.

>>> 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.
> but then you need three times the bandwidth which may not be an option

When I have needed to do that (and a very long time ago) we used a
Hamming code 7,4 to deal with a somewhat unreliable punchtape machine
and a single chance to grab the raw data. Correct any single bit error,
detect any two bit error. Overhead for the simplest useful one is 100%.

https://en.wikipedia.org/wiki/Hamming_code#[7,4]_Hamming_code

The error rate turned out to be low enough that it never actually saw a
2 bit error in what was about 32kb of data (64k chars on tape). But we
only discovered that later when it was decoded on the mainframe.

Hadamard convolutional codes might be a better choice now but the
overheads are going to be significant in time and code space.

Space probes use Golay codes these days but you may not have enough
horsepower for that either. The lookup tables for Hamming might be OK...

--
Regards,
Martin Brown

Re: Error correction in short packet.

<16f0525496e050be$77$3423140$c2965a1b@news.newsdemon.com>

 copy mid

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

 copy link   Newsgroups: sci.electronics.design
Date: Thu, 19 May 2022 08:06:25 +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>
From: eatREMOV...@tpg.com.au (David Eather)
In-Reply-To: <tq7a8htn5hae97crdtj6lep2dnlop2ag5s@4ax.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 37
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!2.eu.feeder.erje.net!feeder.erje.net!news.uzoreto.com!feeder.usenetexpress.com!tr1.eu1.usenetexpress.com!news.newsdemon.com!not-for-mail
NNTP-Posting-Date: Wed, 18 May 2022 22:06:26 +0000
X-Received-Bytes: 1991
Organization: NewsDemon - www.newsdemon.com
X-Complaints-To: abuse@newsdemon.com
Message-ID: <16f0525496e050be$77$3423140$c2965a1b@news.newsdemon.com>
 by: David Eather - Wed, 18 May 2022 22:06 UTC

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.

Re: Error correction in short packet.

<ckta8h9etghmhefrmops0bufpaemai5b6a@4ax.com>

 copy mid

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

 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: Wed, 18 May 2022 17:46:24 -0500
From: jlar...@highland_atwork_technology.com (John Larkin)
Newsgroups: sci.electronics.design
Subject: Re: Error correction in short packet.
Date: Wed, 18 May 2022 15:46:23 -0700
Organization: Highland Tech
Reply-To: xx@yy.com
Message-ID: <ckta8h9etghmhefrmops0bufpaemai5b6a@4ax.com>
References: <t634rq$8ml$1@dont-email.me> <tq7a8htn5hae97crdtj6lep2dnlop2ag5s@4ax.com> <16f0525496e050be$77$3423140$c2965a1b@news.newsdemon.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: 52
X-Trace: sv3-qGdV06LCz3qtTa3wbFwD37A1LRPJH+wKGHfC/UnTC/gVTPgVSlfm28y+ajpv7zsN4/qr1L9XExuYz+I!f2R3seXCQU3v1jZzMcf789hc69riLTDR7SMb4dp2Ak2ab5rhWNpDdlbTtaXKfpGMGdBwLEE/3qHe!zEGF7g==
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: 3109
 by: John Larkin - Wed, 18 May 2022 22:46 UTC

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.

--

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.

<jelrp6F66fiU1@mid.individual.net>

 copy mid

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

 copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: syl...@email.invalid (Sylvia Else)
Newsgroups: sci.electronics.design
Subject: Re: Error correction in short packet.
Date: Thu, 19 May 2022 13:27:33 +1000
Lines: 33
Message-ID: <jelrp6F66fiU1@mid.individual.net>
References: <t634rq$8ml$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: individual.net 0SZghTuyCoT2AZTp/nEO9Aeunn2ktwfOWnH8DuTI6D3D0J6HKn
Cancel-Lock: sha1:4tmleVI2+MTJFVcziii2Za3/FfM=
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Content-Language: en-GB
In-Reply-To: <t634rq$8ml$1@dont-email.me>
 by: Sylvia Else - Thu, 19 May 2022 03:27 UTC

On 19-May-22 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.
>

Even if you had a 16 bit value that told you which two bits were wrong,
you'd then have to make use of that information to flip the incorrect
bits. That doesn't sound like small number of LUTs.

Is your channel really that noisy that you cannot just discard bad packets?

Sylvia.

Re: Error correction in short packet.

<e461ff7e-c2cb-4064-9263-f7df1d3a0d9en@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: sci.electronics.design
X-Received: by 2002:a05:6214:c29:b0:45a:fedd:7315 with SMTP id a9-20020a0562140c2900b0045afedd7315mr2536522qvd.59.1652937008846;
Wed, 18 May 2022 22:10:08 -0700 (PDT)
X-Received: by 2002:a81:980c:0:b0:2f8:be8d:5100 with SMTP id
p12-20020a81980c000000b002f8be8d5100mr3032570ywg.52.1652937008681; Wed, 18
May 2022 22:10:08 -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: Wed, 18 May 2022 22:10:08 -0700 (PDT)
In-Reply-To: <vsga8h9f3r4eddlunq554df94klkqprndh@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> <tq7a8htn5hae97crdtj6lep2dnlop2ag5s@4ax.com>
<898b4c0a-3ada-4e55-9ff9-8648894142c2n@googlegroups.com> <ceb6e07c-27ce-4e49-b841-bbc5309c8843n@googlegroups.com>
<vsga8h9f3r4eddlunq554df94klkqprndh@4ax.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <e461ff7e-c2cb-4064-9263-f7df1d3a0d9en@googlegroups.com>
Subject: Re: Error correction in short packet.
From: whit...@gmail.com (whit3rd)
Injection-Date: Thu, 19 May 2022 05:10:08 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2286
 by: whit3rd - Thu, 19 May 2022 05:10 UTC

On Wednesday, May 18, 2022 at 12:07:43 PM UTC-7, John Larkin wrote:
> On Wed, 18 May 2022 11:20:33 -0700 (PDT), John Walliker
> <jrwal...@gmail.com> wrote:
>
> >On Wednesday, 18 May 2022 at 17:40:22 UTC+1, lang...@fonz.dk wrote:
> >> onsdag den 18. maj 2022 kl. 18.32.15 UTC+2 skrev jla...@highlandsniptechnology.com:
> >> > On Wed, 18 May 2022 16:54:32 +0100, Clive Arthur

> >> > >I have serial data in 14 byte packets on which I'd like to detect and
> >> > >correct errors. Two bit errors would be nice.

> >> > Send it three times and compare.

> One could send three copies of the packet and majority-vote each bit.

Or, send one copy with checksum, then a second copy with checksum, then
a third copy. Take the first one that has a correct checksum, or... just stick
with copy 3, you're out of time.

Majority-vote takes (on average) longer because it always waits for three copies.
Checksum, one hopes, is more reassuring per extra bit than voting.

Re: Error correction in short packet.

<t650fs$1l2n$1@gioia.aioe.org>

 copy mid

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

 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 09:52:10 +0100
Organization: Aioe.org NNTP Server
Message-ID: <t650fs$1l2n$1@gioia.aioe.org>
References: <t634rq$8ml$1@dont-email.me>
<tq7a8htn5hae97crdtj6lep2dnlop2ag5s@4ax.com>
<16f0525496e050be$77$3423140$c2965a1b@news.newsdemon.com>
<ckta8h9etghmhefrmops0bufpaemai5b6a@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="54359"; 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
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-GB
 by: Martin Brown - Thu, 19 May 2022 08:52 UTC

On 18/05/2022 23:46, 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.

What do you do when all three are different?
>>
>> 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.

The best bet under his specified constraints is send it with a crc in
the extra 2 bytes and keep on sending it until you get an ack back from
the other end that one has decoded OK. Or if you insist on a simple
voting algorithm until you get two the same. It all depends on the bit
error rate. If it is low enough then detecting a fail by quick crc and
sending a "say again" msg back to the sender would be least invasive.

If the channel is noisy in both directions then it requires a bit more
thought since the conversation could go on forever at very bad SNR.

It should be possible to correct any single bit error and detect any
double bit error in the data stream with just 75% overhead even with a
simple Hamming code - just under double the size of the raw data.

Better EC encodings exist but they require more horsepower.

--
Regards,
Martin Brown

Re: Error correction in short packet.

<t650re$76f$1@dont-email.me>

 copy mid

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

 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: Thu, 19 May 2022 09:58:21 +0100
Organization: A noiseless patient Spider
Lines: 56
Message-ID: <t650re$76f$1@dont-email.me>
References: <t634rq$8ml$1@dont-email.me> <jelrp6F66fiU1@mid.individual.net>
Reply-To: clive@nowaytoday.co.uk
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 19 May 2022 08:58:22 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="f408969eca6ca0381ade7cf9b95a2e77";
logging-data="7375"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19YgZ9keWKPw1Vcj6S2NnlRa/rSljKHU5Q="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Cancel-Lock: sha1:Fn98Lt5V5UT4zptANM+VKaCHDQQ=
In-Reply-To: <jelrp6F66fiU1@mid.individual.net>
Content-Language: en-GB
 by: Clive Arthur - Thu, 19 May 2022 08:58 UTC

On 19/05/2022 04:27, Sylvia Else wrote:
> On 19-May-22 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.
>>
>
> Even if you had a 16 bit value that told you which two bits were wrong,
> you'd then have to make use of that information to flip the incorrect
> bits. That doesn't sound like small number of LUTs.
>
> Is your channel really that noisy that you cannot just discard bad packets?
>
> Sylvia.

I don't have control over the transmission path, it may be noisy, it may
not - it's not a fixed installation. I want to get the best shot at
correcting errors within my fixed constraints, even a single bit EDC
would be useful. I can't request a resend, and sending multiple copies
restricts bandwidth too much.

Of course, there comes a point when it just won't/can't work.

I do know that a CRC approach is easy to implement from the POV of error
detection. I also know that this could detect and correct at least a
single bit error, but I don't know if there's a quick and easy way of
finding the bad bit.

And to be honest, much of the maths associated with EDC is beyond me at
the moment.

--
Cheers
Clive

Re: Error correction in short packet.

<t651o3$p3p$1@dont-email.me>

 copy mid

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

 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: Thu, 19 May 2022 10:13:38 +0100
Organization: A noiseless patient Spider
Lines: 33
Message-ID: <t651o3$p3p$1@dont-email.me>
References: <t634rq$8ml$1@dont-email.me>
<tq7a8htn5hae97crdtj6lep2dnlop2ag5s@4ax.com>
<16f0525496e050be$77$3423140$c2965a1b@news.newsdemon.com>
<ckta8h9etghmhefrmops0bufpaemai5b6a@4ax.com> <t650fs$1l2n$1@gioia.aioe.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: Thu, 19 May 2022 09:13:39 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="f408969eca6ca0381ade7cf9b95a2e77";
logging-data="25721"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19DTTNQXsWPjN16twnsYBBE3GvL8LaTRlA="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Cancel-Lock: sha1:QOVoF7/NJhS4c1VNoVU/iiOY+MA=
In-Reply-To: <t650fs$1l2n$1@gioia.aioe.org>
Content-Language: en-GB
 by: Clive Arthur - Thu, 19 May 2022 09:13 UTC

On 19/05/2022 09:52, Martin Brown wrote:

<snip>

> The best bet under his specified constraints is send it with a crc in
> the extra 2 bytes and keep on sending it until you get an ack back from
> the other end that one has decoded OK. Or if you insist on a simple
> voting algorithm until you get two the same. It all depends on the bit
> error rate. If it is low enough then detecting a fail by quick crc and
> sending a "say again" msg back to the sender would be least invasive.
>
> If the channel is noisy in both directions then it requires a bit more
> thought since the conversation could go on forever at very bad SNR.
>
> It should be possible to correct any single bit error and detect any
> double bit error in the data stream with just 75% overhead even with a
> simple Hamming code - just under double the size of the raw data.

I can't resend packets.

I've looked at 8,4 Hamming codes, easy to implement (and understand!) to
correct a single bit error in a data nibble and detect two bit errors.
It may be the way to go, but it's quite an overhead. Still, with the
ability to switch it in only when needed it might be an answer if
nothing better shows up.
>
> Better EC encodings exist but they require more horsepower.
>
Yes 255,223 Reed-Solomon is used elsewhere, but too 'expensive' here.

--
Cheers
Clive

Re: Error correction in short packet.

<t6523k$dd3$1@gioia.aioe.org>

 copy mid

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

 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 10:19:46 +0100
Organization: Aioe.org NNTP Server
Message-ID: <t6523k$dd3$1@gioia.aioe.org>
References: <t634rq$8ml$1@dont-email.me>
<tq7a8htn5hae97crdtj6lep2dnlop2ag5s@4ax.com>
<16f0525496e050be$77$3423140$c2965a1b@news.newsdemon.com>
<ckta8h9etghmhefrmops0bufpaemai5b6a@4ax.com> <t650fs$1l2n$1@gioia.aioe.org>
<t651o3$p3p$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="13731"; 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 09:19 UTC

On 19/05/2022 10:13, Clive Arthur wrote:
> On 19/05/2022 09:52, Martin Brown wrote:
>
> <snip>
>
>> The best bet under his specified constraints is send it with a crc in
>> the extra 2 bytes and keep on sending it until you get an ack back
>> from the other end that one has decoded OK. Or if you insist on a
>> simple voting algorithm until you get two the same. It all depends on
>> the bit error rate. If it is low enough then detecting a fail by quick
>> crc and sending a "say again" msg back to the sender would be least
>> invasive.
>>
>> If the channel is noisy in both directions then it requires a bit more
>> thought since the conversation could go on forever at very bad SNR.
>>
>> It should be possible to correct any single bit error and detect any
>> double bit error in the data stream with just 75% overhead even with a
>> simple Hamming code - just under double the size of the raw data.
>
> I can't resend packets.

What do you do then if you receive a packet with a detected 2 bit error?
>
> I've looked at 8,4 Hamming codes, easy to implement (and understand!) to
> correct a single bit error in a data nibble and detect two bit errors.
> It may be the way to go, but it's quite an overhead.  Still, with the
> ability to switch it in only when needed it might be an answer if
> nothing better shows up.

I think it is probably your best bet. Hadamard might be another one to
look at but harder to understand and implement efficiently.

It will really hinge on how noisy the data channel is. Can you not
subvert a V90 modem chip at each end and send the data that way?

--
Regards,
Martin Brown

Re: Error correction in short packet.

<t653gs$12rn$1@gioia.aioe.org>

 copy mid

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

 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 10:43:54 +0100
Organization: Aioe.org NNTP Server
Message-ID: <t653gs$12rn$1@gioia.aioe.org>
References: <t634rq$8ml$1@dont-email.me> <jelrp6F66fiU1@mid.individual.net>
<t650re$76f$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="35703"; 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 09:43 UTC

On 19/05/2022 09:58, Clive Arthur wrote:
> On 19/05/2022 04:27, Sylvia Else wrote:
>> On 19-May-22 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.
>>>
>>
>> Even if you had a 16 bit value that told you which two bits were
>> wrong, you'd then have to make use of that information to flip the
>> incorrect bits. That doesn't sound like small number of LUTs.
>>
>> Is your channel really that noisy that you cannot just discard bad
>> packets?
>>
>> Sylvia.
>
> I don't have control over the transmission path, it may be noisy, it may
> not - it's not a fixed installation.  I want to get the best shot at
> correcting errors within my fixed constraints, even a single bit EDC
> would be useful.  I can't request a resend, and sending multiple copies
> restricts bandwidth too much.
>
> Of course, there comes a point when it just won't/can't work.
>
> I do know that a CRC approach is easy to implement from the POV of error
> detection.  I also know that this could detect and correct at least a
> single bit error, but I don't know if there's a quick and easy way of
> finding the bad bit.
>
> And to be honest, much of the maths associated with EDC is beyond me at
> the moment.

I vaguely recall a trick using parity over an orthogonal basis set of
Walsh functions (much like Hadamard) that could be designed so that the
computed signature of the data received gave you the index of the bad
bit. Described in more detail here.

https://en.wikipedia.org/wiki/Hamming_code#General_algorithm

It seems Hamming(127,120) is what you want. Now just a SMOP!
Or 2x Hamming(63,57) applied to 64 bits (one bit left hanging).

--
Regards,
Martin Brown

Re: Error correction in short packet.

<t654bf$auq$1@dont-email.me>

 copy mid

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

 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 02:58:00 -0700
Organization: A noiseless patient Spider
Lines: 23
Message-ID: <t654bf$auq$1@dont-email.me>
References: <t634rq$8ml$1@dont-email.me>
<tq7a8htn5hae97crdtj6lep2dnlop2ag5s@4ax.com>
<16f0525496e050be$77$3423140$c2965a1b@news.newsdemon.com>
<ckta8h9etghmhefrmops0bufpaemai5b6a@4ax.com> <t650fs$1l2n$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 09:58:07 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="aa343c9a4b693c96437eb2de260e2439";
logging-data="11226"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/qVPsY1/ZrP6JT2jHCg8IK"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.1.1
Cancel-Lock: sha1:s55kyf6/zc80O9jGN28ltz8liLw=
In-Reply-To: <t650fs$1l2n$1@gioia.aioe.org>
Content-Language: en-US
 by: Don Y - Thu, 19 May 2022 09:58 UTC

On 5/19/2022 1:52 AM, Martin Brown wrote:

> It should be possible to correct any single bit error and detect any double bit
> error in the data stream with just 75% overhead even with a simple Hamming code
> - just under double the size of the raw data.

It would be wasteful to encode each byte individually -- though it gives
greater detection/correction "at the byte level" -- due to the excess overhead
it introduces.

Instead, treat the entire 14-byte message as a 112 bit datum. Add 7 parity
bits and you can correct a single bit error in the resulting 119 bit "augmented
message". Use the remaining (8th) bit -- assuming the underlying protocol
is byte-based and not bit-oriented -- and you can detect two errors.

> Better EC encodings exist but they require more horsepower.

Hamming can be decoded with a polynomial-per-parity-bit (i.e., 8 in this case)
all "watching" the same deserializer. The syndrome then "points" to the bit
that is in error (if only one) and, as bits are only bivalued, you just have
to toggle that bit to fix it.

Detecting a *second* error is where it gets a bit trickier...

Re: Error correction in short packet.

<t65etp$boo$1@gioia.aioe.org>

 copy mid

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

 copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!aioe.org!HQqjtrwtWYY0cW+c5n/Byw.user.46.165.242.75.POSTED!not-for-mail
From: keegan.m...@hotmail.com (Keegan Major)
Newsgroups: sci.electronics.design
Subject: Re: Error correction in short packet.
Date: Thu, 19 May 2022 12:58:33 -0000 (UTC)
Organization: Aioe.org NNTP Server
Message-ID: <t65etp$boo$1@gioia.aioe.org>
References: <t634rq$8ml$1@dont-email.me> <jelrp6F66fiU1@mid.individual.net> <t650re$76f$1@dont-email.me>
Injection-Info: gioia.aioe.org; logging-data="12056"; posting-host="HQqjtrwtWYY0cW+c5n/Byw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
X-Notice: Filtered by postfilter v. 0.9.2
 by: Keegan Major - Thu, 19 May 2022 12:58 UTC

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?

Re: Error correction in short packet.

<t65geq$tg3$1@dont-email.me>

 copy mid

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

 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: Thu, 19 May 2022 14:24:40 +0100
Organization: A noiseless patient Spider
Lines: 17
Message-ID: <t65geq$tg3$1@dont-email.me>
References: <t634rq$8ml$1@dont-email.me> <t63dv6$f5c$1@dont-email.me>
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: Thu, 19 May 2022 13:24:42 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="f408969eca6ca0381ade7cf9b95a2e77";
logging-data="30211"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19ycRoixU1Hn8n4A0f8cvcI/LB0jSniT7E="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Cancel-Lock: sha1:flLgFcVvHeYvRuBCuxKDFGgmxhI=
In-Reply-To: <t63dv6$f5c$1@dont-email.me>
Content-Language: en-GB
 by: Clive Arthur - Thu, 19 May 2022 13:24 UTC

On 18/05/2022 19:29, Martin Rid wrote:

<snip>
>
> Well Reed-Solomon would do what you want. Problem is the crc can
> not fix the errors.
>
> Cheers

CRCs can be used to correct one error provided there's not too much
data. The brute force method involves changing one bit at a time until
the CRC is correct; I don't know if there's a quicker way or if more
errors could be corrected using a suitable CRC.

--
Cheers
Clive

Re: Error correction in short packet.

<nalc8ht3kb9euvbqgskvknklakc0oakkpb@4ax.com>

 copy mid

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

 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 09:36:11 -0500
From: jlar...@highlandsniptechnology.com
Newsgroups: sci.electronics.design
Subject: Re: Error correction in short packet.
Date: Thu, 19 May 2022 07:36:14 -0700
Message-ID: <nalc8ht3kb9euvbqgskvknklakc0oakkpb@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>
X-Newsreader: Forte Agent 3.1/32.783
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 36
X-Trace: sv3-R2pDjrapj7SOBaYv7E3pLMotcnS8b0qQx6eTd5YBnolghkjGchQ9x4h9NSwrFym/mZO8070T7UCv4Ti!cFum2By1Xeu1MNDaHX+REFG1q5JLe4cGGpicT57d+HCZYZueTrv8HB8GoiCiKYRf8jgY6ky+Ndrq!T7dSRA==
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: 2305
 by: jlar...@highlandsniptechnology.com - Thu, 19 May 2022 14:36 UTC

On Thu, 19 May 2022 12:58:33 -0000 (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?
>
>

It's normal here to get underspecified problems. Details usually
emerge, but some people do refuse to explain their top-secret
projects.

--

Anybody can count to one.

- Robert Widlar

Re: Error correction in short packet.

<69e5ec0a-ba86-4e49-aafb-f8a65998ef4cn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: sci.electronics.design
X-Received: by 2002:a05:6214:d0c:b0:45b:3c7:fd68 with SMTP id 12-20020a0562140d0c00b0045b03c7fd68mr4201812qvh.77.1652971246159;
Thu, 19 May 2022 07:40:46 -0700 (PDT)
X-Received: by 2002:a25:2358:0:b0:64d:6ec7:3014 with SMTP id
j85-20020a252358000000b0064d6ec73014mr4626292ybj.141.1652971245970; Thu, 19
May 2022 07:40:45 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.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 07:40:45 -0700 (PDT)
In-Reply-To: <nalc8ht3kb9euvbqgskvknklakc0oakkpb@4ax.com>
Injection-Info: google-groups.googlegroups.com; posting-host=130.225.196.250; posting-account=mW5JKwkAAAAMyuWOVeLp8yffyAkVx0g7
NNTP-Posting-Host: 130.225.196.250
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>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <69e5ec0a-ba86-4e49-aafb-f8a65998ef4cn@googlegroups.com>
Subject: Re: Error correction in short packet.
From: langw...@fonz.dk (Lasse Langwadt Christensen)
Injection-Date: Thu, 19 May 2022 14:40:46 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2544
 by: Lasse Langwadt Chris - Thu, 19 May 2022 14:40 UTC

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/

Re: Error correction in short packet.

<ksmc8hpu9r3f9d9l6i0id6p1888oajvc59@4ax.com>

 copy mid

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

 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:03:43 -0500
From: jlar...@highlandsniptechnology.com
Newsgroups: sci.electronics.design
Subject: Re: Error correction in short packet.
Date: Thu, 19 May 2022 08:03:46 -0700
Message-ID: <ksmc8hpu9r3f9d9l6i0id6p1888oajvc59@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>
X-Newsreader: Forte Agent 3.1/32.783
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 46
X-Trace: sv3-hFRXRSSLbKqO26IYV8CMNi3/aOLPqEikAlEWt6j6b3Ae2ixjcHBCg7nbPvCiKoyTBJI86Sxudl/ovZE!MmN1GirtH6a88UwBaH0x4DxHIm8DJsR9Ke5w39MJY8PwQJt1NCeVQ/ppJ6eQjkVToV9ijXTmwlFi!zd5Wmw==
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: 2888
 by: jlar...@highlandsniptechnology.com - Thu, 19 May 2022 15:03 UTC

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.

--

Anybody can count to one.

- Robert Widlar

Re: Error correction in short packet.

<t65mrr$bup$1@gioia.aioe.org>

 copy mid

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

 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 17:14:02 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t65mrr$bup$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>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="12249"; 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 15:14 UTC

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. Ideas are cheap. Realizing them is costly.
You'll want to be selective.

Jeroen Belleman

Pages:123
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor