蓝牙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接收升级数据,不备份用户代码,这样就能够留出更多空间给用户层代码。

posted @   JayWell  阅读(2765)  评论(0编辑  收藏  举报
努力加载评论中...
点击右上角即可分享
微信分享提示