Javan Cook

Getting Data from a Controller

Sat, 29 Aug 2015 00:00:00 +0000

In the previous post we used Linux to find the Endpoints for the USB Xbox controller. We also used Tattiebogle’s post on wired controller information to identify the purposes of the different Interfaces so we know which of the Endpoints to target for information. This leaves us with the final step for the first item on the checklist; detecting the inputs from the controller. In order to achieve this, we need some way of interacting with the Endpoints. Given I was planning on using Python for this project the module PyUSB seems like the logical choice. The previous link provides details for installing the module and there is a PyUSB tutorial available containing a wealth of information.

The main three lines of code we need from PyUSB are:

>>> usb.core.find(idVendor=a, idProduct=b)
>>> dev.set_configuration()
>>> dev.read(x, y, z)
>>> dev.write(x, y, z)

The first line is used to detect if a USB device of the correct Vendor and Product identifiers is connected. We obtained values for a and b in the previous post and found that a = 0x045e and b = 0x028e. The second line is used to set the device’s Configuration, as there is only one Configuration in this case there is no need to specify. The final two lines are used to read and write data to the device respectively. Here x is the Endpoint address, y is the number of bytes to read or the data to write and z is the timeout time. Again, x and y were determined in the previous post as the bEndpointAddress and the wMaxPacketSize respectively. The final thing left to do before probing the device for data is to pick the right Endpoint to query to get the controller status. It turned out that this is slightly more tricksy than I initially thought.

From Tattiebogle’s controller information it was determined that Interface 0 is the one responsible for the status of the controller. In the literature it was stated that typically each Interface would correspond to a single device function. In this case, Interface 0 incorporates a number of sub-functions including the LED status and the mic status, as well as the control status. It is therefore necessary to query the same Endpoint several times to get to the pertinent information. I’ve prepared some code to do exactly that below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#Import PyUSB and sys
import usb.core
import usb.util
import sys

#Find device
dev = usb.core.find(idVendor=0x045e, idProduct=0x028e)
#Is the controller there or not?
if dev is None:
 sys.exit('Controller not present, please insert and try again.')
else:
 print('Controller present.')

#Configure device
dev.set_configuration()

#Get packets
for x in range(0,5):
 packet = dev.read(0x81, 32, 100)
 print('Packet', x+1,':', packet)

When running this code it may return ‘usb.core.USBError: [Errno 16] Resource busy’. If this happens use $ sudo rmmod xpad to stop the default Xbox controller driver running. This should return the following answer:

Controller present.
Packet 1 : array('B', [1, 3, 14])
Packet 2 : array('B', [2, 3, 0])
Packet 3 : array('B', [3, 3, 3])
Packet 4 : array('B', [8, 3, 0])
Packet 5 : array('B', [0, 20, 0, 0, 0, 0, 88, 253, 184, 7, 58, 3, 255, 0, 0, 0, 0, 0, 0, 0])

This matches up nicely with the information obtained by Tattiebogle where Packet 1 is the LED status, Packet 4 is the mic status and Packet 5 is the status of the controls. The format is a bit odd and it will require some work to make it usable but it is definitely the control status and ticks off the first item on the list of requirements. I’m not going to analyse the contents of Packet 5 immediately, that can wait until item three on the list of requirements is addressed, but feel free to consult Tattiebogle if you can’t wait. Instead I’m next going to address transferring data between a client and server.

Checklist

~~A way of detecting the inputs from a controller.~~
A way of transferring this information from a client to a server.
A way of replicating the inputs on the server side as outputs to the 360 console.
A way to view the gameplay.
A way to control the TV.

Getting Information about a USB Device

Fri, 28 Aug 2015 00:00:00 +0000

In the previous post an introduction to USB protocol was presented. Given what was learnt in that post, the next step for the Remote Xbox Project is to both figure out how to extract data from the wireless Xbox controller and make sense of it. The first step in this process is to identify the different Interfaces and Endpoints within the device. To do this the I used lsusb from usbutils on my raspberry pi obtained using $ sudo apt-get install usbutils. After connecting the controller, I then used the command $ lsusb, which returned the list of USB devices currently connected to my raspberry pi and looked like this:

Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 005: ID 045e:028e Microsoft Corp. Xbox360 Controller
Bus 001 Device 004: ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter

As you can see, the Xbox controller is Device number 5 and has a Vendor id of 045e and a Product id of 028e in hex. We can now use lsusb to inspect it in more detail using the command $ lsusb -d 045e:028e -v , where -d shows only the device of the specified vendor and product id and -v provides more detail.

