How does a USB keyboard work?

The old ps2 style

keyboard

interface is quite simple, only four of the pins are used, two of them are for ground and five volts to provide power to the

keyboard

and then once the keyboard is powered on the other two pins provide two signals that are used. to communicate and every time we press or release a key, the keyboard will send one or more of these bursts of data in those two signals, so each of these bursts includes 11 clock pulses and the corresponding data, a start bit , 8 data bits per parity. bit and bit stop, it really couldn't be a less complicated protocol and in fact, on Patreon, Emily says that I've heard anecdotally that PS2 accessories are better for gaming because the latency is lower than USB, seeing how Simple as the protocol is, I could You probably think that now maybe one day you will connect your oscilloscope to some USB devices and we can see how complex it is.

Well, that day has arrived. I have a USB keyboard here and the standard USB 2 connection also uses only four pins. ground, five volt power and then two data signals here that we can see on the oscilloscope, if we look at the specifications we see that the red is the bus voltage, the black is ground and then the green or white is d plus and d less, so instead of having a separate watch. and data pins, we have a differential pair, so we'll talk more about that in a minute. By the way, this is from page 89 of the USB or the 650 page USB specification, but anyway, if we plug in the keyboard, you'll see that d plus stays low. and d minus goes up when we connect the keyboard, but if we try to type something on the keyboard nothing happens, so what happens?

If we look at the USB specifications for signaling levels there is this table and as is very common with specifications it has a lot of precision but not much clarity but if we break down the two signals we have d plus and d minus and basically there are only four scenarios that we can have here: d plus can be high and d minus can be low. d plus can be low and d minus can be high both could be low or both could be high and that's basically what these first four things here indicate so there's a differential one where d plus is high there's a zero differential where d minus is high and then there is the single ended zero where both are low or both high so the state we are in now when we plug in the keyboard d plus is low and d minus is high so it is a zero differential but that also corresponds to this idle state, d minus is high d plus is low, but notice that that is the idle state for low speed.

There is also an idle state for full speed, which is the opposite where d plus is high and d minus is low and this is because USB runs at different speeds depending on the particular device that is connected. There is a low speed which is 1.5 megabits per second and a maximum speed of 12 megabits per second and then after connecting at full speed a device can even switch to high speed which is 480 megabits per second and then Of course you know that with USB 3 you can go up to 10 gigabits, but that's a completely different interface and what we're seeing here is that by pulling the d minus up like that when we plug in the keyboard the keyboard is actually indicating two things, one is, you know, the signal that it's connected, but two, by pulling d less high, it's indicating that it's a low speed device.

I have another keyboard here, which is uh, I guess maybe I don't know. a little fancier certainly costs more but if we plug it in what you'll see is that it pulls d higher which means this keyboard says it's a full speed device instead of a low speed device but as before when you press keys

does

n't actually do anything and that's because with USB all communication is initiated by the computer and the keyboard never offers anything on its own other than simply saying what speed it wants to communicate at such a low speed. this case, but we actually make the keyboard do everything we need to connect a USB to a computer so that the computer can initiate communication.

I have the other end of that USB connected to this cable here where I broke the d plus. The d minus signals as well as ground and of course I don't need to cut the bus voltage because the computer hub will provide power to the keyboard, but we can still connect the d plus and the d minus here. to our oscilloscope and then I have the ground here so we can get a signal ground for the oscilloscope cables and then when we plug in the keyboard we start to see a signal of some kind and we can zoom in on what we're capturing here and we have some kind of data communication, you know, here, so let's take a single photo of that and we can zoom in and see what's going on here and actually what I'm going to do is I'm going to plug in this little USB stick and then I'm going to zoom in and , you know, to better analyze this, what I can do is basically take screenshots of this and scroll around and try to get screenshots of as much of the waveform as I can. then we'll put them together into a kind of giant image that we can use to analyze this better, so I'll put all these bits together and take the full waveform that we captured and then invert the color so we can print it out and we can use a hard copy to see more of close what's happening here and here is this is the signal that we captured and maybe it's a little silly to print it like this, but I think it'll be interesting to dig deeper and really understand what's going on here.

