AEdison-tech/Chevrolet-Aveo-DPF-monitor

# Chevrolet Aveo (T300) DPF 监视器 [](https://github.com/AEdison-tech/Chevrolet-Aveo-DPF-monitor/actions/workflows/firmware.yml) [](LICENSE) [](platformio.ini) [](#project-status) 一个小巧的 ESP32 + OLED 仪表盘，通过 Wi-Fi ELM327 与 Chevrolet Aveo T300 的柴油发动机 ECU 通信，并显示 **实时 DPF 碳载量、自上次再生以来的行驶里程以及活动的再生进度** — 在再生开始和结束时伴有蜂鸣音提示。之所以开发这个项目，是因为无论是原厂仪表还是现有的开源项目，都没有为这款车展示这些信息。

## 目录 - [为什么选择 ESP32？](#why-esp32) - [项目状态](#project-status) - [硬件](#hardware) - [诊断适配器](#diagnostic-adapter) - [蜂鸣器 / 信号输出](#buzzer--signaling-output) - [电源](#power) - [工作原理](#how-it-works) - [逆向工程 DID](#reverse-engineering-the-dids) - [调试日志系统](#debug-logging-system) - [该 ECU 的 DID 参考](#did-reference-for-this-ecu) - [开发历史](#development-history) - [路线图](#roadmap) - [快速开始](#getting-started) - [贡献](#contributing) - [许可证](#license) - [致谢](#acknowledgments) ## 为什么选择 ESP32？ 最初的计划根本不是使用 Wi-Fi。原本打算复用手头已有的旧款 ELM327 **蓝牙**适配器，并让微控制器像手机上的 OBD 应用程序一样，通过蓝牙经典串口协议 (SPP) 与之通信。之所以选择 ESP32，正是因为它：它是市面上少有的廉价微控制器平台，能够在单个模块中提供完整、成熟的蓝牙经典 + BLE + Wi-Fi 协议栈。 不过，连接到 ELM327 的蓝牙仍然是未来一个完全开放的选择 — 这也是该项目坚持使用 ESP32，而不是更便宜的仅支持 Wi-Fi 或仅支持 BLE 的芯片的重要原因。如果你有能够承受 Mode `$22` 数据流通信的蓝牙 ELM327/OBD 适配器，我们鼓励你尝试并反馈结果。 ## 项目状态 **这是一个功能性原型，而不是一个最终产品。** 它已经在真实的驾驶过程中（包括完整的 DPF 再生循环）完成运行和测试。目前**还没有 PCB**。 ## 硬件 | 部件 | 备注 | |---|---| | ESP32-WROOM-32 开发板 | 任何具有标准 DevKitC 引脚排列的通用 ESP32 开发板均可 | | SSD1306 0.96" I2C OLED, 128×64 | `SDA` → GPIO21, `SCL` → GPIO22 | | 压电蜂鸣器 + NPN/MOSFET 开关 | 参见 [蜂鸣器 / 信号输出](#buzzer--signaling-output) | | Wi-Fi OBD-II (ELM327) 适配器 | 参见 [诊断适配器](#diagnostic-adapter) | 接线原理图：

### 诊断适配器 该项目目前使用的是 **Vgate iCar2 Pro V2.3 (Wi-Fi/蓝牙)** OBD-II 适配器，实践证明它在此用例中非常稳定。

