基于BLE CSCP协议的骑行速度与踏频监测系统开发指南-尧图网络科技

1. 项目概述与核心价值

如果你正在开发一款智能骑行设备，或者想为现有的自行车添加专业的运动数据监测功能，那么基于蓝牙低功耗（BLE）的骑行速度与踏频监测系统绝对是一个值得深入研究的课题。这不仅仅是简单地把传感器数据发出去，它背后涉及一整套成熟的物联网通信协议、嵌入式系统交互逻辑以及运动数据的精准计算。我花了相当长的时间，在TI的MSP432和ST的STM32F4平台上，把官方的CSCP（Cycling Speed and Cadence Profile）演示指南从头到尾啃了一遍，并进行了大量的实际调试和功能验证。这个过程里踩过的坑、总结出的经验，远比那份技术文档要丰富得多。

简单来说，这个系统包含两个角色：传感器端（Server）和收集器端（Client）。传感器通常安装在自行车的花鼓或曲柄上，实时测量车轮转动的圈数、时间以及踏板的转动圈数。收集器则可以是你的手机、智能手表或者一块专用的骑行码表，它负责连接传感器、接收数据，并计算出实时的速度（km/h）和踏频（rpm）。整个通信的基石是BLE的GATT（通用属性配置文件），它定义了数据如何被组织、发现和传输。对于嵌入式开发者而言，理解如何在一个资源受限的MCU上，正确地实现CSCP服务，处理连接、发现、配置、通知这一整套流程，是打通产品化“任督二脉”的关键。本指南将带你深入这个过程的每一个细节，从原理到实操，从命令解析到避坑指南，目标是让你能独立复现并理解这套系统的完整运作机制。

2. 系统架构与BLE通信原理解析

2.1 客户端-服务器模型在BLE中的体现

很多人初次接触BLE时，容易将其与传统的客户端-服务器（C/S）网络模型混淆。在BLE的世界里，这个模型更为轻量和具体。服务器（Server/GATT Server）是数据的持有者和提供者。在我们的骑行监测场景中，它就是那个安装在自行车上的传感器。它的核心任务是：1. 向外广播自己的存在（Advertising）；2. 维护一个包含骑行速度与踏频数据的数据结构，这个结构在BLE中被称为服务（Service）。

一个服务由多个特征（Characteristic）组成。对于CSCP服务，其核心特征至少包括：

CSC Measurement（测量值）：这是一个“通知（Notify）”型特征。传感器不主动发送数据，而是在数据更新时，等待客户端“订阅”后，以通知的方式推送。这极大地节省了功耗，因为只有连接建立且客户端明确表示需要数据时，服务器才会发送。
CSC Feature（特性）：这是一个“读（Read）”型特征。客户端可以读取它，以了解这个传感器支持哪些功能，比如是否支持车轮转速测量、是否支持踏频测量、是否支持多个传感器安装位置。
Sensor Location（传感器位置）：一个“读”型特征，告诉客户端传感器当前安装在哪里（如前轮、后轮、左曲柄等）。
SC Control Point（控制点）：这是一个“指示（Indicate）”型特征。它允许客户端向服务器发送命令，例如重置累计圈数、请求支持的传感器位置列表、更新传感器位置等。指示与通知的关键区别在于，指示要求接收方（服务器）回复一个确认，保证了命令传输的可靠性。

客户端（Client/GATT Client）是数据的请求者和消费者，比如你的手机App。它的工作流程是：扫描并发现附近的传感器，发起连接，连接成功后发现（Discover）服务器提供的所有服务和特征，找到CSC服务及其特征句柄（Handle）。然后，它需要配置（Configure）服务器，例如使能CSC Measurement特征的“通知”和SC Control Point特征的“指示”。一旦配置完成，服务器就可以开始推送数据，客户端则根据收到的原始数据（累计圈数、事件时间）计算出瞬时速度和踏频。

2.2 CSCP数据格式与计算逻辑

这是整个系统的算法核心。传感器上报的不是直接的速度和踏频，而是最原始的脉冲计数和时间戳。这样做的好处是精度高、数据量小，且计算逻辑可以放在资源更丰富的客户端（如手机）上。

数据包结构：当传感器调用NotifyMeasurements时，它会组织一个数据包。这个包包含一个标志位（Flags），用于声明本次数据包含哪些内容。之后的数据字段根据标志位动态出现：