You can see that for the most part the signal is differential, so d plus and d minus are practically opposite to each other and that corresponds to the differential. differential one and zero states we saw before, but there are a couple of places where we see single-ended zero where both d plus and d minus are low, for example here and here and finally at the end and that single-ended zero for about two bit times corresponds to the end of the packet, which suggests that maybe we know one, two, three packets, but anyway it says that the end of the packet is a single-ended zero for about two bit times followed by j for one. bit time and j are this data j state for low speed will be a zero differential and if we were running at maximum speed it would be differential and then they have this state j they also have a state k which is basically the opposite so you know we are running at low speed here, so if j is a differential zero, k is the same as differential one and if we were running at full speed it would be the opposite, but basically in any case the idle state is this state j and then when we start a packet , the data lines change from that idle state to state k, so in this case it will be differential, so state j is this period here where we're basically sitting. in this, you know, this idle state where we were before, where d plus is low, d minus is high, you know if we're a low speed device, that's going to be our idle state and then that end of the packet is a differential or it's a single-ended zero followed by state j and that's what we have here and then an initial packet is changing from that idle state to a state k and that's what happens here, so this change is now to state k by a little while and that's basically the beginning of a packet and then the way we're going to interpret what's in that packet or what all of this actually is is by first decoding this whether it's a j or k state and that will also mean recovering some kind of clock of this because for the most part this data is sent as a differential pair, it's not sent like the PS2 keyboard where we had a separate clock line that was just a clock and then we had data. that we could read against that clock, we don't have to here we have this differential data and we have to infer the clock based on a couple of things, one we know that it is low speed due to the idle state and then we know that the clock should be about 1.5 megabits per second, but as to what exactly that is because of course it's not going to be perfect, we have to just look at where these transitions are and figure it out for ourselves so we can look at something. so and let's see well, those transitions are happening in this interval, so if we want to know exactly how many bits there are, we can infer from these other transitions that you know that in this period there will probably be, let's see it looks like this. three bits and you know somewhere around here, for example, you know it's going to be four bits, so you might be wondering, you know why send this differential pair and then you know to force the receiver to figure out what the clock is by inferring it. since when the transitions occur and the reason is that there are actually many advantages to using a differential pair like this, one of the most important is avoiding susceptibility to interference because if any type of electromagnetic interference occurs with this, the interference will presumably affect both signals.

Same thing because both cables are run next to each other and are the same length, so any interference that affects one will affect the other and with a differential pair like this, what the receiver can do is simply subtract. one signal from the other and any interference that affected one of them will have affected the other in the same way when you subtract them, you will subtract that difference and you will be left with the original signal, the other advantage of a A differential pair like this reduces the emissions because once you send data very fast like this, in this case you know our frequency, our data rate is 1.5 megabits per second, so if we have what is effectively one and a half megahertz of AC.

The signal coming through here, that cable could start to look a lot like an antenna with a one and a half megahertz radio transmission emanating from it and, you know, a one and a half megahertz radio transmission could cause a big problem for any other. electronics, but by using a differential pair like this, you will presumably have two things emitting, but they will be 180 degrees out of phase, and effectively any radio interference emissions they emit will destructively interfere with each other and effectively cancel each other out. Another advantage of using a differential signal like this is the reduction of emissions and since all the remaining signal is differential I will check and fill in whether each bit is j or k, that way we will have all the bits accounted for and then we will be able to analyze and really find out which means, okay, and that's it, so we have our single-ended zeros here and then we have our j and k, now the single-ended zeros.

