Error Detection and Correction 3: Forward Error Correction

Sometimes, requesting that the sender retransmit data whenever there is an error is too costly, so Forward Error Correction is used. Extra information is sent along with each transmission so that certain types of errors can be fixed without requiring data to be retransmitted. This idea depends on the use of Hamming distance to assess which of several possible codewords from a dictionary was the most likely codeword originally sent. Much of this material is based on content from the book Data and Computer Communications by William Stallings.

[@TekCroach]

simple, intuitive, clear, correct, and short.... the best mix in education... thanks :)

[@alaamalek3575]

the clearest explanation for forward error correction ever

[@kateiry4719]

By the way this is the clearest explanation for forward error correction ever 👍

[@kateiry4719]

A normal person: Number of error bits Smartass scholars: *hAmmIGn d1StANcE*

[@oluwaseunoyenuga6641]

God have mercy 😂😂😂

[@ghost_riderrr]

@@oluwaseunoyenuga6641 your mom

[@adrianhartland8289]

This explanation was beautiful in it's simplicity. Thank you...

[@arty7926]

Concise and understandable explained, thank you very much.

[@dr.ahmedredhamahlous2575]

Thanks for the good simple, clear explanation

[@taqikhan5418]

good, i have a question. In case of tie in hamming distance, you said that data will be resend. Please clear that the complete data will be resend or only that part ?

[@garychap8384]

Hmmm... So, if after the sent sequence there was a final checksum of the underlying message, I'm guessing you could then meaningfully explore the possibility space. Let's say you have two ambiguous symbols A and B, where A's possibilities were hamming=2 and B's symbol were hamming=3... then perhaps you'd be able to identify some relaxation priority between A and B that helps you choose between two possible permutations that each meet the checksum - such that, it too, gets met with some least distance metric? I mean, why throw out a possibility of distance=2, just because there are two solutions of distance=1 ... it could be that neither of those d=1 solutions can meet the checksum, but the d=2 does so... or some least-work combination of symbols. Oh, wait... I think you'd also have to see if there was a low-hamming distance change to the checksum, that made the resolution of A and B easier. I mean... sent checksums are data too. So, the checksum I'm using to find a workable set of permutations has to be part of the distance-balancing metric too. Maybe the least-cost permutation involves being prepared to admit a single bit error in the checksum. Oh, man, that complicates things a little :D Now it's a fuzzy sort of search. I understand that this is only a simple example and that modern FECs are far more efficient and can achieve close to the shannon limit - but it's fun to consider how I might approach the problem of choosing between candidates once we have identified one or more ambiguous symbols using this naive codeword strategy. Oooh... I think one intuitive tweak for bursty errors would be to interleave the codewords such that any burst errors are more likely to create single-bit errors across multiple words (high recoverability) - rather than concentrating multi-bit errors in single words (low recoverability) That sounds like something worth doing! Wow, a simple but thought-provoking video :D I guess it's now time for me to write some code to simulate noisy channels of various parameterised characteristics, with "bursty" noise and single-bit error rates - and see how I'd tweak this for different channel conditions. Maybe this scheme can be made adaptive, based on how many times a minute it is forced to ask for a retransmission. A little simple math should be able to find the noise threshold at which it makes sense for the endpoints to agree a larger or smaller codeword size. Oh... I'm definitely gonna have some fun playing with this in code. If only to put off trying to tackle the scarier stuff like Reed-Solomon, LDPC and Adaptive Turbo _(I've looked... they scare me)_ : / Anyway, thanks for taking the time to make this video. It's a great starting point for inquiring minds : )

[@sunnyboy866]

A very clear and simple explanation. Thanks for the effort

[@Iplayforfood88]

Thank you for this explanation.

[@pataleno]

Great Explaination. What does it mean by FEC being 3/5 2/5 etc ?

[@ramadhan1481]

anybody have the answers?

[@ezra6094]

I think n/m means that for every n bits, an m-length codeword is used

[@gamobigz]

