GIMX - Game Input MultipleXor

Recommended bluetooth dongle

2011-08-20T15:20:00.008+02:00

I finally found a compatible, low price, worldwide available bluetooth dongle. The brand name is "Pluscom", it's quite unknown, and the model name is "BT-20". The chip inside this dongle is a CSR Bluecore4-rom, and what's even more surprising is that it's written "CSR BC4" on the product package.

This dongle is available on ebay: link. The price is good and the seller is in the UK, which should provide a faster delivery than China to people living in the EU or the US.

The shape of this dongle is exactly the same than my Peabird PEAB-BT-SM04C-100M (CSR Bluecore4-rom). It's not a very common shape for bluetooth dongles, so that I think it's highly possible that these dongles come from the same factory.

Killzone 3 video by McKack

2011-08-01T11:10:00.002+02:00

This video was recorded running the windows version of GIMX (0.23), which operates over a usb connection.

French review by PgunMan

2011-07-14T22:39:00.007+02:00

Following video is a French review of the usb controller running in Windows.

It's made by PgunMan, a gamer who tests a lot of mouse controllers for both the PS3 & 360.

Online gameplay at 9:00.

Project forum

2011-07-07T21:09:00.004+02:00

A user nicknamed "DjDean" proposed me to launch a forum that will help to organize the information about the sixaxis emulator, and I thought it was time to do that.

Hopefully this will make the support easier than with a blog, and this will help to start a community around the sixaxis emulator.

I chose the domain name "gimx.fr". GIMX stands for "Game Input MultipleXer". I'm intentionally not mentioning the ps3 as I also may target the XBox360 some day...

Most of the information is already moved to this new forum. The layout/design is not definitive.

Forum link: http://gimx.fr/forum/

Stats over a year

2011-07-04T10:41:00.004+02:00

I started blogging about this project in February 2010. Following chart from google analytics shows the fluctuation of visitors.

There were a few peaks:

2 news on hackaday in April/May 2010
in September 2010, due to the psgroove, many people looking for avr usb dev boards
in December 2010, a thread started on gtrp.de about using macros for GT5/B-spec
in Mars 2011, the Kinect-PS3 was released
in May 2011, news on many websites (hackaday, korben, dashhacks, ps3hax, logic-sunrise, psx-scene, psgroove...)

Test package for Duke Nukem Forever

2011-07-02T08:54:00.004+02:00

Instead of using the left stick state to compute movement (the standard way), DNF is using events.

As a result, there is no more movement if the left stick is kept in a position. This is due to the fact that the sixaxis emulator doesn't flood the PS3 with useless events like a real sixaxis. If there is nothing to send, an event is only sent after 1s so as to keep the connection alive...

I built a test package for DNF players: link (i386).

Some more videos by McKack!

2011-06-28T14:35:00.006+02:00

Many people might remember the first video showing the sixaxis emulator in action. It was made by McKack with sixemu v0.11 (Linux+bluetooth).

McKack has made some new videos with the sixemu v0.23 (Linux+bluetooth):

Infamous, Wii Classic Controller

Call Of Duty: Black Ops, Keyboard + Mouse

Thanks McKack!

I added these videos to the "Videos" page of this blog. If you make some videos like that, please give me the links so that I can add them!

Version 0.23 released

2011-06-13T23:19:00.014+02:00

Main improvements:

windows version (usb connection only)
"set dongle address" tool of sixemugui is fixed
"replace mouse dpi" tool of sixemuconf is fixed

All corrected issues:

Download links:

ubuntu package - i386 - amd64 - updated June 16
windows setup (usb connection only)
firmwares-0.23.zip (avr usb firmwares for the usb connection)
CP2102 windows drivers

Known issues:

[linux] the sixstatus gui generates movement glitches (work-around: use 100Hz or lower for the calibration)
[windows] the COM port is not detected (work-around: check the proper COM port in the device manager)
[usb] the controller state is wrong (work around: unplug/replug the teensy board)
[usb] game compatibility: there are some compatibility issues with games like GT5 and Fallout: New Vegas. These games seem to have compatibility issues with gamepads other than the sixaxis/dualshock 3 controllers. Considering game compatibility, it seems the best solution is to emulate a true wired sixaxis/dualshock 3 controller. My first releases won't do that, and I will work on that later.
[usb] buttons can't work as pressure-sensitive buttons: it's useless to configure them in the "Axis" tab of Sixemuconf
[windows] extra mouse buttons are not working

About the windows port

I got a few issues to solve for the windows port. It turned out the official SDL 1.2 library (cross-platform) isn't providing raw events from the mouse. No problem, I checked out the manymouse library and built a custom SDL library that provides raw mouse events.

Many people see the sixaxis emulator only as a mouse+keyboard converter. But it does a lot more than that. It also allows to use ANY game controller (gamepad/wheel...) with custom control mappings. It especially allows to use the XBox 360 controllers that work out-of-the-box (except the X button). What about the sixaxis/dualshock 3 controllers? I wrote a post about QtSixA some time ago. This software allows to use the sixaxis/dualshock 3 controllers in Linux, and can be used with the sixaxis emulator as it emulates a standard game controller. There also is a software that allows to use sixaxis/dualshock 3 controllers in windows, it's called Motioninjoy. It's not open-source, and there are some ads in the GUI, but it's free, comes with signed bluetooth drivers, and is very complete: motion sensing (tested - I managed to control the crosshair in COD:BO...), rumble, but also macros and rapid fire...

Teensy 2.0 + CP2102 board

2011-05-30T23:51:00.013+02:00

I received my Teensy 2.0 board. I ordered it to check that the hardware I am suggesting (for the usb connection) works.
Delivery was very quick, it took a week from the US to my home (France).
The Teensy 2.0 works fine with the CP2102 board I tested in my previous post.

My PC to PS3 usb controller:

I directly soldered the Rx and Tx pins of the CP2102 board on the Teensy. I added a small wire for the grounds.

Note that this assembly requires to be handled with care: if you plug the Teensy, then hold the Teensy, and if you plug the CP2102 board, then hold the CP2102 board. If you don't do that, each board can be damaged (in the long term) near the Rx-Tx pins.

Warning: this hardware solution doesn't work with sixemu <= v0.22 because the serial connection doesn't work at the right speed (v0.23 solves this).

CP2102 USB to serial TTL converter

2011-05-25T21:38:00.011+02:00

I received my CP2102 usb to serial TTL converter bought on ebay from China for 2.8€ (about 4$). The delivery from China to my home (France) usually takes about 3-4 weeks, but this time I was lucky as it arrived in less than 2 weeks :)

As showed in the following picture, I connected it to my Teensy++:

Blue outlined, the CP2102 board, and red outlined, the Teensy++.

First tests were not so hopeful, as it doesn't work as-is with the latest sixemu package (v0.12).

I had to deal with 2 problems:

Rx and Tx pins are for the target device.
The max speed reachable by the Linux driver is 921600 bit/s and not 1 Mbit/s as written in the datasheet.

I inverted two wires, and changed both the emitter (CP2102) and receiver (Teensy++) speed to 500Kbit/s.

My benchmark program shows that we can reach about 45bytes/ms only writing and about 40bytes/ms writing and reading at the same time. This is good enough for the application. Running at 250Hz, I measured a 6.7ms worst latency, and a 5ms average latency.

Conclusion: this cheap CP2102 converter from ebay seems usable! I will test it further playing over a long time to see if it's reliable.

Warning: this hardware solution doesn't work with sixemu v0.22 because the serial connection doesn't work at the right speed (next release will solve this).

DIY pc to ps3 usb controller

2011-05-23T21:43:00.032+02:00

Moved: link.

» Outdated content «

This post explains how to build a pc to ps3 usb controller, that can be used with the v0.23+ sixemu packages.

Warning: I'm not responsible for any wrong hardware you can buy, or anything you can do with this.

Required hardware:

a usb to serial TTL converter - 1Mbps recommended - chip examples: FT232R, CP2102
a usb development board with a chip among the following: at90usb82, at90usb162, at90usb646, at90usb647, at90usb1286, at90usb1287, atmega16u4, atmega32u4

Examples:

USB to serial TTL converter:

CP2102 converters on ebay (as low as 4$)
FT232R converters on ebay (as low as 15$)
CP2102 converter at sparkfun (22$ excl. shipping costs)
FT232R converter at sparkfun (15$ excl. shipping costs)
Some devices like the arduino have an on-board usb to serial chip
A second usb development board can also be programmed as a usb to serial converter.

USB development board:

Teensy board (atmega32u4, 16$ excl. shipping costs)
Boards used for the psgroove hack (check the on-board chip).

The hardware I used for my tests is the following:

Arduino duemilanove (on-board FT232RL) + Bumble-b (discontinued, at90usb162)
Arduino duemilanove (on-board FT232RL) + Teensy++ (at90usb1286)
CP2102 board (from ebay) + Teensy 2.0 (atmega32u4)

I suggest the CP2102 converter from ebay (very low price, but unknown quality and probably low delivery) and the Teensy board (low price, good quality, and standard delivery). I didn't tested this hardware myself, and I will test it as soon as I receive it.

So, you have a usb to serial TTL converter, and a compatible usb dev board?

I/ Load the firmware on the usb dev board

The following archive contains all firmwares: link. I only tested the at90usb162, at90usb1286 and atmega32u4 firmwares.

Load the proper hex file to your board with the Teensy loader, the Flip utility from Atmel, or the dfu-programmer command-line tool.

dfu-programmer example:

sudo dfu-programmer at90usb162 erase ; sudo dfu-programmer at90usb162 flash at90usb162.hex

II/ Connect the two devices

The only thing you have to do is to solder 3 wires between these two devices:

GND <--> GND
RX <--> TX
TX <--> RX

The example below shows how to connect a CP2102 converter (left) to a Teensy board (right):

Warning: Rx and Tx may be inverted on the usb to serial TTL board.
The CP2102 converter in the above example has inverted Rx and Tx.
If you use the arduino on-board USB to serial converter, Rx and Tx are inverted.

III/ Connect it & use Sixemugui-serial

