Call for testing: CAN Capture (v2.16-beta) — grab a candump on your car

[hypery11]

v2.16-beta adds CAN Capture to the Flipper. It is read-only (Listen-Only, never transmits), so it is safe to run on a live car — and we need people on real cars to confirm it works and to grab captures.

Download: https://github.com/hypery11/flipper-tesla-fsd/releases/tag/v2.16-beta (tesla_mod.fap)

What to do

1. Install tesla_mod.fap and open the app.
2. Settings → CAN Capture = ON. Keep Mode = Listen (Listen-Only).
3. Run on your car for ~30 seconds. The screen shows REC <n>.
4. On the SD card, check apps_data/tesla_mod/captures/cap_*.log. It should contain lines like:
   (1.234000) can0 485#00112233445566AA

Report back

• Did cap_*.log appear, and does it contain (t) can0 ID#DATA lines? (paste the first ~20 lines)
• Your Model / year / HW (HW3 / HW4 / Highland) / firmware version.
• Anything odd: no file, empty file, app slow or crashing, missed frames.

Bonus — feed the cracker

If you captured a counter+checksum frame, run:

python3 tools/tesla_crc_cracker.py --id 0x485 cap_xxx.log

and paste the output. We especially want captures of 0x485 (Highland gear shift) and 0x229 (pre-Highland stalk) — recovering their checksum is what unlocks those injections.

Then

File a car_compatibility report (model / year / HW / firmware / region) and attach your capture, or just drop it in this thread.

ESP32 users: you already have capture (SD dump + the port-82 stream) — captures from either platform are welcome.

Thanks for testing on-car.

[hypery11]

Update — v2.16-beta.2 is up and adds the other half of the loop: Send Test.

You can now author a .cantest text profile (one frame per line, the same candump format the capture log uses — so you can paste a captured line and just tweak the bytes), drop it on the SD card under apps_data/tesla_mod/tests/, and replay it from the menu (Send Test [BETA]). It opens in dry-run; sending is gated to a parked, stationary car (fail-closed — no speed frame, no send) and writes a result log to tests/results/ for reporting.

Format + workflow: docs/cantest-format.md · example: examples/example.cantest.

So the full capture → crack → send → report loop is now on-device. Please test on-car (parked!) and report back — both the read-only capture and, if you're comfortable, a Send Test result.

[jewelrylin]

Issue #103 Reply Draft

Replying to "Call for testing: CAN Capture"

ESP32 testing report — full-rate verified, no #104 decimation on this path.

Setup

• Car: Model Y Juniper RWD (HW4)
• Firmware: 2026.14.3, Region: Taiwan
• Board: Waveshare ESP32-S3-RS485-CAN
• Bus tap: X179 pin 13/14 (Bus 6)
• Mode: Listen-Only (all TX features disabled)
• Capture path: /api/can-log/dump (in-memory ring buffer, NOT port-82 stream)

Capture worked, and at FULL rate

Captured four scenarios totaling 79,781 frames over 196 seconds. 0x129 SteeringAngle recorded at 100.1 Hz across all four scenarios, matching the expected real-bus rate for that ID and confirming this capture path is not affected by the #104 RX-queue decimation issue.

Sample (first ~10 lines of 14.3_D_nag.log):

(0.000000) can0 2B9#58D004C778BA5838
(0.005000) can0 118#AE61953031C87006
(0.005000) can0 370#72030836203E0185
(0.007000) can0 129#CD3E1E2006207F00
(0.007000) can0 185#011000011000640C
(0.015000) can0 370#72030838203E0288
(0.016000) can0 118#7F62953031C84006
(0.017000) can0 129#C83F1F2006207F00
(0.025000) can0 118#8063953031C84006
(0.026000) can0 370#7204083B203F038E

Bus 6 contents on HW4 Juniper RWD 14.3

ID         Rate     Note
0x118      100 Hz   DI_systemStatus
0x129      100 Hz   SteeringAngle (full-rate verified)
0x185       50 Hz   Lighting state
0x238        2 Hz   UI_driverAssistMapData
0x2B9       25 Hz   DAS_control
0x318       10 Hz   GTW_carState
0x334        2 Hz   UI_powertrainControl
0x370      100 Hz   EPAS3P_sysStatus (nag)
0x389        2 Hz   DAS_status2
0x398        5 Hz   GTW_carConfig
0x399        2 Hz   DAS_status (note: documented as HW3, but present on this HW4 car)
0x3D9        1 Hz   UI_gpsVehicleSpeed
0x3F8        1 Hz   UI_driverAssistControl
0x3FD        6 Hz   UI_autopilotControl

Notable absences on Bus 6 (HW4 Juniper RWD)

These were explicitly added to the watch list and recorded ZERO frames over 185+ seconds:

