I saw that you managed to get the data from the SPI for accelerometer/gyroscope.

Upon connection the microcontroller initializes a software reset of the MEMS chip, then set up the accelerometer and gyroscope as follows:
...
Since the Joycon polls MEMS data every 1.35ms but only send out controller update every 15ms, there might be some internal averaging to smooth out the data, needs to go through the numbers to find out.

Is this something you've only been able to capture directly from the SPI?

I think it's been established that the joycons don't send accelerometer and gyroscope information without some sort of command being sent to the joycon. Is this accurate?

If so, is there any speculation as to what the command is currently or how to discover it?

disclaimer: I've seen this question asked a lot in other issues but I'm a bit of an outsider to all of the low-level reverse engineering skills this project requires. Please forgive any misunderstandings.

Do you have any information of the pinout (and interface) of the 5-wire flexible PCB that connects the control stick with the controller PCB?

I would guess something like:

• GND
• VCC
• X (analog)
• Y (analog)
• Switch (short to GND)

I'm interested in how the joycon does NFC. I've written my own code[1] to do the basics (set player LED, vibrate, change input remote mode), but I've been struggling to get NFC data. When setting the input report mode to 0x31, it still get all 0’s for the data after the standard HID data. There is a note on the docs about this, "31 input report has all zeroes for IR/NFC data if a 11 ouput report with subcmd 03 00 or 03 01 or 03 02 was not sent before.”, but I’ve tried variations of a 0x11 command with a 0x03 subcommand and still seen any progress (both trying it before changing the input mode, and after). It is also unclear from the notes of the 0x11 command has the same format as the 0x01 command, so its possible I’m putting the subcommand byte in the wrong location.

Do I have the format of the 0x11 command wrong, or does anyone happen to know a minimal sequence of commands to get NFC data to start flowing? I've worked with NFC before[2], so I'm confident that I can work with the data once it starts flowing.

[1] https://github.com/bettse/expecimal (https://gitlab.com/bettse/expecimal)
[2] https://github.com/bettse/FS13_nfc_tag_reader/blob/master/device.nut#L226-L253

Newer joycons use the winbond w25q40ew; can find the datasheet here

Hi,

Loving the work you've done - thanks ever so much. Couldn't find you on social media, so am just gonna drop a message here.

Have you been able to sniff the USB or Bluetooth HID protocol it's using? Been trying to bodge a driver together, and don't really have the tools to analyse the protocol. Whilst the buttons and joysticks work fine, I believe the console sends a feature report to the joy-cons to activate gyroscope input. So far I've not had much luck getting the gyroscope and accelerometers to send anything over the standard protocol.

Could be me, or it could be Nintendo's very kind way of introducing security through obscurity.
Some help on the matter would be great if you are free.

Thanks

Hey! Thank you so much for the packet data! I'm working on getting it into a library so there's joycon access for non-Switch stuff like VR games and the like. I wasn't able to get my hands on any extra joycons, so you breaking one out and doing this has been a lifesaver!

I was wondering if you've made any headway in figuring out how HD rumble data is sent over, especially when the update request just looks like a fixed value and doesn't seem to transmit any information to the joycon. Changing any bytes in the update request just seems to not get a response from the JC I tested.

Once again, thanks a ton!

Hi! I hope you still read this questions section :) I would like to ask, do you explore Pro Controller or Joycons only? Do you have some discord channel maybe where we can talk?

