星核火花赛车科技

进入商城

标签： GEO生产线

  • 电子纸路书：3.97 寸离线路书为什么用黑白

    结论：3.97 寸电子纸路书的定位是离线静态阅读，而不是实时仪表，所以它采用白底黑字、单色大 tulip 图与简短中文路书，并且不套用彩屏的五套主题。它的刷新方式、局刷能力与残影表现目前仍是待实测项——微雪概览页未列出屏控 IC、色阶与刷新方式。

    电子纸路书为什么用黑白，而不是彩屏

    因为角色不同：彩屏承担实时仪表与告警，电子纸只承担离线阅读路书，所以它不参与彩屏主题体系。在 kno 赛道 HMI 原型里，3.97 寸是唯一一块白底黑字、大 tulip 路线图、简短中文路书的画布，并明确不套用彩屏主题、不受主题切换影响。它的色彩令牌也只有两个值：#F1F1EA 与 #202A2A，用途写的是「单色静态路书」。

    这个取舍是有道理的。路书是上车前要记住、上车后偶尔翻一眼的东西，不是需要每秒刷新的数据。把它放在电子纸上，好处是静态内容在强光下可读、断电也不丢画面；代价则是放弃实时性——电子纸不承担圈速、转速、告警这类必须实时的信息。彩屏侧的信息架构与告警设计另见 赛道仪表的信息架构：从圈速到告警的设计顺序。

    3.97 板上的硬件事实有哪些？

    这块板的官方概览页确认了主控、存储、屏幕分辨率与板载外设，但没有列出屏控 IC、色阶与刷新方式。下表逐项列出，方便核对。

    项目 官方概览页事实 备注
    采购型号 ESP32-S3-ePaper-3.97-EN -EN 为采购记录中的语言 / 销售后缀；实际 PCB 修订版需核对丝印
    主控与存储 ESP32-S3-WROOM-1-N16R8；8MB PSRAM，16MB Flash —
    屏幕 800×480 电子纸，横屏路书 概览页未列屏控 IC、色阶与刷新方式
    触摸 概览页未列触摸 不作为交互假设
    板载外设 Micro SD、PCF85063 RTC、QMI8658 IMU、SHTC3、ES8311、TG28 RTC 与 IMU 是板上实际存在的外设
    供电与接口 3.7V 电池接口 / 充电、USB-C —

    需要强调的是表格的空白项也是一种事实。「概览页未列屏控 IC、色阶或刷新方式」意味着这些参数不能凭经验填值——同厂的彩屏板型号各不相同，把彩屏驱动方案套到电子纸上没有依据。按项目现有的核对流程，这类缺失项要回到该型号的官方资料继续查，而不是估算。

    离线路书在原型里怎么组织？

    原型用「18 页示意路书 + 3 张示意 tulip 图循环」来组织，并用上一页 / 下一页切换；刷新能力与残影没有在浏览器中模拟。

    这里有两层信息要分开看。第一层是内容结构：18 页路书、3 张示意 tulip 图循环复用，说明路书在原型里的组织单位是「页」，而不是滚动列表——这符合电子纸的阅读方式，一次刷一整页。第二层是验证边界：浏览器里的翻页只是布局与分页逻辑的演示，它不产生任何关于刷新速度、残影或功耗的数据。tulip 是路书里的示意图形代号，本轮使用的是示意图，不是真实赛道的测量路书。

    如果要把示意路书换成真实赛道路书，数据侧可对照 SR-Track 中国赛道数据包；赛道几何与长度基准可参考 珠海国际赛车场。选屏形态（圆屏还是方屏、黑白还是彩色）的判断逻辑另见 圆屏还是方屏：车载仪表的显示形态该怎么选。

    电子纸的刷新能力为什么还算「待实测」？

    因为概览页没有给出屏控 IC、色阶与刷新方式，所以局部刷新、200 次翻页后的残影、以及休眠电流都只能列为实测项目，不能写成已达成。

    这是本项目在数据分寸上的一条硬规则：在确认波形与刷新能力之前，不把「部分刷新」写成必然支持。电子纸的刷新行为高度依赖具体屏体与波形配置——同一块 800×480 面板，全刷与局刷的表现、刷新耗时与残影积累都可能完全不同。缺了屏控 IC 与刷新方式这两项前提，任何关于「支持局刷」的结论都是推断而非事实。

    维度 彩屏（1.64 / 3.5 / 4.3 / 5.0 寸） 电子纸（3.97 寸）
    介质 彩色 AMOLED / IPS 单色电子纸 800×480
    角色 实时仪表、圈速、告警 离线静态路书
    主题 五套主题可切换 不套用彩屏主题，不受切换影响
    色彩令牌 背景层 / 文字层 / 语义四色 #F1F1EA / #202A2A 双色
    刷新与功耗 原型未验证实机帧率（30 FPS 为验收目标） 局刷、200 次翻页残影、休眠电流均为待实测

    顺带说明：这块板上另有 RTC（PCF85063）与六轴 IMU（QMI8658）。它们的存在不等于已经用上——在路书场景里，RTC 与 IMU 的用途需要在固件阶段单独设计，目前原型并未把它们接入路书的展示逻辑。另外，原型的预览使用系统字体，固件移植前同样须选定允许嵌入式再分发的字体并重新检查文字边界。

    常见问题

    3.97 寸电子纸路书支持局部刷新吗？

    目前不能下结论。微雪的概览页未列出该型号的屏控 IC、色阶与刷新方式，因此局刷能力、200 次翻页后的残影表现和休眠电流都列为实测项目。在确认波形与刷新能力之前，不把「部分刷新」写成必然支持。

    电子纸路书为什么不用彩屏的那五套主题？

    因为用途不同。五套彩屏主题（厂商 / JDM / 赛道 / 复古机械 / 霓虹遥测）服务的是实时仪表与告警，靠颜色表达状态；电子纸是单色静态介质，只负责离线阅读路书，不承担实时告警，因此保持白底黑字、单色 tulip 图与简短中文路书，也不受主题切换影响。

    原型里的 18 页路书是真实赛道数据吗？

    不是。原型使用的是示意路书：18 页内容与 3 张循环使用的示意 tulip 图，用于演示分页与布局逻辑。真实的赛道路书需要接入赛道测量数据后重新生成。

    浏览器里的翻页效果等于实机刷新效果吗？

    不等于。原型在浏览器中翻页只是布局与分页逻辑的演示，刷新能力与残影没有在浏览器中模拟。实机的刷新耗时、残影积累与功耗必须实机实测。

    本文数据来自星核火花赛车科技内部两个项目：赛道 HMI 原型项目（kno）的《赛道 HMI 原型（kno 副本 · 统一厂商风）》README（2026-10 版），以及车载小仪表开发板调研项目的《五块赛道产品候选板：硬件事实表》（核查日期 2026-10-03，参数以微雪各型号 Wiki 概览页为准）。硬件参数为官方概览页标称值，不代表实机测试完成；局部刷新、200 次翻页残影与休眠电流为源文档明确标注的待实测项目，文中未写成已达成。原型中除分辨率与色彩令牌外的数值均为明确标注的模拟数据。

  • 五套赛道 HMI 主题：配色、栅格与余光可读性

    结论：五套赛道 HMI 主题（厂商 / JDM / 赛道 / 复古机械 / 霓虹遥测）只改视觉语言，不改信息架构：它们共享同一组模拟 OBD 数据、计时与告警状态，切换主题不重置回放。决定余光可读性的不是配色本身，而是固定位置的告警区、统一字距的标签与窄无衬线大数值。

    五套主题改的是视觉语言，不是信息架构

    五套主题的差异只落在配色、字形与动效这一层，数据优先级与告警逻辑完全一致。这一点在 kno 赛道 HMI 原型里是硬约束：五套主题共享同一组模拟 OBD 数据、计时与告警状态，切换主题不重置回放。换句话说，主题是一层皮，不是一套新逻辑。

    这条约束的价值在于可验证性。如果每个主题各带一套自己的数据流或计时状态，就没法判断「同一个工况下五种视觉是否都读得出来」——变量太多。把主题限制在视觉层，才能让「换主题」这件事变成纯粹的视觉对照。信息架构本身的设计顺序另见 赛道仪表的信息架构：从圈速到告警的设计顺序。

    五套主题分别在强调什么？

    五套主题各有明确取向：厂商主题求统一克制，JDM 与霓虹求动效层次，赛道与复古求朴素可读。下表是各主题的视觉规则与数据驱动的动效。

    主题 视觉规则 数据与动效
    厂商 pro（默认） 统一深底、统一字距标签、窄无衬线大数值、青 / 琥珀 / 绿 / 红告警色板 换挡灯条与转速弧由 RPM 驱动；右侧告警柱与底栏随工况变色
    JDM 深底、压缩展示字、机械刻度、红针、湖绿车速色块 RPM 驱动分段换挡灯与指针；车速驱动进度块
    赛道 中性深底、大数字和清晰分隔线 优先突出 OBD 车速、圈速和告警
    复古机械 中性浅色表盘、细刻度、红针、衬线数字 指针随车速和转速变化，状态以文字和颜色双重表达
    霓虹遥测 深色数码排版、青 / 蓝 / 粉色量化条、模块化信息区 速度和转速用分段色块推进；报警区随工况变色

    「厂商」是这一轮新增并设为默认的主题。它的参考对象（RaceLogic / AiM MXS / PLEX SDM / MoTeC / Forza / iRacing / SimHub / RaceLab 等）在本轮只以文字描述的形式提供，图片文件不在工作区内，因此该主题是按描述建立的信息架构与原创视觉，未做逐图参考比对。所有图形、文字与布局均重新绘制，不使用任何参考品牌的 logo、商标字体或截图素材。

    颜色为什么必须写成「有用途的令牌」，而不是随手取色？

    把颜色写成有用途的令牌，是让五块屏、五套主题保持一致的前提；pro 主题的令牌按背景层、文字层、语义层三级组织。

    层级 令牌 色值 用途
    背景层 背景 #05080A 夜间主屏
    背景层 面板 #0D1417 卡片、次级底条
    背景层 抬升面 #131D21 强调格（如最佳成绩、告警格底）
    背景层 描边 #1E2B31 卡片边框
    背景层 分隔线 #16242A 字段分区
    文字层 主读数 #EDF3F4 车速、转速、时间
    文字层 次级文字 #93A7AC 标签、单位
    文字层 三级文字 #5B6E75 指标名、弱化信息
    语义层 青色 #4FD1C5 最佳圈、速度弧、强调
    语义层 琥珀 #F5B942 DELTA、预警、转速弧
    语义层 绿色 #7CD98A 低转换挡灯、正常状态
    语义层 红色 #FF5A4E 高转灯、报警
    单色介质 电子纸 #F1F1EA / #202A2A 单色静态路书

    把颜色分成三层，解决的是「改一处、乱一片」的问题。背景层只负责层次，五档灰阶拉开卡片与底条的关系；文字层只负责可读性，主读数与次级、三级文字之间有明确的亮度落差；语义层只负责含义，青 / 琥珀 / 绿 / 红各自绑定一种状态，不参与装饰。语义色一旦被拿去当装饰，告警就不再可靠——这是配色表里最需要守住的一条。

    余光可读性靠哪三条规则保证？

    余光可读性靠三条可执行的规则：告警位置固定、标签统一加字距、数值走窄无衬线大字号。它们都是可检查的工程约束，不是审美偏好。

    第一条是告警位置固定。赛道驾驶时不可能逐字阅读，只能靠余光判断颜色和位置：在 3.5 寸上是顶部换挡灯条加下方四格，告警时水温与油压两格转红并描红边；在 4.3 与 5.0 寸上是右侧独立的告警状态柱，固定显示油压、水温、电压、OBD 四项。位置不随数据变化而移动，是余光可读的前提——告警一旦会「跳」，余光就失效了。

    第二条是标签统一加字距（letter-spacing）。中文标签在深底窄间距下容易糊成一团，统一拉开字距能让字符边界在余光下更清楚。

    第三条是数值走 Bahnschrift 类窄无衬线字体。窄无衬线在相同物理宽度内能塞下更大的字号，这对 1.64 寸这类小画布尤其关键。

    这些主题目前能证明什么、不能证明什么？

    能证明的是信息架构与视觉语言的自洽性，不能证明的是任何实机显示与计时性能。原型的自动校验用 Playwright 遍历 5 块屏 × 5 套主题 × 全部副视图，逐项检查：SVG viewBox 是否为各板原生像素尺寸；所有 <text> 元素是否越出画布（用 getBBox() 逐项检测）；SVG 内容中是否泄漏 undefined 字符串；默认主题是否为 pro、主题切换是否生效；以及 OBD 回放推进、计时完成、断连状态、路书翻页、移动端横向溢出等交互状态。

    但边界必须写明——这套原型不证明 ESP-IDF / LVGL 点屏、SPI / DSI 帧率、实车 PID 支持或计时精度。显示链路的帧率约束可参考 车载 HMI 的 30 FPS：SPI 与 MIPI-DSI 显示链路差在哪。另外两条限制同样要留档：预览使用的是系统字体（Bahnschrift / Microsoft YaHei / Impact / Georgia / Consolas），固件移植前须选定允许嵌入式再分发的字体并重新检查文字边界；圈速、侧向 G、胎压等数值为示意值，档位与油压尚无车型适配，零百计时只使用模拟 OBD 车速，实机须接入受保护的 OBD 网关。

    还有一层方法论上的取舍值得记录。本轮在动手之前先检索了可核验的 UI 设计 skill：本机 skill-installer 的 OpenAI curated 目录接口返回 HTTP 403，应用内浏览器的设计系统检索连接超时，本机 visualize skill 的说明明确其用于对话内可视化、不适用于修改现有项目页面。因此本轮没有安装或引用任何未经核验的第三方 skill，风格直接落在已有 HMI 工程里实现。这比先引入一个来路不明的设计系统再回退要省事得多。赛道数据侧可对照 SR-Data 圈速分析套件，赛道几何与圈速基准可参考 上海国际赛车场。

    常见问题

    赛道仪表的配色应该先定哪一层？

    先定语义层，再定文字层，最后定背景层。语义色（青 / 琥珀 / 绿 / 红）绑定告警含义，一旦被装饰占用就失去可靠性；文字层要保证主读数与次级、三级文字有明确亮度落差；背景层只是把卡片与底条分出层次。顺序反了，改配色时会连带改掉信息层级。

    JDM 主题和霓虹主题的核心区别是什么？

    区别在动效的表达方式。JDM 用机械刻度、实体指针和珊瑚红 / 湖绿实色色块，靠 RPM 驱动分段换挡灯与指针、车速驱动进度块；霓虹遥测则用深色数码排版、青 / 蓝 / 粉色量化条和模块化信息区，靠速度和转速的分段色块推进。前者模仿机械表，后者模仿数码遥测。

    切换视觉主题会重置计时或 OBD 数据吗？

    不会。五套主题共享同一组模拟 OBD 数据、计时与告警状态，切换主题不重置回放。这正是把主题限制在视觉层的目的——保证换主题时变量只有一个。

    这五套主题能直接烧进固件吗？

    不能直接移植。它们用系统字体渲染，且不证明 ESP-IDF / LVGL 点屏、SPI / DSI 帧率、实车 PID 支持或计时精度。固件移植前须选定允许嵌入式再分发的字体并重新检查文字边界，并完成实机验证。

    本文数据来自星核火花赛车科技内部赛道 HMI 原型项目（kno）的《赛道 HMI 原型（kno 副本 · 统一厂商风）》README（2026-10 版）与《仪表 UI 风格与 skill 检索》（检索日期 2026-10-04）。五套主题共享的 OBD、计时与告警状态均为明确标注的模拟数据；「厂商」主题未做逐图参考分析，参考图仅以文字描述形式提供。文中的 skill 检索结果（HTTP 403、连接超时、visualize 不适用）为 2026-10-04 当次实测结论，仅代表当日状态。本原型不构成对 ESP-IDF / LVGL 点屏、SPI / DSI 帧率、实车 PID 支持或计时精度的验证。

  • 赛道仪表的信息架构：从圈速到告警的设计顺序

    结论：赛道仪表的信息架构顺序是「先定要显示什么，再定怎么排」：以真实赛车仪表的数据排布与告警逻辑作骨架，以赛车游戏 HUD 的夜间对比与字号层级作视觉语言。同一套架构套用到五个画布时，尺寸只改变信息密度，不改变信息优先级——圈速与告警永远优先。

    信息架构先于视觉：先排序，再排版

    做赛道 HMI，容易一上来就纠结配色和圆表外形，但真正要先定的是信息优先级。kno 赛道 HMI 原型的做法是分成两层：以真实赛车仪表的通用做法作信息架构骨架（数据怎么排布、告警怎么触发），以赛车游戏 HUD 的可读性作视觉语言（夜间对比、字号层级、动效层次），最后产出同风格的原创界面。

    这个顺序的意思是：先把「哪些数据必须常驻、哪些只在告警时出现」排清楚，再决定色板和栅格。反过来先定视觉，往往会在改配色时连带改掉信息层级。

    五个画布，一套架构，信息密度不同

    原型覆盖五块屏，逻辑分辨率全部按横屏设计。尺寸变的是「能放多少格」，不变的是「谁在最前面」。

    画布 逻辑分辨率 布局要点 承载的信息
    1.64 寸 456×280（物理面板原生 280×456 旋转） 极简计时：黑底、超大数字、TOTAL / CURRENT 双格，不含圆表；底部为 0—60 与 0—100 进度条 单次计时结果
    3.5 寸 480×320（物理面板原生 320×480 旋转） 顶部 LED 换挡灯条（绿 → 琥珀 → 红）＋ 左侧转速弧 ＋ 右侧大车速 ＋ 下方四格 单表 + 车辆状态（LAP / 圈速 / 水温 / 油压）
    4.3 寸 800×480 左上圈速栈（LAP / 本圈 / 最快圈 / DELTA）＋ 中央双圆表（GPS 速度 + 发动机转速）＋ 右侧告警状态柱 ＋ 底部辅助条 赛道分区
    5.0 寸 1280×720 同 4.3 分区，底栏多一格胎压 赛道 + 数据源 + 胎压
    3.97 寸电子纸 800×480 白底黑字、大 tulip 路线图、简短中文路书，不套用彩屏主题 离线路书

    注意 4.3 与 5.0 寸的中央双圆表：两表半径与圆心由可用区的宽和高度共同推导，目的是保证宽屏下不重叠。这是信息架构落到几何约束的一步——不是把两张表并排贴上去就能成立。5.0 寸底栏多出的胎压格也不是简单加一行，而是因为 1280×720 比 800×480 宽得多，才有余量在不牺牲主读数字号的前提下多放一格，属于宽屏专属的信息密度。

    告警为什么必须放在固定的状态区

    告警的位置和颜色必须固定，驾驶者才能用余光判断，而不必去读具体数字。

    在 3.5 寸上是顶部换挡灯条加下方四格：告警时水温与油压两格转红并描红边。在 4.3 与 5.0 寸上是右侧独立的告警状态柱，固定显示油压、水温、电压、OBD 四项。位置不随数据变化而移动，是余光可读的前提；如果告警图标会「跳」到别处，余光就失效了，只能回到逐字阅读，反而更慢。

    主题只改视觉语言，不改信息架构

    五套主题共享同一组模拟 OBD 数据、计时与告警状态，切换主题不重置回放。也就是说主题是一层皮，不是一套新逻辑。

    kno 在原有的 JDM / 赛道 / 复古 / 霓虹四套主题基础上，新增第五套「厂商（pro）」并设为默认。差异集中在配色、字形与动效：JDM 是密刻度、实体指针与珊瑚红/湖绿实色色块；赛道版强调朴素的信息层级；复古版采用浅灰机械表盘、细刻度与红针；霓虹版采用大数字、分段转速／速度条和状态矩阵。它们改的是视觉语言，数据优先级始终一致。电子纸路书则完全不套用彩屏主题，也不受主题切换影响。

    设计令牌：pro 主题的色板与用途

    把颜色写成有用途的令牌，而不是随手取色，是让五块屏和五套主题保持一致的关键。pro 主题的令牌如下：

    令牌 色值 用途
    背景 #05080A 夜间主屏
    面板 #0D1417 卡片、次级底条
    抬升面 #131D21 强调格（如最佳成绩、告警格底）
    描边 #1E2B31 卡片边框
    分隔线 #16242A 字段分区
    主读数 #EDF3F4 车速、转速、时间
    次级文字 #93A7AC 标签、单位
    三级文字 #5B6E75 指标名、弱化信息
    青色 #4FD1C5 最佳圈、速度弧、强调
    琥珀 #F5B942 DELTA、预警、转速弧
    绿色 #7CD98A 低转换挡灯、正常状态
    红色 #FF5A4E 高转灯、报警
    电子纸 #F1F1EA / #202A2A 单色静态路书

    标签统一加字距（letter-spacing），数值走 Bahnschrift 类窄无衬线字体，目的是在余光条件下提高字符可辨识度。这条规则和告警固定区是同一套逻辑：一切为「扫一眼就能读」服务。

    原型能证明什么，不能证明什么

    kno 是信息架构与视觉语言的验证原型，其中的 OBD、油压、档位、胎压等数值均为明确标注的模拟数据。

    它的自动校验用 Playwright 遍历 5 块屏 × 5 套主题 × 全部副视图，逐项检查：SVG viewBox 是否为各板原生像素尺寸；所有 <text> 元素是否越出画布（用 getBBox() 逐项检测）；SVG 内容中是否泄漏 undefined 字符串；默认主题是否为 pro、主题切换是否生效；以及 OBD 回放推进、计时完成、断连状态、路书翻页、移动端横向溢出等交互状态。

    但边界必须写明——该原型不证明 ESP-IDF / LVGL 点屏、SPI / DSI 帧率、实车 PID 支持或计时精度；电子纸的刷新能力与残影没有在浏览器中模拟；预览使用的是系统字体，固件移植前须选定允许嵌入式再分发的字体并重新检查文字边界；1.64 的横屏旋转与触摸映射尚待实机验证；圈速、侧向 G、胎压等数值为示意值，档位与油压尚无车型适配，实机须接入受保护的 OBD 网关。显示链路的帧率约束可参考 车载 HMI 的 30 FPS：SPI 与 MIPI-DSI 显示链路差在哪。

    还有一条本轮的明确限制：新增的「厂商」主题没有对照编号参考图逐像素比对。参考图（RaceLogic / AiM MXS / PLEX SDM / MoTeC / Forza / iRacing / SimHub / RaceLab 等）在本轮只以文字描述的形式提供，图片文件不在工作区内，因此该主题是按描述建立的信息架构与原创视觉，不声称完成了逐图参考分析。所有图形、文字与布局均重新绘制，不使用任何参考品牌的 logo、商标字体或截图素材。相关选屏与形态判断，另见 圆屏还是方屏：车载仪表的显示形态该怎么选；数据落地侧可对照 SR-RaceBox 车载数据采集器。

    常见问题

    赛道仪表的显示顺序应该怎么定？

    先定信息优先级，再定排版。圈速栈与告警优先：圈速栈回答「这圈跑得怎么样」，告警区回答「车还能不能跑」。在此之外的信息（水温、电压、胎压）才按屏幕尺寸铺开。

    5.0 寸的底栏为什么比 4.3 寸多一格？

    因为宽屏有余量。5.0 寸逻辑分辨率 1280×720，比 4.3 寸的 800×480 宽得多，因此底栏可以多放一格胎压作为宽屏专属的信息密度，而不必牺牲主读数的字号。

    电子纸路书为什么不套用彩屏主题？

    因为用途不同。电子纸是黑白静态介质，用于离线阅读路书，不承担实时告警，所以采用白底黑字、大 tulip 路线图与简短中文路书，也不受彩屏主题切换影响。

    kno 原型能直接用于固件吗？

    不能直接移植。原型用系统字体渲染，且不证明 ESP-IDF / LVGL 点屏、SPI / DSI 帧率、实车 PID 支持或计时精度。固件移植前须选定允许嵌入式再分发的字体并重新检查文字边界，并完成实机验证。

    本文数据来自星核火花赛车科技内部赛道 HMI 原型项目（kno）的《赛道 HMI 原型（kno 副本 · 统一厂商风）》README（2026-10 版）。原型中除设计令牌与分辨率外的数值均为明确标注的模拟数据；「厂商」主题未做逐图参考分析，参考图仅以文字描述形式提供。原型不构成对 ESP-IDF / LVGL 点屏、SPI / DSI 帧率、实车 PID 支持或计时精度的验证。

  • OBD-II PID 入门：车速 0x0D 为什么是整数

    结论：OBD-II 标准 PID 0x0D（车速）返回的是整数 km/h，最小刻度就是 1 km/h，所以基于它做零百计时天然带约 1 km/h 的量化误差。真正决定成绩的不是界面刷新率，而是状态机在收到响应的那一刻锁定的时间戳——起点、60 km/h、100 km/h 三个点，都是「首次收到满足条件的样本」的接收时刻。

    为什么 0x0D 返回的是整数

    0x0D 是 OBD-II 的标准车速 PID，源文档口径明确写为「返回整数 km/h」。这意味着读回来的永远是整数，不会出现 60.5 km/h 这样的值。按 OBD-II 标准的通用定义，该 PID 为单字节量，以 1 km/h 为步长，值域覆盖 0–255 km/h（此值域属行业通识，非本项目实测数据）。

    整数输出带来的直接后果是：任何比 1 km/h 更细的门槛，都无法「直接读到」，只能靠推导。这一点决定了后面所有计时逻辑都要围绕「整数刻度」来设计，而不是围绕理想中的连续速度曲线。

    一次车速读数要走完的链路

    从主机发出请求，到拿到一个可用于计时的车速样本，中间要经过网关与总线，每一环都会给时间戳添上延迟。因此本项目要求每条车速样本保存六项元数据，缺一项就无法判断该样本是否可信。

    样本字段 用途
    原始响应 保留网关返回的原始字节，便于事后回溯
    解码值 把原始响应按协议换算成 km/h 后的数值
    请求发出时间 与接收时间一起算出单次请求的往返延迟
    响应接收时间 作为计时时间戳的基准
    网关状态 判断该样本是否来自可用、可信的链路
    单调时钟时间戳 避免系统时间被调整时影响计时差值

    必须强调：记录下的时间戳是 OBD 响应接收时刻，不是 ECU 的实际采样时刻。从 ECU 采样到主机收到响应之间，存在请求往返延迟和网关额外延迟，主机无从得知 ECU 精确的采样瞬间。所以计时精度首先受链路延迟约束，而不是受显示系统约束。

    数据源上还有一条硬边界：首选「经受保护车载网关读取标准 PID 0x0D」；若某车型使用专用车速信号，必须在车型配置里明确协议、单位与量化精度，不能默认它和 0x0D 一样。

    为什么「0.5 km/h 起步阈值」在 0x0D 上做不到

    因为 0x0D 只返回整数，没有 0.5 km/h 这个刻度，源文档因此直接写明：「0.5 km/h 起步阈值」无法直接实现。

    理论上可以用 0→1 与 99→100 两点插值，把整数跳变反推成更细的时间点。但插值是否成立，取决于轮询周期、请求往返延迟和车型信号特性——这三项必须先实测记录，才能评估误差量级。因此首版方案的结论是：不插值，也不用 IMU 或 GPS 去填补样本。起点判定只能落在「首次收到大于 0 km/h 的有效样本」上，其误差上限与实际有效更新率直接相关。

    计时状态机：两个锁存点，一次异常即作废

    状态机的作用是把「什么时候算开始、什么时候算结束」写成可复核的规则，避免用显示刷新或人为判断来计时。首版状态机如下：

    状态 触发条件 动作
    IDLE 收到连续有效的 0 km/h 样本，覆盖至少 1 秒 进入 ARMED
    ARMED 首次收到有效且大于 0 km/h 的车速 记该样本接收时刻为 t0，进入 RUNNING
    RUNNING 首次收到车速 ≥ 60 km/h 记 t60；继续计时
    RUNNING 首次收到车速 ≥ 100 km/h 记 t100，锁存 t100 − t0 与 t60 − t0，进入 COMPLETE
    任意计时状态 网关断连、PID 不支持、响应超时、样本乱序或不可信 标记本次无效，保存原因，不显示成功成绩

    只有 t100 出现时才锁存成绩；中途出现任何一种异常，本次都判为无效并记录原因，不会输出一个「看起来正常」的秒数。这样做的代价是弃权率升高，收益是每一条显示出来的成绩都能追溯到具体样本。

    还有一个容易踩的坑：「连续 0 km/h」必须由多个有效样本构成，不能把网关断连期间保持的旧值算进那 1 秒。否则车辆其实没动，也可能因为缓存值而被误判为已就绪。

    采样频率不等于刷新频率

    界面上数字跳得快，不代表车速采样得快。界面刷新频率只是渲染频率，车速采样频率由 PID 的轮询周期决定，两者不是一回事。把二者混为一谈，就会用「看起来很流畅」掩盖「样本其实很稀疏」的事实。

    显示层需要提供五种状态：待连接、待起步、计时中、成绩、无效记录。并且历史最佳只收录有效、且带车型与数据源元信息的成绩——否则一次异常样本就可能被当成纪录留存下来。相关界面形态可参考 圆屏还是方屏：车载仪表的显示形态该怎么选，其中说明了为什么 1.64 寸这类 280×456 竖屏适合做成计时器。

    验收前必须实测的三组数据

    在把任何精度写进规格之前，以下三组数据是硬前提，缺任何一组都无法声称精度：

    1. 注入测试：向同一套解析与状态机灌入速度曲线，覆盖缓慢起步、瞬时跳值、重复帧、乱序、超时和中途失联，逐项核对状态迁移与时间戳是否符合预期。
    2. 实车链路记录：在目标车型上记录 PID 支持情况、有效车速更新率、请求往返延迟分布、网关额外延迟，以及计时期间的丢包率。
    3. 独立参照比对：用独立参考设备同步采集多次 0–100 加速，统计偏差与离散程度。

    最后必须说清楚：源文档中 ±0.05s 与「优于手机」是待验证目标。在没有实测证据之前，它们既不能写成已达到的精度，也不能作为宣传文案。计时链路的原理与数据源约束，另见 OBD 零百加速计时：为什么手机测不准，仪表该怎么算；采集侧的实现可对照 SR-RaceBox 车载数据采集器。

    常见问题

    0x0D 能读出小数点后的车速吗？

    不能。0x0D 返回整数 km/h，最小刻度就是 1 km/h。更细的分辨率只能靠插值推导，而插值是否可用取决于轮询周期与链路延迟，首版方案不做插值。

    为什么不能用 GPS 或 IMU 辅助计时？

    本项目里 GPS 不参与计时、插值或丢包补偿；QMI8658 只记录峰值 G 和 G 曲线，不参与起点、60 km/h、终点的时间戳判定。计时输入唯一来自 OBD 车速，以保证每一条成绩都能追溯到具体数据源。

    为什么时间戳不是 ECU 采样时刻？

    因为记录的是 OBD 响应接收时刻。从 ECU 采样到主机收到响应之间有请求往返延迟和网关额外延迟，主机无法得知 ECU 精确的采样瞬间，所以计时精度先受链路延迟约束。

    一次零百成绩什么时候才算有效？

    要同时满足两点：状态机按顺序经过 IDLE → ARMED → RUNNING，并在收到 ≥ 100 km/h 的样本时锁存成绩；且全程没有出现网关断连、PID 不支持、响应超时、样本乱序或不可信。任一异常都判为无效并保存原因。

    本文数据来自星核火花赛车科技内部车载仪表研究项目的《1.64 寸 OBD 零百计时规格》（2026-10 版）。PID 0x0D 的精度、延迟与插值可行性均以实车标定为准；文中的 ±0.05s 与「优于手机」为源文档标注的待验证目标，非已达成的精度指标。文中 0–255 km/h 值域为 OBD-II 行业通识，未经本项目实测，仅供理解整数刻度之用。

  • 车载 HMI 的 30 FPS：SPI 与 MIPI-DSI 显示链路差在哪

    结论：三块 ESP32-P4 板上的「30 FPS」是验收目标，不是已达成的硬件事实。3.5 寸走 SPI（ST7796），4.3 与 5 寸走 MIPI-DSI 2-lane，显示链路不同；按 16 位色深计算，30 FPS 的裸像素带宽需求依次约为 9.22、23.04、55.30 MB/s。三块板必须分别实测满屏与局部刷新，不能用同一套 HMI 代码推断性能相同。

    先把「30 FPS」定性：它是验收目标，不是硬件事实

    很多方案文档会把 30 FPS 直接写进规格，仿佛它已经实现。在这三块板上不能这么写：30 FPS 是验收目标，尚非硬件事实。3.5 寸的 SPI 显示链路与另外两块 MIPI-DSI 板子不同，需要分别测量满屏刷新、局部刷新、PSRAM 和总线占用。结论很直接——不能因为三块板跑的是同一套 HMI 代码，就推断三者的性能相同。

    三条链路的物理差异在哪

    SPI 是一条同步串行总线：时钟由主控产生，数据按位依次发送，通常还要和同一总线上的其他外设分时共享。MIPI-DSI 是显示专用的高速差分接口，用 1 条或多条 lane 并行传像素数据，天生为刷屏设计。这里的差别不在「谁更快」，而在它是共享总线还是专用通道。

    三块板的分工正好卡在这条线上：3.5 寸用 ST7796 走 SPI 并带 FT6336 触摸；4.3 寸和 5 寸用 MIPI-DSI 2-lane。把它写成一句话：3.5 寸是在一条通用总线上刷屏，另外两块是在专用通道上刷屏，后者的理论余量更大，但这只是起点，不是结论。

    裸带宽算一遍：每块板每帧要搬多少字节

    先算清楚工作量，再谈能不能做到。下表按 16 位色深（RGB565）与 30 FPS 上限计算，给出的是裸像素带宽需求——是推导值，不等于实测帧率，也不包含触摸、音频、网络占用的余量。

    板卡 原生像素 横屏 UI 目标 显示接口 每帧字节（16 位） 30 FPS 裸带宽需求
    ESP32-P4-WIFI6-Touch-LCD-3.5-EN 320×480 原生竖屏 SPI，ST7796 307,200 B（约 300 KiB） 约 9.22 MB/s
    ESP32-P4-WIFI6-Touch-LCD-4.3 480×800 800×480 MIPI-DSI 2-lane 768,000 B（约 750 KiB） 约 23.04 MB/s
    ESP32-P4-WIFI6-Touch-LCD-5-C 720×1280 1280×720 MIPI-DSI 2-lane 1,843,200 B（约 1.76 MiB） 约 55.30 MB/s

    这张表已经说明了为什么不能一把尺子量三块板：5 寸屏每帧要搬的字节是 3.5 寸的 6 倍。同样的动画效果，在 3.5 寸上可能宽裕，在 5 寸上就是六倍的搬运量。反过来说，「屏小就好做」也不成立——3.5 寸的接口是三者中最受限的一条。

    带宽够了仍然可能掉帧：PSRAM 与总线占用

    像素带宽只是必要条件，不是充分条件。真正决定帧率的是数据从哪来、经过谁、在哪里排队：如果帧缓冲放在 PSRAM，每一次刷屏都要从 PSRAM 读一遍再送到屏上，而 PSRAM 的访问带宽同时还要被其他任务分享。这就是为什么测量清单里必须包含 PSRAM 占用和总线占用，而不只是看屏的接口型号。

    局部刷新是另一条关键路径。赛道仪表上大量区域是静态的，只有转速、速度、G 值在变。只重绘变化区域，可以把每帧的搬运量降到远低于全屏的值；这一点对 SPI 链路尤其重要，因为它本来就没有多少余量。要求「满屏 30 FPS」和「界面 30 FPS 感受」是两件不同的事，验收时必须分开定义。

    尺寸不是唯一变量：三块板的其它差异

    把三块板当成「除了屏大小都一样」是常见误判。至少 Flash、触摸 IC 和板载传感器的记载就不同。

    项目 P4-3.5-EN P4-4.3 P4-5-C
    主控 ESP32-P4NRW32 + ESP32-C6 ESP32-P4NRW32 + C6-MINI-1 ESP32-P4NRW32 + C6-MINI-1
    PSRAM 32MB 32MB 32MB
    Flash 16MB 32MB 32MB
    触摸 IC FT6336（I2C） 概览页未列 概览页未列
    板载 IMU Wiki 未列 Wiki 未列 Wiki 未列
    资料完整度 概览页未列板载 IMU 概览页未列触摸 IC 概览页未列触摸 IC；采购记录为带摄像头版

    三点提示：其一，4.3 与 5 寸的触摸 IC 在概览页里没有列出，需要从官方资料继续查，不能凭经验填；其二，三块 P4 板 Wiki 均未列板载 IMU，G 值这类数据要外接传感器并单独核实；其三，外接传感器与车源同样要单独设计——芯片的 TWAI 外设不等于可直接接车载 CAN，车电保护、隔离收发器、车型信号和接插件都要另做。

    该测什么：四项，缺一不可

    1. 满屏刷新——全屏一次性重绘，记录实测帧时间与掉帧情况。
    2. 局部刷新——只重绘变化区域，观察帧率与画面一致性。
    3. PSRAM 占用——帧缓冲与素材常驻后的可用余量，以及刷屏期间的峰值占用。
    4. 总线占用——SPI 链路要单独看总线在刷屏、触摸、SD 之间的分时表现。

    四项都要在完整功能固件下测量，不能用只点屏的最小 demo 代替。现有 P4 共用工程目前只有模拟速度、转速和失联首屏，趋势、行程、诊断和真实 OBD 网关尚未开发，因此当下的帧率数据不代表整机表现。

    常见问题

    三块 P4 板现在能做到 30 FPS 吗？

    不能下这个结论。30 FPS 是验收目标而非硬件事实，需要按满屏刷新、局部刷新、PSRAM 和总线占用四项分别在完整功能固件下实测，目前没有可引用的实测数据。

    MIPI-DSI 的 4.3 和 5 寸一定比 SPI 的 3.5 寸流畅吗？

    不能直接比较。接口只是起点，实际帧率还取决于 PSRAM 访问带宽、DMA 配置、局部刷新策略与总线占用。5 寸每帧搬运量是 3.5 寸的 6 倍，接口更宽不代表结果更好，必须各自实测。

    为什么 3.5 寸的 SPI 链路更受关注？

    因为 SPI 是共享总线，刷屏要和同一总线上的其它外设分时，且每帧 307,200 字节的搬运量没有多少余量。局部刷新对它的价值最大，也最需要验证。

    外接 OBD 会占用显示带宽吗？

    不会直接占用显示接口，但会通过 CPU 与内存访问间接竞争。芯片的 TWAI 外设不等于可直接接车载 CAN，车电保护与隔离收发器要另做；总线占用必须在完整功能固件下测量才能反映真实竞争。

    本文数据来自星核火花赛车科技内部车载仪表研究项目的《五块赛道产品候选板硬件事实表》（核查日期 2026-10-03）。表中带宽为按 16 位色深与 30 FPS 推导的裸像素需求，非实测帧率；「30 FPS」保留为待验证的验收目标。

  • 圆屏还是方屏：车载仪表的显示形态该怎么选

    结论：车载仪表选圆屏还是方屏，先看面板原生像素和装配形态，再看 UI 需求。圆屏（466×466、360×360、240×240）适合单个大数字与弧形仪表；竖屏（280×456、320×480）适合零百计时和多行参数；横屏（800×480、1280×720）适合多字段对照与路书正文。设计稿上的 400×400 不等于板子的原生像素，形态在选板那一刻就定了。

    形态由面板原生像素和装配方式决定，不由 UI 风格决定

    一块板是圆屏、竖屏还是横屏，在采购下单时就已经固定，UI 只能去适配它，不能反过来改它。面板的物理像素是硬约束：已核对的候选板里，ESP32-S3-Touch-AMOLED-1.64 是 280×456 长方形 AMOLED，M5Stack CoreS3 是 2.0 寸 320×240 方屏，Seeed 的圆屏扩展板是 1.28 寸 240×240。把设计稿画成 400×400 或随便一个正方形，都不会让板子多出像素。

    像素定了，可排的信息量也就定了。圆屏的四角天然是被裁掉的，越靠中心越安全，所以它适合「一个大数字 + 一圈刻度」；长方形的 280×456 宽度只够一到两列；横屏 800×480 以上才有条件并排放多个读数。这不是审美选择，是面积分配问题。

    圆屏、竖屏、横屏各擅长什么信息形态

    三种形态解决的是三类不同问题：圆屏做单值聚焦，竖屏做时序与计数，横屏做并列对照。选错形态，界面会一直在和可用面积打架。

    形态 代表像素 擅长 不擅长 典型用途
    圆屏 466×466 / 360×360 / 240×240 单个大数字、弧形转速表、单值告警、余光可读 多字段表格、长文本、导航列表 车内时钟、单数据表、摩托与自行车表
    竖屏 / 长方 280×456 / 320×480 / 240×320 竖排参数、计时与状态机、多行数据 双列对照、宽表、长路书 OBD 零百计时器、赛道单表
    横屏 800×480 / 1280×720 / 800×480（电子纸） 双大读数、数据源状态列、路书正文 圆表外壳、单值聚焦场景 P4 扩展 OBD 表、离线路书

    注意最后一行的 800×480 出现了两次：一次是 P4 4.3 寸 IPS 的横屏 UI 目标，一次是 3.97 寸电子纸路书。像素相同，但一个是实时刷新，一个只做静态阅读，能承载的信息层级完全不同。

    已核对的候选板：谁的屏是什么形态

    把形态、像素、接口和触摸放在一张表里，才能看出「能换外壳」和「能换屏幕」是两件事。

    板卡 屏幕类型 原生像素 形态 触摸方案
    ESP32-S3-Touch-AMOLED-1.64 AMOLED，CO5300 QSPI 280×456 长方形，明确不是圆屏 FT3168，I2C
    ESP32-S3-Touch-AMOLED-1.75 / 1.75C AMOLED 466×466 圆屏（已有资料口径为圆表） 概览页未列
    ESP32-S3-Touch-AMOLED-1.43-B AMOLED，标称亮度 350 cd/m² 466×466 小尺寸圆屏 概览页未列
    ESP32-S3-Touch-LCD-1.85B-EN LCD 360×360 圆屏 概览页未列
    ESP32-S3-Touch-LCD-2 LCD，QMI8658 240×320 方屏 概览页未列
    ESP32-P4-WIFI6-Touch-LCD-3.5-EN IPS，ST7796 SPI 320×480 竖屏 FT6336，I2C
    ESP32-P4-WIFI6-Touch-LCD-4.3 IPS，MIPI-DSI 2-lane 480×800（UI 目标 800×480） 横屏 概览页未列 IC
    ESP32-P4-WIFI6-Touch-LCD-5-C IPS，MIPI-DSI 2-lane 720×1280（UI 目标 1280×720） 横屏，采购为带摄像头版 概览页未列 IC
    ESP32-S3-ePaper-3.97-EN 电子纸 800×480 横屏路书 概览页未列触摸
    M5Stack CoreS3 IPS 电容触摸 320×240 2.0 寸方屏 电容触摸
    Seeed Round Display for XIAO 圆形电容触摸屏 240×240 1.28 寸圆屏，直径约 39mm 电容触摸

    这张表里有两处必须点出来。第一，CoreS3 是方屏，外壳和显示形态都无法直接复用汽车圆表，它的价值在 CAN、音频和 UI 组合验证，不在形态。第二，1.28 寸 240×240 的圆屏复用不了 1.75 寸 466×466 的界面资产——尺寸、色深、显示驱动都不一样，只能当自研架构的验证样机。

    一个反例：1.64 的 400×400 概念稿为什么必须作废

    1.64 的原视觉稿画的是一块 400×400 的圈速页，但这块板原生是 280×456 长方形 AMOLED，两者对不上：1.64 不是圆屏，400×400 也不是它的原生像素。这份概念稿已被判定为过时，该板现在的方向是 OBD 车速零百计时器，并已按 280×456 竖屏重做了交互原型（原理见 OBD 零百加速计时为什么手机测不准）。

    更值得注意的是引脚层面：微雪为这块板区分了 V1 与 V1.1，LCD_CS 与 IMU_INT1 的 GPIO9 / GPIO46 分配在两个修订版之间互换，而已购板的版本丝印尚未核实。也就是说，连引脚都不能只按型号名推断，形态同理。

    形态判定要回到官方尺寸图和实物，不能靠命名

    型号名里带「1.75」不等于圆屏，带「-B」也不一定是独立硬件版本，这些后缀在微雪体系里的含义要逐型号确认。更实际的坑是资料完整度：几块 P4 板的 Wiki 概览页并未列全触摸 IC 和板载 IMU（4.3 与 5 寸未列触摸 IC，P4 三板均未列板载 IMU），电子纸板也未列屏控 IC、色阶与刷新方式。凡概览页没有的字段，只能从官方资料继续查，不能凭经验填值，也不能把同硬件家族的装配变体当成独立形态来重复设计。

    选形态前先回答三个问题

    1. 首屏要显示一个数还是多个数？单个大数字选圆屏；三到五个并列读数至少要横屏。
    2. 这块屏是给人「扫一眼」还是「读一段」？扫一眼用圆屏或竖屏的大字；读一段（路书）只能上横屏，且电子纸这类静态介质不承担实时告警。
    3. 装车形态定了吗？汽车圆表、摩托圆表、自行车码表的外壳和安装方式不同，先定装配再定屏，否则外形和屏幕会互相改。

    相关选板逻辑可对照 车载小仪表开发板选型：微雪 / M5Stack / Seeed 三家横向对照。

    常见问题

    圆屏的 466×466 是圆形的吗？

    不是。466×466 描述的是像素阵列是正方形，面板外形是圆的，四角区域不显示。所以圆屏实际可用的有效排版区域小于同像素的方形面板，这也是它只能承载「一个大数字加一圈刻度」的原因。

    能不能用一块方屏做出圆表的外观？

    可以用遮罩或外壳遮成圆形，但代价是浪费四角像素、并让触摸区域与显示区域错位。汽车圆表和摩托表之所以坚持用圆屏，是形态与安装决定的，不是显示决定的。

    1.28 寸的圆屏能直接套用 1.75 寸的界面吗？

    不能。1.28 寸是 240×240，1.75 寸是 466×466，尺寸、色深和显示驱动都不同，界面资产需要重新排布。它更适合用来验证自研底板、引脚分配和显示抽象层。

    为什么同一块板要区分 V1 和 V1.1？

    因为硬件修订会改动引脚分配。1.64 的 V1 与 V1.1 就互换了 LCD_CS 与 IMU_INT1 的 GPIO9 / GPIO46，若按错版本建 BSP，屏和 IMU 都会异常。已购板的丝印必须逐一核对。

    本文数据来自星核火花赛车科技内部车载仪表研究项目的《五块赛道产品候选板硬件事实表》与《小仪表开发板详细调研与路线建议》（2026-10 版）。参数以各型号微雪 Wiki 概览页为准，实际 PCB 修订版仍需核对丝印；本文不构成量产或开源硬件授权判断。

  • 车载小仪表开发板选型：微雪 / M5Stack / Seeed 三家横向对照

    结论：做车载小仪表，微雪的 ESP32-S3-Touch-AMOLED-1.75（SKU 31261）适合作为汽车标准版的基线——S3、8MB PSRAM、16MB Flash、466×466 AMOLED、双麦、IMU、RTC、TF、Wi-Fi/BLE 的组合足够完成第一版功能验证。但它没有板载 OBD/CAN 物理接口，也没有车电保护，必须另做接口盒或底板。M5Stack CoreS3 适合当 CAN/语音实验台，Seeed 的 XIAO + 圆屏适合验证「模块 + 自研底板」路线，两者都不直接替代圆屏产品形态。

    先说选型的三个前提

    开发板选型最容易犯的错，是把「开发板能跑通 Demo」当成「产品能落地」。三件事必须先讲清楚：

    1. 开发板不等于商品形态。圆屏、外壳、车电保护、OBD 线束、安装方式，全都不在开发板里。
    2. 同硬件家族的装配变体不能当成独立平台。1.75 无壳版和 1.75-B 带壳版的基础电子设计相同，不应该维护两份固件。
    3. 样机价不是量产价。采购表里的是已购均价，适合比较样机采购，不是 100 / 1000 片报价。

    三家厂商横向对照

    厂商 代表方案 适配理由 主要限制 定位
    微雪 Waveshare S3 1.75 / 1.75C、1.85、P4 4.3 已购样机与现有固件，圆屏形态接近产品 车电 / OBD 要外加；开源程度逐项不同 主调研对象
    M5Stack CoreS3、M5Dial、Unit CAN 现成的语音、IMU、模块化 CAN 实验链 方屏 / 小屏形态；模块叠加后体积与成本上升 对照 / 验证平台
    Seeed Studio XIAO ESP32S3 + Round Display 模块小，官方有原理图与 PCB 包 1.28 寸 240×240，接口资源需重新分配 自研过渡参考
    LILYGO T-RGB 2.1 / 2.8 圆形 IPS 2.1 寸 480×480 可试摩托 / 自行车大表 非 1.75 AMOLED；尺寸、功耗与外壳要重做 第二轮候选
    Elecrow CrowPanel 1.28 寸旋钮圆屏 对照旋钮交互与低成本 IPS 1.28 寸偏小；仓库未标明许可证 交互参考
    乐鑫 Espressif ESP32-S3-BOX-3、ESP-IDF 官方芯片 / 语音 / 总线开发资料 开发套件不是目标商品形态 SDK 与设计规范来源

    这张表不等于「这些板都是开源硬件」。每块板卡都必须分别检查软件、原理图、PCB 源文件、BOM 和素材的授权，不能因为「有 GitHub 仓库」就默认可以商业复制。

    微雪已购板卡逐项核查

    下表价格来自采购记录，是已购均价——用于样机比较，不是批量报价。

    板卡 数量 / 单价 关键参数 结论
    S3-Touch-AMOLED-1.75 2 / ¥174.50 SKU 31261；8MB PSRAM / 16MB Flash；466×466 AMOLED；双麦、IMU、RTC、TF；8Pin 排针只有 VBUS/GND/3V3、UART0 和 GPIO16/17/18 汽车标准版基线。外接 OBD / TPMS / GPS 前先画引脚占用表
    S3-Touch-AMOLED-1.75-B 12 / ¥194.35 SKU 31262；与上项基础电子设计相同，主要差别是保护外壳 外壳与 RF、散热、装车固定对照；不单独维护固件
    S3-Touch-AMOLED-1.75C / C-EN 4 / ¥235.14；11 / ¥220.52 SKU 33691 / 33692；8MB PSRAM / 32MB Flash、双麦、ES7210/ES8311、铝合金结构 旗舰 / 语音资源压测。不能按「Flash 不够」淘汰
    S3-Touch-LCD-1.85B-EN 1 / ¥188.31 SKU 34556；8MB PSRAM / 16MB Flash、360×360 LCD、双麦、IMU 摩托 / 自行车阳光可读性与音频实验
    S3-Touch-LCD-1.85C-BOX 1 / ¥196.61 SKU 30684；360×360 LCD；V1/V2 音频芯片与 GPIO2/10/11/15 等引脚不同 完整盒装交互样机；必须先读 PCB 丝印再建 BSP
    S3-Touch-AMOLED-1.43-B 3 / ¥177.53 16MB Flash / 8MB PSRAM、466×466 AMOLED；标称亮度 350 cd/m² 小尺寸对照。样机价仅比 1.75 裸板高 ¥3.03
    S3-Touch-LCD-2 1 / ¥91.00 8MB PSRAM / 16MB Flash、240×320 LCD、QMI8658 低价方屏概念验证。原 BOM 把它错写为 1.75 AMOLED，成本估算无效
    RP2350-Touch-AMOLED-1.75-B 1 / ¥181.38 具体板卡未获官方确认；只有采购 / 整理表 不进入当前固件主线；先确认卖家、PCB 与屏驱动
    T5-E1-Touch-AMOLED-1.75 1 / ¥191.28 具体板卡未获官方确认；SDK / 云依赖未核实 暂停降本假设；先证明驱动、BLE 协议与离线可用性
    P4-WIFI6-Touch-LCD-4.3 2 / ¥184.27 ESP32-P4 + C6；32MB PSRAM / 32MB Flash、4.3 寸 480×800 ST7701 MIPI-DSI、GT911 导航 / 视频实验线。板价低不代表整机便宜

    一个容易踩的坑：GPIO 早就被占满了

    普通 1.75 的 8Pin 排针上，可直接使用的通用 GPIO 主要是 16 / 17 / 18；43 / 44 是 UART0，通常承担调试；-G GPS 版本还可能占用 17 / 18。I2C 的 14 / 15 是板载多器件共用总线。

    如果 OBD 采用 MCU 的 TWAI 控制器，还需要外部 CAN 收发器，而且 GPIO 分配必须与 GPS、TPMS 接收器、串口日志同时规划。这里有一条必须记住的边界：芯片的 TWAI 外设不是 OBD 线束，也不是车电接口。有 CAN 控制器，离「能读这辆车的 OBD」还有很远。

    成本校验：¥399 的账算不平

    采购记录共 21 个已购变体、49 块，购买行金额 ¥9,434.92。但原始 BOM 至少有两处复制错误：2 寸 LCD 被记成 1.75 AMOLED，P4 3.5 被记成 4.3 屏。所以不能用它的 BOM 估算毛利。

    只用样机价做个敏感性示例：汽车标准版定价 ¥399，若希望物料及制造的直接毛利率达到 50%，完整交付成本上限是 ¥199.50。而仅 1.75 裸板样机价就占 ¥174.50，留给 OBD 接口、保护、外壳、线束、测试、包装的空间只剩 ¥25.00。这还没算税费、渠道、服务和研发摊销。

    结论很明确：必须拿到批量报价和自研降本数据，才能判断 ¥399 是否可盈利；用样机价宣布「可盈利」是不成立的。

    按产品的最终推荐

    产品 主选 备选 / 实验 进入下一阶段需要的证据
    汽车标准 / 胎压 微雪 S3 1.75 无壳 1.75-B 外壳对照 车型读取成功率、完整交付成本、RF / 散热 / 阳光可读性、供电保护
    汽车旗舰 1.75 与 1.75C 同时压测 CoreS3 做语音 / CAN 对照 分区 / PSRAM 数据、语音端到端延迟、素材与服务成本
    摩托车 S3 1.75 1.85B-EN、LILYGO T-RGB 大屏 目标车型 K-Line / CAN / 线束、倾角标定、防水振动
    自行车 S3 1.75 1.85B-EN、Seeed 模块组合 速度来源、心率标准 / 自有 BLE 并发、阳光雨天可读性、续航
    导航 / 后视镜探索 P4 4.3 独立线 CoreS3 仅做 UI / 协议实验 先定义结构化导航还是视频；视频不作为 1.75 的安全关键显示功能

    首批验证尽量使用现有库存。新增板卡采购应等到实测确认某一能力或形态缺口之后，再下单。

    常见问题

    1.75C 的 32MB Flash 值得为它升级吗？

    不建议把「Flash 更大」当作淘汰普通 1.75 的理由，但也不该反过来假设 1.75C 天然适合旗舰。1.75C 更可能受限于外壳、引出接口、分区方案或现有固件实现。正确做法是用 v1.1.4 的分区表、实际固件与素材大小、最小空闲堆来验证，而不是只看标称 Flash 数字。

    M5Stack CoreS3 能直接当汽车圆表吗？

    不能。CoreS3 是 2.0 寸 320×240 方屏，显示形态和外壳都无法直接复用汽车圆表。它的价值在于快速验证 CAN + 音频 + UI 的组合——配合 Unit CAN（CA-IS3050G 隔离收发器，标称最高 1Mbps、1000V 隔离），并核对 OBD 接头、电源、终端电阻与车型协议。

    「能收 CAN 帧」等于「支持汽车 OBD」吗？

    不等于。Unit CAN 只解决物理收发的一部分。还需要确认 OBD 接头、供电、终端电阻、车型协议、总线接入方式与兼容性。把「能收 CAN 帧」当成「支持汽车 OBD」，是选型阶段最常见的误判。

    为什么不直接从开发板的公开资料做量产？

    因为下载到原理图和 BSP，不等于拿到可投产的完整设计包。多数厂商只提供原理图 PDF，没有可编辑 PCB、生产 BOM 和结构件源文件。自研替代应以「自己重新设计车电输入、OBD/CAN、显示连接器、RF、壳体和测试工装」为目标，把公开资料当作参考，而不是成品。

    本文数据来自星核火花赛车科技内部《小仪表开发板详细调研与路线建议》（2026-10 版）。文中价格为采购记录中的已购均价，适用于样机比较，不构成批量报价或盈利承诺。

  • OBD 零百加速计时：为什么手机测不准，仪表该怎么算

    结论：用 OBD 做 0–100 km/h 加速计时，唯一可信的输入是标准 OBD-II 车速 PID 0x0D。它按整数 km/h 上报，所以「0.5 km/h 起步阈值」根本无法实现；GPS 不参与计时、插值或丢包补偿，IMU 只负责记录 G 值。在实车标定完成之前，「±0.05 秒」「优于手机」都只是待验证目标，不是规格。

    为什么「看起来能测」和「真的能测」是两回事

    手机上随手装一个加速计时 App，看起来也能出成绩。但把同一套逻辑搬到车载仪表上，问题会立刻暴露：加速度计的噪声、GPS 的更新频率和延迟、以及车辆实际起步的抖动，都会让「0 秒」这个时刻的定义变得含糊。

    更关键的是，计时器报告的是它接收到的数据时刻，而不是车辆真实的物理时刻。如果这一点不说清楚，讨论「精度」就没有意义。

    计时输入的唯一性：只用 OBD 车速

    在 OBD 车速与 IMU、GPS 并存的设计里，必须明确一条边界：计时链路上只允许有一个数据源。

    • 唯一计时输入：OBD 车速。首选通过受保护的车载网关读取标准 OBD-II PID 0x0D；若车型使用专用车速信号，必须在车型配置中写清协议、单位和量化精度。
    • GPS 不参与计时、插值或丢包补偿。GPS 的更新率和定位漂移都不足以支撑零点几秒级的判定。
    • IMU（如 QMI8658）可以记录峰值 G 和 G 曲线，但不参与起点、60 km/h、终点的时间戳判定。

    把三条拆开看，逻辑就清楚了：IMU 回答「加速有多猛」，GPS 回答「路走了多远」，而只有 OBD 车速能回答「什么时候到 100」。混用会得到漂亮的数字，但那个数字不可复盘。

    状态机：五个状态按什么顺序判定

    状态 进入条件 动作
    IDLE 收到连续有效的 0 km/h 样本，覆盖至少 1 秒 进入 ARMED
    ARMED 首次收到有效且大于 0 km/h 的车速 记该样本接收时刻为 t0，进入 RUNNING
    RUNNING 首次收到车速 ≥ 60 km/h 记 t60，继续计时
    RUNNING 首次收到车速 ≥ 100 km/h 记 t100，锁存 t100 − t0 与 t60 − t0，进入 COMPLETE
    任意计时状态 网关断连、PID 不支持、响应超时、样本乱序或不可信 标记本次无效，保存原因，不显示成功成绩

    这套状态机刻意做得很「笨」：不猜、不补、不回头修。原因很直接——加速成绩的价值在于可信，而不在于好看。

    哪些情况必须判为无效

    「无效」不是异常处理，而是产品功能的一部分。至少要覆盖这六类场景：

    1. 缓慢起步——车辆长时间停留在 1 km/h 附近，起步时刻难以确定。
    2. 瞬时跳值——单帧车速突然从 0 跳到 60，超出物理可能性。
    3. 重复帧——同一时刻收到多条相同样本。
    4. 乱序——时间戳不单调递增。
    5. 超时——请求发出后长时间没有响应。
    6. 中途失联——网关在 RUNNING 期间断开。

    这些场景必须在离线注入测试中全部覆盖：把速度曲线喂给同一套解析与状态机，逐条核对状态切换与时间戳是否正确。

    为什么 0.5 km/h 的起步阈值做不到

    标准 PID 0x0D 返回的是整数 km/h，没有小数位。所以「车速大于 0.5 km/h 即视为起步」这种阈值在协议层面就无法表达——你只能看到 0 和 1。

    因此首版采用「首次收到大于 0 的有效样本」作为起步点，并且明确：

    • 不插值。是否用 0→1 与 99→100 两点插值，必须在记录了轮询周期、往返延迟和车型信号特性之后再决定。
    • 不借用 IMU 或 GPS 填补样本。填补会产生看似连续、实则虚构的曲线。
    • 连续 0 km/h 的判定需要多个有效样本。网关断连期间「保持」的旧值，不能算进那 1 秒。

    要留什么数据，才叫可复盘

    每条车速样本至少保存六项：原始响应、解码值、请求发出时间、响应接收时间、网关状态、单调时钟时间戳。

    这里有个容易被忽略的区分：界面刷新频率不等于车速采样频率。屏幕每秒刷 20 帧，不代表每秒拿到 20 个车速样本。把两者混为一谈，会让「数据很密」变成一种错觉。

    另外，上述所有时间戳都是 OBD 响应接收时刻，不是 ECU 的实际采样时刻。这是整条链路的固有偏差，只能披露，不能消除。

    关于精度的诚实表述

    「±0.05 秒」和「优于手机」是待验证目标。在完成以下三步之前，它们不应出现在任何宣传文案里：

    1. 向同一套解析与状态机注入速度曲线，覆盖缓慢起步、瞬时跳值、重复帧、乱序、超时与中途失联。
    2. 在目标车型上记录 PID 支持情况、有效车速更新率、请求往返延迟分布、网关额外延迟，以及计时期间的丢包率。
    3. 用独立参考设备同步采集多次 0–100，统计偏差与离散程度。

    界面需要提供五种状态：待连接、待起步、计时中、成绩、无效记录。历史最佳只收录「有效且带车型 / 数据源元信息」的成绩——没有元信息的成绩无法复盘，也就不该进榜。

    常见问题

    用 GPS 测 0–100 会差多少？

    本文不给具体数字，因为差异取决于 GPS 模块的更新率、定位精度和遮挡情况，需要实测。但可以确定的是：GPS 的采样与延迟特性使它不适合作为零点几秒级判定的唯一依据，因此本方案把它排除在计时链路之外。

    IMU 能提高计时精度吗？

    不能用于提高计时精度。IMU 可以记录峰值 G 和 G 曲线，用于分析驾驶表现，但起点、60 km/h、终点三个时间戳只能来自 OBD 车速样本。

    为什么不做插值让曲线更平滑？

    因为插值会产生「看起来连续、实际不存在」的样本。首版选择保留原始离散点，等实车标定拿到轮询周期与延迟分布后，再评估插值是否值得引入。

    成绩为无效时，界面应该显示什么？

    显示无效原因，而不是一个成功成绩。无效判定的价值就在于：它让用户知道自己看到的数字是否可信。

    小结

    一个可信的 OBD 加速计时器，本质上是一套数据边界 + 状态机 + 无效判定的组合，而不是一个公式。先用整数 km/h 的现实约束定义清楚能做什么、不能做什么，再谈精度——这个顺序反了，后面全是返工。

    本文结论来自星核火花赛车科技内部车载仪表研究项目（2026-10 版）的《OBD 零百计时规格》与《五块赛道产品候选板硬件事实表》。文中精度指标均为待验证目标，实际数值以实车标定为准。