So a zero is represented as, Ah, positive voltage transitioning to a negative voltage.

And a one is a negative voltage transitioning to a positive voltage.

And so we decoded each of these bits, and then we kind of flip the order of the bits for each of the bites.

And this bite is when we convert to Decimal is 75 which is K.

And then despite is a 65 which is an A and so we're sending K A.

But you might be wondering how we knew our more importantly, how receiving computer would know that the that these particular group of eight bits make up the bites, you know, presumably there's a whole stream of, like ones and zeroes off here to the left, and that stream is gonna continue off to the right.

A cz Well, so what happens if we pick the wrong group of eight bits?

So here, for example, we're starting with, like, the third of these bits that shown here, you know, But what happens if we start instead with the with the fourth.

So maybe we draw our boundaries.

Here are Are we gonna get up, end up with something else?

So here we have the you know, two more groups of eight bits, and we've reversed the order there.

Um, but now if we convert these eight bits Thio decimal, you know, this is equal Thio 1 65 and that actually maps to if we map it to assemble, depending on what character set we're using.

This is the the yen symbol.

Um, and this one over here, if we convert this to decimal is 1 60 and that maps to just a blank space.

So if we meant to send the letters que es and the receiver is interpreting, this is yen space.

Then you clearly something has gone very wrong.

So how does the receiver know what the correct bite boundaries are?

So how does it know that that this bite should start here, you know, and actually start over here and not here or here, here or anywhere else.

Well, so the way it knows is that bites are grouped into something called frames which might be 1000 or so bites long.

And if we have a way of telling where a frame begins, then we can use that to find the bite boundaries.

Hopefully, if I show you a couple examples, this'll make a bit more sense.

So I'm gonna show you two different ways of doing framing that are used in networks.

There are many others, but this should give you give you a sense.

The first framing mechanism that I want to talk about is used by a protocol called H D L C, which stands for high level data link control.

And this is a protocol that use pretty commonly an Internet service provider, networks and other large networks.

And so what HDL see does is it uses a special bit pattern called a framed a limiter or or a flag and in.

And this pattern with H.

D.

L C is just defined to be 01 1116 one's followed by a zero.

And so whenever the receiver sees this particular pattern of bits, it knows that the very next bit starts the beginning of the frame, and then every bits after every eight bits after that makes up a bite for example, if we have this stream of bits, we can just go along here until we see this framed a limiter and then each set of eight bits following that makes him a bite.

So the framed a limiter is right here so we could just ignore these bites.

The beginning, the frame.

The limiter is here, and then each set of eight by bits after that makes him a bite.

So there's eight bits.

There's eight bits and there's eight bits on.

And then we could keep going here if there are more bids.

And so if we So this is the framed A limiter, the flag.

And then this bite right here is 75.

This is 65 and then this over here is to 48 and so on.

We could keep going.

So now I did something kind of sneaky here.

I don't know if you noticed, but if you look right here, this set of eight bits is actually another flag.

But this flag pattern here isn't here to sort of identify the start of another frame.

It just happens to accidentally show up as part of the data we're sending.

So how do we send this data without the receiver sort of accidentally mistaking.

This is a new frame and starting a new frame right here at this zero.

So it turns out when you're using HDL, see framing like this, there's there's another rule that we need to follow whenever they're five consecutive one bits anywhere in the data that we're sending, then we should just stuff an extra zero in after those five ones to prevent this problem.

So then, whenever the receiver sees five consecutive one bits like this, then it should expect that the next bit is gonna be a zero, and it could just ignore it s o.

If the receiver ever sees, like, six consecutive ones in a row, then it's either part of a flag like this or there's been some kind of something has gone wrong.

And so this this technique of putting these extra bits in here is is something called bit stuffing.

So that's H D.

L C.

Ethernet is quite a bit different, So let's scroll down here and I'll show you what the beginning of another net frame looks like.

So, at the beginning of a new Ethernet frame, there's this was called an inter frame gap, which is actually a period of silence.

Where there's nothing, there's nothing being transmitted all In fact, the voltage on the wire is zero, and Ethernet requires, you know, an inter frame gap of at least 96 bit times.

So whatever the timing of the bid is depending on the speed of the Internet, Um, this is silent for some period of time, and so that's a way to know that that there's no frame being sent.

And then as data starts to show up, that frame is going to arrive following that silence.

Then Ethernet starts to send this preamble, which is 56 bits of alternating ones and zeroes, and so you can see the ones and zeros here.

I've taken a capture from the telescope and patched together the entire beginning of an Ethernet frame here just to take a look.

And so the preamble is 56 bits of alternating ones and zeroes, and this this does a couple things.

One is, um, it's kind of a distinctive pattern.

Also following the silence here where there are where there's no data being sent, it gives the receiver an opportunity to synchronize its clock Because, remember, as we start to read bits off the data when the data shows up, we want to make sure that the receivers clock is synchronized with the sender's clock.

And so this gives the receiver kind of an opportunity to, um, to get its clock synchronised among some other things.

So there's the preamble of 56 ones and zeroes, and so it keeps alternating 101010 And then it gets to this point where it continues where we get to this started frame dilemma.

And so it continues.

101010 and then the last two bits of the start of framed a limiter is 11 And so even if the receiver kind of like synchronizes partway through this, it's going to see this stream of ones and zeros that may not know where it is among those 56 bits.

But eventually it's gonna get to this point where instead of alternating 1010 you get the 11 and that's the That's the trigger.

That's when the receiver knows that the next the next bit that shows up is the first bit of the data, and then all it needs to do is just start reading the data.

And this is exactly what we looked at before.

And each each sequence of eight bits forms a bite on this continues on and on.

And so I just one more thing that I that I'd like to add is just about frame length.

And so the number of bites that you have in a frame.

So after once we've synchronized the frame, we have a start of frame.

We start having data here.

The number of bites can vary.

So, like in theory, we could send a frame with just one bite.

So after this bite, we just go silent.

We have another inter frame gap.

We could do another preamble and have another frame, but that's very inefficient, because we have to do this whole preamble nonsense just to send one byte of data.

It's on the other hand, you could imagine, you know, once we started sending this frame and the receiver knows where the bite boundaries are, you know, we could send thousands and thousands of bites or even millions of bites, and that that would work too.

But The problem is that if any kind of error happens on the receiver, misread something or gets out of sync, then it's gonna misread everything that follows it up until the next frame.

So there's this trade off, I guess, between efficiency.

You know where you'd want large frames on being able to quickly recover from an error, in which case you kind of want small frames.

So in practice, frame sizes tend to vary between 64 bites and 1500 bytes.

Um, but you know, in some high performance networks, he may see frames as large as 9000 bites or more on those air, generally referred to as jumbo frames.