Discovery 3 CAN Bus Sniffing, Part 2: LilyGO ESP32 CAN Board Setup

The interface for this Discovery 3 test was a LilyGO CANbus ESP32 board connected to a Windows laptop over USB-C. The board appeared as a CH9102 USB serial device once a proper data cable was used.

USB detection

At first, Windows only showed the laptop internal management serial port:

COM3 = Intel(R) Active Management Technology - SOL

That is not the CAN adapter. After changing the USB cable, the LilyGO appeared correctly:

COM23 = USB-Enhanced-SERIAL CH9102
VID/PID = VID_1A86 PID_55D4

The failed cable was a LISEN USB-C cable. It may have been charge-only, damaged, or unreliable for data. Either way, it caused the board to disappear from the serial port list and made the CAN side look like the problem when USB was actually the blocker.

Firmware already on the board

The board already had a CAN sniffer firmware loaded. At 115200 baud it printed a command menu:

LilyGO CAN sniffer
Commands:
  status
  start
  stop
  mode listen
  mode normal
  pins 5 4
  pins 27 26
  speed 500
  tx 7DF 02 01 0C 00 00 00 00 00
  obd 0C

It also brought up Wi-Fi, either as a station or fallback access point:

Fallback AP: LilyGO-CAN
Fallback password: canbus123
Fallback URL: http://192.168.4.1/

Passive listen mode

The first safe test was listen-only mode at 500 kbit/s:

mode listen
pins 5 4
speed 500
start
status

The firmware reported:

CAN listen-only started: TX=GPIO5 RX=GPIO4 bitrate=500k
status: running=yes mode=listen-only TX=GPIO5 RX=GPIO4 bitrate=500k frames=0

No frames were observed. We also tried the common alternate LilyGO mapping, GPIO27/GPIO26, with the same result.

Diagnostic request mode

Passive sniffing can be quiet if the vehicle modules are asleep or the wrong bus is being watched, so the next step was a standard OBD-II diagnostic request for engine RPM:

mode normal
speed 500
start
obd 0C

The board transmitted the request:

TX OK ID=0x7DF DATA=02 01 0C 00 00 00 00 00

But no response was seen while the cable was still wired using the incorrect colour chart. That made sense once the cable was continuity mapped: CAN-L and ground were not on the expected colours.

The useful lesson is to prove the USB layer first, then the firmware settings, then the actual OBD pin-to-wire mapping. Debugging all three at once wastes time.