As I mentioned before, they delineate the boundaries of these packets, so what we're seeing here is that we're seeing three different packets being sent as part of this burst of information. The end of a packet like this is signaled by the single-ended zero. for about two bit times we see followed by a state j, well it says one bit time but I think it means at least one bit time and then the start of the packet is the data line change from idle to a state k, so this k is where the start of the packet actually occurs and then each packet starts with a synchronization pattern and says three kj pairs followed by two k are required for a total of eight symbols, so if we look here we have one, two, three kj states. followed by two k and there's our sink and then the same thing here we have one, two, three kj pairs followed by two k and then for the last packet here, we have one, two, three kj pairs followed by two k and the reason why the sink starts that way is that the kj pairs give you this nice oscillating signal here that you can use to synchronize your clock so you know you can do your little tape measure here to find out exactly what those bit times are so you know that if you dig into some of these situations where you have quite a bit of time here, you can figure out well, this is going to be seven bit times, but any At this point, the synchronization pattern is over and we're in the data part of the packet and the first few bits of the packet indicate the packet id, which is essentially the type of packet, but it's not encoded the way you might think it's not like you know the case corresponds to a 0 j corresponds to a 1 or something well, it actually uses a different type of encoding called nrzi no return to zero inverted and with nrzi encoding the way it

work

s is basically a one is represented by no change in level and a zero is represented by a change in level , so for example, here this first k is not a change in level, because the previous bit was a k, this is a k, so there is no change in level, so there is no change. at the level it represents a one, so it's actually a one, then it changes from k to j, so that represents a zero because that's a change in the level.

Then when we change from j to k, that's also a change in level, so it's also a zero, but now. k to k that's the same thing, it's a one and those are the first four bits that we decode using this nrzi encoding and the reason for using this encoding instead of encoding the ones and zeros as different high or low levels is that you know particularly At speedshigher, it is easier to detect a transition between two different voltage levels than it is to know how to measure exactly what that voltage level is, whether it is above or below some threshold at a given time, it is easier to simply look for those transitions , so detecting a one or a zero based on the presence or absence of a transition is much more reliable and because a zero is represented by a change in level, that means that, by looking here, you can see many changes of level here, which suggests that in this area there will probably be a lot of zeros, which we want because we want to be able to get that clock back and be able to count, you know, how many holes we have.

In fact, one of the problems with encoding clock and data using the same signal is that if you don't have either. level transitions over a period of time, maybe you could lose count of how many bits you have, so for example, again here you know that if we count these bits we get to this area here where we don't have transitions for quite a while and if we count it looks like which is seven bits, but if this went on for too long and our clocks weren't perfectly synchronized, we might know that this was wrong and another thing that the USB protocol uses is this thing called bit stuffing to ensure that it knows the signal transitions Basically, what happens is that every time there are six consecutive in the data stream, it basically forces a zero in the data stream to just make sure that there is some kind of transition here and that actually seems to have happened here because we have seven bit times here and seven bit times means that there are six times where there was no transition, which corresponds to six ones and so after six ones, this, this, this j, which is like stuck here or actually this transition that's stuck here, uh, to mean a zero, you know? the result of a little filler to say, well, we've gone too long without a transition, we need a transition. here so that when we do the clock recovery we don't have this long interval, so anyway it's something to keep in mind when we're decoding this, anyway, we've decoded our first four bits here one zero zero one and the USB transmits least significant bit first, so if we wanted to read this kind of normal bit order, it would be one zero zero one because it's symmetric, but those first four bits indicate the packet ID and again we can look in the specification for what those identifiers are. of packet and one zero zero one is um, it's a symbolic packet for the input, so it basically says that this packet is an input packet, whatever it is, because the packet id is one zero zero one, so that we can say that this is going to be an incoming packet and then the next four bits, if we decode them, this is a transition, that is, zero, no transition, no transition, and then a transition to that k, we get 0 1 1 0 and that will always be the complement. of the first four bits, so we get 1 0 0 1 and then 0 1 1 0.

So it's all the bits inverted and that's basically done as a kind of data integrity check to make sure that we receive this correctly and then that's the first byte of data that we receive, so now I'm going to go ahead and decode the rest of this packet so we can know, look what that means, so that's the binary for the rest of the packet and this. it's an input packet, so if we look for an impact it's a type of token packet, so if we look at what looks like a token packet it has the packet id, which is eight bits, that's what we've decoded here and then it has a seven bit address, a four bit endpoint and then a 5 bit crc and the crc is the same it checks the address and the endpoint it

does

