...

[ghost]

...

[javmarina]

Hi! Sorry for the delay, I've had a busy week.

It's super strange that the response is displayed as 0. It's either a bug in the Java side, or an electrical failure (short circuit?), because the Arduino is not supposed to send 0x00 never.

I think the Switch version is not relevant, because the issue has to do with the PC <-> Arduino connection, not with Arduino <-> Switch. Afaik, nothing to modify in the FW regarding Switch version, only if they changed the Pro Controller protocol, which I doubt.

How did you bypass the syncing?? It's a key feature so that packets are interpreted correctly by the Arduino.

I will try to investigate the Java exception, but it doesn't seem critical.

[javmarina]

Hmmmmm, so the syncing is still necessary tho.

Yes. If no syncing is performed, the messages could be interpreted incorrecly. Messages with the controller input are 8 bytes. If not synced, byte 1 could be read as byte 2, thus sending the Switch a wong input.

I have solved the Exception in the text log, should be fixed with the last commit.

Great setup! I have analyzed the code and discovered a potential issue with how bytes are read from the serial port. Can you check that Arduino -> PC messages are also sent? In the video we can see that PC -> Arduino is working, but I don't know about the other direction Sorry, according to the logs, the Java progam is in fact receiving FF bytes.

Please, also tell me the baudrate you are using, because it might have something to do with the issue.

My guess is that the issue lies in SerialAdapter.java:112. The readByte() method would return 0 (which appears in the log) if the read timeout is elapsed. In this case, serialPort is not null. My proposal is that you change READ_TIMEOUT to 0, if you're able to.

It seems that you are using Windows. Did you enable low latency mode? See here, try changing it in the Windows Control Panel.

[javmarina]

Please note that you have to use the same baudrate that is configured in the firmware. If you use the provided .hex, it's 1M.

For Java compilation, I use the Gradle 'buildAll' command (defined by me for this project), which generates fresh JARs. Did you make sure you were running the recently compiled programs, after the changes to the timeouts?

Does the exception of the first comment still occur? It's supposed to be fixed now, with the last commit.

As a last resort, you can try the Python script (here) and see if it works. If it does, then it's an issue with the Java program. Otherwise, it might be a HW issue. This is not the first time a faulty HW is the issue (#5), but I don't know in this case.

I think the issue is certainly because Arduino Uno R3 doesn't has UART1.

I don't understand what you mean.

[nullstalgia]

Can you take a photo of the pinout of your UART-USB board?

Also, in your pictures here and in the issue in my repository, I do not see a wire properly connecting into GND of the UART board and the Arduino.

Here is how my connection looks.

GND - GND
TX - TX
RX - RX (Normally these would be swapped, but this is an unusual use case for the hardware)

I didn't load HoodLoader2 when testing it just now. Low chance, but could you have a weird AVR fuse setup? I'm assuming you have a way to use the ISP, and using AVRDUDESS I got these fuses from my 16u2. HoodLoader2 uses different fuses.

[javmarina]

No.

Perfect!

I flashed Arduino_UNO_R3.hex from Development Build to my arduino one more time then i disconnected my arduino to my pc then i inserted TX-TX, RX-RX, 5V-5V, GND-GND to my USB-to-UART then my PC then blue cable connected to my nintendo switch TX-TX, RX-RX doesn't turn on the TXD and RXD lights on USB-to-UART adapter and arduino after enter "python client.py 1000000" then "0" the sync fails after a few seconds, after swapping to TX-RX, RX-TX does turn on the TXD and RXD lights on USB-to-UART except arduino then turn off and still sync fail in under than a second, i think we'll wait for someone to test the same thing with geninue original arduino uno r3 from arduino.cc and USB-to-UART named "Usb 2.0 P Rs232 Ttl Uart Cp2102" which is not FTDI unfortunately to see if appears the same issue as mine. so do i need to install HoodLoader2 to my arduino?

I don't know what HoodLoader2 is and I didn't do anything with it. From what I've seen I don't think it will help us.

See last commit, I have added more messages to client.py (untested). Try again with that, if it doesn't work try increasing timeout variable in line 524. My bet is that there is some HW issue and the PC is never receiving bytes!! Either because the adapter is malfunctioning or the Arduino is not sending them at all.

[javmarina]

