结论：RiceTimer 是一台把 GNSS、IMU 与 CAN 三路原始数据同步写进 MicroSD 的记录器，但它今天并不解析信号——data/dbc/ 目录下目前只有一份版权声明，说明数据部分派生自 MIT 授权的 OpenDBC；真正的 DBC-based CAN bus parsing 明确写在 Planned Future Work 里，并且作者特别注明它不会影响日志输出，日志永远是原始 CAN 报文。想拿发动机转速和挡位，得自己离线过一遍 DBC。
它记录什么：三路数据共用一个 GNSS 时钟
这个项目最扎实的设计决定是把时间基准统一了：所有消息都按 GNSS 的 UTC 时钟打时间戳，而不是按各自 MCU 的上电时间。这决定了后面能不能把 IMU 的姿态和 CAN 的轮速对齐到同一条时间轴上。
| 数据源 | 器件 | 时间戳方式 | 注意点 |
|---|---|---|---|
| GNSS | uBlox NEO 系列模块 + 外接有源天线 | NMEA 语句本身带 UTC | 必须接 SMA 天线，板上没有内置 GNSS 天线 |
| IMU | ST LSM6 系列（LGA14）六轴加速度 + 陀螺 | 硬件在 data available 时刻打时间戳 | SPI 总线占用 IOMux 快速引脚，不可随意改引脚 |
| CAN | 一路 3.3 V 非隔离收发器 | 固件在报文交付时刻打时间戳 | 兼容 5 V 网络；支持 11/29 位帧，不支持 FD |
三者的时间戳来源不同——IMU 是硬件级的、CAN 是固件级的——这意味着它们相对于 GNSS 时钟都存在各自的偏移。做融合之前，这个偏移必须测出来并补偿，否则 IMU 与 CAN 的数据在时间上会有系统性的错位。
日志格式也刻意朴素：每行一个数据点，且每一条有效 NMEA 语句都被逐字写入。这样做的代价是文件体积偏大，收益是后期可以用任何外部工具重放，不必依赖设备自身的解析器。示例日志 sample-log.txt 里 GPS 坐标做了部分脱敏处理，因此那份文件的 NMEA 校验和是对不上的——这不是日志坏了。
硬件接口契约
接车之前值得把引脚定义核对一遍，因为它是裸板电源与总线共口的设计，接错就是烧片子。
| 接口 | 引脚 | 电气取值 | 注意点 |
|---|---|---|---|
| USB Micro-B | 供电 + 串口调试烧录 | CP210x 桥接 | 同时也是 ESP32 的编程控制台 |
| JST SH 5 针（短边） | 1 GND、2 VIN、3 Reserved、4 CAN L、5 CAN H | VIN 标称 5 至 14 V | CAN 与电源共用同一个座，引脚 3 保留未接 |
| SMA（短边） | 外接有源天线 | 必需 | 无内置天线，不接则 GNSS 不工作 |
| JST SH 4 针（长边） | 1 GND、2 VCC、3 SDA、4 SCL | VCC 标称 3.3 V | 兼容 QWIIC 与 Stemma QT，现用于 SH1107 的 128×64 OLED |
| Micro SD | 4 位 SD 总线 | Micro-SDHC | 占用 IOMux 快速引脚；重流量下建议低延迟卡 |
SD 卡这条容易被忽略。CAN 数据不多时任何 Micro-SDHC 都能用，但报文流量较大时建议换低延迟卡，以避免潜在丢数。市面上通常标注为 Industrial、Endurance 或「行车记录仪专用」的就是这一类。换句话说，丢帧的根因未必在 CAN 侧，可能在文件系统的写入延迟上——而这个问题在 CAN 侧是查不出异常的。
DBC 目录现在的实际内容
往下钻一层看 data/dbc/，会发现这个目录目前只有一份 README，全文只有一个信息：这里的数据部分派生自 OpenDBC（MIT 授权），详见 LICENSE。目录里没有可加载的 .dbc 文件。
这与 README 里的计划清单完全对应——DBC-based CAN bus parsing 被列在 Planned Future Work，描述是「把 DBC 加载到设备上，从而提取并利用实时信号，例如发动机转速、油液温度、车辆自身的 IMU、轮速等」。而紧接着那句话才是关键：这不会影响日志输出，日志始终包含原始 CAN 报文。
这条约束很值得照抄。它把设备切成两条正交的路径：实时显示在未来可以走 DBC 解析，落盘数据则永远保持原始。收益是后处理链路不会因为解析定义的改动而失效——原始帧始终可以重新解码；代价是每次会话都会多写一份原始报文，占用存储。对一个以复盘为目标的项目来说，这是一笔划算的买卖。
计划清单里剩下的四件事
README 明确列出了待办，读它能判断这台设备的成熟度：一是稳定日志格式与后处理流程（当前日志格式尚未正式规定，这对依赖它做自动分析的人是硬约束）；二是传感器融合与标定，需要对 IMU、车辆、GNSS 天线之间的刚性变换做标定；三是预测圈速，当前 OLED 只显示少量实时诊断信息；四是启用 Wi-Fi 与 BLE——选 ESP32 就是为了留这一步。
还有一条对项目形态影响很大：README 明确写「本项目目前不接受贡献」。这解释了为什么它是一个清晰的单人项目而不是一个社区协议库——想要更多的信号定义，只能等作者更新或自己在离线侧补全。
作为参照，作者已经用早期原型硬件在 Thunderhill East 赛道的实数据跑通过后处理，转换成空格分隔表并交给 CircuitTools 分析。也就是说「赛道实车采集的数据转成空格分隔表，再交给 CircuitTools 分析」这条主链路是通的，缺的只是设备端的 DBC 解析那一环。
常见问题
RiceTimer 现在能直接在设备上解出发动机转速吗？
不能。DBC-based CAN bus parsing 仍列在 Planned Future Work 中，data/dbc/ 目录目前只有一份说明版权与 OpenDBC 派生关系的 README，没有可加载的 dbc 文件。要得到转速、水温、轮速等信号，需要在拿到原始日志后自行用外部工具按 DBC 解码。
这台设备支持 CAN FD 吗？
不支持。它只有一路 3.3 V 非隔离 CAN 收发器通道，兼容 5 V 网络，支持 11 位与 29 位帧，文档明确指出 FD 不支持。接 FD 总线不会得到正确报文。
为什么建议换低延迟的 SD 卡？
因为写入延迟会在 CAN 流量大时造成丢数。作者说明 CAN 数据不多时任何 Micro-SDHC 都能用，但报文流量较大时应换低延迟卡，通常是标注 Industrial、Endurance 或行车记录仪专用的型号。这类丢帧在 CAN 侧查不到异常。
示例日志里的 NMEA 校验和为什么对不上？
因为示例日志的 GPS 坐标做了部分脱敏处理。README 明确说明这一操作会导致校验和不匹配，这是隐私保护的结果，不代表日志损坏或记录链路有问题。
延伸阅读
- 车电接入：为什么 ESP32 的 TWAI 不等于 OBD 接口 —— ESP32 方案接车前的硬件前提
- 2022 GR86 / BRZ 的 CAN 数据地图：ASC 与 DCM 口 —— 可与该赛道场景配合使用的公开信号地图
- 公共 CAN/DBC 数据集怎么选：四类来源与三道筛查 —— 离线补一层 DBC 时怎么挑
- 车载信号为什么会说谎：TTL、源时间与 500 ms 新鲜度阈值 —— 为什么 GNSS UTC 统一时钟还不能解决所有对齐问题
参考资料
- 项目 01 ——
public-can-dbc-datasets/additional/hpde-rice-timer/README.md（定位与原名 ShiftWatch、三种数据源与器件型号、GNSS UTC 统一时间戳、CAN 收发器电气与 FD 不支持、两个 JST SH 接口的引脚定义、SD 卡低延迟建议、示例日志脱敏说明、Planned Future Work 六项、暂不接受贡献） - 项目 01 ——
public-can-dbc-datasets/additional/hpde-rice-timer/data/dbc/README.md（该目录数据部分派生自 MIT 授权的 OpenDBC，详见 LICENSE）
免责声明
本文所述硬件规格、引脚定义与项目状态均来自公开开源仓库的说明文件，属社区项目产物，未经实车独立验证，也不代表任何制造商的官方数据。日志格式尚未正式规格化，接口定义可能随硬件版本变化。涉及车载供电与总线接入的操作请以实际测量与官方资料为准。
更新记录
- 2026-10-14 初稿
发表回复