首页智能硬件与嵌入式系统

NaviLink：把 BMW WonderWheel 变成智能骑行入口

• 数据时间：2026-06-28 Asia/Shanghai
• 研究对象：NaviLink CAN-first 骑行交互平台、BMW Motorrad 首车验证、ESP32 PoC、CH32V208 产品化路线
• 报告类型：智能硬件与嵌入式系统专题
• 产品阶段：ESP32 PoC 已形成可验证主链路；CH32V208 处于 bring-up 与 EVT 风险收敛阶段
• 工程基线：NaviLink 最近提交 54cc517，并参考当前 CH32 HID Keyboard 对齐、NCM/DoIP PoC 和未提交 bring-up 工作树状态
• 资料来源：NaviLink 工程文档、固件提交记录、产品推介稿、骑手介绍稿、WunderLINQ X 官方商品页、WunderLINQ 2.0 kit 欧洲商品页、HEX ezCAN 官方站、BMW ConnectedRide Navigator 操作说明 PDF、WCH CH32V208 官方资料、openwch/ch32v20x

产品先说清楚

NaviLink 是一块装在摩托车上的 CAN-first 智能硬件。它读取车把控制件和车辆数据，把不同车型的 CAN 协议翻译成统一输入事件与车辆状态，再输出给手机、平板、客户端软件和外设。

第一条产品链路足够窄，也足够有杀伤力：

BMW WonderWheel -> NaviLink -> BLE HID / USB HID -> 手机导航、音乐、相机和常用动作

BMW 骑手口中的 WonderWheel，官方资料里通常称为 Multi-Controller。它已经是骑行中最合适的输入件之一：手不用离开车把，戴手套能盲操，有滚动、倾斜、确认、返回和菜单焦点切换。问题在于，最常用的软件入口已经转到手机上，最顺手的控制件仍主要服务仪表、原厂导航和 BMW 自家生态。

痛点很具体：骑行中需要看路、控车、听导航、切歌、缩放地图、记录路线；风噪、震动、雨天和手套会让手机触控变得笨重。NaviLink 想补上的，就是车把控制件和手机软件之间那条开放、稳定、可配置的链路。

首版体验可以很直接：

• WonderWheel 上下滚动控制地图缩放、列表选择或媒体切换。
• 左右拨动映射到返回、确认、上一项、下一项。
• 长按或组合动作触发常用导航、音乐、相机或自定义快捷键。
• 车辆速度、档位、温度、刹车、点火等数据进入客户端和调试工具。
• 后续通过车型包、配置工具和客户端，把不同品牌的输入与数据接到同一个产品合同上。

NaviLink 的入口是 BMW WonderWheel，目标产品形态是一套摩托车智能控制和数据平台。

愿景

摩托车上的控制件、总线数据和骑行软件应该连成一个整体。NaviLink 的愿景，是让摩托车成为骑手的智能控制中枢。

短期目标是安全输入：把车把上的物理控制动作稳定送到手机、平板和外设，减少骑行中戳屏。中期目标是车辆数据：把速度、档位、温度、刹车、点火、电源、故障和行程状态沉淀成统一数据面。长期目标是平台化：每个品牌是一组协议模块，每个车型是一套配置包，客户端软件、调试工具、外设和后续数据服务围绕同一套事件和状态模型演进。

这条路线需要同时尊重三件事：

• 摩托车热爱：产品必须从真实骑行场景出发，解决手套、风噪、震动、雨天、注意力和安装可靠性这些细节。
• 嵌入式底层：CAN、BLE HID、USB、车规电源、调试入口、故障恢复和产测流程要可控。
• 智能硬件体验：交付给用户的应是易用、稳定、可配置的客户端和硬件组合，开发板日志只服务工程验证。

BMW Motorrad 是第一步，原因很朴素：我曾经拥有一台 F 900 R 2022。它可以反复接线、抓包、观察车把输入、验证真实骑行体验，把骑手直觉转成工程证据。

后来项目停了几个月，到现在还没有正式重启实车验证。新的变量是我买了一台 R 1300 GS 2025，替换了原来的 F 900 R 2022。这会改变下一轮验证的车辆基线。下一次重启时，要从 R 1300 GS 2025 重新抓取 WonderWheel、TFT、车辆数据和导航焦点行为；F 900 R 的帧和行为只能作为历史线索。

这仍然是好的第一步。BMW Motorrad 给了一个足够成熟、足够有代表性的输入系统，也给了一个明确竞品战场：原厂 ConnectedRide、WunderLINQ、ezCAN 这类产品都在证明，骑手愿意为车载控制和智能硬件付费。

