Interesting discovery

[sunryze-git]

I'm not sure if youre actively working on this but ive been doing my own research to get a fully featured implementation for the switch 2 controllers in linux.

With my current configuration i get different packets than your parser expects. My BTLE packets on the Pro Controller are 112 bytes. The offsets differ and the IMU data is basically unrecognizable as it contains an extra 16 bytes (bringing it up to 40 bytes worth of IMU-related data, up from 24 on USB)

Pro Controller BTLE packet: 88 20 00 00 00 09 48 89 28 18 7E 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 28 92 00 03 0F 83 C4 D5 8F CD 33 F1 F8 06 09 40 47 7A 01 DE 37 E8 BB 14 41 D9 5F 40 3E A2 CE 9C 25 1D A2 60 E3 0F 78 B0 0B 00 00 00 00 00 00

I also see the same thing on my Joy Cons:

E8 18 00 00 07 4F 88 7E 38 00 00 00 00 FF 00 28 EF 74 02 0F 63 DB FC 79 59 48 58 55 B6 D3 DB 04 08 8F 1A 41 33 FC 36 40 12 17 F9 C3 E6 03 A0 F2 5D 87 E1 08 47 EB A5 1D 00 00 00 00 00 00 00

Same sized IMU data and seem to be structured identically. Both also start with 28 being some magic number.

I'm not exactly sure where to proceed here with this and im wondering if you have any input. I also get these on different interfaces than you recorded, 0x002E for the Pro Controller and 0x000E for the Joy Con (right).

[german77]

There are a couple of motion formats. However we only figured out the structure of format A. The others use some sort of dynamic quaternion compression that changes depending on the motion, someone was able to get the format working but didn't share the details.

I only have captures from switch-joycon2 but you can use handle A on all controllers so is recommended to use that if you are implementing any kind of driver. For more info see https://github.com/ndeadly/switch2_controller_research/blob/master/hid_reports.md#input-report-0x0a

Motion format handle 0x000A
| Offset | Size | Value              | Comment               |
| 0x2A   | 0x4  | Motion Timestamp   | 50k = 1s              |
| 0x2E   | 0x2  | Temperature        | 25°C + x/127          |
| 0x30   | 0x2  | Accel X            | 4096 =  1G            |
| 0x32   | 0x2  | Accel Y            | 4096 =  1G            |
| 0x34   | 0x2  | Accel Z            | 4096 =  1G            |
| 0x36   | 0x2  | Gyro X             | 48000 = 360°          |
| 0x38   | 0x2  | Gyro Y             | 48000 = 360°          |
| 0x3A   | 0x2  | Gyro Z             | 48000 = 360°          |

[ndeadly]

Both also start with 28 being some magic number

0x28 is not a magic number, but the length of the motion data following. We don't fully understand the motion format, but it seems to be able to encode a variable number of samples. This is likely due to LE connections being limited to transmitting only as fast as the minimum connection interval will allow. When the controller wants to send a command response it needs to skip an input report for that period. By encoding an additional sample in the next input report it's able to make up for the missing sample. AFAIK USB connections don't suffer from anything similar so you should see a constant size for motion data.

But as @german77 said, just use handle 0x000A (report 0x05) for all devices instead (wrong report was linked above)

someone was able to get the format working but didn't share the details

He said he had it kind of working but it still wasn't quite figured out, FWIW