n't check the packet id that's why we had that thing inverted duplicate, so let's see what We have here, so the next seven bits will be the address, so that's up to this point here, so those seven bits are the address, then we have four bits of the end point and then these last five bits They are crc and again all. of these the least significant bit is transmitted first, so if you want to look at this in a normal way, you might be used to looking at binary numbers, if you are someone who is used to looking at binary numbers, you flip all these bits so they are 0 0 1 1 0 0 0. 0 0 1 1 0 0 0 you will see a 1 8 in hexadecimal that if we convert it to decimal 1 8 in hexadecimal the decimal is 24. that was the address, we have this end point and again 0 0 0 1 we read this backwards so if we turn it around it's 0 0 0 1 which of course is just one and then these last five bits are crc which just checks all we'll assume that's correct so we've decoded it and basically what it says is that this is a command in I guess, or a token packet for the address 24 .1, so what could that mean if we look at the computer it's on? is connected, I have this lsusb command that will show what USB devices are connected and you can see we have the Dell keyboard that we're looking at and the device ID is 24.

So this first packet that What we're looking at here is literally the computer sending a command that says I want to receive data from device 24 from that keyboard at endpoint 1 and endpoint one. You know that's going to be the first endpoint you see basically. corresponds to the keys being pressed right now and then we have a crc that probably checks all of that, so the computer asks the keyboard what keys are pressed next and presumably this will be the answer, so let's go ahead and decode that . so this is the package id one one zero zero actually the other way around this will be zero zero one one will be the package id and then we have the plugin here to check it but zero zero one one corresponds to zero zero one one data zero so this it's a data packet so we have a data packet and then if we decode it we basically get a bunch of zeros so these are all zeros because every time the signal changes remember in nrzi encoding a transition means a zero, so these are all zeros, so the data is basically all zeros, so we divide it into bytes and we basically end up with a bunch of bytes of zeros and it looks like we have one, two, three, four, five six seven eight. zeros and then we have other things here, so let's go ahead and decode this and now we have six ones and after six ones we're going to have data that we're going to fill with bits, so we're actually going to Basically ignore this, this j because this or ignore this transition at least because this transition is only here for the purpose of padding bits to make sure that we don't have too long a run of one signal level, so that transition we're basically going to ignore, but then this k is a state change, so we're going to interpret it as a zero because it's a state change, so we're kind of missing a space here, but anyway 0 1 and then the rest of this is a transition transition no transition transition like that and now if we look at the format of a data packet, we have the eight-bit packet ID and that's what we have here, it says zero data, we have it, then we have data, which is, you know.

I guess between zero and eight thousand one hundred ninety-two bytes or not, I guess it would be bits and then a 16-bit crc that protects that data, so in our case we have eight bytes of data or I guess 64 bits. and then this would be the crc, so if we wanted to figure out what that crc is backwards, it would be 1 1 1 1, so that's f and then 0 1 0 0 is 4 in hexadecimal and then 1 0 1 1 is b and then 1 1 1 1 is f, so the crc is f4 bf, which I assume is the crc for all zeros, does that make sense? Let's check that.

We have a calculator here and it's going to be hexadecimal. Let's see, yes, that's eight bytes of zeros. Calculate a crc. 16. And do any of these output to f4 bf here we go f4bf and that's oh yeah, crc16 usb, so that sounds good, that's what we're doing, so that's our data packet, we have eight byte data? zeros and then we have a checksum or crc, I guess, and then we have one more packet here, we have our synchronization and then if we decode this, let's see that there is a transition no transition transition transition no transition transition no transition no transition, so that is zero zero one zero is the packet ID and zero zero one zero is an acknowledgment so the acknowledgment and that's really all there is in that packet is just an acknowledgment so if we look at this whole sequence here we have the computer.

Well, we assume it's the computer, we can't actually tell which part of this transaction or which part of this communication is the computer and which part is the keyboard because they both use the same signal lines, but presumably it's the computer doing the pulling. the keyboard requests input from device 24, which we have determined as the keyboard at endpoint 1, which will correspond to the keys that are pressed and then the keyboard responds with some data with eight bytes of zeros and because these are all zeros basically what the keyboard says, well there are no keys being pressed right now, what was the case when we captured this correctly, no keys were pressed and then it checks that there is a crc for that and then the computer responds with a recognition and so on That's the whole transaction, so the question, of course, now is what does this look like if we're actually pressing some keys.

