Discovery 3 CAN Bus Sniffing, Part 4: We Have Frames

Part 3 ended with the LilyGO ESP32 CAN board talking over USB, but the Discovery 3 CAN frame counter stuck at zero. The breakthrough was not firmware magic. It was correcting the physical OBD pigtail wiring, then using the working LilyGO CAN pin mapping.

The wiring that finally worked

The seller colour chart for the DIY OBD cable was wrong, so the cable was mapped by continuity from the actual OBD plug pins. The corrected wiring is:

OBD pin 6   Green       -> LilyGO CAN-H
OBD pin 14  Green/White -> LilyGO CAN-L
OBD pin 5   Light Blue  -> LilyGO GND

This matters because the earlier assumed mapping had CAN-L and ground on the wrong wires. Once the cable was mapped by pin instead of by colour, the vehicle CAN lines made sense.

The LilyGO pin mapping that worked

The first test after fixing the vehicle-side wiring still used the original LilyGO mapping:

mode listen
pins 5 4
speed 500
start
status

That still showed zero frames:

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

Switching to the alternate mapping brought the bus to life:

mode listen
pins 27 26
speed 500
start
status

The working configuration for this LilyGO board is therefore:

TX = GPIO27
RX = GPIO26
bitrate = 500 kbit/s

First successful passive capture

The first useful capture was saved as:

can_capture_2026-05-06_corrected_wiring_pins27_26.txt

Summary:

frames captured: 4644
unique CAN IDs: 27
bitrate: 500 kbit/s
format: extended IDs
working LilyGO mapping: TX=GPIO27 RX=GPIO26

The most frequent IDs in that capture were:

0x17B452B0 count=1157
0x1F1F0    count=462
0x979BAB0  count=458
0x71C0AA0  count=408
0x4C1F6B0  count=369
0x12E9E6A0 count=285
0x17ADBF70 count=244

The important result is that this is now real vehicle traffic, and it is showing extended-ID CAN frames rather than the simple standard-ID OBD-II pattern we were initially looking for.

RPM request test

After passive capture worked, a standard OBD-II RPM request was tested on the working LilyGO mapping:

mode normal
pins 27 26
speed 500
start
obd 0C

The transcript was saved as:

can_obd_request_2026-05-06_pid_0c.txt

Summary:

frames captured: 3242
unique CAN IDs: 27
standard 0x7E8/0x7E9 OBD-II style reply: not observed

That does not mean diagnostics are impossible. It means the plain functional request to 0x7DF did not produce an obvious 0x7E8 or 0x7E9 reply in this capture. The Discovery 3 traffic observed here is extended-ID traffic, so later diagnostic work may need Land Rover/Jaguar-specific addressing rather than assuming the basic generic OBD-II response shape.

What changed from the zero-frame tests

The failed setup had two independent traps:

• The OBD cable colour chart was wrong for this physical cable.
• The LilyGO mapping TX=GPIO5 RX=GPIO4 did not receive frames on this board, while TX=GPIO27 RX=GPIO26 did.

The working combination is:

Green       -> CAN-H
Green/White -> CAN-L
Light Blue  -> GND
TX=GPIO27
RX=GPIO26
500 kbit/s

Next plan

Now that capture is working, the next step is not to guess a DBC file. The better order is:

• Clean up the serial CLI and logging so captures are consistent.
• Build a small log parser to summarise IDs, counts, lengths, byte changes, and timing.
• Take labelled captures for suspension access height, normal height, and off-road height.
• Run correlation and range analysis across those labelled captures.
• Only start DBC work after there are repeated captures tied to known vehicle actions.

Part 4 is the point where the project changes from electrical debugging to data analysis. We have frames now; the next job is making those frames explain themselves.