ELM327 BLE verified in the car: service FFF0, FFF1 notify/write, ELM327 v2.1

Scanner log saved in 11-BLE-Scanner/results; CLAUDE.md updated with the
adapter's GATT layout, replies and supported PIDs 01-20.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
patriandClaude Opus 5.5 committed 2026-10-23 14:21:44 +02:00
1 parent 8a84b42a3b
commit 0bd6aef6b5
2 files changed
+127 -1

No files matched your search

+6 -1
View File
@@ -95,7 +95,12 @@ Re-flash it with Flash Download Tool: ESP32-S3, `1.85_demo.bin` @ 0x0.
## OBD adapter (user's)
AliExpress "ELM327 Mini V2.1 Bluetooth OBD **Dual Mode** 5.1" — dual mode = Bluetooth Classic SPP **and BLE**, so the ESP32-S3 should be able to connect directly over BLE (no bridge ESP32).
Cheap dual-mode clones typically expose BLE service `FFF0` (notify `FFF1`, write `FFF2`) — **not yet verified** on this adapter; use `11-BLE-Scanner` in the car (results in its flash log). Adapter is powered from the car's OBD port (pin 16, 12 V).
**Verified in the car (2026-10-23, `11-BLE-Scanner`, log in `11-BLE-Scanner/results/2026-10-23_car_test.txt`):**
- BLE name **`OBDII`**, MAC `1c:a1:35:69:8d:c5`, advertises service **`0xFFF0`**. Characteristics: **`FFF1` [W, WnR, Notify]**, **`FFF2` [W, WnR]**.
Working setup: subscribe to notifications on `FFF1`, write commands (`"...␍"`) to `FFF1` (write without response) — `FFF2` is the usual write characteristic on such clones and should work too.
- Replies: `ATZ` → `ELM327 v2.1` (echo on by default → send `ATE0`), `ATRV` → `12.9V`, `0100` → `41 00 BE 3E A8 13`.
- **Supported PIDs 01–20** (from `BE 3E A8 13`): 01 monitor status, 03 fuel system, 04 engine load, 05 coolant temp, 06/07 fuel trim B1, **0B intake manifold pressure (MAP)**, **0C RPM**, **0D speed**, 0E timing advance, 0F intake air temp, 11 throttle, 13 O2 sensors, 15 O2 sensor 2, 1C OBD standard, 1F run time, 20 → more PIDs in 21–40. **No 10 (MAF)** → speed-density engine.
- Adapter is powered from the car's OBD port (pin 16, 12 V).
## Gotchas / observations
- **LVGL 8 GIF bug (patched locally, only relevant if LVGL 8 is used again):** LVGL 8.3.11 `gifdec.c` (`gd_open_gif`) filled the canvas *opaque* with the GIF's background color. GIFs with a transparent background (e.g. `loligod.gif`, bg = RGB 28,29,49) showed that dark gray except where "restore to background" frames had cleared to transparent (→ screen black). **Patched** in the vendor copy `2-Program Example/Demo_Arduino/library/lvgl/src/extra/libs/gif/gifdec.c`: initial canvas alpha 0x00 (marked `LOCAL PATCH`). Re-apply if LVGL is ever replaced/upgraded.