Repurposing the PS3 Move
Extracted Page: http://www.eissq.com/ps3_move/Repurposing the PS3 Move
Schematic in pdf format
Schematic in Eagle format
Buttons schematic in pdf format
Buttons schematic in Eagle format
The goal of my project is develop quadcopter firmware for a university research project. The advantage of the Move is its incredibly low price and its suite of inertial and absolute sensors, all linked together by a reasonably powerful STM32 ARM-Cortex M3 chip. Any new firmware can easily be developed with available tools. Eclipse, Embedded workbench, etc...
This page will be updated with our work, which most likely will be based on the excellentOpenPilot system.One important facet of the firmware is how to turn on all the various regulators. I’m not sure yet, but it seems that it might be enough to simply enable PD11 (pin 58) on the STM32. This pin is connected to the enable pin on the TI TPS63030 voltage regulator.Update: Success! Everything went according to theory and plan. I now can run arbitrary code on the Move, and have successfully programmed a small routine that reads all the accelerometer, gyroscope, and magnetometer axes. I will someday try to make a short tutorial showing this, but in the meantime feel free to write me and I’ll send you the project files.Original firmware
For whatever reason, Sony chose not to lock its firmware. I actually downloaded it by accident when hooking up my STM32Discovery’s ST-Link debugger. In the resources section, I have included the firmware as read from my Move, as the ability to see how the Move communicates with the BC4 might be invaluable. I’m hoping that someone with more knowledge than I could help me figure out what’s going on. I have already erased and reflashed this firmware, so it is known good.Resources:
Sony PS3 Move firmware
There’s an 8MHz crystal that feeds the STM32’s PLL.
Table of notable pins
STM32F103 data sheet
STM32 Programming reference manual
Check out thefirmware post for more information.
For the moment, I'm unsure what the PE... pin is doing. Is suspect it might have something to do with a serial port DRTS, or something like that. I'm not familiar enough with the serial protocol to really say. I hope to learn more about the BC4RE with additional poking and prodding, although considering its complexity that will have to wait some time. Hopefully, some enterprising soul will pick up my work and completely specify this module.
Finally, the small chip just to the side of the BC4RE is the 24C23, a 4KByte EEPROM chip from Seiko Instruments. Since it’s inside the BT module’s metal shielding, it would make sense that this chip serve the BT chip, and no the STM32. As the STM32 has no onboard EEPROM, it might be nice if a few bytes of this could be repurposed.Outgoing data
The outgoing data format is quite simple. Here is an example message:0x34 0x00 0xA1 0x01 0x00 0x00 0x00 0x05 0x00 0x00 0x7F 0x7F 0x7F 0x7F 0xC6 0x04 0x17 0x90 0x71 0x80 0x71 0x7B 0x18 0x90 0x76 0x80 0x63 0x7B 0x03 0x80 0xFD 0x7F 0x0D 0x80 0x01 0x80 0xFF 0x7F 0xEE 0x7F 0x79 0x22 0x85 0x09 0x71 0x67 0x71 0x00 0x00 0x00 0x00 0x00
The instructions to the bluetooth module are the first two bytes. I don’t know what these do, but I suspect that the first byte indicates how many bytes are in the message (52 in our case), and the0x00 indicates that the message follows immediately afterwards.
Packet body, transmitted via bluetooth. The first byte is always0xA1, and is not part of the Move’s input report:
0xA1 0x01 0x00 0x00 0x00 0x05 0x00 0x00 0x7F 0x7F 0x7F 0x7F 0xC6 0x04 0x17 0x90 0x71 0x80 0x71 0x7B 0x18 0x90 0x76 0x80 0x63 0x7B 0x03 0x80 0xFD 0x7F 0x0D 0x80 0x01 0x80 0xFF 0x7F 0xEE 0x7F 0x79 0x22 0x85 0x09 0x71 0x67 0x71 0x00 0x00 0x00 0x00 0x00
The moveonpc project has a wiki page describing theformat of the input report message. Again, note that the 0xA1 is not part of the input report, and so can be ignored when decoding the sensor data.Incoming data
From hcidump, I can see that the outgoing bluetooth packet:
0x02 0x28 0x20 0x0C 0x00 0x08 0x00 0x48 0x00 0x52 0x02 0x00 0xFA 0xAA 0xAF 0x00 0x5A
outputs the following from the bluetooth module:
where the field occupied by0xFA is the red LED, by 0xAA the green LED, 0xAF the blue LED, and finally 0x5A the vibrating motor.
I suppose that the0x07 added by the bluetooth module is the data packet length.Resources:
Table of notable pins
Outgoing communications at startup
Incoming communications at startup
Outgoing communications at wakeup
Incoming communications at wakeup
Outgoing communications during run
Incoming communications during run
Between two different Moves, the gyroscopes seem not to have consistent markings. iFixIt’s is marked 067S8. On my Move, it's marked 090B8. This could be regional differences-- I bought mine in Luxembourg, whereas iFixit most likely bought theirs in America-- or it could be that the parts are actually different, or sthat this is a serial number. In any case, what is clear is that without some inside knowledge we'll probably never get a document sheet, or really even know the gyroscope's noise specifications.
There are extra capacitor pads C85, C103 and C104, C106-- x- and y-axis, respectively-- which I think could be used for changing the filtering frequency of the analog outputs.
Update: It would seem that the brass casing is likely for electromagnetic shielding, as EETimes Asia identifies it as the LPR425AL, which is likely from STM: “None of the sensors can be found in their exact form on either vendor's websites but part markings are consistent with the full part numbers shown, and suggestive of custom parts for Sony.” However, as I do not wish to take the brass shell off my Move and perhaps render it inoperative, it is possible that there is another chip underneath.
No table is provided as due to the brass shield it is very difficult, if not impossible, to see the pins. However, the microcontroller post details which STM32 pins read the analog sensor outputs.
EETimes Asia identifies this as an STM LY5250 accelerometer, for which there is no available chip doc.
Table of notable pins
1.6V is the zero output. The accelerometers have a scale of about .250V/g. Assuming that the chip is able to go full scale, from 0V to 3V, this gives an absolute output of +-6g. That's perhaps a little high for my purposes, but it should be able to give pretty decent resolution with the STM32's 12-bit ADC.
There is a 30mV voltage spike every 125us (in other words, at 8MHz). This frequency doesn’t seem to be present at any of the pin inputs, which implies that there is some kind of digital noise either due to the accelerometer’s analog outputs or the microcontroller’s ADC inputs.Resources:
Table of notable pins
While this kind of sensor package already exists in many mobile phones, the Playstation Move is special because of its price point. An iPhone 4 is $599. A Playstation Move can be bought for $49.99. While a Wiimote with Motion Plus can be bought for a similar price, it does not have a magnetometer. The magnetometer is of special interest because it provides an absolute measurement of orientation. While the measurement might not be the best, and indeed has calibration problems, this can be overcome with slow-rate sensors such as an additional GPS.
The host STM32, like many modern microcontrollers, has CANbus support, which is a very interesting feature for quadcopters, my particular interest. CAN is a very robust protocol that is used in most, if not all, modern cars for signaling. It combines a robust physical layer with an error-checking software protocol that is very suited to noisy environments. The quadcopter's four BLDC motors, which oftentimes are cheap motors with cheap motor controllers, generate large amounts of EM noise, which makes the CAN network essential for communicating with the motor controllers.
My motivation for this is to be able to reverse engineer and reprogram the STM32 host microcontroller in order to program my own IMU. This means understanding the sensors, the sensor communications protocols, the bluetooth module, the power circuit, etc...
In iFixit.com, the ones who were the first to do a teardown and thus inspire me to do the hacking, they surmise that the black chip is the 3-axis gyroscope. In fact, this chip is not a 3-axis gyroscope at all, but rather is the Z single-axis gyroscope. The brass-covered chip houses the gyroscopes for the X and Y axes. What is interesting is that in iFixit's photos, the chip is marked 067S8. On my Move, it's marked 090B8. This could be regional differences-- I bought mine in Luxembourg, whereas iFixit most likely bought theirs in America-- or it could be that the parts are actually different, or that this is a serial number. In any case, what is clear is that without some inside knowledge we'll probably never get a document sheet, or really even know the gyroscope's noise specifications.
This is also somewhat true for the other sensors on the board, but at least it is clear who manufactures them, so there is some hope of being able to characterize the chip.
The hacking and reverse engineering was done by soldering small wires throughout the board. This was not a particularly difficult task, but it was tedious. The resulting traces could be examined with the use of a logic probe and oscilloscope. I do not pretend that all information is perfectly correct, it is entirely possible that I have made a mistake. If so, please let me know and I will correct it ASAP.
Most of this work was done at theSyn2cat hackerspace in Luxembourg. Thanks so much guys for supporting me through all this.
This work was also heavily inspired and facilitated by themoveonpc project, the motioninjoy board, and most importantly linmctool derivatives.