星核火花赛车科技

标签： 车型协议

  • Strym 工具链：Toyota RAV4 / CHR 与 Honda Pilot 的 CAN 记录与可视化

    结论：Strym 不是一个「某台车的信号表」，而是一套围绕 comma.ai Panda 与 Giraffe 连接器的 CAN 数据记录、分析与可视化工具链，文档把它的适用车型举例为 Toyota RAV4、Toyota CHR 与 Honda Pilot。它能做的是：把 OBD 口采到的原始帧按 DBC 解码成时间序列，再用 isoviz／isolog 实时绘图或离线分析。关键边界在于——真正的信号定义来自外部 DBC 文件（示例引用 newToyotacode.dbc），源文档并未附上逐信号解码表，因此不能据此列出任何一台车的具体信号清单。

    本文整理自该工具项目的说明文档。它记录的是「数据怎么进、怎么出」的管线，而不是某个车型的字段含义；下文严格区分「文档已说明的工具能力」与「文档未给出的车型信号定义」。

    车辆与适用范围

    源文档以举例方式列出可用车型，并说明其数据形态是「Panda 与 Giraffe 采到的时间序列」。文档给出的示例 CSV 文件名包含一个 RAV4 的 VIN，但它没有标注年款、市场版本或具体配置，也没有针对任一车型给出字段验证结论。

    项 内容
    车型 文档举例：Toyota RAV4、Toyota CHR、Honda Pilot（表述为「supported modern vehicles such as …」）
    年款 / 市场版本 源文档未确认；示例 CSV 文件名含 VIN 2T3MWRFVXLW056972，未标注年款
    ECU / 改装状态 由 comma.ai Panda USB-CAN 板配合 Giraffe 连接器接入车辆 OBD 口采集
    采集跨度 源文档未给出；示例为一段 CSV 记录
    适用范围 工具能力层面；不含任一车型的逐信号定义与验证

    总线与寻址

    文档只说明数据经 Panda 与 Giraffe 从 OBD 口进入主机，并由 DBC 文件解析消息。它没有给出物理层速率、11 位 / 29 位寻址、CAN FD 是否存在等链路层细节，也没有描述 OBD 口后是否存在网关。这些都属于源文档未覆盖项，本文不补。

    项 内容
    物理层 经 comma.ai Panda + Giraffe 从 OBD 口采集（源文档未给速率）
    链路层 源文档未给出
    寻址 源文档未给出 11 位 / 29 位结论
    CAN FD 源文档未提及
    消息定义来源 外部 DBC 文件（示例引用 newToyotacode.dbc）

    已解码信号

    源文档是工具项目，没有提供逐信号的解码表；信号含义由外部 DBC 决定，而该 DBC 内容未收录在文档中。下表只列出文档中可确认的可解码对象与数据通路，每条的证据都指向工具说明本身，而非某台车的实测。

    条目 位置（来源 / 入口） 解码 / 处理 证据
    消息类型 SPEED DBC newToyotacode.dbc；示例属性号 1 作为 isoviz / isolog 的「消息类型 + 属性号」入参 源文档示例代码
    车速时间序列 strymread(file).speed() 返回速度数据框（DataFrame） 源文档「快速开始」
    时间列 Time CSV 第 1 列（Unix 秒） 解析为 Pandas DataFrame 的时间列 源文档格式表
    数值列 Message CSV 第 2 列 解析为 DataFrame 的数值列 源文档格式表
    车型 Toyota RAV4 支持车型举例 由 Panda + Giraffe 接入 OBD 采集 源文档
    车型 Toyota CHR 支持车型举例 同上 源文档
    车型 Honda Pilot 支持车型举例 同上 源文档
    DBC 解码 cantools 库 按 DBC 消息定义解码原始帧 源文档依赖与示例
    实时可视化 isoviz() 边采集边绘制目标信号，同时写 CSV 源文档示例
    离线分析读入 strymread(csvfile, dbcfile) 读 CSV + DBC 后调用分析方法 源文档快速开始

    读取方法与注意事项

    输入形态。文档规定工具期望的时间序列是两列 DataFrame：Time（Unix 时间戳）与 Message（数值）。文档特别说明，虽然默认来源是 Panda，但任何符合该两列格式的时间序列都可以使用这套方法，因此它的处理对象是「规整后的时间序列」，不是原始帧本身。

    实时与离线两条路径。实时路径用 isoviz()：它按「消息类型 + 属性号」指定要看的信号，一边把 CAN 消息写进 CSV，一边绘制该信号；按 Ctrl-C 触发 SIGINT 处理，结束记录并把图分别保存为 pdf 与 pickle。离线路径先用 strymread() 读入 CSV 与 DBC，再调用具体分析方法（例如 speed()）。

    工程条件。文档列出的软件要求是 Ubuntu 20.04 或更高、Python 3.12 与 UV 包管理器；硬件要求是 comma.ai Panda 板、Giraffe 连接器与一台带 CAN 总线的现代车辆。若在树莓派上安装，文档建议从源码装 Python 3.7，并预先准备 NumPy 的预编译二进制，否则构建会比较麻烦。以上都是源文档给出的操作条件，本文未在实车上复核。

    证据等级与边界

    源文档是工具说明，没有为任何字段标注置信度或证据等级，也没有给出原始 CAN 抓包或实车验证结论。它唯一带有「实测」色彩的内容是一段示例 CSV 与一段示例 DBC 的引用，二者都只是用法演示。

    因此边界很明确：第一，本文列出的信号条目只是「文档说明的处理对象与数据通路」，不代表任何车型的真实字段含义；第二，真正的信号定义在外部 DBC 里，而该 DBC 未被收录，无法据本文列出某一台车的信号清单；第三，支持车型是文档的举例表述，其年款、配置与协议细节均未确认。任何字段级结论都不能从工具文档外推到具体车辆。

    常见问题

    Strym 支持哪些车型？

    源文档以举例方式写出 Toyota RAV4、Toyota CHR 与 Honda Pilot，并说明适用对象是「带 CAN 总线的现代车辆」。它没有给出完整的支持清单，也没有标注每款车的年款与配置，本文不据此扩展。

    它能直接给出某台车的信号清单吗？

    不能。该项目的信号含义来自外部 DBC 文件，示例引用的是 newToyotacode.dbc，而源文档没有收录该文件内容，也没有逐信号解码表。它提供的是「用 DBC 解码」的工具能力，不是现成的车型字段表。

    它的数据格式是什么？

    文档规定核心输入是两列 Pandas DataFrame：Time（Unix 时间戳）与 Message（数值）。符合该格式的时间序列都能使用这套方法，不一定非得来自 Panda。

    这套工具能替代某台车的协议分析吗？

    不能。它负责记录、解码与可视化，协议与字段含义由外部 DBC 决定。要判断某台车的字段，仍需以该车自己的 DBC 与实测为准，本文不把工具文档当作车型结论。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/jmscslgroup-strym/README.md（本项目车型档案唯一来源；取用了支持车型举例、两列数据格式与 isoviz/strymread 工作流）。

    说明：本文整理自第三方开源项目的公开文档，仅代表该文档所记录的单个车辆样本，不代表同型号全系车型。CAN 与诊断操作存在风险，任何实车操作前请自行复核并遵守当地法规。

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11

  • BMW E46 PT-CAN 数据档案：MS42/MS43 的 500 kbps 报文表

    结论：BMW E46 的 PT-CAN 是一张没有加密、没有网关隔离的广播总线：500 kbps、11 位 ID、DLC=8，DME、DSC、IKE、转向角传感器和（选装）变速箱都在这张网上直接广播，被动监听即可解码转速、水温、车速、四轮速、转向角、制动压力、挡位、里程与油量等信号。它的典型难点不在「能不能抓」，而在同一份 ID 在 MS42（M52TU）与 MS43（M54）上字节位置不同：源文档明确标注 MS42 的字节位置是从 MS43 文档抄来的、仍需真实抓包验证。下述结论仅限源文档记录的这一套 DME+DSC+IKE 组合。

    车辆与适用范围

    源文档是一份开源车载仪表项目为 E46 机箱写的 CAN 参考，信号表的权威来源是公开的 MS4X 维基，项目自述其解码表「逐字节镜像维基表格」。项目本身处于早期（README 自述 Early），只覆盖 E46 的 PT-CAN 一张网。

    项 内容
    车型 BMW E46，覆盖 M52TU（MS42）与 M54（MS43）两种 DME
    年款 / 市场版本 源文档未给出具体年款与市场版本，只按 DME 区分 M52TU / M54
    ECU / 改装状态 DME（MS42/MS43）、MK60 / DSC III ABS、IKE 仪表、转向角传感器、可选 EGS 自动变速箱；使用 SLCAN 适配器被动监听，不改线束
    采集跨度 源文档未给出日志数或帧数；DBC 侧记载 MS42 文件 11 条报文、102 条信号，MS43 文件 11 条报文、108 条信号
    适用范围 仅限文档所记录的 MS42/MS43 + DSC + IKE 组合；具体年款、动力总成、ABS 版本与配置须自行核对

    总线与寻址

    源文档明示 PT-CAN 运行在 500 kbps、11 位 ID、DLC=8。多字节整数都注明端序；位位置写成 B<字节>.<位>，位 0 是 LSB；百分比缩放的规范系数是 BMW 的 0.390625 = 100/256。有一点很关键：项目只做广播帧的监听与解码，明确不做诊断协议（无 DS2、无 UDS、无 EDIABAS）。

    项 内容
    物理层 双绞线 CAN，PT-CAN（动力总成 CAN）
    链路层 / 比特率 500 kbps（源文档明示）
    寻址方式 11 位 ID，DLC=8
    CAN FD 否；源文档按经典 CAN（8 字节载荷）处理
    端序约定 绝大多数报文为 Intel/小端；LWS1（0x1F5，转向角）为 Motorola/大端
    不做的事 不含诊断协议；电池电压不在 PT-CAN 广播，只能走 DS2 诊断

    已解码信号

    下表从源文档的信号表中抽取代表性条目。MS43 独有或与 MS42 位置不同的信号单独标注；源文档标注「未验证」「无外部旁证」的条目按原样保留。

    信号 位置（ID / 字节 / 位） 解码 证据
    转速 N_ENG 0x316 DME1，B2-B3 小端 × 0.15625 rpm MS4X 维基 0x316 页
    指示扭矩 TQI_CAN 0x316，B4 × 0.390625 % MS4X 维基 0x316 页
    冷却液温度 TEMP_ENG 0x329 DME2，B1 × 0.75 − 48 → °C MS4X 维基 0x329 页
    油门踏板 TPS_CAN 0x329，B5 × 0.390625 % MS4X 维基 0x329 页
    车速 VSS 0x153 ASC1，13 位（B1.3-7 + B2） ((MSB×256+LSB − 0x160) × 0.0625) km/h 维基公式；源文档指出维基公式与「最小值 0x160」不自洽，解码器补了偏移并钳位到 ≥0
    四轮车速 0x1F0 ASC2，B0-B7 小端（每 2 字节一轮） (raw − 44) / 15.875 km/h MS4X 维基 0x1F0 页；raw 最小 0x002C=44 对应 0
    转向盘转角 ANG_PSTE 0x1F5 LWS1，B0-B1 大端 有符号 × 0.04394° 维基页；源文档指出维基把量表四舍五入，真实系数约 0.04395，解码器仍用维基系数
    转角角速度 VEL_ANG_PSTE 0x1F5，B2-B3 大端 有符号 × 0.04394 °/s MS4X 维基 0x1F5 页
    制动压力 P_BRAKE 0x1F8 ASC4，B2 × 1 bar（0–255） MS4X 维基 0x1F8 页
    纵/横向加速度 AX_REF / AY_REF 0x1F3 ASC3，10 位有符号原始值 维基未给缩放；界面按 10 位有符号原始值呈现 MS4X 维基 0x1F3 页（无缩放公式）
    挡位 GEAR_INFO 0x43F EGS1，B0.0-2 3 位枚举（0=N，1-6 前进挡，7=R） MS4X 维基 0x43F 页
    里程 KM_CTR_CAN 0x613 ICL2，B0-B1 小端 × 10 → km MS4X 维基 0x613 页
    油量 FTL_CAN 0x613，B2.0-6 7 位原始值（仪表映射到刻度） MS4X 维基 0x613 页
    机油温度 TOIL_CAN 0x545 DME4，B4（MS43 独有） raw − 48 → °C MS4X 维基 0x545 页；MS42 不广播此字节
    油面高度（MSS54HP） 0x545，B6（MS43 独有） (raw − 158) / 10 → L MS4X 维基 0x545 页

    读取方法与注意事项

    第一是端序陷阱：源文档特别提醒 Intel/小端的 start bit 是 LSB，而 Motorola/大端的 start bit 是 MSB，两者在同一个字节里所指的位完全不同。E46 上除 LWS1 转向角外都是 Intel，LWS1 是唯一的 Motorola 报文，混用会解出错误数值。

    第二是 MS42 / MS43 的字节错位：源文档用一整节列出 DME 发送帧里两种 DME 把信号放在不同位置的条目。例如 TQI_MAF_CAN 在 MS43 位于 DME1 的 B7、在 MS42 位于 B6；机油温度、换挡提示、机油压力低、胎压、机油液位等一串信号在 MS42 上根本不广播。源文档据此为 MS42 做了一个去掉 MS43 专有信号、并重定义 TQI_MAF_CAN 与 ERR_AMT_CAN 字节位置的配置。

    第三是维基公式的已知瑕疵。车速那条，维基同时给出「公式 = ((MSB×256)+LSB) × 0.0625」和「最小值 0x160（0 km/h）」，两者只有在先减偏移再缩放时才自洽；解码器选择减去 0x160 并钳位到 ≥0，让静止车读 0。转向角那条，维基把量表取整到 5 位有效数字（0.04394），真实系数约为 0.04395，量程末端会有约 0.2° 偏差。

    第四是取值语义：源文档规定解码器只在「该帧本就不携带该信号」时（多路复用场景）返回空值，绝不把「数值未知」编码成空值——那是仪表该处理的事，不是解码器的职责。

    证据等级与边界

    可视为外部旁证的是各条 ID 对应的维基页面，项目自述解码表与维基表格逐字节一致；这属于公开文档级证据，不等同于本项目自己的实车复现。属于明确不确定性的是 MS42：维基 MS42 页自己写了「数值抄自 MS43 页，需验证」，因此 MS42 专有的字节位置在真实抓包确认前应视为暂定。

    不能外推的地方有两处。第一，可选装件会改变报文存在性：EGS 自动变速箱、SMG 变速箱、MSS54 相关信号只在对应配置上出现，源文档明确把 0x338 DME3、0x43D AMT1、0x445 TXU1、0x610 ICL1 列为「未解码」，理由分别是赛道化选装、缺真实 SMG 抓包、维基页为空、以及对 VIN 远程帧只做被动监听。

    第二，本文所有条目都绑定 E46 PT-CAN 这一张网与文档所列 ECU 组合，不能套到其他宝马机箱或其他总线（例如诊断总线）。电池电压这条尤其要记住：源文档写明它不在 PT-CAN 由任何已记录的 DME 广播，只能通过 DS2 诊断获得，所以「在广播流里找电池电压」在这台车上找不到。

    常见问题

    E46 的 OBD 口能直接抓到这些信号吗？

    源文档记录的是 PT-CAN 广播帧的监听与解码，总线为 500 kbps、11 位 ID。它明确不做诊断协议（无 DS2、无 UDS、无 EDIABAS），也不保证从标准诊断适配器（如只透传 ISO-TP 请求/响应的电缆）能拿到广播帧；实际取数用 SLCAN 适配器被动监听。

    为什么同一条 ID 在 MS42 和 MS43 上解码结果不同？

    因为源文档列出了一串信号在两种 DME 上位于不同字节：例如 TQI_MAF_CAN 在 MS43 是 DME1 的 B7、在 MS42 是 B6，机油温度等信号 MS42 直接不广播。项目为此为 MS42 单独定义了一套配置。

    车速解码为什么要先减 0x160？

    因为源文档指出维基的公式与「最小值 0x160 对应 0 km/h」不自洽，只有在缩放前减去该偏移才能让静止车读 0；解码器据此补了偏移并钳位到 ≥0。

    电池电压能从总线上读到吗？

    不能。源文档写明电池电压不在 PT-CAN 由已记录的 DME 广播，只能通过 DS2 诊断获得。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/emdzej-dashx-e46/docs/bmw-e46-can-ids.md（主来源：E46 PT-CAN ID 与逐字节信号表）。
    • 项目 01 —— public-can-dbc-datasets/additional/emdzej-dashx-e46/docs/vehicle-overlays.md（DBC + overlay 表达方式与端序/复用说明）。
    • 项目 01 —— public-can-dbc-datasets/additional/emdzej-dashx-e46/SOURCE.md（快照范围、DBC 信号条数与适用范围提示）。

    说明：本文整理自第三方开源项目的公开文档，仅代表该文档所记录的单个车辆样本，不代表同型号全系车型。CAN 与诊断操作存在风险，任何实车操作前请自行复核并遵守当地法规。

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11

  • 丰田 RAV4 TSS2 雷达 ARS510：0x80 对象列表与 0x85 元数据

    结论：在一辆车主自有的 2022 款丰田 RAV4（TSS2，前向雷达固件 8821F0R03100，雷达在 0x750/0x0f）上，ARS510 前向毫米波雷达的对象列表是可以被动解码的广播数据：它走雷达总线，以 0x80 分 106 帧拼成一条 742 字节记录，每个对象槽 36 字节，直接给出纵向距离、横向偏移、对地速度、车道权重和类别。这个结论只覆盖这一辆车这一次固件记录——文档明确把「字段比例与零点」标为名义值、多处置信度存疑，不能外推到 RAV4 其他年款或其他雷达固件。

    本文整理自一份针对这台车雷达的开源解码与集成文档。该文档把「原始解码」「物理量校准」「实车结论」分层标注，本文保留这套分级，不将其拔高为「RAV4 全系通用」。

    车辆与适用范围

    数据来自一位车主的一辆 2022 RAV4，用 openpilot 记录。文档给出的证据结构是：3 段参考行程（开发、城市、高速，共 88 分钟）带摄像头与里程计参照；24 段行程中的 399 个一分钟片段用于字段统计；20 段留出行程（4.6 小时）做回放对照；6 段新行程（1.9 小时）与多套分支上的闭环路测。

    项 内容
    车型 丰田 RAV4（TSS2，对应 openpilot 的 2022 / 2023 平台标识）
    年款 / 市场版本 2022（源文档未给出销售市场，也未确认具体配置）
    ECU / 改装状态 前向雷达固件 8821F0R03100；由 openpilot 采集，非量产改装
    采集跨度 3 段参考 88 分钟 + 399 个一分钟片段（来自 24 段行程）+ 20 段留出 4.6 小时
    适用范围 仅这一辆车的雷达与这一次固件；比例与零点多为名义值

    总线与寻址

    文档按 openpilot 的总线编号描述器件：雷达本身与其 ACC 目标帧在 bus 1，车速来自 bus 0 的车体帧 0xB4。对象列表在 bus 1 的 0x80，以 106 帧拼成一条 742 字节记录：头部、20 个 36 字节对象槽、一个 CRC32。雷达周期约 60 毫秒，解码后以约 16.7 Hz 输出对象点。

    文档没有描述这台车的 OBD 口之后是否存在网关，也没有给出 11 位 / 29 位寻址或 CAN FD 的结论——这几项属于源文档未覆盖的范围，本文不补。

    项 内容
    物理层 车用 CAN，分为雷达总线（bus 1）与车体总线（bus 0）
    链路层 对象列表 0x80 分帧传输（106 帧 → 742 字节记录）
    寻址 源文档未给出 11 位 / 29 位结论
    CAN FD 源文档未提及
    记录完整性 CRC32/ISO-HDLC（小端）覆盖记录第 1 至 140 字节

    已解码信号

    下表从源文档的对象槽与 0x85 元数据记录中抽取代表性字段。置信度沿用文档符号：● 已确认、◐ 可能、○ 候选。位宽写法如 32|12 表示起始位 32、宽 12 位。

    信号 位置（ID / 位域） 解码 证据
    dRel（纵向距） 0x80 槽 32|12 (code − 160) / 16 米 ● 字段布局确认；零点与比例见准确度文档
    yRel（左为正横向偏移） 0x80 槽 44|12 (code − 2048) / 64 米 ● 同上，比例标称 ±10%
    对地速度 0x80 槽 64|10 (code − 510.5) × 0.15 米/秒；相对速度 = 该值 − 自车速度 ● 运动解释确认
    age（航迹年龄） 0x80 槽 24|7 雷达周期数；重启即视为新航迹 ●
    车道权重（右 / 左 / 自车） 0x80 槽 148|4、152|4、156|4 0–15，三者之和为 15 或 16 ●
    类别 class 0x80 槽 163|3 1 新建、2 车、3 大型车、4 行人、5 暂定、6 两轮车 ●；5 为 ○ 候选
    ACC 目标 0x235 / 0x237，50 Hz 原始字段 ● 原始字段；◐ 名义单位换算
    目标摘要 0x191–0x194 原始结构 ● 原始结构；◐ 解释，需度量与类别校准
    事件对 0x195 / 0x196 原始载荷；10 位短时距碰撞码领先本车减速 ● 原始载荷；◐ 状态解释
    元数据 c0 偏移 0x85 单元 32|12 (code − 2000) × 0.01 米 ◐ 比例约 ±10%
    元数据 c1 航向 0x85 单元 48|16 −1.8e-5 × (code − 31200) 弧度/码，零点 31100–31300 ◐ 符号与零点；单位有界 1.6–2.2e-5
    元数据 c2 曲率 0x85 单元 64|15 +2.5e-6 × (code − 16020) 1/米/码 ◐ 符号与零点；单位有界 2.0–2.7e-6
    元数据 c3 曲率变化率 0x85 单元 10|10 +4e-6 × (code − 500) 1/米²/码 ◐ 符号、零点；单位仅到量级

    读取方法与注意事项

    拼接与校验。0x80 记录按 106 帧重组后，用 CRC32/ISO-HDLC（小端）校验；0x85 记录的 147 字节同样按 21 帧重组成，CRC32 覆盖第 1 至 140 字节。文档报告自带样本与七份完整日志的全部记录均通过校验。

    配对要按计数器，不要按到达时间。0x85 前缀与 0x80 头部共享一个时钟和记录计数器；用「最近的到达时间」配对，约有三分之一的机会会配到相邻周期，因此文档要求按计数器配对，并报告在 28 段行程、446371 组配对中覆盖了超过 99.96% 的 0x80 记录。

    速度外溢是这套解码目前最大的问题。文档记录了一个缺陷：出现 1 至 10 秒的假接近，距离超过 40 米。默认的 anchor 配置用雷达自车 ACC 目标给前车速度加界，并叠加 steady 的护栏与平滑；两者合起来在 20 段留出行程上把硬假刹车从 93 个 tick 降到 48 个 tick，响应时间不变。文档另给出 steady（不含 ACC 目标）与 stock（纯解码，外溢直达规划器）两个配置。

    证据等级与边界

    文档用 ●／◐／○ 三级标注：● 已确认、◐ 可能、○ 候选。所有比例与零点都被写明是名义值。也就是说，「(code − 160) / 16」这类公式是文档给的标称关系，并非经独立测量标定的绝对定标。

    另一层边界在来源：全部统计都出自这位车主这一辆车、这一次雷达固件与这批日志。车道单元的分配、航向与曲率的相关性、以及与摄像头车道线的中位误差，都只在记录范围内成立；据此，任何字段含义与比例都不能外推到其他 RAV4、其他年款或其他固件版本。

    常见问题

    这辆 RAV4 的雷达对象列表，能从 OBD 口直接读吗？

    源文档没有涉及 OBD 口这一层，它只按 openpilot 的总线编号给出「雷达在 bus 1、车速在 bus 0」。OBD 口之后是否存在网关、能否直达雷达总线，文档未记录，本文不据此下结论。

    为什么对象列表和 0x85 要按计数器配对，而不是按到达时间？

    因为两条记录的时间戳邻近，用「最近到达时间」配对约有三分之一的机会会配到相邻周期，把不同周期的对象和车道曲线混在一起。文档改用共享的时钟与记录计数器配对，并在 28 段行程、446371 组配对中把覆盖提高到 99.96% 以上。

    文档里说的「速度外溢」是什么，怎么缓解？

    它是这套解码目前最大的已知缺陷：在 1 至 10 秒窗口内出现距离超过 40 米的假接近。默认 anchor 配置用雷达自车 ACC 目标给前车速度加界，叠加 steady 的护栏与平滑，在 20 段留出上把硬假刹车从 93 降到 48 个 tick，响应不变；stock 配置不做过滤，外溢会直达规划器。

    这些字段比例与零点，能套到别的 RAV4 或其他年款吗？

    不能。比例与零点在源文档里都是名义值，全部结论只覆盖这一辆车、这一次固件与这批日志。其他年款、其他雷达固件是否一致，文档未验证。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/toyota-ars510-radar-48b9508/README.md（本项目车型档案主来源，取用了对象列表与总线的总体结论）。
    • 项目 01 —— public-can-dbc-datasets/additional/toyota-ars510-radar-48b9508/docs/04_metadata_record_0x85.md（取用了 0x85 记录的布局、配对规则与车道边界单元字段）。

    说明：本文整理自第三方开源项目的公开文档，仅代表该文档所记录的单个车辆样本，不代表同型号全系车型。CAN 与诊断操作存在风险，任何实车操作前请自行复核并遵守当地法规。

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11

  • Fisker Ocean 2023-24 的 ADASBUS：单总线取数与 92 个地址

    结论：这台 Fisker Ocean 2023-24 的 CAN 数据特征不是「OBD 口后面有没有网关」，而是整车信号被网关镜像到一条 ADASBUS 上：只需要接一条 CAN-FD 总线就能读到车身与 HMI 信号。源文档记录，panda 以摄像头转接线束插在原车网关侧（bus 0）与 OEM ADAS 模块侧（bus 2）之间，bus 1 未使用；bus 0 一次实车指纹抓取到 92 个地址（网关镜像的车身/HMI 加上 ESP、EPS、YRS、BCM、VCU、MFS、ICC），bus 2 约 65 个地址且全部由 ADAS 发出。下述结论仅限源文档记录的这一台车与 2023-24 年款，不代表同型号全系。

    车辆与适用范围

    源文档是一份开源 ADAS 项目里的车型平台定义，属于单车型移植（single-model port），不是车厂或第三方机构的批量采集。文档明确说明固件版本指纹被故意留空，识别以 CAN 指纹为准，因此「适配到哪一台车」由这一次实车抓包决定。

    项 内容
    车型 Fisker Ocean 2023-24（源文档记为 Ocean Extreme 整备质量口径）
    年款 / 市场版本 2023-24；市场版本源文档未确认
    ECU / 改装状态 摄像头转接线束（camera-splice harness）；panda 接在车辆侧网关与 OEM ADAS 模块之间；bus 1 未使用
    采集跨度 源文档只写「来自一次实车指纹抓取（live fingerprint capture）」，未给出日志数或帧数
    适用范围 仅限该次抓取的一台 2023-24 Ocean；轴距、方向盘比、轮胎刚度等车辆模型参数仍标注为待阶跃响应日志复核

    总线与寻址

    源文档把总线分成两侧：车辆侧（bus 0）与 OEM ADAS 模块侧（bus 2）。因为网关把车身/HMI 信号镜像到同一条总线上，移植只需要接一条总线；bus 1 在代码里被标为未使用。报文 ID 都是 11 位，ADAS 侧除固定报文外还有一段雷达目标列表。

    项 内容
    物理层 CAN-FD 双绞线；源文档注明 ADASBUS 为 CAN-FD
    链路层 / 比特率 源文档未给出比特率数值
    寻址方式 11 位 ID，例如 0x117、0x118、0x121、0x1C0、0x1D0、0x313、0x314、0x315、0x316、0x317、0x31A、0x31C
    总线划分 bus 0 = 车辆侧（网关镜像）；bus 2 = OEM ADAS 模块侧；bus 1 未使用
    CAN FD 是；源文档按 CAN-FD 处理
    SecOC 0x1D0 与 0x121 受 SecOC 保护；同步报文 0x20 GW_Syn_All，50 ms，线上 40 位 freshness

    已解码信号

    下表只登记源文档里带证据或明确标注状态的条目。挡位枚举与按键映射直接来自平台定义中的 DBC 值表与按键映射表；转向与加速度指令给出缩放与周期，但周期条目原文标注为「需从日志确认」。雷达目标只给 ID 区间，未给字段定义。

    信号 / 功能 位置（ID / 来源） 解码 证据
    挡位 VCU_GearSig 网关镜像到 bus 0 的 VCU 报文 枚举 1=P、2=N、3=R、4=D、6=E、7=S 平台定义 DBC VAL_ 注释
    转向角指令 ADAS_LatCtrl_SteerAnReq 0x1D0（ADAS 侧） 0.0625°/LSB，量程 ±780°；周期 10 ms（≈100 Hz），原文标注需从日志确认 平台定义注释
    加速度指令 ADAS_LgtCtrl_AccelReq 0x121 0.0004882 m/s²/LSB，偏移 −16 平台定义注释
    驾驶员转向力矩 EPS_DrvrSteerTq 网关镜像的 EPS 报文 0.01 Nm/LSB；驾驶员接管阈值 0.5 Nm 平台定义注释
    巡航主开关 MFS_RiBtnNorth MFS（方向盘多功能开关） 映射为 mainCruise（ADAS 总开关） 按键映射表
    巡航设定 MFS_LeRollPress MFS 映射为 setCruise（接合巡航） 按键映射表
    加速 / 减速 MFS_LeRollUp、MFS_LeRollDwn MFS 映射为 accelCruise / decelCruise 按键映射表
    LKAS 开关 MFS_RiBtnSouth MFS 映射为 lkas 按键映射表
    取消 / 恢复 / 车距调节按键 MFS 源文档标注为 TBD（待台架测试确定） 按键映射表注记
    雷达目标列表 0x2C7…0x2E9（ADAS 侧） 源文档只给 ID 区间，未给字段定义 总线说明
    网关镜像的车身/HMI 信号 bus 0 挡位、踏板、车门、安全带、转向灯、MFS 按键 总线说明

    读取方法与注意事项

    第一条是取数路径：因为网关把车身/HMI 信号镜像到 ADASBUS，移植只接一条总线，摄像头转接线束让 panda 落在车辆侧网关与 OEM ADAS 模块之间。源文档强调 bus 1 未使用，因此不要把抓不到流量归因于「少接了一条线」。

    第二条是 SecOC：转向角指令与加速度指令在 ADAS 侧受 SecOC 保护，需要同步报文 0x20 GW_Syn_All 提供的 40 位 freshness，同步报文周期 50 ms。源文档说明这些数据 ID 在 AUTOSAR Short SecOC 口径下等于 CAN 报文 ID。任何只解析载荷、不做 freshness 校验的读取方式，都拿不到可信的指令值。

    第三条是周期：0x1D0 每个控制帧都发送，源文档把周期记为 10 ms（≈100 Hz），但同一行原文写了「需从日志确认周期」，因此本条保留不确定性，不作为实测结论。第四是识别：固件版本指纹被故意留空，品牌不参与固件版本匹配，CAN 指纹是唯一依据。

    最后是车辆模型参数：轴距按公布数据从 2.99 改成 2.921（源文档给出理由：原值让横向模型预期更慢的入弯、导致 MPC 在弯道入口过度指令转角），steerRatio 15.0 记为「first-cut」，tireStiffnessFactor 0.85 记为「crossover-typical」。这些都属待复核值，不应作为 Fisker Ocean 的通用参数。

    证据等级与边界

    可视为实车观测的是总线地址数量（bus 0 约 92 个、bus 2 约 65 个）与两侧总线的分工，它们来自一次实车指纹抓取；挡位枚举和按键映射来自 DBC 值表与映射表，属文档级证据。属于待复核或推测的是转向角周期、steerRatio、tireStiffnessFactor，以及取消/恢复/车距调节三个按键。

    不能外推的地方有三处。第一，源文档是单车型移植，固件指纹为空，挡位与按键映射只在这台车上被记录，其他年款、市场版本的报文布局未验证。第二，雷达目标列表只给了 ID 区间，字段含义未知，不能据此宣称读到了目标距离或速度。第三，车辆模型参数是工程首值，不是实测标定，换车即失效。

    关于「安全访问」类问题：源文档未提供任何绕过方法，且不建议尝试；本文只整理公开文档登记的广播信号与指令定义，不涉及对车辆安全机制的规避。

    常见问题

    Fisker Ocean 是从 OBD 口取数，还是接别的总线？

    源文档没有走 OBD 诊断口，而是接 ADASBUS：panda 以摄像头转接线束落在车辆侧网关（bus 0）与 OEM ADAS 模块（bus 2）之间。OBD 口在本车是否可读这些报文，源文档未给出结论，因此不能据此推断。

    为什么只需要接一条 CAN 总线？

    因为网关把车身/HMI 信号（挡位、踏板、车门、安全带、转向灯、MFS 按键）镜像到 ADASBUS 上，源文档说明移植只接一条总线即可；bus 1 未使用。

    转向角和加速度指令为什么不只解载荷？

    因为 0x1D0 与 0x121 受 SecOC 保护。源文档说明需要同步报文 0x20 GW_Syn_All（50 ms、40 位 freshness）才能得到可信指令值，只解析载荷不做 freshness 校验拿不到可信值。

    挡位信号在哪条总线上？

    挡位来自网关镜像到 bus 0 的 VCU 报文，源文档的 DBC 值表给出 1=P、2=N、3=R、4=D、6=E、7=S 的枚举。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/jos-technion-fisker-ocean/README.md（主来源：该项目保留的开源 ADAS 项目根文档）。
    • 项目 01 —— public-can-dbc-datasets/additional/jos-technion-fisker-ocean/opendbc/car/fisker/values.py（平台常量、总线划分、挡位与按键映射、SecOC 说明）。

    说明：本文整理自第三方开源项目的公开文档，仅代表该文档所记录的单个车辆样本，不代表同型号全系车型。CAN 与诊断操作存在风险，任何实车操作前请自行复核并遵守当地法规。

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11

  • 车型文档与线束清单：CarDocs、SupportType 与 CARS.md

    结论：车型支持文档系统是一条「car_docs → PLATFORMS/EXTRA_PLATFORMS → get_params_for_docs() → 品牌 init_make() + CarDocs.init() → 自然排序 → 两种 Markdown 输出」的生成链，它产出的是展示/采购文档，不是车型识别、上车认证或电气设计规范。三个状态必须分开：车型可展示、线束可购买、车型协议已识别、发布固件允许发送，CarDocs 与 SupportType 都不能直接授予 CAN 写入权。以下为固定提交 c8fb906 的静态阅读与隔离探针分析。

    数据与生成顺序

    get_all_car_docs() 汇合正常平台与 extra_cars.py 的额外目录，为每个平台调用 get_params_for_docs()，再对每个车型文档项依次执行品牌 init_make()、共同 CarDocs.init()，最后按自然顺序排序。一个平台可包含多个市场车型/年款条目，因而文档行数不等于车型接口数量。

    关键是 get_params_for_docs() 的输入：它以空 CAN 指纹、一个占位 CarFw、alpha_long=True、is_release=True、docs=True 调用车型 get_params()；额外目录中没有运行时接口的平台使用 MOCK 参数。这样的 CP 是排版/说明输入，既未验证目标车辆固件，也不代表该车能执行控制。

    阶段 入口 产出与边界
    数据汇合 car_docs + PLATFORMS + EXTRA_PLATFORMS 正常平台与额外目录合并，文档行数不等于车型接口数量。
    模拟参数 get_params_for_docs() 空指纹、占位 CarFw、alpha_long=True、is_release=True；无接口平台用 MOCK。
    品牌钩子 品牌 init_make() 品牌级展示字段调整为排版输入，非运行时 CP。
    共同派生 CarDocs.init() 计算 ACC、最低速度、自动起步、转向星级、支持级别与详情句；展示值可能被文档字段覆写。

    展示字段与派生逻辑

    split_name()、get_year_list() 从名称分离品牌、型号、年款并展开年款范围，依赖名称格式和 20YY 结束年推断，不是 VIN/车型年款校验器。CarDocs.init() 从 CP 和文档覆写计算展示列，其中 min_steer_speed、min_enable_speed 等可由文档字段覆写，展示值未必直接等于运行时 CP。

    CarDocs.init() 在 CP.dashcamOnly 且 merged=True 时通常把支持级别降为 DASHCAM，但 CUSTOM 和 REVIEW 是例外；ExtraCarDocs 默认 merged=False、INCOMPATIBLE，社区/安全限制类型由额外目录的子类钩子改写。SupportType 的 UPSTREAM、REVIEW、DASHCAM、COMMUNITY、CUSTOM、INCOMPATIBLE 是文档分类，不是运行时安全模式。

    线束清单以 Device.four 及常见附件为基础，品牌/平台可加入特定接头和工具；CarHarness 枚举包含摄像头/网关/OBD 类接头，并有 has_connector 展示标记。CarParts.common() 会加入默认设备并按 remove 列表过滤，但不做去重；递归展开也可能包含共享子件，数量显示在 CarDocs.init() 统计结果中。这些清单列出的是营销/采购名称，不含供电、针脚、隔离、保险丝或失效态参数。

    两种 Markdown 输出

    输出 入口 范围
    opendbc docs/CARS.md opendbc.car.docs.generate_cars_md() 对传入的全部条目构造简化列，包含不同 SupportType 的支持级别。
    openpilot docs/CARS.md openpilot.selfdrive.car.docs.generate_cars_md() 只筛 SupportType.UPSTREAM，生成 ACC/ALC/硬件/视频等宽表及脚注。

    两个生成器都是模板替换，作为 CLI 执行时会覆写各自的输出文件；get_all_car_docs() 和生成函数的注释明确说明它们也被外部网站调用，因此字段语义变化有仓库外消费者。openpilot 生成器的 _build_cars_table() 按 Column 枚举顺序取列，把 Hardware Needed 表头替换为含宽图片的 HTML 片段，前三列左对齐、其余居中。**kwargs 被直接丢弃，是兼容调用签名而非扩展参数。

    脚注按 get_all_footnotes() 映射的键迭代顺序重新编号，不使用映射值中的编号；只移除字面量 </br>，不移除 <br>。模板使用严格 Template.substitute()，未定义占位符会抛 KeyError。build_sorted_car_docs_list() 只在文档对象尚无 row 时初始化它；后续对同一内存对象再次生成时，已派生的行不会随新的 CP 或脚注参数自动重算。这是生成过程的状态边界，适合把文档项当一次性构建对象。

    对自制硬件与插件化的含义

    源文档给出的是一组建议而非现有代码已实现的保障：把「车型可展示」「线束可购买」「车型协议已识别」「发布固件允许发送」定义为四个不同状态，插件目录只展示已验证字段，不用 CarDocs 或 SupportType 直接授予 CAN 写入权；自制硬件物料表应另存电气契约（接头 pinout、线序、额定电流、供电/点火检测、隔离、ESD、保险与断电默认态），并逐车/年款验证，文档 CarParts 只能作高层采购提示；文档生成改为按版本快照纯计算，记录来自哪个 CarParams、DBC、固件数据库和硬件 BOM。

    测试与缺口

    opendbc 文档测试检查年款重复、命名、部分星级假设和上游线束清单；openpilot 生成器测试主要确认模板能生成。四项原函数隔离探针以临时模板和假 CarDocs 核对上游筛选、列顺序/对齐、调用参数、脚注编号与严格占位符；没有导入完整 opendbc，也未执行真实车型目录生成或覆写归档 CARS.md。这些测试不验证真实线束电气连接、商城库存、车型硬件兼容性或实际发布固件的执行能力。

    常见问题

    被列为 UPSTREAM 就等于该车型已获安全许可吗？

    不等于。SupportType 是文档分类而不是运行时安全模式；文档生成用的是带空 CAN 指纹与占位 CarFw 的模拟参数，不能直接授予 CAN 写入权。

    get_params_for_docs() 得到的参数能上车吗？

    不能。它以空 CAN 指纹、一个占位 CarFw、alpha_long=True、is_release=True、docs=True 调用车型 get_params()，是排版/说明输入，既未验证目标车辆固件，也不代表该车能执行控制。

    线束清单能当电气设计依据吗？

    不能。CarParts.all_parts() 列出的是营销/采购名称，不含供电、针脚、隔离、保险丝或失效态参数；自制硬件应另存电气契约并逐车/年款验证。

    为什么再次生成文档时行不刷新？

    因为 build_sorted_car_docs_list() 只在文档对象尚无 row 时初始化它，已派生的行不会随新的 CP 或脚注参数自动重算，这是生成过程的状态边界。

    延伸阅读

    参考资料

    • 项目 02 —— openpilot-research/CAR_DOCS_SUPPORT_HARNESS_DEEP_DIVE.md（生成顺序、展示派生逻辑、两种 Markdown 输出与测试缺口）。
    • 项目 02 —— openpilot-research/ 同目录平台参数与自制硬件方案专题（作为相邻边界参考）。

    说明：本文为对固定源码快照的静态结构分析，未运行完整测试套件、未连接硬件、未验证目标车型的真实参数组合。文中所有阈值、行号索引与配置均出自源文档，标注为未验证的结论保留其原有边界。

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11

  • Mercedes-Benz W212 仪表台：CAN E 状态图与唤醒帧

    结论：2010 款 Mercedes-Benz E350（W212）的组合仪表是一个可以单独上台架的 CAN 节点：20 针连接器里只有 7 针有关，接上 500 kbit/s 的 CAN E 就能点亮。源文档用「试验法」（逐位扫描观察仪表反应）找出了 0x001 的状态编码与唤醒帧，并把 CAN E 的上电状态整理成一张状态图。以下所有结论仅限源文档记录的这一个仪表台。

    车辆与适用范围

    本文数据来自第三方开源项目对一台 W212 E350 组合仪表的台架逆向记录。项目的目标是把这个仪表台用于模拟赛车，因此在台架上重建了它的供电与 CAN 环境，再逐条找出让它显示、点亮的报文。

    项 内容
    车型 Mercedes-Benz E350（W212），2010 年
    对象部件 组合仪表（cluster）；20 针 A1 连接器，其中只有 7 针有关：1 / 4 / 6 为供电，12 / 13 为 CAN E，17 / 18 为 CAN B
    台架硬件 Arduino Mega 2560 加 Seeed CAN-BUS Shield V2.0（MCP2515 控制器）；两个 120 Ω 终端电阻
    台架参数 500 kbit/s；MCP2515 晶振 16 MHz；串口 115200 baud
    适用范围 仅限源文档记录的这个仪表台；不适用于其他年款或其他配置的 W212

    总线与寻址

    因为是「只把一个仪表台搬上台架」，环境被大大简化：没有整车、没有网关，只有仪表自身与台架控制器之间的两条总线。

    项 内容
    总线 CAN E（引脚 12 / 13）、CAN B（引脚 17 / 18）
    速率 500 kbit/s
    终端 两个 120 Ω 电阻
    控制器 MCP2515（经 Arduino Mega 2560 驱动）
    ID 约定 源文档的 DBC 中消息 ID 记为十进制，使用前必须转成十六进制
    状态可读性 仪表上电后自身会发出若干帧（0x015、0x39D），可作为机器可读的状态指示

    已解码信号

    下表从源文档的记录中抽取。项目把已确认的编码与仅来自 DBC 命名、尚未在台架上触发的条目分开，本文原样保留标注。

    信号 位置（ID / DID / 字节） 解码 证据
    CAN E 状态 0x001 B0 枚举：00=OFF、04=Minimal full ON、C2=Limited/ACC-like、CC=Alternate full ON、CF=Delayed OFF、07=过渡候选 已确认（试验法逐位扫描）
    唤醒 0x045 载荷 00 00 00 00 FF 00 00 00 已确认
    OK 按钮 0x045 载荷 00 00 00 00 FF 02 00 00 已确认
    车门状态 0x283 55 = 全关；56 = 左前门开 已确认
    状态指示 A 0x015 3D FE 00 00 与 00 FE 00 00 两种 标定记录
    状态指示 B 0x39D B0 及末字节 B0：80 或 FF；末字节为存活计数器（07, 0F, …, 7F） 标定记录
    驱动控制（DRIVER_CONTROLS） 0x045（DBC 十进制 69） — 标定记录
    点火（IGNITION） 0x245（DBC 十进制 581） — 未确认（静态搜索无响应）
    轮速（WHEEL_SPEEDS） 0x203（DBC 十进制 515） — 标定记录
    安全带（SEATBELT_SENSORS） 0x375（DBC 十进制 885） — 标定记录
    油门（GAS_PEDAL） 0x105（DBC 十进制 261） — 标定记录
    挡杆（GEAR_LEVER） 0x06D（DBC 十进制 109） — 标定记录
    挡位包（GEAR_PACKET） 0x073（DBC 十进制 115） — 标定记录

    读取方法与注意事项

    第一条是接线与终端。20 针连接器里真正有用的是 7 针：1 / 4 / 6 是供电，12 / 13 是 CAN E，17 / 18 是 CAN B。台架上需要接两个 120 Ω 终端电阻，否则总线反射会让通信不稳定。

    第二条是 ID 进制。源文档的 DBC 把消息 ID 记成十进制（如 69、581、515），而 CANID 是十六进制的——所以 DRIVER_CONTROLS 十进制 69 对应 0x045，IGNITION 十进制 581 对应 0x245。解析前必须先做这个换算，否则会对着错误的 ID 收发。

    第三条是「试验法」。项目找编码的方式是逐位扫描 0x001 的字节并观察仪表反应，从而归纳出 ON/OFF 的取值（如 00 表示 OFF、04 表示最小开启、C2 表示受限/类似 ACC、CC 表示另一种全开）。源文档还记录了一个细节：让保持开启成立的是约 450 毫秒的 07 脉冲。

    证据等级与边界

    项目有一条很好的「机器可读验证」手段：仪表上电后自身会发回 0x015（其值在 3D FE 00 00 与 00 FE 00 00 之间变化）和 0x39D（首字节 80 或 FF，末字节是存活计数器），因此台架可以用这些回发帧判断仪表当前处于什么状态，而不必靠肉眼观察。这比单纯看背光亮不亮更可靠。

    但也存在明确未解项。0x245（IGNITION）在静态搜索下没有任何响应，源文档把它归入未解与下一步清单。此外，若干信号（轮速、安全带、油门、挡杆、挡位包）只是按 DBC 命名列出，尚未在台架上逐一触发验证，本文按「标定记录」而非「已确认」标注。

    边界上必须强调：以上编码、载荷与状态图都限定在源文档记录的这个仪表台（2010 款 W212 E350）上。台架环境与整车环境不同——整车上有网关与其它节点参与，仪表台在整车上的行为未必与台架一致；不同年款或配置的仪表也可能使用不同的编码。

    常见问题

    为什么只接 7 根线就能点亮这个仪表？

    因为源文档确认 20 针连接器里只有 7 针有关：1 / 4 / 6 供电，12 / 13 为 CAN E，17 / 18 为 CAN B。其余针脚在该用途下不需要。台架上再接两个 120 Ω 终端即可组成可通信的最小系统。

    0x001 的状态值是怎么找出来的？

    用试验法：逐位扫描 0x001 的字节并观察仪表反应，归纳出各取值的含义（00=OFF、04=最小开启、C2=受限/类似 ACC、CC=另一种全开、CF=延时关闭、07=过渡候选）。源文档还指出让「保持开启」成立的是约 450 毫秒的 07 脉冲。

    怎么判断仪表当前处于什么状态？

    用仪表自己发回的帧作为机器可读指示：0x015 的值在 3D FE 00 00 与 00 FE 00 00 之间切换，0x39D 的首字节为 80 或 FF、末字节是存活计数器（07, 0F, …, 7F）。据此判断状态比看背光是否点亮更可靠。

    台架上找出来的结论能直接用到整车上吗？

    不能直接套用。台架是把这个仪表台从整车中独立出来，缺少网关与其它节点。同一仪表台在整车上的行为可能与台架不同，不同年款或配置的仪表也可能使用不同编码。实车使用前必须重新验证。

    延伸阅读

    参考资料

    • 项目 10 —— public-can-dbc-datasets/additional/izakulus-w212-cluster-notes/README.md（本项目车型档案主来源：接线、台架参数、状态图与未解清单）

    说明：本文整理自第三方开源项目的公开文档，仅代表该文档所记录的单个车辆样本，不代表同型号全系车型。CAN 与诊断操作存在风险，任何实车操作前请自行复核并遵守当地法规。

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11

  • Tesla 分总线 DBC 档案：同一 CAN ID 的两种报文

    结论：这份档案的对象是随某类商业诊断工具发布的一套 Tesla 平台 DBC，按「一条总线一份 DBC」拆分，另有一份 _shared 文件承载确实跨多总线的报文。它的数据特征不是某个信号的值，而是「同一个 CAN ID 在不同总线上是不同的报文」：例如 0x3D8 在动力总线上可能是 3 字节的 DC-DC 变换器状态，在底盘总线上却是 8 字节的 GPS 位置——一个编号、两条无关报文。正因如此，源文档给出的定位原则是用发送者（transmitter）字段标注报文属于哪条总线。源文档明确这套 DBC 「仅供参考、不受支持」，且其发布方不逆向信号，因此本文只记录结构与少数示例，不构成完整信号地图。

    车辆与适用范围

    源文档是一份 DBC 仓库说明加许可证。它描述的是数据组织方式与使用约定，而非某一台车的采集记录。

    项 内容
    车型 Tesla 各平台（源文档按「每个平台若干份 DBC」组织，未逐一点名具体车型）
    年款 / 市场版本 源文档未确认；并提示 Tesla 可能在不通知的情况下更新信号
    ECU / 改装状态 无改装；表现为可导入诊断工具的 DBC 定义文件
    采集跨度 源文档未提供日志数或帧数（其致谢提及来自社区提供的总线日志）
    适用范围 仅作参考、不受支持；发布方不逆向信号，用户须自行编辑与维护解码信息

    总线与寻址

    源文档的组织原则是「一个总线一个 DBC」，核心动因就是 ID 复用问题。

    项 内容
    物理层 / 比特率 源文档未给出
    寻址方式 源文档未给出；示例 ID 为 11 位量级（0x102、0x399）
    组织方式 按总线拆分：动力、底盘等各一份，另加一份 _shared 承载真正跨总线的报文
    跨总线识别 约定用发送者字段标识报文所在总线；_shared 内报文不带总线标签，在每个通道上都解码
    CAN FD 源文档未提供
    ID 复用示例 0x3D8：动力总线为 3 字节 DC-DC 状态；底盘总线为 8 字节 GPS 位置

    已解码信号

    源文档是 DBC 的说明文档，只举了少量示例。下表登记源文档实际给出的条目（含两个示例信号、一个 ID 复用示例与两类属性约定），并逐条标注出处；源文档没有提供逐信号清单，这一点在表格之后另有说明。

    条目 位置（ID / 属性） 含义 / 解码 证据
    BMS_packCurrent ID 258（0x102） 高压电池电流；被赋显示名「HV Battery Current」 显示名属性示例
    DAS_autopilotState2 ID 921（0x399） 枚举含 DISABLED/UNAVAILABLE/AVAILABLE/ACTIVE_NOMINAL/ACTIVE_RESTRICTED/ACTIVE_NAV/ACTIVE_FSD/ABORTING/ABORTED/FAULT/SNA 取值配色属性示例
    DC-DC 变换器状态 0x3D8（动力总线） 3 字节报文 ID 复用说明
    GPS 位置 0x3D8（底盘总线） 8 字节报文；与上面同编号但无关 ID 复用说明
    显示名属性 属性名（源文档用到具体属性键） 为信号指定在界面上显示的名称 属性说明
    取值配色属性 属性名（源文档用到具体属性键） 为枚举值指定颜色；合法值含 NONE、BLUE、GREEN、INDIGO、ORANGE、PINK、PURPLE、RED、TEAL、YELLOW、WHITE、BLACK、GRAY，也接受 3 字节十六进制色 属性说明
    _shared 报文 _shared 文件 不带总线标签，在每个通道上都解码 组织说明
    发送者字段 报文属性 按约定标明报文所在总线，导入时须开启「按发送者分配总线」 导入说明
    车辆无关定位 项目说明 工具定位为车无关，授权用户自行编辑并维护解码信息 项目说明

    读取方法与注意事项

    导入流程有一条关键约束：源文档说明在某版本的工具中，要把多份 DBC 导入同一个预设，须使用信号列表上的导入功能，因为主菜单的「打开文件」一次只能打开一份。同时有三个开关需要留意——保留不在该 DBC 内的信号/报文（以保住此前手工创建的内容）、按发送者名称尝试分配总线（必须开启）、以及保留计算信号（避免导入时删除默认预设里的计算信号）。这三项决定了导入结果是否与预期一致。

    由于 ID 复用，解析时不能只按编号索引。正确做法是：先确定当前监听的是哪条总线，再用「总线 + ID」的组合去查报文；对 _shared 中的报文才允许跨通道解码。若只有编号没有总线归属，0x3D8 这类报文会被错误地解码成另一条总线的含义。

    数据性质的提醒同样重要：源文档明确发布方不逆向 CAN 信号，并把它描述为一场「猫鼠游戏」——Tesla 可能不通知就更新信号，也不提供总线报文与信号说明。因此这套 DBC 只应作为起点，任何用于关键判断的信号都应在本车日志上复核；改进与修正通过提交合并请求汇集，可能随工具后续版本一起发布。

    证据等级与边界

    本文的证据等级是「项目说明级」：组织原则、ID 复用示例、两类属性与导入约定都能在源文档逐条核对，属直接证据；但源文档没有逐信号清单、没有比特率，也没有实车日志，因此本文只记录结构与少数示例，不提供完整信号地图。这一点与源文档「仅供参考、不受支持」的定位一致。

    两点不能外推。第一，Tesla 各平台之间的报文与信号可能不同，源文档按平台分别组织 DBC，把某一平台的条目外推到另一平台属于超范围。第二，信号可能随 Tesla 的更新而变化，源文档对此已明确提示；任何跨时间、跨软件版本的外推都缺乏依据。此外须注意许可：设备与设计文件采用 CC BY-SA 4.0（署名—相同方式共享），衍生作品需以相同许可发布，商用前应先核对条款。关于安全访问，源文档未提供任何绕过方法，且不建议尝试；本文只整理 DBC 的组织与示例。

    常见问题

    为什么这些 DBC 要按总线拆成好几份？

    因为 Tesla 可能在不同总线上复用同一个 CAN 编号。源文档举 0x3D8 为例：动力总线上是 3 字节的 DC-DC 状态，底盘总线上是 8 字节的 GPS 位置，两者无关。按总线拆分并用发送者字段标注归属，才能避免解码串线。

    导入多份 DBC 时要注意什么？

    源文档提示：要在同一预设里导入多份 DBC，须用信号列表上的导入功能（主菜单「打开文件」一次只能开一份）；并按需处理三个开关，其中「按发送者名称尝试分配总线」必须开启，否则总线归属会错。

    这套 DBC 能直接用于关键判断吗？

    不建议。源文档明确发布方不逆向信号，把维护描述为「猫鼠游戏」，Tesla 可能不通知就更新信号，且这套 DBC「仅供参考、不受支持」。用于关键判断的信号应在本车日志上复核，也可通过提交修正参与维护。

    许可上有什么限制？

    该数据集采用 CC BY-SA 4.0（署名—相同方式共享），衍生作品需以相同许可发布；商用或打包分发前应先核对条款。原文中出现的第三方贡献者名单与本档案无关，未予引用。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/teslax-dbc/README.md（本项目车型档案主来源：按总线拆分 DBC 的原则、ID 复用示例、两类属性与导入约定）。
    • 项目 01 —— public-can-dbc-datasets/additional/teslax-dbc/LICENSE.md（CC BY-SA 4.0 许可条款）。

    说明：本文整理自第三方开源项目的公开文档，仅代表该文档所记录的单个车辆样本，不代表同型号全系车型。CAN 与诊断操作存在风险，任何实车操作前请自行复核并遵守当地法规。

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11

  • opendbc 车型档案：DBC 结构、指纹与安全模式

    结论：这份档案记录的是 opendbc——一个「用 Python 读写你的车」的开源库与 DBC 仓库集合，目标是让带 LKAS + ACC 的车（多为 2016 年后）都能被读状态、控油门刹车与转向。它最值得记录的不是某一辆车的信号，而是三件工程约定：DBC 预处理器把品牌级与车型级 DBC 合成 _generated 文件；指纹（fingerprinting）用 ECU 固件版本识别车型；安全模型让 panda 上电默认处于 SAFETY_SILENT（总线静默），必须先选安全模式才能发报文。逐条信号定义在各自的 DBC 里，本文只登记文档明确写出的示例与能力。

    车辆与适用范围

    源文档是 opendbc 项目的总说明与其 DBC 目录说明。它覆盖的车辆范围很宽，但支持清单放在被引用的 docs/CARS.md（本快照未包含）。

    项 内容
    车型 多品牌；指向「支持车型清单」与约 300 个车型的公开 CAN 数据集
    年款 / 市场版本 多为 2016 年后具备电子可执行转向、油门、刹车的车（因 LKAS/ACC 普及）
    ECU / 改装状态 通过 comma four 与车型线束接入两条 CAN 总线，其中一条被拆开用于注入本系统的执行报文
    采集跨度 源文档未给出统一跨度；提供约 300 车型的 CAN 片段数据集
    适用范围 仅限被登记支持并可被指纹识别的车型；自定义安全模式需自行编译烧录

    总线与寻址

    项目结构分为四层：opendbc/dbc/（DBC 仓库）、opendbc/can/（从 DBC 解析与构造报文的库）、opendbc/car/（与车辆交互的高层 Python 库）、opendbc/safety/（功能安全）。这些层共同决定「一辆车能被读到什么、能写什么」。

    项 内容
    物理层 由车型线束决定；线束接两条 CAN 总线并拆开其中一条用于注入
    链路层 / 比特率 源文档未给出（随车型 DBC 与适配器）
    寻址方式 源文档未给出；DBC 内以报文与信号为单位
    CAN FD 源文档未提及
    承载硬件 comma four + 车型线束 + panda；自定义安全模式需自行编译固件

    已解码信号

    源文档是项目总说明，不是逐车信号清单。下表登记文档中明确写出、可核对的示例与能力条目：信号示例来自 DBC 目录说明的书写范例，其余来自项目总说明的术语与结构。具体每辆车的完整信号以各自 DBC 为准。

    条目 位置 解码 / 含义 证据
    车速 DBC 信号示例 7|15@0+ (0.00278,0) [0|70] "m/s" dbc/README 书写范例
    加速踏板位置 DBC 信号示例 6|7@0+ (1,0) [0|100] "%"（留出首比特不分配） dbc/README 书写范例
    纵向加速度 报文 490 / LONG_ACCEL 注释原文：轮速导数，噪声大且会吸附到零 dbc/README 注释范例
    转向角 car 库读取 读出转向角等状态 README 首段
    油门 / 刹车 / 转向控制 执行器写入 控制油门、刹车、转向 README 首段
    EV 充电状态 读写目标 目标之一：读取并写入充电状态 README 首段
    门锁开 / 关 读写目标 目标之一：读写信门锁 README 首段
    雷达解析 radar_interface.py 解析（若车辆配备） README「Structure of a port」
    指纹 fingerprints.py ECU 固件版本数据库，用于识别车型 README「Structure of a port」
    安全模式状态 SAFETY_SILENT / SAFETY_ALLOUTPUT 上电默认静默；部分模式在发布固件中被禁用 README「Safety Model」
    DBC 预处理器产物 *_generated 由品牌 DBC + 车型 DBC 合成 dbc/README「DBC file preprocessor」
    公开 CAN 数据集 commaCarSegments 约 300 个车型的 CAN 数据 README「More resources」

    读取方法与注意事项

    接入第一步是硬件：拿到兼容车型的线束（若没有现成的，就从「开发者线束」起，再压接所需连接器），线束会把你接到两条 CAN 总线并暴露注入点。第二步是反向工程：先录一段包含丰富事件（开启 LKAS 与 ACC、把方向盘打到两端等）的 route，再用 cabana 打开分析。

    一个车型端口的代码结构很固定：carstate.py 解析状态、carcontroller.py 输出控制、<brand>can.py 是围绕 DBC 的构造辅助、fingerprints.py 存 ECU 固件版本、interface.py 是高层接口、radar_interface.py 解析雷达、values.py 枚举该品牌车型。

    DBC 层面有一个实用的约定：同一个品牌下不同车型的 DBC 大量重叠，因此项目提供预处理器，从「品牌 DBC + 车型 DBC」生成输出文件（_generated 后缀）。改动了源文件需重新运行生成脚本。文档还给出两条书写规范：注释直接写进 DBC（便于在 cabana 里查看/编辑），以及信号只用最少的比特——若不能确定某比特归属，就把它留空不分配，以避免误读。

    证据等级与边界

    本档案属于项目登记。可核对的是结构、命名、安全模型与文档示例；不支持据此列出任何一辆车的完整信号表，因为逐车定义在被引用但未包含在本快照内的 DBC 与 docs/CARS.md 里。

    三处不能外推。第一，「支持某品牌」不等于「支持某年款某配置」——支持清单以车型为单位，文档用术语明确区分 port（某车型的集成）与 brand（品牌）。第二，安全模式不是默认可用：panda 上电默认 SAFETY_SILENT，且 SAFETY_ALLOUTPUT 之类在发布固件中被禁用，需要自行编译烧录才能用。第三，DBC 示例里的数值（如 0.00278 的 m/s 系数）只是书写范例，不代表任何真实车型的标定。

    关于「安全访问」类问题：本文只整理公开文档登记的结构与安全模型，未涉及安全访问的绕过；源文档未提供绕过方法，且不建议尝试。

    常见问题

    opendbc 支持哪些车？

    见被引用的支持车型清单：任何具备 LKAS 与 ACC 的车都可能被支持，多为 2016 年后的车型。本快照只含项目总说明与 DBC 目录说明，未包含完整支持清单。

    怎么给一辆新车加支持？

    按「车型端口」的结构来做：先连上硬件并录一段含丰富事件的 route，再用 cabana 反向工程；随后补齐状态解析、控制输出、指纹与车型枚举等文件。相似车型已有支持时，大部分工作可能已经完成。

    panda 上电后能直接发报文吗？

    不能。上电默认处于 SAFETY_SILENT，总线被强制静默；必须先选择一个安全模式才能发送报文。部分模式（如 SAFETY_ALLOUTPUT）在发布固件中被禁用，需要自行编译烧录。

    DBC 里的 _generated 文件是怎么来的？

    由预处理器从「品牌 DBC + 车型 DBC」合成。源文件改动后需重新运行生成脚本，产物放在仓库根目录并带 _generated 后缀。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/commaai-opendbc-master-20261004/README.md（本项目车型档案主来源：项目结构、安全模型、端口结构与反向工程流程）。
    • 项目 01 —— public-can-dbc-datasets/additional/commaai-opendbc-master-20261004/dbc/README.md（DBC 目录说明：书写规范、预处理器与示例）。

    说明：本文整理自第三方开源项目的公开文档，仅代表该文档所记录的单个车辆样本，不代表同型号全系车型。CAN 与诊断操作存在风险，任何实车操作前请自行复核并遵守当地法规。

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11

  • Ford Fiesta MK5 影音 CAN 档案：125 kbps 车身信号

    结论：这份档案的对象是2006 年以后的 Ford Fiesta MK5（改款，配 2-DIN 与 6000CD 收音机）的影音 CAN（MS-CAN）。它的数据特征是「低速、易接入、以车身与影音信号为主」：总线速率 125 kbps，从收音机 QuadLock 连接器的 CANH/CANL 即可旁听，不需要 120 欧姆终端电阻；可见内容包括仪表显示屏文字（经 ISO-TP）、电台名、音量、CD 状态、时间、车门/车灯/挡位/踏板等。源文档只覆盖这一台改款 Fiesta 与这台 6000CD 收音机，且其定义文件不完整，部分报文只做到部分解码；下述结论不外推到其他年款或配置。

    车辆与适用范围

    源文档是一份逆向记录：作者以「截取收音机送给仪表 LCD 的文字」为起点，顺带解出若干其他报文。以下范围仅对应这一台车与这台收音机。

    项 内容
    车型 Ford Fiesta MK5，2006 年以后（MK5 改款），配 2-DIN 与 6000CD 收音机
    年款 / 市场版本 源文档以「>2006 改款」界定；其他年款与市场版本未确认
    ECU / 改装状态 无改装；在收音机 QuadLock 连接器的 CANH/CANL 上旁接一块 CAN 扩展板
    采集跨度 源文档未提供日志时长或帧数
    适用范围 仅这一台改款 Fiesta 与 6000CD 收音机的影音 CAN；定义文件不完整，部分报文仅部分解码

    总线与寻址

    源文档对物理层描述简练而具体：接入选定在收音机端，且对终端条件有明确说明。

    项 内容
    物理层 / 比特率 MS-CAN，125 kbps
    寻址 / 帧格式 源文档列出的 ID 均为 11 位标准帧（0x080–0x4F3）
    接入点 收音机 QuadLock 连接器的 CANH/CANL
    终端 不需要 120 欧姆终端电阻（源文档明示）
    CAN FD 源文档未提供（该年代与总线类型指向经典 CAN）
    传输层 仪表文字使用 ISO-TP（ISO 15765-2）分帧，含单帧与首帧/连续帧/流控

    已解码信号

    下表抽取源文档中最有代表性的条目（车身状态、影音与仪表文字）。位置列保留原文 ID 与字节序号，解码列保留其换算公式；证据列注明源文档对该条目的完成度或限定。

    信号 位置（ID / 字节） 解码 证据
    日期时间 0x080 / 字节 1–6 年（两位）、月、日、时、分、秒；1 秒分辨率 车载 RTC 独立于收音机时钟
    电台名 0x1E9 / 8 字节 ASCII 文本 完全解码
    转速 / 车速 / 油门 0x201 / 字节 1–2、5–6、7–8 km_h = speed/100；gas_percent = gas*100/50944 部分字段未标注
    转向灯箭头 0x265 / 字节 1 位掩码：左 0x20、右 0x40 位掩码按需相加
    前灯 / 手刹 0x286 / 字节 1 位掩码：手刹 0x10、示宽/近光 0x80、远光 0x40 示宽与近光共用同一 LED，无法区分
    音量 0x2D8 / 字节 2 volume = volume_raw/8 完全解码
    CD 状态 0x2DA / 字节 2、4 模式 0x2A/0x4A/0x6A；驱动器 0x23/0x21/0x22/0x26 枚举表完整
    CD 曲目 / 时间 0x2DB / 字节 3–4、6 曲目时间 track_seconds = track_time - 64；另含 track_id 非播放时为全 FF
    方向盘模式/选台键 0x2D5 / 字节 2 位掩码：模式 0x10、上选 0x40、下选 0x80 音量键不经此报文
    制动状态（一） 0x360 / 字节 6 未踩 0x60、轻搭 0x68、踩下 0x78 同一状态在两报文重复
    冷却液 + 制动（二） 0x420 / 字节 1、6 coolant_degrees = coolant - 40；制动 0x00/0x10/0x30 两处制动编码不同
    蓄电池电压 0x428 / 字节 2 battery_v = battery/10（十分之一伏） 完全解码
    车门 / 倒挡 / 锁止 0x433 / 字节 1、4、6 门位掩码：左前 0x80、右前 0x40、后备箱 0x08；倒挡 0x02；锁 0x10/解锁 0x20 位掩码完整
    仪表文字 0x4C0 / 短格式与扩展格式 短格式：0x07 0x34 + ASCII；扩展格式：首帧 0x10 + 长度 + 0x34，连续帧 0x21 + ASCII 为 ISO-TP；配套 0x4C8 流控
    车辆识别（VIN 低位） 0x4F3 / 8 字节 周期性广播的车辆 ID（VIN 低位，含生产日期信息） 完全解码

    读取方法与注意事项

    接入非常直接：源文档说明只需把 CAN 接口接到收音机 QuadLock 连接器的 CANH/CANL，无需 120 欧姆终端电阻。这一条与多数两节点试验台的接线习惯相反，源文档把它作为结论明确写出，实际接线时不要凭经验加终端。

    仪表文字那一类是ISO-TP（ISO 15765-2）传输：短格式只在收音机切到 AUX 模式时可见，形如「首字节标志 + 0x34 + ASCII」；扩展格式由一条含文本长度的首帧加若干条提供后续文本的连续帧组成。响应里随后出现的 ACK 报文提供流控：字节 1 为 0x30 表示「可继续发送」，字节 2 为 0x00 表示不做分帧流控，字节 3 为 0x00 表示按发送方最快速度。解析这类文本时，必须按 ISO-TP 的帧类型分别处理，而不能把每条 ID 当独立报文读。

    还有一处容易混淆：制动状态在两条报文里重复出现但编码不同——0x360 用 0x60/0x68/0x78，0x420 用 0x00/0x10/0x30。同一物理状态的多套编码要求解析方选定一个来源并保持口径一致。此外，音量键并不经方向盘那条报文（0x2D5 只覆盖模式与选台键），源文档对此如实标注为「似乎如此」。

    证据等级与边界

    本文属于单台实车逆向观测：ID、字节与换算公式均可在源文档逐条核对，属于直接证据；但源文档没有给出采集时长、帧数或时序，也未声明校验与计数器机制（除 ISO-TP 流控外）。随文档提供的定义文件（某类商业诊断工具的 .kcd 格式）源文档明确标注为不完整，因此不能把它当作完整协议描述。

    两点不能外推。第一，全部内容来自一台「2006 年以后改款」的 Fiesta 与一台 6000CD 收音机；换成其他年款、其他市场版本或其他音响配置，ID 与编码都可能不同。第二，多个报文只做到部分解码，源文档用「unspecified」标记了未解析字节；把这些字节当作已知信号会超出源文档证据。关于安全访问，源文档未提供任何绕过方法，且不建议尝试；本文只整理只读旁听所能看到的内容。

    常见问题

    接入这条总线要不要加 120 欧姆终端？

    不需要。源文档明确：把 CAN 接口接到收音机 QuadLock 的 CANH/CANL 即可，不用终端电阻。这与多数两节点试验台的接线习惯相反，接线时按源文档结论来，不要凭经验加终端。

    仪表屏的文字是怎么传的？

    走 ISO-TP（ISO 15765-2）。短格式如同「0x07 0x34 + ASCII」，只在 AUX 模式可见；扩展格式由带文本长度的首帧（0x10 + 长度 + 0x34）加若干连续帧（0x21 + ASCII）组成，随后有 0x4C8 流控 ACK。解析时必须按 ISO-TP 帧类型分别处理。

    为什么同一制动状态有两种编码？

    因为在源文档里它被两条报文重复承载：0x360 用 0x60/0x68/0x78，0x420 用 0x00/0x10/0x30。这是源文档记录的实际状态，解析时应选定一个来源并保持口径一致，不要混用两套编码。

    随文档提供的定义文件能当完整协议看吗？

    不能。源文档明确标注该文件（某类商业诊断工具的 .kcd 格式）不完整，多处字节以「unspecified」标记为未解析。把它当作完整协议描述会引入未经证实的字段。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/roncapat-ford-fiesta-mk5/README.md（本项目车型档案主来源：总线速率、接入方式、全部已解码 ID 与换算公式）。

    说明：本文整理自第三方开源项目的公开文档，仅代表该文档所记录的单个车辆样本，不代表同型号全系车型。CAN 与诊断操作存在风险，任何实车操作前请自行复核并遵守当地法规。

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11

  • CarCluster 仪表注入：13 个 Simhub 字段与 13 款仪表盘

    结论：这份档案记录的是一个反方向的 CAN 项目：不是从车上读信号，而是用 ESP32 + MCP2515 把 PC/游戏数据注入真实仪表盘，让一台退役的原车仪表在桌面上工作。源文档最可直接引用的是它的输入字段表——Simhub 集成示例把 13 个字段（车速、挡位、转速、最大转速、左右转向、机油温度、暂停、运行、油量百分比、手刹、ABS、TC）映射进这套固件。硬件与支持的仪表清单同样值得记录，但要注意：多款较新仪表（如 T-Cross）存在组件保护，一旦触发无已知解法。

    车辆与适用范围

    源文档是一个开源桌面项目，目标是驱动真实仪表盘，主要用于游戏，也可作时钟等用途。硬件极简：一块 ESP32、一个 MCP2515 CAN 模块、一个 12V 电源。

    项 内容
    车型 面向多种车型仪表盘（VW PQ35/MQB/PQ46、BMW F/E 系、Mercedes W204/W221、Mini F55/F56/F57、Opel Corsa E 等）
    年款 / 市场版本 随平台不同；源文档未统一给出年款，示例为 VW Polo 5、Golf 7、Škoda Superb 2、BMW F10/F30 6WA、E60、E46、W204/W221 等
    ECU / 改装状态 退役仪表盘 + 自制电源/线束；部分平台需逻辑电平转换（如 E46）、数字电位器模拟油位
    采集跨度 源文档未给出；无整车采集，数据来自游戏或网页界面
    适用范围 仅限源文档明确「已完整测试并支持」的仪表型号；相近平台「可能可用但需按具体车型修改」

    总线与寻址

    物理连接对普通爱好者很友好：ESP32 Devkit 板 + 通用 MCP2515 CAN 模块，另可用项目自制的转接 PCB 或跳线/面包板两种接法。仪表侧接线按平台各有专门文档。

    项 内容
    物理层 ESP32 板 + MCP2515 CAN 模块 + 12V 电源；E46 需逻辑电平转换
    链路层 / 比特率 源文档未给出
    寻址方式 源文档未给出
    CAN FD 源文档未提及
    仪表侧接线 按平台各有一份接线文档（PQ/MQB/BMW F/E60/E46/MB W204/W221/Opel Corsa E）

    已解码信号

    这份主素材不是从整车抓包的信号表，而是注入端的数据字段映射。下表逐条来自源文档给出的 Simhub 集成更新消息格式，是文档中唯一逐字段列出的信号清单，括号内为默认值（若有）。

    字段 键名 含义 / 默认值 证据
    车速 spe 车速（km/h），取整 Simhub 更新消息示例
    挡位 gea 挡位字符串，空值默认 P Simhub 更新消息示例
    转速 rpm 当前转速，空值默认 0 Simhub 更新消息示例
    最大转速 mrp 红线转速，空值默认 8000 Simhub 更新消息示例
    左转向灯 lft 左转向指示，默认 0 Simhub 更新消息示例
    右转向灯 rit 右转向指示，默认 0 Simhub 更新消息示例
    机油温度 oit 机油温度，默认 0 Simhub 更新消息示例
    游戏暂停 pau 是否暂停，默认 0 Simhub 更新消息示例
    游戏运行 run 是否运行，默认 0 Simhub 更新消息示例
    油量百分比 fue 计算得到的燃油百分比，默认 0 Simhub 更新消息示例
    手刹 hnb 手刹状态，默认 0 Simhub 更新消息示例
    ABS abs ABS 是否激活，默认 0 Simhub 更新消息示例
    TC tra 牵引力控制是否激活，默认 0 Simhub 更新消息示例

    读取方法与注意事项

    初始化流程在源文档里很明确：下载项目后用 Arduino IDE 打开 Carcluster.ino，在 BEGIN USER CONFIGURATION 段选择目标仪表盘（例如把 #define CLUSTER 1 改成 3 使用 Golf 7 仪表），其余参数按具体仪表配置；项目已内置所需库，无需额外安装。烧录后 ESP32 会开一个名为 CarCluster 的 Wi-Fi 热点（密码 carcluster），连上后跳转 192.168.4.1 选择要接入的网络；若 3 分钟内未配置，则进入串口模式，可配合 Simhub 使用。

    两个易踩的坑：一是接上 CAN 模块时可能无法烧录，需先断开再上传；二是部分 ESP 板的串口不支持全速，会出现「板子无响应」之类错误，此时把 SERIAL_BAUD_RATE 改成 460800，并同步修改串口监视器、Simhub 与 Arduino 的上传速度。仪表侧的功能自测可以用网页界面（可设转速、车速等）来验证。Simhub 目前只支持 USB 连接、不支持 Wi-Fi。

    证据等级与边界

    本档案属于项目登记 + 集成示例。字段表本身是源文档写死的键名，可核对；「某款仪表盘被完整支持」是作者自测结论；至于实车报文，本项目并不产生——它是把游戏/PC 数据注入仪表，信号方向与整车抓包相反。

    三处不能外推。第一，字段表是注入协议，不是任何一辆车的 CAN 信号定义，不能当成车型档案使用。第二，平台相近不等于可用：源文档明说「相近平台可能可用，但需按具体车型修改」。第三，组件保护是硬边界：较新的 MQB 仪表（如 T-Cross）在未知时间后会进入组件保护模式，闪屏且多数指示灯失效，目前无已知解法，应避免使用。

    关于「安全访问」类问题：本文只整理公开文档登记的注入字段与硬件，未涉及对车辆安全机制的规避；源文档未提供绕过方法，且不建议尝试。

    常见问题

    CarCluster 是从车上读信号吗？

    不是，方向相反。它把 PC/游戏的数据注入真实仪表盘，让仪表显示外部数据；项目目的是在桌面使用退役仪表，而非从整车抓包。

    为什么有些仪表盘不能用？

    以 VW T-Cross 为代表的新款 MQB 仪表会在未知时间后进入组件保护模式，闪屏且多数指示灯失效，源文档明说目前无已知解法，建议改用较老的 Golf 7 等。

    哪些仪表盘支持得最好？

    源文档给出的入门推荐顺序是：Mercedes 某几款仪表、BMW F 系仪表、VW MQB 系仪表；并列出已完整测试支持的具体型号，其中 W204/W221、BMW F10/F30 6WA、E46 等标为完整支持，E60 标为「部分支持、开发中」。

    注入的信号都有哪些？

    源文档的 Simhub 集成示例列出 13 个字段：车速、挡位、转速、最大转速、左右转向灯、机油温度、暂停、运行、油量百分比、手刹、ABS、TC。它们都有默认值，缺省时按默认显示。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/r00li-carcluster/README.md（本项目车型档案主来源：硬件、支持的仪表清单、Simhub 字段映射与安装说明；本快照仅含此文件）。

    说明：本文整理自第三方开源项目的公开文档，仅代表该文档所记录的单个车辆样本，不代表同型号全系车型。CAN 与诊断操作存在风险，任何实车操作前请自行复核并遵守当地法规。

    更新记录

    首次发布 2026-10-11 最近核对：2026-10-11