ESP32 PoC 已经做了什么

ESP32 PoC 的角色是快速证明用户价值。当前 PoC 硬件使用 ESP32-D0 + SN65HVD230 + USB，把真实 CAN、BMW 解码、事件抽象、BLE HID、BLE 数据面和 UART CLI 接起来。

主链路已经拆清楚：

CAN/TWAI -> BMW decoder -> adapter_input -> binding_map -> BLE HID

这条链路让 PoC 板能够从真实 CAN 或 UART 注入帧中识别 BMW 输入事件，再把它们变成手机能理解的键盘或 consumer control 报告。手机侧看到的是标准 BLE HID 设备，产品侧保留的是车型协议和输入语义。

车辆数据链路也已经进入 PoC：

CAN frame -> BMW data decoder -> vehicle_data -> vehicle_data_state -> JSON / BLE publish / UART status

当前高置信度 BMW 数据集中在 0x290、0x293、0x2BC 等帧，覆盖速度、档位、温度、刹车、点火等字段。vehicle_data_state 负责维护最新快照和字段老化，vehicle_data_json_v1 负责把车辆状态压成紧凑 JSON，方便后续客户端读取。

BLE 侧已经做过三类验证：

• BLE HID：键盘报告、consumer control 报告、自动 release、映射配置。
• BLE Data：配置写入/读取、车辆数据读取、车辆数据周期 publish。
• 配对恢复：ESP32 Boot/GPIO0 长按触发断链、清 bond、重新广播。

UART CLI 已经从简单调试口长成 PoC 的产品测试合同。它可以做 CAN status/dump/filter、诊断请求、BMW 2A0 / 290 / 293 / 2BC 注入、vehicle status、hid key/combo/consumer、ble adv/data 等操作。配套 device-cli-tests 让 CLI 行为有自动化回归入口。

最近提交 54cc517 feat(esp32): add CAN diagnostic MVP 进一步补上了 CAN diagnostic MVP：新增 esp32_can_diag、诊断 CLI、设备测试和 CAN pipeline trace handler。它让 ESP32 PoC 更适合实车抓包、诊断请求、响应等待和超时观察。

ESP32 的定位是 PoC 和验证工具。它的价值是快：快接线、快抓包、快改映射、快试手机侧体验。只要 PoC 能持续回答“骑行中这条链路好不好用”，它就应该留在工具链里。

能力怎么设计

NaviLink 的固件设计已经从“能跑起来”转到“可迁移、可测试、可产品化”。ESP32 代码把能力分成三层。

层次	当前模块	作用
Reusable Logic	adapter_input、vehicle_data、vehicle_data_state、vehicle_data_json_v1、navilink_binding_map、navilink_can_router、bmw_motorrad_tft、bmw_motorrad_data	保留输入语义、车辆数据、车型解码、映射和路由，迁移到 CH32 时优先复用
ESP32 Platform	esp32_can_twai、esp32_can_pipeline、esp32_ble_hid、esp32_ble_data、esp32_vehicle_ble_bridge、esp32_can_diag、esp32_uart_debug	负责 ESP-IDF、TWAI、Bluedroid、UART、任务和调试能力
main	启动编排	负责初始化和回调接线，BMW 协议与 HID 映射逻辑留在独立模块

产品能力也能按同样方式看：

• 输入层：接收 BMW WonderWheel 和后续品牌控制件。
• 事件层：把原始帧转成 up / down / left / right / confirm / back / home / next_track / previous_track 等语义。
• 数据层：把车辆速度、档位、温度、刹车、点火等字段变成车型无关状态。
• 输出层：BLE HID、USB HID、BLE Data、后续客户端 API。
• 调试层：UART CLI、设备测试、CAN dump、诊断请求、状态快照。
• 产品层：车型包、配置工具、手机/平板客户端、外设联动。

这套设计的重点，是让 BMW PoC 产生的工作能继续留到 CH32 产品化阶段。车型协议、输入事件和车辆数据应该稳定；底层 BLE、USB、CAN、调度和调试实现可以随平台重写。

为什么推进 CH32V208

NaviLink 转向 CH32V208，来自产品账本：BOM、功耗、板面积、外围器件数、产测、售后恢复和供应链都要压住。

摩托车后装硬件的成本空间很硬。用户愿意为骑行中真的好用的体验付费，也会为线束、防水、外壳、安装件和稳定性买单。主控和外围器件成本过高时，产品容易被迫进入小众高价路线；主控集成度和 BOM 结构压下来，才有余量把预算留给车载可靠性和用户能摸到的体验。

