Circle Pad Pro: Difference between revisions
0x10 is my typo and thanks. But I don't see the point of blindly merging unknown fields |
|||
Line 10: | Line 10: | ||
Communications with this device is done via the [[IR_Services|ir:USER]] service, which uses obfuscation implemented in software. The [[IRU:SetBitRate|bitrate-value]] passed to IRUSER is 0x04, hence the actual bps is 96000. | Communications with this device is done via the [[IR_Services|ir:USER]] service, which uses obfuscation implemented in software. The [[IRU:SetBitRate|bitrate-value]] passed to IRUSER is 0x04, hence the actual bps is 96000. | ||
The application sends requests via [[IRUSER:SendIrnop]] and receives response from Circle Pad Pro via [[IRUSER:ReceiveIrnop]] (or read data from the [[IRUSER_Shared_Memory|shared memory]]). The request and response data structures below are payloads in packets. | The application sends requests via [[IRUSER:SendIrnop]] and receives response from Circle Pad Pro via [[IRUSER:ReceiveIrnop]] (or read data from the [[IRUSER_Shared_Memory|shared memory]]). The request and response data structures below are payloads in packets. Each request begins with a one-byte ID that determines the request type. | ||
=== Read Input === | === Request 1: Read Input === | ||
Request (3 bytes): | Request (3 bytes): | ||
Line 67: | Line 67: | ||
|} | |} | ||
=== Read Calibration Data? === | === Request 2: Read Calibration Data? === | ||
Request (6 bytes): | Request (6 bytes): | ||
Line 115: | Line 115: | ||
| data size | | data size | ||
| calibration data? | | calibration data? | ||
|} | |||
=== Request 3 === | |||
Request (22 bytes?): | |||
{| class="wikitable" border="1" | |||
|- | |||
! offset | |||
! Size | |||
! Description | |||
|- | |||
| 0x0 | |||
| 0x1 | |||
| Request ID (fixed value 3) | |||
|- | |||
| 0x1 | |||
| 0x1 | |||
| Expected response time in ms? | |||
|- | |||
| 0x2 | |||
| ... | |||
| ? | |||
|} | |||
Response (2 bytes?): | |||
{| class="wikitable" border="1" | |||
|- | |||
! offset | |||
! Size | |||
! Description | |||
|- | |||
| 0x0 | |||
| 0x1 | |||
| Response ID? Fixed value 0x12 | |||
|- | |||
| 0x1 | |||
| 0x1 | |||
| 0? | |||
|} | |||
=== Request 4: Reset Calibration Data? === | |||
Request (3 bytes?): | |||
{| class="wikitable" border="1" | |||
|- | |||
! offset | |||
! Size | |||
! Description | |||
|- | |||
| 0x0 | |||
| 0x1 | |||
| Request ID (fixed value 4) | |||
|- | |||
| 0x1 | |||
| 0x1 | |||
| Expected response time in ms? | |||
|- | |||
| 0x2 | |||
| 0x1 | |||
| ? | |||
|} | |||
Response (2 bytes?): | |||
{| class="wikitable" border="1" | |||
|- | |||
! offset | |||
! Size | |||
! Description | |||
|- | |||
| 0x0 | |||
| 0x1 | |||
| Response ID? Fixed value 0x13 | |||
|- | |||
| 0x1 | |||
| 0x1 | |||
| 0? | |||
|} | |||
=== Request 5 === | |||
Request (2 bytes): | |||
{| class="wikitable" border="1" | |||
|- | |||
! offset | |||
! Size | |||
! Description | |||
|- | |||
| 0x0 | |||
| 0x1 | |||
| Request ID (fixed value 5) | |||
|- | |||
| 0x1 | |||
| 0x1 | |||
| Expected response time in ms? | |||
|} | |||
Response (2 bytes?): | |||
{| class="wikitable" border="1" | |||
|- | |||
! offset | |||
! Size | |||
! Description | |||
|- | |||
| 0x0 | |||
| 0x1 | |||
| Response ID? Fixed value 0x14 | |||
|- | |||
| 0x1 | |||
| 0x1 | |||
| ? | |||
|} | |} |
Revision as of 11:42, 1 March 2017
Also known as CTR-009, it sends the commands to the console through the IR interface on the back of the console.
Usage Instructions
IR Protocol
Communications with this device is done via the ir:USER service, which uses obfuscation implemented in software. The bitrate-value passed to IRUSER is 0x04, hence the actual bps is 96000.
The application sends requests via IRUSER:SendIrnop and receives response from Circle Pad Pro via IRUSER:ReceiveIrnop (or read data from the shared memory). The request and response data structures below are payloads in packets. Each request begins with a one-byte ID that determines the request type.
Request 1: Read Input
Request (3 bytes):
offset | Size | Description |
---|---|---|
0x0 | 0x1 | Request ID (fixed value 1) |
0x1 | 0x1 | Response period in ms |
0x2 | 0x1 | Unknown |
Response (6 bytes): This Response will be sent repeatedly by the specified period.
offset | Size | Description |
---|---|---|
0x0 | 0x1 | Response ID? Fixed value 0x10 |
0x1 | 0x3 | Right circle pad position.
This three bytes are two little-endian 12-bit fields. The first one is for x-axis and the second one is for y-axis. |
0x4 | 0x1 | bit[0:4] battery level?
bit[5] ZL button bit[6] ZR button bit[7] R button Note that for the three button fields, the bit is set when the button is NOT pressed. |
0x5 | 0x1 | Unknown |
Request 2: Read Calibration Data?
Request (6 bytes):
offset | Size | Description |
---|---|---|
0x0 | 0x1 | Request ID (fixed value 2) |
0x1 | 0x1 | Expected response time in ms? |
0x2 | 0x2 | Data offset? (aligned to 0x10?) |
0x4 | 0x2 | Data size (aligned to 0x10?) |
Response (5 bytes + requested size)
offset | Size | Description |
---|---|---|
0x0 | 0x1 | Response ID? Fixed value 0x11 |
0x1 | 0x2 | Unknown. Same as request+0x2 |
0x2 | 0x2 | Data size |
0x4 | data size | calibration data? |
Request 3
Request (22 bytes?):
offset | Size | Description |
---|---|---|
0x0 | 0x1 | Request ID (fixed value 3) |
0x1 | 0x1 | Expected response time in ms? |
0x2 | ... | ? |
Response (2 bytes?):
offset | Size | Description |
---|---|---|
0x0 | 0x1 | Response ID? Fixed value 0x12 |
0x1 | 0x1 | 0? |
Request 4: Reset Calibration Data?
Request (3 bytes?):
offset | Size | Description |
---|---|---|
0x0 | 0x1 | Request ID (fixed value 4) |
0x1 | 0x1 | Expected response time in ms? |
0x2 | 0x1 | ? |
Response (2 bytes?):
offset | Size | Description |
---|---|---|
0x0 | 0x1 | Response ID? Fixed value 0x13 |
0x1 | 0x1 | 0? |
Request 5
Request (2 bytes):
offset | Size | Description |
---|---|---|
0x0 | 0x1 | Request ID (fixed value 5) |
0x1 | 0x1 | Expected response time in ms? |
Response (2 bytes?):
offset | Size | Description |
---|---|---|
0x0 | 0x1 | Response ID? Fixed value 0x14 |
0x1 | 0x1 | ? |