T3.6 USB Host - Bluetooth

I just ordered one Ebay - should be here mid next week. Looked quickly at the links and after poking around a little found a few more referenced sites. I'll keep poking around:

EDIT: More info
Programmer's Notes
PSMoveService-Programmer-Notes
ClientPSMoveAPI-Programmer-notes
PSMoveProtocol
Alex's Notes on the PSMove HID Protocol

EDIT2: Buried at the end is a lot of info on the http://thp.io/2010/psmove/ implementation especially in the appendices
 
Last edited:
@mjs513 - Thanks

As I mentioned, I have been a little distracted, but have made a little progress with this...
IMG_0109.jpg
I know have the setLEDs working... Note, I created a new version of this API that allows you to pass in a uint32_t for all 3 LEDS... Hopefully I did not screw it up for other joysticks... Will
hopefully try some other later.

Have not decided yet, to push up my changes into the BT branch or create a new branch off of BT, that we can update and then pull into BT once working... Probably depends on how much I get working, before you get yours to play along ;)

P.S. - I had to edit the photo first as I had picture showing T4...

Edit: It looks like I also have the JoystickBT example app setup to cycle through colors and if a BT dongle was detected (either now or previous), it does do the pairing... And I now am able to have the BT dongle in place and hit the PS button on it and it looks like it starts up the pairing... I also have it matching the name and knows that it is a PS3 motion joystick...

Next up to try to get data from it...
 
Last edited:
@KurtE

Nice job to get that far. You merged the BT changes into the your master branch? If you did then would say put the Move into the BT branch. Know mine has been shipped and coming from Florida - so you may well be done before I start playing and testing :)
 
@mjs513 and @Paul...

I have not merged yet - Paul is the owner of the library and the BT stuff is in a current PR...

For some reason Paul has been busy with some other stuff ;)

Kurt
 
@KurtE

As to Paul being busy that is a little understated :)

Anyway maybe just create its own branch for now until we know its working and didn't break anything.
 
Just pushed up some more changes to the new branch.

I now have it talking using Bluetooth. I still have not gone through mapping all of the axis. I think it has mostly gyro and aceel data...

But I do have the buttons mapped through, plus right now it appears like the trigger button is on axis[0]...
So updated joystickBT app, to have different display handling stuff for this one, currently does not show much.

You can press the select button (on side of it) to toggle to show raw data.
Also pressing the trigger will rumble and
pressing some of the buttons like TRI... Will set the bulb color. There are three buttons that set Red, Green, blue to either 0 or 0xff and so you have combo of colors.

So making a little progress!
 
@KurtE
Poked around the reference links and found this structure which might help with the mapping:
Code:
typedef struct {
    unsigned char type; /* message type, must be PSMove_Req_GetInput */
    unsigned char buttons1;
    unsigned char buttons2;
    unsigned char buttons3;
    unsigned char buttons4;
    unsigned char trigger; /* trigger value; 0..255 */
    unsigned char trigger2; /* trigger value, 2nd frame */
    unsigned char _unk7;
    unsigned char _unk8;
    unsigned char _unk9;
    unsigned char _unk10;
    unsigned char timehigh; /* high byte of timestamp */
    unsigned char battery; /* battery level; 0x05 = max, 0xEE = USB charging */
    unsigned char aXlow; /* low byte of accelerometer X value */
    unsigned char aXhigh; /* high byte of accelerometer X value */
    unsigned char aYlow;
    unsigned char aYhigh;
    unsigned char aZlow;
    unsigned char aZhigh;
    unsigned char aXlow2; /* low byte of accelerometer X value, 2nd frame */
    unsigned char aXhigh2; /* high byte of accelerometer X value, 2nd frame */
    unsigned char aYlow2;
    unsigned char aYhigh2;
    unsigned char aZlow2;
    unsigned char aZhigh2;
    unsigned char gXlow; /* low byte of gyro X value */
    unsigned char gXhigh; /* high byte of gyro X value */
    unsigned char gYlow;
    unsigned char gYhigh;
    unsigned char gZlow;
    unsigned char gZhigh;
    unsigned char gXlow2; /* low byte of gyro X value, 2nd frame */
    unsigned char gXhigh2; /* high byte of gyro X value, 2nd frame */
    unsigned char gYlow2;
    unsigned char gYhigh2;
    unsigned char gZlow2;
    unsigned char gZhigh2;
    unsigned char temphigh; /* temperature (bits 12-5) */
    unsigned char templow_mXhigh; /* temp (bits 4-1); magneto X (bits 12-9) (magneto only in ZCM1) */
} PSMove_Data_Input_Common;
Don't have mine yet so can't be of much help here, yet
 