标志位（1字节）：Bit 0表示是否包含车轮数据，Bit 1表示是否包含曲柄数据。
累计车轮转数（Cumulative Wheel Revolutions， 4字节）：从传感器启动或上次重置以来，车轮转动的总圈数。这是一个32位无符号整数，会随着骑行不断累加。
上次车轮事件时间（Last Wheel Event Time， 2字节）：最近一次车轮转动事件发生时的时间戳。单位是1/1024秒。这是一个16位无符号整数，每过大约64秒（65536 / 1024）会归零一次。
累计曲柄转数（Cumulative Crank Revolutions， 2字节）：从传感器启动或上次重置以来，曲柄转动的总圈数。16位无符号整数。
上次曲柄事件时间（Last Crank Event Time， 2字节）：最近一次曲柄转动事件发生时的时间戳。单位同样是1/1024秒。

瞬时速度计算：速度计算依赖于连续两次通知的数据。

计算圈数差：ΔRev = 本次累计车轮转数 - 上次累计车轮转数。这里需要注意32位整数的溢出回绕问题，正确的处理方式是使用无符号整数运算，并认为(本次值 - 上次值)的结果即为差值（即使本次值因溢出而小于上次值，在无符号运算下也能得到正确的差值）。
计算时间差：ΔTime = (本次事件时间 - 上次事件时间) & 0xFFFF。由于时间是16位的，需要用掩码处理可能的回绕。单位是1/1024秒。
计算瞬时速度：速度（cm/s) = (ΔRev * 车轮周长(cm)) / (ΔTime / 1024)。
单位转换：速度（km/h) = 速度（cm/s) * (3600 / 100000) = 速度（cm/s) * 0.036。也可以合并为：速度（km/h) = (ΔRev * 周长(cm) * 3.6 * 1024) / (ΔTime * 100)。

瞬时踏频计算：踏频计算同样依赖连续两次数据。

计算圈数差：ΔCrankRev = 本次累计曲柄转数 - 上次累计曲柄转数。处理16位溢出。
计算时间差：ΔCrankTime = (本次曲柄事件时间 - 上次曲柄事件时间) & 0xFFFF。
计算瞬时踏频：踏频（转/秒) = ΔCrankRev / (ΔCrankTime / 1024)。
单位转换：踏频（rpm) = 踏频（转/秒) * 60 = (ΔCrankRev * 60 * 1024) / ΔCrankTime。

关键提示：在嵌入式传感器端，通常只负责准确计数和上报(累计值，事件时间)对。所有的差值计算和单位转换都应在客户端完成。TI的演示代码在开启DISPLAY_DEBUG宏时，会在客户端终端直接显示计算好的速度和踏频，这为我们验证传感器数据准确性和计算逻辑提供了极大的便利。

2.3 开发平台与协议栈选择

官方指南基于TI的蓝牙协议栈，并适配了MSP432（TI自家MCU）和STM32F4（通过移植）两个平台。这里有几个深层次的考量：

为什么是TI协议栈？TI在蓝牙芯片领域深耕多年，其协议栈以稳定性和完整性著称。对于快速实现标准协议（如CSCP），使用成熟的商业协议栈可以避免在底层射频驱动、链路层管理上耗费大量时间，让开发者聚焦于应用逻辑。但这也意味着你需要遵循它的API框架和事件回调机制。
MSP432 vs STM32F4：从��心演示功能上看，两者没有区别。选择哪个往往取决于项目已有的技术栈、成本、外围设备需求以及团队熟悉度。MSP432是TI的亲儿子，集成和调试可能更顺畅。STM32F4则拥有更广泛的生态和更高的主频，适合需要复杂处理或与其他STM32外设协作的项目。实操中发现，STM32F4的工程移植需要注意时钟配置和串口引脚的映射，确保用于打印调试信息的UART能与PC正常通信。
硬件连接与调试接口：无论是哪个平台，开发板都需要通过USB转串口（CDC）与PC连接。在设备管理器中，它会显示为“XDS110 Class Application/User UART (COMx)”或类似的串行端口。使用PuTTY或任何你喜欢的串口工具（如SecureCRT、MobaXterm）以115200波特率、8数据位、无校验、1停止位（8N1）连接即可。这是一个非常关键的调试手段，所有的命令输入和状态输出都依赖这个串口终端。

3. 服务器端配置与广播详解

3.1 服务注册与特性声明

