The necAnalyzer came to life out of a personal quest for the perfect NEC infrared remote control analysis tool. With existing options falling short, I took matters into my own hands.

From the outset, the vision was clear: a web client paired with an ESP32-C3 development board, communicating via WiFi-WebSocket. The plan came to fruition smoothly.

Upon deciding to share this tool with the world, I hit a snag—router configurations and WebSocket setups proved elusive, unless resorting to mini-programs or apps, which seemed like too much of a hassle.

Then, by a stroke of luck, I stumbled upon the Web Serial API, and my jaw dropped. Could it be that browsers can now converse directly with hardware?

(Naive me, indeed.)

Plug and play is the tool I've been dreaming of.

I dived right in, patching together the terminal with example routines, and the IDF monitor confirmed everything was a-okay ✔

But on the web front, trouble brewed. The serial connection was solid, yet data was nowhere to be found, and error messages were conspicuously absent. If it were an issue with the development board, why did desktop serial tools communicate without a hitch?

I tried it all—handcoding according to MDN and Chrome's documentation, copy-pasting code from the web, AI-generated scripts, and every online serial tool under the sun, all to the same unyielding result.

I even began to doubt the Web Serial API itself, testing across browsers and versions, but to no avail.

Desperate for a solution, I reached out for help, only to find that everyone else found the online tools just fine! Fine? Then maybe it was the ESP32-C3 or IDF causing the trouble? At this point, my thoughts were in chaos, and I was questioning everything!

But a true warrior braves the bleakest of circumstances, so I resolved to give it one last shot. If the desktop could handle it, why not use it to catch serial data and toss it over to the web?

I coded, I debugged, and finally, the long-awaited message arrived—but it was a boot message, announcing that the development board had entered download mode!

The second round of troubleshooting commenced, with searches spanning from Bing to Haoso, from AI to the wisdom of veterans... all in vain.

As I lay exhausted, my mind finally cleared. If CH340 clashed with the Web Serial API, what about other serial chips?

With a jolt of inspiration, I dusted off another ESP32 development board, programmed it, connected it, and voilà! Success!

The CP2132 was in the clear, so the culprit had to be the CH340. Yet, the CH340 solution is ubiquitous, and Web Serial API has been around for ages. If there were compatibility issues, wouldn't there be a whisper online?

It dawned on me that the chip itself might be faulty or that there was an issue with the chip version.

Recalling a past project, I had a CH340 chip on hand and decided to give it a whirl. As I prepared to dive in, I noticed something about the Anxinke ESP-C3-32S-Kit development board—it lacked the usual two 8050s, which are essential for hardware control of the serial port.

Consulting the development board's spec sheet, I discovered that the CH340's RTS was directly wired to the C3's EN, and DTR to IO9.

Could this be the culprit? Too tired for truth tables and power-on sequences, I opted for the simplest test: replacing the components with a conventional setup and powering up.

I removed R4/R6 and added two 8050s (VT1/VT2) and two 10K resistors (R1/R2).

I plugged it in, turned it on, and WOOOOOO~, web serial communication was a success!

Thus, I reached an unofficial conclusion:

The ESP32-C3 & CH340 scheme, omitting the two 8050s for automatic download control, affects webSerial and nodeJS's serialport package, causing the microcontroller to enter download mode after connection.

So, hello AI-Thinker, like Linus's greeting to NVIDIA.