在完成骑行台项目时，由于不同于简单ANT设备，如心率带等，只需要进行ANT信号的发送，骑行台在使用过程中，需要通过蓝牙链接手机等设备进行路线规划，阻力设置等操作，不同于使用骑行码表对骑行台进行操作，骑行软件需要通过蓝牙连接，通过蓝牙传输和接受数据，这时还需要通过蓝牙和ANT同时发送，来实现对骑行台的共同控制。
一、蓝牙（BLE）关键技术点
1.1 核心服务架构
实现的服务
1.CPS (Cycling Power Service - 0x1818)
- 功能：发送功率、踏频数据
- 特性：支持曲柄转数、累计功率
- 控制点：支持累计值设置、校准指令
2. FMS (Fitness Machine Service - 0x1826)
- 功能：最小实现，仅服务声明
- 目的：让骑行软件（Zwift、行者）识别设备
3.DIS (Device Information Service - 0x180A)
- 功能：设备信息（固件版本、序列号等）
4.NUS (Nordic UART Service)
- 功能：调试用串口服务
接下来介绍一下上述说的四种协议或传输格式
Cycling Power Service (CPS) - 0x1818
1. 核心定义
CPS 是蓝牙 SIG 标准化的骑行功率设备核心服务（归属《Cycling Power Profile (CPP) v1.0+》规范），专为骑行功率计、智能骑行台设计，是 “运动数据上报 + 设备控制” 的核心通道，也是骑行台蓝牙通信的 “核心业务层”。
2. 核心特征（UUID + 属性 + 功能）
CPS 的功能通过 “特征（Characteristic）” 实现，每个特征有固定 UUID 和访问属性，骑行台需实现以下核心特征（按优先级）：
| 特征 UUID（16 位） | 特征名称 | 访问属性 | 核心功能（骑行台场景） |
|---|---|---|---|
| 0x2A63 | Cycling Power Measurement | READ + NOTIFY | 核心：上报实时运动数据（必实现）- 瞬时功率（W）、踏频（RPM）、曲柄转数（累计）、累计功率（kJ）；- 数据格式：小端序，首字节为 “标志位”（标识包含哪些数据，如 0x03 = 功率 + 踏频）；- 上报频率：蓝牙 SIG 推荐 4Hz（250ms / 次），适配 Zwift/TrainerRoad 默认解析频率。 |
| 0x2A64 | Cycling Power Control Point | WRITE + WRITE_WITHOUT_RESPONSE | 核心：接收 APP 控制指令（必实现）- 校准指令：零偏校准（0x01）、自旋校准（0x02）；- 累计值设置：重置曲柄转数 / 累计功率（0x03）；- 响应要求：指令接收后 500ms 内通过该特征返回执行结果（成功 / 失败）。 |
| 0x2A65 | Cycling Power Vector | NOTIFY（可选） | 进阶：上报踏板平衡、功率相位等精细数据（骑行台一般无需实现，功率计专用）。 |
| 0x2901 | Characteristic User Description | READ | 特征描述：如 “Cycling Power Measurement”（UTF-8 字符串，APP 用于显示特征名称）。 |
3. 典型交互流程（骑行台←→APP）
4. 骑行台场景核心作用
- 数据上报：所有运动核心数据（功率、踏频、累计骑行功率）唯一合法通道，APP 仅认可 CPS 0x2A63 的标准化数据；
- 指令接收：校准、累计值重置等关键操作必须通过 CPS 0x2A64 接收，是 APP 控制骑行台的核心入口；
- 兼容性基础：即使未实现 FMS，部分老 APP（如早期行者）也可通过 CPS 识别骑行台。
5. 开发 / 适配关键注意事项
- 数据格式严格对齐规范：
- 功率数据分辨率 1W，小端序（如 200W=0x00C8→字节序 0xC8 0x00）；
- 标志位必须准确（如仅上报功率则标志位 = 0x01，漏设会导致 APP 忽略数据）；
- 指令响应超时≤500ms：APP 下发校准指令后，若骑行台未及时响应，会判定 “设备无响应”；
- 累计值持久化：曲柄转数、累计功率需存储到 NV RAM，断电后不丢失，APP 会读取累计值计算骑行里程 / 能耗；
- 避免数据溢出：功率值最大支持 0xFFFF（65535W），踏频最大 0xFF（255RPM），超出需截断（骑行台实际功率不会超此范围）。
Fitness Machine Service (FMS) - 0x1826
1. 核心定义
FMS 是蓝牙 SIG 标准化的健身设备通用服务（归属《Fitness Machine Profile (FMP) v1.0+》规范），覆盖智能骑行台、动感单车、跑步机等健身设备，核心价值是 “设备类型识别 + 健身设备专属控制”，是解决 “APP 搜不到骑行台” 的关键服务。
2. 核心特征（UUID + 属性 + 功能）
骑行台场景下分 “最小实现” 和 “完整实现”，最小实现仅需声明服务即可兼容 APP 识别，完整实现支持阻力 / 坡度控制：
| 实现等级 | 特征 UUID（16 位） | 特征名称 | 访问属性 | 核心功能（骑行台场景） |
|---|---|---|---|---|
| 最小实现 | - | 仅服务声明（0x1826） | - | 无特征，仅在 GATT 表中注册 0x1826 服务，广播包包含该 UUID，让 APP 识别为 “健身设备”。 |
| 完整实现 | 0x2A85 | Fitness Machine Status | NOTIFY | 上报设备状态：正常（0x00）、校准中（0x01）、故障（0x02）、低电量（0x03）。 |
| 完整实现 | 0x2A88 | Fitness Machine Control Point | WRITE + WRITE_WITHOUT_RESPONSE | 接收健身设备专属指令：- 阻力百分比设置（0x01）、目标功率设置（0x02）；- 模拟模式（坡度 / 风阻）设置（0x05）；- 紧急停止（0x07）。 |
3. 典型交互流程（最小实现）
4. 骑行台场景核心作用
- 设备识别兜底：解决 “手机蓝牙列表可见、APP 搜不到” 的核心问题 ——Zwift / 新版行者等 APP 会优先筛选含 0x1826 的设备，仅 CPS（0x1818）会被过滤；
- 进阶控制扩展：完整实现后，可接收 APP 下发的阻力 / 坡度指令（比 CPS 0x2A64 的指令更通用，适配更多 APP）；
- 状态标准化：通过 0x2A85 上报设备状态，APP 可统一显示 “校准中”“故障” 等状态（无需自定义 CPS 特征）。
5. 开发 / 适配关键注意事项
- 最小实现成本极低：
- 仅需在 GATT 表中注册 0x1826 服务（无需实现任何特征），并将 0x1826 加入广播 UUID 列表；
- 无需处理任何指令，仅作为 “识别标识”，是解决 APP 兼容的最优解；
- 完整实现需对齐操作码：
- 阻力百分比分辨率 0.5%（如 50%=100→0x0064，小端序 0x64 0x00）；
- 坡度值需加偏移 1000（如 5%=1050→0x040A，小端序 0x0A 0x04）；
- 广播包必须包含 0x1826：仅 GATT 表注册但广播不包含，APP 扫描阶段仍无法识别。
Device Information Service (DIS) - 0x180A
1. 核心定义
DIS 是蓝牙 SIG 通用设备信息服务（归属《Device Information Profile (DIP)》），是所有蓝牙设备的 “标准化信息面板”，用于存储 / 提供设备厂商、固件版本、序列号等静态信息，无 “控制 / 上报” 功能，仅用于 APP / 系统读取设备基础信息。
2. 核心特征（UUID + 属性 + 功能）
骑行台需实现以下核心特征（均为 READ 属性，无需 NOTIFY/WRITE）：
| 特征 UUID（16 位） | 特征名称 | 数据格式 | 核心功能（骑行台场景） |
|---|---|---|---|
| 0x2A25 | Serial Number String | UTF-8 字符串 | 设备唯一序列号（如 “54321”），APP 用于设备绑定、故障排查。 |
| 0x2A26 | Firmware Revision String | UTF-8 字符串 | 固件版本（如 “V2.1.0”），APP 用于检测版本兼容性、提示固件更新。 |
| 0x2A27 | Hardware Revision String | UTF-8 字符串 | 硬件版本（如 “V2.0”），区分不同硬件批次。 |
| 0x2A29 | Manufacturer Name String | UTF-8 字符串 | 厂商名称（如 “XCADEY”），APP 用于显示品牌。 |
| 0x2A24 | Model Number String | UTF-8 字符串 | 型号名称（如 “XCT-01”），APP 用于识别设备型号。 |
3. 典型交互流程
4. 骑行台场景核心作用
- 版本兼容检测：APP 读取固件版本后，可提示 “固件版本过低，需更新以支持 XX 功能”；
- 设备唯一标识：序列号用于用户绑定设备、客服排查问题（如 “序列号 54321 的设备校准失败”）；
- 合规性要求：蓝牙 SIG 认证要求所有商用蓝牙设备实现 DIS，未实现可能无法通过认证（量产必备）。
5. 开发 / 适配关键注意事项
- 数据格式为 UTF-8 字符串：
- 如固件版本 “V2.1.0” 需按字节存储为 0x56 0x32 0x2E 0x31 0x2E 0x30，不可用二进制 / 十六进制；
- 信息持久化：序列号、硬件版本需存储到 NV RAM，不可随固件更新改变；固件版本需与实际固件匹配（如 APP 读取 V2.1.0，但实际是 V2.0.0 会导致用户误解）；
- 特征值长度限制：每个特征字符串长度≤20 字节，超出会被 APP 截断（如序列号最长 16 位）。
Nordic UART Service (NUS)
1. 核心定义
NUS 是Nordic Semiconductor 自定义服务（非蓝牙 SIG 标准），专为 nRF51/nRF52 系列芯片设计，核心功能是 “蓝牙←→硬件 UART 透传”，即通过蓝牙模拟串口通信，是开发阶段的调试神器，非量产必备。
2. 核心特征（UUID + 属性 + 功能）
NUS 无蓝牙 SIG 标准 UUID，Nordic SDK 默认使用 128 位 UUID（可简化为 16 位自定义 UUID）：
| 特征类型 | 128 位 UUID（Nordic 默认） | 访问属性 | 核心功能（骑行台场景） |
|---|---|---|---|
| TX 特征 | 6E400002-B5A3-F393-E0A9-E50E24DCCA9E | NOTIFY | 蓝牙→UART：芯片将蓝牙主机下发的数据转发到硬件 UART（如调试电脑→蓝牙→骑行台 TI 芯片）。 |
| RX 特征 | 6E400003-B5A3-F393-E0A9-E50E24DCCA9E | WRITE | UART→蓝牙：芯片将硬件 UART 接收的数据（如 TI 芯片日志）通过蓝牙 NOTIFY 上报到调试电脑。 |
3. 典型交互流程（调试场景）
4. 骑行台场景核心作用
- 开发调试：无需物理串口线，通过蓝牙即可读取 TI 芯片的调试日志（如 “阻力调节失败”“校准超时”）；
- 临时数据透传：开发阶段可通过 NUS 下发测试指令（如 “设置阻力 50%”），验证 TI 芯片逻辑，无需通过 CPS/FMS；
- 量产禁用：NUS 是自定义服务，会被部分 APP（如 Zwift）过滤，且可能泄露调试信息，量产固件必须移除。
5. 开发 / 适配关键注意事项
- 与业务服务隔离：
- NUS 的 TX/RX 数据透传不可占用 CPS/FMS 的通信带宽（如 NUS 高频上报日志会导致 CPS 功率数据延迟）；
- 调试后必须移除：
- 量产固件需注释 NUS 初始化代码，否则会导致 APP 识别异常（如 Zwift 过滤含 NUS 的设备）；
- 串口参数匹配：
- NUS 透传的 UART 参数（波特率 115200、8N1）需与 TI 芯片的 UART 参数一致，否则数据乱码。
四类服务核心对比（骑行台场景）
| 服务 | 标准属性 | 核心价值 | 骑行台实现要求 | 适配 APP 关键 |
|---|---|---|---|---|
| CPS | 蓝牙 SIG 标准 | 功率数据上报 + 校准指令接收 | 必实现（核心业务） | 数据格式 / 指令响应 |
| FMS | 蓝牙 SIG 标准 | 设备识别（APP 搜得到） | 最小实现（仅服务声明） | 广播包包含 0x1826 UUID |
| DIS | 蓝牙 SIG 标准 | 设备信息提供 + 合规认证 | 必实现（量产必备） | 字符串格式 / 持久化 |
| NUS | Nordic 自定义 | 开发调试（蓝牙←→UART 透传） | 仅调试阶段启用 | 量产必须移除 |
扫一扫
1652
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