• 0x39B — HW4 DAS_status — see Issue [bug] Nag killer not working on HW4 2026.14.6.x — need 0x370/0x39B captures #100 reply, this changes the picture for HW4 14.x nag.
• 0x485 — Highland gear shift — confirms Call for testing: CAN Capture (v2.16-beta) — grab a candump on your car #103 captures of this ID need pin 9/10.
• 0x229 — pre-Highland stalk — expected absent (Juniper has no physical stalk).
• 0x3C2 — VCLEFT_switchStatus — re-confirms 14.3 Protection Mode — auto-warn on 2026.14.x firmware (v2.15) #73 / commit 19d33c6.

Files

ZIP attached: 14.3_HW4_Juniper_RWD_BusSixCaptures.zip (4 candump .log files).

Compatibility report context (per your request):

• Model: Model Y Juniper / Highland refresh, RWD trim
• Year: 2025+ (Juniper)
• HW: HW4
• Firmware: 2026.14.3
• Region: Taiwan
• Tap: X179 pin 13/14 (Bus 6)
• Capture: works, full-rate via /api/can-log/dump

14.3_HW4_Juniper_RWD_BusSixCaptures.zip

[hypery11]

@jewelrylin thank you for the first full testing report on the call, and a thorough one. Logged the compat data point: Model Y Juniper RWD HW4, 2026.14.3, Taiwan, Waveshare S3, Bus 6 (pin 13/14).

Two useful confirmations from your run:

• Full-rate capture works on the Waveshare S3 via the in-memory dump path — 0x129 at 100.1 Hz is the proof. That also independently validates the Full-rate single-ID capture: hardware acceptance filter (web-stream captures are RX-queue decimated) #104 hardware-filter fix on a second TWAI board.
• Your Bus-6 ID inventory (especially 0x39B-absent / 0x399-present) is gold; replied in detail on [bug] Nag killer not working on HW4 2026.14.6.x — need 0x370/0x39B captures #100.

Worth flagging the two capture paths so others pick the right one: the in-memory dump (/api/can-log/dump) you used is full-rate but bounded by the ring buffer, good for short scenarios; the port-82 ?ids= stream (with the #104 fix) is full-rate for a single ID and unbounded, good for long single-ID hunts like the 0x229 work. Both write candump-compatible files.

[hypery11]

v2.16-beta.4 is up — https://github.com/hypery11/flipper-tesla-fsd/releases/tag/v2.16-beta.4

Since beta.3 it adds:

• Continuous AP (HW3/Legacy, @vrs11 Continuous AP implementation #107) — auto-re-engage after a turn-signal disengage. Off by default; brake / full right-stalk-up is the kill switch. HW4 is stubbed inert (engage sequence not mapped yet).
• HW4 0x399 nag fallback ([bug] Nag killer not working on HW4 2026.14.6.x — need 0x370/0x39B captures #100) — for Juniper RWD trims that don't broadcast 0x39B on Bus 6.
• 0x229 checksum cracked + gated — tools/crack_0x229.py; injection turned out to be a dead end on a shared bus (the writeup is on v2.16 candidate: 0x229 SCCM_rightStalk AP engage for pre-Highland HW3 #95), and 0x229 is now refused by the Send Test runner for safety.

Full-rate single-ID capture (#104) and the AP-First 1s debounce from beta.3 are included.

If you're testing: HW3 owners, try Continuous AP (enable it deliberately, kill switch = brake or full stalk-up). HW4 Juniper owners — does the nag actually hold off now? And the full-rate ?ids= capture still wants more cars. Reports + result logs welcome.

[hypery11]

v2.16-beta.5 is up: https://github.com/hypery11/flipper-tesla-fsd/releases/tag/v2.16-beta.5 — focused fix for the HW4 Juniper nag killer (second-wave escalation, #100) plus an honest AP-First banner on the ESP32 dashboard. HW4 Juniper 14.x testers: this is the one to try for the hands-off nag. Reports welcome.

[hypery11]

v2.16-beta.6 is up: https://github.com/hypery11/flipper-tesla-fsd/releases/tag/v2.16-beta.6 — brings AP-First to the ESP32 (off by default). On 2026.14.x: enable it, engage AP from the stalk first, and the device only injects once AP is up + stable (1s). Gates 0x3FD/0x3EE and the nag 0x370. This is the ESP32 fix for the activation-edge steer-jerk / 'autosteer turning off'. HW3/HW4/Legacy testers on 14.x — please try and report.

[Symness]

Hi @hypery11, does this require the car to be offline, or does it work online?
(Sorry, I didn't have time to capture the logs you needed on another issue)

[hypery11]

@Symness — no need to take the car offline. The capture is passive: the board just listens on the CAN bus (Listen-Only) and writes what it sees, so the car stays fully online and connected the whole time. "Online vs offline" doesn't matter for capturing — you can do it on a normal connected car in your driveway. Power the board, start the capture, drive or sit as needed, stop, grab the log. No internet or account state is touched.

(And no rush on the logs from the other issue — whenever's convenient.)

[Symness]

I'm talking about actually enabling FSD, not just retrieving logs