服务器端的初始化是一个严谨的、按步骤进行的过程，不能错序。第一步永远是RegisterCSCS。这个命令背后调用了CSCS_Initialize_ServiceAPI，它的作用是向协议栈注册CSCP服务，并生成一个唯一的InstanceID。这个ID是后续所有针对该服务操作的句柄。如果注册失败，常见的错误码是CSCS_ERROR_INSUFFICIENT_RESOURCES，这通常意味着协议栈内存分配失败，需要检查堆栈大小配置。

注册成功后，服务器还只是一个“空壳”，它具备了CSCP服务的框架，但具体支持哪些功能是未定义的。接下来就需要使用SetSupportedFeatures命令来声明自身能力。这个命令接收三个参数：<Wheel Measurement Support> <Crank Measurement Support> <Multiple Location Support>，每个参数为0（不支持）或1（支持）。

经验之谈：这里的设置必须与硬件实际能力匹配。如果你的传感器只装了车轮磁铁，没装曲柄磁铁，那么Crank Measurement Support必须设为0。如果设为1，后续在NotifyMeasurements时却无法提供曲柄数据，会导致通知失败。我建议在产品固件中，这个特性集应该通过读取硬件配置（如跳线帽、EEPROM设置）来动态决定，而不是写死在代码里。

SetSupportedFeatures 1 1 1是最完整的配置，支持车轮、曲柄和多位置。执行后，服务器会提示需要在客户端执行GetRemoteFeatures。这是因为在BLE规范中，服务的“特性（Features）”是一个可读的特征，客户端需要主动去读取才能知晓。

3.2 传感器位置列表配置

当Multiple Location Support启用时，SetSupportedSensorLocationBitMask命令才有效。这个命令用一个16位的位掩码（BitMask）来定义传感器可能被安装的所有位置。每一位代表一个预设的位置（如0x0001-其他，0x0002-鞋顶，0x0004-鞋内，0x0008-髋部，0x0010-前轮，0x0020-左曲柄，0x0040-右曲柄等）。0x7fff表示支持所有15个标准位置（第15位保留）。

这个列表是“支持的位置列表”，并非当前实际位置。它相当于告诉客户端：“我这款传感器可以装在这几个地方”。实际安装位置由另一个独立的特征Sensor Location表示，并且可以通过客户端的SetSCControlPoint命令来更改（如果支持多位置）。

配置示例：如果你的传感器设计为仅可安装在前轮或后轮，那么位掩码应为0x0010 | 0x1000 = 0x1010。输入命令SetSupportedSensorLocationBitMask 0x1010。

3.3 启动广播与连接管理

完成上述配置后，服务器就可以开始广播了。命令AdvertiseLE 1会启动低功耗广播。此时，服务器会周期性地发送广播包，其中包含设备名称、服务UUID（0x1816，即CSCP服务）等信息，等待客户端扫描和连接。

广播参数（如间隔、广播数据）通常在协议栈初始化时或通过其他API设置，演示代码可能使用了默认值。在实际产品中，你需要权衡广播间隔：间隔短则被快速发现，但功耗高；间隔长则省电，但客户端扫描到它的时间会变长。

一旦有客户端发起连接并成功，服务器和客户端都会收到LE_Connection_Complete事件。在演示代码的串口终端，你会看到相关的连接信息打印出来，包括连接句柄和对方设备地址。至此，服务器端的被动准备工作全部完成，进入等待客户端配置和请求数据的状态。

4. 客户端连接、发现与配置流程

4.1 设备扫描与连接建立

客户端的第一步是发现周围的传感器。通过StartScanning命令，客户端开始扫描广播包。在串口终端，你会看到扫描到的设备列表，通常包括设备地址、信号强度（RSSI）和设备名称（如果有）。找到你的传感器设备（可以通过设备地址或名称识别），记下它的蓝牙地址（BD_ADDR）。

排查技巧：如果扫描不到设备，请按以下步骤检查：
确认服务器板子已上电并执行了AdvertiseLE 1。
检查两块板子之间的距离，确保在BLE有效范围内（通常10米内无障碍）。
确认没有其他强射频干扰。
查看服务器终端是否有错误打印。

找到目标地址后，使用StopScanning停止扫描，然后使用ConnectLE <BD_ADDR>命令发起连接。连接成功后，双方终端都会打印连接完成的信息。这里有一个细节：连接参数（连接间隔、从机延迟、监控超时）会由协议栈自动协商。对于CSCP这种需要频繁（如每秒1-10次）更新数据的应用，较短的连接间隔（如15ms-30ms）有利于降低数据传输延迟，但会增加功耗。在实际开发中，你可能需要通过协议栈的API来优化这些连接参数。

4.2 服务与特征发现

