标签: 车型协议

  • FT86 与 MX-5 的赛道 CAN 信号:RaceChrono 公式表

    结论:这是一组面向赛道数据记录的 CAN 信号表,覆盖四类车:2013-2020 Subaru BRZ / Toyota 86 / Scion FR-S、2022 BRZ / GR86、Mazda MX-5 的 NC 与 ND 两代。它们的共同点是——老一代 FT86 与 NC/ND 的主 CAN 就在 OBD 口引脚 6/14 上,用一款 OBD 读取器即可直接抓广播帧;而 2022 BRZ/GR86(以及 2018+ WRX、许多 Porsche)把 CAN 与 OBD 口隔离了,只能拿慢速有限的 OBD 数据,或另找接入点。下表登记的是各平台可用的通道与公式,其中若干系数源文档自述为「经验值」或「可能有误」。下述条目只适用于各表所记录的车型与年款。

    车辆与适用范围

    源文档是一个 DIY BLE CAN 记录设备的说明,作者用它给一款商业赛道计时 App 供数。信号表按车型分组保留,ND 表明确说明是在一台 2019 MX-5 RF 上测试的。

    项 内容
    车型 2013-2020 Subaru BRZ / Toyota 86 / Scion FR-S;2022 Subaru BRZ / Toyota GR86;Mazda MX-5 NC(2005-2015)、ND(2019 RF 实测)
    年款 / 市场版本 各表相互独立;ND 表按 2019 MX-5 RF 测试,其他 ND 年款「应可适用」但未独立确认
    ECU / 改装状态 原厂状态;接入走 OBD 口或隐藏连接器,作者自制 nRF52840 + MCP2515 记录设备
    采集跨度 源文档未给出统一日志数;MX-5 NC 表附有一份怠速时 10 秒内的 CAN ID 直方图
    适用范围 各车型表只适用其列出的年款/代际;跨代不可套用(同一功能在不同代的 ID 完全不同)

    总线与寻址

    源文档说明 FT86 与 Miata 的老一代主 CAN 在 OBD 引脚 6/14 上;较新的车把 CAN 与 OBD 口隔离。信号表以 11 位 ID 记录(如 0x140、0xD1、0x081、0x201),源文档未展开 29 位或 CAN FD 话题,按经典 CAN 处理。

    项 内容
    物理层 双绞线 CAN;FT86/Miata 老一代主 CAN 在 OBD 引脚 6/14
    链路层 / 比特率 源文档未统一给出比特率,按经典 CAN 处理
    寻址方式 11 位 ID
    CAN FD 源文档未涉及
    接入差异 2022 BRZ/GR86、2018+ WRX 等把 CAN 与 OBD 口隔离,需另找接入点

    已解码信号

    下表从四张源表中抽取代表性信号,逐条标注车型与证据/置信度。源文档标注为经验值、可能错误或请求独立核对的系数,按原样保留。

    信号 车型 / ID 解码 证据 / 置信度
    加速踏板位置 FT86 gen1 / 0x140 A / 2.55(%) 源表「Recommended」
    加速踏板位置 FT86 gen2 / 64 E / 2.55(%) 源表「Recommended」
    制动位置 FT86 gen1 / 0xD1 min(C / 0.7, 100)(%) 0.7 为经验除数;看到频繁 100% 可改用 0.8 / 0.9
    制动压力 FT86 gen1 / 0xD1 C × 128 源表「Recommended」
    制动压力 FT86 gen2 / 313 F × 128 系数取自 gen1,源文档称「似乎吻合」
    冷却液温度 FT86 gen1 / 0x360 D − 40 → °C 源表「Recommended」
    机油温度 FT86 gen1 / 0x360 C − 40 → °C 源表「Recommended」
    转速 FT86 gen1 / 0x140 bitsToUIntLe(raw, 16, 14) 源表「Recommended」
    车速 FT86 gen1 / 0xD1 bytesToIntLe(raw, 0, 2) × 0.015694 源文档建议对 GPS 核对乘数
    车速 FT86 gen2 / 313 bitsToUIntLe(raw, 16, 13) × 0.015694 乘数同样建议对 GPS 核对,换更大/更小直径轮胎时尤其
    转向角 FT86 gen1 / 0xD0 bytesToIntLe(raw, 0, 2) × −0.1(正值为左转) 源表「Recommended」
    四轮车速 FT86 gen1 / 0xD4 每 2 字节一个轮,× 0.015694 与「车速」同乘数
    横摆角速度 FT86 gen2 / 312 bytesToIntLe(raw, 4, 2) × −0.2725 对某款外部陀螺仪标定;gen1 用 0.286478897
    横/纵向加速度 FT86 gen1 / 0xD0 bytes(6,1) × 0.2;bytes(7,1) × −0.1 源文档标注「数据噪声大」
    离合器位置 FT86 gen1 / 0x140 (B & 0x80) / 1.28(只有 0% 和非 0%) 源文档标注仅能区分 0% 与「非 0%」
    转速 MX-5 NC / 0x201 bytesToUInt(raw, 0, 2) / 4.00 源表(WIP)
    车速 MX-5 NC / 0x201 ((bytesToInt(raw, 4, 2) / 100) − 100) / 3.6 原始值含 100 km/h 偏移;/3.6 转 m/s
    制动压力 MX-5 NC / 0x085 (3.4518689053 × raw − 327.27) / 1000 kPa 乘数取自他人数据,源文档标注「可能有误」
    车速 MX-5 ND / 514 bytesToInt(raw, 2, 2) / 360.0 源表「Recommended」(2019 RF 实测)
    转速 MX-5 ND / 514 bytesToUInt(raw, 0, 2) / 4 源文档提问:若有人记录到 > 8192 rpm 请告知
    转向角 MX-5 ND / 134 (16000 − bytesToUInt(raw, 0, 2)) × 0.1(正值为右转) 源表「Recommended」

    读取方法与注意事项

    第一是通道预算:源文档提醒,每增加一个基于新 CAN ID 的通道都会增加会话文件体积,并可能拖低其他通道的更新率,因为 BLE 带宽有限;但如果新通道与已有通道共用同一个 CAN ID(例如「节气门位置」和「加速踏板位置」都用 0x140),协议会自动优化,基本不影响更新率。

    第二是接入点:FT86 与 Miata 老一代可以直接用 OBD 引脚 6/14;作者也提到可以在信息娱乐主机后方找一个隐藏连接器做完全隐式的接入。2022 之后的部分车型把 CAN 与 OBD 口隔离,这时要么接受慢速 OBD 数据,要么另找物理接入点并自制连接。

    第三是公式单位:源表的车速公式末尾带「/3.6」,是把 km/h 换成 App 内部使用的 m/s,再由 App 换算成用户选择的单位;照着抄时不要重复换算。转向角公式前的负号只是朝向约定(正值为左转或右转随车型不同),可按喜好去掉。

    证据等级与边界

    可视为有证据的是 ND 表(在 2019 MX-5 RF 上实测)与各表标注为「Recommended」的基础信号。属于经验值/待核对的是:制动位置的 0.7 除数、gen2 制动压力沿用 gen1 系数、车速乘数(建议对 GPS 核对)、MX-5 NC 的制动压力乘数(源文档自述可能有误)、横/纵向加速度(噪声大)、离合器位置(只能区分 0%)。

    不能外推的地方有两处。第一,同一功能在不同代际是不同的 ID 与公式(例如加速踏板 gen1 是 0x140、gen2 是 64),跨代套用必然出错。第二,各表相互独立,ND 表虽称「应适用于其他 ND 年款」,但只有 2019 RF 一台被实测,其他年款与配置需自行确认。

    关于「安全访问」类问题:源文档未提供任何绕过方法,且不建议尝试;这些表都是监听广播帧得到的结果,不涉及对车辆安全机制的规避。

    常见问题

    哪些车能直接从 OBD 口抓到主 CAN?

    源文档说明 2013-2020 的 BRZ/86/FR-S,以及 NC 与 ND 代 Miata,主 CAN 就在 OBD 引脚 6/14 上,用一款 OBD 读取器即可直接抓。2022 BRZ/GR86、2018+ WRX 以及许多 Porsche 把 CAN 与 OBD 口隔离了,只能拿慢速有限的 OBD 数据或另找接入点。

    2022 BRZ 和 2013-2020 的公式能通用吗?

    不能。同一功能在不同代是不同的 ID 与公式,例如加速踏板 gen1 用 0x140、gen2 用 ID 64;两代表是独立维护的。

    车速公式里的乘数需要改吗?

    源文档建议对 GPS 核对,换更大或更小直径轮胎时尤其要核对;FT86 两代都用 0.015694,MX-5 NC 用含 100 km/h 偏移的分式。

    加更多通道会影响刷新率吗?

    会,若新通道基于新的 CAN ID。源文档说明同一 CAN ID 上的多个通道不影响更新率,而基于新 ID 的通道很可能拖低所有其他通道的更新率。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/timurrrr-racechrono-can-notes/README.md(主来源:设备与接入总说明)。
    • 项目 01 —— public-can-dbc-datasets/additional/timurrrr-racechrono-can-notes/can_db/ft86.md 与 can_db/ft86_gen2.md(两代 FT86 信号表)。
    • 项目 01 —— public-can-dbc-datasets/additional/timurrrr-racechrono-can-notes/can_db/mazda_mx5_nc.md 与 can_db/mazda_mx5_nd.md(MX-5 NC/ND 信号表)。

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

    更新记录

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

  • 起亚 Soul EV(PS)DBC 档案:转向、制动与四轮速信号

    结论:这是一份以起亚 Soul EV(PS)命名的 DBC 数据档案,由两部分组成:一份「整车」文件记录可读的转向角、制动压力与四轮车速(每 20 毫秒更新,单位分别为度、Bar、KPH);一份「DriveKit」文件记录可写的转向角、转向扭矩、油门踏板与制动踏板命令(同样 20 毫秒)。三条硬边界:其一,这不是厂家整网定义,而是研究与自动驾驶平台用的消息集合;其二,文档把底盘控制(雨刮、转向灯、喇叭、大灯、读 VIN)标为 Niro 专用,每条 DriveKit 消息是否适用于 Soul EV「未建立」;其三,所有声明的量程都是 [0|0],不能当作真实范围。

    本文整理自该项目的 DBC 说明与其来源说明。来源说明本身就把适用范围、许可与验证状态标得很保守,本文原样保留这些限定。

    车辆与适用范围

    仓库说明该项目是一个起亚 Soul EV 的 CAN 记录与解码脚本,用于某实验室的自动驾驶平台采集;DBC 覆盖范围被描述为「有限」。来源说明进一步指出:这是记录集合而非出厂整网,本归档也未针对具体年款、配置或固件做过独立核对。

    项 内容
    车型 起亚 Soul EV(PS)
    年款 / 市场版本 源文档未确认(未绑定具体年款、配置或固件)
    ECU / 改装状态 面向自动驾驶平台的数据采集;DriveKit 为可写命令集
    采集跨度 源文档未给出;说明称用于 AV 平台数据采集,本归档未核对原始采集
    适用范围 仅该 DBC 快照;DriveKit 消息对 Soul EV 的适用性未建立

    总线与寻址

    来源说明没有给出该车的总线速率或 11 位 / 29 位寻址结论,也没有 CAN FD 的说明。文档给出的是消息与信号的名称、方向(读 / 写)与周期,属于应用层与数据层;物理层与链路层细节属源文档未覆盖项,本文不补。

    项 内容
    物理层 源文档未给出
    链路层 源文档未给出
    寻址 源文档未给出 11 位 / 29 位结论
    CAN FD 源文档未提及
    消息周期 文档列出的信号多为 20 毫秒周期

    已解码信号

    下表分「整车文件(只读)」与「DriveKit 文件(可写)」两组。所有声明的物理量程均为 [0|0],因此「单位」是文档给出的量纲,不是经验证的范围。表格中凡「Niro only」者不得套到 Soul EV。

    信号 / 命令 来源与方向 解码 / 取值 证据
    Steering Angle(整车) Vehicle DBC,只读 度,20 毫秒 源文档规格表
    Brake Pressure(整车) Vehicle DBC,只读 Bar,20 毫秒 源文档规格表
    Individual Wheel Speed(整车) Vehicle DBC,只读 KPH,20 毫秒(四个轮速) 源文档规格表
    steering_angle_cmd_flags DriveKit STEERING_ANGLE_COMMAND,写 Disable / Enable 源文档命令表
    steering_angle_cmd_angle 同命令消息 度 源文档命令表
    steering_angle_cmd_max_velocity 同命令消息 度(文档示例用 300) 源文档命令表与示例
    steering_angle_report_flags DriveKit STEERING_ANGLE_REPORT,读 Enable / Disable,每 20 毫秒发布 源文档报告表
    steering_angle_report_errors 同报告消息 Angle Missing / Angle Irrational / Module Disabled / Command Rejected 源文档报告表
    steering_enable_magic DriveKit STEERING_ENABLE 默认 magic number(用于先使能扭矩控制器) 源文档示例
    Steering Torque DriveKit,写 度,20 毫秒 源文档规格表
    Throttle Pedal Position DriveKit,写 百分比,20 毫秒 源文档规格表
    Brake Pedal Position DriveKit,写 百分比,20 毫秒 源文档规格表
    CHASSIS_CONTROL_COMMAND(Niro only) DriveKit,写 前雨刮(off / intermittent / slow / fast)、后雨刮(off / on)、左右转向灯、喇叭、读 VIN、大灯(off / low / high) 源文档命令表,标注 Niro 专用

    读取方法与注意事项

    转向角命令三步走。文档给出的顺序是:先发 STEERING_ENABLE(带默认 magic number)使能转向扭矩控制器;再发 STEERING_ANGLE_COMMAND,其中 flags 置 Enable、angle 设目标角、max_velocity 设最大角速度(示例用 300 度/秒);最后应能在总线上看到 STEERING_ANGLE_REPORT 回报 flags 为 Enable、errors 为 None。

    命令互斥与越界拒绝。文档明确:转向角命令与转向扭矩命令不能同时使用,二者互斥。示例还演示越界:请求超过车辆能力的角度(9999 度)时回报变为 flags 为 Disable、errors 为 Command Rejected,控制器自我禁用。

    底盘控制是 Niro 专用。CHASSIS_CONTROL_COMMAND 可在一条消息里同时设置一个或多个底盘部件(雨刮、转向灯、喇叭、大灯,以及请求 VIN),但文档把这组功能标为 Niro only。是否适用于 Soul EV,来源说明写明「未建立」,因此不能照搬。

    写命令有实车风险。DriveKit 文件里转向、油门、制动等都是写入类命令,一旦发送就会作用在真实车辆上。本文只转述文档记录,不构成操作指引。

    证据等级与边界

    第一层是覆盖范围:来源说明写明整车文件只有 3 条消息、6 个信号,DriveKit 文件有 15 条消息、32 个信号,这是一套研究用的消息集合,不是厂家整网定义。

    第二层是数据质量:每个声明的物理范围都是 [0|0],来源说明把它列为需要独立复核的信号准确性问题;DriveKit 说明文件还提到 Niro 专用的底盘控制,因此「每条 DriveKit 消息都适用于 Soul EV」并未成立。

    第三层是来源状态:项目自报做了 AV 平台采集,但本归档未将该副本与其采集数据、具体年款 / 配置 / 固件做独立核对;快照中也未发现仓库级许可证,仅作私有离线研究副本保留。据此,本文的信号与方向只能视为「这份 DBC 所声明的范围」,不能外推到其他 Soul EV 或其他起亚车型。

    常见问题

    这份 DBC 是起亚 Soul EV 的整车出厂网络吗?

    不是。来源说明写明整车文件只有 3 条消息、6 个信号,DriveKit 文件有 15 条消息、32 个信号,是一套研究 / AV 平台用的消息集合,而非厂家整网定义。

    为什么每个信号的物理范围都写成 [0|0]?

    因为源 DBC 就是这么声明的,来源说明也把它列为「信号准确性需要独立复核」的问题。所以 [0|0] 不能当作真实量程,表格里的「度 / Bar / KPH / 百分比」只是文档给出的量纲。

    转向角命令和转向扭矩命令能一起发吗?

    不能。文档明确二者互斥,不能同时使用。示例演示的顺序是先发使能消息,再发转向角命令,并通过报告消息确认 flags 为 Enable、errors 为 None。

    Niro 的底盘控制能不能套到 Soul EV?

    未确认。文档把这组底盘控制(雨刮、转向灯、喇叭、大灯、读 VIN)明确标注为 Niro only;来源说明也指出「每条 DriveKit 消息是否适用于 Soul EV 尚未建立」。因此不能照搬到 Soul EV。

    转向角报告里会出现哪些错误?

    文档列出的四种是:Angle Missing(角度缺失)、Angle Irrational(角度不合理)、Module Disabled(模块禁用)、Command Rejected(命令被拒)。越界请求(如示例中的 9999 度)会得到 Command Rejected,随后控制器自我禁用。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/aroongta-kia-soul-ev/DBC/DBC-README.md(本项目车型档案主来源,取用了整车 / DriveKit 的信号与周期表)。
    • 项目 01 —— public-can-dbc-datasets/additional/aroongta-kia-soul-ev/SOURCE.md(取用了覆盖范围、[0|0] 量程与「未建立」等边界说明)。
    • 项目 01 —— public-can-dbc-datasets/additional/aroongta-kia-soul-ev/README.md(取用了 AV 平台采集的项目背景)。

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

    更新记录

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

  • Fiat Ducato X250 车身 CAN 档案:50 kbit/s 上的 24 条信号

    结论:Fiat Ducato X250 的一个反直觉特征是OBD 口后面不是发动机 CAN,而是一张 50 kbit/s 的车身 CAN:引脚 6/14 承载 B-CAN,500 kbit/s 上什么都没有;发动机 ECU 走引脚 7 的 K 线(ISO 14230-4 KWP2000)。好消息是仪表需要的多数发动机量(转速、冷却液温度、车速、里程、续航)都被广播到这张车身网上,所以一个只监听、不发送的 CAN 记录器就能读到。源文档记录 18 个 ID、约 90 帧/秒,并逐条说明每个信号是怎么在实车上核对出来的。下述结论仅限源文档记录的那一台 2009 X250。

    车辆与适用范围

    源文档是一位车主的业余项目,属于单台车、单人实验。作者明确声明「只做监听、绝不发送」,并说明是配合一款支持 MQTT 的 OBD-CAN 记录适配器完成的;文档还提到另一台车(同平台另一辆 van)提供了油量数据。作者列出该平台同款车型(Citroën Jumper / Peugeot Boxer 2006–2014),但只有 Ducato X250 被测试过。

    项 内容
    车型 Fiat Ducato X250,2.3 MultiJet 柴油(车身改装为 Elnagh Prince 55L 房车,7.15 m)
    年款 / 市场版本 2009(第一代 X250,模拟仪表 + 橙色 LCD);意大利(EU)市场
    ECU / 改装状态 原厂线束未改;OBD 口插一款 OBD-CAN 记录适配器(只监听模式);发动机 ECU 走 K 线
    采集跨度 5 段真实抓包(怠速、门与灯、杂项动作、冷启动与轰油、约 20 分钟 7 km 行驶),约 90 帧/秒
    适用范围 仅限这一台 Ducato X250;同平台 Jumper/Boxer 未测试,车身电路(例如车门与柜锁共用一条回路)因改装而异

    总线与寻址

    源文档把物理层写在最前面:OBD 引脚 6/14 是车身 CAN(B-CAN),50 kbit/s、11 位 ID;引脚 7 是发动机 ECU 的 K 线。作者特别提醒:把记录器设成 500 kbit/s 时「什么都看不到」,因为这张网上没有 500 kbit/s 的流量。

    项 内容
    物理层 双绞线 CAN,B-CAN 高/低;OBD 引脚 6/14
    链路层 / 比特率 50 kbit/s(源文档明示;500 kbit/s 无流量)
    寻址方式 11 位 ID,文档记录 18 个 ID
    CAN FD 否;按经典 CAN 处理
    发动机 ECU 走 OBD 引脚 7 的 K 线(ISO 14230-4 KWP2000)
    模式 只监听(Silent / listen-only),记录器不在总线上发送

    已解码信号

    源文档对每个信号都写了「怎么验证」的一列,并明确保留未完成核对的条目。下表抽取代表性信号;油量与瞬时油耗两条按源文档原样保留其未完成核对的标注。

    信号 位置(ID / 字节 / 位) 解码 证据
    制动踏板 0x180,b0 位 7 位 踩踏板
    示宽灯 / 近光 / 远光 0x180,b1 位 5 / 3 / 4 各自为 1 位 灯光开关、拨杆
    左 / 右转向灯 0x180,b2 = 0x40 / 0x20 随闪光跳变 拨杆
    发动机是否运转 0x281 用「转速 > 300」判定(不用 b1 位 7) 3 次钥匙测试(仅通电、启动、运转后停机)
    冷却液温度 0x281,b3 b3 − 40 → °C 表针居中时 81 °C
    转速 0x281,b5 与 b6 (b6×256 + b5) / 8 → rpm 怠速约 830,轰油 1800 / 3000
    车速 0x286,b2 与 b3 (b2×256 + b3) / 16 → km/h 4 段稳态行驶与 GPS 差在 1% 内
    车速(副本) 0x2A0,b0 与 b1 (b0×256 + b1) / 16 → km/h 同 0x286
    驻车制动 0x380,b0 位 5 位 拉手刹
    任一车门开 0x380,b1 任一门开时为 0x0C,全关为 0x00 驾驶室门、房车门、储物柜共一条回路
    倒挡 0x380,b2 位 2 位 挂倒挡进出 3 次
    启动电池电压 0x380,b3 b3 × 0.16 → V 与启动电池上的分流计对比 20 分钟行驶
    低油量告警 0x380,b4 位 1 0x02 表示进入储备 与仪表储备灯同亮时 b5 = 11、续航 110 km
    油量 0x380,b5 b5 → 升 另一台满油 90 L 罐读 91;本文档尚未在本车下次加油时交叉核对
    驾驶员安全带 0x39A,b2 位 0 1 = 未系(副本见 0x3C3 b4 位 1) 系/解 3 次,跟随仪表告警灯
    里程 0x603,b1 低半字节 + b2 + b3 20 位 → km 61744 与仪表一致,行驶 7 km 后 +7
    续航 0x603,b4 位 2-0 + b5 11 位 → km 272 与仪表一致
    瞬时油耗 0x603,b0 + b1 高半字节,BCD BCD → L/100km(示例 11 6x = 11.6) 源文档标注「待行驶中验证」
    行程平均油耗 / 平均车速 / 时间 / 距离 0x643,b0-b7 油耗 BCD、车速 km/h、时间 BCD、距离 20 位×0.1 km 与仪表行程电脑一致
    仪表时钟 0x683,b0 / b1,BCD 时 / 分 BCD 与本车仪表钟一致(本车约慢 3 分钟)

    读取方法与注意事项

    第一是速率设置:把记录器设成 50K、静默(Silent)模式,并在协议上选 slcan 以便抓包;源文档提醒设成 500K 会完全看不到流量。第二是总线上没有的东西:增压压力、发动机负荷、进气温度与故障码都在 K 线上,CAN-only 的记录器看不到;源文档把这条写进「不在本总线」一节。

    第三是时间边界的陷阱。源文档给出三条:车钥匙拔出时整条总线静默,什么也读不到;熄火瞬间的最后一帧会「说谎」(油量 0、驻车制动释放、发动机仍报运转),不要基于该边沿做自动化;判断发动机是否运转要用「转速 > 300」,不要用 0x281 的 b1 位 7——它在仅通电、发动机未启动时就是 1,熄火最后一帧和行驶后 ECU 继续发送约 20 秒时也会误报。

    第四是数据回读的取舍:里程、续航与油量没有过期机制,停车时会保留最后值,但在重启或 MQTT 重载后会变成未知值,直到下次通电;需要的话要在自己一侧加保留(retain)。此外作者提到,同一 ID 上的多个按位条目在实践中不一定都能可靠发布,所以灯、刹车、转向被合成一个 24 位原始值再在上层拆分。

    证据等级与边界

    可视为实车证据的是绝大多数条目——源文档逐条写了验证方式(踩踏板、切灯、GPS 对比、与分流计/仪表比对)。属于明确未完成的是油量(本文档尚未在本车加油时交叉核对,数字来自另一台车)与瞬时油耗(标注为待行驶中验证)。

    不能外推的地方有两处。第一,这台是改装房车,车门、房车门与储物柜共用一条回路,所以 0x380 只能给「某个门开着」,不能分辨具体是哪扇门——同平台不同车身(van、底盘车、房车)的门路会不同。第二,源文档只测试了这一台 Ducato X250;同平台的 Jumper/Boxer 未测试,年款差异也可能改变 ID 与位定义。

    关于「安全访问」类问题:源文档未提供任何绕过方法,且不建议尝试;它是纯监听项目,明确「不要在总线上发送报文」。本文只整理公开文档登记的只读信号。

    常见问题

    Ducato X250 的 OBD 口能读到发动机数据吗?

    能读到一部分。源文档说明 OBD 引脚 6/14 是 50 kbit/s 的车身 CAN,引脚 7 是 K 线的发动机 ECU;转速、冷却液温度、车速、里程、续航这些被广播到车身网上的量,CAN-only 记录器可以只监听读到,而增压压力、负荷、进气温度与故障码在 K 线上读不到。

    为什么设成 500K 看不到任何报文?

    因为这张 OBD 口的车身 CAN 跑在 50 kbit/s,源文档说 500 kbit/s 上什么都没有。应设为 50K。

    怎么判断发动机是否在运转?

    用「转速 > 300」。源文档明确不要用 0x281 的 b1 位 7:它在仅通电、发动机未启动时就是 1,熄火最后一帧和行驶后 ECU 继续发送约 20 秒时也会误报。

    为什么熄火后油量显示为 0?

    因为源文档记录熄火瞬间的最后一帧会给出异常值(油量 0、驻车制动释放、发动机仍报运转)。作者建议不要基于这个边沿触发自动化,并让实时传感器用超时机制转为「不可用」而不是冻结。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/danderik88-fiat-ducato-x250/README.md(主来源:车辆、总线、取数路径与坑点)。
    • 项目 01 —— public-can-dbc-datasets/additional/danderik88-fiat-ducato-x250/docs/can-id-reference.md(逐 ID 的信号表与验证方式)。
    • 项目 01 —— public-can-dbc-datasets/additional/danderik88-fiat-ducato-x250/captures/README.md(5 段真实抓包的用途说明)。

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

    更新记录

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

  • Holley EFI 的 29 位 CAN ID:通道索引与参数解码档案

    结论:Holley EFI 系统(HP / Dominator V4+、Terminator X、Sniper V2+ 等)用的是29 位扩展 CAN 标识符,而且把「命令位 + 目标 + 通道索引 + 源 ID + 源序列号」编进 ID 本身。文档记录的结构是:位 28 为命令位(等于 1)、位 27:25 为目标(等于 111 表示广播)、位 24:14 承载通道索引 / 参数标识、位 13:11 为源 ID(等于 010 表示 ECU)、位 10:0 为 ECU 序列号低 11 位。读取侧的关键一步是用 ECU 序列号的低 11 位做过滤(例如序列号 19838 对应 0x57E,即 1406)。默认波特率是 1000000(1 Mbit/s)。边界:源文档是工具说明,参数含义来自官方 DBC,本文不为其数值或安全阈值背书。

    本文整理自该解析工具的 CAN 部分文档。它记录的是「怎么把 Holley 的 ID 与 DBC 对起来」,而不是某一台车的出厂网络定义。

    车辆与适用范围

    这里的「车型」应理解为被记录的 Holley EFI 平台,而非某一款整车:文档适用的产品线是 HP / Dominator(V4+)、Terminator X 与 Sniper(V2+),解码依据是官方 DBC 文件。文档没有绑定到某台具体车辆,也没有给出硬件型号随年款变化的说明。

    项 内容
    车型 / 平台 Holley EFI 系统:HP / Dominator(V4+)、Terminator X、Sniper(V2+)
    年款 / 市场版本 源文档未给出(按产品代次表述)
    ECU / 改装状态 面向后装电喷 ECU;示例 ECU 序列号 19838(CAN ID 中使用 0x57E)
    采集跨度 源文档未给出;示例为一段实时会话与一份 candump 日志
    适用范围 工具与 ID 结构说明;不含具体车辆的整网定义

    总线与寻址

    文档明确使用 29 位扩展标识符,并给出默认波特率 1000000(1 Mbit/s)。没有提到 CAN FD,也没有给出 11 位寻址的用法。ID 的位域划分本身就是寻址方式的一部分,见下表。

    项 内容
    物理层 CAN,默认波特率 1000000(1 Mbit/s,文档默认值)
    链路层 29 位扩展标识符
    寻址 ID 内置:命令位(位 28)、目标(位 27:25,111 为广播)、通道索引(位 24:14)、源 ID(位 13:11,010 为 ECU)、源序列号低 11 位(位 10:0)
    CAN FD 源文档未提及
    多 ECU 按 ECU 序列号低 11 位过滤,用于多 ECU 同总线场景

    已解码信号

    下表分两部分:ID 位域(用来定位是哪个 ECU、哪个通道)与参数(由官方 DBC 解码的量)。源文档是工具说明,未对单个参数标注置信度;参数含义来自官方 DBC,安全阈值则是「可配置的代码取值」,不是厂商规格。

    条目 位置 解码 / 含义 证据
    命令位 ID 位 28 等于 1 表示命令 源文档 ID 结构说明
    目标 ID ID 位 27:25 111 表示广播 源文档 ID 结构说明
    通道索引(参数标识) ID 位 24:14 标识具体参数通道 源文档 ID 结构说明
    源 ID ID 位 13:11 010 表示 ECU 源文档 ID 结构说明
    源序列号(低 11 位) ID 位 10:0 取 ECU 序列号低 11 位;例:19838 用 0x57E(1406) 源文档 ID 结构说明
    RPM 示例 0x9E005000,ECU 1406,通道 8 DBC 解码;示例值 6500 rpm 源文档示例输出
    FUEL_AFR_AVERAGE DBC 消息 由 DBC 解码 源文档配置示例
    OIL_PRESSURE DBC 消息 由 DBC 解码;文档阈值 警告 30 psi、危险 20 psi 源文档阈值表
    COOLANT_TEMP DBC 消息 由 DBC 解码;阈值 警告 210 华氏度、危险 230 华氏度 源文档阈值表
    机油温度 DBC 消息 阈值 警告 250 华氏度、危险 280 华氏度 源文档阈值表
    燃油压力 DBC 消息 阈值 警告 40 psi、危险 30 psi 源文档阈值表
    爆震退点火 DBC 消息 阈值 警告 2 度、危险 4 度 源文档阈值表
    增压 DBC 消息 阈值 警告 20 psi、危险 25 psi 源文档阈值表
    转速阈值 RPM 参数 警告 7000、危险 8000 源文档阈值表
    DL 日志参数 二进制日志列 Param_002 = RPM、Param_066 = TPS,共 516 个参数 源文档参数表

    读取方法与注意事项

    先按序列号过滤。解析器会自动提取 ECU 序列号的低 11 位用于匹配,因此多 ECU 同总线时,必须先填对序列号,否则会同时看到别的 ECU 的消息。

    DBC 决定字段含义。参数名与单位来自官方 DBC(文档列出的文件包括 HP Dominator & Terminator X DBC.dbc、Sniper V2 DBC.dbc、HARDWIRE HOLLEY DBC FILE.dbc)。DBC 放错或不匹配,字段会解不出或解错。文档建议把 DBC 放在同目录或用 --dbc 指定完整路径。

    实时与离线两条通道。实时侧可直接监听 can0 等接口(无需先跑 candump),也可把 candump 文本通过管道或文件喂给解析器;输出支持人类可读、JSON、CSV 与实时仪表盘四种格式,仪表盘可按 --minmax 跟踪最小 / 最大值并同时 --record 录制。

    二进制日志的格式差异。同一仓库还处理 .DL / .DLZ 日志:.DLZ 先做字节交换、RLE 解压、再字节交换;.DL 分 V3(魔数 0x0095365F)、V4 / V5(魔数 0x0085F41F)与 V6。文档说明 V5 为稀疏存储、无法直接解析,需要先在官方软件里打开转换成 V6;V6 可端到端解析。

    证据等级与边界

    源文档是工具说明,没有为单个参数标注置信度。表中「解码 / 含义」一列,凡属参数含义者都来自官方 DBC;凡属数值(如 RPM 6500)都是示例输出;凡属阈值(如 OIL_PRESSURE 20/30 psi)都是「代码里可配置的取值」,文档原文即写明可配置,因此不能当作厂商规格或安全红线。

    范围边界同样清楚:这套 ID 结构与 DBC 面向的是 Holley 的后装 EFI 平台,不是某一款整车的出厂网络;文档未绑定具体车辆、年款或整车网络,也未提供实车验证结论。任何字段值、阈值或「安全」判断,都应回到你自己的 ECU、DBC 与实车数据上复核,不能跨平台外推。

    常见问题

    Holley EFI 的 CAN ID 为什么用 29 位?

    因为它要在 ID 里同时编码「谁发的、发给谁、哪个通道、什么命令」。文档给出的划分是:位 28 命令、位 27:25 目标(111 广播)、位 24:14 通道索引、位 13:11 源 ID(010 为 ECU)、位 10:0 源序列号低 11 位。

    总线上有多个 ECU,怎么只看其中一个?

    按 ECU 序列号过滤。解析器自动取序列号的低 11 位做匹配,例如序列号 19838 对应 ID 中的 0x57E(1406);填错序列号会解到别的 ECU 的消息。

    默认波特率是多少?

    文档默认值是 1000000,即 1 Mbit/s。可在命令行用 --bitrate 覆盖。

    .DLZ 和 .DL 是什么关系?

    .DLZ 是压缩日志,文档给出的解压步骤是字节交换、RLE 解压、再字节交换。解出的 .DL 分 V3 / V4 / V5 / V6;其中 V5 为稀疏存储、不能直接解析,需在官方软件里转成 V6 才能端到端解析。

    文档里的阈值能当安全结论用吗?

    不能。文档原文写明这些阈值是「代码里可配置」的取值,不是厂商规格或安全红线。它们只用于实时仪表盘的红 / 黄 / 绿显示,实际判断需回到你自己的标定与实车数据。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/hackinglz-holley-efi/can/README.md(本项目车型档案主来源,取用了 Holley CAN ID 结构与参数阈值表)。
    • 项目 01 —— public-can-dbc-datasets/additional/hackinglz-holley-efi/README.md(取用了 DL / DLZ 日志格式与参数列说明)。

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

    更新记录

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

  • 雪铁龙 C2 的 CAN-Confort:125 kbit/s 上解码 16 个 PSA 标识符

    结论:在一辆雪铁龙 C2 1.1(TU1JP,BSI AEE2004,EMF 为 Magneti Marelli)上,舒适总线 CAN-Confort 是 125 kbit/s、11 位标识符,而且它不经过 OBD 口——只能在收音机后方的 Quadlock 连接器(pin 10 CAN-H、pin 13 CAN-L)上接入。文档在该总线上识别出 16 个 PSA AEE2004 标识符,并解码转速、车速、水温、车门、灯光、方向盘按钮、续航与保养提醒等信号。边界有三条:部分信号只有单点标定或来自公开参考结构、未在本车验证;外部温度与总里程存疑;结论只覆盖这一辆 C2,不能外推到其他 C2 或 PSA 车型。

    本文整理自该项目的 CAN 解码文档。文档为每个信号标注了证据等级,本文原样保留其分级。

    车辆与适用范围

    数据来自一位车主的这辆 C2;原车 RD4 收音机换为一台后装安卓车机,解码用于方向盘控制、实时仪表与多功能屏(EMF)操控。

    项 内容
    车型 雪铁龙 C2 1.1(发动机 TU1JP,BSI AEE2004,EMF 为 Magneti Marelli)
    年款 / 市场版本 源文档未给出具体年款(PSA C2 平台文档标注为 2003–2009,BSI 第二代)
    ECU / 改装状态 原车 RD4 收音机已拆,替换为后装安卓车机;由一款 SLCAN 协议的开源 CAN 适配器接入
    采集跨度 实车现场测试 2026-04-26;配合诊断工具截图的标定会话 2026-05-03
    适用范围 仅这一辆 C2;多条标定仍需在车上复核

    总线与寻址

    目标是舒适总线 CAN-Confort,速率 125 kbit/s、11 位标识符。接入点在收音机后方的 Quadlock,pin 10 为 CAN-H、pin 13 为 CAN-L;文档明确指出 OBD 口不暴露这条总线,因此不能从诊断座直读。适配器未加 120 Ω 终端电阻(文档说明总线本身已有终端)。

    项 内容
    物理层 CAN-Confort,125 kbit/s(区别于 500 kbit/s 的 CAN-IS)
    链路层 11 位标识符
    接入点 收音机 Quadlock:pin 10 CAN-H、pin 13 CAN-L;OBD 口不暴露该总线
    CAN FD 源文档未提及,按 125 kbit/s 的 AEE2004 语境应视为经典 CAN
    现场总线负载 约 185 帧/秒、38 个不同标识符(现场测试记录)

    已解码信号

    下表从文档信号表中抽取代表性条目,证据等级沿用原文:✅ 在本车验证(现场测试或用户确认)、🎯 只用一个测量点标定(该点正确、斜率未验证)、📄 取自公开的 AEE2004 参考结构(未在本车验证)、⚠ 来源互相矛盾。字节从 0 起编号,BE 为大端。

    信号 位置(ID / 字节) 解码 证据
    发动机转速 rpm 0x0B6 字节 0-1(BE) ÷ 8,四舍五入到 0.1 转/分 ✅ 怠速 704–768 转/分(诊断工具读数)
    车速 speed 0x0B6 字节 2-3(BE) ÷ 100,四舍五入到 0.1 km/h ✅ 静止时确认;行驶中待与 GPS 比对
    冷却液温度 tCoolant 0x0F6 字节 1 字节 − 53 摄氏度;0xFF 表示未就绪(null) 🎯 92 摄氏度对应 0x91(测量中水温在 86–92 波动)
    总里程 odo 0x0F6 字节 2-4(BE) ÷ 10 公里;0xFFFFFF 表示未就绪 ⚠ 取自参考结构;现场测试未找到对应图案
    外部温度 tExt 0x0F6 字节 6 字节 − 102 摄氏度;0xFF 表示未就绪;另加用户偏移 ⚠ 三种假设互相矛盾
    倒挡 reverseGear 0x0F6 位 7.7 位为 1 表示挂倒挡 📄 参考结构
    手刹 handbrake 0x128 位 0.5 位为 1 表示手刹拉起 ✅
    转向灯(左 / 右) 0x128 位 4.1 / 4.2 对应位为 1 表示点亮(双闪为两位同时) ✅
    远光 / 近光 / 示宽灯 0x128 位 4.5 / 4.6 / 4.7 对应位为 1 表示点亮 ✅
    机油温度 tOil 0x161 字节 2 字节 − 64 摄氏度;0x00 与 0xFF 表示未就绪 🎯 71 摄氏度对应 0x86(算出 70)
    燃油百分比 fuelPct 0x161 字节 3 直接取百分比 ✅ 用户确认(2026-05-09)
    续航 rangeKm 0x221 字节 3-4(BE) 公里;0xFFFF 表示未计算 ✅ 440 km(帧内 0x01B8)
    瞬时油耗 fuelInst 0x221 字节 1-2(BE) ÷ 10 升/百公里;0xFFFF 表示未计算(停车时) 📄 与诊断工具「停车时显示未计算」一致
    方向盘按钮 0x21F 字节 0(位图) 位 1 源、位 2 音量减、位 3 音量加(本车与通用文档相反)、位 6 上一曲、位 7 下一曲 ✅ 本车完全验证
    车门(驾驶员 / 乘客 / 尾门) 0x220 位 0.7 / 0.6 / 0.3 对应位为 1 表示打开 ✅
    平均油耗 tripAvgCons 0x261 字节 4 ÷ 10 升/百公里 ✅ 7.6 升/百公里对应 0x4C

    读取方法与注意事项

    哨兵值一律视为「未就绪」。文档规定:温度为 0xFF、里程为 0xFFFFFF、0xFFFF 类字段在充电或刚唤醒时代表「尚未可用」,解码器应输出 null,绝不当作真实数值。

    节奏由 0x0B6 决定。0x0B6 以 20–50 Hz 发送,界面按 10 Hz 采样,音频逐帧跟随。

    按钮要防抖,并注意本车接线方向。0x21F 的字节 1 是滚轮的累计计数,应用需自行计算两帧之间的带符号差值。信号处理采用上升沿加 200 毫秒防抖。这台 C2 的 VOL+ 与 VOL− 与通用文档相反,位图不能照抄。

    发送会落在真车上。文档列出的发送帧(如多功能屏按键、校时帧)会直接发到车辆实际总线,有风险。关于用 CAN 设置 EMF 时钟:文档记录了多次尝试与「未提供可行方法,也不建议尝试」的结论——校时要么走多功能屏自身的菜单,要么依赖原车收音机的私有序列,不存在文档化的 CAN 校时方案。

    证据等级与边界

    文档的分级是硬边界:✅ 本车验证,🎯 只有单点标定(点正确、斜率未验证),📄 取自公开参考结构未在本车验证,⚠ 来源互相矛盾。也就是说,🎯 与 📄 两类条目尚未在这辆 C2 上成立,不能当作已确认字段使用。

    文档还专门列出「待复核」清单:外部温度存在三种互斥假设,都只在 23 摄氏度一点上对齐,斜率未验证;总里程来自参考结构但现场测试未找到对应图案,且参考诊断点自身也不自洽;机油 / 水温斜率只有一个点;行驶中的车速尚待与 GPS 比对;保养 0x3A7 与行程距离 0x261 的格式也未确认。

    另有至今未找到的信号:电池电压、进气温度、BSI 时间(0x276 帧缺失)、EMF 时钟(不能通过 CAN 设置)。这些应记为「未确认」,而非「不存在」。所有结论限于这一辆 C2,不能外推到其他 C2 或 PSA 车型——本车已经出现了与通用文档相反的方向盘按钮接线,正说明逐车核对是必需的。

    常见问题

    雪铁龙 C2 的 CAN-Confort,能从 OBD 口直接读吗?

    不能。文档明确指出 OBD 口不暴露这条总线,接入点是在收音机后方的 Quadlock 连接器(pin 10 CAN-H、pin 13 CAN-L),速率 125 kbit/s、11 位标识符。

    为什么车速在静止时已确认,行驶中还要再核对?

    因为静止时只能确认零值与量程端点,无法验证斜率。文档把「行驶中把 speed 与 GPS 比对」列为待办,说明该字段在动起来之后仍需独立确认。

    为什么这台车的 VOL+ 和 VOL− 与通用 PSA 文档相反?

    文档记录这台 C2 的接线本身就把 VOL+ 与 VOL− 对调了。方向盘按钮 0x21F 虽已在本车完全验证,但位图不能照抄通用文档,必须按本车实测为准。

    外部温度和总里程为什么被标成存疑?

    外部温度有三种互斥假设,且都只在 23 摄氏度这一个点上对齐,斜率未验证;总里程取自公开参考结构,但现场测试未在总线上找到与仪表读数对应的图案,参考诊断点自身也不自洽。两者都需要更多实车数据才能确定。

    能用 CAN 设置多功能屏(EMF)的时钟吗?

    文档记录的全部尝试都失败了,并明确给出「源文档未提供可行方法,也不建议尝试」的结论。校时只能走多功能屏自身菜单,或依赖原车收音机的私有序列;不存在文档化的 CAN 校时方案。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/wasabules-citroen-c2/docs/can/signaux_decodes.md(本项目车型档案主来源,取用了信号表与证据分级)。
    • 项目 01 —— public-can-dbc-datasets/additional/wasabules-citroen-c2/docs/can/psa_can_confort.md(取用了 CAN-Confort 的通用标识符与载荷说明)。
    • 项目 01 —— public-can-dbc-datasets/additional/wasabules-citroen-c2/docs/can/c2_field_test_results.md(取用了现场测试的验证项与失败尝试记录)。

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

    更新记录

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

  • VW PQ35 ABS 仿真器档案:Bremse 帧与 0x7E9 车速

    结论:这份档案记录的是 VW PQ35 平台上一组用于「替代原厂 ABS 模块后恢复仪表」的 CAN 报文:一台开源设备(ESP32 + MCP2515)从 OBD 地址 0x7E9 读取 09G 变速箱的车速(PID 0x0D),再向动力总成 CAN(500 kbit/s)发送 Bremse_* 系列帧,让车速表与里程表继续工作。源文档反复强调:它只恢复仪表信号,不恢复 ABS 制动与稳定控制,且没有真实 ABS 帧时制动系统可能报警或表现异常。下述说明仅限源文档记录的那一台车(2009 Jetta 2.5 / 09G / PQ35)。

    车辆与适用范围

    源文档是一个开源仿真器项目的说明,属于单台车实测 + 标定。它同时列出若干「大概率兼容」的车型,但明确标注这些只是推测,只有 Jetta 2.5 2009 一台被标为已测试。校准默认值是按这一台车标定的。

    项 内容
    车型 VW Jetta 2.5 2009(PQ35 平台)
    年款 / 市场版本 2009;源文档未给出市场版本
    ECU / 改装状态 09G 自动变速箱 TCU、MK60EC1 ABS 模块、PQ35 仪表;ESP32 Dev Module + MCP2515 接入动力总成 CAN
    采集跨度 源文档未给出日志数或帧数;标定基于实车速度与里程比对
    适用范围 仅 Jetta 2.5 2009(09G)被标为已测试;Rabbit/Golf 2006-2009、Audi A3 2006-2009、Passat 2006-2010、Skoda Octavia 2006-2008 均标为「大概率(Likely)」,需 09G TCU + MK60EC1 + 500 kbit/s 动力总成 CAN

    总线与寻址

    源文档明示接入的是动力总成 CAN(Powertrain CAN,500 kbit/s),不是舒适 CAN;MCP2515 需 8 MHz 晶振、移除 120 Ω 终端跳线(除非它是总线末端节点)。OBD 响应地址为 0x7E9,源文档未展开 11 位 / 29 位差异,但所列 ID(0x1A0、0x440 等)均为 11 位经典 CAN 口径。

    项 内容
    物理层 双绞屏蔽线 CAN;动力总成 CAN 高/低;两端各 120 Ω 终端
    链路层 / 比特率 500 kbit/s(源文档明示 VW 动力总成标准)
    寻址方式 11 位 ID(0x1A0、0x4A0、0x5A0、0x3A0、0x7E9、0x440、0x540 等)
    CAN FD 否;源文档按经典 CAN 8 字节处理
    方向 设备向总线发送 Bremse_* 帧;从 0x7E9 / 0x440 / 0x540 接收车速与挡位

    已解码信号

    下表登记源文档明确给出的发送帧与接收帧及其周期与用途。涉及具体信号位域的部分,源文档只给到「16 位原始值在 bits 17-31」「每位 10 位」这类粒度,未逐位展开。

    帧 / 信号 位置(ID / 位域) 解码 / 用途 证据
    车速(主来源) 0x7E9(TCU,09G),PID 0x0D OBD 响应读车速;驱动仪表与里程计算的输入 源文档「RX」表
    挡位 Getriebe_1(wahl) 0x440(TCU) 挡位选择,用于运动状态判定 源文档「RX」表
    接合挡 Getriebe_2 0x540(TCU) 接合挡与档位显示,用于驻车判定 源文档「RX」表
    Bremse_1 轮速 0x1A0,16 位原始值在 bits 17-31 车速表主来源;周期 10 ms 源文档「TX」表
    Bremse_3 轮速(冗余) 0x4A0,同 Bremse_1 部分仪表需要此冗余帧;周期 10 ms 源文档「TX」表
    Bremse_2 中轮转数与里程脉冲 0x5A0,16 位中轮转数 + 时间计数器 + 6 位里程脉冲 驱动里程计数;周期 20 ms;空闲用原始值 127(中性) 源文档「TX」表与 v2.0 安全说明
    Bremse_10 单轮脉冲 0x3A0,VL/VR/HL/HR 各 10 位 供 ABS 模块使用的单轮脉冲;周期 20 ms 源文档「TX」表
    Bremse_5 静止位 0x4A8,10 ms ESP 帧——静止位,中性加速度避免误报 源文档「TX」表
    Bremse_8 纵/横向加速度 0x1AC,20 ms 中性值 127 / 361 / 512,用于抑制错误的 ABS/ESP 报警 源文档「TX」表与 v2.0 说明
    Bremse_6 加速度帧 0x1A8,3 字节,10 ms 中性加速度 源文档「TX」表
    Bremse_11 校验帧 0x5B7,20 ms 中性校验值 源文档「TX」表
    Bremse_4 Haldex 帧(可选) 0x2A0,3 字节,20 ms 仅当开关打开时发送 源文档「TX」表

    读取方法与注意事项

    第一,源文档把「恢复什么、不恢复什么」写得很直白:恢复的是车速表指针、里程表公里数与车辆运动状态;不恢复的是 ABS 制动与稳定控制、实时加速度遥测、OBD2 诊断码,以及(没有 Getriebe 报文时的)挡位显示。因此这台设备不是「修复 ABS」,而是让仪表在没有原厂 ABS 模块时继续工作。

    第二,校准有三个默认值且都针对这一台车:车速表偏置修正系数 1.084、里程脉冲/km 系数 0.2581、车轮周长 1.985 m。源文档给出求值方法,例如车速系数可用「GPS 速度 / 表显速度」反推,里程系数用「OBD 脉冲 vs 实际公里」按比例调整,车轮周长按轮胎规格或实测滚动法获得。调整步长建议 ±0.01。

    第三,安全上与「误报」相关的是中性值:源文档在 v2.0 把 Bremse_2 的静止值设为 127、Bremse_8 的加速度中性值设为 127/361/512,目的就是避免触发错误的 ABS/ESP 警告灯;若灯亮,源文档建议先核对这三个中性值。

    第四,可诊断性:串口 115200 输出循环耗时、滤波前后车速、脉冲计数、TX 失败计数、堆/栈占用等指标;源文档提示循环耗时过大(>12 ms)说明时序有问题,TX 失败非零说明缓冲溢出或总线冲突,栈低于阈值会提示栈溢出风险。

    证据等级与边界

    可视为实车证据的是「已测试」一台车与三组默认标定值,以及 0x1A0/0x4A0/0x5A0 等帧 ID 与周期。属于推测的是「大概率兼容车型」列表,源文档用 Likely 标注,并要求用「OBD 响应地址、DBC 帧 ID 匹配、上路前用监测工具验证」三步自行确认。

    不能外推的地方有三处。第一,兼容性依赖三个前提同时成立:09G TCU、MK60EC1 ABS、500 kbit/s 动力总成 CAN;缺一即不适用。第二,标定值是单台车的,车速修正与里程系数在不同轮胎、不同表头下会不同。第三,源文档明确声明设备不恢复 ABS/ESP,制动行为可能异常,任何「照抄即上路」都超出证据范围。

    关于「安全访问」类问题:源文档未提供任何绕过方法,且不建议尝试;本文只整理公开文档登记的报文与标定,不涉及对车辆安全机制的规避。

    常见问题

    装上这个仿真器后 ABS 会恢复吗?

    不会。源文档明确写它只恢复仪表信号(车速表、里程表、运动状态),不恢复 ABS 制动与稳定控制;没有真实 ABS 帧时制动系统可能报警或行为异常。

    车速是怎么来的?

    设备从 0x7E9(09G TCU 的 OBD 响应,PID 0x0D)读取车速,再据此驱动 Bremse_1(0x1A0)/Bremse_3(0x4A0)的轮速与 Bremse_2(0x5A0)的里程脉冲。

    车速表读数偏高/偏低怎么办?

    调整车速表偏置修正系数(默认 1.084)。源文档给的方法是以恒定 GPS 速度行驶,比较表显值,用「GPS 速度 / 表显速度」推系数,再以 ±0.01 步长微调。

    为什么里程表不动?

    源文档把里程不增归因于里程脉冲/km 系数(默认 0.2581)不对,建议先核实车轮周长,再用实际距离与 OBD 脉冲比对后按比例调整。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/pandolfipedro-pq35-abs/README.md(主来源:车辆、总线、TX/RX 帧表、标定与安全说明)。

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

    更新记录

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

  • 2017 Subaru BRZ 的 CAN 帧阅读笔记:端序、位序号与 WIP 配置

    结论:这台 2017 款 Subaru BRZ 的档案记录的不是一张成品信号表,而是一套「怎么读 CAN 帧」的方法笔记:如何区分 Motorola/大端与 Intel/小端、位序号为什么与端序无关、商业仪表工具里的 offset/length/startbit/bitcount 分别指什么,以及用回放脚本在没有实车时验证解码。主素材明确这是进行中(WIP)的工作,配置里的偏移、缩放与标签尚未逐条与保留的抓包核对;因此本文把它当作方法记录,而不是可直接套用的信号定义。下述结论仅限源文档记录的这一台车。

    车辆与适用范围

    源文档是车主对自己车辆的私有研究记录。按项目的来源说明,车辆是作者的 2017 Subaru BRZ,配置、市场与 ECU 变体未完全说明;仓库没有找到许可或再分发授权,因此属于非公开的研究副本。文档给出的抓包是作者自述的一段「普通短途驾驶」,共 23,451 行数据。

    项 内容
    车型 2017 Subaru BRZ(据仓库说明)
    年款 / 市场版本 2017;源文档未给出配置、市场版本与 ECU 变体
    ECU / 改装状态 取自 OBD 口的主 CAN 广播;作者用某款 OBD-USB 适配器按 500k 波特率读取
    采集跨度 保留一段约 23,451 行数据的短途驾驶日志;来源说明另提到其他抓包未一并保留
    适用范围 仅限这一台 2017 BRZ;配置的偏移、缩放与标签尚未与抓包逐条核对

    总线与寻址

    源文档按「8 字节 / 64 位经典 CAN 帧」讲解,没有涉及 CAN FD。示例帧是 0x141: 84 26 95 27 B1 82 A7 00,作者用它演示如何定位第 43 位。文档还提醒:商业仪表工具展示字节顺序的方式与常见约定不同,要单独留意。

    项 内容
    物理层 双绞线 CAN;作者按 500k 波特率读取(据文档自述)
    链路层 / 比特率 500 kbit/s(文档自述)
    寻址方式 源文档以 11 位示例 ID(如 0x141、0x0d3)讲解,未展开 11 位 / 29 位差异
    端序 Motorola = 大端,Intel = 小端;小端按递增字节地址读,大端按递减字节地址读
    位序号 全帧 64 位序号固定:字节 0 的位 0 是第 0 位,字节 1 的位 0 是第 8 位,依此类推;端序不改变位序号
    CAN FD 源文档未涉及

    已解码信号

    主素材没有给出成品信号表,只给了一个示例帧与若干配置属性。为守住「只抄有证据的条目」这条线,下表登记源文档明确写出的字段与规则,涉及具体缩放/标签的条目一律标注为未逐条核对。

    字段 / 规则 位置 解码 / 说明 证据
    Custom_Engine_Torque 0x141,bitcount=15 自定义输入;示例未给缩放 README 示例配置
    Engine_Engine_Stop 0x141,startbit=15,bitcount=1 1 位,单位 bit README 示例配置
    Wheel_Torque 0x141,offset=2(第 3 个字节) 示例未给长度与缩放 README 示例配置
    转速类目标值 0x141,offset=4,length=6 映射到商业仪表工具的 RPM 输入(targetId 37) README 示例配置
    车速 长度不足 8 字节的帧(示例 0x0d3) 回放补零后读不准,作者说明该信号受补零影响 README「回放」小节
    帧 ID 写法 XML 的 frame id 可为十进制或 0x 前缀十六进制;若外层有 baseId 则最终 ID = baseId + id README「frame id」小节
    值的 name 与 targetId XML 的 value 有 targetId 则写入工具内置输入;否则用 name 新建 ECU-Specific 自定义输入 README「value」小节
    配置规模 WIP 配置 28 个 frame 元素、145 个 value 元素;偏移、缩放、标签未逐条核对 来源说明
    位序号查找法 任意帧 先把每字节转 8 位,再按全帧序号表定位目标位 README「位序号」小节

    读取方法与注意事项

    第一条是端序与位序号要分开理解。源文档反复强调「位的位置不会因为端序改变」:不管大端小端,第 43 位永远是第 5 个字节里从右边数第 4 个位(位 3)。端序只影响你按什么顺序把连续的字节拼成一个多字节数值。混用是这类解码最常见的错误来源。

    第二条是配置属性的含义——startbit 是开始读的位,bitcount 是一次读多少位,offset 是从哪个字节开始(十六进制),length 是连续读几个字节。作者用一款商业 CAN 数据库编辑器做可视化对照来推导这些含义,因为该工具的术语与仪表工具不同。

    第三条是回放验证的坑。源文档说明其回放脚本会把不足 8 字节的帧用零补齐,例如 0x0d3: 00 06 C0 0F 00 00 42 会变成 8 字节。补零等于给多字节字段多加了 16 位,会改变按位计数与端序结果,因此「用回放测车速」这类信号会读不准。作者建议回放时把推送速率设到能产出约 400 帧/秒,以接近实车从 OBD 口 500k 波特率读到的速率。

    证据等级与边界

    属于方法性、可核对的:端序与位序号的对应规则、配置属性含义、帧 ID 与 baseId 的加法规则。属于未验证的:整套 WIP 配置的偏移、缩放与标签——来源说明写明它们「没有被独立地对照保留的抓包检查过」,而且这套配置是从公开的前代 Subaru DBC 改编而来。

    两处不能外推。第一,车辆本身就是单一样本,且配置、市场与 ECU 变体未说明;同型号不同配置不宜套用。第二,回放脚本的补零行为会系统性歪曲短帧信号,任何用回放得到的数值都不能当作这台车的真实解码结果。

    关于「安全访问」类问题:源文档未提供任何绕过方法,且不建议尝试;本文只整理公开文档记录的解码方法,不涉及对车辆安全机制的规避。

    常见问题

    大端和小端只影响读的顺序吗?

    是的。源文档说明位的位置不会因端序改变,改变的只是你按什么顺序把连续字节拼成多字节数值:小端按递增字节地址读,大端按递减字节地址读。

    第 43 位在示例帧里怎么找?

    按源文档的全帧序号表,第 43 位位于第 5 个字节(示例中为 0x82)内从右数第 4 位(位 3),该帧此位为 0。这个方法与端序无关。

    为什么回放测车速不准?

    因为回放脚本把不足 8 字节的帧用零补齐,等于给字段多加 16 位,改变了按位计数与端序结果。源文档明确说车速信号正来自一个不足 8 字节的帧,因此受此影响读不准。

    这份配置里的 ID、缩放能直接拿来用吗?

    不能直接当作已验证结果。来源说明指出这套 WIP 配置的偏移、缩放与标签尚未与保留抓包逐条核对,且改编自公开的前代 Subaru DBC;使用前需自行复核。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/painellope-brz-2017/CAN_Decoding/README.md(主来源:CAN 帧阅读方法、示例帧与配置属性说明)。
    • 项目 01 —— public-can-dbc-datasets/additional/painellope-brz-2017/SOURCE.md(快照范围、配置规模与「未逐条核对」的边界提示)。
    • 项目 01 —— public-can-dbc-datasets/additional/painellope-brz-2017/CAN_Decoding/CAN_Frame_Datalogs/fileIndex.md(保留抓包的用途与回放补零说明)。

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

    更新记录

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

  • 日产 Leaf ZE1:0x1DA 与 0x1D4 的 CRC 同多项式、两种算法

    结论:在一份以日产 Leaf ZE1 命名的 CAN 数据库与配套研究文档里,0x1DA 与 0x1D4 两个帧使用同一个 CRC 多项式 0x85(MSB-first),但算法细节不同:0x1DA 校验时把帧 ID 字节 0xDA 拼进输入并输出异或 0xBF;0x1D4 生成校验时不拼帧 ID、也不做输出异或,只对 b0 至 b6 求 CRC。第三帧 0x11A 则根本没有 CRC 字节,b7 是多路复用(mux)载荷。需要强调:源文档自己的来源说明写明这些 CRC 结论属于「上游声明、未在本归档独立核验」,且该车型的精确年款、配置与固件均未确认。

    本文整理自该研究文档与一份 ZE1 命名的 DBC 快照。文中所有结论的边界,都以下文「证据等级与边界」一节为准,不做拔高。

    车辆与适用范围

    素材包含两部分:一份以 Leaf ZE1 命名的 DBC(含 48 条消息、257 条信号行),以及作者围绕 0x1DA、0x1D4 的 CRC 处理所写的研究文档。文档称 CRC 结论曾用 4 帧已知良好的参考帧校验,但那 4 帧来自第三方 VCU 样机与日产逆变器的采集,并非本归档内独立复核。

    项 内容
    车型 日产 Leaf(DBC 以 ZE1 命名,即 Leaf-CAN_ZE1.dbc)
    年款 / 市场版本 源文档未确认;精确年款、配置与固件 applicability 均未建立
    ECU / 改装状态 涉及逆变器状态帧与扭矩请求帧;文档语境为第三方 VCU 搭配日产逆变器的样机
    采集跨度 CRC 结论基于文档所述 4 帧参考帧;未给出完整日志规模
    适用范围 仅限该 DBC 快照与文档所声明的帧;不得外推至其他年款或固件

    总线与寻址

    本文素材没有给出该车的物理层速率或 11 位 / 29 位寻址结论,也没有 CAN FD 的说明。文档讨论的是帧级 CRC 与字段布局,工作对象是 0x1DA、0x1D4、0x11A 三个 8 字节帧。下表只列文档明确涉及的内容,其余标注为源文档未给出。

    项 内容
    物理层速率 源文档未给出
    寻址 源文档未给出 11 位 / 29 位结论
    CAN FD 源文档未提及
    帧长 所涉三个帧均为 8 字节载荷
    校验字段位置 0x1DA 与 0x1D4 的 CRC 在 b7;0x11A 无 CRC,b7 为 mux 载荷

    已解码信号

    下表汇总文档给出的 CRC 参数、帧结构与 DBC 片段中的字段。凡未标注独立复核的,均沿用「上游声明」边界。位宽写法如 23|12 表示起始位 23、宽 12 位;@0- 表示 Motorola 字节序、有符号。

    信号 位置(ID / 位域) 解码 证据
    CRC_1D4(发送校验) 0x1D4 b7(DBC 56|8) poly 0x85、init 0x00、无输出异或、输入为 b0 至 b6(不拼帧 ID) 上游声明,未独立核验
    0x1DA 线上校验 0x1DA b7 poly 0x85、init 0x00、输出异或 0xBF、输入为 [0xDA, b0..b6] 上游声明;按文档所述对 4 帧参考帧吻合
    时钟选择 clock 0x1DA b6 低 2 位 clock = b6 与 0x03 上游声明
    HCM_CLOCK 0x1D4 38|2 2 位计数,对应 b4 滚动(见下) DBC 片段
    MotorAmpTorqueRequest 0x1D4 23|12 @0- 比例 0.25,范围 0 至 1024 Nm DBC 片段
    ChargeStatus 0x1D4 48|8 MODEMASK 取值 DBC 片段
    StatusOfHighVoltagePowerSupply 0x1D4 34|1 1 位状态 DBC 片段
    Relay_Plus_Output_Status 0x1D4 46|1 1 位状态 DBC 片段
    JoystickGearPosition 0x11A 4|4 4 位 DBC 片段
    CarOnOffStatus 0x11A 13|3 3 位 DBC 片段
    Multiplexor M(mux) 0x11A 48|8(b6) 选择器,逐帧 0、1、2、3 循环 DBC 片段与文档
    HeartbeatVCM 0x11A 24|8(b3) 取值在 85 与 170 之间(文档记 b1 应为 0x40) DBC 片段
    ECOselected 0x11A 12|1 1 位 DBC 片段
    0x11A 的 mux 载荷 0x11A b7 mux0 至 3 对应 0x6B、0xEE、0xE4、0x61 文档表

    读取方法与注意事项

    接收侧校验。对 0x1DA,文档的做法是:用 [0xDA, b0..b6] 求 poly 0x85、init 0x00、xorOut 0xBF 的结果,与收到的 b7 比较,不等即判为坏帧;文档还给出一种运行时策略——连续坏帧达到 10 次则关闭 CAN 回退。

    发送侧构造(文档语境)。0x1D4 每 10 毫秒发送一次:b0、b1 为静态 0x6E,b2、b3 为 0x00,b4 是滚动计数器,b5 为静态充电状态 0x44,b6 为静态 0x01,b7 填入按上文规则算出的 CRC。文档强调 b4 的计数器必须按 0x87 → 0xC7 → 0x07 → 0x47 循环,且 0x11A 的 b1 必须是 0x40,否则逆变器会持续拒帧。

    第三帧无 CRC。0x11A 是每 10 毫秒的心跳:b0 至 b5 为静态字节,b6 逐帧循环 0、1、2、3 作 mux 选择器,b7 随 mux 取对应值,没有校验字节。文档把 b7 明确称为「启动 / mux 载荷数据」,并指出它「不是 CRC 字节」。

    操作提示。以上帧属于车辆逆变器通信;任何在真实总线上发送或改写这些帧的操作都会影响实车,风险自负。本文只转述源文档的算法描述,不构成操作指引;源文档未提供安全访问绕过方法,也不建议尝试。

    证据等级与边界

    第一层边界来自来源说明本身:该归档明确写着,DBC 与其中若干信号「解析器兼容性与信号准确性需要独立复核」,且文中标注了诸如 SG_: 这样的畸形语法与形如 4294967256 这类不合理的无符号物理下限;CRC 结论是上游声明,未在本归档独立验证;精确车型年款、配置与固件 applicability 未确认。许可方面,检查的快照中也没有发现通用仓库许可证,仅作为私有离线研究副本保留。

    第二层边界来自文档自己的措辞:它把结论表述为「已验证并工作」,但依据的 4 帧参考帧来自第三方样机,不是本归档的实测;文档另记录了三类被否定的旧做法(例如错误的 0x1D29 多项式),不应被当作可用方案。

    因此,本文给出的 CRC 参数、计数器循环与字段布局,只能视为「这份 ZE1 命名 DBC 与这份文档所声明的范围」,不能外推到其他 Leaf 年款、其他固件或其他逆变器组合。需要真值时应以实车采集与独立复核为准。

    常见问题

    0x1DA 和 0x1D4 的 CRC 到底差在哪?

    差在两处:0x1DA 把帧 ID 字节 0xDA 拼进输入、并对结果异或 0xBF;0x1D4 不拼帧 ID、也不做输出异或,只对 b0 至 b6 求 CRC。两者共用同一个 MSB-first 多项式 0x85。

    0x1D4 的 b4 计数器为什么必须按 0x87 → 0xC7 → 0x07 → 0x47 循环?

    这是源文档记录的要求:计数器不按该顺序滚动时,逆变器会拒帧并给出状态「100 000」。文档把「计数器未按 10 毫秒循环」列为导致拒帧的可能原因之一。

    逆变器状态「100 000」和「000 000」分别是什么意思?

    按文档,状态「100 000」表示帧被拒绝,「000 000」表示帧被接受。文档还列出可能导致拒帧的原因,包括 0x1D4 的 CRC 错误、0x1D4 计数器未循环、0x11A 未发送或 mux 未循环,以及 0x11A 的 b1 不是 0x40。

    0x11A 有没有 CRC 字段?

    没有。文档明确说明 0x11A 不含 CRC,其 b7 是随 mux 选择器变化的启动 / 载荷数据,而非常规校验字节。

    这些结论能直接套到别的 Leaf 上吗?

    不能。来源说明写明 CRC 结论为上游声明、未在本归档独立核验,且精确年款、配置与固件 applicability 未确认。任何外推都需要以实车采集和独立复核为前提。

    延伸阅读

    参考资料

    • 项目 01 —— public-can-dbc-datasets/additional/kristianehr-leaf-ze1/docs/CRC_ALGORITHM_DEFINITIVE.md(本项目车型档案主来源,取用了 0x1DA / 0x1D4 / 0x11A 的 CRC 参数与帧结构)。
    • 项目 01 —— public-can-dbc-datasets/additional/kristianehr-leaf-ze1/docs/NISSAN_LEAF_1DA_CRC.md(取用了 0x1DA 的校验参数与 clock 定义)。
    • 项目 01 —— public-can-dbc-datasets/additional/kristianehr-leaf-ze1/SOURCE.md(取用了适用范围与「未独立核验」等边界说明)。

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

    更新记录

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

  • 桌面还是手机:CAN 数据记录工具的四个能力层级

    结论:桌面与手机的 CAN 数据记录工具并非同一品类,而是覆盖四个能力层级:CAN 物理 / 帧层、OBD 服务 / PID 层、厂商增强诊断层、维修决策层。桌面端多出 USB、串口与 Windows 平台上的 J2534 入口,手机端则受限于 BLE / Wi-Fi / 经典蓝牙,二者都不天然支持工程级总线分析。理解这条分层,就能解释为什么「支持 CAN」不等于「能诊断所有 ECU」,也能解释重卡诊断为何要单独看待。

    桌面与手机的入口差异

    公开资料显示,桌面诊断软件与手机应用在物理接口上并不对等。桌面端通常覆盖更完整的接口集合,手机端的连接方式则相对收敛:

    维度 桌面端(PC) 移动端(手机)
    操作系统 Windows 10 / 11、macOS 较新版本 iOS 与 Android
    接口形态 USB、串口、经典蓝牙、BLE、Wi-Fi BLE、Wi-Fi、MFi,Android 另有经典蓝牙
    专业总线入口 Windows 另支持 J2534 兼容设备 通常不提供
    典型场景 离线回放、报告与大屏分析 随车实时读数与一次诊断会话

    两个边界需要说清楚:其一,桌面端对 J2534 的支持通常限定在 Windows,不能外推到 macOS;其二,移动端一般不提供 USB 入口。因此「桌面能力更全」只在特定接口与平台组合下成立,跨平台购买时还需逐项核对授权是否分开。

    四个能力层级:帧、服务、增强、决策

    抛开平台,工具的能力可以按抽象层次排成四级:

    层级 数据表示 主要工作
    CAN 物理 / 帧层 总线、ID、时间戳、字节 采集、过滤、解码规则研究
    OBD 服务 / PID 层 服务号、PID、DTC、物理量 通用诊断与实时监测
    厂商增强诊断层 ECU、私有服务、车型包 多模块诊断、适配与保养
    维修决策层 故障解释、报告、配件 / 流程 判断下一步行动

    这个分层解释了为什么单靠通用 OBD2 适配器与故障码表,无法自然长成工程级 CAN 工具或维修厂诊断平台。原始 CAN 层先保留时间戳与原始帧,再用 DBC 或人工分析建立语义;OBD 服务层则围绕服务号与 PID 的请求和物理量换算。两者处于不同抽象层,不能把「支持 CAN」视为「已能诊断所有 ECU」。

    需要区分的是,原始帧类工具的定位是工程级分析与仿真,而不是给车主解释故障码;它们围绕时间戳、帧 ID、总线与载荷组织数据,用 DBC 把帧转成信号只是其中一步。选择时应先明确目标是「复盘一段总线」还是「读一次故障码」,两者对应的工具形态并不一样。

    原始 CAN 与诊断之外:数据可离线复盘

    桌面端的另一项结构差异是离线可复盘。公开资料中的开源 CAN 分析工具支持从多种日志格式(如 CSV、candump、Vector、PCAN)导入导出,围绕时间戳、帧 ID、总线、方向、长度与载荷组织帧,并借助 DBC 将帧 ID / 位段转成可解释信号。这类工具的定位是工程级总线分析与仿真,而不是给车主解释故障码。

    与之相对,一些桌面 OBD 工具的核心仍是「设备随附的诊断软件」定位:故障码、实时 PID、Mode 05 / 06 / 09、日志回放与 CSV。二者的差别在于:前者以原始帧为中心,后者以服务与物理量为中心。

    重卡与商用车是独立品类

    公开资料强调,重卡 / 商用车诊断的协议、故障语义与售后场景与轻型车不同,不应把轻型车排放诊断能力直接推到重卡。重卡类工具通常依赖专用蓝牙接口,面向 DPF 再生、降额等场景,并可能提供双向命令;另有相邻的维修资料类产品,提供故障码、接线图与维修资料,属于诊断之后的知识层,并不等同于直接采集车辆数据。

    对选型者而言,这意味着:如果目标车辆是商用车,通用 OBD App 的能力清单参考价值有限,需要单独核对协议与售后链路。从能力层级看,重卡工具的重心通常落在「厂商增强诊断层」与「维修决策层」,依赖专用接口而非通用适配器,其数据入口与售后链路都与轻型车不同。

    常见问题

    桌面端一定比手机端能力更强吗?

    不能一概而论。桌面端在 USB、串口与 Windows 的 J2534 入口上更完整,适合离线回放与大屏分析;但 J2534 通常限 Windows,且桌面与移动授权常需分别购买。要按具体接口与平台组合核对。

    「支持 CAN」就等于能诊断所有 ECU 吗?

    不等于。原始 CAN 层只保留时间戳与原始帧,需要 DBC 或人工分析才能建立语义;OBD 服务层则只覆盖标准服务与 PID。能否读到某个 ECU,取决于车型协议、总线拓扑与适配器能力。

    重卡诊断能用轻型车 OBD 工具替代吗?

    不建议。重卡的协议、故障语义与售后场景与轻型车不同,公开资料明确不应把轻型车排放诊断能力直接推到重卡,通常需要专用接口与面向 DPF、降额等场景的功能。

    桌面工具的离线回放有什么价值?

    它可以围绕时间戳、帧 ID、总线与载荷复盘一段采集,并用 DBC 把原始帧转成可解释信号,是对比多份日志、验证解码规则的重要手段,也是移动端一次会话不擅长的场景。

    延伸阅读

    参考资料

    • 项目 01 —— car-scanner-research/桌面与原始CAN.md(取用桌面与移动接口差异、四个能力层级、原始 CAN 分析定位与重卡品类边界;未引用任何逆向材料)。
    • 项目 01 —— car-scanner-research/逐产品拆解.md(取用移动端接口集合口径,用于对比桌面端)。

    说明:本文仅取用公开资料对桌面与移动诊断工具的能力分层与接口口径,未安装任何安装包、未连接总线、未进行通信抓包,也未核验各商品宣称的接口兼容与平台支持。文中所有层级、接口与边界均出自源文档,标注为未验证的结论保留其原有边界。

    更新记录

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

  • Honda 平台表:38 个条目里的 DBC、flags 与线束提示

    结论:Honda 的平台表把三类东西放在不同层:软件平台定义(固定快照里 38 个 Honda/Acura 条目)、DBC 与 flags、以及 HondaCarDocs 的线束提示。三者不能互相替代——同 DBC 不等于同线束,CAN FD DBC 不等于 CAN FD 平台,文档线束提示也不等于接线验证。任何车型插件都必须冻结精确平台 ID、DBC 哈希、静态与动态 flags、物理总线图与线束版本,不能只凭「Bosch/Nidec」或 DBC 文件名授予控制权。

    38 个平台条目:计数的是代码平台

    在固定快照 c8fb906 的 CAR 枚举里,Honda/Acura 有 38 个平台条目:26 个 Bosch 配置,其中 7 个为 HondaBoschCANFDPlatformConfig,另有 12 个 Nidec 配置。源文档强调,这里计数的是代码平台,不是市场车型、年款或可装车数量。

    HondaBoschCANFDPlatformConfig 继承 Bosch,构造时加 BOSCH_CANFD,并默认 PT DBC 为 honda_common_canfd_generated;HondaNidecPlatformConfig 加 NIDEC,各平台通过 radar_dbc_dict() 同时声明 PT DBC 与 acura_ilx_2016_nidec 雷达 DBC。

    软件类别 代表平台 DBC / flags 含义
    Bosch 有雷达 HONDA_ACCORD、HONDA_CRV_5G PT DBC 依车型而异;BOSCH_ALT_BRAKE 可为静态标志,也可由指纹条件补上。
    Bosch 无雷达 HONDA_CIVIC_2022、HONDA_HRV_3G、ACURA_ADX BOSCH_RADARLESS 使车端总线、按钮目标和纵向权限走不同分支;不能只按 DBC 名判断。
    Bosch CAN FD HONDA_ACCORD_11G、HONDA_CRV_6G、ACURA_MDX_4G_MMR BOSCH_CANFD 标志和默认 PT DBC 一起定义平台;本快照参数层不开放 CAN FD 实验纵向。
    Bosch 非 CAN FD 但复用 CAN FD DBC ACURA_MDX_4G PT DBC 仍是 honda_common_canfd_generated,源码注释明确「not CANFD car but shares same dbc」;安全模式和总线拓扑不能由 DBC 文件名反推。
    Nidec HONDA_CIVIC、HONDA_CRV、HONDA_ODYSSEY PT/雷达双 DBC;NIDEC_ALT_SCM_MESSAGES、NIDEC_ALT_PCM_ACCEL 和全车门字段标志决定输入/输出分支。

    CarSpecs 与参数复用不等于实车测定

    CarSpecs 给质量、轴距、转向比、质心前轴比、最低转向/使能速度和轮胎刚度因子;通用 get_params() 将其写入 CarParams,并加默认载荷后计算惯量/轮胎刚度。平台间存在显式参数复用:旧 HONDA_HRV 复用 HONDA_HRV_3G.specs,旧 HONDA_PILOT 复用四代 Pilot 的 specs。源文档提醒,这是代码共享,不是目标车辆物理参数已经测定的证据。

    CarInterface._get_params() 把静态平台资料与指纹、固件、用户选择合成为实际 CarParams 和 safetyParam;CarState.get_can_parsers() 按 PT/相机/车身路由建立解析器,RadarInterface 在 Nidec 平台另用 Bus.radar DBC 建立雷达解析器,CanBus/CarControllerParams 再把车型能力映射为物理总线与转向扭矩上限。源文档据此把「平台表」定位为软件声明,而不是可直接施工的线束图。

    静态 flags、指纹动态标志与总线映射

    平台表中的 BOSCH、NIDEC、BOSCH_RADARLESS、BOSCH_CANFD、BOSCH_ALT_RADAR 是构造时的静态能力。CarInterface._get_params() 还从指纹动态设置 BOSCH_EXT_HUD、HYBRID、条件性的 BOSCH_ALT_BRAKE 以及特定五代 CR-V 的 HAS_BSM;固件 EPS 版本含逗号则置 dashcamOnly。BOSCH_TJA_CONTROL 在控制器有分支,但本快照平台定义中未见设置,不能把 dormant 代码当作已开通能力。

    CanBus 把 Bosch 有雷达平台的 PT 映射到 offset+1、radar 到 offset,纵向模式影响 LKAS 发送总线;radarless/CAN FD/Nidec 使用另一组映射。CarState 的相机解析器使用同一 PT DBC,却绑定 CanBus.camera 物理输入;BSM parser 使用 Bus.body DBC 但读取 CanBus.radar,需要 panda 转发 B-CAN。源文档据此总结:DBC 语法共用、逻辑 Bus 名称和真实总线接线是三个不同层次。DBC 语法共用不代表物理总线相同。

    这些 flags 的取值分支会一路传到构帧与限幅:例如 BOSCH_RADARLESS 影响车端总线与按钮目标,纵向模式影响 LKAS 发送总线。因此只按 DBC 名或品牌判断输入/输出分支,会同时误判总线映射与限幅参数。

    线束提示只是文档族

    HondaCarDocs.init_make() 按 flags 选择文档线束族:Bosch CAN FD 为 bosch_c,radarless 为 bosch_b,其他 Bosch 为 bosch_a,Nidec 为 nidec。CarDocs 的年款、最低转向速度、套件和 AEB/FCW 脚注用于支持表呈现,不构成引脚、供电、继电器或 EMC 的工程验收。部分平台 car_docs=[] 只是不在支持表展示,不代表平台代码不存在。

    把这些层叠起来看:平台表决定「软件认为这是什么车」,flags 决定「走哪条分支」,DBC 决定「怎么解析字段」,线束文档决定「支持表怎么展示」,而物理接线与 ECU 固件证据是独立的一层。四者只有在插件描述符里逐项冻结,才谈得上可复现。

    插件描述符必须冻结什么

    必须冻结的字段 为什么不能省
    精确平台 ID、DBC 哈希 同 DBC 不等于同线束;ACURA_MDX_4G 复用 CAN FD DBC 却是非 CAN FD 平台。
    静态 flags(BOSCH / NIDEC / BOSCH_RADARLESS / BOSCH_CANFD) BOSCH_RADARLESS 会使总线、按钮目标和纵向权限走不同分支。
    动态 flags(EXT_HUD / HYBRID / ALT_BRAKE / HAS_BSM / dashcamOnly) 由指纹与固件条件设置,不能只按 DBC 名或品牌判断。
    物理总线图、线束版本 逻辑 Bus 名称与真实接线是不同层次,DBC 名不能反推拓扑。
    ECU 固件证据、panda safety 模式 决定控制权授予与失联回退,不能只靠「Bosch/Nidec」授予控制权。

    源文档给出的顺序是:先建立目标车型的只读 CAN/电源/接线记录,再验证 PT、camera、radar、body 路由、原车 ADAS 保留和失联回退;没有原厂资料和台架证据,不把文档线束类型当作可照抄的接线表。此处仅完成静态结构分析,未验证 38 个平台的实际车辆参数或装配兼容性。

    常见问题

    38 个 Honda 平台条目等于 38 款可装车型吗?

    不等于。源文档明确,这 38 个是代码里的平台条目(26 个 Bosch 配置含 7 个 CAN FD 配置,加 12 个 Nidec 配置),计数的是代码平台,不是市场车型、年款或可装车数量。

    用了同一个 CAN FD DBC,是否说明这平台就是 CAN FD 车?

    不是。ACURA_MDX_4G 的 PT DBC 仍是 honda_common_canfd_generated,但源码注释明确它「not CANFD car but shares same dbc」,说明安全模式和总线拓扑不能由 DBC 文件名反推。

    文档线束提示(bosch_a/b/c、nidec)可以直接照抄接线吗?

    不可以。这些是 HondaCarDocs.init_make() 按 flags 选择的文档线束族,用于支持表呈现,源文档明确它们不构成引脚、供电、继电器或 EMC 的工程验收。接线仍需原厂资料与台架证据。

    BOSCH_TJA_CONTROL 出现分支,是否代表该能力已开通?

    不代表。源文档指出它在控制器里有分支,但本快照的平台定义中未见设置,属于 dormant 代码,不能当作已开通能力。

    延伸阅读

    参考资料

    • 项目 02 —— openpilot-research/HONDA_PLATFORM_DBC_HARNESS_MATRIX_DEEP_DIVE.md(取用了平台类别计数、静态与动态 flags 分层、总线映射与线束文档族选择逻辑)。

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

    更新记录

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