@mjs513 - Thanks for the information, I had sort of figure out some of these from looking at other sources, but wondering if we more or less leave it alone... That is the callers get this information in that order?
Or do you see mapping some of this to some of the same indexes as with other PS3s?

Also need to figure out what 2nd frame implies.
 
@KurtE
My honest opinion other than the buttons in the sketch I would leave the mapping alone but the other data would still be in the axis array I presume. Thing the use the other info as a IMU type of device and get position data from it but that is the beyond the scope of the USBHost…..

I might do something with later as a stand alone example but I would have to go through the thio thesis to sort it out - I did download it though and put it on my list of things to do.

By the way I just posted some benchmarking sketches that might be able to be used but what to get Paul's reading on it first before doing comparisons and posting the data - might be fun to play with though. :)
 
@mjs513 @defragster (and of course anyone else)

I pushed up my latest changes in the branch: https://github.com/KurtE/USBHost_t36/tree/PS3_Motion_WIP2-Bluetooth
Note: I squashed all of the commits into one, as to remove things like WIP...

If you get a chance you might try out this branch and make sure I did not screw something else up... Will try as well with a few other joysticks.

Note: Been doing most of the testing on T3.6 beta board.

Assuming no one finds anything, will probably merge this into other WIP branch as part of the PR...

Fixed and updated a few features in the JoystickBT example app, like it now also shows which BT device connected and disconnected. I also changed the Joystick.setLEDs method into two
versions: setLEDs(uint32_t color) and setLEDs(uint8_t r, uint8_t g, uint8_t b)... Before only had the second where g=0, and b=0 defined...
Note the first one is a simple inline defined where each color is 8 bits RGB.... And it simply calls the 3 parameter one with the shifted values.

I liked it in the HS2 stuff where for example you could have color table (or color defines), and simply call off with index for all three colors...
But in doing so, it changed to which LED field was used for PS3 (now index 2 instead of 0)...

Edit: Note: I did a quick and dirty test of PS3 and it still did the pairing with BT and appears to show the right data... And LEDs to change
 
@mjs513 Follow on to above, I am not really sure about the data structure for the Move data...

That is if I map that data into textual form, it is something like:
Code:
//  data[1-3] Buttons (mentioned 4 as well but appears to be counter
// axis[0-1] data[5] Trigger, Previous trigger value
// 2-5 Unknown probably place holders for Axis like data for other PS3
// 6 - Time stamp
// 7 - Battery
// 8-19 - Accel: XL, XH, YL, YH, ZL, ZH, XL2, XH2, YL2, YH2, ZL2, ZH2
// 20-31 - Gyro: Xl,Xh,Yl,Yh,Zl,Zh,Xl2,Xh2,Yl2,Yh2,Zl2,Zh2
// 32 - Temp High
// 33 - Temp Low (4 bits)  Maybe Magneto x High on other??
But if I look HS2 stuff you see data like:
Code:
enum SensorEnum {
        /** Accelerometer values */
        aX = 50, aY = 52, aZ = 54,
        /** Gyro z-axis */
        gZ = 56,
        gX, gY, // These are not available on the PS3 controller

        /** Accelerometer x-axis */
        aXmove = 28,
        /** Accelerometer z-axis */
        aZmove = 30,
        /** Accelerometer y-axis */
        aYmove = 32,

        /** Gyro x-axis */
        gXmove = 40,
        /** Gyro z-axis */
        gZmove = 42,
        /** Gyro y-axis */
        gYmove = 44,

        /** Temperature sensor */
        tempMove = 46,

        /** Magnetometer x-axis */
        mXmove = 47,
        /** Magnetometer z-axis */
        mZmove = 49,
        /** Magnetometer y-axis */
        mYmove = 50,
};
Note their offsets are different, but also note their order is different... Also how the 2 bytes per field is different
Code:
int16_t PS3BT::getSensor(SensorEnum a) {
        if(PS3Connected) {
                if(a == aX || a == aY || a == aZ || a == gZ)
                        return ((l2capinbuf[(uint16_t)a] << 8) | l2capinbuf[(uint16_t)a + 1]);
                else
                        return 0;
        } else if(PS3MoveConnected) {
                if(a == mXmove || a == mYmove) // These are all 12-bits long
                        return (((l2capinbuf[(uint16_t)a] & 0x0F) << 8) | (l2capinbuf[(uint16_t)a + 1]));
                else if(a == mZmove || a == tempMove) // The tempearature is also 12 bits long
                        return ((l2capinbuf[(uint16_t)a] << 4) | ((l2capinbuf[(uint16_t)a + 1] & 0xF0) >> 4));
                else // aXmove, aYmove, aZmove, gXmove, gYmove and gZmove
                        return (l2capinbuf[(uint16_t)a] | (l2capinbuf[(uint16_t)a + 1] << 8));
        } else
                return 0;
}
With the offsets, some of this can be explained: That is we have already stripped off some of the L2CAP header so we read the buttons at bytes: 1-3
and They read them at bytes: 10-12...
So again an offset of 9 and plus for axis, I then copy the data down 5 bytes... So I can imagine 14 bytes different...
So would Think that maybe 28-14=14 for axmove...