连接建立后，客户端对服务器一无所知，不知道它提供什么服务，更不知道特征句柄。因此，必须进行服务发现。DiscoverCSCS命令就是这个过程的触发器。它内部调用了GATT_Service_Discovery_Start，并指定了CSCP服务的UUID（0x1816）。发现过程完成后，客户端会在本地存储该服务下所有特征的句柄（Handle），例如：

CSC Measurement特征的句柄（用于订阅通知）
CSC Feature特征的句柄（用于读取）
SC Control Point特征的句柄（用于发送命令）
各特征对应的CCCD（Client Characteristic Configuration Descriptor）句柄（用于配置通知/指示）。

这些句柄是后续所有读写操作的“门牌号”，至关重要。发现成功后，终端会打印出找到的句柄值。

4.3 远程特性读取与配置

发现句柄后，客户端需要了解服务器的能力。GetRemoteFeatures命令会向服务器发起一个读请求，读取我们之前在服务器用SetSupportedFeatures设置的值。返回的位掩码会打印在终端上，客户端解析后就知道该服务器支持车轮、曲柄还是两者都支持。

接下来是最关键的一步：配置通知和指示。ConfigureRemoteCSCS 1命令会做两件事：

向CSC Measurement特征的CCCD写入0x0001，启用通知（Notification）。
如果服务器支持SC Control Point特征，则向其CCCD写入0x0002，启用指示（Indication）。

这个命令执行后，服务器端会收到配置更新的事件。从此，服务器就可以通过NotifyMeasurements主动推送数据，而客户端也可以安全地发送SetSCControlPoint命令（因为指示已被启用，能收到确认）。如果配置失败，请检查服务发现是否成功，以及对应的CCCD句柄是否正确。

5. 数据交互与核心功能实现

5.1 车轮��长设置与速度计算基础

在客户端开始接收数据前，有一个必须设置的参数：车轮周长。速度计算的公式依赖于这个值。命令是SetWheelCircumference <周长（厘米）>。例如，一辆典型的700x25c公路自行车，车轮周长约为210厘米。设置命令SetWheelCircumference 210会将这个值保存在客户端，用于后续所有速度计算。

重要提示：这个参数是保存在客户端的，服务器端完全不知情。这意味着，同一个传感器连接不同的客户端设备（如手机和码表），需要在每个客户端上分别设置正确的轮周长。这也是为什么专业的骑行App或码表都有手动设置轮周长或选择轮胎型号的功能。

5.2 SC控制点命令详解与应用

SC Control Point是客户端主动管理传感器的通道。它支持三种操作码（Op Code）：

设置累计车轮转数（Op Code = 1）：SetSCControlPoint 1 <新累计值>。这个功能非常实用，例如在更换电池后，累计值可以从0开始，但用户希望保持总里程的连续性，就可以用这个命令将传感器的累计值设为一个较大的数。注意：此操作仅在服务器支持车轮测量（Wheel Measurement）时有效。
更新传感器位置（Op Code = 2）：SetSCControlPoint 2 <位置编号>。位置编号来源于“支持的传感器位置列表”。这个操作允许用户通过客户端App更改传感器位置记录，而无需重新拆装硬件。前提是服务器支持多位置，且目标位置在支持列表中。
请求支持的传感器位置列表（Op Code = 3）：SetSCControlPoint 3。当客户端不清楚服务器支持哪些位置时，可以发送此命令。服务器会通过一个“指示（Indication）”回应，将SetSupportedSensorLocationBitMask对应的位掩码列表（每个位置作为一个独立的条目）发送给客户端。客户端收到后可以解析并展示给用户选择。

操作流程示例（更改传感器位置）：

客户端发送SetSCControlPoint 3，请求列表。
服务器回复指示，包含列表（例如[0x0010（前轮）， 0x1000（后轮）]）。
客户端解析列表，并在UI上显示“前轮”、“后轮”选项。
用户选择“后轮”，客户端发送SetSCControlPoint 2 0x1000（假设位置编号映射正确）。
服务器更新内部位置记录，并回复操作成功的指示。
客户端可以发送GetRemoteLocation命令（或服务器主动通知后查询）来验证位置已更新。

5.3 测量数据通知与实时计算

一切就绪后，服务器端可以通过NotifyMeasurements命令模拟数据上报。该命令的参数取决于支持的特性：

仅支持车轮：NotifyMeasurements <累计车轮转数> <车轮事件时间>
仅支持曲柄：NotifyMeasurements <累计曲柄转数> <曲柄事件时间>
两者都支持：NotifyMeasurements <累计车轮转数> <车轮事件时间> <累计曲柄转数> <曲柄事件时间>