We can try it and it looks like there are some changes here, although it's a little hard to tell. exactly what's going on and I don't really feel like you know how to try to capture this and go through the process of decoding another one of these packets, although you know they make fancy oscilloscopes that will decode USB automatically, unfortunately this is not one of them. but the folks at Keysight were nice enough to lend me one that does, so I have it wired up the same way and we're looking at the d plus and d minus signals here and if I press some keys you can see there are bits. flipping here we're going to set up serial decoding so let's see we don't want i squared c we want usb and mode the usb speed for this keyboard is low and then the d plus signals on channel one d minus are on the channel two and you can actually already see the data here, so this shows the data packet and then the acknowledgment and now you can see what happens when I press different keys on the keyboard, some of these or this byte here seems to be changing when I press. different keys, the other thing you'll see is this blinking, it looks like there are two types of transactions happening, so sometimes we get this whole report which is like what we manually decoded, but then if I keep triggering here, come on, too there is a smaller transaction. it's the same thing in the token packet, but instead of the data and acknowledgment we get this ability, this negative acknowledgment, this is basically the keyboard's way of saying that nothing has changed, I guess it saves a little time and width if no new keys have been pressed. or released so if we only want to see transactions with acknowledgments we can set up a trigger so go here and then type the type of trigger we want USB and then we can activate the trigger let's say we want a token packet and then we can configure the package.

ID to be okay, no, we want to see, we want to activate the acknowledgments, so it's a handshake package and then the acknowledgment, so let's do that and then the acknowledgment will be activated and there we go, now it doesn't flash between the acknowledgment and the skill is that we are only seeing transactions that end with an acknowledgment and one thing you will see is that sometimes the keyboard responds with the data zero and sometimes it responds with the data one, but otherwise everything is the same and there is really no difference between them . only the protocol says that every time a device sends data it should alternate between using data 0 and data 1 as the packet ID, so it really gives the receiver a basic way to detect if a data packet has been lost anyway.

I see that as I press the keys, the key codes are included in this data packet. If I press multiple keys, multiple key codes are included, so it simply lists the keys being pressed. That's pretty simple. The only thing that is different is how the modifier keys are handled. Notice that if I press Ctrl we get this here that appears if I press shift it's a two alt it's a four and then the Windows key here is an eight, so each of those corresponds to a single bit, so if I hold down a combination of those keys just represent the combination there, so if control is one and alt is four, one plus four, if I hold them down it's five and that's where the key on the left is and then the ones on the right, control shift and alt. on the right use this other nipple, so between that first bite you have a little bit for each modifier key, so the first byte is always the state of the modifier keys, the next byte is reserved and not used for anything as far as I know that that is always zero, which leaves uswith six bytes left, four keys that are pressed, so you can see a b c and if I hold down multiple keys, it just lists them all and I can hold down up to six keys and it will report.

Six keys are held down, which means if we press more than six keys simultaneously there's no way to detect that and we just get this error where they're all reported as one, so it's kind of an air condition, though seems. like there are smaller key combinations let's see yeah there we go q w and a if we hold it down we also get an error so there are smaller key combinations that also result in an error and that's probably because they share connections internally in the key matrix or something to save costs on the keyboard, but my understanding is that more sophisticated keyboards don't have that limitation and in fact can even negotiate with a computer to use a larger block of data so they can report more than six simultaneous keypresses, but as you can see six is ​​usually the default you get outside of any kind of fancy gaming hardware, still, there's a reasonably complicated initial setup that happens when you plug in a keyboard for the first time , so let me try to set this all up so I can capture as much as possible. of that as possible so we can open up a listing here so it's easier to see everything that's going on and then I'll reset this for a single shot to try to capture as much as I can and then go ahead and plug in the Enter the keyboard and let's see what we have and I won't go into this too much, but you can see it starts with a configuration packet and gets some data and then we have some communication here with what looks like an address. 1e, which I'm going to assume is the endpoint that is assigned for the keyboard when we first plug it in and there's a little more back and forth now that we have input for address one e and endpoint zero and remember that before it was the endpoint one, which is where we were reading what keys are pressed, but endpoint zero is used for sort of installing and configuring parameters, etc., and you'll see if we continue here here, this is, this is It's kind of interesting because We see that some of the data that is being transferred is 413c and 413c is the vendor ID that corresponds to Dell, so that is the keyboard that tells the computer that it was manufactured by Dell and then we have 2003 and 2003 correspond. to the particular model of keyboard I have, so you can see that there is a lot of negotiation that happens here before we can send keystrokes back and forth, but anyway, how about the original question?

