LoRa模组FSK模式下WOR功耗估算实例

 

LoRa模组（例如SX127X模组、SX126X模组或者LLCC68模组）不仅支持LoRa调制模式，也支持FSK调制模式。
 

实际应用中有部分使用者硬件使用的是LoRa模组，但是使用的不是该模组的LoRa模式，而是使用的该模组的FSK模式，并需要使用FSK模式下的WOR功能。

在确定使用FSK模式下的WOR功能时需要先估算功耗是否能满足使用者的低功耗需求，本文就给有这种需要的使用者提供一种估算WOR功耗的参考方法。

 

 

过程

以LLCC68模组为例。

01

确认正常通信模式下参数和WOR模式下参数

本次举例以如下参数为例。

1、正常通信模式下：4字节前导码；4字节同步字；10Kbps空中波特率；0dBm发射功率（使用0dBm只是为了调试期间在仪器上看数据方便些）；可变数据包模式；

2、WOR模式下：2字节前导码；2字节同步字；10Kbps空中波特率；0dBm发射功率（使用0dBm只是为了调试期间在仪器上看数据方便些）；固定数据包模式；

WOR 模式下选择如上配置目的是使唤醒包的长度能尽量短一些，实际使用者可以根据自己的需要选择不同的参数，但是最好和正常通信模式做一个区分。达到一个正常模式下接收的模组收不到唤醒包并且WOR模式下的模组不会被正常模式下的数据包唤醒的目的。

 

02

WOR模式下唤醒包测算

把主机调整套WOR模式下的参数后，让主机不停的连续发射唤醒短包（2字节前导码；2字节同步字；2字节负载），发送完一个唤醒短包后加个20ms延时后马上发送下一个唤醒短包，这里加入20ms延时是为了读取单个唤醒短包发送时间方便而加入的。

WOR模式下10Kbps空中波特率2字节前导码；2字节同步字；2字节负载时，每个唤醒短包发送时间应该为：1000ms/10Kbps*6字节*8bit=4.8ms。

实测一下，发现和计算值能够对得上。

然后把20ms的延时去掉，改为每发送完一个唤醒短包后马上发送下一个唤醒短包，测算能够充分发送完两个唤醒短包的时间。
 

“能够充分发送完两个唤醒短包得时间”测算时，需要取一个比较宽裕的充分值，这里测到的值为15.5ms，我们按照16ms记录。

测算这个值的重要性是因为每个单独的唤醒短包实际发送时间虽然能和理论值4.8ms对得上，但连续发送状态下，有状态得转换时间，有SPI得占用时间，所以连续发送唤醒短包的2包时间并不是9.6ms（4.8ms*2=9.6ms）。

这个实测出的16ms非常重要，因为该时间将作为WOR状态下接收端的WOR接收窗口的开启时间的计算基础参数。

只有WOR状态下接收端的WOR接收窗口的开启时间大于等于这个16ms，才能充分保证接收窗口时间内，能保证至少有一个完成得唤醒短包得整个空中传输过程被包含在WOR接收窗口内。

 

 

WOR功耗计算

1、接收电流测算。

由模组规格书可知，LLCC68模组接收状态下功耗在5mA左右（3.3V供电下）。

实测下为4.6mA，就按照5mA计算（为了计算的待机时间更加充裕稳妥所以接收电流按照稍微大点的计算）

2、SLEEP电流测算。

由规格书可知，SLEEP功耗在3.3V下在0.6uA左右。

实测一下为0.6uA左右，按照1uA计算（为了计算的待机时间更加充裕稳妥所以SLEEP电流按照稍微大点的计算）

3、以WOR周期中每保持4秒得SLEEP状态后开启一次WOR接收窗口为例计算。

如上可知：WOR接收窗口时长为16ms，WOR接收窗口电流为5mA（5000uA），WOR得周期SLEEP保持时间为4s（4000ms），WOR得周期SLEEP功耗为1uA。

模组WOR期间平均功耗为：

（5000uA*16ms+1uA*4000ms）/（16ms+4000ms）=20.92uA

4、以使用者要求平均功耗为30uA，估算每个WOR周期时间，计算如下。

（5000uA*16ms+1uA*Xms）/（16ms+Xms）=30uA

X=2742.1ms

即每保持SLEEP状态2742.1ms后开启一次16ms得WOR接收窗口时，可以达到WOR的平均功耗为30uA的要求。

 

 

结论

参考如上方法即可估算出LoRa模组在WOR模式下的平均功耗值，或者满足客户要求下得WOR周期情况。
需要说明如下几点：

1、单个唤醒短包的空中发送时间长度的2倍不能做为WOR接收窗口的参考时间，WOR接收窗口的参考时间需要真实测试后确定。

2、接收电流和SLEEP电流在测试后取值用来做为估算参考值时需要稍微取偏大一点，为了保证计算的结果更加充裕稳定。

3、使用者估算电池是否够用时不要忘记电池的自放电特性。

4、正常通信模式下和WOR状态下的模组的参数配置最好有所变化（能达到正常模式下接收的模组收不到唤醒包并且WOR模式下的模组不会被正常模式下的数据包唤醒的目的），以减少系统内部误唤醒的概率。