Hi Jacob a question. If in the case at 10:08, where a resend protocol happens. What if the resend gives the same exact errored bits or if a entirely difference sequence of bits happens? What will the FEC do then?

[@skipperry63]

Excellent explanation! Thanks!

[@DiskTuna]

Thank you for this! Could you perhaps explain how this would work for a hard drive (ECC error detection/correction)? So sector is 'protected' by ECC to detect and correct errors. But if I'd apply this method we'd need a several sectors if we'd write 11100 rather than 01 (taking codewords from your example)?

[@hyunseokjeong7994]

It was great for me. Bluetooth 5 said they used FEC - then that makes longer range, lower data rate. This video explains a lot. :-)

[@farazansari2170]

Awesomely explained Mr.Jacob. Thank a lot awesome👏🤘✌👍

[@danielahernandezprado6017]

Hi, the dictionary of code is created by the sender/receiver? Or how this dictorionary is created? Thank you for the video!

[@gayrozayppeli8431]

Yes. It's like a reference guide. You have it with you on both sides since it's to be used specifically for this; it was specifically created for this by the creator. Say for example, this is for a data transmission between two branches of a company. The company creates the reference dictionary and gives it to both branches. So don't fret too much about it(especially if you're worried about exams and all since it will be given unless you're tasked to actually make one lmao)

[@aruphareesh]

Excellent detailed and easy to understand explanation

[@seungbumyang]

Thank you for this video

[@allankyazze1]

A very simple and excellent explanation! Thank you!!!

[@COMB0RICO]

You have a talent for teaching. May the Lord Jesus Christ bless you for teaching the people.

[@COMB0RICO]

I do have one concern. Your concept of FEC is different from the one presented in Kurose&Ross's Computer Networking 5th edition. They are stating a copy of the actual data of the first packet is piggybacked on the second packet. A completely different scheme from dictionary-code scheme.

[@slamduncan1392]

Very well made and to the point, thanks!

[@adamw1845]

Very VERY good video, clear and understandable, thank you

[@duskviper]

thanks a tonne for this. helped to get a grip on this concept completely.

[@Timer1024]

Excellent video

[@padmashrimm671]

On what based that 5 codeword are stored in sender & receiver dictionary??.....fr ex:- How 01 = 11100

[@The5BYTE]

thanks alot, helped me get the point.

[@soumenduchaudhuri9383]

good one, keep it up sir

[@tekbaobaozhang]

clear and simple!!! great

[@kaushalnijhawan9626]

how do we get code word

[@lezwon]

Your Video was very informative. Than you very much :)

[@alichoudhary9156]

thank you life saver

[@timefortourismjh6772]

How can I use LDPC code in QR code error correction????

[@wei48221]

great video..

[@vatsk]

But this only works on these specific codeword parts right. PS: Thanks for the video!

[@priyanshuganatra]

dammnnn, awesome explanantion!!!!!!!!!

[@JRock1900]

Why not send send everything twice? which will save you one bit for every 2 bits. Every 2 bits should send a duplicate of itself and you just match them up. And resend if you have an error. Or send 6 bits (2 the original and 2 copies, with the majority winning, this will save time to compare it to a dictionary and less likely to have as many errors (misinterpretation) as the 5 bit method??? Thanks for the video

[@hmdz150]

I think this is not practical for real-time/live broadcasting where every frame should be transmitted in the shortest time possible.

[@COMB0RICO]

A very good question!

[@odissey2]

I support this question. The amount of transmitted bits increases 2.5 times. Why not to send a message 3 times in a row, and select bits which repeat twice? ("a majoritar")

[@phanikiran8689]

thanks for this video

[@gokuaravind]

Thank you

[@HussainAhmad-kh3eo]

Thanks sir

[@amirgul8573]

thank u sir

[@billevans5612]

well explained. better too slow than too fast!

[@LordSarcasticVlogger]

watching from moon

[@gantagayatri1251]

Plz rise your voice

[@harshaaeron1120]

aosomw