WEBVTT

00:00:00.700 --> 00:00:05.220
We will now review a problem on
error correction and detection

00:00:05.220 --> 00:00:08.010
in order to better
understand how the selected

00:00:08.010 --> 00:00:11.670
encoding of a message can
help both detect and correct

00:00:11.670 --> 00:00:14.440
transmission errors.

00:00:14.440 --> 00:00:18.890
In this problem messages consist
of 9 data bits and 7 parity

00:00:18.890 --> 00:00:20.130
bits.

00:00:20.130 --> 00:00:22.800
Each Dij represents
a data bit which

00:00:22.800 --> 00:00:26.200
belongs to row i and column j.

00:00:26.200 --> 00:00:29.880
The Pij bits are used to
make the parity of each row

00:00:29.880 --> 00:00:32.189
and column be odd.

00:00:32.189 --> 00:00:35.660
The Pxx box, which is in
the bottom right corner,

00:00:35.660 --> 00:00:39.400
is used to make the parity
of the entire message odd.

00:00:39.400 --> 00:00:44.640
In other words, it makes the
total number of ones be odd.

00:00:44.640 --> 00:00:47.160
The first question we
want to ask ourselves

00:00:47.160 --> 00:00:50.520
is what is the minimum Hamming
Distance between valid code

00:00:50.520 --> 00:00:52.910
words using this encoding?

00:00:52.910 --> 00:00:55.030
In order to figure
that out, we need

00:00:55.030 --> 00:00:57.250
to think about how many
bits of the encoding

00:00:57.250 --> 00:01:01.320
are changed if I want to
change one of the data bits.

00:01:01.320 --> 00:01:04.480
The easiest way to see
this is through an example.

00:01:04.480 --> 00:01:07.990
Suppose that I want to
change D01 from a 0 to a 1.

00:01:07.990 --> 00:01:12.280
The first thing changing
is my data bit itself.

00:01:12.280 --> 00:01:16.420
Then P0x would get flipped
because I just added another 1

00:01:16.420 --> 00:01:19.460
to my row which means that
I need to flip the parity

00:01:19.460 --> 00:01:22.360
bit in order for the total
number of 1's in my row

00:01:22.360 --> 00:01:24.560
to remain odd.

00:01:24.560 --> 00:01:27.560
The next change is
that Px1 needs to get

00:01:27.560 --> 00:01:31.910
flipped in order to maintain
an odd parity in my column.

00:01:31.910 --> 00:01:34.330
So far, 3 entries
have changed which

00:01:34.330 --> 00:01:37.710
implies that the parity of
the entire message flipped.

00:01:37.710 --> 00:01:41.010
In order to keep the parity
of the entire message odd,

00:01:41.010 --> 00:01:44.420
Pxx needs to be flipped
as well so that there

00:01:44.420 --> 00:01:47.020
are a total of 4
entries being flipped

00:01:47.020 --> 00:01:49.960
which will cause the odd
parity of the entire message

00:01:49.960 --> 00:01:52.830
to remain unchanged.

00:01:52.830 --> 00:01:54.990
This means that our
minimum hamming distance

00:01:54.990 --> 00:01:59.450
for this encoding equals 4
because any time we flip a data

00:01:59.450 --> 00:02:02.590
bit, a total of 4
entries need to change

00:02:02.590 --> 00:02:05.080
to maintain our encoding.

00:02:05.080 --> 00:02:07.580
We know that to
detect an E-bit error,

00:02:07.580 --> 00:02:10.410
the hamming distance (HD)
has to be greater than E,

00:02:10.410 --> 00:02:15.910
or in other words,
the HD >= E + 1.

00:02:15.910 --> 00:02:21.770
So to detect a 1-bit
error, one needs a HD >= 2.

00:02:21.770 --> 00:02:27.810
We also know that to correct
an E-bit error, the HD > 2E,

00:02:27.810 --> 00:02:33.460
or the HD >= 2E + 1.

00:02:33.460 --> 00:02:38.350
So to correct a 1-bit error,
one needs to have a HD >= 3.

00:02:38.350 --> 00:02:42.910
For this encoding, since our
hamming distance equals 4,

00:02:42.910 --> 00:02:45.880
that means we should
be able to both detect

00:02:45.880 --> 00:02:47.940
and correct 1-bit errors.

