How does USB device discovery work?

a standard usb keyboard uses eight bytes of data to encode which keys are being pressed at any point in time the first byte encodes the modifier keys so ctrl shift alt windows key for the right side as well as the left side of the keyboard the next byte is always zero and that leaves this remaining six bytes to encode any other keys that are pressed and so each uh each of each of these six bytes can indicate the key code for a particular key up to six keys if i press a seventh key they all go to one indicating an error and i have to release some keys and it will encode only up to six simultaneous keys so this limit of being able to only encode six simultaneous key presses is referred to as six key rollover and perhaps it's a fine limitation for many applications but for some applications like gaming or i guess stenographers who are using multiple simultaneous keystrokes to encode entire words at once being limited to just six bytes here six simultaneous key presses can be a bit of a problem i'm looking at the electrical signals for the d minus and d plus uh signals in inside the usb cable and this oscilloscope is measuring those and then decoding them into the data here for more information on how this decoding is done you can check out i've got another video where i go into that in quite a bit more detail but in this video we're going to look at why this is limited to six simultaneous keystrokes and what we can do about it and what the usb protocol allows us to do about it as i briefly mentioned in that previous video when you first plug a usb device in there's some setup and negotiation that takes place the first thing that happens is the device signals whether it's a low speed device or a high speed device it's a low speed device it'll bring the d minus pin high if it's a high speed device it'll bring the d plus pin high and that tells the computer what speed to start communicating with it uh with in this case this keyboard is a low speed device so it's bringing this d minus pin high and then the computer goes ahead and resets it here and and then the computer will basically strike up this lengthy conversation where it where the keyboard is able to tell it about all of its capabilities and all sorts of information now capturing that entire conversation is a bit tricky because you can see if we zoom in here the data that's decoded is is kind of corrupted here because to sample such a long interval like this the entire setup conversation we end up getting fewer samples overall and we aren't able to decode the actual data from it whereas if we zoom in and our capturing we can get much more detail about a single packet so what i want to do is find a way to capture these single packets one at a time so we can see the entire conversation so for example if i disconnect this capture a single capture here and plug it in the first thing i get is a setup packet because what i'm doing is i'm i'm triggering on a an acknowledgement packet so any packet that's sent and acknowledged the acknowledge is here if we zoom in we've got our setup we've got our data and then we've got the acknowledge and so i'm triggering on that acknowledge so i'm getting that acknowledged but the problem is i can only get one at a time so to capture the entire conversation when we first plug the keyboard in what i can do is use this acquire function to do a segmented capture so we turn this on what this will do is it'll say capture some number of segments so i can say capture a hundred segments and if i disconnect this go into single capture it's now going to acquire 100 different segments that are all going to trigger on that usb acknowledgement so let's plug this in it goes ahead and captures all those and now i've got all these different segments so if i look at that first segment we see the setup and data if i go to the next one we see some more data go to the next one i see another setup packet and we can kind of keep going through these segments that are captured to see the entire negotiation that takes place when the keyboard's first plugged in so let's start at the top here so the first thing that actually happens we zoom in here is we get a setup packet and every setup package is addressed to a particular address and endpoint and that's what this zero zero is the address and then zero is the endpoint and so by default when you first plug a usb device in it doesn't have an address and so the initial configuration actually takes place using this address zero and then the data is going to follow a particular a particular format for for setup data and we can actually look in the usb spec for the format of that set of data setup data and this describes what what we're seeing here so the first byte is the request type and it has those characteristics of request and it's it's basically a bitmap so in this case our first byte is zero so all of these are zero which means it's host to device so the host the computer is talking to the device the keyboard this is a standard request and the recipient is the device the keyboard so that's what that first zero zero means the next byte five is the specific request it says refer to table nine three [Music] the requests are actually listed in table nine four here so this is a type five which is set address and then table nine three if we go look at that it shows us what the entire request looks like for set address so we've got a request type is zero set address this is the five that we're getting and then the next pieces of the request again if we go back to what the format of the setup data we have two bytes for a value two bytes for an index two bytes for a length so our value in this case is the zero c zero zero our index is zero zero zero zero and our length is zero zero zero zero and then value index and length all of that sort of varies depending on the particular request so that's why we go and look at this table here and so for a set address that value is the device address so this zero c00 that's the device address and these are sort of flipped around so to convert that it's actually zero zero zero c so the device address it's saying is c and these other two index and length fields for set address it just says those are zero and in fact those are zero so what's happening here is as i mentioned when the keyboard is first plugged in it has an address of zero well the first thing the computer does is it actually gives it a different address and that's what's happening here this is a set address to address c and actually if we go to the computer where this is plugged in and we do ls usb and run this command it's going to list all of the usb devices that are plugged in and we can see here it's detected the the dell keyboard that we just plugged in and the device here is device 12 and 12 of course in hexadecimal is c so we can see that this first command where it's assigning this address of c to the the device it actually actually seemed to have worked so once the computer sends this command uh one thing it's saying is is the last two bytes here is the length of data um bytes of uh you know number of bytes to transfer well if we go here well it's a zero so if we go to the next thing here we get an in trying to read the the result of that and here's the data and there's no there's no data here so this is essentially the acknowledgement if we kind of go over here a little bit we'll see the acknowledgement so this is the acknowledgement for that first set address command so we're setting the address we're getting the acknowledgement here with with no data and then the next thing that happens is another setup packet but look at this this setup packet now the address is 0c so now the computer is able to talk to the keyboard using that address that it just assigned 0c so that's the address and then the second parameter in the setup packet is the endpoint and this we're always going to see this as endpoint 0 for the setup stuff and that refers to the device's default control path so all of this setup stuff is happening on endpoint zero and we'll see actually once the keyboard is set up and operating the actual key presses are all happening on endpoint one but in the event we're now we've now got a second setup packet here and we can interpret this basically the same way where we just go kind of we've got eight bytes of data here and we can look at this same format here for a setup data request and decode what it means so in this case the first byte 8 0 is a little bit different that first bit is set so this is device to host so this is now we're going to transfer some data from the usb keyboard to the computer now of course the computer always sends the setup package the computer is setting the setup packet but the setup package is effectively asking the device the usb keyboard to send it some some data and the rest of the bits are zero so the type is standard and the recipient is still the device here but now the request the specific request is six so let's look up what six is six is get descriptor so the computer is sending a get descriptor command to the keyboard and that sort of makes sense why it was now this device to host because when the computer is saying get descriptor from the device from the keyboard it's expecting the device to return some data to the host so okay the computer's saying get descriptor so now what is this value index in length what are these next six bytes or refer to well if we look at what a getdescriptor does the value is the descriptor type and descriptor index and the way this is encoded the descriptor type is one the index is zero so what is descriptor type one well we've got a table of descriptor types descriptor type one is device so this is getting the device descriptor for index zero so the zeroth device descriptor and then get descriptor the index is zero or language id in this case it's zero and then the length is one two which is what would that be 18 in decimal so it's expecting 18 bytes so what's going on here is the computer is saying give me the descriptor or essentially the description of the device because right now we've plugged a usb device in the computer has no idea what it is it's assigned an address it doesn't know anything else it could be a keyboard it could be a mouse it could be a hard drive it has no idea so it's asking for the device descriptor something that describes what the device is and by the computer putting this length of of one two which is uh in decimal that's 18 bytes the computer's saying i expect the device descriptor to be 18 bytes long and that's because if you look at what a standard device descriptor looks like it is in fact you know 18 bytes 18 bytes long so that's what it's expecting to get back and if we go and look at the response what we see is we see some data so this is in and then we see eight bytes of data here and then if we look at the next segment here we have another eight bytes of data so we're up to 16 of our 18 and if we look at the next one we see where is it two more bytes of data so the request for the device descriptor that's requesting 18 uh bytes of data takes three packets to send it two eight byte packets and then a two byte packet and of course we could go through here and decode this whole thing so we could look at this this data that we're starting to get and you know we see the first byte is the length the size of the descriptor which is 1 2 or 18 bytes we see the descriptor type is one so it's a device descriptor the next thing we see is the usb spec release number in binary coded decimals what does that mean well this one zero zero one you flip that around and then you interpret it as it's described here and basically what that says is this this usb keyboard supports usb version 1.1 which is a fairly old version of usb but it's you know it's a low speed device so no surprise there so that's what's encoded there and then we've got our class subclass all sorts of other stuff that are described in here and we can we could decode all of this using the oscilloscope but i think an easier way to decode all of this because there's this conversation goes on for quite a while there's a whole bunch of information that the keyboard is sending to the computer and a much easier way to interpret this rather than scrolling through these waveforms is if we go to there's a lister here that will show it'll scan through all those segments and decode all of that data and we can either scroll through the data here and and read the same the same data we were just looking at or i could put a usb drive in here and save this data so we're going to save lister data to usb file name sure whatever press to save so we'll go ahead and hit that and that will save all this data onto this usb drive and we can now pull this data up on the computer where it might be easier to look at so once we export that data it gives us a csv file which we can look at here and this is what it looks like and you can see it's the same data we had before so here's that setup packet that's setting the address to zero c and then here is the setup packet to address zero c that's getting the device descriptor here's the response coming in and so on and so on this conversation just sort of goes on and on and on there's all sorts of information that's being sent by the keyboard until we eventually get down to this point here where the keyboard is just operating and here you see the in uh command going to address zero c the the address of the keyboard this time it's endpoint one and that's what's getting the actual report of which keys are pressed and so i think while i was capturing this i wasn't pressing any keys so you see all these are just zeros but if we were pressing keys we would see that but if we scroll back up this is all of the negotiation that goes on ahead of time to get that set up so what i'm going to do is create a filter here to make this a little bit simpler to look at just what we care about and we just care about the data and setup if we just look at those that should make this a little bit simpler and so here we go we can see our setup this is our setup command and in the for the first one there's no response for the second one here's our setup command and 1 2 is the length so that's in decimal 18 byte response and then here's that 18 byte response and so it just kind of keeps going here's the next setup command you're just expecting a two byte response there's the two byte response the next setup command is expecting what is that 2 4 in hex would be 30 36 bytes um in decimal so there's the response for that um and this you know just sort of goes on and on and on um you know here's a whole bunch of stuff that it's sending until we finally get to this port here where it's just uh replying with the the reports of what keys are pressed so this is the whole negotiation here to get the keyboard set up so the question now is what does it all mean well to make sense of it we can start by decoding each of the setup data packets because they all follow the same basic format there's the characteristics of request so direction and type and all that stuff that's the first byte and then the second byte is going to be the specific request and then there's two bytes for value two bytes for index two bytes for length and so i've kind of broken that out so these are all the various requests that are coming in that we captured and i've broken it out into that characteristics the the request and then the value index and and length there and then i've used the usb spec to just go ahead and decode what those actually mean so we can see in the spec that you know five is going to be set address so i can just decode that there or six is get descriptor so i've got all that decoded here and then depending on what the request is we might get some some data back from the keyboard or we might be sending data from the computer and so i've also sort of broken out what that data is and depending on the particular type of data so in this case this is a get descriptor for a device so the response is going to be a device descriptor and so the usb spec you know tells you what format a device descriptor is and what all the different data means so i've gone ahead and decoded that as well based on the usb spec so i've got this whole thing sort of decoded here and we can we can go through step by step and see the entire conversation that the keyboard and the computer have before uh before the keyboard actually starts working and i won't go through it in excruciating detail but i'll just try to kind of go through and hit some of the highlights so as we saw the first thing it does is it does the set address to give it an address and then get descriptor to get the device descriptor and so the device descriptor has you know some stuff in it's got the usb version of the keyboard supports um it's got the max packet sizes eight and that's for the the control channel so you know if you saw all these packets that we're getting are eight bytes that's that's that's why we've got a vendor id and product id that are that are sent to the computer as well as a version number for the keyboard and then it's got the these these string indexes so it's the manufacturer description product description and product serial number and it's saying that those are stored in these different strings so string one string two or string zero and then it says there's one possible configuration but the strings are kind of interesting because what that's saying is that the product description for example is in string two and the computer actually that's the next thing it does is it gets string two so it's doing get descriptor which is six but instead of the descriptor type being one for device remember if we look at the spec descriptor type one is a device it's getting descriptor type three which is for a string so descriptor type three is a string and then the index is two to get string number two which the device descriptor said corresponds to the product description so it's getting that string too that corresponds to the product description there's a field in here for which language it wants and there's a whole other spec where you can figure out what all those languages are and then it's saying that it's expecting a response length of 2 bytes and so in fact it receives two bytes but the format of this response is is defined such that the first byte indicates how long the string is so here it's saying the string is actually 2 4 bytes long or if we convert that to decimal that's 36 bytes so it's saying the string is actually 36 bytes long and then the second byte here just tells us what type of descriptor it's type 3 which is a string just confirming that so the computer is going to all the trouble of getting string 2 and it's it's not actually getting anything it's just getting the length because then what it can do is i can do the same thing it's a git descriptor string two but now it can say ah now i'm expecting the the full 36 bytes and now the response is going to be those first two bytes plus the rest of the bytes that are actually the string and this is all utf-16 encoded so if we decode that then what it spells out is dell usb keyboard which is a description of the device and so this is actually is actually pretty interesting so we as soon as we plug the keyboard in or any usb device in the first thing it does is it gets this device descriptor which tells it where to find the product description and then it gets the product description so the computer has at this point has no idea what this device is we just plugged some usb device in it could be a hard drive it could be a webcam it has no idea but what it does know is it knows this you know human readable string that describes it so if the computer has any problems you know configuring this or dealing with it or there's any errors then it can give us an error message saying hey there's an error with your dell usb keyboard and even though the computer doesn't actually know that it's a keyboard it can at least give us that message so if you've ever had that experience of plugging some usb device in and it doesn't work but the computer like quote unquote recognizes it and tells you what it is the computer may not actually really know very much at all about it at this point so anyway i thought that's kind of interesting the next thing it does is it gets another string this case it's string number one it does the same thing where it's getting two bytes to just to find out how long it is and then it gets it with the correct length in this case it the string spells out del and that's for string one which we saw up here string one is the manufacturer so it also gets the manufacturer so it knows that it's manufactured by dell and that is a dell usb keyboard but again the computer can't really do anything with that information other than just show the user but it's interesting that it does that first before it goes on to get the actual configuration which this is actually going to be information the computer can make sense of and so there's another get descriptor command says getdescriptor for configuration type which is two type two configuration zero there is only one configuration that was in the device descriptor told us that and it's expecting it to be a length of nine and if we look at the format of a configuration descriptor it is nine bytes long and it's all described here in the spec and i've interpreted the spec to to figure out what this particular configuration descriptor says and again i won't get too into the details here but one thing that's interesting is there's a nine byte configuration descriptor which is sort of a usb standard thing but then the usb device can have other configuration data and so part of the configuration descriptor is to tell the computer the total length of all configuration data and so that's what this field here is and it says that that length is 2 2 in hex and basically what happens is the computer then does another get descriptor for that configuration just you know the same same command again just kind of like we saw with the strings but instead of saying give me nine bytes it says give me 2 2 bytes because it knows now that that's how much configuration data there is and now it gets all this data describing all kinds of other things and so the first nine bytes are the same that's our configuration descriptor but then we get an interface descriptor an hid descriptor and an endpoint descriptor and all of this has the effect of describing to the computer that the keyboard is a what's called an hid device or human interface device device that has one end point and human interface devices are a whole other thing that has got it's got its own spec and i've got some of the pieces of that spec that i needed in order to decipher this printed out here but a human interface device is you know something that a human uses to interface with a computer so a keyboard or a tablet or a mouse or game controller all kinds of things like that so this configuration is describing to the computer that this is a human interface device and it has an end point it has one end point that's pulled every 18 milliseconds and that that end point is uh well it's endpoint number one which is sort of interesting because if we look at the oscilloscope here when we're just pulling the the keyboard when we press various keys and look at this at this response here we're receiving on n point one that's what this one here indicates and so what the configuration is describing is it's describing that endpoint as endpoint number one and it's and then just pulled every 18 milliseconds which is you know kind of what we're seeing here and when we pull it what we're getting here is this eight bytes of data that you know we saw before it has you know the list of keys that i'm pressing or that first byte that corresponds with the modifier keys if i'm pressing any of those this eight byte response here is referred to as a report because i guess it's reporting you know data from from the keyboard and so if we look in this configuration data here in the hid descriptor it says there's one hid class descriptor and that class descriptor type is report so this is saying that there there is a report descriptor and that descriptor length is 4-1 and you'll see later on where we actually get that but this is kind of the the first step there to say that that somewhere in all this data that we're going to get from the keyboard is a description of this report and that's going to be very interesting to take a look at the next thing we see here is a command that's sent from the host to device to set configuration um and then a configuration one so you know we got this configuration up here uh we know this is the only configuration and so i guess the spec says you've got to specify which configuration you want seems a little bit unnecessary since there's only one of them but anyhow we we set that there next we see a command the set feature instruction and the particular feature that's being set is device remote wake up and this is a usb feature that uh you know gives the ability so if if the computer goes to sleep or goes into power save mode or whatever some usb devices have the ability to wake the computer up and so this is setting that feature on the keyboard because the keyboard has that capability so for example if your computer goes into power save mode you want to be able to press a key in order to get it out of power save mode so this is just the host acknowledging or setting the keyboard to to sort of enable that functionality but now that's set up this next command here is the interesting one so the first thing that's interesting about this is the initial request type here is different than everything we've seen so far so far we've either seen things that are hosted device where the computer is sending an instruction to the keyboard so for example here this set feature that was hosted a device or it's been device to host where the computer's requesting something like it's getting one of those strings or it's getting the device descriptor or whatever but here that bit is still set so it's device to host so it is getting information from the keyboard but that last bit is also set so instead of device it's now referring to the interface so it's not getting information from the device it's getting information from the interface and the interface here uh we're actually sort of stepping outside of the the base usb spec and into the uh the hid spec the human interface device spec and this is where we're getting that report so we're getting a report descriptor and this this report descriptor thing that's defined in this hid spec and we're getting report descriptor zero for interface zero and we're expecting a response length of four one hex and that four one comes from our you know when we got our configuration before we had this hid class descriptor um with the report descriptor descriptor lack 4-1 so this is going to be the report descriptor and remember the report is is this is it's this data that we get from the keyboard that reports which keys are pressed so that's very interesting this is the descriptor for that so this that means this is describing what that data uh what that data format is so this is going to break out in excruciating detail what data the keyboard sends us on every report and all of these codes are defined in the hid spec in various places so for example the very first thing that it does if i can find it in here is this usage page so you can see zero five is going to be this code here so it's zero zero zero zero one zero one um is the prefix and then the the final zero one indicates that there's one byte following in that case the one byte is a one and that one is going to be specify the current usage page and to find that there's this whole set of hid usage tables that list various usage pages and other things and so usage page one is generic desktop and then if we get into generic desktop there's all kinds of different things defined there as well so once we're into usage page one next command is usage six so we see here usage six is keyboard and then once we get into usage keyboard um there's a sort of grouping collection that we start here and then there's end collection down at the end and then everything in here is sort of considered a collection which i'm not sure is all that significant for what we're looking at here but the next thing it does is it switches usage page again to usage page seven and so usage page seven is the keyboard keypad page so now if we look at the keyboard keypad page that's this page here it has all these various usage ids and if we actually look at what these are each of these ids corresponds to characters and actually as it turns out these are the same codes that get sent when we press a key so if i press uh you know keyboard end is 4d so if i press the end key on my keyboard sure enough there's a 4d that shows up so that's you know where all that's defined in terms of you know where in the spec it's defined it's this keyboard keypad page all of those ids are defined but anyway once we specify that we're you know looking at this keyboard keypad page there's um a series of other sort of commands that are sent in here there's local usage minimum maximum logic logical minimum logical maximum report size report count and so on and all of those again are defined in the hid spec so if you dig through this hid spec there's uh you know i don't know here we go there's there's logical minimum logical maximum all these things are defined and so anyway i've sorted all this stuff out and and decoded it all and this is this is basically what i've come up with here and so i'll just sort of describe what's going on here this local uh our usage minimum and usage maximum e0 and e7 that refers back to this keyboard keypad page and if we look up what e0 and e7 are we get over here e0 is keyboard left control so that's the the control key on the left side of the keyboard and then e7 is keyboard right gui and gui is the the windows key i think that's what the note here yeah windows key or it could be the option key on a mac or whatever so e037 is you know left control left shift left alt left windows key right control right shift right alt right windows key so it's those modifier keys okay so it's saying there's a minimum maximum of of those modifier keys there's there's eight of them and we're putting together a bunch of reports um so i'll go ahead and hear so report size is one bit and then there's eight reports so what this is basically doing is it's mapping these uh you know these these usages as the as the spec calls them of these different keys it's mapping them into um eight one bit reports where each report is either going to be a zero or one depending on whether it's pressed or not in other words this is this is defining this first this first bit um so this there this first byte rather of the report is and it's saying that it is these modifier keys and they're mapped each modifier key each of the eight modifier keys is mapped to one bit and then this last thing here input is saying that everything that we've we've sort of put together up up until this point we're going to create an input from that and that input will be a variable and so that's what's defining that first byte in the report so after we've defined that now we get report count 1 report size 8 bits and now this is input constant so constant as opposed to variable this is just a 1 instead of a two there constant means it doesn't change so that's defining this second byte here and remember i've said the second byte is always zero i don't know why it's always zero but it's always zero and here is the is the report descriptor saying that this is a constant next we've got a couple things here that are um maybe a little bit out of order i'm going to skip these next two sections just for now and get to this last section here which is report count six so that six means that there are six reports and this eight means that each report is eight bits well that of course refers to the following the remaining six bit uh six bytes here so each of these eight bit things is a report and there are six of them so that makes that makes sense and now this is saying this logical minimum logical maximum um is zero through ff which makes sense they're eight bits so it's going to be zero through you know 255 and then it's going back to usage page seven which again is this keyboard keypad page and it's saying the logical usage minimum is 0 and the logical usage maximum is ff so it's just mapping from 0 through ff all of the different keys that are defined on this keyboard keypad page usage page and then our input command here that's that's defining an input is is using type 0 which is an array and so this section here is defining those last six bytes and it's just saying that those six bytes correspond you know basically one for one to the to the key um key codes that are defined in the spec and that's and that's what we see that's the behavior we see and so this description is describing this input it's saying we have eight one bit reports that's one input then we have eight bits of constant that's nothing and then we have six reports that are eight bits each as an array and those are our inputs so we see input input and input so that describes the the input from the keyboard that we're seeing here now what about these other sections here these output sections well this suggests that there's also an ability to send output to the keyboard and in fact there is you know if we're looking at what's going on in the scope now we're receiving data from the keyboard but that's because we're sending or the computer is sending an in command to uh to the keyboard at endpoint one and it's receiving this six or this eight byte report back but if the computer sent an out command it could also send data to the keyboard and the format of that data is described by any of these sort of output things here so let's take a look at that so here we have three reports one bit each from usage page eight so what is usage page eight well usage page eight is the led page and if we look at what the the minimum and maximum is one through three so one is num lock two is caps lock three is scroll lock so those correspond to the three leds that you would see on the keyboard and all sorts of other leds you could i guess potentially have it's kind of crazy um in the spec but in any event this keyboard supports three leds and it just maps them one bit each into three reports and it says that's output and then we've got one report of five bits that is constant and i think what that's doing is it's just saying we've got three bits corresponding to the three leds and we're just gonna have five bits that are zero so that gives us eight bits total so that if you wanted to set the leds you would send an out command to the keyboard and then data would just be one byte and only three of those bits in that byte are used to set the leds so this is describing describing that and all this data remember is coming from the keyboard so the keyboard is telling us this is how i communicate and it's up to the computer to just understand and adhere to this so once the the keyboard sends this the computer sends a couple other commands it sends a set idle which is an hid specific command that says that if if nothing changes on the keyboard for 24 milliseconds don't send a report and then set protocol to the report protocol which is just basically saying you know use use this report protocol and then the last command that is sent before we start receiving keys is a set report to interface zero and it's one byte and it's that one byte is zero which i believe what this is doing is it's setting all the leds to off so when we first plug the keyboard in in case they were in some other state the computer's setting them all off and that's it that's that whole conversation when we first plugged the keyboard in so back to that question of how we could support more than six keys being pressed at the same time well if we look at that report descriptor you can probably imagine a few things that we could change in here one for example is change this from six reports to something more than six and we could presumably support however many key presses we wanted to but hopefully it makes sense to you that this format gives us enough flexibility to design a keyboard that does support you know true and key rollover the next step of course would be to take a look at an actual keyboard that claims to support end key rollover and see how it actually works and so i've got one here and that's what i'm going to do in the next video because it actually turns out that this is a bit more complicated than i expected to get it to reveal its secrets but in the next video i'll show how this keyboard actually supports n key rollover so make sure you're subscribed to the channel so you don't miss that and of course as always i want to thank all my patrons who help make these videos possible you can join them over on patreon and let me know what other types of videos you'd like to see and of course check out my website eater.net where i've got all my videos cataloged as well as various projects and things

Channel: Ben Eater

Views: 197,865

Keywords:

Id: N0O5Uwc3C0o

Length: 36min 15sec (2175 seconds)

Published: Sat Jul 10 2021

Reddit Comments

[u/B8F1F488]

>$6k oscilloscope <3

[u/Venthe]

I just love his content, even if it's so far removed from my day job that at times all I can do is nod :)

[u/drdabbles]

Ben puts out such good content so consistently.