适配器的两个特性影响了固件的设计，如果你打算自己动手制作，了解这些会很有帮助： - **请求缓冲区 / 会话限制。** 该适配器只能在特定的 TCP 连接上可靠地响应大约前半打的查询/响应往返 — 之后就会悄无声息地停止响应。这是通过记录约 50 分钟连续驾驶日志证实的：在此之后的会话中，任何请求都得不到真实响应。这就是为什么固件**在每次读取循环之前都会重新建立 TCP 连接**（参见 `ElmDataProcessing::reconnect()`），而不是保持一个长连接 — 这是对该限制的刻意变通方案，而不是疏忽。 - **休眠/唤醒行为。** 适配器在发动机关闭一段时间后会自动休眠（为了节省汽车蓄电池电量），这是符合预期的。问题在于它一旦休眠，就**无法通过 Wi-Fi 或蓝牙自行唤醒** — 需要手动按下适配器上的物理按键，它才会再次响应。这使得使用该特定适配器实现完全的“即走即用”操作变得不可能。 **如果你知道有哪款诊断适配器能够可靠地休眠和唤醒（无需手动按键），并且能在持续的 Mode `$22` 轮询下保持稳定，请提交一个 issue — 非常欢迎大家推荐更好的适配器。** ### 蜂鸣器 / 信号输出 蜂鸣器是一个带有内部振荡器的压电元件（只需输入直流电即可自行发声 — 无需 PWM/音频信号）。它的额定电压为 5V，这就是为什么原理图中通过 MOSFET 开关级来驱动它，而不是直接连在 GPIO 上。实际操作中，直接接 3.3V 也能正常工作，只是声音会明显小一些。 正因为如此，固件对蜂鸣器引脚的驱动始终只有**开/关**状态 — 不涉及任何音调生成或 PWM。这意味着，如果不需要声音警报，可以直接将该压电蜂鸣器换成普通的 LED，而无需更改任何固件。 ### 电源 ESP32 通过 USB 由汽车点烟器/USB 充电器供电，因此它会随着点火自动开机，无需单独的开关。 ## 工作原理 ECU 通过基于 CAN 总线的 ISO-TP 协议，使用 **UDS Mode `$22` (ReadDataByIdentifier)** 来公开车辆数据，请求标头为 `7E0` / 响应标头为 `7E8`。固件在原始 AT 透传模式下与 ELM327 适配器通信（通过 [ELMduino](https://github.com/PowerBroker2/ELMduino)），并将 Mode `$22` 请求作为原始十六进制字符串发送，例如使用 `223275` 请求 DID `3275`。 每个周期读取三个 DID： | DID | 含义 | 公式 | |---|---|---| | `223275` | DPF 碳载量 % | `byte / 255 * 100` | | `223277` | 自上次再生以来的里程 | 3字节大端序数值 | | `223274` | 活动再生进度 % | `byte / 255 * 100`，再生期间以外为 0 | `223274` 在非再生期间为 0，在大约 5-10 分钟的燃烧过程中以近乎线性的方式攀升，并在结束后降回 0。固件通过监测该值在周期之间穿过零/非零边界，来检测再生的开始和结束，触发蜂鸣器，并在再生处于活动状态时，将 OLED 切换到专用的进度条屏幕。 ## 逆向工程 DID 目前似乎还没有针对这款车进行 DPF 监控的现有开源项目，而且网上基本上找不到关于 Chevrolet/GM-Aveo 专用 UDS DID 的文档。在无法使用已经识别该 ECU（Bosch EDC17C59）的专业级诊断工具的情况下，弄清楚这辆车上到底存在哪些 DID 以及它们的实际含义 — 而不是仅仅盲目猜测不相关车辆的 PID — 是最难的部分。 ### 调试日志系统 为了让这种搜索变得可行，固件包含一个调试日志模式（在 `platformio.ini` 中配置 `DATALOGGING_ENABLED` / `DATALOGGING_SD_ENABLED`），该模式会记录发送的每个请求和接收的每个原始响应，并附带时间戳，同时输出到 Serial 控制台和 SD 卡上的 `log.txt` 文件中。这使得在真实的多小时驾驶过程中探测候选 DID 成为可能。 随后对生成的日志进行分析，将候选 DID 的值与已知事件（再生开始/结束、碳载量%下降、距离重置）进行关联。**Claude（Anthropic 的 AI 助手）被用作帮助梳理和分析这些日志的工具** — 用于发现其数值能追踪再生状态的 DID，排除常数和噪声，并比单纯的手动审查日志更快地缩小候选范围。 ### 该 ECU 的 DID 参考 通过对驾驶记录和日志分析的确认，在此 ECU（Bosch EDC17C59, Chevrolet Aveo T300 A13DTR）上的情况如下： | DID | 状态 | 备注 | |---|---|---| | `223274` | **已使用** | 活动 DPF 再生进度，0–100%。本项目所需的关键 DID。 | | `223275` | **已使用** | DPF 碳载量 %，0–100%。在活动再生期间冻结，燃烧结束后更新。 | | `223277` | **已使用** | 自上次再生以来的里程 (km)。在活动再生期间也会冻结，结束后重置为 0。 | | `010C` *(Mode `$01`)* | 确认可用，未使用 | 发动机转速 (RPM)。保留为禁用的调试探针，受 `SCAN_EXTRA_DIDS` 控制。 | | `012F` *(Mode `$01`)* | 确认可用，未使用 | 燃油液位 %。保留为禁用的调试探针，受 `SCAN_EXTRA_DIDS` 控制。 | | `223271` | 已识别，未使用 | 始终读取为 `0x00`，包括在真实的再生过程中 — 其本身不是一个有用的信号。 | | `223272` | 已识别，未使用 | 恒定为 ~`0x03`。 | | `223273` | 已识别，未使用 | 数值偏低且充满噪声；与发动机负荷呈弱相关性。 | | `223276` | 已识别，未使用 | 缓慢增加，不受再生影响 — 可能是无关的计数器。 | | `223278`, `223279`, `22327A` | 已识别，未使用 | 基本恒定。 | | `22327B` | 已识别，未使用 | 与负荷/RPM 相关 — 可能是压力或流量读数。 | | `22327D`, `22327F` | 已识别，未使用 | 大多为 `0x00`。 | | `223270`, `22327C`, `22327E` | 确认不支持 | 在此 ECU 上始终返回 NRC `0x31` (请求超出范围)。 | | `2220F8`, `2220FD` | 确认不支持 | 可信度较低的第三方猜测；测试中始终返回 NRC `0x31`。 | 上面“已识别，未使用”的 DID 都会在该 ECU 上响应*某种内容*，但并未被确认具有具体含义，且在 DPF 监控中不需要它们，因此从未被引入固件。**这里列出它们，是为了方便任何想要深入挖掘并添加屏幕以显示更多车辆实时数据的人** — 欢迎提交 pull request。 ## 开发历史 按时间顺序的总结，从最早的工作草图到当前的模块化固件（完整细节请参见提交/备份历史）： 1. **第一个工作草图。** ESP32 + SSD1306 + Wi-Fi ELM327，以原始 AT 透传方式通信 Mode `$22`。确认 DID `223275` (碳载量%) 和 `223277` (自再生以来的里程) 可用。此时尚未进行再生检测。 2. **添加 DID 扫描。** 调试扫描模式探测已知可用集群旁边的 `3270`–`327F` 范围，寻找 EGR/排气温度/活动再生相关的 DID。 3. **延长驾驶 + 记录会话。** 记录了多次真实驾驶过程（包括仅怠速和多次出行会话），以排除错误候选：证实 `3270`/`327C`/`327E` 在驾驶、怠速*以及*在真实再生之后立即进行的持续轮询中均不支持 (NRC `0x31`)；证实 `3271` 恒定。在继续搜索期间，采用“碳载量下降”的启发式方法作为临时的“正在再生”替代指标。 4. **确认再生 DID。** 在 2026-07-08 至 2026-07-14 之间，其中一次会话捕获了完整的再生过程，日志分析证实 `223274` 即为活动再生进度 DID。 5. **燃烧率% 重构。** 将“碳载量下降”启发式算法替换为直接读取 `223274`，并增加了 `RegenEvent::Started`/`Ended` 边缘检测和开始/结束蜂鸣器提示。 6. **模块拆分。** 将单文件草图拆分为 `ElmDataProcessing` (适配器/协议)、`Display` (LED) 和 `DataLogging` (Serial/SD 调试输出) 模块，`main.cpp` 则被精简为仅负责编排连接生命周期。 7. **再生界面。** 为活动再生添加了带有实时进度条的专用 OLED 界面，取代了原有的纯状态文本。 8. **清理工作。** 在发布此仓库之前，对所有模块的注释和结构进行了全面整理。 ## 路线图 - **强制再生按钮。** 下一个计划的功能是添加一个按钮，用于从 OLED 设备本身请求手动/强制的 DPF 再生。这需要专业诊断工具在 EDC17C59 上触发该操作所使用的 UDS 例程/服务（及其确切参数）— 这首先需要从支持该功能的真实诊断会话中**抓取流量**，然后才能在固件中复现。如果你可以使用能够在此 ECU 上强制执行再生的专业诊断工具，并且能够捕获该通信数据，请联系我们或提交 issue。 - 将一个或多个 [“已识别，未使用”](#did-reference-for-this-ecu)的 DID 接入到第二个信息显示屏幕中。 - 在功能集稳定后推出专用 PCB。 - 重新评估对蓝牙 ELM327 的支持（参见 [为什么选择 ESP32？](#why-esp32)）。 ## 快速开始 1. 安装 [PlatformIO](https://platformio.org/)（独立版本或 VS Code 扩展）。 2. 克隆此仓库。 3. 在 [`platformio.ini`](platformio.ini) 中编辑 `build_flags` 以适应你自己的设置： -D WIFI_SSID='"V-LINK"' ; 你的 ELM327 适配器的 Wi-Fi SSID -D WIFI_PASS='""' ; 其 Wi-Fi 密码（通常为空或 "1234"） -D OBD_IP='"192.168.0.10"' ; 适配器的 IP 地址 -D OBD_PORT=35000 ; 适配器的 TCP 端口 -D BUZZER_PIN=4 ; 驱动蜂鸣器/LED 的 GPIO 4. 构建并烧录： pio run -t upload pio device monitor ## 许可证 基于 **[PolyForm Noncommercial License 1.0.0](LICENSE)** 授权。 简而言之：出于任何非商业目的（个人使用、业余爱好构建、研究、教育），均可免费使用、复制、修改和分享。商业用途 — 包括出售本项目、其衍生品或基于它的产品 — 需要获得作者的事先书面许可。 ## 致谢 - [ELMduino](https://github.com/PowerBroker2/ELMduino) 提供的 ELM327 接口支持。 - [ThingPulse 用于 SSD1306 显示屏的 ESP8266 和 ESP32 OLED 驱动程序](https://github.com/ThingPulse/esp8266-oled-ssd1306)。 - 在 DID 逆向工程过程中，使用了 Claude (Anthropic) 作为分析工具（参见 [调试日志系统](#debug-logging-system)）。

标签：ELM327, ESP32, OLED, 云资产清单, 嵌入式硬件, 汽车诊断, 物联网, 逆向工程