便携式串口与 CAN 分析记录套件

状态：idea
提出人：待确认
参与人：王小杰、刘力夫
创建日期：2026-08-14
最近更新：2026-08-14

一句话说明

开发一款支持串口与 CAN 的便携式诊断工具，可脱机可靠记录现场数据，并通过手机或桌面端实时分析和回放。

背景与问题

设备调试、故障复现和无人值守监测都需要在不持续连接电脑的情况下保留通信数据。串口记录仪与 CAN 分析套件虽然物理接口和协议不同，但共享时间戳、缓存、存储、文件轮转、故障标记、实时传输和历史回放等核心能力，分别开发会造成硬件与软件重复。

串口方向已有三款低价脱机记录模块作为市场参考；CAN 方向已有 projects/can-tools 的 ESP32-C3 采集硬件实验，以及 projects/canscope 的 Android 与桌面波形显示原型。合并后的关键假设是：同一批现场调试人员确实需要串口和 CAN 两类接口，并愿意为统一工作流承担额外体积与成本。该假设尚未验证。

目标用户与使用场景

嵌入式与硬件工程师：记录设备启动日志、串口调试信息和 CAN 报文，定位偶发问题。
售后与现场运维人员：把设备留在客户现场，事后取回故障前后的通信证据。
汽车电子与工业设备工程师：在车辆、台架或设备现场快速判断总线状态并回放分析。
实验室与小批量产测人员：统一保存启动过程、通信结果和失败样本。

最有机会形成差异化的首要场景是“无人值守、长时间、不能丢失故障前后数据”的现场诊断。普通桌面串口调试或仅需单次 CAN 监听的用户，可能使用低价单功能工具就已足够。

核心设想

使用可替换或分版本配置的输入接口，候选范围包括 UART/TTL、RS232、RS485 和经典 CAN。
采集核心统一负责高精度时间戳、缓存、MicroSD 写入、文件轮转、事件标记和丢失统计。
没有电脑时独立记录；连接手机或电脑后，可配置、查看实时数据、打标、导出和回放。
串口数据与 CAN 帧使用同一事件时间轴和容器格式，同时保留各自的协议字段。
CAN 首版默认被动监听；任何主动发送、回放上总线或终端电阻切换都需要显式模式与状态提示。
产品形态可能是单机多接口成品，也可能是共享主机加接口适配模块，需通过体积、成本和隔离需求验证。

端到端架构

UART / RS232 / RS485 ─┐
                      ├→ 接口适配与保护 → 采集/时间戳/缓存 → MicroSD 原始日志
CAN ──────────────────┘                              ↓ Wi-Fi / USB
                                                手机或桌面分析端

采集端是诊断证据的主来源：上位机断开时仍应继续记录并标注异常。
接口层负责电平转换、隔离、终端和接线保护，不把不同总线的电气差异泄漏到统一记录核心。
实时链路优先传输原始事件、统计和设备状态，协议解码、波形和信号分析优先放在上位机。
记录文件必须携带格式版本、设备时间、单调时钟、接口类型、配置快照和丢失计数。

统一记录模型

每条记录至少包含以下公共字段：

单调时间戳、RTC 时间、接口编号、接口类型、方向和数据长度。
原始数据、设备配置版本、文件序号和会话 ID。
数据丢失、缓存溢出、存储异常、重连和用户打标等事件。

串口记录附加波特率、数据位、停止位、校验方式和原始字节；CAN 记录附加 ID、标准/扩展帧、DLC、标志位和控制器错误状态。文本、CSV 等易读格式作为导出结果，不作为唯一事实来源。

典型使用流程

用户选择接口并完成接线，设置串口参数或 CAN 速率、监听模式和终端状态。
设备上电后自动建档，通过明确状态显示正在记录、存储异常、缓存溢出和总线故障。
用户可脱机留置设备，也可连接手机或电脑实时过滤、查看、打标和测量。
发生故障后导出对应时间窗口，并保留原始记录用于复盘。
意外断电或客户端掉线后，设备能说明上一文件是否完整并继续记录，不覆盖旧证据。

首版范围

必须验证

以 UART/TTL 和单通道经典 CAN 作为首批接口，验证二者能复用同一记录核心；RS232、RS485 是否同版加入待确认。
MicroSD 原始记录、RTC 与单调时间戳、缓存、文件轮转、配置持久化和异常恢复。
串口原始字节记录，以及 CAN 被动监听、过滤、统计和 BUS-OFF 状态记录。
Wi-Fi 或 USB 中的一种实时链路，先支持一个优先客户端。
卡缺失、卡满、写失败、缓存溢出、断电、总线断开和上位机掉线的诊断闭环。

暂不纳入首版

