Talk:Forward error correction

Software patents

I have heard that some methods for FEC are covered by software patents. Does anyone know if this is (still) the case? If so, it should probably be mentioned in the article. 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. --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. — Preceding unsigned comment added by 139.95.251.21 (talk) 21:58, 14 September 2011 (UTC)

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, --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. 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? --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. 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. Mangojuice 19:13, 3 March 2006 (UTC)

• Do not merge. FEC is only one type of ECC; there are many types of ECC. 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. 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. 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, WLD 19:37, 26 May 2006 (UTC)

I see several people *propose* using FEC in VOIP: [1], [2], [3], and a few products that say they implement FEC in VOIP: [4]

I see one proposal that seems to simply blindly send each packet of VOIP data twice [5], 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. --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?

--Timmywimmy 02:59, 13 July 2006 (UTC)

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

Relevance of reference

The edit dated 29 July 2006 added the following citation:

• "Forget Sudoku and smile for the camera". 2006. Retrieved 5 December 2006. {{cite web}}: Cite has empty unknown parameter: |coauthors= (help)

While I find this article very interesting, I don't see a clear connection to FORWARD error correction. Am I missing something? 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? --75.19.73.101 (talk) 19:00, 13 December 2007 (UTC)

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 "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. --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... 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. --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". --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. 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? 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! =) —Preceding unsigned comment added by 67.101.31.49 (talk) 08:40, 19 September 2007 (UTC)

Yes, that sounds great. --75.19.73.101 (talk) 19:00, 13 December 2007 (UTC)

Rewrite

I think the whole article requires a rewrite. -Muthu —Preceding unsigned comment added by 129.107.27.193 (talk) 19:15, 30 September 2007 (UTC)

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 —Preceding unsigned comment added by 129.107.27.193 (talk) 19:20, 30 September 2007 (UTC)

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? --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 codes, repetition codes
• Introduction to Shannon's work and channel coding theorem, beginning of Information theory
• Hamming codes
• 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 codes
• 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, 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? 83.104.249.240 (talk) 20:32, 13 November 2008 (UTC)

list of error-correcting codes

Recently, a list of codes was moved from[6] the "error detection and correction" article to[7] 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? --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. 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. 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) — Preceding unsigned comment added by Ghiraddje (talk • contribs)

Yeah, I read it that way too. I've changed it again, with elaboration in the text. —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. --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. ~KvnG 17:15, 6 February 2015 (UTC)

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? --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? Jimw338 (talk) 23:28, 8 September 2016 (UTC)

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). --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? 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 my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit 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.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 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 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. 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? Tom94022? Thank you. --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? Gah4 (talk) 06:52, 24 August 2019 (UTC)

Merger proposal

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

To merge Forward error correction into Error correction code; synonyms with overlapping meaning used differently in different fields; differences best discussed on one page. Klbrain (talk) 17:47, 19 September 2020 (UTC)

---

See: Misleading title - split the article, above for backround information.

After a little further reserarch I think FEC is the application of ECCs so that this article should be merged into the 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 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. Gladrim (talk) 08:51, 23 August 2019 (UTC)

@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. Tom94022 (talk) 18:06, 23 August 2019 (UTC)

@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. Gladrim (talk) 17:41, 25 August 2019 (UTC)

@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 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. 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. Tom94022 (talk) 23:23, 25 August 2019 (UTC)

@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. Gladrim (talk) 16:02, 27 August 2019 (UTC)

@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

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. 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. 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. 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.) Gah4 (talk) 07:03, 24 August 2019 (UTC)

As u noted 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? 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". 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) — Preceding unsigned comment added by 2600:1700:7AC0:A650:5DB1:9BE:D7DF:D070 (talk)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

  Y Merger complete. 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? Jsinnreich (talk) 02:29, 10 December 2023 (UTC)