Hi, I have pushed a new commit. The PC is receiving a lot of bytes, maybe they were received before and stored in the input buffer. Last commit should fix that. Also, now the received bytes are printed (for easier debugging) and I have fixed a very obvious issue with the read_byte_latest() function. 😅

[javmarina]

My bad, try again with the latest commit. However, it's super strange that you're receiving 47 bytes! There is something going on with the Arduino firmware. With the last change we will be able to see what we are receiving. Is the Arduino connected to the Switch via USB? Try disconnecting it (just serial between Arduino and PC) and powering the Arduino with a 5V cable from the serial adapter.

[ethanriverpage]

I have the same Arduino && same USB to TTL adapter.

I could not get the client.py to read anything from the server -- I would consistently get the error Couldn't sync with the AVR MCU.

Poking around with drivers -- I've noticed that I can manually adjust the baudrate of the COM4 port in Device Manager. It would not work at the default 1M baudrate. I recompiled the Joystick.hex, adjusting avr.h to a baudrate of 9600. I then adjusted the baudrate within the driver to 9600.

Works! Issue is controller latency is absolutely terrible, but expected for 9600 baudrate. Issue is -- I can't find a way to set baudrate to above 128000? This is with the official driver for this cable. I have yet to try 128000, but currently the latency is completely unusable.

I believe this means it is an issue with this specific cable and it not adjusting to the baudrate of server.jar, rather using the driver settings. Does anyone know of a solution to this? Google is getting me nowhere.

Will test 128000 and get back.

[ethanriverpage]

Baudrate 128000 works, and does not give me a latency warning.

[javmarina]

That looks cool! So after some investigation I think what is happening is that 1M is not a supported baudrate for the CP2102, and when we try setting the baudrate by code (either Python or Java), the device/driver discards it. So it seems we're in fact working with a lower baud rate. That would explain reading such a high number of input bytes.

According to the CP2102/CP2109 datasheet, supported baudrates are (Table 12): 300, 600, 1200, 1800, 2400, 4000, 4800, 7200, 9600, 14400, 16000, 19200, 28800, 38400, 51200, 56000, 57600, 64000, 76800, 115200, 128000, 153600, 230400, 250000, 256000, 460800, 500000, 576000 and 921600.

As you can see, 1M is not there. You might be wondering now why I chose 1M as the default. It's because it is the highest baudrate supported by Arduino Uno - ATmega16u2 (actually the highest is 2M when double speed mode is enabled, but it's very unstable). Coincidentally, it's supported by the FTDI USB-UART adapter (the one I use), so I never had issues.

The issue is then that there is a mismatch between the adapter baudrate and the Arduino baudrate. The criterion for selecting a baudrate is to select values in the intersection of "supported by adapter" (see above for CP210x) and "supported by ATmega16u2", some of which can be seen in Tables 18-9 to 18-12 of the datasheet. They're basically 1M, 0.5M, 250k, 230.4k, 115.2k...

I think the way to go is: first, select a baud rate from the intersection (preferably high). In this case, baud rates supported by both ATmega16U2 (Arduino) and CP210x (adapter) are: 0.5M, 250k, 230.4k... (not 1M!!!). So I would go with 0.5M; then, compile the firmware for your AVR device (not limited to Arduino Uno), setting the BAUD macro in avr.h to the desired value (a warning will appear if not achievable, look out for it). Then, operate the software as usual: select the baudrate in the Java GUI or Python script, and it should work. Regarding @ethanriverpage's concern of having to use the Device Manager settings, I think it's not necessary as long as we use supported values. The libraries I'm using are capable of reconfiguring the virtual COM driver on the go.

Going forward, the corrective actions are imho:

1. Clearly show this information in the documentation (sort of a guide on how to select the baud rate).
2. In the software side, detect whether the baud rate was set correctly. If not, display a warning to the user

Let me know if you think more actions are needed!

[javmarina]

I have included some checks in the Python script and the Java GUI, however they are not guaranteed to work because of differences in drivers implementations. Moreover, I have explicitly updated the Java serial library to the latest version and enabled reducing the latency timer for FTDI devices.

[javmarina]

So now we see what you are receving. This is super strange. There is no way that the FW sends those bytes. Are you sure you are correctly flashing the firmware? If so, try to compile the old FW version (here), because there was a big rewrite afterwards. Maybe I introduced a bug somewhere.

However, I tell you again, it's very strange. Can it be a faulty HW (Arduino, serial adapter, cables...)?