Posts

Posted on

Connection errors

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.

Posted on

What’s next?

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.

Posted on

Version 0.20 released

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!!

Posted on

A tool to estimate the latency

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.

Posted on

Mouse mapping improvement – 2

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, x = 0
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, x = 0
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 🙁

Posted on

Beware of CSR counterfeits!

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:

  1. 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.
  2. 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!

Posted on

My working dongles

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 😉