00:02:51.820 --> 00:02:53.930
Taking a look at
this message, if we

00:02:53.930 --> 00:02:58.520
check the parity of each row,
column, and full message,

00:02:58.520 --> 00:03:02.230
we see that in all
cases our parity is odd.

00:03:02.230 --> 00:03:05.130
Since odd parity
indicates a valid message,

00:03:05.130 --> 00:03:09.730
there are no errors
in this message.

00:03:09.730 --> 00:03:12.720
Looking at this message
we see that all the row

00:03:12.720 --> 00:03:17.300
parities are odd, but the
parity of column 1 is even.

00:03:17.300 --> 00:03:20.390
This means that there
is an error in column 1.

00:03:20.390 --> 00:03:22.530
However, since
there were no errors

00:03:22.530 --> 00:03:26.010
in the parity of the rows, this
means that the bit in error

00:03:26.010 --> 00:03:28.180
is the parity bit itself.

00:03:28.180 --> 00:03:32.060
If we flip Px1 from
a 0 to a 1 we now

00:03:32.060 --> 00:03:35.610
have a valid message again.

00:03:35.610 --> 00:03:39.420
Looking at the parity of each
row and column in this message,

00:03:39.420 --> 00:03:42.720
we see that row 0
has an even parity,

00:03:42.720 --> 00:03:45.800
and column 0 has an even parity.

00:03:45.800 --> 00:03:50.770
This means that the data bit
at row 0, column 0 is wrong.

00:03:50.770 --> 00:03:54.800
If we flip this bit, we now see
that all of our row and column

00:03:54.800 --> 00:03:58.370
parities are correct, and
our total message parity

00:03:58.370 --> 00:04:01.120
is correct as well,
so we have restored

00:04:01.120 --> 00:04:03.950
our message by identifying
the bit in error.

00:04:06.480 --> 00:04:10.510
In this example, all of the row
parities and column parities

00:04:10.510 --> 00:04:11.330
are odd.

00:04:11.330 --> 00:04:14.950
However, the parity of the
entire message is even.

00:04:14.950 --> 00:04:17.579
This means that the bit
in error in this message

00:04:17.579 --> 00:04:20.430
is the Pxx bit itself.

00:04:20.430 --> 00:04:23.580
Flipping that bottom right
bit results in a valid message

00:04:23.580 --> 00:04:26.220
once again.

00:04:26.220 --> 00:04:28.840
Now let's go back to our
original valid message

00:04:28.840 --> 00:04:31.840
and see if we can
correct 2-bit errors.

00:04:31.840 --> 00:04:38.970
Suppose we flip D11 to 0 and D22
to 1 to create a 2-bit error.

00:04:38.970 --> 00:04:41.560
Now when we look at
the parity of each row,

00:04:41.560 --> 00:04:47.030
we find that both row 1
and 2 have a parity error.

00:04:47.030 --> 00:04:50.910
Similarly, columns 1 and
2 have a parity error.

00:04:50.910 --> 00:04:54.220
The total message
parity remains correct.

00:04:54.220 --> 00:04:57.430
Given this information, we
know that an error occurred

00:04:57.430 --> 00:04:59.300
in the transmission
of this message,

00:04:59.300 --> 00:05:02.870
but we cannot identify exactly
which bits are in error

00:05:02.870 --> 00:05:06.450
because there is more than one
possible way to alter two bits

00:05:06.450 --> 00:05:09.510
and arrive at a valid message.

00:05:09.510 --> 00:05:12.940
This demonstrates that we
can detect a 2-bit error,

00:05:12.940 --> 00:05:15.720
but we can't correct
a 2-bit error.

00:05:15.720 --> 00:05:19.230
Going back to our original
claims about hamming distances,

00:05:19.230 --> 00:05:22.340
this is in line with
our expectations.

00:05:22.340 --> 00:05:26.690
If E=2, meaning that we want
to detect a 2-bit error,

00:05:26.690 --> 00:05:31.200
then the HD >= E+1
which equals 3.

00:05:31.200 --> 00:05:40.040
To correct a 2-bit error, the
HD >= 2E+1 which equals 5.

00:05:40.040 --> 00:05:42.560
Since our hamming distance
in this problem is 4,

00:05:42.560 --> 00:05:47.660
we can only detect 2-bit
errors, but not correct them.