openwch/ch32v20x 对 CH32V208 的公开说明很适合 NaviLink 当前问题：32-bit wireless RISC-V MCU，Qingke V4C 内核，最高 144MHz，64KB SRAM，128KB Flash，集成 BLE 5.3、10M Ethernet MAC+PHY、USB 2.0 full-speed host/device + device、CAN 2.0B active、4 USART、2 I2C、2 SPI 和低功耗模式。WCH 官方页面也把 CH32V208 放在 USB/Bluetooth/Ethernet/RISC-V connected MCU 产品线中。

这些资源正好覆盖 NaviLink EVT 想验证的组合：

产品问题	CH32V208 的价值
首版能否低成本交付 CAN + BLE HID	BLE、CAN、USB 集成在同一 MCU 体系，外围器件和板级复杂度更容易压住
手机控制能否保留开放出口	BLE HID / USB HID 都有硬件路径，首版可以先收敛到通用 HID
配置、产测、恢复能否有清晰入口	USB FS、UART、外部 SPI Flash 规划和模式切换给调试/产测留下空间
DoIP / ENET 是否值得探索	10M Ethernet MAC+PHY 让 USB NCM <-> Ethernet PoC 有真实硬件路径
骑行设备能否做低功耗路线	RISC-V wireless MCU + sleep/stop/standby 模式适合后续做车载待机策略
BOM 是否能支撑规模化	WCH 器件路线和高集成度有利于极致 BOM 成本目标

RISC-V 架构本身只是一部分。真正有价值的是组合：低成本 MCU、BLE/CAN/USB/Ethernet 集成、WCH BLE/TMOS 软件栈、官方 EVT 示例、MounRiver managed project 工程路径，以及后续围绕单主控做 DVT/PVT/MP 的可能性。

这条路线也有工程代价。CH32V208 的 BLE、TMOS、USB、linker layout、ROM/direct-link 库、MRS 工程元数据和官方示例对齐，比 ESP32 生态更需要耐心。当前 CH32 工作的意义，是提前把这些风险烧掉。

CH32V208 做到哪里

已提交历史显示，CH32 路线已经走过一轮真实 bring-up：

• 91eaee1 增加 self-contained bring-up scaffold。
• eaf0a95 把目录布局对齐 WCH EXAM。
• 6d885cb 和 22831f5 推进 BLE stack 与官方 profiles 对齐。
• fd861d6 把 CAN bring-up 往 WCH sample 对齐。
• 6974e27 增加 USB HID + MIDI 双模式传输探索。
• 0240f72 把 BLE、CAN、USB flow 往 EVT best practices 收敛。
• 52d84d5 增加可配置 LED 和 repair button service。
• 3676969 清理 CH32 宏和 helper 命名。
• 994c914 新增独立 USB FS CDC-NCM <-> 10M Ethernet bridge PoC。

当前未提交工作树又做了一次重要回收：BLE HID bring-up 被拉回 WCH 官方 HID_Keyboard 路径。项目 vendored 了官方 hiddev.c、hidkbdservice.c、hidkbd.c 和对应头文件；ble.c 暂时缩成 WCHBLE_Init -> HAL_Init -> GAPRole_PeripheralInit -> HidDev_Init -> HidEmu_Init 的薄封装；main.c 也临时对齐官方 HID Keyboard leaf startup，调试输出回到 SDI printf，HardFault 进入 LED blink 诊断。

这说明 CH32 还处在稳 baseline 的阶段。BLE consumer control、BLE data service、NaviLink composite HID、USB composite、CAN driver 细节和完整 app orchestration 都需要逐步合回。现阶段先拿到一个能稳定启动、能观察早期故障、能继续回归的官方对齐基线，再谈功能堆叠。

NCM / DoIP 也是同样思路。994c914 新增的 NCM PoC 是独立工程，目标是验证 USB NCM <-> 10M Ethernet 桥接、Windows 11 / ISTA+、BMW ENET / DoIP 服务路径。它属于 EVT 模式验证，不应该拖慢首版骑行交互主链路。若资源、稳定性或 BOM 压力过大，Ethernet / DoIP 可以停留在 EVT。

竞品分析

先承认竞品强，定位才不会飘。