Bus 001 Device 005: ID 045e:028e Microsoft Corp. Xbox360 Controller
Couldn't open device, some information will be missing
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass       255 Vendor Specific Subclass
  bDeviceProtocol       255 Vendor Specific Protocol
  bMaxPacketSize0         8
  idVendor           0x045e Microsoft Corp.
  idProduct          0x028e Xbox360 Controller
  bcdDevice            1.14
  iManufacturer           1
  iProduct                2
  iSerial                 3
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength          153
    bNumInterfaces          4
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumInterfaces           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass     93
      bInterfaceProtocol      1
      iInterface              0
      ** UNRECOGNIZED:  11 21 00 01 01 25 81 14 00 00 00 00 13 01 08 00 00
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               4
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               8
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           4
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass     93
      bInterfaceProtocol      3
      iInterface              0
      ** UNRECOGNIZED:  1b 21 00 01 01 01 82 40 01 02 20 16 83 00 00 00 00 00 00 16 03 00 00 00 00 00 00
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               2
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               4
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval              64
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval              16
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass     93
      bInterfaceProtocol      2
      iInterface              0
      ** UNRECOGNIZED:  09 21 00 01 01 22 84 07 00
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval              16
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        3
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    253
      bInterfaceProtocol     19
      iInterface              4
      ** UNRECOGNIZED:  06 41 00 01 01 03

As you can see from the results above the controller has one Configuration with four Interfaces and no Alternate Settings to worry about. Interface 0 has two Endpoints, one IN and one OUT; Interface 1 has four Endpoints, two IN and two OUT; Interface 2 has one Endpoint, an IN; and Interface 3 has no Endpoints. Also of interest is the fact that all the Endpoints are of the interrupt transfer type. Now that we’ve established the details of the different Interfaces and Endpoints, and most importantly their addresses, we need to figure out what processes they correspond to and where to extract the controller inputs from.

Fortunately, this has already been done within Tattiebogle’s post on wired controller information. He found that Interface 0 corresponds to the data from the controller, including the status of components such as the rumble motors, the LED ring and whether the headset is present, as well as the controls status. He also speculates that Interface 1 is for the audio data for the mic and speaker in the headset and Interface 3 is a security measure used by Microsoft to check that the controller is licensed. This latter point makes sense due to the lack of Endpoint associated with Interface 3 and the presence of what appears to be a proprietary chip on the controller circuit board. This also has implications for item three on the checklist, replicating the inputs on the server side as outputs to the 360 console, and as such will be discussed in more detail in a later post. No speculation is offered for the role of Interface 2. As it possesses only a solitary IN Endpoint, I reckon it could be for the chatpad accessory. This is something I’ll be investigating further, once I acquire a chatpad, along with extracting data from the Endpoints in the next post.

An Introduction to USB Protocol

Mon, 24 Aug 2015 00:00:00 +0000

In order to begin fulfilling the first item on the Remote Xbox checklist a I needed to find an input controller. Fortunately, I happened to have a wired Xbox 360 controller that I could use. That left me with having to figure out how to extract the inputs using the raspberry pi. It turns out that there are plenty of pre-existing solutions to solve this problem, including using xboxdrv combined with pygame as described here by Martin O’Hanlon in his post on using an Xbox controller to control a robot. However, it seemed like it would be more fun to figure things out from the beginning myself and as such would require me to carry out some research on how USB devices actually work. This led me to the websites USB Made Simple, Beyond Logic’s USB in a NutShell and Microsoft’s Concepts for all USB developers .

These sources provided me with a rudimentary knowledge of USB devices, enough to get started with anyway. Essentially, in addition to a Vendor and Product identifiers, USB devices feature Configurations, Interfaces and Endpoints, a combination of which control how the device works. The top level is the Configuration which controls what the device does. Whilst a device can have more than one Configuration associated with it, only one can be active at any time, and it is selected by the device driver. A given Configuration can have a number of Interfaces which specifies the functions of the device, usually one function per Interface. Again, Interfaces can have alternate settings associated with them and only one can be active at once. Finally, Interfaces have Endpoints which are used to transfer the data in and out of the device and cannot be shared between Interfaces.

Figure 1: An example of a USB device. This device has one Configuration and two Interfaces, one of which has an alternate setting. The Interfaces have different Endpoints associated with them. Endpoint 0 is the control Endpoint used to configure the device.