示例：NotifyMeasurements 2008 64000 65534 9300

2008: 累计车轮转了2008圈。
64000: 最后一次车轮事件发生在64000 / 1024 ≈ 62.5秒的时刻。
65534: 累计曲柄转了65534圈（接近16位溢出）。
9300: 最后一次曲柄事件发生在9300 / 1024 ≈ 9.08秒的时刻。

当客户端（在调试模式下）收到连续两次通知后，就会利用前面提到的公式，结合预设的车轮周长，计算出瞬时速度和踏频并打印出来。

模拟真实数据流：

第一次通知：NotifyMeasurements 1000 50000 30000 8000
等待一小段时间（模拟骑行）。
第二次通知：NotifyMeasurements 1005 50200 30010 8020
客户端计算：
- 速度：ΔRev = 5圈，ΔTime = (50200-50000) & 0xFFFF = 200 ticks，时间差 = 200/1024 ≈ 0.1953秒。假设周长210cm，速度 =(5 * 210) / 0.1953 ≈ 5376 cm/s ≈ 193.5 km/h（这个速度显然不现实，说明模拟的时间间隔太短，仅作演示计算逻辑）。
- 踏频：ΔCrankRev = 10圈，ΔCrankTime = (8020-8000) & 0xFFFF = 20 ticks，时间差 = 20/1024 ≈ 0.0195秒。踏频 =10 / 0.0195 ≈ 512.8 转/秒 ≈ 30770 rpm（同样不现实，仅演示计算）。

在实际产品中，传感器会根据磁铁触发频率，以固定的时间间隔或每转一圈就发送一次通知，从而计算出符合物理规律的速度和踏频。

6. 关键API深度解析与开发注意事项

6.1 服务端核心API调用链

CSCS_Initialize_Service：这是起点。它分配服务所需的内存，注册事件回调函数。回调函数是服务端应用的核心，所有客户端发来的读/写/指示请求，以及连接事件，都会通过这个回调函数通知应用层。开发者必须在这个回调里妥善处理各种事件，例如更新特征值、响应控制点命令。
CSCS_Set_Supported_Features与CSCS_Set_Sensor_Location_List：这两个调用设置了服务的“元数据”。它们必须在服务开始广播前完成。在回调函数中，当收到客户端读取“CSC Feature”或“Sensor Location”特征的请求时，协议栈会自动返回这些预设的值。
CSCS_Measurements_Notification：这是服务端主动推送数据的唯一途径。它被NotifyMeasurements命令调用。其内部会检查连接是否存在、通知是否已被客户端启用，然后通过ATT协议将数据包发送出去。开发者需要确保调用此函数时，传入的CSCS_Measurements_Data_t结构体中的标志位（Flags）与数据字段严格匹配，否则会导致客户端解析错误。

6.2 客户端核心API调用链

GATT_Service_Discovery_Start：由DiscoverCSCS触发。这是一个异步操作。它启动发现过程，发现结果（找到的特征句柄）会通过注册的回调函数返回。演示代码将这些句柄保存在一个全局结构体中供后续使用。在实际开发中，你需要编写代码来解析这个回调，并存储各个特征的句柄。
GATT_Write_Request：这是一个通用函数，用于向远程设备的某个特征写入数据。它被用于：
- ConfigureRemoteCSCS：向CCCD写入0x0001或0x0002。
- SetSCControlPoint：向SC Control Point特征写入格式化好的命令数据。这是一个异步带确认的写入（Write with Response）。操作结果（成功或失败）会通过指定的回调函数返回。
GATT_Read_Value_Request：用于读取远程特征的值。GetRemoteFeatures和GetRemoteLocation命令都使用它。同样，读取到的数据通过回调函数返回，应用层需要解析这些数据。

6.3 开发中的常见陷阱与解决方案