May still have to experiment... Note: in the sketch update I checked in, I made a copy of your PS4 display sensor stuff, and tried to read the right fields...
Appears to be garbage output so far...

But again the HS2 stuff gives some hints:
Code:
float PS3BT::getAngle(AngleEnum a) {
        float accXval, accYval, accZval;

        if(PS3Connected) {
                // Data for the Kionix KXPC4 used in the DualShock 3
                const float zeroG = 511.5f; // 1.65/3.3*1023 (1.65V)
                accXval = -((float)getSensor(aX) - zeroG);
                accYval = -((float)getSensor(aY) - zeroG);
                accZval = -((float)getSensor(aZ) - zeroG);
        } else if(PS3MoveConnected) {
                // It's a Kionix KXSC4 inside the Motion controller
                const uint16_t zeroG = 0x8000;
                accXval = -(int16_t)(getSensor(aXmove) - zeroG);
                accYval = (int16_t)(getSensor(aYmove) - zeroG);
                accZval = (int16_t)(getSensor(aZmove) - zeroG);
        } else
                return 0;

        // Convert to 360 degrees resolution
        // atan2 outputs the value of -π to π (radians)
        // We are then converting it to 0 to 2π and then to degrees
        if(a == Pitch)
                return (atan2f(accYval, accZval) + PI) * RAD_TO_DEG;
        else
                return (atan2f(accXval, accZval) + PI) * RAD_TO_DEG;
}
 
@KurtE

Been taking a break today so a little slow on responses so I just saw this. Don't thing its going to be as easy as HS2 did it for PS3 and PS4. Got some of the stuff for the other axis for the PS4 from there. Never did it for the PS3 as the data wasn't making sense when I tried it. Anyway for the Move I found this https://github.com/thp/psmoveapi/blob/6f8a0efbb0f3f0b51a53d76186b0e9f08ce733bb/src/psmove.c, look for the psmove_get_accelerometer function. Looks like there may be a couple of models and depending on which one you have it does the calculation a little different
 
@KurtE

Finally got my Move Controller but no power - looks like the battery is absolutely dead..... Kind of gave up on the CANFD so figure I had something else to play with. But guess not. Just ordered a new battery to see if that's the problem.
 
@mjs513 -

Sorry to hear that... I assume you already tried plugging it into your computer to maybe see if the battery will charge some... I know that helped on at lest one of the two other PS3 ones I received off of ebay...

Mine is sort of on hold right now with other distractions.
 
@KurtE
Got a new battery today and plugged it into the pc and it worked. Next I wired into the USBhost port and it cycled through the colors - only problem I am having is can't figure out how to get the thing paired - hope I got the right one :)

Mike
 
@mjs513 - Try first plugging in BT dongle, unplug, and then plug this one in... It should cycle through the colors and hopefully it should automatically try to pair...

I believe there are messages stuff that print to that effect...
 
@KurtE
Yep - finally got it to pair and output but the interesting thing is it doesn't print to the sermon but if I open tycommander I see the data and I see the problem - going to play around with that now that I finally got FD working :)

Mike
 
@KurtE

Going to push up a change to the joystickBT example for the PS3 motion controller. Broke the code on the accel, gyro and added the magnetometer for Model ZCM1 controller. Took a bit but got it. The second frame in the structure is supposedly the latest data from controller while the first frame is the previous frame. So now am getting:
Code:
Changed: 575d0000 Buttons: 0: Trig: 0
Battery Status: 4
Accel-g's: 0.014160, 0.072021, 0.967041
Gyro-deg/sec: -26.353821, -21.765682, -8.057219
Mag: 114, -157, 25
Pitch/Roll: 222.331192, 198.599533
There is a way to get calibration data from the controller but not sure its worth it at this point - maybe when you get done with your other distractions :)

Mike
 
Back
Top