Every USB device must assign a bidirectional control Endpoint at the 0 address. This is so information about the device can be obtained and the Configuration for the device can be set. The data Endpoints are unidirectional (IN or OUT) and have one of four types (control, interrupt, isochronous and bulk). IN and OUT are relative to the host, so IN is a transfer from the device to the host whilst OUT is a transfer from the host to the device. A typical example of a USB device using Figure 1 would be that of a webcam with a built-in microphone and speaker. Here Interface 0 would correspond to the camera of the device. The Alternate Setting 0 would be active when the camera is not in use to save bandwidth as it has no Endpoint associated with it. Alternative Setting 1 would be active when the camera is in use and the IN Endpoint is used to transfer the video data from the camera to the host. Interface 1 would correspond to the microphone and speaker, where Endpoint 1 would take noise detected by the microphone and transfer it the host whilst Endpoint two would take data from the host and output it from the speaker.

As mentioned above, there are four different types of transfer available for an Endpoint. The transfer types each have their own properties which makes them suitable for different applications. Control transfers are used by Endpoint 0 when configuring the device and are used for command and status operations. Interrupt transfers are used to provide regular status updates from a device and have included error checking so the data arrives error free. Isochronous transfers are used to transfer large amounts of time sensitive data, such as video or audio streams, where it is less important if a packet of data is dropped on the way. Bulk transfers are also used to transfer large amounts of data, however, they are assigned the remaining bandwidth that has not already been allocated to interrupt and isochronous transfers. As such, they are primarily used for non-time critical applications, such as print jobs, and they are error checked with guaranteed delivery unlike isochronous transfer. So for the example above the camera Endpoint would use isochronous transfer whilst the microphone/speaker Endpoints would likely use interrupt transfer.

The Remote Xbox Project

Mon, 17 Aug 2015 00:00:00 +0000

This year for Christmas I was lucky enough to get a couple of Raspberry Pi devices and a load of miscellaneous accessories and gizmos. After getting back in to Python by making some flashing lights and random number generators, I was looking for a new project. I toyed with making them into media servers or retro game emulators but in the end I didn’t really have any need for either of those things. Instead I decided that I wanted to try something new where I could learn some new things and increase my knowledge of Python, preferably involving hardware of some description too.

I decided to try to implement some sort of system to play my Xbox 360 remotely whilst I am away from home. This would involve a number of different coding stages to make it work and would also require modifying hardware. The recent announcements from Microsoft regarding streaming Xbox One to Windows 10 devices and the backwards compatibility of the Xbox One have rendered this project redundant. However, as this was more of a learning exercise than an alternative to these services, and given I started this in January, I’ve continued with the project.

In order for this project to work, I needed to integrate a number of features:

A way of detecting the inputs from a controller.
A way of transferring this information from a client to a server.
A way of replicating the inputs on the server side as outputs to the 360 console.
A way to view the gameplay.
A way to control the TV.

This is the checklist of essential features that I’ve worked on in an attempt to make this project succeed. This will be updated in subsequent posts as progress is made and some optional extras may be incorporated if feasible.

Making This Blog

Sun, 16 Aug 2015 00:00:00 +0000

I first heard about Github pages from my friend Matt whilst looking for a place to host a blog for free that I could use to document my progress on various projects. As I wanted to be able to produce content using my Windows based laptop I initially followed a guide by @juthilo which worked really well. The only point at which I found this guide lacking is for if you plan to use pygments for syntax highlighting. When posting samples of code, I found initially that pygments wasn’t working despite being installed sucessfully. After visiting the pygments website I found that I needed to generate a stylesheet first.

I first used the following code in the Python command line to check which styles were already installed:

>>> from pygments.styles import STYLE_MAP
>>> STYLE_MAP.keys()

From the list this provided I selected paraiso-dark, based on some experimentation on the pygments website. Having selected my style of preference I then needed to generate my CSS stylesheet. To do this I put the following line into the command prompt:

pygmentize -S style -f html >output.css

Where “style” is the name of the style obtained earlier and “output.css” is the output file.

The majority of the rest of the blog was produced using the documentation on Jekyll and Bootstrap in conjuction with the Andrew Munsell tutorial. The search bar was modified from Dave Taylor’s site whilst the tag and category search function was modified from Alex Pearce’s site. Finally, the next and previous post buttons were adapted from David Elbe’s site and my favicon was generated using Favic-o-matic.

As you can see, most of the elements of this blog have been cannibalised from other people’s sites. However, being new to HTML, CSS and Javascript, it has been fun learning experience to adapt them to my needs and make them all work together.