结论：神行者 2（Freelander 2）的这套中速 CAN 材料不是一个已完成的解码成果，而是一个进行中的信息娱乐替代工程副产品。它的核心是两份同名不同版本的 DBC：FL2_13MY_MSCAN r01.dbc 有 35 条报文 12 条信号，r03.dbc 有 39 条报文 39 条信号——两者 ID 相互重叠，是迭代关系而非总线分区互补。信号数从 12 跳到 39 而报文只多 4 条，说明大量条目仍停留在报文清单或初步解释层面。硬件侧倒是清晰：两路 MCP2515 分别跑 125 kbit/s 与 500 kbit/s，对应中速与高速两条总线。
两个版本是迭代关系，不是互补分区
最容易犯的错是把 r01 与 r03 当成两条不同总线的定义拼在一起用。归档记录明确写着：这是两个版本、ID 重叠，不是互补的总线分区。正确做法是只取较新的一份作为当前基线，把旧版留作来源快照。
| 文件 | 报文数 | 信号数 | 与另一版的关系 | 使用建议 |
|---|---|---|---|---|
FL2_13MY_MSCAN r01.dbc |
35 | 12 | 较早版本，ID 与 r03 重叠 | 留作来源快照，不参与合并 |
FL2_13MY_MSCAN r03.dbc |
39 | 39 | 较新版本，比 r01 多 4 条报文、多 27 条信号 | 作为当前基线，逐条核对 |
多出来的 27 条信号分布在 39 条报文里，平均下来每条仍不足 1 条。这个比例本身就是一条判据：文件里相当一部分条目只是被登记了报文 ID，尚未解出对应的物理信号。较新版本还包含 4 条扩展 ID 条目，发送方被标注为项目自定义来源（原文记作 JPL-Added），分别对应转向灯、背光、驻车雷达与钥匙电池状态。
三条总线的分工：中速、高速与娱乐总线
这个工程同时面对三条总线。中速 CAN 是主攻方向，高速 CAN 目前主要用于生成 CanDump 供调试；娱乐总线则是音频主机与显示屏之间的专用链路，独立于 MS/HS 之外，解码进度反而更具体。
| 总线 | 速率 | 接口 | 承载内容 | 解码状态 |
|---|---|---|---|---|
| 中速 CAN（MS-CAN） | 125 kbit/s | can0 | 车身与信息类 ID，含 VIN | 进行中，README 标注 work in progress |
| 高速 CAN（HS-CAN） | 500 kbit/s | can1 | 车辆高速总线 | 可生成 CanDump 用于调试开发 |
| 娱乐总线（Entertainment Bus） | 未在 README 中标注 | 音频主机与主机显示屏之间 | 音源（FM/DAB/AM/Aux/蓝牙，CD 待定）、电台名与 RDS 附加数据、音量、蓝牙媒体的曲名与艺术家 | 部分解码，条目比 MS-CAN 更具体 |
娱乐总线的音量项有个细节：它只在操作原车硬件旋钮开关时弹出。这类「事件触发而非周期广播」的行为，是被动监听时最容易漏掉的报文类型，也说明了为什么单纯抓一段 CanDump 不足以还原总线行为。
硬件与接口配置：两路 MCP2515 与两个波特率
工程跑在树莓派上，通过 SPI 挂两路 MCP2515 控制器。/boot/config.txt 里先开 SPI，再声明两个 overlay，晶振均为 16000000，中断脚分别是 25 与 23；/etc/rc.local 里在 exit 0 之前拉起两个接口，速率一高一低。
| 配置项 | 取值 | 说明 |
|---|---|---|
| SPI | dtparam=spi=on |
MCP2515 经 SPI 挂载的前提 |
| can0 | 晶振 16000000，中断 23，bitrate 125000 | 对应中速 CAN |
| can1 | 晶振 16000000，中断 25，bitrate 500000 | 对应高速 CAN |
| 系统依赖 | can-utils、libsocketcan2、libsocketcan-dev | 通过 apt 安装 |
| 运行时 | Node.js 20.10.0（仅在此版本测试过） | 随后执行 npm i |
| 构建目标 | pi64-build（RPi 4 且 4GB 以上）、pi32-build（RPi 3 或 4GB 以下的 RPi 4）、electron-build（Ubuntu，仅供测试） | 产物在 /dist 下，运行 AppImage |
| 免硬件调试 | vcan 加 can-gw 双向转发 | 先 down 掉 can1 再以 125000 拉起，或建两条 vcan 互转 |
证据边界：哪些是已解码，哪些只是假设
这份材料的价值在于把「已实现」「进行中」「假设」分得很清楚。直接照抄 DBC 里的信号名会带来两类风险：把未验证的假设当结论，以及把项目自定义的编码当原车报文。
| 条目 | 状态 | 边界说明 |
|---|---|---|
| VIN 解析 | 已实现 | 解析 VIN 得出车龄、品牌与型号；首次启动需要一点时间完成配置 |
| 娱乐总线解码 | 部分实现 | 音源、电台名与 RDS、音量、蓝牙曲目均已覆盖 |
| CD 音源 | 待定 | 原文标注为 Pending |
| MS-CAN ID 解码 | 进行中 | README 明确标注 work in progress |
| 4 条扩展 ID（转向灯、背光、驻车雷达、钥匙电池） | 未确立 | 发送方被标注为项目自定义来源，尚未确认是原车观测帧还是项目自有编码 |
| 带问号的注释（如胎压归属） | 假设 | 仍是推测，未验证 |
| 车辆配置文件解析 | TBC | 是否需要尚未确定 |
| 逐信号验证与配置/固件适配 | 缺失 | README 只给出工程与大致车型范围 |
| 许可证 | 无 | 检查的快照中没有许可证文件 |
被动监听时要特别留意的两类帧
第一类是非周期帧：娱乐总线的音量只在操作原车旋钮时弹出，短时抓包很可能整段缺失。第二类是来源存疑的帧：那四条扩展 ID 与带问号的注释都属于此类。合理的抓取策略是先长录一段覆盖静置、上电、操作旋钮与行驶四个阶段，再按 ID 出现次数做筛选，而不是只看某一段 CanDump 里出现了什么。
常见问题
r01 与 r03 该用哪个？
用 r03 作基线，r01 只作来源快照。归档记录明确说明两个版本 ID 相互重叠、是迭代关系而非互补的总线分区，把它们合并会引入重复 ID 与冲突定义。r03 有 39 条报文 39 条信号，比 r01 多 4 条报文、27 条信号。
125 kbit/s 与 500 kbit/s 分别对应哪条总线？
125 kbit/s 是中速 CAN，绑定在 can0；500 kbit/s 是高速 CAN，绑定在 can1。两者都由 MCP2515 经 SPI 提供，晶振 16000000，中断脚分别为 23 与 25，配置写在 /boot/config.txt 与 /etc/rc.local 里。
那四条扩展 ID 是原车报文吗？
尚未确立。它们出现在较新版本里，对应转向灯、背光、驻车雷达与钥匙电池状态，发送方被标注为项目自定义来源。归档记录明确写到，尚未独立确认这些条目是观测到的原车帧还是项目自有编码，因此不能当作原厂信号使用。
娱乐总线和中速 CAN 是同一条总线吗？
不是。README 把娱乐总线描述为音频主机与主机显示屏之间的专用总线，独立于 MS/HS 之外，并单独列出了音源、电台名与 RDS、音量、蓝牙曲目等解码项。它的速率未在 README 中标注。
这套配置能直接搬到别的车型上吗？
硬件部分可以复用，报文部分不能。两路 MCP2515 加 can-utils 的接法与车型无关；但 DBC 里的 ID 与信号是针对 2012 年款之后的 Freelander 2 整理的，且 README 未提供逐信号验证与具体配置、固件适配的证据，换车型必须重新取证。
延伸阅读
- Opel Astra H 的 LS-CAN 与 MS-CAN 解码档案 —— 同为低速/中速双总线的解码口径
- Ram ProMaster 2022：三总线与 19 个 UDS 模块 —— 多总线车型的总线切分方法
- 车电接入：为什么 ESP32 的 TWAI 不等于 OBD 接口 —— 单板接入 CAN 的常见误区
- 车型协议接入实践：从指纹识别到安全固件的最低契约 —— 新车型取证的最低要求
参考资料
- 项目 01 ——
public-can-dbc-datasets/additional/n95jpl-freelander2-mscan/SOURCE.md（两个 DBC 版本的报文数与信号数、重叠关系、扩展 ID 与许可证状态） - 项目 01 ——
public-can-dbc-datasets/additional/n95jpl-freelander2-mscan/README.md（功能清单、娱乐总线解码项、树莓派双 CAN 接口配置与 vCAN 调试步骤）
免责声明
本文所述内容均为社区逆向与开发中的工程产物，不代表车辆制造商的官方数据。文中数字均来自上述公开仓库的说明文件，未经独立实车验证；不同车型年款、配置与固件版本可能存在差异，部分条目在原始材料中即标注为假设或未确立。涉及安全相关用途时请仅作参考，并以实际测量与官方资料为准。
更新记录
- 2026-10-14 初稿
发表回复