I've been wrangling around with the Joy-Con and think I've figured out how the rumble data is sent over, starting from byte 13 in the packet sent from the Switch. (It doesn't look like standard HID...)

Byte 13 is a constant, 0x10. It's probably an identifier, as it's always 0xf for all pings not containing rumble data. Byte 14 looks like some sort of timekeeper in the event of the packets colliding; it starts at 0xa, increments with every ping sent until 0xf, then loops back around to 0x0, 0x1, etc. Changing either of these bits doesn't trigger any rumble at all. There are then 8 bits, 6 of which seem to correspond to the 6 faces of the Joy-Con; but my drivers started crapping out before I could dope out the last 2. The first of the 8 (Byte 15) seems to be some sort of global intensity modifier; as changing it seemed to jolt the whole thing more or less, so that leaves 6 faces, one global modifier, and ?????.

I've managed to trigger some rumble events, but my laptop drivers are suddenly refusing to play nice with the Joy-Cons. I'm not sure if it's hardware failure or something to do with manipulating this data, but I'd love to have some fresh eyes verify it. I verified it against @dekuNukem's BotW data and it seems to check out with respects to which bits change when during the bomb rumble. (I would love to try it with this, because it would let us isolate which bits correspond to which edge of the Joy-Con.)

Once someone else verifies, we can add it to the README?

Oh, and as a clarification because my Bluetooth has been hell, they're sending the same data over BT as they are over serial, right? The only thing that's different is the clock speed?

hey all,

Don't know if this is related to #73, but i just opened up a left joycon from an open box deal at best buy. for the first time, it was different than the one diagrammed here!

Did some digging and found this: https://www.ign.com/articles/2018/04/30/nintendo-working-on-new-redesign-of-joy-con-for-switch. Apparently, the left joycon has long had connectivity issues, so nintendo is redesigning it.

So you may want to try to buy older ones to use as much information from this repo as possible.

So I'm working on a library for handling Joy-Con I/O and I'm trying to change the input mode to 0x30 for both so that I have a continuous stream of input reports. Since the default is 0x3F, or for me it's 0x3F, it only sends input reports when there's input from buttons or analog sticks. I'm able to send an output report for the 0x03 subcommand and change the input report mode to 0x30 on one joy-con, but when I have two joy-con's connected (one left, and one right) I am only able to have one of them be in input report mode 0x30. I have a Joy-Con constructor that sends that subcommand output report every time a Joycon object is constructed:

    public Joycon(HidDevice device) {
        this.device = device;
        this.setPlayerLED();
        this.setInputReportMode(); //Output report sent here
        device.setInputReportListener(new JoyconHIDInputHandler(this));
        device.setDeviceRemovalListener(HidDevice::close);
    }

And the Joycon#setInputReportMode:

    private void setInputReportMode(){
        byte[] buf = new byte[50];
        buf[0] = 0x01;
        buf[10] = 0x03;
        buf[11] = 0x30;
        this.device.setOutputReport(buf[0], buf, buf.length);
    }

I am also setting the HID input report listener for every joycon device that is constructed into a Joycon object as a class implementation of an InputReportListener (purejavahidapi) here:
https://github.com/AlexCouch/JoyCouch/blob/master/src/main/java/couch/joycouch/joycon/JoyconHIDInputHandler.java

However, when I set 0x30, and set a breakpoint inside my onInputReport method, it shows that I'm continuously receiving full standard input reports that I can then take data from. But when I try to have two joycons connected, only one of them has the input mode 0x30, regardless. I first tested with the right joycon, and the right joycon works. I have a right joycon input handler test here:

https://github.com/AlexCouch/JoyCouch/blob/master/src/main/java/couch/joycouch/JoyconTest.java#L19-L31

Where JoyconInputReportHandler is an interface I created, which is invoked in the HID input report listener attached to the joycons. However, upon connecting a left joycon with the right, only the right sends full standard input reports. I also have a left input report handler in the same class as the right (linked above). When I disconnect the right and only have the left, the left has the input mode 0x30.

I'm just curious of whether this is an issue on my end or if this is just how the joycons work? And if there's a way to enable both joycons to be in the same input mode, or if I have to do some kind of output report first and turn something on or off? But I haven't seen anything regarding this. I'm gonna keep digging. If you have any questions my repo is linked but feel free to request more information if anything is missing. If I find a solution I'll be sure to update!

Dears,

I just received two format input reports (0x3f, 0x21):

• 0x3f: Receive when press or release any button on Joy-Con

  <Buffer 3f 01 00 08 00 80 00 80 00 80 00 80>
  

• 0x21: Receive when write a output record 0x01

  <Buffer 21 03 8e 00 00 00 00 00 00 cd b8 75 04 80 00 03 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>
  

Question

I want to get the gyro data, and find the doc here.

But 6-Axis data only be provided by 0x30 to 0x33, I don't know how to send a request to make Joy-Con provide the 6-Axis data (Let Joy-Con provides INPUT report 0x30).

My environment

Product: Jon-Con (L) / (R)
OS: Deepin 15 (Debian's stable branch)
Framework: Node.js v10.15.1
Lib: node-hid v0.7.7

Iam currently working on a small project DIY controller and I would like to add the switches iconic small factor joystick so I ordered some from china, sadly it would take a lot of time(month) till they come and iam already working on the model, so can some great soul take me those measurements?

(preferably into the image)

I have a project in mind that would require me to replace the switches for the dpad and face buttons. Soldering to the test points shouldn't be any major issue, but from the readme I gather that the way button presses are dealt with is a bit unconventional:

Nintendo didn't use the traditional "one side pulled-up other side to ground" way of reading buttons, instead they used a keypad configuration where buttons are arranged in rows and columns.

Is this something I will have to take into account or is still a matter of bridging test points to ground?

In their Nintendo Labo Demo they show IR tracking, but I didn't see IR data in your dump.
Please figure out IR Data too. Thanks.

Had anyone been able to identify the 10 pin connector. I assume it most likely arbitary, but if something close enough exists it'd be quite useful

@shuffle2
So I found time to play with the OTA FW commands on the Joy-Con.

It seems that RAM is partitioned to 2 regions: 0x0D0000-0x0DFFFF and 0x200000-0x247FFF which match the 353KB RAM of Bcm20734.

I did 2 consecutive ram dumps with controller reboot in-between. I also added some extra that may help you.

You can find them here.

Also, I have difficulties loading the rom vanilla style or with your script in IDA.
Addresses and other stuff do not match in the disassembly..

As I understand, 1st uint32LE (0x200400) is stack pointer and 2nd (0x201 THUMB) is reset vector.
So I used many combinations in rom address offset and loading addres with 0x200 (because thumb), 0x0 and 0x4 (offset to remove the 1st uint32) but nothing solid.

I also tried your script and then loaded additional binary (rom) with various loading offset and file offset but I could not find anything familiar in the .c file produced.

Can you help me on what to input on the various fields in IDA ("Disassembly memory organization", "Load additional binary file")?

I will also try to load the ram dumps to fill the RAM voids. BTW, If I do this, it will override the patched addresses?

Would it be possible to hot rod a joy con to improve stick, range, disconnects and ergonomics? I imagine replacing the joy con stick with the pro controller Alps stick might be just drop in. Perhaps some antenna tweaking could improve reception and a custom designed grip would improve ergonomics for larger hands. Would still be nice to be able to attach to the switch, but not strictly necessary. Then charging could be Qi or USB C.

Just took a stab at the checksum. Based on the data provided it appears to be a CRC8 with polynomial x8 + x7 + x3 + x2 + 1 (110001101) computed over bytes 5 through 11.
switch_checksum.py.zip

Are there any plans to find out how to read the output from the ring-con when it's attached? I'm guessing it's an axis, but I don't even know where to start looking. Does anyone know?

I am new at this whole tinkering thing right now. I want to know if its possible to take the joystick & its connector (from the board) and port it to an entirely different board, (I get the plastic connector won't be easy to remove... heck probably impossible). What I hope to be able to do is make a keyboard matrix on a different circuit board using a atmega32u4 micro controller (used in an Arduino pro micro). The keyboard will have 60 (10 rows x 6 columns) buttons, (idea based off: https://medium.com/@monkeytypewritr/building-your-own-keyboard-from-scratch-bd0638c40850), {Rather than click buttons I will just have contacts, for "buttons" that connect their circuits when touched} but I plan to keep the joystick separate from the matrix and still connected to the micro controller. The board will be powered by a micro usb connected to the usb input of a raspberry pi zero w (I won't use the gpio pins because I need to use a small screen that takes them up the way it will be connected if I can't get it to work through mini HDMI.). The matrix acts as a keyboard, while the joystick acts like a mouse with a click. The reason I want the joystick from the joy con is because it is very low profile, and clicks. Since the ps vita, nor the psp joystick click they are virtually useless to me. I need to better understand if the joystick has any special programming quarks to it, the map out of the pin connectors and a good way to connect them to the micro controller (if it needs resistors on the board etc)... I also want to know how to remove the rubber grip on the joystick (I don't want to break it) . The programming I can probably figure out its the hardware I'm not use to. I came to this place because it had the most information on the joycon and its joystick than anywhere else. This is also very theoretical at this point, no schematics exists because like I said I'm new to this tinkering thing.

I dont know much about programing or anything but, if the firmware can be dumped,could be then ijected the firmware(of a lower version), so it works like a downgrade?
Or can only be injected on the same console?
Thats just my opinion and i dont know if this can be done so...
-Thanks

I'm trying to read from SPI via USB, but all I ever am returned is "FF" of the length of the request.

81 92 00 92 00 31 00 00 6d 55 21 60 81 00 80 00 aa 97 77 18 18 81 00 90 10 26 80 00 00 0f ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

Here is an example response.

Does anybody know what I should be doing differently? I'm using the subcommand 10 to read from spi

This is my question from this issue, catching fire in my head and landing here.

Does anyone know what happens when a paired controller disconnects with the console, and tries to reconnect again?

https://github.com/dekuNukem/Nintendo_Switch_Reverse_Engineering/blob/master/bluetooth_hid_subcommands_notes.md#subcommand-0x06-set-hci-state-disconnectpagepairturn-off says that the switch may reconnect to the last BD_ADDR; I tried this but the console was not replying anything back. Is there a specific protocol here that I can look into?

It's 5V but how many amperes ?
Does the Switch's Joy-con rail constantly provide the power ?

Hello,
first of I'm really impressed by the work you have already especially on joy-cons.
Keep going with your good job.
I've got an interesting issue to share. Recently I've bought almost new Nintendo Switch Dock marked as not working on internet auction for reasonable price.

I've just wanted to check what's going on inside, expecting damaged USB-C connector or damaged ribbon cable which I could easily fix. I was really surprised when I saw Dock without any scratch outside and actually looking like it was never unscrewed before.
After brief PCB examination I've discovered that there is no voltage present on ribbon and also on test-points near ribbon connector...
But the most interesting thing turned out when I've compared a newly bought dock PCB with the old one I had.

As you can see there are tons of small elements missing (Capacitors, Resistors) near ribbon connector. Moreover on Side-B (as the iFixit claims) Macronix International MX25L512E 512 Kb CMOS flash is missing. The soldering pads are for sure untouched. There are no any signs of using hot air or soldering iron on the PCB so it's impossible someone has soldered out these elements (who even would need to solder out 0402 size capacitors...). At the begging I supposed that It could may be some newly released montage option with much elements spared. However it is not working and too much elements are missing in my opinion. From the other side I could imagine they could manage to store all persistent data on the other CMOS present on the board and capacitors and small elements could be only filters necessary to pass emission tests.

My question is: has anyone encountered such version of Dock PCB? If this is broken piece how it was possible for such incomplete board to pass Quality Check at Nintendo's factory (PCB manufacturer tests, assembly tests and so on...)?

So I was looking at the pinout for the joycon and I noticed pin 6 is ground only when the console isn’t sleeping. The same goes for the sounds that play when you connect/disconnect the joycon from the console. My question, does pin 6 send the console information to play the aforementioned sounds?

You have the data (images) listed for the Joycons but not the pro controller.

Do you have the schematics of the right joycon pinout i need to make a bridge for the r button

I was wondering if anyone has a measurement of the width of the joystick FFC connector so that I could find a replacement connector that could make using Switch joysticks on other projects easier than trying to solder to that tiny ribbon cable. I've ordered a couple from China but if I could get a breakout board designed and ordered before they get here that would be fantastic. Thanks!

i try to communicate with joycon in Android platform.

i had change some hidapi(use linux hidraw) source(drop the udev, directly read and write /dev/hidrawX). the code i write can running fine in ubuntu.But failed in Android.

After a long time dig,i found out the ubuntu use BlueZ as the bluetooth core stack,and Android use bluedroid.They are many different.But after read some Android bluedroid source, i found the bluedroid use "uhid" to communicate with linux kernel, when i write and read /dev/hidX ,They are same .

so i capture Android bluetooth log (btsnoop_hci.log),And analyze with Frontline Viewer. The problem is when the Android Host send BT-HID SET_REPORT to init joy-con Enable vibration, The joycon feedbcak with HANDSHAKE and the Parameter is ERR_INVALID_REPORT_ID.

The data i write is (01 01 00 01 40 40 00 01 40 40 48 01)

The code i write are running just fine in ubuntu.

Can anyone tell me what is the problem is?

I'm trying to replicate the setup you have, but I just can't get the wires to solder to the contacts. Could you explain how you did it?

Sorry for offtop. Is it exists datasheet for LRA thar used for rumble in switch?

just wanted to share...if you bridge this test point to COL, it seems to register as a press on the "HOME" button.

ive got a spare wired switch controller, what would i need in order to make the wired controller
also how

In your document, it says that data is read every 15 ms or 66.6 fps. How could I convert this into 60 fps so I could theoretically create a TAS for a Switch. Thank you for your help.

So I've been reading through a ton of this repo, and it's amazing BTW, and I keep reading what seems like conflicting information.

Can anyone outright confirm/deny that joy-cons with a charging grip will communicate over USB instead of BT, and will this include gyro data if initialized properly?

I ask because I currently have an HID device (16u2) plugged in via USB that emulates a HORIPAD controller, and it works great, but I'm looking at the possibility of incorporating gyro controls, but am unsure of the support over USB. I'm in the process of acquiring a charging grip to do some digging myself, but didn't want to waste the time if someone else can deny that this will ever work.

I see some saying you have to pair via BT then switch to USB, then there's others stating that the joy-cons only communicate over BT unless physically connected to the sides of the switch.

I'm tempted to try and make a modified joy-con firmware that includes not only standard joy-con functions but also connection for the MFi spec, so joy-cons can be used with the iPhone and Apple TV. Before I start something like that, I need to know:

• How hard is it to get a joy-con to update its firmware, period?
• How hard is it to get a joy-con to update to non-Nintendo-made firmware? (does firmware need signed keys, etc.)
• How much capacity do the joy-cons have for stuff like MFi? (it's not worth it to try if the joy-cons don't even have enough ram/rom to manage the standard BLE/HID stacks and the separate MFi stack)

It's unwieldy to keep everything in one page.

Do you have any plans on deconstructing and looking into the pokéball joycon, the device will allow you to get mew in game. I was thinking that if that is saved in memory on the device you could scan before and after using it in game and seeing what the byte changes are and seeing if you can from there re program mew "back into" the ball, This all asuming that mew is a one time unlock on the upcoming game and that the joycon insides are just a pcb modification and not an enrire new board.

TDLR, any plans on trying to do what you have done already but with the pokeball

Is there any way you can investigate the communication between the JoyCon and the switch during the boot process and the Nvidia Integra boot loader process?

This would be very helpful! DM me if you want @xxwiredxx.

Has anyone reversed the lcd? I'm working on a custom project, and i bought a LCD, same as in the switch, to use with a raspberry, if possible id need the pinouts to connect it

MAC address are 6 Bytes long. But under the headline "Handshake Process" you wrote that the Joycon has a 20 Byte MAC address.
If you take the grey con response data and subtract the 4 Bytes of header + 8 bytes of (to be named)some data, you get 6 bytes + 2 bytes of extra data, the 1st extra data being the checksum. The second has to be some padded zeros.

Since these are serial datas, it is worth finding out whether the transmitted data is encoded before finding out what they actually mean.

To dig into the hdmi dock and figure out why standard usb-c -> hdmi dongles don't work.

Hey, great repo! I'm just beginning to look around , and I thought perhaps someone could point me in the right direction for my goal: I want to build a application that listens for button presses during Switch gameplay, and in response to detected key matches, triggers a Phillip hue hub to change its controlled light states. Think: press the shoot button, and the room lights flash white.

Hello! I have a weird way of trying to add controllers to my arcade fighting stick but I seem to have run into a new situation with trying to convert the signal from the joy stick into a way signal output. I've done it before with Xbox 360 but the Switch's joy stick is new to me. Any ideas would be appreciated.

I want to add a led to each joycon but I don't know where to connect them...
I know you can connect them to the HD rumble but I want the leds to stay on while the joycon is on and turn off when the joycons are off.
I will appreciate it if someone could help me with that
Thanks in advance

EDIT: I think I got it... I just need to find Jc3 on the other joycon...

I am working on adding Joy-Con Bluetooth support to the USB Host Shield 2.0 Library and I have the joy-con connecting and switching to the standard input report format. I'm having this odd behavior though where when I press and release a button, they come back "stuck" in the 0x30 input report message. The amount of time they stay stuck is variable and happens on all buttons. I don't seem to see the same behavior on the analog stick values, they seem to snap back instantly.

Any suggestions?

I'm trying to use BTstack on ESP32 to read basic data (buttons, joystick, and IMU) from a Joy-Con controller. BTstack has limited support for HID host applications, but the HID documentation here is great, so I've been trying to implement what I think is correct protocol. I am able to connect a Joy-Con to the ESP32 as an HID device by using the existing "hid_host_demo" from BTstack. I can send any output report I want - LEDs change accordingly so I know output reports work.

However, the only input reports I ever receive are the "3F" standard input reports that contain button and joystick hat data. If I change the reporting mode using a subcommand, or change the name of the ESP32 to "Nintendo Switch" so the Joy-Con uses full reporting mode by default, no data comes in on the ESP32, not even in response to output reports. As far as I can tell, the ESP32 isn't receiving data (aside from 3F reports) on the HCI or L2CAP layers when it definitely should be. Is it possible that there is some incompatibility in BTstack that prevents it from receiving specific reports from a Joy-Con? Perhaps more L2CAP channels need to be opened somehow (there's only one for control and one for interrupt currently)?

I can post code if needed but the only modifications I've made to "hid_host_demo" are for output reports which don't seem to have any issue.

Since the usb c port doesnt provide any power in rcm mode. I'm looking for other methods to get some power for an arduino.

Can someone check if the 5v pin from the switch has Power while beeing in rcm mode?