View source for Talk:Forward error correction

{{merged-to|Error correction code#Forward error correction|19 September 2020}}
{{WikiProject banner shell|1=
{{WikiProject Telecommunications }}
{{WikiProject Computer science }}
{{WikiProject Mathematics}}
{{WikiProject Computing |software=y |network=y |hardware=y }}
}}
{{Copied |from=interleaving |from_oldid=553160018 |to=forward error correction |diff=https://en.wikipedia.org/w/index.php?title=Forward_error_correction&diff=553162734&oldid=553141105 }}

== Software patents ==

I have heard that some methods for FEC are covered by [[software patent]]s. Does anyone know if this is (still) the case? If so, it should probably be mentioned in the article. [[User:Haakon|Haakon]] 13:06, 17 Jan 2005 (UTC)

== Weird ==

From the article:

'''The original information may or may not appear in the encoded output; codes that include the unmodified input in the output are systematic, while those that do not are nonsystematic.'''. 

Ehm, if the original information did not appear in the encoded output, then what sense should such an encoded output make? We couldn't reconstruct the original information back from the encoded output... or do you mean "the original information may not appear in '''plain text''' in the encoded output"?

: Yes, exactly -- the original sequence of bits always occurs in the output of a systematic encoder, but the original sequence of bits almost never occurs in the output of a nonsystematic decoder (although, of course, the ''information'' can still be extracted). Please improve the article to make this easier to understand. --[[User:75.37.227.177|75.37.227.177]] 07:31, 16 July 2007 (UTC)

: Think you mean that the original sequence of bits almost never occurs in the output of a nonsystematic _encoder_.  The job of the decoder is to extract the original information, perhaps correct it, and flag whether (uncorrectable) errors have occurred.  <span style="font-size: smaller;" class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/139.95.251.21|139.95.251.21]] ([[User talk:139.95.251.21|talk]]) 21:58, 14 September 2011 (UTC)</span><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->

== Incomplete text ==
From the article:
'''Nearly all block codes apply the algebraic properties of'''.
The algebraic properties of what?

'''[Turbo Codes] perform to within a fraction of a decibel of the Shannon limit.'''
Does that mean it is even below the Shannon limit ("just a fraction of the Shannon limit"), or very close to it, but still above it?

:''-no, it approaches the Shannon limit but can not surpass it (very close to it, but still above it)'' 16:28, 7 January 2006 (UTC)

==What is forward?==
What is so "forward" on the "forward error correction" codes?

Thanks for your help, --[[User:Abdull|Abdull]] 05:29, 16 October 2005 (UTC)

:In this context, ''forward'' refers to when you can start performing the error correction: you can correct bits "going forward  from here". Some error correction algorithms require te entire message to be received in order for the ECC algorithm to be applied to it. FEC algorithms generally allow you to fix errors as the message comes in, bit by bit, rather than analysiing the entire message. A general ECC algorithm may require looking at "future" bits, yet to be received, as well as "past" bits, to correct the current bit. The [[Viterbi algorithm]] is famous in that it took a particularly strong form of ECC, and got rid of the part that depended on future, as-yet-unrecieved bits. [[User:Linas|linas]] 17:40, 26 May 2006 (UTC)

I've heard an entirely different definition of what "forward" means. I've been told that "forward" refers to the direction of transmission: "forward error correction" techniques allow the receiver to correct errors, even though all communication goes in the "forward" direction from the transmitter to the reciever.

The only other kind of error correction technique, "repeat request" ([[ARQ]]), requires 2-way communication, both the "forward" and "reverse" directions.

Certainly the Viterbi algorithm is "forward" under both these definitions.
I would call [[Cross-interleaved Reed-Solomon coding]] a kind of "forward error correction", even though it requires analyzing an entire 28 byte block (or is it 784 bytes?) before fixing an error in the first bit.
If you want a narrower definition of FEC that excludes Reed-Solomon coding, then what would you prefer to call the wider group of error correction codes that includes Reed-Solomon codes?
--[[User:68.0.120.35|68.0.120.35]] 22:08, 23 May 2007 (UTC)

Well, I disagree with the above explanation for ''forward'' ( you can correct bits "going forward  from here" ). Using this explanation, turbo codes have nothing to do with FEC, but they are discussed in this article.

== Merge? ==

* I vote '''Do not merge''' - the article on touches upon Forward Error Correction and its applications, and can be expanded considerably.  Rather than mergeing into a general Error detection and correction article, I believe it is correct to split this topic out.  When treated properly, this article alone will generate several sub-articles. [[User:West London Dweller|WLD]] 20:26, 5 February 2006 (UTC)

* I agree: '''Do not merge''', but clean this article up so that it is more clear about the difference between forward error correction and error correction. [[User:Mangojuice|Mangojuice]] 19:13, 3 March 2006 (UTC)

* '''Do not merge'''. FEC is only one type of ECC; there are many types of ECC.  [[User:Linas|linas]] 17:34, 26 May 2006 (UTC)

== Retransmission !? ==

I reverted the recent change about "retransmission"; the concpet of "retransmission" is a very different concept, and it only applies to the the retransmission of entire messages or packets. Its at a whole different level in the communications process, its rather totally unrelated. By contrast, in FEC, there's usually no real "packet" or message boundaries, there's just a stream of incoming bits.

The improtant distinction here is between forward correction, and plain-old bi-directional correction, such as CRC.  In CRC, you need to have *all* of the bits of the packet received, so that you can compute the CRC of the whole packet.  The difference between forward corection and plain-old correction is that in forward correction, it is only the bits in the past (the bits to the "left" of "here") that are used to correct the "current" bit.  In plain-old or "bi-directional" correction, bits both to the left and to the right are used to come up with the correct message.  [[User:Linas|linas]] 18:44, 26 May 2006 (UTC)

:I re-wrote again.  Perhaps we can work together to improve this article? We need to be clear about the distinction between error-'''detecting''' codes (such as CRC), error-detecting & '''correcting''' codes (such as Hamming), and Forward Error Correction codes. The 'simple' example of a FEC needs improving as well, as the example is actually a Hamming code (I believe) - my fault, as I put it there - if you have a simple example of a FEC, then by al means put it in. [[User:West London Dweller|WLD]] 19:32, 26 May 2006 (UTC)

:: Oh - and it's worth pointing out that FECs remove the need for retransmissions - which is especially important in Deep-space missions, and broadcast applications, where re-transmissions are infeasible.  Is there an example of FECs being used in VoIP i wonder - it should be a good area to use them in, so long as the latency of the FEC process is not too high.  On another note, you used terms like 'more effective','fast' & 'lightweight', which need qualifying - more effective - how? fast - in what way? lightweight - in what way.  Regards, [[User:West London Dweller|WLD]] 19:37, 26 May 2006 (UTC)

::: I see several people *propose* using FEC in VOIP: [http://www.commsdesign.com/showArticle.jhtml?articleID=16505914], [http://www.springerlink.com/content/930294t1j4t56375/], [http://portal.acm.org/citation.cfm?id=507681&jmp=cit&dl=GUIDE&dl=Portal], and a few products that say they implement FEC in VOIP: [http://www.mapleleaf-technologies.com/webstore/multitech_gateways.php]

::: I see one proposal that seems to simply blindly send each packet of VOIP data twice [http://www.freepatentsonline.com/20040008667.html], hoping that at least one will make it through. The nice thing about this idea is that it looks like it is backwards-compatible with systems that don't use it -- standard UDP will ignore duplicate packets; and if the first one doesn't make it, UDP will accept the second one. This "forward error correction" article needs to distinguish that sort of "blindly send" thing from the "retransmission" used in a [[ARQ]] system.

::: To repeat [[Talk:Forward_error_correction#What_is_forward.3F]], my understanding is that "bi-directional correction, such as CRC" is a synonym for [[ARQ]]. The [[error detection and correction]] explicitly states that there are only 2 kinds of error correction, "[[automatic repeat-request]]" and "error-correcting code". Since "[[error-correcting code]]" currently redirects to "forward error correction", if one is a subset of, or "distinct from" the other, this article needs to make that clear. As far as I can tell from the "error detection and correction" article and the "forward error correction" article, "forward error correction", "error-correcting code", and "systems that can correct errors without ever sending feedback back to the source" are all synonyms. --[[Special:Contributions/75.19.73.101|75.19.73.101]] ([[User talk:75.19.73.101|talk]]) 19:00, 13 December 2007 (UTC)

== Most recent development? ==

The article says:

The most recent (early 1990s) development in error correction is turbo coding,


Have their been any other major developments since that or are their likely to be any more in the future?

--[[User:Timmywimmy|Timmywimmy]] 02:59, 13 July 2006 (UTC)

You can refer to 
http://www.ietf.org/html.charters/rmt-charter.html
--[[User:Sireesht|Sireesh]] 04:41, 19 December 2006 (UTC)

== Relevance of reference ==

The edit dated 29 July 2006 added the following citation:

*{{cite web
 | last = 
 | first = 
 | authorlink = 
 | coauthors = 
 | year = 2006
 | url = http://plus.maths.org/latestnews/jan-apr06/sudoku/index.html
 | title = Forget Sudoku and smile for the camera
 | format = 
 | work = 
 | publisher = 
 | accessdate = 5 December 2006
}}

While I find this article very interesting, I don't see a clear connection to FORWARD error correction. Am I missing something? [[User:Ged Davies|Ged Davies]] 17:37, 28 February 2007 (UTC)

I agree -- this particular article doesn't say anything about errors, much less error correction. So leave it out. (Or move it to the [[phase problem]] article).

However, since Sudoku is much more widely known than error correction codes, Sudoku might make a good analogy for a "layman's introduction" [[Talk:Forward_error_correction#Simplified_Layman.27s_terms_explanation]].

The [[Turbo_code#Solving_hypotheses_to_find_bits]] says that correcting errors in interleaved turbo codes is analogous to solving Sudoku.
The [[Latin square]] article claims that "Latin squares ... have applications in ... in error correcting codes. ... The popular Sudoku puzzles are a special case of Latin squares".
Is it merely alluding to the previous interleaved turbo code, or is there a more general application of Latin squares to error correcting codes -- not merely an analogy?
--[[Special:Contributions/75.19.73.101|75.19.73.101]] ([[User talk:75.19.73.101|talk]]) 19:00, 13 December 2007 (UTC)

== Dubious ==
== MLC NAND ==

The article currently claims
:''"More dense multi level cell (MLC) NAND requires stronger multi-bit correcting ECC such as BCH or Reed-Solomon"''

I think this is incorrect.
If I read [http://www.electronicproducts.com/print.asp?ArticleURL=toshiba.apr2004.html "Choosing flash memory"] article correctly,
it seems to say that SLC may be reliable enough to not need any error correction (in some applications).
In contrast, MLC has a much higher error rate.
''"However, this is easily compensated for by using error detection and correction codes (EDC). System designers have long been aware of the benefits of using EDC to detect and correct errors in systems using Hamming codes (common in memory subsystems) and Reed Solomon codes (common in hard drives and CD-ROMs)."''

As far as I can tell (original research), single-bit-correcting Hamming codes should work fine with MCL flash, as long as the multiple bits stored in a single cell are spread across *different* Hamming code words.
--[[User:68.0.120.35|68.0.120.35]] 22:08, 23 May 2007 (UTC)

While it is true that SLC NAND has a generally lower bit error rate than MLC NAND, both technologies' bit error rates are dramatically affected by how the data is accessed. If the point here is to give some examples of several types of FEC, and their applications, perhaps this paragraph could be made more general - to indicate that Hamming Code is suitable for relatively low bit error rate channels, while other schemes such as Reed-Soloman are better suited to higher bit error rate channels. I guess what I am trying to suggest is that NAND memory technology is changing rapidly - potentially invalidating this paragraph. Just a thought...
[[User:Tpfinkbeiner|Tpfinkbeiner]] ([[User talk:Tpfinkbeiner|talk]]) 18:23, 13 February 2011 (UTC)

: Just added 2 refs (eeasia and note by one of flash memory supplier). They says that SLC often uses Hamming; and MLC often uses RS or BCH. May be we should rewrite the phrase as: "More dense multi level cell (MLC) NAND ''often used with'' stronger multi-bit correcting ECC such as BCH or Reed-Solomon"

:: Thank you very much for the references, A5b. --[[User:DavidCary|DavidCary]] ([[User talk:DavidCary|talk]]) 19:49, 10 August 2013 (UTC)

== FEQ vs. FEC ==

What is FEQ?
Clicking on [[FEQ]] doesn't tell me, because '''FEQ''' currently redirects to '''forward error correction''', which never mentions "FEQ".
--[[User:75.37.227.177|75.37.227.177]] 07:31, 16 July 2007 (UTC)

: FEQ isn't an abbreviation that matches anything to FEC that I know of or can find a reference to.  I just proposed FEQ for deletion. [[User:Danoelke|Danoelke]] ([[User talk:Danoelke|talk]]) 15:46, 27 February 2008 (UTC)

:: The section on ''Averaging noise to reduce errors'' still uses the term FEQ without explanation. Should each instance of FEQ be replaced with FEC? [[Special:Contributions/83.104.249.240|83.104.249.240]] ([[User talk:83.104.249.240|talk]]) 20:26, 13 November 2008 (UTC)

== Simplified Layman's terms explanation ==
This article needs a simple layman's terms explanation.  I wrote the following based on how I understand error correction to work, but I'm far from an expert.  So I'm gonna post my proposed article text here and let someone else post it once an expert confirms the validity.

----
Error correction works sort of like a game of sudoku.  If a single number is missing from any random location on nearly complete sudoku board, then any one of the relational number rules of sudoku provide all the extra information you need to correctly fill in that particular missing number box back to its intended value.  However, as more and more numbers are missing you need to know more and more different sudoku rules in order to recreate the missing numbers.  

So the original data to be kept corrected of errors is like the numbers you start with on an incomplete sudoku board, and the additional error correction parity files you use to correct errors in your data back to the original set are like the rules you use on a sudoku board to fill in the missing number squares back to their intended values.  

If too many squares on your sudoku board are missing (i.e. there are too many errors in your data) then the rules of sudoku don't give you enough information to fill in the missing numbers (i.e. the parity files don't contain enough extra information to recreate the errors in your data).  But if you knew additional sudoku rules (i.e. had more parity files) then you could recreate the correct set of numbers on your sudoku board (i.e. you could recreate the correct data in the portions which contain errors).

---

If that is approximately correct, then please add this text to the article!  =)  <small>—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/67.101.31.49|67.101.31.49]] ([[User talk:67.101.31.49|talk]]) 08:40, 19 September 2007 (UTC)</small><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

Yes, that sounds great.
--[[Special:Contributions/75.19.73.101|75.19.73.101]] ([[User talk:75.19.73.101|talk]]) 19:00, 13 December 2007 (UTC)

== Rewrite ==
I think the whole article requires a rewrite.
-Muthu  <small>—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/129.107.27.193|129.107.27.193]] ([[User talk:129.107.27.193|talk]]) 19:15, 30 September 2007 (UTC)</small><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

This article does poor justice to the fantastic depth and quality of the
subject. Take a look at how good Information Theory article reads.
-Muthu  <small>—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/129.107.27.193|129.107.27.193]] ([[User talk:129.107.27.193|talk]]) 19:20, 30 September 2007 (UTC)</small><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

Dear neighbor,

Would you be so kind as to point out a few ways the article could be improved?
Is something missing? Please add it.
Unnecessarily complicated-sounding?
Or ... something else?
--[[Special:Contributions/75.19.73.101|75.19.73.101]] ([[User talk:75.19.73.101|talk]]) 19:00, 13 December 2007 (UTC)

I agree that this article needs (almost) a complete rewrite. Missing:
* History
* Reference to early theory on [[BCH code]]s, [[repetition code]]s
* Introduction to Shannon's work and [[Shannon's channel coding theorem|channel coding theorem]], beginning of [[Information theory]]
* [[Hamming code]]s
* Principle of [[sphere-packing]] in codes, [[Hamming distance]], minimum distance code, properties regarding error correction and detection
* Various useful/popular bounds, such as [[Hamming bound]], [[Singleton bound]], [[Gilbert–Varshamov bound]], etc.
* Problem of [[maximum likelihood decoding]]
* Introduction to theory of [[linear code]]s
* Classes of codes, and their subset relation: e.g., block codes -> linear codes -> cyclic codes -> BCH codes -> RS codes

I'm sure I'm still missing a lot, but this came to my mind right away... Anyway, I'm sure I'll not be able to tackle this (rather big) task anytime soon, but maybe someone else will give it a shot.

Cheers, [[User:Nageh|Nageh]] ([[User talk:Nageh|talk]]) 22:26, 9 January 2010 (UTC)

== 2/3 FEC and 3/4 FEC ==

The acronym FEC is usually accompanied by a pair of numbers denoting a fraction or ratio. Shouldn't this be explained in the article? [[Special:Contributions/83.104.249.240|83.104.249.240]] ([[User talk:83.104.249.240|talk]]) 20:32, 13 November 2008 (UTC)

== list of error-correcting codes ==

Recently, a list of codes was moved from[http://en.wikipedia.org/w/index.php?title=Error_detection_and_correction&diff=next&oldid=336176585] the "[[error detection and correction]]" article to[http://en.wikipedia.org/w/index.php?title=Forward_error_correction&diff=next&oldid=334740042] the "[[forward error correction]]" article.

While I think this edit improved both articles, I think [[Wikipedia:WikiProject Laundromat]] and [[Wikipedia:Embedded list]] seems to discourage such lists, and I'm thinking about deleting that list entirely.

Is there any good reason to manually maintain that list in this article, instead of using the automatically-updated category mechanism -- similar to [[:Category:Checksum algorithms]]?
Is the list at [[:Category:Error detection and correction]] adequate for our readers, or should we use a more specific category for that list?
--[[Special:Contributions/68.0.124.33|68.0.124.33]] ([[User talk:68.0.124.33|talk]]) 16:45, 25 January 2010 (UTC)

:The list was moved here temporarily, as the article needs a rewrite anyway. However, do not just delete the list, but rather move it to a list article like "List of forward error correction codes". Also, an appropriate category would be "Forward error correction codes", and be defined as a sub-category of "Forward error correction", which itself is a sub-category of [[:Category:Error detection and correction]]. Category "Forward error correction" would include all the theoretical background articles on the topic. I would be glad if you could do these changes, and provide a link to the list article in the "See also" section. [[User:Nageh|Nageh]] ([[User talk:Nageh|talk]]) 22:23, 25 January 2010 (UTC) 12:53, 26 January 2010 (UTC)

:Also, all the articles referenced in the list should be moved to the new category from [[:Category:Error detection and correction]]. [[User:Nageh|Nageh]] ([[User talk:Nageh|talk]]) 22:26, 25 January 2010 (UTC)

== Codeword confusion ==

Let's get this straight.

One interleaving example cites "aaaa, eeee, ffff, gggg" as codewords. i.e. a codeword is represented as four consecutive letters.

Another example cites "cddd" as a codeword. i.e. the codeword is inexplicably made of different letters. Apparently this is "correct".

Since "codeword" seems to be randomly defined, there needs to be an explanation of these examples, otherwise it makes no sense.

What's the significance of groups of four letters if you can just make up whatever boundaries you like? If the letter boundaries aren't codeword boundaries, then what are they?

Ghiraddje 17:59, 7 May 2014 (UTC)  <small><span class="autosigned">—&nbsp;Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Ghiraddje|Ghiraddje]] ([[User talk:Ghiraddje|talk]] • [[Special:Contributions/Ghiraddje|contribs]]) </span></small><!-- Template:Unsigned --> <!--Autosigned by SineBot-->

:Yeah, I read it that way too. I've changed it again, with elaboration in the text. —[[User_talk:Quondum|''Quondum'']] 22:05, 7 May 2014 (UTC)

== Merge? ==

I suggest merging [[channel code]] into [[forward error correction]].

The Wikipedians who wrote [[coding theory]], [[forward error correction]], and [[channel coding]] already seem to think that [[channel code]] is a synonym for "forward error correction code".

Perhaps the difference, if any, can be summarized in a couple of paragraphs in the merged article.
--[[User:DavidCary|DavidCary]] ([[User talk:DavidCary|talk]]) 07:52, 31 January 2015 (UTC)

*'''Oppose''' - It appears that [[Forward error correction]] is an instance of a [[Channel code]]. The other significant instance is [[Automatic repeat request]], this according to this article. The refs actually seem to indicate otherwise and that is a larger problem that should be addressed before any merge is considered further. ~[[user talk:Kvng|KvnG]] 17:15, 6 February 2015 (UTC)

:: [[user talk:Kvng|KvnG]], my understanding is that automatic repeat request is *not* a channel code. The first reference in the [[coding theory]] ( Irvine and Harle 2002 ), if I'm reading page 4 correctly, defines "channel code" in a way that excludes automatic repeat request. What are the next steps towards solving the larger problem? --[[User:DavidCary|DavidCary]] ([[User talk:DavidCary|talk]]) 13:26, 20 August 2019 (UTC)

== backward error correction ==

::Is there such a thing as a "backward error correction" code, that would contrast with this article's subject? [[User:Jimw338|Jimw338]] ([[User talk:Jimw338|talk]]) 23:28, 8 September 2016 (UTC)

::: [[User:Jimw338|Jimw338]], my understanding is that there are 2 techniques for [[error correction]] of a message. Both techniques send a message in the "forward" direction. The automatic repeat request (ARQ) technique uses acknowledgements (ACKs). Those ACKs must travel over a "back channel" ("[[reverse channel]]") in the opposite direction as the message. I speculate that the "forward error correction" technique has that name because it is the only kind of error correction technique doesn't require a "back channel"; both the message and all the extra correction information go in the same "forward" direction.
::: (If anyone has a reference that explains the origin of the term, *especially* if it's different from my speculation, please tell us). --[[User:DavidCary|DavidCary]] ([[User talk:DavidCary|talk]]) 13:26, 20 August 2019 (UTC)

== Fire codes ==

There is discussion in a newsgroup about fire codes using in disks such as the IBM 3330 and DEC RP06.  It seems to be a form of FEC that is easier to process than some more modern ones. (That is, using late 1960's technology.)  I don't see anything here about it, though. Does it have a different name? [[User:Gah4|Gah4]] ([[User talk:Gah4|talk]]) 00:26, 29 July 2015 (UTC)

== External links modified ==

Hello fellow Wikipedians,

I have just modified one external link on [[Forward error correction]]. Please take a moment to review [https://en.wikipedia.org/w/index.php?diff=prev&oldid=803797912 my edit]. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit [[User:Cyberpower678/FaQs#InternetArchiveBot|this simple FaQ]] for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20070519161253/http://www.st.com/stonline/products/literature/an/10123.htm to http://www.st.com/stonline/products/literature/an/10123.htm

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

{{sourcecheck|checked=false|needhelp=}}

Cheers.—[[User:InternetArchiveBot|'''<span style="color:darkgrey;font-family:monospace">InternetArchiveBot</span>''']] <span style="color:green;font-family:Rockwell">([[User talk:InternetArchiveBot|Report bug]])</span> 18:16, 4 October 2017 (UTC)

== Misleading title - split the article ==

The title "forward error correction" is a process that may use an ECC - most of the article is about ECC.  Also the article uses the accroymn FEC where it really means ECC, or at best FECC, the latter not being in the IEEE dictionary and far less in use per a Google search (not necessarily a reliable source).  Also note that the term ECC goes back to Hamming 1950 and Shannon 1948 discusses the correction of errors without once using the term "forward."  I don't know when and where the term FEC comes from, I suspect telcom but earliest cite I can find is [https://www.sciencedirect.com/science/article/pii/S0019995872900575 1972].  So it seems we have two subjects, ECC and FEC, mixed up in one article with the preponderance of the article devoted to ECC. I suggest the simplest fix is to split the articles into an ECC article and an FEC article with the latter being relatively short, almost a dictionary entry.  If nothing else all the FECs that really mean ECC need to be changed.  [[User:Tom94022|Tom94022]] ([[User talk:Tom94022|talk]]) 17:06, 2 April 2018 (UTC)

: If ECC and FEC are different enough to be "two subjects", could someone please write a sentence or two clearly explaining the difference between them? [[User:Tom94022|Tom94022]]? Thank you. --[[User:DavidCary|DavidCary]] ([[User talk:DavidCary|talk]]) 13:26, 20 August 2019 (UTC)

::Above there is discussion about VoIP, sending each packet twice.  It seems to me that is FEC without ECC. (Or, sending duplicate packets is a degenerate case of ECC, with no actual coding.)  I think that means that separate article are fine, but we should be careful as to what goes where.  FEC should maximize the idea of the forward part (mostly not requiring requests or waiting for retransmission) and minimize the ECC part.  If that makes FEC too small, though that doesn't seem so likely, then consider a merge.  Is there a suggested minimum for article size?  [[User:Gah4|Gah4]] ([[User talk:Gah4|talk]]) 06:52, 24 August 2019 (UTC)

== Merger proposal ==
{{Discussion top|result=To '''merge''' [[Forward error correction]] into [[Error correction code]]; synonyms with overlapping meaning used differently in different fields; differences best discussed on one page. [[User:Klbrain|Klbrain]] ([[User talk:Klbrain|talk]]) 17:47, 19 September 2020 (UTC)}}
See: [[Talk:Forward_error_correction#Misleading_title_-_split_the_article|Misleading title - split the article, above]] for backround information.

After a little further reserarch I think FEC is the application of [[Error-correcting code|ECC]]s so that this article should be merged into the [[Error-correcting code|ECC article]] and replaced by a redirect and perhaps a line in the main article.  Alternatively this could be reduced to a single sentance pointing to the main article [[User:Tom94022|Tom94022]] ([[User talk:Tom94022|talk]]) 17:39, 20 August 2019 (UTC)

* ''' Oppose ''' - FEC is a distinct technology, and one which is gaining in usage and popularity.  The new web standard ([[HTTP/3]]) is based on [[QUIC]], which includes FEC as part of the spec, as do several other recent RFCs.  True, it is an application of ECC.  [[Espresso]] is an application of [[coffee beans]], but both deserve separate articles. [[User:Gladrim|Gladrim]] ([[User talk:Gladrim|talk]]) 08:51, 23 August 2019 (UTC)
::{{ping|Gladrim}} I'm not sure it is distinct as much as it is just symantics with the terms more or less used interchangeably as in this article.  Can u identify an use of ECC not in a forward sense?  But you have a point about [[Espresso]].  Since most of this article is about ECC do u oppose moving what is about ECC into that article and leaving on FEC material in this article? After all there appears to be very little overlap between the [[Espresso]] and [[coffee beans]] articles with only a single link in the [[Espresso]] article pointing to  [[coffee beans]].  [[User:Tom94022|Tom94022]] ([[User talk:Tom94022|talk]]) 18:06, 23 August 2019 (UTC)
:::{{ping|Tom94022}} At the moment there's probably more overlap than there should be in the articles. Part of the problem is that the ECC article discusses some of the FCC applications, as well as ECC itself, and the FEC article needs some improvement.  No objection from me to moving the ECC stuff and leaving the FEC (applied) bits.  If I get some time I'll see what I can do to improve and extend the FEC article. [[User:Gladrim|Gladrim]] ([[User talk:Gladrim|talk]]) 17:41, 25 August 2019 (UTC)
::::{{ping|Gladrim}} Actually I think the fact that the ECC article discusses some of the ECC applications is not as much of a problem as it is a semantical issue arrising from different usages in different industries.  The storage industry I am pretty sure never used the term FEC to describe the error correction they routinely perform, they appended error correction codes to blocks of data and then used the codes to correct the data -FEC as defined.  I don't know when and where the term FEC comes from, I suspect telcom and the earliest cite I can find is [https://www.sciencedirect.com/science/article/pii/S0019995872900575 1972].  "Error correction" as a term of the art which used an ECC (Fire code to be specific) goes back to as early as the IBM 3330 HDD circa 1970.  In the end I think FEC and error correction are different terms in different art for the same thing.  I'm not sure how to fix this in the several articles involved.  My first thought was to merge but now I'm thinking truncation of this article. [[User:Tom94022|Tom94022]] ([[User talk:Tom94022|talk]]) 22:46, 25 August 2019 (UTC)
::::A little more digging and I found FEC used in context of 2400 baud modems circa 1969.  Shortly there after the storage folks began using "error correction" to describe the same process.  [[User:Tom94022|Tom94022]] ([[User talk:Tom94022|talk]]) 23:23, 25 August 2019 (UTC)
:::::{{ping|Tom94022}} I've almost always encountered the term FEC in reference to communication protocols (eg. computer networks).  I still think of ECC as referring to the codes, and FEC as their application in protocols.  Hardware folk seem to use ECC as a term for both. [[User:Gladrim|Gladrim]] ([[User talk:Gladrim|talk]]) 16:02, 27 August 2019 (UTC)
::::::{{ping|Gladrim}} Speaking for both hardware and software folks on the memory and storage side, they first used EDCs for error correction calling it retry and then went to ECCs for error correction (including retry if the ECC failed) and called it error correction.  They did not use a back channel.  So we seem to have an industry semantics problem as illustrated in this table
{| class="wikitable" style="margin-left: auto; margin-right: auto; border: none;"
|+ Error detection and correction semantics
|-
| Memory and Storage Industry || Data Communications Industry
|-
| Retry || ARQ
|-
| Error correction || FEC
|-
| Retry upon ECC failure || Hybrid ARQ
|}
::::::Maybe what I need to do is find an RS for the storage/memory semantics and clarity the distinction in this and related articles, along with moving the ECC detail out of this article. [[User:Tom94022|Tom94022]] ([[User talk:Tom94022|talk]]) 18:14, 27 August 2019 (UTC)

:::::::In the case of communications, sometimes you can request retransmission. That is usual for TCP/IP. It seems that is usually not called forward. In the case of RAM, tape, or disk, you can retry the read, which sometimes is successful.  (Dirt on the tape, for example.) That might also not be called forward.  One that I am not sure about reading the above, I believe some early tape systems used a longitudinal parity character. In the case of one bit error, that, along with the character parity bits can find the exact bit.  Otherwise, it seems to me that forward means you already have all you need and don't have to request, retry, or reread anything. As I understand it, FEC is not used for Ethernet, as the reliability (with collision detect and retransmission) is high enough not to make it worthwhile.  I believe it is used for power-line based communications systems, where line noise is high.  As well as I know, FEC is not used to describe ECC for semiconductor or magnetic core memory, even though retry is possible. In the case of data communications, there might be a large delay to request retransmission. But also, I believe that pure (uncoded) redundancy, sending the same thing twice, is not ECC.  [[User:Gah4|Gah4]] ([[User talk:Gah4|talk]]) 21:13, 27 August 2019 (UTC)
::::::::FEC is often used where retransmission is undesirable eg. high-latency communications (space communications - Voyager uses FEC), or multicast networks where retransmission should be avoided. [[User:Gladrim|Gladrim]] ([[User talk:Gladrim|talk]]) 15:45, 28 August 2019 (UTC)

* '''Weak oppose''' - I believe the current article emphasizes the forward part, and doesn't overly discuss ECC codes. I suppose the CD error concealment process could go here, as that isn't ECC.  (That is, what to do when ECC fails.)  [[User:Gah4|Gah4]] ([[User talk:Gah4|talk]]) 07:03, 24 August 2019 (UTC)
:::As u noted [[Talk:Forward_error_correction#Fire_codes|above]] Fire Codes used in HDDs are a form of FEC.  Doesn't this suggest FEC as used herein is pretty much the same as error correction used in the context of ECC? [[User:Tom94022|Tom94022]] ([[User talk:Tom94022|talk]]) 22:46, 25 August 2019 (UTC)
* '''Support''' - Any hypothetical content that would justify its existence doesn't actually seem to be in the article. Also, a full 50% of this article's references don't ever mention the phrase, "forward error correction". [[User:Metaquanta|Metaquanta]] ([[User talk:Metaquanta|talk]]) 06:08, 22 March 2020 (UTC)
* '''Support''' - FEC and ECC are synonymous in my view. Forward error correction cannot be implemented without an error-correcting code, and an error-correcting code _is_ forward-error correction. Note that code here is not computer code, but more an algebraic (or similar) scheme for encoding/decoding. Robert McEliece used the term ECC in lectures. I personally only encountered the term FEC after moving from the west coast of the US to the east coast. 19:51, 2 July 2020 (UTC)  <!-- Template:Unsigned IP --><small class="autosigned">—&nbsp;Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/2600:1700:7AC0:A650:5DB1:9BE:D7DF:D070|2600:1700:7AC0:A650:5DB1:9BE:D7DF:D070]] ([[User talk:2600:1700:7AC0:A650:5DB1:9BE:D7DF:D070#top|talk]]) </small> <!--Autosigned by SineBot-->
{{Discussion bottom}}
:{{merge done}} [[User:Klbrain|Klbrain]] ([[User talk:Klbrain|talk]]) 17:47, 19 September 2020 (UTC)

== Satellites around Uranus? ==

The article includes the following example of a ECC benefit: "Long-latency connections also benefit; in the case of a satellite orbiting Uranus, retransmission due to errors can create a delay of five hours".  Please correct me if I'm wrong, but pretty sure there are currently no (nor have there ever been) man-made, transmitting satellites around Uranus.  What an odd example, why not cite Juno orbiting Jupiter, or the MRO orbiting Mars? [[User:Jsinnreich|Jsinnreich]] ([[User talk:Jsinnreich|talk]]) 02:29, 10 December 2023 (UTC)