Connect the USB to serial converter to your PC, and connect the usb dev board to your ps3. Turn the PS3 on (the ps3 button is not working yet). The ps3 should detect a joystick (turn a sixaxis on, it should be detected as controller #2).

If it's not already done, install the sixemu package (v0.23 or higher).

Start Sixemugui-serial:

The USB to serial TTL converter should be detected as "ttyUSB0".

Start emuclient & play!

Notes:

Don't set the frequency to a value higher than the mouse frequency (ask google about your mouse frequency, or let the value to 100Hz).
It's not recommended to run at 500Hz or 1000Hz, unless you have a realtime linux kernel (running at 500Hz with a 500Hz mouse may generate some small glitches).
For details about the installation & the configuration of the sixemu software, read the sixaxis emulator tutorial.
Multiple usb connections should work (not tested).
The calibration GUI lags for frequencies higher than 100Hz.

Limitations:

All buttons are "digital" (i.e. value is 0/1, not in 0-255).
No PS3 button yet.

Enjoy!!

Version 0.22 released

2011-05-22T23:43:00.010+02:00

If you are upgrading from v0.15 or lower, read this post first: link.

Warning: this release wasn't tested deeply...

New configuration example installed in the /etc/emuclient folder:

CallOfDuty:BlackOpsG500i2.xml (1:1 translation attempt)

Main improvements:

usb connection
the calibration mode automatically saves the configuration
calibration test for the 1:1 translation

All corrected issues:

Download links:

sixemu_0.22-1_i386.deb

Sixemugui-rs232 layout:

More details about how to use this coming soon!

Subposition precision, 1:1 translation

2011-05-20T23:03:00.020+02:00

This post explains a mechanism for the mouse to stick translation, that allows to reach a better precision and that is required to perform a 1:1 translation.

If you don't want to read some math, then skip this post :)

All values are considered positive so as to simplify the explanation.

Each 10 ms, the sixaxis emulator processes all pending events.
All mouse motion events are merged and as a result, a single mouse event is processed.
This mouse event contains cumulated x and y deltas: (dx1, dy1).

This motion vector is then translated into a stick position according to the following formula:

(1) pos1 = dz1 + mul * pow(mv1, exp)

pos1 = desired stick position (real)
dz1 = deadzone (real, function of dx1, dy1 and the deadzone shape)
mv1 = mouse value (integer), dx1 or dy1
mul = multiplier (real, constant)
exp = exponent (real, constant)

The result pos1 is a real. But the final stick position has to be an integer.
What emuclient was doing previously is rounding pos1 to the nearest integer.
This obviously results into a lower or higher speed than the desired one.
A much more precise solution to tackle this real to integer conversion is to truncate pos1, and compute a mouse vector remainder to be added next iteration.

The mouse event that corresponds to the applied stick position is: (dx2, dy2).
dx2 and dy2 are reals.

(2) pos2 = dz1 + mul * pow(mv2, exp)

pos2 = applied stick position (truncate(pos1), integer)
dz1 = deadzone (same value, the angle is considered to be the same)
mv2 = mouse value (real), dx2 or dy2
mul = multiplier (real, constant)
exp = exponent (real, constant)

Note: norm(mv1) >= norm(mv2)

(3) vrem = mv1 - mv2

vrem = mouse vector remainder
mv1 is known.
mv2 is computed from (2):

(4) mv2 = pow[(pos2 - dz1)/mul, 1/exp]

mv2 can be replaced in (3):

(5) vrem = mv1 - pow[(pos2 - dz1)/mul, 1/exp]

Conclusion:

(5) gives the mouse vector remainder that has to be added the next iteration
this emulates a subposition precision

Notes:

this is useful with 8-bit precision for stick axes as the speed difference between two neighbor stick positions is high
this is useless with 16-bit precision for stick axes

USB connection - it works!

2011-05-16T00:06:00.009+02:00

Done:

write a clean joystick interface: 4 axes with 16-bit precision, 12 buttons (no PS3 button yet), and a hat (d-pad). This uses the excellent LUFA framework from Dean Camera.
configure an interrupt for the serial reception (great tutorial from Dean Camera)
write a RS232-capable emu process (docs).
write a new Sixemugui

Sixemugui layout:

Results:

2ms update period = 500Hz update frequency (same as my G500 mouse) - not sure the PS3 can drive a usb device at that speed - not sure running as fast is relevant considering the Linux latency
measured worst latency between a usb packet received by the PC from a peripheral (like a mouse) and the usb packet received by the device the joystick is connected to (for easiness, the PC - should be the PS3) is about 4.7ms, average latency is about 3.6ms

Notes:

It's probably better to avoid connecting both the mouse and the USB to serial device to the same usb bus.
A kernel with realtime capabilities could probably lower the worst latency.
It's not good to work at a frequency higher than the mouse frequency (no mouse report in the last period => stick is set to the center => jerky movements).
The dead zone ~~doesn't seem to be~~ is proportional to the max absolute axis value.
The report period is probably not constant without a realtime kernel (2ms is probably too low considering the Linux latency).
For performance reasons, emu & emuclient could be merged in a single process.

Next tasks:

build a package

USB connection

2011-05-14T13:32:00.001+02:00

Some time ago I announced my intention to work on a usb connection that can replace the bluetooth connection (it's well known that the ps3 is compatible with some joysticks that comply with the USB HID specification).

Why do I want a usb connection?

better precision for sticks (better than 8-bit precision)
higher update frequency (better than 100Hz)
good solution for a native windows controller
challenge ;)

What hardware can be used?

This usb connection requires a system with 2 usb ports, one for the PC, and the other for the PS3. My first though was to use a VNC2, which is a programmable device with 2 usb ports. But the development tools are windows only :(

Widely distributed, available, and cheap devices with usb capabilities are the at90usb* boards (Teensy++, bumble-b, AvrUsbKey...). These only have a single usb port, which is not enough. But it's possible to talk to these boards with other means like a UART (RS232, AKA serial connection).

USB to RS232 TTL devices are very easy to find and are very cheap (a few $/€). The theoretical maximum baud rate reachable with these devices is 1 Mbit/s = 125 Kbytes/s = 125 bytes/ms, which seems fast enough. As a comparison, the sixaxis sends about 64 bytes to the PS3 each 10ms.

Another good point for this at90usb + RS232 solution is that I already have all the hardware parts, as you can see in the following picture:

Red outlined, the USB to RS232 TTL chip (FT232RL from FTDI). It's on an arduino board, which is not required at all.
Blue outlined, the bumble-b (at90usb162).
Green outlined, the push-buttons required by the bumble-b to enter into dfu mode (other usb boards generally have on board push-buttons).

The RS232 connection requires as low as 3 wires (Gnd, Rx and Tx). Rx and Tx wires are crossed.

The Rx and Tx connectors of the arduino are for the AVR chip (which is absent on my board), and are crossed with the FT232RL. That's why the arduino Rx pin is the FT232RL Tx, and the arduino Tx pin is the FT232RL Rx. I obviously fall into the trap :)

First experiments:

The ps3 seems to handle 16-bit axes.
The at90usb162 can report its joystick state each 1ms (but not sure the ps3 can work as fast).
The practical max baud rate of the RS232 connection is about 85 bytes/ms bidirectional (instead of the 125 bytes/ms theoretical max baud rate).
There seems to be no transmission error for the RS232 connection (I won't handle errors in a first time).

Next tasks:

write a clean joystick interface
write a RS232-capable emu process

Version 0.21 released

2011-05-07T17:05:00.004+02:00

Warning: the configuration writer of the mouse calibration mode is not working (issue 82) :(

If you are upgrading from v0.15 or lower, read this post first: link.

New configuration example installed in the /etc/emuclient folder:

CallOfDuty:BlackOpsG500i.xml (with stick intensity control)

Improvements:

~~the calibration mode automatically saves the configuration~~
stick intensity control for button-to-stick mapping
macros are fixed
emuclient is started automatically
the last used config file is auto-selected
a (big) memory leak is fixed

All corrected issues:

Download links:

sixemu_0.21-1_i386.deb

New sixemuconf layout:

It's now possible to have a better control over a stick with 4 keys or buttons (for ex WASD) and at least 1 modifier key or button (for ex a wheel, which is in fact 2 buttons).

The original idea was to enable to reach mid-positions. This was proposed by KillerBug (see issue 73).

The solution I coded enables to reach more positions of the 8 directions that can be generated with 4 buttons. Up to 127 positions for each direction = up to 1016 positions!

Example:

- dead zone = 31 (null-movement positions = black zone)
- shape = circle
- steps = 3 (number of positions for each direction)

The circle radiuses are 127, 95, 63.
Each red dot is a position we can reach with 4 direction buttons (ex WASD) + at least 1 modifier button (ex wheel).
With shape = rectangle, the red dots are aligned as squares.

Enjoy!!

Ubuntu 11.04

2011-05-02T22:47:00.000+02:00

Ubuntu 11.04 is out! Some important changes for the sixaxis emulator:

the bluez version is now 4.91

The Ubuntu 10.10 bluez version (4.69) seems to cause some connection problems in some undefined cases.

the middle mouse button emulation is now off by default

This "feature" can cause a 50ms lag for left and right mouse buttons.

Download link.

And now, fake sixaxis...

2011-05-02T21:56:00.000+02:00

Bouvrie, a reader of this blog, reported issues getting the sixaxis emulator to work.

The connection isn't successful, even with a dongle that has a chip know to work (CSR bluecore4).

The result of our investigation - see issue 74 - is that the sixaxis doesn't give the right ps3 bdaddr (bluetooth device address). It always gives the same wrong bdaddr.

Obviously, with a wrong ps3 bdaddr, the sixaxis emulator can't connect to the ps3.

The reason why this sixaxis doesn't give the right baddr is simple: it's a fake one :(

Yet another fake CSR dongle...

2011-04-27T23:32:00.000+02:00

The whole series of posts about cheap ebay dongles: link.

It seems ebay is really not a good option to find a CSR bluecore4 dongle. As a reminder, these dongles can have their bdaddr (bluetooth device address) changed, and 99% of them work with the sixaxis emulator. As far as I remember, only 1 or 2 users reported a non-working CSR BC4 dongle.

After having tried 2 sellers and only having received 2 out of 7 non-fake dongles, I decided to try another seller. But this time, I asked before buying, so as to make sure I will get what I am paying for. The answer to my question "Is there really a CSR BC4 chip inside your dongles?" was a clear "YES". Fine, I decided to buy 5.

After 3 weeks I finally received my order. First test, plug it to my PC, see what kind of bluecore revision it is. No revision, not good at all. Try to change the bdaddr. No error for the command, but the bdaddr is not changed. Finally, unplug it, open it, and look at the chip manufacturer: Conwise. Obviously not CSR...

Lesson learnt: don't buy these cheap ebay dongles, even if it's advertised as a BC4 (CSR+EDR) dongle!

A good advice I could give is to borrow every dongle you can borrow, and test it. Last solution: get a dongle from a local store.

Connection errors

2011-04-19T22:02:00.001+02:00

This post is for people getting connection errors.

Some people reported connection issues that were fixed by upgrading the linux bluetooth stack (default one in Ubuntu 10.10 is version 4.69).

Instructions if you want to do upgrade to the latest version (4.91):

System > Administration > Synaptic Package Manager
Settings > Repositories > Other Software

Add
Apt Line: ppa:blueman/ppa
Close

Reload
Mark all upgrades
Apply

I just upgraded to this version and it seems not to cause any issue on my setup. Do it at your own risk!

Note: bluez version 4.91 is now in Ubuntu 11.04.

What's next?

2011-04-15T08:53:00.001+02:00

Version 0.20 is bringing many new stuffs and I hope its quality is good. I was thinking to code more things for this release, but it would have even more delayed the release date. Issues 66, 68 and 70 (enhancements, not bugs) will probably be fixed in the next release.

There also are a few things I want to work on.

Translation tables

I already studied the stick position to rotation speed relation some time ago (link). Measuring rotation speed for each stick position is quite painful, and I'm thinking to design a tool to automate it. I want this to work with a cheap video capture card (about 10$).
Why do I want to study rotation speed? I want to add some translation tables (there will be one different translation table for each game) so that a 1:1 translation can be achieved. A 1:1 translation means that if you double your mouse speed, your rotation speed will double. This aims to produce a better PC-feel.

Following chart gives the rotation speed vs stick position measured for COD:MW2:

It's obviously not 1:1, especially for positions lower than 50.

Following table (values do not correspond to the above chart) shows how to perform a 1:1 translation:

1:1 translation
position	speed	1:1 speed	1:1 position
1	0	8	7
...	...	...	...
32	91	140	57
...	...	...	...
64	295	480	85
...	...	...	...
96	589	720	108
...	...	...	...
128	960	960	128

All stick positions are required. Speed unit is °/s.

First column is the stick position.
Second column is the measured rotation speed.
Third column is the speed that we would expect with a 1:1 position to rotation speed translation (position*max speed/max position).
Fourth column is the translation of the position to perform a 1:1 translation. Look for the expected speed in the 2nd column (closest value) and look what position it is in the first column, this gives the 1:1 position.

The translation looks like this:

This position to position translation may introduce a loss of precision. It probably would be better to have a direct speed to position translation.

Better precision for the right analog stick

8-bit precision allows 256 stick positions. 10-bit precision allows 1024 stick positions. More positions give a finer control. As a comparison, a high-end mouse reports x and y values with a 16 bit precision.

The official sixaxis page tells that analog sticks and l2/r2 buttons have a 10-bit precision. This is wrong: stick and button positions are reported with a 8-bit only precision. Only motion sensing controls have a 10-bit precision. This is lame because many people are saying that the Xbox360 pad is technically lower than the Sixaxis (8-bit precision vs 10-bit precision), which is absolutely wrong.

We can't change the precision of the sixaxis emulator, but it is probably possible to build a usb gamepad interface that has a precision higher than 8-bit for the right stick.

Version 0.20 released

2011-04-14T22:19:00.000+02:00

WARNING: this release totally breaks the configuration compatibility.

EDIT 21 April: The macro fonctionnality is broken :(

New configuration examples are installed to the /etc/emuclient folder:

CallOfDuty:BlackOps.xml (updated)
CallOfDuty:BlackOpsG500+G5.xml (configuration for 2 controllers)

Following items in the edit menu of Sixemuconf will let you convert your old configuration quickly:

Replace mouse: detect and replace mouse name&id in the current controller
Replace keyboard: detect and replace keyboard name&id in the current controller

Due to the correction of issue 60, you also will have to change ALL your mouse multipliers depending on your mouse frequency:

125Hz : divide by 1.25
250Hz : divide by 2.5
500Hz : divide by 5

If you don't know what frequency your mouse is running at, just try each value (or ask google for your mouse max frequency, and limit it to a maximum of 500Hz). High-end mice like the Logitech G5 or G500 are running at 500Hz (default frequency).

I know, this incompatibility sucks, but the new features in this version are worth the price. This probably won't happen another time.

To prevent beginners to use this version until I'm sure its quality is good, I will not change the version in the tutorial, and the previous version will remain "featured" in the googlecode download page. About 500 people downloaded the previous version :) I'm waiting everyone's feedback! I'm just joking, but I really appreciate a few words and I accept both positive and negative feedbacks.

Main improvements:

multiple mice & keyboard (new configuration examples in /etc/emuclient)
synchronization improved
mouse translation improved
up to 8 configurations per controller
new mouse calibration mode

All corrected issues:

Download links:

New items in the edit menu of Sixemuconf:

The "Replace Mouse DPI" item lets you adjust your multipliers according to your old and new mouse dpi values (the higher the better). I recently bought a Logitech G500 (which is excellent by the way), and I run it at its max dpi (5700). My previous mouse is a Logitech G5 (max 2000 dpi). This means I had to multiply my multipliers by: 2000/5700.

New calibration mode, displayed in Sixstatus:

This calibration mode lets you calibrate each mouse independently. It reads values from the loaded configuration, but it still doesn't save them (use Sixemuconf to apply changes to the configuration file). To change values, use rctrl+FX key combinations and use the mouse wheel.

Enjoy!!

A tool to estimate the latency

2011-04-04T09:12:00.000+02:00

In a series of posts I am talking about the sixaxis emulator latency.

What kind of latency am I talking about? Basically, the time between event reception from PC peripherals, and event emission to the PS3. The most critical event to me is a mouse left clic in a FPS game.

The most accessible estimation is to measure the difference between usb timestamps. See this post for more details. I created a small utility to make this estimation easier. It has to be launched in a terminal, but I am thinking to add it some day in sixemugui.

matlo@matlo-hcpc:~/hack/test$ wget http://diyps3controller.googlecode.com/svn/trunk/tools/sixemulat.c
matlo@matlo-hcpc:~/hack/test$ gcc -lm -o sixemulat sixemulat.c

matlo@matlo-hcpc:~/hack/test$ lsusb
[...]
Bus 003 Device 008: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 003 Device 005: ID 046d:c041 Logitech, Inc. G5 Laser Mouse

matlo@matlo-hcpc:~/hack/test$ ./sixemulat
usage: ./sixemulat <mouse bus id> <mouse device id> <dongle bus id> <dongle device id>
matlo@matlo-hcpc:~/hack/test$ ./sixemulat 3 5 3 8

Be sure to use the correct mouse/dongle bus/device ids, specifically if you have several mice and/or several dongles!

Sixemulat displays:
- the number of caught left clics
- the worst latency
- the average latency

About a hundred of samples should be enough to get significant values.

The average latency is an interesting value, but the most important value is the worst latency. Commercial products will tend to give you only the average latency, as it is a lower (generally half) value...

I only tested this tool with two logitech mice. If it doesn't work for you, please get in touch with me.

Mouse mapping improvement - 2

2011-03-29T10:15:00.000+02:00

Last mouse mapping improvement was about tweaking the dead zone shape, and was proposed by a reader of this blog. Another reader suggested me to change the way the mouse motion is processed.

The sixaxis emulator currently approximates the velocity from the mouse report average over 10ms (=the sixaxis report period). For ex, if it receives N mouse reports, it assumes a constant 10/N ms period.

Example 1:

t0-1ms  report x = some value
t0      all mouse report processed, a report is sent to the ps3
t0      report x = +10
t0+1ms  report x = +8
t0+2ms  report x = +6
t0+3ms  report x = +4
t0+4ms  report x = +2
...     no other report
t0+10ms all mouse report processed, a report is sent to the ps3

5 reports, report period is approximated to 2ms.
Mouse report average: (10+8+6+4+2)/5 = 6 units/ms

Well, this is overestimated.

With a simple accumulation + division:
Mouse report average: (10+8+6+4+2)/10 = 3 units/ms

For this example, the computed velocity is 2x the real one o_O

This is not harmful if the computed velocity is always 2x the real one.
But let's take another example.

Example 2:

t0-1ms  report x = some value
t0      all mouse report processed, a report is sent to the ps3
t0      report x = +10
t0+1ms  report x = +8
t0+2ms  report x = +6
...     no other report
t0+10ms all mouse report processed, a report is sent to the ps3

3 reports, report period is approximated to 3/10ms.
Mouse report average: (10+8+6)/3 = 8 units/ms

With a simple accumulation + division:
Mouse report average: (10+8+6)/10 = 2.4 units/ms

For this example, the computed velocity is 3.33x the real one...

The previous computation was introducing a non constant multiplier :(

Beware of CSR counterfeits!

2011-03-29T09:21:00.000+02:00

It seems some bt dongles out there are CSR counterfeits.

I suspect most of the cheap CSR-advertised ebay dongles of being CSR counterfeits.

These dongles are advertised as CSR dongles supporting EDR, which means they should contain a CSR bluecore4 chip.

But in fact they contain an ASC (Accel semiconductor) chip named AS3620QA.

What makes them counterfeits:

they all have the same bluetooth address! This means several of these dongles can't be used in the same area. If you and your neighbor are using the same dongle at the same time, it won't work, or it will work with many connection errors.
they are using the CSR usb vendor id (0x0A12)

What's even worst for us is that these dongles can't have their bdaddr changed!

My working dongles

2011-03-27T00:50:00.000+01:00

A photo of all my working dongles:

From left to right: Trust (CSR bluecore4-rom), "cheap ebay dongle" (CSR bluecore4-rom), Fujistsu-Siemens FMWBA-101 (CSR bluecore2-ext es2), Com1 (Broadcom), Peabird (CSR bluecore4-rom), Cellink BTA-3000 (CSR bluecore2-ext), and Linksys USBBT100 (CSR bluecore2-ext).

All connected to a Belkin usb hub:

I can get all these dongles working simultaneously with the sixaxis emulator, which means I can emulate 7 sixaxis controllers at the same time ;)

Multiple mice and keyboards support

2011-03-23T22:19:00.000+01:00

I managed to build a custom SDL library (from libSDL 1.2 sources) that exposes the source of mouse & keyboard events. People interested in how I did that will find the patch there: patch. It uses XI2/RawEvents. It's very hackish and ugly, but it does the job. Note that it probably breaks stuffs useless to the sixaxis emulator.

This allows to use several mice and keyboards with the sixaxis emulator, which is a nice feature to play split-screen FPS games with friends :)

Before I release this feature, I want to be sure I didn't broke anything.
That's why I'm looking for testers!

If you own at least 2 mice, 2 keyboards, 2 working bt dongles, a FPS with split-screen, and 1 friend :p, and if you want to test this stuff, please get in touch with me, I will send you a test package (i386 only). My mail can be found on my googlecode page (you need to log in to see it).

About the "Kinect-PS3" project

2011-03-21T22:51:00.000+01:00

The Kinect-PS3 project from Shantanu Goel makes some huge buzz on the web. The Kinect-PS3 uses -among others things- the sixaxis emulator (called "diyps3controller" everywhere because of the name of my googlecode page), and probably wouldn't be there without it. Many websites are talking about the Kinect-PS3, and they only give credits to only one person... guess who. This is not very fair, and I really would have appreciated getting a few credits for what I am working on.

That said, the Kinect-PS3 is a great showcase for the sixaxis emulator, and my googlecode page and blog are currently receiving an unusual amount of visitors.

I guess Sony will not enjoy this stuff at all, and I hope they won't try to break the compatibility with the sixaxis emulator. But if they try to, be sure I will do my best to fix it.

Version 0.15 released

2011-03-07T08:42:00.000+01:00

Main improvements:

multiple emu (but still single mouse & keyboard)
configuration switch/switch back
compatibility with QtSixA
buttons to stick mapping improved

All corrected issues:

Download link: sixemu_0.15-1_i386.deb

Enjoy!!

QtSixA - Sixaxis control mapping for all!

2011-03-05T10:30:00.000+01:00

The Sixaxis emulator supports standard joysticks thanks to the SDL library.
The sixaxis itself is not a standard joystick. This means some ugly patches have to be done to get it work.

It already works fine in usb mode, which makes it usable as-is with the sixaxis emulator, BUT bluetooth mode doesn't work out of the box.

If you want to use your sixaxis in bluetooth mode, there is an excellent tool called QtSixA. There is a big thread about it in Ubuntu forums.

It turns out that QtSixA (current version is 1.5.0) works fine with the sixaxis emulator :D

This tool even let you use the motion sensing! This is not supported by the sixaxis emulator... for now :)

To install it, from a terminal:

Code:

sudo add-apt-repository ppa:falk-t-j/qtsixa
sudo apt-get update && sudo apt-get install qtsixa

There is a shortcut in menu Applications > Accessories.

The pairing is currently broken, to fix it, just type in a terminal:

Code:

sudo mv /usr/bin/sixpair /usr/sbin/sixpair

All buttons and sticks are working with the sixaxis emulator. There is an issue with some 'analog' (pressure sensitive) buttons that are not working as axes: square/triangle/circle/cross.

There also is a minor compatibility issue regarding the joystick name which is different in bt mode. The joystick name is used to distinguish joystick models, so that this will require a small patch.

Remember: don't use the same bluetooth address at the same time! This requires 2 sixaxis (1 turned off, 1 turned on). Or a usb dev board (such as the teensy++) to pair custom bluetooth addresses.

Installation video

2011-02-28T10:02:00.000+01:00

This video shows how easy and quick (about 3 minutes!) it is to install the sixaxis emulator once you have Ubuntu running.

It was made with a Ubuntu 10.10 live usb, using a broadcom dongle (the address change doesn't survive to a hard reset).

Version 0.14 released

2011-02-27T15:07:00.000+01:00

Main improvements:

Config file permission/ownership problems should be fixed.
Software reset is improved (better compatibility with Broadcom dongles).
It's possible to choose a circle or rectangle dead zone shape.
Sixemuconf allows to modify a mapping.
Sixemugui doesn't hang anymore if connection is not successful.

All corrected issues:

Download link: sixemu_0.14-1_i386.deb

Enjoy!!

New all-in-one package 0.13

2011-02-22T08:51:00.000+01:00

I built a new all-in-one package 0.13 that includes everything needed to install, configure and launch the sixaxis emulator.

It features a new gui called "sixstatus" that is able to display the sixaxis status (issue 35), as shown in the following screenshot:

It's now possible to save the configuration of sixemugui (Sixaxis and PS3 addresses) so that it is not required (except for the first launch) to have the sixaxis plugged anymore (issue 33).

Last but not least, the mouse calibration mode is improved (issue 36).

If you installed the 9.99 test package, uninstall it before installing this new package!

Package download: sixemu_0.13-1_i386.deb

I will update the tutorials latter.

Deutsches Tutorial

2011-02-18T15:17:00.011+01:00

Umgestellt: Link.

» Alte Version «

Mouse mapping improvement

2011-02-17T08:55:00.000+01:00

Each polling period (=10ms=sixaxis refresh rate), emuclient processes all queued events.
This means that depending on the mouse refresh rate, emuclient may process one or several mouse motion events.

Examples:

(rate=100Hz) => 1 event max
(rate=500Hz) => 5 events max
(rate=1000Hz) => 10 events max

In a single polling period, emuclient may receive several events, but only performs a single sixaxis status refresh. Therefore, mouse motion events have to be merged into a single one that is the average mouse motion event. This allows to reach a better precision since no event is ignored.

The average mouse motion event is translated to a sixaxis axis thanks to the following formula:

res=sign(val)*mul*pow(abs(val),exp)

I usually use exp=1 so that the simplified formula is:

res=mul*val

The dead zone has also to be removed:

if res>0: res=res+dz
if res<0: res=res-dz

Different multipliers, exponent and dead zones may be set for x and y mouse motions.
This calculation supposes the dead zone is rectangular.

Following to the suggestion of a reader, I decided to test a different dead zone shape.

With a circular dead zone:

if x!=0 and y!=0:
dz_x=dz*cos(atan(abs(y/x)))
dz_y=dz*sin(atan(abs(y/x)))
else:
dz_x=dz
dz_y=dz

I also improved the result precision by storing each intermediate result as a double (and not an integer). Only the final result is converted to an integer.

I built a test package for people that want to try these new things.
Just remember to set the same value for both x and y dead zones.
Let me know the results of your tests!

Tutoriel en français

2011-02-15T10:36:00.010+01:00

Déplacé : lien.

» Ancien contenu «

New packages released

2011-02-05T11:06:00.000+01:00

New packages are available there: link.

It fixes issues 24, 25, 31, 19.

There is a new package (sixemugui_0.1-1_i386.deb) that contains the sixemugui tool.

Package installation now adds shortcuts for sixemuconf and sixemugui in the Application>Game menu.

It looks like this:

Quick instructions:

Plug you sixaxis and bt dongle
Select the sixaxis
Select the bt dongle
Set the dongle address (don't forget to write the old one down)
Re-select the sixaxis and the bt dongle
Start emu (a popup will tell you if connection is succesful)
Start emuclient
Enjoy!

As I won't be available next week, I didn't updated the tutorial.

So if you use them and find some issues, please report them, but don't expect to have a quick answer or a quick fix.

Left and right mouse button lag

2011-02-01T09:57:00.000+01:00

In my previous post I told that I was experiencing about 50ms latency for left and right mouse clics. After some investigations I discovered that the problem was located in xorg.

It appears it's not a bug, it's a functionality called "3rd button emulation" that is useful with a 2 button mouse. Xorg waits up to 50ms to see if both left and right buttons are pressed, and in case it is, it generates a middle button press.

It's nothing to say that this implementation is lame and should be disabled by default.

Following bug reports were filled by people complaining about that behavior:

Although a real middle button press is enough to disable the functionality (not persistent), it's possible to disable it by default (works for Ubuntu 10.10):

sudo gedit /usr/share/X11/xorg.conf.d/20-mouse.conf

Copy-paste to following lines:

Section "InputClass"
Identifier "Mouse0"
MatchIsPointer "true"
Option "Emulate3Buttons" "false"
EndSection

Save, and Restart!

Another post about latency

2011-01-29T18:57:00.000+01:00

My previous work on that subject

I already worked on measuring how much latency the sixaxis emulator is adding compared to a real sixaxis. I did that using a microphone, measuring the overall response time for a gunshot.

Assuming we have:
R=C+G
R=overall response time
C=controller latency
G=game latency

For the real sixaxis:
R1=C1+G
For the sixaxis emulator:
R2=C2+G

Assuming G is constant:
R2-R1=C2-C1

To estimate the controller latency difference, which is C2-C1, I just had to subtract the overall response time.
The result was about 15ms, which is not that bad compared to the overall response time (>100ms) and the human response time (>100ms).

A way to estimate the latency of the sixaxis emulator

The basic idea is to measure the time between a usb packet coming from the mouse (or any other usb controller) and a packet sent to the usb bt dongle.

For ex, the time between the usb packet for a left clic and the usb packet that sends the R1 button press (via the bluetooth dongle).

A great tool provided with the Linux kernel is usbmon, which allows to sniff the usb traffic. It's possible to use it with wireshark (with root user rights), but it's better to play in a terminal to automate extraction of valuable information.

The usbmon documentation is available there: link.

First of all, what the lsusb output says:

matlo@matlo-hcpc:~/hack/test$ lsusb
Bus 004 Device 002: ID 050d:0200 Belkin Components
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 009: ID 054c:0268 Sony Corp. Batoh Device
Bus 003 Device 008: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 003 Device 006: ID 054c:0268 Sony Corp. Batoh Device
Bus 003 Device 005: ID 046d:c041 Logitech, Inc. G5 Laser Mouse
Bus 003 Device 003: ID 046d:c517 Logitech, Inc. LX710 Cordless Desktop Laser
Bus 003 Device 002: ID 058f:9254 Alcor Micro Corp. Hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 003: ID 046d:0809 Logitech, Inc. Webcam Pro 9000
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

What is useful there is the bus and device ids. The G5 mouse is device 5 on usb bus 3, and the bt dongle is device 8 on usb bus 3.

To start the capture:

matlo@matlo-hcpc:~/hack/test$ sudo cat /sys/kernel/debug/usb/usbmon/0u > test

Generate left clics into the sixaxis emulator, and stop the capture (ctrl+c).

Then, to display the mouse packets:

matlo@matlo-hcpc:~/hack/test$ cat test.txt | grep "3:005"

And for the bt dongle packets:

matlo@matlo-hcpc:~/hack/test$ cat test.txt | grep "3:008"

Both these commands may give a huge amount of data.

To only display packets that correspond to left clicks:

matlo@matlo-hcpc:~/hack/test$ cat test.txt | grep "3:005:1 0:1 10 = 01000000 00000000 0000"
f6747a40 967102843 C Ii:3:005:1 0:1 10 = 01000000 00000000 0000
f6747a40 968852805 C Ii:3:005:1 0:1 10 = 01000000 00000000 0000
f6747a40 970341772 C Ii:3:005:1 0:1 10 = 01000000 00000000 0000
f6747a40 971609742 C Ii:3:005:1 0:1 10 = 01000000 00000000 0000
f6747a40 972760716 C Ii:3:005:1 0:1 10 = 01000000 00000000 0000

To only display packets that correspond to R1 button presses:

matlo@matlo-hcpc:~/hack/test$ cat test.txt | grep "3:008:2 -115 58 = 2b203600 32004300 a1010000 08000080 80808000 00000000 00000000 0000ff00"
f32e2640 967105205 S Bo:3:008:2 -115 58 = 2b203600 32004300 a1010000 08000080 80808000 00000000 00000000 0000ff00
f32e2640 968861926 S Bo:3:008:2 -115 58 = 2b203600 32004300 a1010000 08000080 80808000 00000000 00000000 0000ff00
f32e2640 970345964 S Bo:3:008:2 -115 58 = 2b203600 32004300 a1010000 08000080 80808000 00000000 00000000 0000ff00
f3a904c0 971618231 S Bo:3:008:2 -115 58 = 2b203600 32004300 a1010000 08000080 80808000 00000000 00000000 0000ff00
f3a90ac0 972769407 S Bo:3:008:2 -115 58 = 2b203600 32004300 a1010000 08000080 80808000 00000000 00000000 0000ff00

What is to be extracted from this is the timestamp in microseconds, which is the second column.

matlo@matlo-hcpc:~/hack/test$ cat test.txt | grep "3:005:1 0:1 10 = 01000000 00000000 0000" | awk '{ print $2 }'
967102843
968852805
970341772
971609742
972760716

matlo@matlo-hcpc:~/hack/test$ cat test.txt | grep "3:008:2 -115 58 = 2b203600 32004300 a1010000 08000080 80808000 00000000 00000000 0000ff00" | awk '{ print $2}'
967105205
968861926
970345964
971618231
972769407

Then, it's easy to copy-paste this data into a spreadsheet, compute the difference, compute the average, and the standard deviation.

For this example (with 5 more samples), it gives a 7.6ms average difference, with a 2.9ms standard deviation. The max difference is about 12ms.

It has to be reminded that the event polling period is 10ms (equal to the sixaxis report period), so that the maximum latency added by the event polling is 10ms, and the average is 5ms. Thus, the processing time is in average 7.6-5=2.6ms. It has to be noticed that I'm using a Linux kernel with realtime/low latency capabilities.

It's also possible that there is some more latency added by the usb stack and the bt dongle, but it's probably less than the 7.6ms processing time.

Conclusion:

- it's probably not possible to have a lower response time with a sixaxis emulation (bt or usb)
- to lower the controller latency, the only potential way is to use a usb device to usb device controller (a custom usb link between the PC and the PS3), with a report period lower than 10ms

Thanks to that work I found a latency issue (about 50ms) that only impacts left and right mouse clics. The work-around -I'm not joking!- is to press the middle button after the mouse is plugged to the PC (see next post).

Great youtube video

2011-01-25T14:07:00.000+01:00

McKack made a great video and posted it on youtube:

It shows the sixaxis emulator working with a keyboard and a mouse, with Call Of Duty: Black Ops.

Nice showcase, thanks McKack!

One GUI to rule them all

2011-01-25T09:38:00.000+01:00

Last WE I started working on issue 19.

The idea is to make a simple GUI that can help the user in steps 2/3/4 of the (new) tutorial.
That means, no more "scary" commands to type in a terminal, and no more typos issues :D
This also will make my work easier, since it will help people to report their issues.

Hopefully that will make windows users come to the Linux live USB solution...

Now, a few words for people that like technical stuffs and C/C++ programming.
To make my work easier and the code lighter, I'm not using the bluetooth and libusb libraries directly into the GUI app. I'm using a GLIB function called g_spawn_sync that allows to launch a command (bdaddr, hciconfig, sixaddr, emu, emuclient...) and to store the output of that command into a buffer (the output that is usually displayed into the terminal). This buffer is parsed so as to read interesting values (bdaddrs, dongle name, chip version, manufacturer...), which are lastly displayed in the GUI. I admit it is "quick and dirty", but it works, and it's time-saving :)

Updated 26/01
Screenshot:

Voice control

2011-01-18T09:43:00.000+01:00

This is my first post about "voice control" for the PS3.

Voice control is only #4 in my todo list, but as I'm curious, I wanted to know how hard this stuff is, and I decided to begin searching for Linux tools.

Speech recognition is a wider area than voice control. Considering what I want to do (voice control), it is a hard and wasteful thing (cpu consumption, complexity).

There are many projects that allow voice control stuffs. I will only focus on projects that are widely used/tested and still developed/maintained.

Project to watch regularly:

SpeechControl Ubuntu project: hopefully providing some easy to install tools in a near future.

Some projects that are probably good enough to make a "hackish" proof-of-concept:

Simon: the wiki tells the installation is easy, but this sadly seems to be broken with Ubuntu Maverick. I need to work more on that cross-platform (Linux+Windows) solution.
Julius+Voxforge: seems to be very easy to install, but no GUI.
Pocketsphinx: a recognizer library written in C.

To be continued!

Support for Xbox 360 gamepad

2011-01-16T23:39:00.000+01:00

Thanks to the sixaxis emulator, it's possible to use a Xbox 360 gamepad with the PS3.

This requires a small patch for the d-pad, which is defined as a "joystick hat".

The configuration file is available there.

The d-pad support will be included in next packages.

English tutorial

2011-01-11T21:03:00.015+01:00

Moved: link.

» Outdated content «

New stuffs coming very soon

2011-01-10T09:08:00.000+01:00

The configuration reader for the emuclient process is finished.

I tested it (=played!) with my G5 mouse and n52 keyboard, and it works well for COD: Black Ops :)

All game controllers are now supported. Great examples of game controllers that are now possible to use: Xbox gamepads, racing wheels (no force feedback yet), joysticks.

I tested with a sixaxis (wired, but it should work wireless too). You may ask, why would I need to do that? The response is simple: button mapping & dead zone removal.

I'm now focusing on making .deb packages, so as to make the installation easier.

There also will be an update for the tutorial.

For now, the tutorial has been modified to use a specific revision of the code, which is not the head revision.

Stay tuned!

Tuning mouse movements

2011-01-04T21:28:00.000+01:00

There are now two different multipliers: one for horizontal moves, and one for vertical moves.

This is in emuclient.c:

#define DEFAULT_MULTIPLIER_X 4
#define DEFAULT_MULTIPLIER_Y 9

These two values are for Call of Duty: MW2/Black Ops (with in-game sensitivity set to the highest=10), and have to be adapted depending on the game.

Some new code allows to trigger a circular mouse movement, that helps to adjust a 1:1 ratio between vertical moves and horizontal moves.

Press Keypad 0 to enable calibration mode, then press 'p' to trigger a circular mouse movement.

If the result is an ellipse and not a circle, this means you have to adjust the multipliers.

Press Keypad 0 again to disable calibration mode.

Note: this post will be deprecated when the configuration tools will be released.

Some news about the project...

2011-01-03T14:32:00.000+01:00

I am on the way to finish the config reader code in the emuclient process...
It seems I underestimated the time needed for that, and overestimated my time available to it :(

I will try to release a beta version ASAP. I really hope that will come before the end of the week, but as I wasn't able to make good predictions, I won't promise anything. And I want to make the final code generic, as I hope to reuse it for a XBox360 controller. That makes stuffs to be even more complicated.

Note that I probably will modify the tutorial so that it will make the reader use a specific revision of the code corresponding to the last stable version (i.e. without my work on the config stuffs).

I also want to say a few word about the 27C3 presentation on the 'PS3 Epic Fail' made by the fail0verflow team. I was very excited to watch the live streaming, and I wasn't disappointed. That really was epic :D

Now that the PS3 is completely hacked, it seems it will be possible to play with ANY USB device directly connected to ANY PS3 running ANY firmware. ANY is a keyword I was waiting for. Moreover, it will be possible to do it with custom pup files, which makes the crappy dongle stuffs deprecated. Last but not least, it seems everything will be reversible, so that it will avoid the PS3 to be banned by Sony (reinstalling the official firmware before getting online). This means at least that we will be able to play offline with USB devices directly connected to the PS3. Sony will probably still try to fight against players running custom stuffs and playing online.

It will also be possible to reverse engineer the remote play/keyboard stuffs only available to Sony devices such as the PSP and viao laptops.

I don't know yet what I will be working on. Before that, I will try to finish my current work.

To summarize, I will not stop the sixaxis emulator development since it's the only way to play online safely, but I will more than likely try to find some time to run custom stuffs on the PS3.

The configuration GUI works in windows...

2010-12-22T10:35:00.000+01:00

All the libraries I chose are cross-platform (wxWidgets, libxml, libSDL...).

Thus, it's pretty straightforward to port the configuration GUI to windows.

For now, it's not very useful to use it in windows, since the sixaxis emulator doesn't run natively in this OS (virtualization works, but it breaks down performances).

Trigger

Buttons

Axis

Above screen shots show the look and feel of the gui in windows.

I uploaded a binary on the project google code web page (direct download link).

I'm not sure I included all the required dll, so if it complains about a missing dll at the application startup, please tell me what dll it is.

Feel free to test it. A basic test is to make a configuration, save it into a file, close/restart the gui, open the file, and see if everything is correct.

Tell me what you think about it! You can start reporting bugs on the issue list.

The sixaxis emulator configuration GUI is finished!

2010-12-20T23:24:00.000+01:00

This configuration GUI is now able to:

instantiate a new configuration
read a configuration from a file
save a configuration into a selected file

Don't get over excited, there is some remaining work to use this tool with the sixaxis emulator.

The sixaxis emulator has now to read the configuration files produced by the configuration GUI.

~~I hope to finish that before Saturday. I guess that would be a good Christmas gift!~~

Installation instructions

sudo apt-get install subversion build-essential libSDL-dev libxml2-dev curl

curl http://apt.wxwidgets.org/key.asc | sudo apt-key add -

sudo gedit /etc/apt/sources.list

Add following 3 lines at the end of the file:

# wxWidgets/wxPython repository at apt.wxwidgets.org
deb http://apt.wxwidgets.org/ karmic-wx main
deb-src http://apt.wxwidgets.org/ karmic-wx main

sudo apt-get update

sudo apt-get install libwxgtk2.8-dev libwxgtk2.8-dbg

svn checkout http://diyps3controller.googlecode.com/svn/trunk/sixaxis-emu-configurator diyps3controller-read-only

cd diyps3controller-read-only/

make -f sixaxis-emu-gui.cbp.mak release

cd bin/Release/

./sixaxis-emu-gui

Enjoy!!

Sixaxis Emulator Tutorial (DE)

2010-12-10T15:50:00.003+01:00

Dieses Tutorial ist nicht mehr aktualisiert. Das neue Tutorial ist hier : Link.

» Alte version «

Cheapest usb 2.0 high-speed sniffer?

2010-12-08T09:16:00.000+01:00

The beagleboard-xm

Some weeks ago I discovered that the beagleboard has both usb 2.0 high-speed host and OTG functionalities.

This board can run Linux, so that it's possible to capture the usb traffic and to visualize it with wireshark.

The following idea came to my mind: using a usb port as a host, and the usb OTG port as a device, the beagleboard may be used as a usb proxy/sniffer.

I then started looking for a usb sniffer running on the beagleboard.

After some researches I found the following project: blog /wiki.

It was written by Nicolas Boichat as a Google Summer of Code 2010 Project.

I bought a beagleboard-xm, and I'm on the way to test this great tool...

Now working on the core of the configuration GUI

2010-11-24T09:37:00.000+01:00

Yesterday evening, I began to work on the core functionalities of the configuration GUI:

~~read a configuration from a file~~ done
~~edit a configuration~~ done
~~save a configuration into a file~~ done

I hope to have this done later this week.

I decided to postpone the macro edition.

New skeleton for the configuration GUI

2010-11-13T13:25:00.000+01:00

New screen-shots:

As you can see, I divided the main window into panels.
The "Macros" panel is not finished yet.

There are a few changes:

the configuration trigger may only be a button
the device type, device name, device id, event type and event id can be auto-detected
the "button down" and "button up" events will only be available for macros edition
the joystick name is added, so that the joystick identification is easier (for both user and software)

Auto-detection does not work if a joystick is not well calibrated.
The auto-detection is not usable with a sixaxis, because each button generate both axis and button events (for pressure-sensitive buttons).

That's all for this week.

Skeleton of the configuration GUI

2010-11-11T23:44:00.000+01:00

There it is:

It's kind of primitive, but it's a first step!

Brief description:

The menu bar has a File menu (buttons: new, open, save, save as, quit), a Controller Menu (radio buttons: 1 ... 7), and a Configuration Menu (radio buttons: 1 ... 4).
The main window is composed of 3 parts: Configuration trigger, Button configuration and Axis configuration.

Each controller (up to 7) has up to 4 configurations.

Working on a cross-platform configuration GUI

2010-11-10T09:55:00.000+01:00

Since a few weeks I've been thinking about writing a GUI so as to make the configuration of the sixaxis emulator easier.

Mandatory requirements:

run on Linux, Windows, and OS X
allow the configuration of multiple sixaxis controllers (max=7)
multiple configurations for a single sixaxis controller
automatically detect user inputs (keyboard, mouse, joysticks)
save the configurations in a human-readable format

Optional requirements:

detect bt modules and launch the sixaxis emulator (multiple emu + a single emuclient)
detect sixaxis controllers plugged to the usb bus and allow to change bdaddrs of bt modules

For 1. and 5. mandatory requirements, I chose to use wxwidgets/Codeblocks and XML/libxml.

I will try to make a GUI skeleton before the end of this week, and publish some screen-shots on this blog.

Back to the latency: my audio system sucks

2010-10-31T23:12:00.000+01:00

In my previous post, I warned that I was experiencing some measure inconsistency.

The reason is simple: my audio system sucks :(

For some measures, I recorded the LCD audio output, and for some others, I recorded the audio output of my digital audio system.

But my digital audio system is adding an audio latency that varies from about 40ms for PCM 2.0 to about 90ms for Dolby Digital! (the PS3 could introduce some of this latency, see EDIT2)

Speaking of stuffs that may add latency, a good advice I could give is not to use weak usb extension cable.

I changed the following stuffs so as to take better measures:

only record the LCD audio output
use a better microphone that makes a lot less noise
increase the LCD audio output level
take all measures within 10cm near the speaker (1m = 3.4ms)
only start the sixaxis emulator, and record the sound with another PC

New measures of the response time:

Wireless sixaxis: average 112ms, standard deviation 11ms

Wired sixaxis: average 108ms, standard deviation 10ms

Sixaxis emulator: average 123ms, standard deviation 8ms

Note that this response time probably includes the response time of the LCD audio output, which seems to be quite constant, since the standard deviation is about 10ms in each case.

The sixaxis emulator is adding 11ms latency compared to the wireless sixaxis, and 15ms compared to the wired sixaxis.
This actually shows the sixaxis emulator is doing quite a good job :)

EDIT: I took new measures for CSS in Win7 too, it gives a 158ms response time, with a 16ms standard deviation.

EDIT2: I should measure the response time for CSS with my digital audio system, so as to see if the PS3 is a source of audio latency for dolby digital...

EDIT3: all samples in a single archive file

Sixaxis emulator: the truth about latency

2010-10-26T20:03:00.000+02:00

Warning: I need to work again on these measures. I took some more measures for the wireless sixaxis. These measures are not consistent with my earlier values :s For these new measures, the average game response time with the wireless sixaxis is about 150ms. All values in this post have to be confirmed. EDIT: See my next post.

No suspense: it's not good.

I measured the average delay between a gunshot action and its corresponding gunshot sound (in BF:BC2).

Real wireless sixaxis: 125ms

Real wired sixaxis: 139ms

Sixaxis emulator: 168ms

Note that this isn't the controller latency. This is the overall latency for a gunshot.
The difference between two values gives the controller latency difference.

The sixaxis emulator adds a 43ms latency. That's more than 1 or 2 frames (40ms@25fps, 33ms@30fps, 17ms@60fps). Not good at all.
I should take some measures with a FPS on PC.
125ms seems to be very high for a descent game controller.
The wired sixaxis gives more latency than the wireless one... not as expected.

Methodology:

- plug a microphone on the PC
- start audacity
- start a FPS on the PS3
- put the microphone on the device to test (sixaxis or mouse)
- adjust the volume of the game so that gunshot actions/sounds are recorded
- start recording in audacity
- repeat the gunshot action (empty the cartridge of a pistol) with ~2s delays
- stop recording
- get measures between gunshot actions/sounds and compute the average

I don't know how precise it is to measure the game latency, but it's at least good enough to compute a latency difference.

Following images are screen-shot examples of the audio wave:

As you can see in the second screen-shot, there are two events: the gunshot action (mouse clic) and the gunshot sound. It shows a capture recorded with the sixaxis emulator. The delay was about 150ms for this gunshot.

EDIT:

I took measures for Counter Strike Source in Win7. I get a 188ms average response time for a gunshot.

Although all the measured values seem very high, it seems the real sixaxis and the sixaxis emulator are not that bad... compared to CSS results.

Multiple sixaxis emulators

2010-10-22T22:09:00.001+02:00

It's working!

As you can see in the following screenshot, I am able to launch two emu processes that communicate with my PS3, each one using a different bluetooth adapter. I then can connect an emuclient process to one of them.

The next task is to connect the same emuclient to both emu processes, so that each emu process can send commands to the PS3 at the same time.

This will need some more work, as the SDL 1.2 library (that is used to get events from input devices) is not supporting multiple mice and multiple keyboards. It supports multiple game devices though (joysticks, wheels, gamepads...).

EDIT:

It's not working for the following stuff:

- connect to a PS3 that already has a real sixaxis connected
- connect a real sixaxis after a sixaxis emulator and change the controller id

How to connect to an already started PS3

2010-10-19T23:06:00.000+02:00

I took some time to analyze the hci dumps I got with the sixaxis proxy.

I discovered what was preventing the sixaxis emulator to connect to an already started PS3.

The magic command is:

sudo hciconfig hci0 class 0x508

Explanation:

The following command gives the class of the bluetooth adapter:

hciconfig hci0 class

For ex my broadcom adapter has the following class:

Class: 0x480100
Service Classes: Capturing, Telephony
Device Class: Computer, Uncategorized

After executing the command, it gets the following:

Class: 0x000508
Service Classes: Unspecified
Device Class: Peripheral, Gamepad

That's the class of a sixaxis, and for a mysterious reason, it seems that the PS3 only checks it if it's already started!

Tip: execute this command after each hard/soft reset of the dongle.

To come: several sixaxis emulator running at the same time!

EDIT: this already was suggested by Jim Paris on forums.ps2dev.org (seems to be down right now but it's still available in google cache)

set bluetooth dongle in slave mode, piscan, class 0x000508

I don't know why, but I missed that each time I read this forum thread :\

Some new stuff coming soon...

2010-10-19T00:24:00.000+02:00

Since the beginning of my work with the sixaxis emulator (once again, based on the great work of Jim Paris), I have been looking for a way to get a dump of the bluetooth packets that are received and sent by a real sixaxis.

In May of this year, I was told by a reader of my blog that another French guy called Mikael Bouillot developed a sixaxis proxy. He is sharing his work on his website. I didn't get it work after some early tests and didn't go further until a few days. I asked Mikael some help to get his proxy working on my side, and he gave me the solution on a silver platter!

I'm now able to get the dump of the connection of any sixaxis.

Thanks to the analysis of these dumps, I hope to solve the following issues:

the sixaxis emulator can't be started if the PS3 is already started
another instance of the emu process doesn't work (probably the same issue as 1.)
since the 3.50 firmware version, some more requests are sent by the PS3

Stay tuned, some great stuff should come very soon!

Ubuntu & PS3 upgrades

2010-10-12T23:10:00.000+02:00

I upgraded my PS3 to the 3.50 firmware, and my PC to the 10.10 Ubuntu version.

It works without any trouble on my side.

There's a new trace in the emu process traces ("Unknown feature report [...]") but it doesn't seem to cause any issue. It seems the 3.50 firmware sends some more bt requests. Ideally the sixaxis emulator should respond to these new requests. It's added on my task list.

If you meet problems, please report them.

Stuffs we can't do with a mouse

2010-09-30T23:38:00.000+02:00

As I was playing Battlefield: Bad Company 2, I discovered a limitation due to the mouse to right stick translation.

A constant rotation speed is easy to apply with a stick. That's hard to do with a mouse!

In some situations it is required to emulate a constant max rotation speed. That's just impossible with a mouse.

Next tasks

2010-09-15T11:10:00.000+02:00

After a 1 month break, I want to continue working on the ps3 control.

Here is my task list:

head tracking - test freetrack & estimate portability
"dualshock 3" support - translate rumble to joystick/wheel force feedback (SDL 1.3 required)
motion sensing commands
cross-platform (windows and mac os)
multiple emulators + new usb requests of the 3.50 firmware
make a user manual from the tutorial
other enhancements

The tasks are ordered from the highest to the lowest priority.

Other stuff:

It is now possible to launch homebrew apps onto the ps3. It could be possible to launch an app onto the ps3 emulating a "local" sixaxis and grabbing events from usb input devices.

The PSGroove effect

2010-09-06T14:46:00.000+02:00

This is how I discovered the PSGroove hack was released: on 1. September, an unusual amount of internet users looking for "teensy++" visited my blog - about 4 times more visitors than usual.

Sixaxis emulator on a Ubuntu Live USB Persistent Flash Drive

2010-08-03T10:56:00.000+02:00

As explained in the tutorial there, the sixaxis emulator runs well with a Ubuntu Live CD. But the bad point of that method is that the installed packages & softwares are not persistent (everything runs from volatile memory, nothing is saved on disk).

I discovered it is really easy to setup a Ubuntu Live USB Persistent Flash Drive. This stuff makes the sixaxis emulator extremely transportable: just take your bluetooth dongle and your usb flash drive, plug them on any PC, boot from USB, and start the sixaxis emulator!

A quick & easy tutorial to setup a Ubuntu Live USB Persistent Flash Drive can be found there.

Windows support on its way

2010-07-26T10:52:00.000+02:00

After having tested a quick & ugly solution to get the sixaxis emulator work in windows (see last post), I decided to go further.

I already can run the emuclient process - which grabs events from input devices - as a native windows application.

I now want to run the emu process - which sends controls to the PS3 over bluetooth - as a native windows application too.

This task is hard because the windows bluetooth stack doesn't expose its l2cap layer.

I'm looking for a way to have a l2cap layer access.

The freebt stack could be used (this project seems to be dead).

There also is the btstack project, which is unfortunately not designed for windows. But it contains a great idea: a HCI USB Transport using libusb (not working yet).

~~I'm thinking to get this HCI transport working...~~

I'm going to test the freebt driver first. All drivers for all windows versions are available there. It provides access to the HCI layer, so I have to implement the needed l2cap functionalities.

Ugly windows solution

2010-07-24T03:11:00.000+02:00

Running the whole sixaxis emulator in a Linux Virtual Machine (with VirtualBox) was my first try.

But I discovered the input devices mapping from the host to the guest is not adapted at all: the mouse and the keyboard are emulated by VirtualBox, making the latency of the mouse higher, and breaking the precision of a high-end mouse.

Then I realized that the client/server architecture allows to run the emu and emuclient processes on different machines.

As you can see in the below screenshot, I decided to run the emu (which sends data to the PS3) in a Linux Virtual Machine with a command-line only linux (slitaz-base), and the emuclient (which grabs input device events) in the host Windows machine. The emuclient connects and send data to the emu through TCP/IP. The installation of slitaz+sixaxis-emulator librairies takes about 350Mo of disk space.

It works (seems to be playable), but not as good as the Linux-only solution: there obviously is more latency.

EDIT: some details if you want to try that.

Notes:

- Perform the sixaxis emulator tutorial in a VM first (if step 1 doesn't work, try that step with a livecd).

- The network interface of the VM has to be configured in "Host-only networking" (that's how it is called in VirtualBox, see there). If you can ping the VM Guest Linux from the Host Windows and vice versa, it should work!

- The usb bluetooth dongle has to be added to the VM usb devices.

1/ [VM/Guest Linux] in emu.c, change that line in tcp_listen function:

addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK); // Listen only on localhost

to

addr.sin_addr.s_addr = htonl(INADDR_ANY); // Listen on any interface

Recompile emu process (make).

2/ [Host Windows] Get http://www.libsdl.org/release/SDL-1.2.14-win32.zip

Extract it. Copy SDL.dll to C:\Windows

3/ [Host Windows] Get http://diyps3controller.googlecode.com/files/sixaxis-emu.exe

4/ [VM/Guest Linux] Launch emu process as in the sixaxis emulator tutorial. It should power on the PS3.

5/ [Host Windows] Launch sixaxis-emu.exe with the ip address of the VM/ Guest Linux as argument. It should connect to the emu process running in the Guest Linux.

Handfree PS3 controller

2010-07-07T10:08:00.000+02:00

OneSwitch.org.uk asked me yesterday about the feasibility of a handsfree ps3 controller. This kind of controller is especially great for people with disabilities, and I'm sure everybody can take the fun out of it.

The sixaxis emulator receives events from "common" input devices (mouse, keyboard, game devices) and translates them into ps3 controls.

There's nothing preventing us to use a head tracking system (more generally, a gesture recognition system) and a voice recognition system as "handfree" input devices.

And a combination of common and handfree input devices is even possible...

I googled about a Linux head tracking system. Many projects are using the OpenCV library. I finally found a great project called EHCI - Enhanced human computer interface through webcam image processing library.

A demo to get 3d position of the head is available there. Head position could be translated into thumbstick movements. For example, this could be used to aim in FPS games (right thumbstick).

I have plenty of functionalities to add to the sixaxis emulator... but as always, the fun ones come to the top of my list!

My next task will be to get a demo of head tracking used to aim in a FPS.

EDIT July 9:

In the youtube video demonstrating a handfree PS3 controller, there is no technical details about how it works, so it could be fake. The only alternative ways to control a PS3 are external emulators, like using a PC+bluetooth or a programmable usb controller. Running a piece of software on the PS3 itself (while gaming) hasn't been performed yet.

EDIT August 5:

I tried the EHCI 6DOF head tracking, but I think it's not and not stable and accurate enough for playing purposes. With my latest work about using the sixaxis emulator in windows, I'll be able to test the freetrack 6DOF head tracking (unfortunately not available in Linux), which seems to be approved by many gamers (see videos on youtube). This system requires a webcam and a small additional hardware (quite simple = 3 IR diodes, some resistances and a battery). It can emulate a standard joystick with 6 axis. Events from this joystick can be easily grabbed by the sixaxis emulator, and mapped to some sixaxis controls (as I already did for a steering wheel). I probably will test that at the end of August.

Sixaxis emulator in a Virtual Machine

2010-07-04T14:39:00.000+02:00

I recently was asked about running the sixaxis emulator in a VM (Virtual Machine).

As the sixaxis emulator is not designed to work in any other OS than Linux (mainly because the bluetooth stack is not as open in other OSes), running the sixaxis emulator in a VM could be a work-around for people that can't (or don't want to) install Linux on their machine.

With Windows Vista running VirtualBox/Ubuntu, I tried to perform the Sixaxis emulator tutorial.

Only step 1 doesn't work: it seems the usb connection with the sixaxis doesn't work as expected.

This is not a big issue since step 1 can be done once and for all with a livecd on any pc.

The only thing to care about is to disconnect usb devices from the VirtualBox before unplugging them.

With VirtualBox+Ubuntu, I get too much lag with the mouse, so that it can't be used to play. I'm going to test other VMs.

About cheap CSR dongles

2010-06-23T21:24:00.000+02:00

I was thinking the Bluecore4-ROM dongles can't have their bdaddrs (bluetooth device address) changed... I was wrong! Curiously, these dongles seem to have some writable non-volatile memory!

I bought 4 Bluecore4-ROM dongles on ebay - 3$ each - about a month ago, and thought at the beginning they wouldn't work.

But some people told me that the bdaddr of their Bluecore4-ROM bluetooth dongle can be modified permanently...

I finally received them, and as expected, I got their bdaddr changed permanently :-)

The only bad thing is that 2 of the 4 dongles I received are not, as advertised, CSR dongles with Bluetooth 2.0+EDR (i.e. Bluecore4 dongles). One seems to be an old bluecore1 dongle (its bdaddr can't be changed), and another one seems to be a counterfeit (it has the CSR product and vendor ids, but it does not contain a CSR chip) and doesn't work at all.

EDIT August 4: Sellers usually don't tell which CSR chip is inside a bluetooth dongle. The key point is that bluecore4 implements bluetooth 2.0+EDR. Therefore, a dongle advertised as a CSR dongle with bluetooth 2.0+EDR should contain a bluecore4 chip (or newer). Be careful, it seems some sellers are retailing old bluecore1 dongles as CSR dongles with bluetooth 2.0+EDR. Bluecore1 chips can't have their bdaddr changed!

Joystick support

2010-06-16T09:09:00.000+02:00

Last sunday I went to a bric-a-brac sale. I was looking for a steering wheel to adapt to my emulator. I bought a Wingman Formula Force GP for 5€:

This wheel is quite old - it was released in 2002 - but it still has a force feedback and a usb connector (older steering wheels have a gameport connector). It is probably outdated but I bet I can't find better for that price.

I committed some code that enables the use of this controller with the sixaxis emulator. It uses the joystick API of the SDL library. The code is not well designed and has some limitations (only one joystick plugged to the PC, mappings are hardcoded...), but it is for now a proof of concept. It can be activated by modifying the Makefile: remove the # character from the line "#CFLAGS+=-DJOYSTICK", and perform a make clean and a make.

Note that your joystick may be wrapped by default to a mouse and/or a keyboard by your linux distro. This is annoying because it generates extra mouse/keyboard events that interfere with real mouse and keyboard events in the emulator. This behavior can be configured/removed with the xinput command line utility. For more info on that command, type "xinput --help".

The ultimate sixaxis emulator

2010-06-09T11:46:00.000+02:00

Several input devices (keyboards, mice, wheels, joysticks...), several bluetooth dongles...

Guess what?

I'm thinking to make the sixaxis emulator capable of emulating several sixaxis at the same time, and reading several input devices at the same time (several mice, several keyboards...).

The emuclient process (responsible for grabbing input events) will connect to several emu processes (responsible for connecting and sending data to the PS3).

The bad thing is that the SDL 1.2 is not designed to handle multiple mice/keyboards (unlike joysticks). For mice and keyboards, the origin of an event can't be known.

With the coming SDL 1.3, it seems that multiple mice can be handled at the same time thanks to the merge of the ManyMouse library.

I looked closer to the source code, and it seems that multiple keyboard can be handled by the SDL 1.3 too!

EDIT 12/06: the multi-mouse / multi-keyboard support has been removed from the trunk of the SDL library. It will be re-added in a near future => the multiple sixaxis emulator is postponed.

Sixaxis emulator: coming functionalities

2010-06-08T09:43:00.000+02:00

Yesterday, I wanted to start playing Battelfield Bad Company 2 with the sixaxis emulator.

The great thing with this game is that you can control vehicles including helicopters.

As the sixaxis controls slightly differs from COD MW2, I started to play after doing small changes to the keymap.

Note that the dead zone is 8 for that game. I had to increase - x2 - the multiplier, but this depends on the mouse - mine is a G5 set to the highest sensitivity.

But I quickly saw that the keymap for infantry does not fit to vehicles driving very well.

A great thing to add to the sixaxis emulator is the ability to alter the keymap: a press on a key can change the keymap, so that several keymaps can be used while playing a game. Example: press F9, it emulates a circle button press (=enter into the vehicle) and changes the keymap!

For helicopter driving, there is nothing better than a joystick. I own an old ST200 usb joystick that I'm going to use with the sixaxis emulator!

Sixpair-emu customizer

2010-05-26T00:39:00.000+02:00

The final sixpair-emu firmware for the Teensy++ is available there.

I wrote a small python app that makes the customization of the sixpair-emu easier: nothing to compile, no firmware to download (except the pre-compiled initial one) to the Teensy++!

It looks like this:

Disclaimer:

use it at your own risk
the (vendor id, product id) = (0x054c, 0x0268) is the property of Sony

Instructions:

plug the Teensy++ to the PC
download the firmware to the Teensy++ with the Teensy loader
if the bluetooth device to be used is a dongle, then plug it to the PC (if external)
launch the sixpair-emu customizer
select the Teensy++
select the bluetooth device, or select and edit custom bdaddr
select the (vendor id - product id): sixaxis = 0x054c - 0x0268, original firmware = 0x03eb - 0x2042
clic apply (if there is no change, the application tells nothing was modified)
unplug the Teensy++
plug it to the PS3

=> the bluetooth device is registered as a Sixaxis by the PS3, so that it can connect to the PS3 as a sixaxis!

If a Teensy++ or a bluetooth device is plugged after the application is started, the refresh button allows to refresh the gui without restart.

Python code is available there.

Ubuntu:

It requires following packages:

python 2.6.5
python-tk
libusb > 1.0
pyusb > 1.0
pybluez 0.18

It has to be launched in a terminal with the following command:

sudo python sixp-emu-cust.py

Windows:

(tested in windows vista)

- python 2.6.5 (includes python-tk)
- libusb filter driver 1.1.14.0
- pyusb 1.0.0-a0 (to be installed in cmd shell with 'setup.py install')
- pybluez 0.18

(the bdaddrs are not read, but custom bdaddr can be set)

The Hackaday effect

2010-05-19T09:03:00.000+02:00

Thanks a lot to hackaday for the two posts about my diy ps3 controllers (first and second).

As you can see in the chart below, it made the number of visitors took off. The peaks correspond to the time the posts were in 1st page.

Sixpair-emu

2010-05-19T00:17:00.000+02:00

[deprecated - see newer post]

The code to get a teensy++ pair a bluetooth device with a PS3 is available there.

Disclaimer:

use it at your own risk
the vendor id and the product id are the property of Sony

To get it working, the following changes have to be done:

In sixaxis_pair_emu.c, edit the following lines:

uint8_t EEMEM DeviceBdaddr[6] = {0x01, 0x02, 0x03, 0x04, 0x05, 0x06};
uint16_t EEMEM VendorId = 0x03EB;
uint16_t EEMEM ProductId = 0x2042;

If your bdaddr is 11:22:33:44:55:66 then replace {0x01, 0x02, 0x03, 0x04, 0x05, 0x06 } with {0x11, 0x22, 0x33, 0x44, 0x55, 0x66 }.
The vendor id of a sixaxis is 0x054c, and the product id is 0x0268.

For now, you have to compile the firmware yourself.

Enhancements that I planned to do:

~~make the PS3 bdaddr be learnt by the device (but not persistent)~~ done
~~write the variables that have to be modified in the eeprom~~ done
~~make a specific usb request to modify them~~ done
~~make a definitive firmware~~
~~make a linux/windows gui app~~

Sixutils

2010-05-18T13:35:00.000+02:00

During my investigations to pair a bluetooth device as a sixaxis with my PS3, I modified the original sixpair code:

sixaddr.c is a tool to get the sixaxis device address and the PS3 device address (not useful for the investigation, but it is great for step 1 of the sixaxis emulator tutorial)
sixdump.c is a tool to get all the usb get requests answered by a sixaxis (used in step 2)
sixmod.c is a tool to see the effect of a particular usb set request on the sixaxis (used in step 3)

I couldn't have made the 'pairing device' work without this code!

Pair any bluetooth device with a PS3 as a Sixaxis!

2010-05-16T23:21:00.000+02:00

I have just paired my broadcom dongle with my PS3 as a Sixaxis :-p

I did this without modifying the dongle: this dongle is built on a broadcom chipset, which does not allow bdaddr modification!

I lately have been looking for ways to do that:
- I tried to modify the bdaddr of a sixaxis so as to make it pair the bdaddr of a dongle (you never know, it could have worked - and testing that was very easy)
- I tried to emulate a sixaxis with a usb development board

The development board is a Teensy++, but the code written for this device can be ported to any other atmel usb development board supported by the LUFA framework, such as the bumble-b for example.

Steps of the work:

1/ I wrote the usb hid layer and the "sixpair interface" (3 host to device requests: set master bdaddr, get master bdaddr, and get device bdaddr), and got the usb exchanges with a Linux host (sniffed with Wireshark/usbmon) be identical

=>pairing failed

2/ I bombed a real sixaxis whith "get report" control requests so as to see all the wValue that give responses, and implemented these request responses

=>failed too

3/ I connected my jtagice mkii debugger to my teensy++, made the teensy++ write some request logs in memory, and inspected them.
I identified the request that was blocking, did the same request to a real sixaxis, and saw the response it should give.

=>success!!!

The sixaxis can now be emulated with any bluetooth device!

Sixaxis emulator: keyboard macros

2010-05-14T01:42:00.000+02:00

It's now possible to configure keyboard macros.

A key press will generate a series of events, with timing conditions.

Commands are the following:
- key down
- key up
- key press (= key down + delay + key up)
- delay (unit = ms)

Each macro has to be defined in a file.

Example: macro_example.txt

#Defines the action that triggers the macro execution
MACRO F1
#Performs a keystroke (key down + delay 50ms + key up)
KEY e
#Sleep 50ms
DELAY 50
#Perform a key down
KEYDOWN SPACE
#Sleep 50ms (minimum delay between KEYDOWN and KEYUP)
DELAY 50
#Perform a key up
KEYUP SPACE

Lines beginning with # are comments.

Each macro file has to be referenced in the macros.txt file.

All keys of the keyboard can trigger a macro. The complete list can be found in macro.c.

Remaining work:
- support for mouse events (buttons + moves)
- record/replay functionnality

Please give me a feedback!

2010-05-12T09:01:00.000+02:00

I'm sharing my project for free, so please give me a feedback if you test(ed) it.

Tell me if it works or doesn't work, and especially add the following details:

the tutorial (hidemulator or sixaxis emulator)
the Linux distribution
the libraries (if different from those suggested in the tutorials)
the PS3 hardware version (slim, fat 40Gb, fat 60Gb, ...)
the PS3 firmware version
the bluetooth dongle (exact model + revision if there is one + output of "hciconfig -a hci0" and "sudo hciconfig hci0 revision")
the hardware of the PC (at least the CPU and the amount of RAM)

Report that in commentary to this post.

And if it doesn't work, first verify if you have the latest source code. Then look at the bug list, see if your problems are already known, and if it's not, report them.

The project is still in development. A critical issue remains, and I'm actively working to solve it. The code works actually great on my side, so that it wouldn't be possible for me to be aware of that issue without feedback!

Another way to pair a dongle with the PS3 as a Sixaxis - 2

2010-05-10T20:13:00.000+02:00

A usb device (such as a teensy++, a bumble-b or an atmel chip+vusb) can talk to the PS3 as an "unpaired" sixaxis.

I think it has to have the following characteristics:

the same vendor id and product id
the same hid descriptor
after a small delay, the device sends a PS3 button press
when the PS3 requests for the bdaddr, reply with the bdaddr we want to pair
when the PS3 sends its bdaddr, reply "ok"

Another way to pair a dongle with a PS3 as a Sixaxis?

2010-05-10T13:28:00.000+02:00

Another way to pair a dongle with the PS3 as a Sixaxis could be to change the bdaddr of a Sixaxis with the bdaddr of a dongle, and pair that Sixaxis with the PS3.

It seems that the bluetooth module of the sixaxis is composed of a CSR chip and an additional chip (flash memory?), so that there is a little chance that the bdaddr can be changed.

The bdaddr of the bluetooth master can be get/set with usb commands (as seen with sixpair utility). I'll try to do the same with the bdaddr of the sixaxis (it is already known that there is a get command).

Pros:
- any bluetooth dongle could be used
- using a widcomm compatible dongle could make possible to port the sixaxis emulator to windows
- the sixaxis bdaddr could be reset to its original value so that the sixaxis and the sixaxis emulator could be used at the same time

Cons:
- none

This method doesn't work, the command just fails.

Critical issue corrected! Problème critique corrigé !

2010-05-07T20:10:00.000+02:00

There was a potential buffer overrun in the stack, sorry about that (issue 6).

Please perform step 3 again before creating any issue in googlecode.
-----
Il pouvait se produire un dépassement de buffer dans la pile, désolé (issue 6).

Merci de répéter de nouveau l'étape 3 avant de créer tout rapport de bug dans googlecode.

Compatible CSR bluetooth dongles

2010-05-07T14:58:00.000+02:00

Edit 24/06: Bluecore4-ROM dongles may work too!

It is quite difficult to tell if a usb dongle will work or not (even for CSR chips).

And not to make it easier, dongle manufacturers can change the chip without changing the product name... So be careful about hardware revisions!

I suggest CSR chips such as BlueCore2-ext and BlueCore4-ext. There is no guaranty it will work.

Older CSR chips may work (as the dongle I'm using - Cellink BTA-3000).

There is valuable information about BlueCore2-ext dongles and BlueCore4-ext dongles on that blog and that forum thread.

A list of dongles with BlueCore2-ext can be found there (p.98-104).

Playing FPS with a G5 on PS3 ;-)

2010-05-05T00:33:00.000+02:00

I did it! That feels almost like playing a FPS on a PC ^^

I seriously hope console manufacturers and game developers will think about giving us the right controller for each type of game... But I think they won't, as they actually seem to put all their efforts in those new controllers for casual gamers...

Tutoriel : Sixaxis emulator

2010-05-04T16:01:00.004+02:00

Attention: ce tutoriel n'est plus à jour. Nouveau tutoriel : lien.

» Ancien contenu «

Sixaxis emulator tutorial

2010-05-04T13:30:00.004+02:00

This tutorial is deprecated. New tutorial: link.

» Oudated content «

Working with the C code of Jim Paris

2010-05-04T11:02:00.000+02:00

After having tested the hidemulator python code, I decided to go further with the C code of Jim Paris.

This code produces two executable files:
- a server, that interfaces with the PS3, and that maintains the bluetooth connection
- a client, that interfaces with peripherals thanks to the SDL library, and that sends controls to the server

Pros:
- no need to interrupt the bluetooth connection when exiting the client => no need to restart the PS3 => easier to test
- no need to install python libraries
- better performance of C code over python
- client/server architecture allows developing other clients (imagine a mobile phone client!)

Cons:
- less portable than python code
- I already have strong C code knowledge, so that I'm not learning something new ;-)

I did the following modifications to the server:
- send a report immediately after receiving a command from a client
- send a report if no command was received during 1 second

And to the client:
- poll for events each 10ms, and merge all received events (a single command is sent to the PS3)
- grab raw input from the mouse (i.e. relative position), and constrain the mouse into the window
- custom controls for mouse and keyboard (to play fps games)
- on-the-fly modifiable multiplier for mouse movements (to increase/decrease sensibility)

Remaining work:
- ~~scroll up/down generates two events (SDL_MOUSEBUTTONDOWN & SDL_MOUSEBUTTONUP) that should not be merged~~
- ~~write a tutorial~~
- ...
- integration testing = play! ;-)

Code is available there.

Hidemulator Tutorial

2010-05-01T14:41:00.000+02:00

Introduction

This tutorial explains how to control a PS3 with a keyboard and a mouse plugged on a PC running Linux and using a bluetooth dongle.

This is possible thanks to the hidemulator (derived from the work of Jim Paris).

For gaming purposes, I suggest the sixaxis emulator tutorial instead. The hidemulator is not optimized for games.

Requirements

ubuntu 10.04 Live CD (or any other Linux distro if you are enough comfortable with Linux)

a sixaxis already used with the target PS3

a bluetooth dongle with a chip from one of these manufacturers: Ericsson, Cambridge Silicon Radio (CSR), Texas Instruments (TI), Zeevo or ST Microelectronics (ST)

There are cheap (a few $) CSR Bluecore4 dongles on ebay. These dongles will probably work. See that post.

Notes

Do it at your own risk. I'm not responsible for any damage you can cause to your PS3 or PC.

The PS3 has to be started using the hidemulator (if hidemulator is stopped, the PS3 has to be shut down and restarted with the hidemulator to get it work again).

Unplug any other dongle from this PC (or deactivate them).

Don't try to use the hidemulator and the sixaxis at the same time, and restore the bdaddr of the dongle if you don't use it with hidemulator anymore.

This tutorial was written running ubuntu from the live cd (nothing is saved on the hard drive).

Don't forget to write down the bdaddr of the PS3 in step 1, so that you won't need to perform that step again.

Once step 2 is done, you don't need to do that step anymore since the bdaddr modification is permanent.

As steps 1 & 2 have to be done once, a easy way to launch the hidemulator with a live cd is to write a script for steps 3 & 4.

Feel free to install ubuntu on your PC! If you have a Windows OS installed, you can read this tutorial if you want to install ubuntu on your hard drive without erasing the Windows OS.

1 Discover the bdaddr of the Sixaxis and the bdaddr of the PS3

Plug the sixaxis to the PC with a usb cable

In a terminal (alt+F2, gnome-terminal):

sudo apt-get install libusb-dev

wget http://diyps3controller.googlecode.com/svn/trunk/sixutils/sixaddr.c

gcc -o sixaddr sixaddr.c -lusb

sudo ./sixaddr

Current Bluetooth master: XX:XX:XX:XX:XX:XX
Current Bluetooth Device Address: YY:YY:YY:YY:YY:YY

"Current Bluetooth master" is the bd_addr of the PS3 (write it down).
"Current Bluetooth Device Address: " is the bd_addr of the sixaxis (write it down).

Unplug the usb cable. Sixaxis should power off.

2 Modify the bdaddr of the dongle

sudo apt-get install libdbus-1-dev libglib2.0-dev

wget http://www.kernel.org/pub/linux/bluetooth/bluez-4.63.tar.gz

tar xzvf bluez-4.63.tar.gz

cd bluez-4.63

./configure --enable-test

make

(do not make install)

cd test

./bdaddr

Manufacturer: Cambridge Silicon Radio (10)
Device Address: 01:02:03:04:05:06

Write it down (so that it can be restored).

sudo ./bdaddr ZZ:ZZ:ZZ:ZZ:ZZ:ZZ

(replace the ZZ:ZZ:ZZ:ZZ:ZZ:ZZ with the bdaddr of the Sixaxis dicovered in step 1).

Unplug and replug the dongle.

./bdaddr

Manufacturer: Cambridge Silicon Radio (10)
Device Address: ZZ:ZZ:ZZ:ZZ:ZZ:ZZ

Make sure the bdaddr has been changed.

3 Install python libraries

Note for users that don't run ubuntu from the live cd: uninstall older versions of PyBluez and Pygame.

sudo apt-get install python2.6-dev libbluetooth-dev libsdl1.2-dev

cd ~

wget http://pybluez.googlecode.com/files/PyBluez-0.18.tar.gz

tar xzvf PyBluez-0.18.tar.gz

cd PyBluez-0.18

sudo python setup.py install

cd ~

wget http://www.pygame.org/ftp/pygame-1.9.1release.tar.gz

tar xzvf pygame-1.9.1release.tar.gz

cd pygame-1.9.1release

sudo python setup.py

4 Run the hidemulator

cd ~

sudo apt-get install subversion

svn checkout http://hidemulator.googlecode.com/svn/trunk/ hidemulator-read-only

cd hidemulator-read-only

chmod +x pair.py

gedit pair.py

Line 28, insert the bd_addr of the PS3 (discovered in step 1) between the quotes.

Make sure the PS3 is powered off.

./pair.py

The PS3 should power on!!!

To quit the hidemulator, just press Escape.

Note that the PS3 has to be started using the hidemulator.

I am a Sixaxis, I am a Sixaxis, I am a...

2010-04-30T23:47:00.000+02:00

I managed to control my PS3 from my PC, with the method described at forums.ps2dev.org.

It only works with one of the 3 dongle I tested.

All are able to power up the PS3, but connection is aborted with the 2 dongles that can't have their bluetooth device address changed permanently.

From my desktop pc that is located in another room, I pressed space key (cross button) to select the user, and right and left keys to navigate in the menu :-)

Next step: install a linux distro on a laptop so as to make intensive tests in front of my PS3.

PC as Sixaxis joystick - tests

2010-04-30T15:25:00.000+02:00

On a Linux PC, I tried to modify the bluetooth device address of some dongles:

- COM1 - broadcom chip - modification ok, but not persistent
- Linyx - ISSC chip - modification ok, but not persistent
- Cellink - CSR chip - modification ok & persistent

"Persistent" means that the modification is permanent, even after unplugging the dongle. These results are consistent with infos given there.

I didn't found out a way to modify this address in Windows (temporarily or permanently).

I discovered that pybluez requires the widcomm bluetooth stack to work with l2cap in Windows. ISSC and CSR chips are not supported (anymore) by the widcomm stack. Only my COM1 dongle can work with the widcomm bluetooth stack (property of broadcom company).

As a result I can't use any of these dongles with my hcpc (which runs Windows 7). I could install Linux on it, but I have a TV scheduler installed, so that it would not be possible to control the PS3 and record a TV show at the same time :-(

I have to find another bluetooth dongle, whose bdaddr can be permanently modified, and that works with widcomm stack...

Meanwhile, I will try the hidemulator with another PC running Linux.

PC as Sixaxis joystick

2010-04-29T10:47:00.000+02:00

Asking google about the "sixaxis report frequency", I got the answer on that forum page (seems to be down, but it is still in google cache: page1 page2) on which it is said that there is about 10ms between reports. That matches the mouse frequency in my project (100Hz), so that if the PS3 does not take more than 100 reports per second (to be tested), there is no need to increase it (ps/2 mouse maximum frequency is 200Hz).

This information is less interesting than the forum page itself. It is about using a PC to emulate a sixaxis via Bluetooth! Using a bluetooth dongle, the PC connects to the PS3 using the sixaxis's bluetooth device address. As I have a hcpc near my PS3, and want to use the same wireless keyboard+mouse to control both, I will definitely give it a try!

Links:

- hidemulator googlecode from Brandon (python code)
- source code from Jim Paris (C code)
- how to change bluetooth device mac address (Linux)

hidemulator should work with both Linux & Windows (to be tested).

Software to install:
- python 2.6
- pybluez
- pygame

pygame is used to get input events from mouse and keyboard. Joysticks could be used too.

I think pygame events are get from the OS (mixing all input devices: ps/2, hid...), and therefore may have been modified (accelerated mouse movements). It would probably be better to get raw data from the hid device. This can be done thanks to libhid that supports python.

Small wiki available

2010-04-28T21:10:00.001+02:00

http://code.google.com/p/diyps3controller/wiki/GettingStarted

It explains a simple way to install developpement tools for this project.

Checkout and build are explained too.

Project now works with bumble-b too!

2010-04-28T20:44:00.000+02:00

bumble-b is a mini usb developpement kit with at90usb162 microcontroller. It has a low price - 15$ - and price is digressive if you buy 5 (14$) or 10 units (13$).

The project now works on that board thanks to small updates of the code:
- port D is used instead of port E, which does not exist with at90usb162
- the mouse is reset (=initialized) in the main function, as a last initialization step (avoids a deadlock which seems to occur more with at90usb162 than at90usb1286)

The only modification that remains to build the project for the bumble-b is located in the Makefile: the MCU value has to be set to "at90usb162".

What's next?

2010-03-26T09:10:00.000+01:00

I managed to convert ps/2 devices (mouse + keyboard) to a ps3 controller (see older posts, from the oldest one).

Now, I want to use following devices with my PS3:

1- wireless usb keyboard + mouse (Logitech EX100)
2- usb mouse (Logitech G5) + ps/2 keyboard
3- usb joystick (Saitek ST200)

More ideas:
- add a mouse and a keyboard in the same usb hid device (so that mouse and keyboard can be used as mouse and keyboard too)
- control a pc with the same mouse and keyboard
- convert multiple usb devices to a single ps3 controller

=> I'm now planning to convert usb hid devices to a ps3 controller.

A first idea is to:
- use the v-usb framework for the usb device (ps3 controller)
- use the LUFA framework for the usb host (to get data from hid devices)

BUT Teensy++ is based on an AT90USB1286 chip which only supports usb device mode.

Therefore:
- I have to find an AT90USB647- or AT90USB1287-based board such as AT90USBKEY
OR
- I have to work with a software-implemented usb host stack such as that one.

I'm not sure that it will work on a single chip (see discussion there).

Source code finally available!

2010-03-25T00:57:00.000+01:00

I released the source code.
See http://code.google.com/p/diyps3controller/

It works great with COD MW2.

Farcry 2 code is deactivated with preprocessor conditions.

I probably will not work anymore on this ps/2 keyboard and mouse controller version, as I am planning to build a usb wireless keyboard and mouse controller...

Mouse to joystick translation - Call Of Duty Modern Warfare 2

2010-03-25T00:51:00.000+01:00

COD MW2 has a totally different behavior regarding the position to rotation speed relation.

Following chart gives the rotation speed (degrees per second) given the absolute position of z.
The joystick sensibility is set to the highest position.

The rotation speed is continuous and goes from low to very high values, so that the mouse to joystick translation is very easy to do: a simple x3 multiplier is sufficient.

The acceleration looks like the mouse acceleration that is performed under windows xp (described there).

Mouse to joystick translation - FARCRY2 - part 2

2010-03-10T09:17:00.000+01:00

It was explained in part 1 that absolute positions 1 to 82 give a linear rotation speed (from 0 to about 50°/s), and position 83 a high rotation speed (450°/s for z, 200°/s for rz).

Following chart gives the rotation speed for a given virtual position of z that goes from 0 to 645. That gives a linear speed from 0 to 450°/s. Virtual positions from 83 to 644 have to be created.

Blue dots are speeds that are achieved by real positions with a standard ps3 controller.
Red line is obtained with a simple linear regression.

Each mouse packet applies a rotation speed over a time that is the inverse of the mouse frequency (for ex 100Hz => 10ms).

A rotation speed for a virtual position between 83 and 644 may be generated "in average".

For example, if a speed of 450°/s is applied (virtual position 645=real position 83) over 5ms, and 0°/s is applied (real position 0) over 5ms, the average speed that is obtained over 10ms is 225°/s (virtual position 321).

0+83 makes crappy movements, that technique actually works great with 82+83

I realized afterward that it is similar to PWM.

Mouse to joystick translation - FARCRY2 - part 1

2010-02-17T23:29:00.000+01:00

(x,y) speed of the mouse has to be mapped to a (z,rz) rotation speed.

z and rz are in the range [0..255] with [83..173] as dead zone (128 is the center).

Following chart gives the rotation speed (degrees per second) given the absolute position of z.

This probably may change with the game (values are for Farcry).

This is quite linear except for the max position (83). The max speed that is in the linear area (position 82, about 50°/s) is not fast enough to only use the linear area. The speed of the max position is so fast (about 450°/s) that it shouldn't be used over a long time.

There is the same behavior for rz, except that the speed of the max position is about 200°/s).

A heuristic has to be found to trigger the max position use.

The HID descriptor

2010-02-17T20:55:00.000+01:00

The HID descriptor defines:
- 4 axis (x, y, z, rz)
- 1 hat switch
- 12 buttons

There are 13 buttons on a ps3 controller.
PS3 button is not very useful, omitting it allows avoiding padding.

/* Usage Page (Generic Desktop)*/ 0x05, 0x01,
/*Usage (Joystick)*/ 0x09, 0x04,
/*Collection (Application)*/ 0xA1, 0x01,
/*Collection (Logical)*/ 0xA1, 0x02,
/*Logical Minimum (0)*/ 0x15, 0x00,
/*Logical Maximum (255)*/ 0x26, 0xFF, 0x00,
/*Physical Minimum (0)*/ 0x35, 0x00,
/*Physical Maximum (255)*/ 0x46, 0xFF, 0x00,
/*Report Size (8)*/ 0x75, 0x08,
/*Report Count (4)*/ 0x95, 0x04,
/*Usage (X)*/ 0x09, 0x30,
/*Usage (Y)*/ 0x09, 0x31,
/*Usage (Z)*/ 0x09, 0x32,
/*Usage (Rz)*/ 0x09, 0x35,
/*Input (Data,Var,Abs,NWrp,Lin,Pref,NNul,Bit)*/ 0x81, 0x02,
/*Logical Maximum (7)*/ 0x25, 0x07,
/*Physical Maximum (315)*/ 0x46, 0x3B, 0x01,
/*Report Size (4)*/ 0x75, 0x04,
/*Report Count (1)*/ 0x95, 0x01,
/*Unit (Eng Rot: Degree)*/ 0x65, 0x14,
/*Usage (Hat Switch)*/ 0x09, 0x39,
/*Input (Data,Var,Abs,NWrp,Lin,Pref,Null,Bit)*/ 0x81, 0x42,
/*Unit (None)*/ 0x65, 0x00,
/*Logical Maximum (1)*/ 0x25, 0x01,
/*Physical Maximum (1)*/ 0x45, 0x01,
/*Report Size (1)*/ 0x75, 0x01,
/*Report Count (12)*/ 0x95, 0x0C,
/*Usage Page (Button)*/ 0x05, 0x09,
/*Usage Minimum (Button 1)*/ 0x19, 0x01,
/*Usage Maximum (Button 12)*/ 0x29, 0x0C,
/*Input (Data,Var,Abs,NWrp,Lin,Pref,NNul,Bit)*/ 0x81, 0x02,
/*End Collection*/ 0xC0,
/*End Collection*/ 0xC0

Above screenshot shows the result of this hid device with jstest-gtk as joystick calibration program (axis 4-5 are not relevant).

position	speed	1:1 speed	1:1 position
1	0	8	7
...	...	...	...
32	91	140	57
...	...	...	...
64	295	480	85
...	...	...	...
96	589	720	108
...	...	...	...
128	960	960	128

position	speed	1:1 speed	1:1 position
1	0	8	7
...	...	...	...
32	91	140	57
...	...	...	...
64	295	480	85
...	...	...	...
96	589	720	108
...	...	...	...
128	960	960	128

position	speed	1:1 speed	1:1 position
1	0	8	7
...	...	...	...
32	91	140	57
...	...	...	...
64	295	480	85
...	...	...	...
96	589	720	108
...	...	...	...
128	960	960	128