标签: 车型档案

  • 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

  • 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