For the display shown below, the analyser has been set to display only Bus States, and the highest level Transfers. Each Control Transfer shown is made up of a series of transactions, each of which is made up of a series of packets, as we shall see later.

The capture begins 1.9 seconds before the mouse is plugged in. The analyser indicates that the device has been plugged in, and that it a low speed device (because the pull-up resistor is on D-). After 3 ms, because the host is not yet allowed to send any data, the device is SUSPENDED because of not seeing any activity on the data lines. Shortly afterwards, the host issues a RESET which in this case lasted 31 ms.

It then performs a Get Descriptor request (to the default address 0), to discover the maximum packet size defined for the control endpoint. Having got this information, it resets the device again, and then sends a Set Address request, setting device address to 1 in this example.

All the requests from now on are sent to device address 1. The host has now requested the device descriptor. (Click here to see analysis of the device descriptor in a separate window). It has also requested the first nine bytes of the configuration descriptor collection. Remember that when the host requests the configuration descriptor, it will also get, following it, the interface and endpoint descriptors and maybe others. But the host doesn't know the total length of this collection. It does, however, know that the configuration descriptor itself is 9 bytes long, and that this descriptor contains a value for the total length of the descriptor collection. So it starts by requesting just the configuration descriptor using Get Configuration Descriptor with a required length of 9. (Click here to see an analysis of the configuration descriptor collection in a separate window.)

Additionally the host has requested String Descriptor 0, for the list of supported string languages, and descriptor index 2, which in this case has been assigned to the product description string.

After this it can be seen that the host has asked for much of the information again. This can occur for various reasons, such as the different drivers in the stack each asking the same questions for their own purposes.

The host has then sent the Set Configuration request, and from that point in time, the device is 'configured' and is able to perform its purpose in life. The host is now able to send the HID class request 'Set Idle', to tell the device only to respond to an interrupt IN transaction if a new event occurs. (In any case when an IN request is sent and there is no change to report, the device will respond with a NAK packet. The analyser has been set not to display these 'NAKed' transactions so we will not see them here) It then also requests the HID class report descriptor, which in this case informs the appropriate driver to expect to receive a 4 byte report of mouse events on its interrupt IN endpoint.

At this point the driver starts sending interrupt IN requests, and when any event is available to be reported the interrupt data transfer succeeds and 4 bytes of data are transferred.

You may notice that there was a nearly 3 second gap before the mouse was first moved. In the meantime there were still regular interrupt IN transactions, which were NAKed by the device, as it had nothing to report. To avoid the display being swamped by these NAKed transactions, the analyser has been set not to display them.

As you can see the Get Device Descriptor is made up, in this case, of five transactions. The first transaction (SETUP) comprises the setup stage.

The next three (IN) transactions represent the data stage, during which the 18 bytes of the descriptor are transferred back to the host.

The final (OUT) transaction is the status stage, to acknowledge successful completion.

Each of these transactions is made up of packets. By selecting some of these transactions to expand, we can see the details of the packets. Notice that we have chosen to expand only one of the three IN transactions, to keep the picture smaller. Notice how, for example the SETUP transaction is made up of three packets. You should be able to recognise the component parts of each packet by now.

A good analyser will be able to show you the data from the descriptor in an analysed form, to save you the trouble. (Click here to see analysis of the device descriptor in a separate window).

Device Descriptor Analysis

In a similar way, we might have selected the configuration descriptor set to display in analysed form. The interface descriptor tells us, and the host, that it is a HID class device. The bInterfaceSubClass is usually 0 in HID class devices except for a mouse or a keyboard which meet the simplified protocol requirements for being operated by the BIOS code, before the usual USB drivers have been loaded. In this case we notice that the device will work with the boot interface and (from bInterfaceProtocol) that it is a mouse. The usual HID driver will learn about this in another way; by parsing the HID report descriptor.

We notice that this device has a single Interrupt IN endpoint in addition to the default control endpoint, and that it is set to be interrogated once every 10 ms and expects the host to read 4 bytes each time. (Click here to see a fuller analysis of the configuration descriptor collection in a separate window.)

As with any HID device the descriptor following the interface descriptor is the HID descriptor whose main job is to tell the host where to find the HID Report Descriptor. This is the means by which the device can specify what it is and the detailed content of reports it may send and/or receive.

We have learned that when the device has been configured, the host will start an IN interrupt (on endpoint 1 IN) to read a report or reports up to 4 bytes long at intervals of 10 ms (or possibly less, typically it would be 8 ms with Windows).

So once the mouse is configured, the picture above represents the communication channels possible in the mouse. It still has the bi-directional control endpoint, and can receive the six HID class requests shown in the picture, and it has the interrupt IN endpoint, for sending its reports of mouse events. Typically, and in our example here, the only class request out of the 6 defined HID requests which is used, is the Set Idle request.

We can now select the Get HID Report descriptor to analyse. The display below shows the contents and significance of the HID report descriptor, which, using a form of coding specified in the HID specification, defines one or more reports which are the means of transferring information to or from a HID device. The parsed form of the report desriptor is shown below. Parsing a HID report is a fairly complex operation, so the analyser has helped out by displaying the defined reports, or in this case the one report defined. It is a single Input report, with 5 buttons, and X and Y movement, and a wheel movement, which make up a total of 4 bytes to match the maximum size of the interrupt endpoint.

To complete the picture we now examine the content of one of the interrupt transfers (events 4103 to 4105 in the first sequence we looked at). The bytes transferred were 00 01 00 00. If we select the Interrupt Transfer to analyse we will see how the meaning matches up with the parsed report descriptor analysis.

We can tell from this that the mouse moved 1 unit in the X direction.

What have we not examined?

We have not seen any Keep Alive signals in our displays. There is at least one Keep Alive signal every frame, or every 1 ms. This makes for a very cluttered display, even when they are grouped together by the analyser. So we have set the analyser not to display the Keep Alive pulses for the sake of this discussion.

In the same way, the interrupt IN transfers have only been shown when successful. Every 8 ms there was an attempt to perform an IN transaction by the host, and most of these were NAKed by the device. The analyser was set not to shown these NAKed transactions.

Here is a section of the capture containing these elements with the analyser set to reveal them. In addition, one of the NAKed interrupts has been expanded so you can see what it is built up from.