产品	已经证明的需求	产品重心	NaviLink 的机会
BMW ConnectedRide Navigator / Cradle	BMW 官方资料明确支持通过 Multi-Controller 操作 Navigator 或 Connected app；Navigator 接入 navigation preparation 后，骑手可以在不松开车把的情况下操作导航功能	原厂导航、BMW ID、BMW Connected app、BMW navigation preparation	原厂体验是标杆，但设备和生态相对封闭。NaviLink 要把相同输入价值开放给手机、第三方 app、外设和后续多品牌数据层
WunderLINQ 2.0 / Navigator / X	官方商品页显示 WunderLINQ 通过 BMW Navigation Prep / plug 与 Android 或 iOS app 组合，把 Multi-function wheel 变成 Bluetooth keyboard，并支持车辆数据、故障、音乐、导航和日志	BMW WonderWheel 到手机/app 的成熟商品化路线	这是最直接的产品参照。NaviLink 需要在 CAN 协议层、通用 HID、低 BOM、车型包、客户端分层和后续多品牌扩展上找到差异
WunderLINQ 1.0 / 早期 Navigator 路线	早期商品线已经证明这个需求存在多年：BMW 用户愿意用手机替代 Navigator 5/6，并保留车把控制	BMW 导航支架、手机替代导航、app 配套	早期路线证明市场教育已发生。NaviLink 的第一版应减少概念铺陈，用可测试的 WonderWheel 控制手机体验切进去
HEX ezCAN	官方站把 ezCAN 定义为 Accessory Manager：接入 CAN-bus，不剪原车线束，使用原厂控制件操作辅助灯、喇叭、加热装备、GPS/手机/相机等附件	车载电子附件供电与控制	它证明骑手愿意为 CAN 集成和无损安装付费。NaviLink 首版入口是 HMI、手机控制和车辆数据，后续外设控制可以学习 ezCAN 的安装和配置纪律

WunderLINQ 给 NaviLink 的压力最大。它已经把 BMW WonderWheel 到手机/app 的桥接做成可购买产品，且公开功能覆盖数据、故障、音乐、导航、日志和固件升级。NaviLink 的文章和产品设计都不能假装这个市场空白。

NaviLink 的差异要落在几个可执行点上：

• 先把 CAN -> 事件抽象 -> HID 做成极稳、极低延迟、极好配置的基础体验。
• 首版把通用 BLE HID / USB HID 作为开放出口，降低对单一 app 的依赖。
• 车型协议、输入事件、车辆数据和输出 transport 分层，给多品牌路线留真实空间。
• CH32V208 路线承担极致 BOM 成本和低功耗压力，避免产品长期停在开发板成本结构里。
• 客户端软件承担配置、可视化和数据体验，不把底层调试工具包装成用户体验。

ezCAN 给 NaviLink 的提醒也很直接：摩托车用户关心可靠安装、线束完整、配置简单、出问题可恢复。智能硬件的性感不在参数表里，在骑手上车后愿意天天用。

当前阶段和下一道 gate

NaviLink 当前还在工程验证阶段，距离对外承诺产品还有几道 gate。

层次	当前状态	下一步
用户价值	BMW WonderWheel 到手机 HID 控制是最短价值链路	用 R 1300 GS 2025 重启实车抓包和骑行体验验证
ESP32 PoC	CAN diagnostic、BLE HID、BLE Data、UART CLI、设备测试已经支撑快速实验	保持为抓包、映射、诊断和测试合同平台
CH32 产品化	BLE/HID/CAN/USB/NCM 都进入真实 bring-up，当前回到官方 HID Keyboard baseline 稳启动	先稳定官方 HID Keyboard，再逐步合回 consumer control、BLE Data、CAN、USB 和 app orchestration
竞品定位	WunderLINQ 是直接参照，ezCAN 是附件控制参照，BMW 原厂体验是 UX 标杆	首版聚焦 WonderWheel 开放输入和低 BOM 硬件，后续再扩展数据和外设

下一阶段最该盯住这些问题：

• R 1300 GS 2025 的 WonderWheel、TFT、Navigation Prep 和车辆数据帧是否与 F 900 R 假设一致。
• BLE HID 在 iOS、Android、平板和常用导航 app 上的延迟、连贯性和可配置性。
• CH32 官方 HID Keyboard baseline 是否稳定启动、可诊断、可回归。
• consumer control、BLE Data、NaviLink 自定义 service 是否能有节奏地合回 CH32。
• USB NCM <-> Ethernet 是否证明 DoIP/ENET 值得进入 DVT。
• 首版量产范围是否能守住 CAN + HID + 基础车辆数据 + 配置入口 + 稳定产测/恢复。

如果这些 gate 逐步打穿，NaviLink 就会从 BMW WonderWheel 控制手机的 PoC，走向一套面向摩托车的智能控制和数据平台。它从热爱摩托车出发，底层是嵌入式系统，最终交给骑手的应该是一种很自然的感觉：手还在车把上，手机和外设已经听懂了车。