Gamepadproxy

[J2Kbr]

Thank you Matlo.
I'm very happy to participate of the GIMX project.

[J2Kbr]

Malto, How's the progress with GIMX and GPP? Did you found something about the latency issue?

I'm working on an API (windows) for direct access the GPP, very similar to what we did with libusb on Linux. I got some results that surprised even me. On the PS3 we achieved a rate higher than 400 updates/s, with average latency around 2.3ms. On the XBox 360 the rate is above 800 updates per second, with average latency of 1.2ms.

Here is a video with these tests.

http://youtu.be/oUgYru7GYRk

The difference between the XBox 360 and PS3 is caused by the difference in complexity of the protocols between these controllers.

[Matlo]

I managed to work-around the libusb latency problem. I'm now using the hidraw device in Linux.
I've no idea about when I will be able to make a new release with this functionnality...

On the PS3 we achieved a rate higher than 400 updates/s,

I thought the ps3 was only polling the sixaxis at 100Hz?

with average latency around 2.3ms.

What latency are you measuring in your tests?
The time between the usb packet from the gamepad and the usb packet to the console?

[J2Kbr]

I thought the ps3 was only polling the sixaxis at 100Hz?

If you look at the USB descriptors of DS3 the "interval" parameter of endpoints is 1 (1 ms), which means a max pooling rate of 1000Hz. I'm not sure about Bluetooth pooling rate.

What latency are you measuring in your tests? The time between the usb packet from the gamepad and the usb packet to the console?

I'm measuring, basically, the time required to send a data packet from the application to the GPP and, consequently, to the console.

Anything I can do to help you in relation to GIMX and GPP, please just tell me.

[Matlo]

If you look at the USB descriptors of DS3 the "interval" parameter of endpoints is 1 (1 ms), which means a max pooling rate of 1000Hz. I'm not sure about Bluetooth pooling rate.

The BT polling rate is 100Hz, and I thought the USB polling rate would also be 100Hz. But you are right about the USB descriptor

Anything I can do to help you in relation to GIMX and GPP, please just tell me.

The source code is already commited to the svn repo, but I still need to code a few things for the Linux hidraw layer.
If you can test the windows code, please do it.
There is a wiki about how to build GIMX in Windows there: link.

[Matlo]

I did the same test in Linux with a PS3 and I got similar numbers.

If you look at the USB descriptors of DS3 the "interval" parameter of endpoints is 1 (1 ms), which means a max pooling rate of 1000Hz.

As this interval is 4ms for the 360 pad, it is useless to send updates faster than 250Hz to the GPP connected to a 360, right?

[J2Kbr]

I did the same test in Linux with a PS3 and I got similar numbers.

Good!

If you look at the USB descriptors of DS3 the "interval" parameter of endpoints is 1 (1 ms), which means a max polling rate of 1000Hz.

As this interval is 4ms for the 360 pad, it is useless to send updates faster than 250Hz to the GPP connected to a 360, right?

You're right about the interval of XBox360. But ... if you looking at the USB descriptors of GPP, in both XBox360 and PS3 modes, you will see that I changed the bInterval of EndPoints to 0.

I did it not to increase the update rate, but to decrease latency to the maximum. Making bInterval 0 allows the GPP send a data packet to the console as soon the packet is ready. Otherwise the GPP would have to wait up to 4ms (XBox360) before be able to send the packet, the time required to receive the token IN of the USB protocol.

For sure is great be able to send hundreds of updates per second to the console. But we must agree 100 updates/s is more than enough. During the project phase of the GPP I remember reading, in a documentation about design for gaming devices, that a minimum recommended for a good experience is 50 updates/s.

I looked at the procedure to compile GIMX on windows. As it needs to install a new compiling environment, I'll do it during the weekend.

[]'s

[Matlo]

You're right about the interval of XBox360. But ... if you looking at the USB descriptors of GPP, in both XBox360 and PS3 modes, you will see that I changed the bInterval of EndPoints to 0.

I actually had a look at the USB descriptors of the GPP but I didn't see such values. I guess that's because I still have not updated the firmware.

The usb spec specifies that bInterval should be in 1-255 for full-speed devices.
What's the effect of setting 0 as bInterval? Does the host still poll the device each frame = 1ms?

[J2Kbr]

I actually had a look at the USB descriptors of the GPP but I didn't see such values. I guess that's because I still have not updated the firmware.

I just checked here and actually bInterval values ​​are no longer 0, I had changed it when I did some compatibility testing. I'll return these parameters to 0 (or 1) in the next FW.

The usb spec specifies that bInterval should be in 1-255 for full-speed devices.
What's the effect of setting 0 as bInterval? Does the host still poll the device each frame = 1ms?

For being counter I believe make it 0 has the same effect as if it was 1, since 1ms is the smallest unit of time for tokens transmission of USB protocol. I "copied" this idea from a Bluetooth adapter I have here, which has bInterval = 0 in some endpoints.

[J2Kbr]

Matlo, was very good we have had this discussion. I had forgotten the detail about the bInterval. The important thing is I've already patched it, now the bInterval value is 1, for both PS3 and XBox360.

I tested with 0 and the reception rate of IN tokens remained 1000/s, so there's no reason to keep it at 0.

When you get a chance do the firmware update, I'm already working on version 1.08 and it has had many improvements since version 1.01.