Cookies   I display ads to cover the expenses. See the privacy policy for more information. You can keep or reject the ads.

Video thumbnail
Whenever we send information from one computer to another there's always a risk that the signals received are going to be interpreted differently
From the message that's being sent. Yeah in this case
I'm sending a message from one Arduino to another
This is the transmitter. And this one here is the receiver and they're communicating using just a basic clock and data protocol
That looks something like this
You can see the clock is pulsing here and it's just going from high to low and then each time the clock goes from from
low to high the receiver looks at the data signal and interprets it as either a 0 or a 1
But it also got the switch in the middle here that I can press to interfere with the data line
And so if I do that we get the wrong thing here on the receiver
so now I know I'm using this switch to
Artificially cause problems but it's because it's possible for this sort of glitch to happen all on its own
So I'm showing these as nice clean on-off signals, but really everything is analog
These are just voltages and there's any number of reasons that occasionally this voltage might not be you know
Quite high enough to register as a 1 or this voltage might not be quite low enough to register as a 0
And without a lot of extra engineering work any circuits going to be susceptible to some sort of electromagnetic interference
for example
If I run the power cord for my lights nearby the circuit occasionally I can cause problems just by flicking the lights on and off
You know the quickly changing current and the power cord causes a changing magnetic field that might induce unwanted electrical currents in the nearby
Electronics it's ok. If we accept that errors are gonna happen. What can we do about it?
You know, how can a computer that's receiving a signal that as far as it's knows
It's just a series of ones and zeros. You know, how can it know that the data it's receiving is the correct data
Well one approach would be to just send the message multiple times. So ok
We receive this message here and it says hello word and maybe that's right, maybe not. So let's try again and see what happens
so reset these
And send the message again
You know, I'll just speed this up
Okay, so now we've got something different this time. It says hello world. It actually tells us something useful
You know that tells us that either the first message hello word. It was wrong or this message helloworld is wrong
It could still be that both messages were wrong, but we definitely know at least one of them was wrong
So let's try a third time
reset this and
Resend the message
And again, I'll speed this up and now we've got hello world again
So that certainly suggests that hello world is likely to be the right message
So in terms of you know figuring out if we if there was an error in our transmission, you know
I don't know how you feel about that. It doesn't seem all that efficient to me
I mean we've got to send at least twice as much data as we got to send the message twice and at least twice to
See if it's the same
But it does look like it works pretty well
I mean as long as we don't get the exact same error in the exact same place this ought to catch pretty much any problem
So so hey, you know it works and maybe that's good enough
But it really is not that efficient because we've got to send the message at least twice. So let's try to do better
Well, if we don't send the message multiple times to verify it, you know
What else could you do to figure out that that this is wrong?
You know what have I told you the message is supposed to be a normal English sentence
Well, obviously if you knew that then you know, it's clear that there was an error since this isn't an English word
So that might suggest that that maybe we don't actually have to send the exact message multiple times to verify it
You know might be good enough just to send the message along with some sort of description
Like hey, this is supposed to be English that would give you enough information to know that some bits must have changed along the way
So what sort of description could we send along with the message?
You know literally saying it's supposed to be English only works
If you've got some way to understand English and you know building a circuit to do that would be would be very complicated
Even I don't have enough bread boards to do that
So so let's actually look at the underlying binary
representation of the message since that's going to be easier to build a circuit to work with so
Of course
Our message helloworld is really just sent as a series of ones and zeros and just like knowing the message is supposed to be English
Can help you spot an error there all sorts of ways we could describe the strings of ones and zeros that might help us spot
an error for example
there are a hundred and four bits and that might be useful to know for detecting certain errors if we receive more or fewer than
A hundred and four bits then we know that there was a problem
Yeah, we could say that forty seven percent of the bits are ones and 53 percent are zeros
Or we could say the longest run of zeros is six zeroes
And I'm sure you can imagine all sorts of other descriptions that you know
May or may not be useful in figuring out if we receive the message correctly
And of course some things are better than others, you know
If I said here's a message and the longest run of zeros is six zeros
An error in this bit would be easy to catch
But you can change almost any other bit in the entire message and it would still not have a run of zeros longer than six
So maybe that's not a useful description. But if I said, you know, here's a message and they're supposed to be 49 ones
Well then
You know any single bit got flipped by accident there wouldn't be 49 ones anymore and you know right away that the message was corrupted
Now it's still not perfect, you know
If this bit gets flipped from a 1 to a 0 and then this bit flips from a 0 to a 1
There's still 49 one so you wouldn't catch those errors
But maybe we happen to know that errors are actually very rare and usually only affect a single bit at a time
so if we know that then then you know
If you know how many ones that are supposed to be and any single bit gets changed and we're guaranteed to catch it
Although as long as we're making that assumption, you know, we don't even need to know the exact number of ones
It's actually good enough just to know that there are an odd number of ones
because if we're only expecting a single bit to change if any single bit changes
Then the receiver would get a message with an extra one or a missing one
And so the number of ones wouldn't be odd anymore
Now mathematicians have a fancy word for talking about whether a number is even or odd, you know?
they use the word parity and
That word is also used in computer science to describe whether some data has an even or odd number of ones in it
in other words
We could say that our message helloworld has ad parody because it has an odd number of ones in the binary representation
Now the nice thing about parity is that it's either even or hud
there are only two options so we can keep track of parity in hardware using a single bit a
Good way to store a single bit is with a D flip-flop now
I've got another video on D flip-flops if you want to know exactly how it works
but
basically
the D flip-flop can store a single bit that you can read on the output here and it will update that stored value on the
Rising edge of a clock and then to whatever bit is on the input here. So ok
How can we use this to compute the parity of our message?
Well conveniently we have a clock coming from our transmitter that's going to give us a rising edge for each bit. That's sent
So we connected that clock to the clock for our D flip-flop
You know, let's just say we connect the output of the flip-flop then back to its input like this. Well, then each clock cycle
We're just going to take whatever is in the flip-flop and put it back in the flip-flop
So in other words, it'll do nothing, which is not very exciting
But now let's put in an xor gate in here like this
And if you imagine here that this data input is is low
then the output of the xor gate here is going to be whatever this other input is and so that's going to work just like
Before every time we get the clock, it's just going to put the same thing back in here. So still not very exciting
but if the data is high
Then the output of the xor gate is going to be the opposite of whatever the other input is
So if this data input is high, then the flip flop will alternate each time the clock pulses
So what happens if we hook this up to our clock and data signals? So let's walk through it
Well flip-flop starts off reset and the data is low then it'll just stay off each time the clock
Pulses no, but here where the data is high then on on this clock pulse
then we'll invert the output and feed it back in and so now the flip-flops output would be high and
Then when the data signal goes low again then each of these clock pulses here
We'll just feed that one back into the flip-flop and it'll stay high
But then when we send another one well invert the input into the flip-flop again, and it'll go low
So in other words every time we transmit a 1 the flip-flop will alternate States in other words
If you know the flip-flop starts out off then if we send an odd number of ones
It'll end up on and if we send an even number of ones it'll end up off
So if we feed our message into this circuit using our clock and data signals, it should compute the parity for us
So let's give it a try
So to build this circuit, we just need a D flip-flop and an XOR gate and for the D flip-flops
There's lots of different chips
You could use let me use the 74 HC 273 but there are a lot of other things you could use
You know anything with a D flip-flop will probably be fine
Now this one has 8 D flip-flops, but we'll just be using one of them for now
So look at the 74 HC 273 and then for the xor gate, I'll use the 74 HC 86
Which is a quad xor gate, so there's actually 4 XOR gates
And again, we're only gonna use one of them for now and again
Even though I'm using the 74 HC family you can use 74 LS or whatever
You've got you know, really any D. Flip-flop an xor gate ought to be fine for this
So the first thing i'll do is hook up power and ground for each of these chips
So we look at the data sheet for the 74 HC 273
You know, we're only interested in this one flip-flop down here
we've got our input and output on pins a
3 & 2 and then we've got the clock and that goes up to pin 11 and in this clear signal
Which goes down to pin 1 here and the way this works is that bringing pin 1 low?
Resets the flip-flop to 0 regardless of the other inputs as we don't normally want it to be resetting itself
So we don't normally want pin 1 to be low. So what I'll do is tie it high through a 100k resistor
Now way this pin works is there won't be any current flowing. So there's no current flowing through the resist
So both sides of the resistor will be at 5 volts which means pin 1 will be high
But if I want to manually reset it
I can just use a jumper like this and connect pin 1 to ground and that will reset it and
Having the resistor here will just keep us from having a short-circuit when I do that
So that's the clear pin then pin 3 is the input and if we look at our circuit diagram the input comes from the output
Of the xor gate if we look at the xor gate the output of the xor gate is also on pin 3
so really we just want to type in 3 of the xor gate to pin 3 of the flip-flop and
that will connect the output of the xor gate to the input of the flip-flop and
We also want the output of the flip-flop to go back around to one of the inputs of the xor gate
so I'll type in 2 to pin 2 and
Pin 2 is the output of the flip-flop and that will go to pin 2, which is one of the inputs of the xor gate
And we also want to see what the output is doing
So I'll hook an LED up to that as well
And I'll connect the other side of the LED to ground through this resistor and this is just a 270
Ohm resistor, you know anything that's a few hundred
Ohms ought to be fine just to limit the current through the LED
And so now we basically got this circuit built. We just need to hook up our inputs
so let me connect the bread boards together here for a transmitter and
A transmit clock was on pin D 2 of the Arduino
So I'll hook D 2 here up to pin 11 on
The 74 HC 273 which is the clock input of the flip-flop
So there's our clock and then the transmit data is on pin D 3. So I'll hook that up to
The first input on our xor gate here
So what that'll do is every time we send a bit the clock will pulse
which means every time we send a bit we're going to load a new value into our flip-flop here and
That value is either going to be the value that's currently in the flip-flop if the bit we're sending is a 0
Or it's going to be the opposite of what was in the flip-flop if the bit we're sending it was a 1
In other words every time we send a 1 bit the value in the flip-flop will alternate
Keeping track of the parity. So that is whether we've sent an even or odd number of bits that are ones
so let's power this up and see if it works and
There it goes and
Looks like it's not working. I would expect to see this start to alternate. Oh, you know what? I forgot to connect the power
So I didn't connect the power between the two bread boards. So let me just do that
So now we're actually sharing power between these breadboard. So let's try this again power it up and see if it works and
There it goes and now we see it alternating so every time we send a one we should see this LED alternate and
So if you remember before we looked at the message helloworld and determined that it has 49 1s
Which means there's an odd number of ones which means that by the time this is done sending
Because 49 is odd. We should expect to see this LED on
And there it goes
So it's done sending the message and the LED is on so that indicates that indeed when we sent the message we had an odd
number of 1 bits
So that's great that we can compute the parity on the transmitter
Now to help us detect if there was an error sending the message we could do the same thing on the receiver side in other
Words, we could duplicate essentially the same circuit over here on the receiver
and then we be computing the parity of the sent message and
Computing the parity of the received message and then if any single bit gets flipped
You know zero changes to a 1 or 1 changes to a 0
You know between the transmitter and receiver possibly due to this evil little button
I've installed here then the parity won't match and we'll know that there was an error
So, let's build the same circuit over here on the receiver side
And it's going to be identical
We've got a 74 HC 86 for the XOR gates and a 74 HC
273 for the D flip-flop and I'll hook up power and ground everything and
This time I won't forget to connect power between the bread boards and I'll tie the reset line high through a 100k resistor
the output of the xor gate will go to the input of the D flip-flop and the
Output of the D flip-flop would go back to one of the inputs of the XOR gate
also hook the output of the D flip-flop to an LED and
Connect the other side of the led to a ground through a 270
ohm resistor
Then I'll hook the received clock to the clock input of the D flip-flop
And hope the received data up to the other input of the xor gate
Alright, so now let's power up our receiver
And so this is where I want to be able to reset the parity bit
So I'll manually connect round 2 pin 1 and that should reset it. So
Now if I reset the transmitter so it resends the message
We should see the parity getting computed on both ends. And if there are no errors, then it ought to compute the same parity
and
Indeed. It looks like it came to the same answer
So after sending the message over here, we've sent an odd number of ones and after receiving the message over here
We've received an number of ones
So now let's reset everything and try introducing an error
so first, I'll reset the parity bits by briefly connecting pin 1 to ground then I'll reset the receiver and
Now reset the transmitter to resend the message
So now let me try to re-introduce an error
And already you can see the parity bit is out of sync and so if we just speed this up so it finishes up
and so now at the end of the message we can see the transmitter thinks it sent an odd number of ones because the the
Parity bit is on but the receiver thinks it received an even number of ones because the parity bit is off
So that means there was definitely an error and this message here. HelloWorld is is apparently not what we're which sent
So this is all great but there's still a missing piece
So if we just focus on the receiver, let's say we receive something like this. We've got this message
Hello world and our parity computation is zero saying we received an even number of ones
So the question is did we receive the message correctly?
Well, you might think it looks fishy because we know from before that our message had an odd number of 1 bits
So maybe you'd expect this parity bit to be set
But the message here is actually different, you know before the message was hello comma world
And now there's no comma between hello and world
And it turned out the binary representation of a comma has three ones, which is an odd number so we would expect a message
That's missing a comma to have a different parity from the same message with a comma
So does that mean we receive this message correctly
Well from the receivers perspective
There's still no way to tell but if I show you the parity bit computed by the transmitter, I bet you can tell now
And since the parity of the transmitted message doesn't match the parity of the received message, then we can't possibly have received the correct message
But of course you couldn't know that without knowing what parity the transmitter computed
So the only way this is going to be useful is if the transmitters is able to send its parity bit to the receiver somehow
So the receiver can compare it with its own computation
So how do we get the value of this parity bits sent over to the receiver?
well
I think the easiest way is to have the Arduino just read the value of the parity bit and send it the same way it
Sends the rest of the message so to get the Arduino to read the parity bit
We can hook the a bit to an unused data pin on the Arduino
So I'll connect the parity bit which is the output of the D flip-flop here to pin D 10 on the Arduino
Then in the code for our transmitter, I'll define a new pin for our parity bit on pin 10
And if any of this doesn't make sense, I wrote all this code in my previous video
So check that out if you haven't seen it
in the setup
I'll set the pin mode to input since the parity bit will be read in to the Arduino from the circuit
We just built and then at the end of the loop here after we're done transmitting our message
We want to transmit the parity bit
So we'll do a digital right to our transmit data line and instead of saying high or low
We just want to write whatever the parity bit is
So this digital read will read whatever the parity bit is set to and then put that same value out on our transmit data line
So this works just the same way as when we're transmitting the bits of our message up here in the loop
And then in the same way, we want to pulse the clock high and load a signal that we're sending another bit
So after the loop where we send the message
we put the
Value of our parity bit out on the on the data line and then we have a delay and then we pulsed the clock high
Then a delay and then pulse the clock low again
Just after sending our message. We're sending just one more bit, which is our parity bit
So let's reprogram the transmitter with this and give it a try
Connect a USB here. Make sure I'm on the right port
And upload it
And there Coast looks like it's programmed and now just reset itself
We just let this run for now because we have to kind of reset everything else before we can really test it
okay, so this is programmed and it just reset itself and
So I'll just go ahead and disconnect the USB and get everything else reset
so
Of course
We want to make sure our parity bits are all set to zero and we start
Reset our turn our receiver and then we'll reset the transmitter now and let it transmit the message and hopefully also the parity bit
So now it's you know sending the message just like before and for now I won't induce any errors
So I'll just let the letter transmit the whole message
And I'll speed it up a little bit here
Okay, now it's done and you'll notice right away that the both of the parity LEDs on both sides are off
So that suggests that we must have sent an even number of one bits and received an even number of one bits
and of course our message hasn't changed yet still has an odd number of it's
But now we've also sent the parity bit
Which remember was a 1 and that's actually this one here that you can see on a receiver
And of course our you know, our parity computing circuit is very simplistic, you know
It doesn't know the difference between the data bits and this parity bit
And so it just wound up counting another bit and we wound up with an even number of ones
but if you think about it this leads to an interesting property as anytime our message has an odd number of 1 so for example
our message here has 49 ones which is an odd number and because it's odd the parity bit is going to be 1
But once we add that extra 1 the whole thing the message and parity bit together
Now has an even number of 1 so the receiver ought to expect the whole thing to have even parity
But let's take a different message. Here's a different message
That's got an even number of ones and because it's got an even number of ones the parity bits going to be 0
But that means the whole thing message plus parity bit still has an even number of ones
Which means again that the receiver is gonna have to expect the whole thing to have even parity
So this interesting is this means that no matter what the original message is was it's even or odd
after the transmitter adds the parity bit the entire thing message plus parity bit was always going to have an even number of ones and
That's something the receiver can count on to validate whether the message was received correctly
Even if it doesn't know what the message is is gonna be ahead of time
So whenever we say a transmitter or a communication link is using even parity
This is what we're talking about
we're adding a parity bit to each block of data to ensure that it has an even number of ones and
So we can actually describe our transmitter now as having this property of transmitting even parity
So let's take a look at the receiver again as we receive a message now again
We've got this message where we received hello world without a comma
So was that a mistake or not?
Well because this LED is on we know you received an odd number of ones
But now we also know that our transmitter has even parity. So counting the parity bit
The transmitter will always transmit an even number of ones
and so anytime we receive an odd number of ones like this and
This LED is on after we're receiving we know that there must have been an error
because the only way we could possibly
Receive an odd number of ones as if some bit got changed along the way after it left the transmitter, you know
Either a bit in our message or the parity bit itself
Now as I mentioned before this obviously isn't perfect
if a single bit in our message changed
You know one changes to a zero or zero
Changes to a one then that'll change the parody the message we receive and we'll detect that as a parody error
But if two bits change, for example this zero changes to a one but then this one over here changes to a zero
Then the overall parody the message won't change
So in that case will receive a corrupted message, but we won't be able to detect it. So it's not perfect
You know, there are some things we can do to improve the situation. For example
Instead of having one parody bit for the entire message
We could send a parody bit after every bite
Now that would help us catch some of these cases where more than one bit gets corrupted
But even that won't catch two errors in the same bite
And we can keep playing this game and send a parody bit for every four bits or for every two bits
If we take it to the extreme and send a parody bit for every date a bit
Then we're basically right back where we started, you know, sending our entire message twice
So it looks like there's this trade-off between improving our chance of catching errors versus sending fewer bits and indeed
That is a trade-off that you have to make as an engineer designing a system like this
But even so there are times when you want the best of both worlds you want to detect multiple errors close together
and you want to minimize the number of extra bits you have to send so what then
Well, there are more complex techniques for error detection that can get you closer to the best of both worlds
And that's what I'll talk about in the next video. So make sure you're subscribed with notifications turned on so you don't miss it
These videos are made possible by the support of my awesome patrons
so if you'd like to help make more content like this available hit over to patreon and consider chipping in and a big
Thank you to everyone who's already donated. You're a big help and you're truly the ones making these videos possible
You