CAN FD、多 CAN 通道同步、LIN、车载诊断全协议栈和云端设备管理。
同时集齐 UART/TTL、RS232、RS485、USB Host 与所有连接器组合。
默认允许向现场串口或 CAN 主动注入、自动回放数据。
在没有用户证据前同时维护 Android、Windows、macOS 和 Linux 完整客户端。

首轮验证指标

以下门槛用于决定统一平台是否值得继续投入，不是最终产品规格：

维度	首轮门槛	验证方法
串口完整性	连续 8 小时压力记录无可检测丢字节	发送带序号与校验值的数据并离线比对
CAN 完整性	目标总线负载下连续 2 小时无不可解释丢帧	与参考 CAN 接口或序号报文对比
时间一致性	接口切换、客户端重连和文件轮转后时间轴连续	注入周期事件并核对时间差
掉电恢复	旧文件可读取，尾部数据损失处于可量化范围	在不同写入时刻重复断电
离线能力	上位机断开期间持续记录，重连后能定位断线窗口	主动断开实时链路并检查日志
可诊断性	存储、缓存、串口配置和 CAN 控制器异常均有明确记录	故障注入并复盘原始日志
上手效率	目标用户 10 分钟内完成接线、记录、打标和导出	观察至少 3 名用户首次操作

差异化与商业假设

低价串口记录模块和 USB-CAN 已覆盖单一功能，统一套件的价值必须来自数据可信、跨接口统一时间轴、脱机记录和现场工作流。
串口与 CAN 合一可减少携带设备和学习成本，但也会增加接口保护、隔离、外壳和认证成本。
可测试的产品形态包括多接口一体机、主机加适配模块，以及基础硬件加专业解码/报告功能。
如果目标用户通常只使用一种接口，应拆成共享软件与记录核心、不同硬件型号，而不是强制做成一台全接口设备。

讨论记录

2026-08-14

参与人：待确认
结论：最初将 can-tools 的采集记录能力与 CANScope 的上位机能力收敛为便携式 CAN 产品创意；两端已有独立原型，真实 CAN 端到端链路仍需验证。
补充：明确采集端作为证据主来源、默认被动监听、首版功能边界和性能验证口径；真实总线指标尚未实测。
合并结论：用户确认将“串口记录仪”与“便携式 CAN 分析与记录套件”合并，由本目录作为唯一主位置；串口竞品、掉电保护和长时间记录要求并入统一方案，状态保持 idea。

验证方式

购买至少两款不同价位的串口记录模块，实测持续记录、时间戳、掉电恢复和数据导出体验。
用真实 CAN 设备完成“总线采集 → 写卡 → 实时显示 → 本地录制 → 回放”的端到端测试。
使用同一采集核心分别进行串口 8 小时与 CAN 高负载压力测试，比较缓冲、写卡和实时传输边界。
构造拔卡、卡满、断电、缓存溢出、串口参数错误、BUS-OFF 和客户端掉线，确认仍能保留诊断证据。
访谈至少 3 名同时接触串口和 CAN 的现场工程师，确认统一设备是否比两个单功能工具更有价值。

风险与待确认问题

首要行业、主要接口组合、最高数据率、CAN 负载率和通道数：待确认。
UART 只监听、全双工双向监听或串接转发的首版模式：待确认。
RS232/RS485/CAN 的隔离、浪涌/ESD、终端和目标连接器规格：待确认。
ESP32-C3 同时采集、写卡和实时传输时的吞吐与缓存上限需要实测。
多接口一体化可能抬高成本，却无法替代专业单功能设备，需要先验证共同购买者。
手机与桌面双端并行维护可能分散资源，应先决定首发客户端。
主动发送能力存在误操作风险，需要物理或软件护栏。

阶段里程碑

统一基线：冻结公共记录模型，并分别跑通 UART/TTL 与经典 CAN 写卡。
性能边界：量化串口数据率、CAN 总线负载、掉电损失、延迟、功耗和温升。
端到端样机：完成实时显示、打标、导出与历史回放，验证接口切换体验。
工程样机：加入目标场景所需的隔离、供电、连接器、外壳和状态设计。
用户试用：由目标用户完成真实故障记录，决定一体机或分型号方案。

下一步

冻结首轮 UART/TTL 与经典 CAN 的接口、电气和数据率边界。
定义统一原始日志 schema、接口扩展字段、版本兼容和丢失统计口径。
从串口竞品中选择至少两款下单，并建立带序号和校验值的压力数据源。
接入真实 CAN 信号，跑通采集、写卡、实时显示和回放闭环。
编写拔卡、断电、缓存溢出、参数错误、BUS-OFF 和客户端掉线测试清单。
访谈同时使用串口与 CAN 的现场工程师，确认统一硬件是否成立。