蓝牙mesh组网实践（mesh组网的评估与沁恒蓝牙芯片选型）

沁恒的组网方式主要有2.4G私有协议组网和BLE mesh组网两大类。2.4G私有协议组网灵活性相对较高，对开发者的要求也相对较高。mesh组网本身有一系列规范，考虑到了可靠性、安全性、功能性等等方面，分了网络层、上下传输层、接入层、模型层，层层封装，各司其职，但同时也是一种限制，发包速率远不如2.4G私有协议组网。就好比吃面，懂厨艺的可以买面粉做拉面、炒面、手擀面，没那手艺的做出来的面还不如方便面的，也可以就吃方便面，至少稳定、实惠又安全，加点蔬菜肉类也能照顾到营养。想做密钥验证、转发中继、降低功耗等等功能吗，mesh协议栈里有规定好的的，用2.4G私有协议需要自己写。

一、评估是否使用mesh组网

mesh组网主要有两个局限，一个是发包频率/实时性问题，另一个是低功耗节点的支持问题。

发包频率/实时性：mesh底层发包需要重传，默认重传7次，每次间隔10ms，这样就占用近70ms，再加上数据加密等等过程，发送一则消息大概需要开销100ms，故一个节点往外发送消息的频率最高即为1s10则消息，这是协议限制。若只用2个节点在广播范围内进行应答测试，那100+ms后，发送方也能收到回包了，但在大范围使用中，消息的中继也是由节点转发消息，也是如上的发包流程，故建议整个mesh网络中，1s内最多产生10则消息。某1s内产生超过10则消息也不是不行，需要调整应用层重传次数、重传间隔、随机时长等等来确保接收方能收到消息，可以以时间换取丢包率，但实时性就无法保证。

如果要求每一秒都要产生超过10则消息，且这10则消息都需要跨越整个网络，那蓝牙mesh不太适用。发包频率固然也影响到了实时性，如果期望每秒内发更多的包，或传输延迟在100ms以内，建议用2.4G组网。在2.4G私有协议组网中，做好收发切换，不考虑收包方的话1ms发一包都行，发包频率、实时性和丢包率可以自行平衡，加密、转发等功能需要自己做。

针对低功耗节点，发消息与一般节点一致，工作状态下往外发就行了，有常供电节点进行接收和转发；接收消息的实时性则取决于低功耗节点多久向朋友节点POLL一次数据，若设置为10sPOLL一次，那发送方就只能期待10s内收到低功耗节点的回复。想要1s内就收到低功耗节点的回复，那么至少需要将低功耗节点POLL消息的频率设置为1s，且需要与接收方在广播范围内直连（转发一次消息也需要开销100+ms），代价就是功耗要更高、分布距离要更近。

低功耗节点的支持：消息的接收方是不知道消息什么时候过来的，而一直开着接收扫描等待，功耗会很高，故mesh协议将“接收”的功能分配到了朋友节点上，由低功耗节点轮询朋友节点，查看有没有低功耗节点的消息。发送消息发完就休眠，故不太影响功耗。低功耗节点本身是可以电池供电的，但是朋友节点仍需要常供电以维持接收扫描。这一点没办法规避，总有人需要付出“中继”的代价，没有供电让芯片启用中继转发或是朋友功能，就需要用到已经搭建好的通信平台。如果应用场景是在缺少供电的地方，有手机基站支持则建议用4G/5G通信模块，连手机基站都没有，那甚至需要用到卫星通信模块。

适合mesh的典型场景：楼宇内的灯控，其有市电供电、节点密度高等特点。mesh灯控可以提供良好的转发中继和朋友功能的支持，在楼宇内加装一般节点和低功耗节点比如说加装智能家居类的设备——智能插座、智能窗帘等，加装低功耗设备——温湿度传感器、烟雾传感器等，都可以走灯控网络来通信。

不适合mesh的场景：如多点动作捕捉设备，数据包交互频次高、实时性要求高，更适合通过2.4G自定义协议组网来实现。
再如低功耗要求高、响应速度要求高的智能门锁，更适合通过BLE来实现。mesh组网中，每一包数据都会在三个信道各收/发一遍；而BLE中，每个连接事件只需要在一个信道收/发数据包，这直接带来了3倍的功耗差距。

