Calibration data CECH‐ZCM2
Note: This information applies only to the new CECH-ZCM2 models, not the older CECH-ZCM1 models.
The Move submits its calibration data in HID report 0x10. Unlike other reports from the controller, this one has to be read two times to get everything. The results will typically look like this:
10 00 22 10 fd ff 3c 00 1b f0 07 00 d3 ff 2a 00 07 10 e2 ff 15 00 04 f0 11 00 f9 ff 0a 00 fe 0f 46 00 dc ff d6 ef fb ff 07 00 ff ff 9c 00 00 00 00 10 81 1a 05 00 17 00 9b ff ac 1a 0d 00 5a ff 06 00 9a 1a 59 e5 08 00 e5 ff 58 00 63 e5 ef ff 81 00 06 00 62 e5 1c 02 1c 02 04 00 00 00 00 00 00 00
This data is stored in the Move's Flash memory as binary blob and is unique to every controller.
The following section explains the report's format in detail, e.g. how to interpret the data. There is, however, a lot of guessing involved. If you figured out one of the missing parts, please let us know or add it to this page yourself! Raw calibration data read from different controllers can be found at bottom of this page.
Fields that cover more than one byte are stored as little-endian, i.e. the least significant byte comes first. The same notation is used in the table below! Description of the axes assumes that the Move is held with the buttons pointing up and the glowing ball pointing away from you:
- X-axis pointing to the right
- Y-axis pointing up
- Z-axis pointing away from you.
Since calibration data is split across two parts it has to be reassembled first. In each of the reports, the second byte's lower nibble identifies which of the two blocks we are dealing with. Note that the first report retrieved might as well be the last one in order. The following table assumes that the two reports are chained together in correct order, skipping the first two bytes (report ID and block index) of the second block!
| Byte offset | Length (in bytes) | Description |
|---|---|---|
| 0x00 | 1 | HID Report ID (always 0x10) |
| 0x01 | 1 | Index to keep blocks in order |
| 0x02 | 6 | Accelerometer, orientation #1 (max. X) |
| 0x08 | 6 | Accelerometer, orientation #2 (min. X) |
| 0x0E | 6 | Accelerometer, orientation #3 (max. Z) |
| 0x14 | 6 | Accelerometer, orientation #4 (min. Z) |
| 0x1A | 6 | Accelerometer, orientation #5 (max. Y) |
| 0x20 | 6 | Accelerometer, orientation #6 (min. Y) |
| 0x26 | 6 | Gyro bias (?) |
| 0x2C | 2 | |
| 0x2E | 2 | |
| 0x30 | 6 | Gyroscopes, rotation +X (90 rpm) |
| 0x36 | 6 | Gyroscopes, rotation +Z (90 rpm) |
| 0x3C | 6 | Gyroscopes, rotation +Y (90 rpm) |
| 0x42 | 6 | Gyroscopes, rotation -X (90 rpm) |
| 0x48 | 6 | Gyroscopes, rotation -Z (90 rpm) |
| 0x4E | 6 | Gyroscopes, rotation -Y (90 rpm) |
| 0x54 | 2 | |
| 0x56 | 2 | |
| 0x58 | 2 | |
| 0x5A | 2 | |
| 0x5C | 2 | |
| 0x5E | 2 |
The lower nibble of this byte indicates where to put this report in the reassembled block. It can either be 0x00 or 0x81. Not sure what the additional high bit for the seconds blocks means. It probably only indicates that this is the last block.
Accelerometer values for 6 different orientations (6-point tumble test, read more: http://www.gcdataconcepts.com/calibration.html). Order of the axes is X-Z-Y for each orientation. The values are signed 16-bit integers and stored as two's complement (0 being the ideal zero G level).
From these values alone the bias vector and the gain matrix can be calculated with a multidimensional optimization algorithm, e.g. the downhill simplex algorithm.
Do not confuse them with the maximum output these sensors can report (e.g. by violently shaking the controller)!
The description in the above table contains information which axis is reporting minimum or maximum. To further illustrate, these are the decoded min/max accelerometer values found in the sample calibration data at the top of this page.
| Byte offset | X-member | Z-member | Y-member |
|---|---|---|---|
| 0x02 | 4130 | −3 | 60 |
| 0x08 | −4096 | 7 | −45 |
| 0x0E | 42 | 4103 | −30 |
| 0x14 | 21 | −4092 | 17 |
| 0x1A | −7 | 10 | 4094 |
| 0x20 | 70 | −36 | −4138 |
Gyroscope readings for rotation at 90 rpm about the 3 main axes, both directions each. The axis order is X-Z-Y. The values are signed 16-bit integers and stored as two's complement (0 being the 0 rad/s level). It's not clear if we should do the same thing as the accelerometer values and compute the gyro gain as 1 / ((max - min)/2).
There also appears to be a small-valued vector stored at 0x26 that might be some gyro bias or drift values, but it's unclear what the units are (Same RPM units as the gyro readings? Radians/sec? Degrees/sec?). Some gyro drift measurements are needed.
This section contains calibration data read from different Move Motion controllers. Feel free to add more.
To get the data easily, you can use a python script at the following address: https://github.com/nitsch/moveonpc/wiki/Calibration-data-CECH%E2%80%90ZCM2
The script will provide you with 2 blocks of the data. Detete the first 2 bytes of the second block (they should be "10 81"). Those are just indexes for organization. Then shift the remaining bytes and join the two blocks into one.
10 00 22 10 fd ff 3c 00 1b f0 07 00 d3 ff 2a 00 07 10 e2 ff 15 00 04 f0 11 00 f9 ff 0a 00 fe 0f 46 00 dc ff d6 ef fb ff 07 00 ff ff 9c 00 00 00 00 1a 05 00 17 00 9b ff ac 1a 0d 00 5a ff 06 00 9a 1a 59 e5 08 00 e5 ff 58 00 63 e5 ef ff 81 00 06 00 62 e5 1c 02 1c 02 04 00 00 00 00 00 00 00
10 00 29 10 ed ff 55 00 25 f0 0d 00 fa ff 41 00 fd 0f 19 00 10 00 f9 ef 35 00 fd ff 05 00 38 10 52 00 e4 ff 0a f0 fd ff 0d 00 0b 00 a8 00 00 00 00 1a ee ff 3a 00 ce ff a4 1a 34 00 8e ff 1c 00 ae 1a 56 e5 2e 00 de ff 2a 00 78 e5 e4 ff 81 00 00 00 68 e5 1c 02 1c 02 04 00 00 00 00 00 00 00
10 00 10 10 e7 ff 63 00 03 f0 e4 ff 18 00 01 00 e5 0f 3b 00 10 00 e9 ef 44 00 02 00 d9 ff 48 10 0f 00 f2 ff 32 f0 fb ff f3 ff 08 00 9f 00 00 00 00 1a 14 00 45 00 cd ff 8c 1a 15 00 cd ff c3 fe a0 1a 55 e5 d1 ff cc ff 28 00 58 e5 fb ff 29 00 23 01 6e e5 1c 02 1c 02 08 00 00 00 00 00 00 00