类似非小号的网站怎么做,ui设计是什么需要美术功底吗,广告设计制作合同模板,沈阳专业网站建设报价模组支持的功耗模式
蜂窝通信模组支持多种工作模式#xff0c;每种模式的功耗各不相同#xff0c;常见的工作模式有以下几种#xff1a; ACTIVE#xff1a;模组进行LTE数传、GSM通话或RTOS在运行逻辑时的状态#xff0c;功耗受到具体业务和网络通信制式的影响#xff0c…模组支持的功耗模式
蜂窝通信模组支持多种工作模式每种模式的功耗各不相同常见的工作模式有以下几种 ACTIVE模组进行LTE数传、GSM通话或RTOS在运行逻辑时的状态功耗受到具体业务和网络通信制式的影响CPU本身功耗和网络射频功率都有所不同故实际功耗在不同工况下会有较大差异。
IDLE此时模组处于空闲状态硬件正常在电RTOS保持运行但没有任何线程需要被执行。有业务启动或网络业务呼入时会立即恢复运行。ECX00U系列模组会在IDLE模式下降低时钟频率进入轻睡眠状态关闭高速时钟但CPU不休眠的状态。
休眠休眠模式的前提是模组处于空闲状态且使能autosleep进入休眠模式后RTOS暂停运行模组的时钟频率会变慢部分外设控制器UART、SPI等下电同时只保留部分中断控制器达到减小功耗的目的。
PSMPSM模式是3GPP协议所规定的一种低功耗模式这种模式下模组只会周期性的唤醒并执行业务其余时间都处于PSM休眠中。PSM休眠时模组行为和功耗都近似于关机。
关机模组完全下电的状态此时BB芯片和外设控制器完全关闭但PMIC仍是在电的。一般可由Powerkey或者RTC闹钟唤醒。
各平台工作模式支持情况和功耗
ECX00UECX00GECX00NECX00MECX00EBG95EC21IDLELTE FDD64ms12.34 mA10.1 mA17.36 mA16.72 mA4 mA18.9 mA(catm128ms)16.9 mASLEEP(LTE FDD64ms)2.05mA1.99 mA1.64 mA1.37 mA0.64 mA1.89 mA(catm128ms)2.74 mASLEEP(CFUN0)1.29mA1.03 mA0.96 mA0.8 mA60 μA0.575mA1.00 mAPSM15 μA15 μA不支持不支持5 μA5.10 μA不支持关机33 μA15 μA20 μA38 μA3 μA14.87 μA7 μA
IDLE即是模组空闲的状态关机则是切断电源这两种功耗模式我们不多做赘述。实际使用中我们经常用的休眠模式就是休眠和PSM模式。
休眠
休眠是蜂窝通信模组最常用的一种低功耗模式。模组处于空闲状态时若autosleep被使能则模组会进入休眠状态。此时模组会关闭部分IP核如外设控制器和中断控制器等并且降低时钟频率从而实现功耗的降低。 autosleep是一个控制是否在空闲时进入休眠的标志其作用和原理后续会详细介绍 RTOS休眠原理
RTOS的休眠机制基本都是配合CPU的休眠模式使用的。这个模式会关闭CPU、高速时钟和大部分外设关闭前会保存外设的上下文。此时SRAM保持在电保留休眠前CPU的运行状态因此在唤醒时可以立即恢复运行不会有很大的延迟。
休眠检测机制 RTOS在上电初始化时会默认建立一个名为IDLE的TASK优先级为0也就是说这个task只在RTOS不运行其它task时才会被调度到。休眠相关处理就在IDLE TASK中被执行。RTOS在IDLE TASK中会检测模组的外设是否正在使用网络是否有数据等休眠条件等满足休眠条件且autosleep使能时控制模组进入休眠模式。
休眠机制 RTOS的休眠一般也会指令CPU进入睡眠模式此时高速时钟将会关闭外设会在保存上下文后断电ARM的内核会停止运行但NVIC中断控制器和SRAM仍可保持运行任意中断都可将内核唤醒。
唤醒机制 任意中断均可将内核唤醒唤醒后内核立即恢复运行高速时钟恢复输出为断电的外设恢复上下文最后恢复应用程序的运行。这种休眠-唤醒模式不仅实现了功耗的降低还能较快恢复应用程序的运行。
休眠流程图例 不同的RTOS可能实现休眠的逻辑不同但原理基本类似 典型耗流特征 蜂窝通信模组休眠
Quecpython支持的蜂窝通信模组要进入休眠需要先使能休眠模式。不使能休眠模式时模组空闲时默认处于IDLE状态。
根据前一章节可知模块空闲时保持IDLE状态还是进入休眠状态完全取决于是否使能autosleep。换言之模块空闲时进入休眠时没有任何硬性阻碍而是完全由用户控制。那么为什么不选择默认进入休眠呢
原因是某些外设需要一直刷新如LCD。然而当模组休眠时这些外设便不能连续工作而是不断进行掉电-恢复的过程严重降低了外设的刷新效率和响应速度。同时由于休眠时采用低速时钟任何依赖高速时钟的设备即使不掉电也无法正常工作。故而模组空闲时会默认保持在IDLE状态维持所有设备的正常工作。
Autosleep机制
autosleep本质上是操作RTOS休眠检测机制中的一个flag不使能autosleep时模组的检测机制就会指令模组保持在IDLE状态。autosleep被使能时检测机制才认为模组处于允许休眠的状态从而进入休眠的逻辑。
使用方法参见自动休眠模式控制
休眠锁机制
在某些场景下我们既要使模组能够进入休眠又需要在特定代码段保护某些外设的正常工作这时我们就要引入休眠锁机制。
休眠锁本质上也是一个flag允许创建多个。生效机制是只要有任意一个休眠锁处于lock状态模组就不会进入休眠。
使用方法参见创建wake_lock锁
影响蜂窝通信模组休眠的因素
底电流
影响底电流的功耗的原因主要是系统的主频、打开的IP核的功耗这块和PMIC 相关。 底电流的影响因素主要来源于硬件包括模组本身和外设两部分 模组本身的耗流因素主要包括系统主频、打开的IP核。 外设耗电部分外设使用模组PMIC进行供电此时其耗流就会由模组负担。
一般来说测量底电流时需要将网络置为CFUN0使射频停止工作此时测试出的电流即为模组底电流正常情况下其特征一般近似直线如下图 DRX 周期Paging
基站寻呼paging当网络状态产生变化/需要对UE进行呼叫/ETWS或CMAS系统发送预警时基站会对模组发起寻呼通知处于IDLE状态的模组开始进行通信。
DRX周期模组网络在没有RRC连接的情况下会周期性的监听基站寻呼保证基站寻呼到来时能及时响应。这个监听的周期就叫做DRX周期。DRX周期一般有32ms、64ms、128ms几种DRX周期越短同样时间内监听基站信号的次数就越多功耗就越高但响应寻呼就更及时。反之DRX周期越长功耗越低但响应寻呼的速度越慢。
附上SleepCFUN1模式下耗流图图中规律性的凸起即为paging其周期即DRX周期 信号质量
信号质量差的时候在完成相同的网络行为时模组需要更大的发射功率。这会在两个场景下影响模组功耗 1.进行网络业务时耗流会上升除上文描述的发射功率外如果网络业务出现了因通信质量差导致的重连或重传整体的业务时间会被拉长导致整体耗流进一步上升。 2.模组休眠时每次寻呼的峰值耗流会上升导致整体休眠电流上升。
业务数据
模组在进行网络通信时射频和CPU都会工作从而产生较大的耗流。一般实际业务中不会一直进行业务数据传输常见的业务模式是心跳包。 由于在使用长连接时如果长期不进行通信可能会被对端认为已经离线从而断开连接。所以业务中一般会以固定周期向对端发送一包数据用来保活长连接。 各心跳周期下的耗流数据(LTE-FDD64)
ECX00UECX00GECX00MECX00EEC21BG955min2.16 mA2.13 mA1.32 mA4.41 mA5 mA10min1.84 mA1.76 mA1.03 mA3.39 mA4.43 mA
RRC 释放时间
无线资源控制Radio Resource ControlRRC又称为无线资源管理RRM或者无线资源分配RRA是包括呼叫准入控制、切换、功率控制、信道分配、分组调度、端到端QoS保障等各自独立的调配和管理算法。模组要进行业务时需要和基站建立RRC连接只有当RRC连接被释放时模组才能进入休眠。
但如下图所示这个RRC连接的生命周期中只有最开始数秒在进行真正的数据业务。从业务完成到RRC连接释放之间有一段耗流近似IDLE却无法休眠的时间这段耗流的形成和RRC的运营商策略有关 为了避免乒乓效应指网络状态反复切换的情况会导致更多的系统资源占用和网络性能下降基站并不会在网络业务完成后立即释放RRC连接而是会等待一段时间保证短时间内再次进行业务时无需重新建立RRC连接。RRC连接的时长会因网络环境和运营商策略而不同产生差别在没有网络数据而RRC未释放的条件下模组并不会进入休眠。因此RRC连接的时长会显著影响模组功耗。
休眠模式唤醒源
蜂窝通信模组进入休眠模式后有多种模式可以唤醒模组包括网络数据、电话、GPIO 中断、Timer等各种方式实际上都是通过中断来唤醒系统。
Soc 唤醒机制
模组的休眠状态可以由任意中断唤醒前提是有效的部分中断控制器处于功耗考虑也会被关闭唤醒后会在临界区中恢复设备上下文。此时中断控制器中存有此中断的标志但是不会运行。等待外设恢复完毕CPU会退出临界区此时中断的ISR会立即运行。
网络数据电话唤醒
网络数据电话基站通过paging通知模组有呼叫请求之后cp或DSP通过回调唤醒CPU并通知CPU有网络数据到来CPU开始将空口数据搬运进协议栈的buffer此时上层应用socket或电话可从协议栈中获取到网络数据。 GPIO 中断唤醒
GPIO可用的前提GPIO在模组休眠时保持供电且其连接的中断的控制器也未被关闭。 GPIO硬件被触发时其连接的中断控制器会立即响应并唤醒CPUCPU会将外设的上下文恢复然后退出临界区。此时ISR检测到GPIO的中断已经触发会立即执行GPIO的中断函数一般是发消息触发GPIO绑定的回调最后触发该GPIO绑定的回调函数。 timer 唤醒
Timer超时会触发系统定时器绑定的中断中断控制器会立即响应并唤醒CPUCPU会将外设的上下文恢复然后退出临界区。最后通过ISR触发timer绑定的回调。 唤醒源获取
实际上从上面三条可以看到凡是涉及到唤醒行为都要通过中断控制器进行这正是休眠模式的特征由任意中断唤醒。由此我们可以得出结论不需要刻意去获取唤醒源唤醒行为必然对应着特定中断的触发。
唤醒后业务处理
上一条已经做出结论不需要刻意去获取唤醒源唤醒行为必然对应着特定中断的触发。那么业务处理的原则也就很简单了模组出休眠逻辑中设备的上下文恢复后退出临界区唤醒中断的ISR就会立即去执行我们需要的业务逻辑直接由此触发即可一般都是采用在ISR发送消息或者信号量来触发对应业务的执行。
弱信号休眠方案
模组在网络未连接时会主动搜索网络并尝试连接。这种机制保证了模组能以最快速度附着到网络但也会带来一个功耗问题当模组所在地信号弱或者无网络时模组会一直进行搜网此时无法进入休眠且射频功耗也较高。
对此问题的解决方案有以下两个:
1.OOSOut of service机制在模组开机/服务中断/射频从关闭状态切换到打开时会尝试驻留小区。如果网络质量较好模组驻留到当前小区如果网络质量不好模组可能驻留失败。 除此之外驻留小区在射频条件不佳的情况下会造成下行失步从而模组执行重新驻留。 OoS 算法定义了模组尝试重新驻留的时间如果未能驻留成功则模组会进入睡眠状态睡眠一定时间后再次尝试进行网络驻留。通常的OSS机制随着尝试网络驻留的次数增加休眠时间也会相应增长增加到上限就不会再增加了按最大的睡眠时间往复尝试。例如
第一阶段睡眠30s,尝试驻留到小区重复10次
第二阶段睡眠45s,尝试驻留到小区重复10次
第三阶段睡眠60s,尝试驻留到小区从此依次往复此过程。
模组的的OOS机制一般会尝试多次后才停止且该时间段内射频一直处于工作状态相较于正常网络环境该机制可能会产生更多的的耗流。
2.在业务中自行执行退避和重连的流程。在一定时间内网络未连接时可手动停止搜网如指令模组进入飞行模式等需要重连时恢复全功能模式即可实际上就是业务中可自行控制时间和处理逻辑的退避模式代码示例如下
import net
import checkNet %%
def check_net_status():stage, state checkNet.waitNetworkReady(30)if stage 3 and state 1:print(Network connection successful.)elsenet.setModemFun(4)def reconnect():net.setModemFun(1)Copy
典型应用
网络例程网络主动发送心跳包模块接收寻呼唤醒
#利用MQTT来实现心跳包和接受寻呼
from umqtt import MQTTClient
import utime
import net
import sim
import sms
import _thread
import gc
import pmsub_path /a1A5W32fexl/test2/user/Text
pub_path /a1A5W32fexl/test2/user/Text
state 0
a 0
global cdef sub_cb(topic, msg):global stateprint(subscribe recv:)print(topic, msg)def err_cb(err):print(thread err:)print(err)def wait_msg():global cwhile True:try:c.wait_msg()except OSError as e:print(wait_msg thread err: %s%str(e))breakglobal c
c MQTTClient(client_ida1A5W32fexl.test2|securemode2,signmethodhmacsha256,timestamp1675836667378|,servera1A5W32fexl.iot-as-mqtt.cn-shanghai.aliyuncs.com,port1883,usertest2a1A5W32fexl,passworda5882fb77108cbd93f1413a403b31ed06d0c0e97c0ebca4b0b2f8dffe286da77,sslFalse,keepalive600) #keepaliveMQTT的保活机制此处为每10min发送一次心跳包
c.error_register_cb(err_cb)
c.set_callback(sub_cb)
print(set_callback)
pm.autosleep(1)#打开休眠模式
c.connect()#连接MQTT本质上建立TCP长连接
print(connect)print(MQTT is connecting)
c.subscribe(sub_path)
print(Connected to mq.tongxinmao.com, subscribed to %s % sub_path)
c.publish(pub_path, bhello)
print(Publish topic: %s, msg: hello % pub_path)_thread.start_new_thread(wait_msg, ())#监听MQTT,等待数据到来本质上就是等待寻呼低功耗无需做特殊处理心跳包发送、接收时会自动唤醒模组 硬件例程1GPIO/keypad 等外部硬件中断唤醒
import pm
pm.autosleep(1)#开启休眠# 创建ExtInt对象
from machine import ExtInt
def fun(args):f open(/usr/log.txt, a) #以追加模式打开一个文件低功耗时无法连接交互口在文件中保存调试信息f.write(### interrupt {} ###.format(args)) # args[0]:gpio号 args[1]:上升沿或下降沿写入文件f.close()#关闭文件保存写入信息extint ExtInt(ExtInt.GPIO1, ExtInt.IRQ_FALLING, ExtInt.PULL_PU, fun)#给GPIO1绑定回调fuctionextint.enable()#使能GPIO中断#进入低功耗后测试触发GPIO1然后连接USB查看文件是否写入了正确信息。
#若文件中写入了正确的信息说明低功耗模式下GPIO中断有效唤醒了模组并且执行了其绑定的中断。硬件例程2UART唤醒和接收 运行本例程需要通过串口线连接开发板的 MAIN 口和PC在PC上通过串口工具
打开 MAIN 口并向该端口发送数据即可看到 PC 发送过来的消息。import _thread
import utime
import pm
from machine import UART
将主串口接到串口小板上连接到PC* 参数1端口注选择主串口所有平台的主串口都支持低功耗唤醒机制其它串口具有不确定性UART2 – MAIN PORT* 参数2波特率* 参数3data bits 5~8* 参数4Parity 0NONE 1EVEN 2ODD* 参数5stop bits 1~2* 参数6flow control 0: FC_NONE 1FC_HW
class Example_uart(object):def __init__(self, noUART.UART2, bate115200, data_bits8, parity0, stop_bits1, flow_control0):self.uart UART(no, bate, data_bits, parity, stop_bits, flow_control)self.uart.set_callback(self.callback)def callback(self, para):if(0 para[0]):self.uart.write(UART WAKRUP!)#在串口RX回调中发送特定数据 def uartWrite(self, msg):self.uart.write(msg)def uartRead(self, len):msg self.uart.read(len)utf8_msg msg.decode()return utf8_msgif __name__ __main__:uart_test Example_uart()pm.autosleep(1)# 进入低功耗后向主串口发送数据如果返回了UART WAKRUP!则串口唤醒低功耗成功并执行了发送
# 注部分平台会丢一包数据 硬件例程3利用功耗锁在休眠唤醒时保护硬件时序和状态
from machine import SPI
import utime
import pmspi_obj SPI(0, 0, 1)if __name__ __main__:pm.autosleep(1)lpm_fd pm.create_wakelock(test, len(test))#创建功耗锁保护SPI读写pm.wakelock_lock(lpm_fd) #功耗锁上锁开始spi读写r_data bytearray(5) # 创建接收数据的buffdata bworld # 测试数据ret spi_obj.write_read(r_data, data, 5) # 写入数据并接收spi_log.info(r_data)pm.wakelock_unlock(lpm_fd)#释放功耗锁允许在SPI不进行读写时进入低功耗 常见问题
1.无法正常进入休眠:排查唤醒源
常见唤醒源备注功耗锁任一把锁未释放都无法休眠需要全部释放UARTUART有数据时不可休眠USBUSB插入不可休眠ThreadThread运行时不会进入IDLE无法休眠SPISPI有数据时无法休眠LVGLLVGL会不断刷新休眠时应使LVGL先进入sleep
2.正常进入休眠后底电流高检测硬件和网络环境需要检查的部分包括
耗流源备注PWMPWM控制器可在休眠时使用低速时钟进行输出GPIOGPIO休眠时能够保持对外输出需要检查是否漏电VDD_EXT常开电源休眠时需要检查漏电
3.网络环境导致功耗高
影响因素备注射频功耗检查paging时耗流峰值和网络质量RRC周期检查业务完成到RRC链接释放的时间
PSM 模式
什么是PSM 模式
PSM模式是一种比休眠模式功耗更低的低功耗模式其硬件原理就是模组关机RTC闹钟唤醒。与关机RTC闹钟唤醒相比PSM模式有以下两点不同
1.RTC闹钟的唤醒时间由网络下发。
2.进入PSM模式时模组虽然关机但核心网仍然保留其注网信息。因此PSM唤醒时无需重新进行网络附着联网速度更快且功耗更低。
PSM模式是在UE空闲一定时间后关闭信号的收发以及AS层相关功能这相当于部分关闭降低了天线、射频、信令处理等功耗。
PSM模式的优点是可以长时间睡眠但缺点是无法及时应对终端接收移动终端、MT服务。主要应用在远程抄表和一些对实时性要求不高的场景中。
PSM 模式原理
PSM是一种比常规休眠功耗功耗更低的模式但其运行需要网络侧支持。
启用PSM时需要先向基站发送请求通过ATTACH或TA_UPDATER携带定时器信息。基站若支持进入PSM则会在对应的REQUEST中下发定时器信息需要注意的是实际PSM的参数会使用基站下发的值并不一定和我们请求的值相同。
模组会以基站下发的值来配置定时器时间当模组进入IDLE且ACT定时器超时模组会关闭CPU和一切射频此时相当于部分关机只是保留了比关机更多的唤醒源一般包括ACT、TAU定时器和PSM_INT。功耗一般下降到微安级别。此时由于基站已经记录UE使用PSM不会断开此UE的连接下次如果在同一小区内重新开机就无需拨号直接用原有的IP等信息进一步减少了功耗。
当PSM TAU定时器超时、RTC_alarm到期或PSM_INT等唤醒源被触发时模组会被唤醒。由于硬件上CPU包括SRAM和PA均被下电此时并不能恢复休眠前运行状态而是要重新走开机流程。开机后可进行网络业务网络业务完成且RRC被释放后ACT定时器编开始计时超时便进入PSM中。
整体流程如下 最终在两个定时器的作用下模组会进行周期性的休眠唤醒切换但只有在唤醒的时候才能进行网络业务休眠时是无法响应网络寻呼的。
耗流特征如下(本示例每1min唤醒一次) ACT和TAU定时器#
ACT又称T3324当模组完成网络业务即RRC连接释放时开始计时超时后立即进入PSM。
TAU又称T3412当模组完成网络业务即RRC连接释放时开始计时超时后若模组在PSM模式会将模组唤醒。
它们的时序关系如下图 模组收到基站下发的PSM时间后会立即启动一个RTC闹钟和一个Timer。RTC闹钟是PSM模式的唤醒源超时时间就是T3412的值也就是说经过T3412时间后模组会被RTC唤醒进入下一个周期。Timer的超时时间是T3324只有其超时后模组才可能进入PSM模式即RTC闹钟将模组唤醒后模组会保持运行的时间为T3324。
由此可见要想模组能正常进入PSMT3324必须小于T3412否则便会出现RTC闹钟已经超时模组仍无法进入PSM模式的情况。
PSM RTC 模式下的功耗以及各平台支持情况#
ECX00UECX00GECX00MECX00EBG95PSM15 uA15 uA不支持5uA5.10 uARTC关机33 uA15 uA38 uA5uA(非关机hibernate休眠模式)14.87 uA
PSM 唤醒源
PSM_INT
PSM_INT是唤醒PSM的引脚此引脚一般都引出自PMIC。PSM_INT的功能是固化的不需要额外的配置进入PSM休眠后按照指定方式触发即可唤醒模组。
但对于ECx00E系列模组没有专门的PSM_INT而是由wakeup引脚实现此功能wakeup引脚需要在休眠前进行配置。
RTC 闹钟
RTC闹钟能将模块从PSM模式下唤醒。其使用方法与模块关机时RTC闹钟的使用方法相同。
参见RTC相关API说明
Powerkey
Powerkey也能唤醒PSM模式作用原理和触发开机一致。
TAU Timer
上文描述过TAU定时器超时会唤醒模组。 注意BG95 的TAU Timer 和RTC alarm复用了同一个PMIC唤醒源因此PSM和RTC不能同时使用 PSM 典型应用
PSM功耗虽低但有以下缺点
1.PSM启动时需要走重启逻辑应用恢复时间远远长于autosleep
2.产生小区切换时无法拿到原有的网络信息导致出现掉网和重新注网问题反而会使耗流上升
3.PSM休眠时不响应寻呼
所以PSM的应用场景一般满足以下三个条件
1.定时任务间隔较长可忽略启动时间
2.较少进行移动不会频繁切换小区
3.对数据实时性要求不高
示例代码
import utime
import pm
from machine import RTC
from misc import Power
import checkNetdef Business_code_example(run_time):i 0for i in range(run_time): print(Business app running)#Business code here utime.sleep(1)return def psm_try_set():if pm.get_psm_time()[0] 1:#开机时获取psm是否设置如果已经使能则无需再次进行设置print(PSM has been enable, set pass)return 0else:return pm.set_psm_time(0,1,0,1)#T341210min T33241mindef psm_failed_handle(delay_time):utime.sleep(delay_time)#等待指定时长后若模组仍未进入PSM模式才会往下运行。此处执行PSM失败的处理逻辑即代之以关机RTC关机闹钟rtc RTC()tm_rtc_tuple rtc.datetime()tm_rtc_second utime.mktime((tm_rtc_tuple[0], tm_rtc_tuple[1], tm_rtc_tuple[2], tm_rtc_tuple[4], tm_rtc_tuple[5], tm_rtc_tuple[6], 0, 0))alarm_second tm_rtc_second 600#RTC闹钟设为当前时间 10minalarm_tuple utime.localtime(alarm_second)rtc.set_alarm([alarm_tuple[0], alarm_tuple[1], alarm_tuple[2], alarm_tuple[6], alarm_tuple[3], alarm_tuple[4], alarm_tuple[5], 0])rtc.enable_alarm(1)Power.powerDown()if __name__ __main__:psm_failed_delay_time 60 30 #PSM的 T3324超时30S后启用错误处理逻辑lpm_fd pm.create_wakelock(psm_lock, len(psm_lock)) #申请功耗锁stage, state checkNet.waitNetworkReady(30)if stage 3 and state 1:print(Network connection successful.)psm_try_set() #网络连接成功时尝试设置PSM如果PSM设置已经生效则不用再次设置else:print(Network connection failed.)psm_failed_delay_time 1 #PSM依赖网络无网络时应立即使用RTC代替之pm.wakelock_lock(lpm_fd)#锁定功耗锁防止业务运行过程中出现sleep时错误进入PSM模式Business_code_example(10)#业务代码运行 pm.wakelock_unlock(lpm_fd)#业务运行完成后释放功耗锁。模组空闲状态且T3324超时后自动进入PSMpsm_failed_handle(psm_failed_delay_time)#运行错误处理若模组能正常进入PSM在sleep中就进入PSM了该处实际的处理逻辑并不会运行点此在github中下载完整代码
如何进入PSM
需要在联网且确认运营商支持PSM的前提下使用。根据业务需求决定ACT和TAU的周期通过API设置即可
参见PSM相关API说明
PSM_INT 应用
EC600U和BG95支持此引脚上升沿触发进入PSM时模组PMIC会默认配置此引脚确保触发方式正确即可在PSM模式下唤醒模组。 ECX00E系列模组使用wakeup引脚需要额外进行配置 弱信号PSM 方案
弱信号下PSM实际并不能保证生效因为和基站的东西实际上未必能够正常建立更罔论请求与下发TAU和ATC定时器是否正常。 此时我们可以主动在业务中的解决同行方案是设定一个最大尝试联网的时间若超过这个时间且网络仍未能正常连接转而使用关机RTC alarm来实现方案。
不支持PSM 的运营商的方案
如果运营商不支持PSM基站会设法阻碍模组进入PSM。常见的行为有三种
在模组向基站请求定时器时直接REJECT请求(此情况很少绝大部分为后两种)。下发不成对的ACT和TAU定时器不成对的定时器无法使模组进入PSM。不下发定时器
此时只能通过RTC闹钟定时唤醒关机来实现类似的业务需求这种方式也能达到在无需数据交互时减少耗流。但从关机状态重新开机相比PSM多了一个注网和拨号的动作在每次唤醒注网时都会产生更多射频功耗。 此外ECX00E系列模组在不支持PSM时需要通过pm.forcehib()方法强制进入hibernate休眠因为此平台关机时RTC无法维持运行。 常见问题排查
1.PSM设置返回True但无法进入
基站可能不支持PSM确认这一点的方法是从CPlog中查看基站下发的信息需要查看的条目为
ATTACH_REQUEST
ATTACH_ACCEPT
TA_UPDATE_REQUEST
TA_UPDATE_ACCEPT
如图模组设置成功后REQUEST一定会带有成对的定时器信息我们需要关注ACCEPT中基站是否正确下发了定时器信息。 如图网络环境不支持PSM基站未下发成对的定时器只下发了一个ACT定时器这时候是不能进入PSM的 2.PSM成功进入但休眠-唤醒周期与设置的不同
同样的查看以上CPlog条目基站下发的定时器周期可能不等于设置的值且模组最终以基站下发的值为准。
常见应用场景
对讲机低功耗方案
RRC快速释放对讲机的网络业务是不固定的随机触发的。快速释放RRC能够保证在任何一个随机时间点都能在对讲后快速释放RRC从而进入休眠。
业务上将周期性任务的时间周期尽量统一或均为某个最小周期的整数倍。在单次唤醒中处理尽量多的周期性任务心跳包、呼吸灯、定位等。若周期性任务时间不统一唤醒次数会增加同一周期内休眠的时间占比会下降。如果唤醒太频繁甚至无法进入休眠。
tracker 低功耗方案
RRC快速释放tracker是一个定位器位置是不固定的定期进行一次定位。可使用RRC快速释放减少RRC连接保持的时长从而降低整体耗流。
表计、门磁低功耗方案
PSM此类产品的唤醒间隔较长且一般不会经常移动对数据的实时性要求不高可采用PSM。若需要在无网络或运营商不支持的情况下使用可采用关机RTC闹钟定时唤醒的方案。
根据功耗需求选型
uA级耗流必须选择支持PSM或关机RTC唤醒的型号
mA级耗流全平台支持autosleep根据其它需求评估适合型号
待机时间推算方法
1.首先确定电池选型得到电池容量。
2.确定模组选型根据规格书和实际业务计算平均待机电流。如果需要准确的待机电流应保持整机按照业务流程运行然后使用功耗仪测试出平均待机电流。
3.从待机时间的计算公式待机时间 电池容量/ 平均待机电流
例如已知电池容量800mah给ECX00E系列模组供电。ECX00E系列模组在autosleep模式下保持网络连接LTE-FDD64时平均待机电流约0.64mA。
则实际待机时间T800mah/0.64mA1250h
耗流测试指导
耗流测试概述
有多种方法可以测量模组消耗的电流。首选方法通常是使用专用功率分析仪。功率分析仪通常能够根据电流大小自动切换电流测量范围采样频率和精度也较高。可以精确测量电流并记录具有大动态范围的电流消耗。
除了功率分析仪外也可以用电流表来测试模组耗流但电流表的范围并不能动态变化故难以记录动态范围较大的模组耗流。
需要注意的是若要测试准确的模组电流需要尽量排除外围电路的影响最好将模组电源直连到功耗仪上。
耗流测试前的准备
首先将功耗分析仪的电压调整到待测设备的额定电压注意这一步必须先进行防止给待测设备输入过高电压导致损坏将功耗分析仪的输出和GND连接到待测设备的输入引脚上对蜂窝通信模组而言供电引脚一般称为VBAT部分模组有两路独立的VBAT 分为VBAT_RF和VBAT_BB都要连接到功耗分析仪上。
对于上图的耗流待测设备而言模组供电来自于红框内的VBAT底板上其它器件的供电来自于底板DC电源或USB因此VBAT的耗流就完全是模组功耗。
检测耗流测试环境
在进行耗流测试前我们应检测耗流测试的健全性。用已知功耗符合标准的待测设备接入当前测试环境并测试耗流。 将此时获取的结果和标准耗流进行对比若数据与标准相符合则本测试环境是符合要求的可以进行功耗测试。反之需要排除影响耗流检测结果的因素。
测量关机耗流
待测设备硬件连接完毕后不进行开机断开USB_VBus即可直接测量关机电流。此时模组不工作对外的输出引脚也全部拉低或悬空整体平均耗流保持相对稳定基本都在uA级。 测量模组休眠电流
完成关机电流测量后长按powerkey开机模组开机默认的功耗模式是IDLE我们需要调用休眠相关的接口让模组在空闲时进入休眠操作方法参见autosleep相关API说明。设置完休眠后注意断开USBUSB连接时模组无法进入休眠。
进入休眠模式后模组应有的耗流波形会有周期稳定的凸起这就是上文所述的DRX周期如下图 因为单个DRX周期的功耗具有一定随机性此时模组平均耗流的计算应选取数个完整的DRX周期取平均值。如上图即是选取了三个完整周期算出此时休眠的平均耗流。功率分析仪一般提供了特定时间段内平均耗流的计算功能选取数个DRX周期即可。
测量开机时模组的底电流
完成联网情况下耗流测试后重新连接USB指令模组将射频关闭接口见此处net - 网络工作模式配置 。配置完成后断开USB观察耗流此时模组空闲且射频被关闭所耗的电流是模组休眠时可达的最低水平这时候的电流一般可称之为底电流 底电流近似一条稳定直线选取一段平均电流即可。
测量PSM电流
测量PSM耗流之前我们要设置PSM模式并检测是否生效应用方法和检测PSM是否生效的方法可参照前文[PSM模式章节](#PSM 模式)。
确认能正常进入PSM休眠后断开USB我们开始测试。等待ACT定时器超时后我们可查看PSM休眠下的底电流。 如图可见PSM的底电流远低于普通的autosleep模式和关机耗流的大小、特征较为相似。
PSM会定期被TAU定时器唤醒完成网络交互所以会有一个周期和TAU相符的耗流尖峰 同样PSM平均耗流需要取多个周期计算平均值
常见的耗流源以及排查思路
软件和硬件的设计失误均会导致模组耗流无法达到预期水准以下介绍一些常见的唤醒或耗流源以及对应的排查思路。
1.代码运行
在任何线程中代码运行必然会导致模组定期唤醒此时的耗流特征为底电流符合要求但不能一直保持休眠。如果代码持续运行或两次运行的间隔时间过短模组就无法进入休眠。
import utimewhile 1:print(Cant sleep!)#软件耗流源例1死循环任何线程出现死循环时无法进入休眠utime.sleep(1)#任务运行的间隔足够长时,在两次运行的间隔可以进入休眠但任务再次运行时模组将被唤醒排查思路分解业务逻辑逐个关闭运行的代码块当出现某一块逻辑关闭后耗流恢复预期。则可定位此处逻辑是否有异常唤醒。
2.定时器 定时器包括osTimer、RTC和硬件定时器超时都会唤醒模组此时的耗流特征为底电流符合要求但不能一直保持休眠。如果两次超时时间过短模组会无法进入休眠。
import osTimerdef test_cb(arg):print(Will wakeup!!)
# 创建os定时器
timer osTimer()#软件耗流源例2定时器定时器超时会唤醒模组
# 启动循环定时器未停止就会一直定期唤醒
timer.start(10000,1,test_cb) 排查思路分解业务逻辑逐个关闭定时器当出现某一个定时器耗流恢复预期。则可定位此处定时器是否有异常唤醒。
3.外设通信 外设通信包括SPI、串口和I2C等。这些外设通信需要高速时钟的保障因此通信时无法休眠。此时的耗流特征为底电流符合预期但不能一直保持休眠唤醒行为和外设是否来数据有关。
排查思路 1.关闭外设通信寻找是哪一路通信引发的模组功耗异常。 2.排查对端与模组通信的时间和频率是否符合需求。 3.如果对端发送不可控制而模组又需求进入休眠可在休眠前关闭响应的外设不接收对端的数据。
4.休眠锁 休眠锁会直接锁定RTOS状态使之在模组空闲且使能过休眠的情况下仍保持在IDLE而非进入sleep。此时无法进入休眠模组空闲时耗流特征和模组IDLE耗流对应。
排查思路 模组日志中一般可见休眠锁阻止休眠的条目可通过日志分析是否有休眠锁未释放。
5.硬件漏电 在实际应用中常出现某电压域漏电的情况。对整机而言任何电压域产生漏电例如不经电阻接地、电压域内元件异常耗电等就会引起整体耗流上升。此时的耗流特征为底电流不符合预期但开启和关闭休眠能观察到明显的耗流变化即模组能正常进入休眠但底电流不符合预期。
排查思路 1.对于模组IO能够控制的电压域根据实际情况做拉高或拉低处理原则是将电压域的电源切断。对于切断后耗流下降显著的电压域进行排查检查是否有对地漏电或元器件异常耗流。
2.对于模组无法控制的电压域可在硬件上做断开处理对于切断后耗流下降显著的电压域进行排查检查是否有对地漏电或元器件异常耗流。 常见的耗流器件 LCD背光和驱动芯片均有耗流如果LCD持续刷新还会导致模组无法进入休眠休眠时LCD应停止刷新并熄屏 上拉电路没有电阻或二极管进行扼流时上拉电路对低电平会产生较大漏电 电平转换芯片部分电平转换芯片输入阻抗较低漏电流较高。 audio 功放电路漏电流较高不用时应关闭 触摸芯片耗流较高进入休眠时可指令触摸芯片进入低功耗或直接关闭 PHY网卡耗流较高进入休眠时应控制网卡进入低功耗但为了保持网络连接此设备不能关闭