二、选型沁恒的mesh组网MCU

沁恒的RISC-V BLE芯片主要有CH592系列(性价比)、CH585系列(更大内存)、CH32V208系列(带以太网接口)、CH573系列/CH583系列(这两个系列的产品定位由后续推出的592/585系列迭代覆盖，不推了)。mesh协议栈是纯软件的，这几款芯片走mesh都能互通，对于mesh的应用来说，差别只在falsh与ram的大小上。

MCU选型 - 南京沁恒微电子股份有限公司

跑mesh+BLE的应用，或是跑mesh的配网器代码，强烈推荐CH585/584，ram容量为128K/96K，管够。

CH32V208的flash标注为128K，是特指用户层APP占用的零等待flash，实际总量为480K。mesh/BLE库后置到320K的非零等待flash中，也能实现mesh和BLE从机功能同时运行，能够支持OTA。

V208的ram大小为64K，CH585/585的ram容量为128K/96K，这几款MCU作为配网者节点，可以支持协议栈限制的最大数量255个设备（自配网/手机配网方式下不受限，可做到标准mesh规定的32K个节点），作为朋友节点也可以支持255个低功耗节点（通信频次很低的场景下）。

（由CH591平替，不再推荐）571的局限在于codeflash为192K，ram为18K。BLE库+mesh库需要占用大概200K的codeflash，故不支持在跑mesh的同时走BLE连接手机。如果作为中心节点，最多支持100个节点。

573的codeflash为448K，足够存放BLE库和mesh库。带BLE功能的节点代码编译后，占用ram大小为16K+，作为一般节点是能跑的。编译时ram没有计算局部变量、动态申请的内存等空间，加上用户层代码的ram开销，若占用ram总量的95%以上很有可能会影响到使用，故用户层做的功能也不能太多。对于OTA升级功能，ram的利用率相对较低，需要挖掉4Kram以供BLE固定库使用，留给mesh的ram就只剩10K。然而只提供mesh透传模型，不带BLE的一般节点，默认代码编译之后都需要占用14K+的ram，故不支持OTA。对ram大小要求比较高的需求，包括朋友节点功能和管理网络的配网器，都不建议用571/573来进行。573的ram资源与571一致，如果作为中心节点，最多支持100个节点。

（由CH584/585平替，不再推荐）583相较于582，优势在于低电压供电，其他功能是一致的。582的codeflash为448K，ram为32K，可以支持OTA功能（参考最新EVT中的手机配网例程），是沁恒的蓝牙mesh方面主推的mcu。如果作为中心节点，最多支持200个节点。若用作自配网的一般节点，582这颗MCU是足以胜任的。如果涉及到用作朋友节点（FN），FN支持的低功耗节点（LPN）的个数上限由RAM的大小决定，每一个LPN会占用FN332字节的RAM以及CONFIG_MESH_UNSEG_LENGTH_DEF*CONFIG_MESH_LPN_REQ_QUEUE_SIZE_DEF字节的缓存（BLE_MEMHEAP_SIZE）。目前测试，能够实现支持10个LPN，每个LPN每隔2s向FNPOLL一次数据。

对表格中的不同方式OTA的解释：

OTA(MESH+BLE)：支持WCH MESH做OTA升级的代码，是通过BLE直连任意一个节点，经由该节点将BEL包转发为mesh包，走mesh网络转发OTA升级数据到指定节点进行升级的，需要做固定库+备份用户代码（用户层代码中包含有实现mesh功能的代码，故需要备份以保持mesh通信，新代码校验完成后再把老代码擦除誊写），占用的codeflash比较多。

OTA(仅BLE)：仅走BLE升级而不做mesh网络转发OTA的新固件包，适合用户代码占用codeflash很多的情况。使用固定库升级，在IAP中由BLE接收升级数据，不备份用户代码，这样就能够留出更多空间给用户层代码。