Does all this USB complexity introduce anything significant? latency over the old ps2 interface, well certainly more data is sent when you press a key so initially you might think you know if a ps2 keyboard only sends 11 bits when you press a key and a usb needs close to 200 bits to do the same thing surely is something, but of course PS2 sends those bits at 16 kilobits per second compared to USB which is one and a half megabit for low speed or 12 megabits for full speed so you really know that the USB is much faster, the real concern. comes from the fact that when you press a key on a ps2 keyboard it immediately sends the scan code, but for USB the computer has to extract the keyboard by sending it in a packet of tokens, so how often are they sent?

Let's set up our trigger for USB and we want a token packet for a pid there we go and then if we back up and zoom out we can see that we're triggering an input token packet here and then we'll show you another one before and so we can see the period here and this uh this interval seems to be about 16 milliseconds and you know if it's being acknowledged with a skill or if it's sending data anyway, the polling seems to be done every 16 milliseconds, that's a big problem. I'm sure a ps2 keyboard only sends data at 16 kilobits per second, but sending an 11-bit scan code at 16 kilobits per second takes about 700 microseconds or 0.7 milliseconds, so here it looks like we'll have to wait until 16 milliseconds, you know? 0.7 milliseconds after pressing a key before sending it to the computer, so it's almost 20 times more latency with USB than with a PS2, so maybe there's something to that idea that the PS2 is better but not as fast, this is literally, it's like a cheap. low speed USB keyboard, you know, how about a better quality keyboard that runs at full speed?

You know that's going to make some difference, let's plug it in and then set it to full speed. You can see when I press the keys. What appears in the data here, one thing I notice that is different with this keyboard is that it does not send this data periodically, what happens is that if we turn on packet input for most packets, instead, everything what we get is a to a skill, it only sends data if it actually has something to report, so you can occasionally see it appear if I press a lot of keys, but for the most part, if nothing has changed, this particular keyboard just responds with a skill, which is fine, that's all. need to do it, however, the question is how often is the polling done and what you can see here is that if I set this to one millisecond per division and you look at the times here as well, you can see that it is pulling every millisecond and so therefore, extracting. every millisecond vs every 16 milliseconds, that's a big difference, so now that ps2 keyboard's 0.7 millisecond serialization delay doesn't have as much of an advantage over this one millisecond pull delay, in fact, since they're basically the same order of magnitude.

I'm convinced that there's really no practical advantage to PS2 over USB unless you're using literally the cheapest keyboard you can find and I think this is a really compelling way to see that I have a PS2 keyboard and a USB keyboard. both connected to the headset here and of course the USB keyboard

work

s every millisecond but I have the headset set to wake up on the ps2 keyboard clock so press the key and you can see the clock and data from the ps2 keyboard ps2, but then down. Here you can see the millisecond coming out of the USB keyboard, so these little beeps are every millisecond, and although the USB keyboard needs more bits to say what it says, those bits happen 12 million times per second versus 16,000 times. per second, the USB swap takes much less time, but with the poll here, of course, if you press a key on the USB keyboard here, you'll have to wait until the next poll here before the computer has any chance of seeing that, but I think overall this shows that either way, whether you're waiting to serialize the data from the PS2 keyboard or you're waiting for the next polling interval from the USB keyboard, these are basically the same, so I hope it gives you It was interesting, as always.

Thank you to all my patrons for helping make this video possible, you can join them in supporting me through the patreon link below and for more computer engineering videos and projects, don't forget to visit my website eater.net.