Game Input MultipleXer

I am making a similar device, I am using a STM32F2 microcontroller (it has two OTG interfaces), the USB host interface is connected to a USB hub (with mouse and keyboard downstream) and the USB device interface is connected to a PS3, and eventually, the PS4.

I also own a Beagle USB 12 analyzer and I am reverse engineering the data between the Dualshock 3 and the PS3. I have come across a series of control requests from the PS3 and I can see the reply data, but I do not understand what they really mean.

I am reading your source code in https://code.google.com/p/diyps3control ... axis_emu.c and you send back similar replies in "buf301" and such, but your code comments do not really tell me what they actually mean. Are these packets Bluetooth MAC addresses? Calibration data for the ADCs? Serial numbers? UUID/GUID of some sort?

What are "bdaddr" and "masterBdaddr"? Is that the Bluetooth MAC address or something? What is "byte_6_ef"?

Thank you, let me know if you are interested in my hardware. I might give you a PCB of the next revision.

I moved your post to the dev section.

"bdaddr" stands for bluetooth device address, which is a unique identifier used in the bluetooth protocol.

In the source code, bdaddr refers to the sixaxis, and masterBdaddr refers to the PS3. byte_6_ef is just some value that is set by the PS3...

I don't know the meaning of every single byte. If you find out the use of other bytes, please tell it.

thanks for the fast reply

your code is very useful as a reference in my project, thank you, my own project will definitely become open source once I finish it.

there's a set report request to wValue 0x03F4, I don't see it handled in your code, it's a wLength 4 byte request, the contents are "42 0C 00 00"

there are two possibilities, either it sets the LEDs or it enables the interrupt-in transfers, which start immediately after this request

do you know what this one means? i can just ignore it but i am curious

This request is handled in the bluetooth code: http://code.google.com/p/diyps3controll ... axis.c#266

cool thanks

I am making a revision of my PCB. It's a STM32F2, one end is USB host and the other end is USB device.

My current code can read multiple HID interrupt-in endpoints downstream from a USB hub using the host side. The device side enumerates as a Dualshock 3 thanks your help.

Once I get the revision, I'll test it again and maybe send you one as a gift.

Here's a preview http://i.imgur.com/mPosxUy.png

It looks cool

Here's the first revision: http://i.imgur.com/6joYIzr.jpg , that version had a 3 port hub built in, and some other fancy (but useless) features. I also completely screwed up the oscillator circuit for the hub so there's some hacked up soldering going on.

But I figured an extremely simplified version without the hub would be more flexible to hackers, and since it's so cheap I can give a few of them away. If you need the hub for both keyboard and mouse, just provide your own, which should be $2 these days.

by the way, I just got a DualShock 4 and I am working on reverse engineering it. I already got some basic USB captures, and a full teardown. http://eleccelerator.com/wiki/index.php ... ualShock_4 and http://imgur.com/a/ytRW5

I also plan to work on the next-gen consoles... I started a fundraising a few days ago

I would not be surprised that Sony added something to block non-licensed third-party joysticks on the PS4, like Microsoft did for the 360.

I don't really care too much about the security challenge and response system. All it really means is that you must own at least one genuine controller and plug it in. It's not too much of a hinderance for either of our setups. It's not the end of the world.

But it does mean that there's no dirt cheap controllers on the market, which is disappointing.

Although I don't think the microcontroller that Sony used has any built-in AES hardware. I remember the Xbox 360 had hardware DES.

frank26080115 wrote:All it really means is that you must own at least one genuine controller and plug it in. It's not too much of a hinderance for either of our setups. It's not the end of the world.

This is what many adapters (including GIMX) do.