连接不稳定或频繁断开：
- 可能原因：连接参数（Connection Parameters）不合理，或者射频信号受干扰。
- 解决方案：在连接建立后，客户端可以使用GATT_Update_Connection_Parameters请求更优的参数（如最小连接间隔15ms，最大30ms，从机延迟0）。确保天线周围没有金属物体遮挡。
通知无法收到或时有时无：
- 可能原因1：客户端没有成功写入CCCD。检查ConfigureRemoteCSCS命令的返回值和终端的打印信息。
- 可能原因2：服务器端调用CSCS_Measurements_Notification过于频繁，超过了连接间隔或缓冲区限制。
- 解决方案：在服务器端，确保在收到“CCCD已更新”事件后再开始发送通知。控制通知发送频率，不要高于连接事件频率。
控制点命令发送后无响应：
- 可能原因：SC Control Point特征的“指示（Indication）”未被启用。指示需要客户端先写入CCCD（0x0002）来启用。确保ConfigureRemoteCSCS命令已执行，且服务器支持控制点功能（需要车轮或��位置支持）。
- 解决方案：检查服务器端SetSupportedFeatures的配置。在客户端，确认ConfigureRemoteCSCS执行成功。
速度/踏频计算值异常（过大、过小或负数）：
- 可能原因1：车轮周长设置错误。检查SetWheelCircumference的值，单位是厘米。
- 可能原因2：累计值或事件时间溢出处理不当。客户端代码必须使用无符号整数运算，并正确处理16位和32位的回绕。
- 可能原因3：两次通知的时间间隔太短或太长，导致计算误差。确保传感器模拟数据时，事件时间的增量符合物理规律（例如，时速30km/h，周长210cm，则每秒约转40圈，事件时间增量约为1024/40=25.6个tick）。
- 解决方案：在客户端计算代码中加入详细的调试日志，打印出每次收到的原始数据和中间计算步骤，与预期值进行比对。
功耗过高：
- 可能原因：广播间隔太短、连接间隔太短、或CPU未在空闲时进入低功耗模式。
- 解决方案：优化广播参数（如增加到几百毫秒）。协商合理的连接间隔。在MCU的main loop或空闲任务中，调用协议栈提供的进入低功耗模式的函数（如Power_sleep()）。使用示波器测量电池电流，定位耗电大户。

7. 从演示到产品：工程化实践建议

官方的演示代码提供了一个完美的起点，但要将它变成一个真正的产品，还有很长的路要走。以下是我在实际项目中总结的一些经验：

传感器数据源：演示代码用串口命令模拟数据。真实产品需要连接霍尔传感器或磁编码器来检测车轮和曲柄的转动。你需要编写中断服务程序（ISR）来捕获磁铁信号，在中断中记录事件时间并增加累计圈数。注意防抖处理和功耗优化（例如使用MCU的外部中断唤醒功能）。
数据上报策略：不要每转一圈就发送一次通知。对于速度，可以定时（如每秒1次）计算并上报；对于踏频，由于频率较低，可以每转一圈或每两圈上报一次。更智能的策略是动态调整上报频率，高速时频率增加，低速或静止时降低甚至停止。
功耗管理：
- 静态功耗：在未连接时，MCU和蓝牙芯片应进入深度睡眠，仅由RTC或外部中断（磁铁信号）唤醒。
- 连接态功耗：协商尽可能长的连接间隔，同时满足数据实时性要求。利用从机延迟（Slave Latency）特性，允许从机跳过一定数量的连接事件而不唤醒，进一步省电。
- 软件优化：处理完事件后立即进入低功耗模式。
鲁棒性增强：
- 连接丢失处理：实现断线重连机制。当连接意外断开时，传感器端应自动恢复广播。
- 数据校验与容错：在传输的数据包中加入简单的校验（如CRC），客户端对异常数据（如时间戳逆跳）进行过滤。
- 参数存储：将车轮周长、传感器位置等配置参数保存到MCU的Flash或EEPROM中，掉电不丢失。
多客户端连接：标准CSCP通常是一对一连接。如果你的设备需要支持同时连接手机和码表，可能需要实现BLE的“一对多”连接，或者使用广播模式发送数据（但这不属于CSCP规范，需要自定义）。这涉及到更复杂的协议栈配置和资源管理。
认证与测试：如果计划上市销售，产品需要通过蓝牙SIG的认证，以确保符合CSCP规范。同时，需要进行大量的实地骑行测试，在不同速度、不同路况、不同温度下验证数据的准确性和系统的稳定性。

把这个演示跑通只是第一步，就像拿到了乐高说明书拼出了基础模型。真正的挑战和乐趣在于，如何基于这个模型，设计电路、编写固件、优化功耗、处理异常，最终把它变成一个装在自行车上、可靠运行数百小时、为用户提供精准数据的成品。这个过程会遇到无数数据手册里没写的问题，而每一次解决问题的经历，都是嵌入式开发者和物联网工程师最宝贵的财富。希望这份详细的指南和补充的经验，能为你点亮前行路上的几盏灯。