电池寿命计算器
ULE设备电池寿命计算
概述
与(DECT)无绳电话(待机和通话时间分别以天/小时为单位)不同，ULE设备的生命周期以年为单位。因此，测量这些寿命是不切实际的，因此通过计算来预测它们是必要的。为了计算寿命，我们需要收集以下信息:
- 器件电流耗尽或电荷耗尽，适用于各种休眠等交流活动:数据事务、音频、心跳(Keep Alive)
- 用例，即设备从休眠中唤醒的频率和(DECT-ULE)通信(和非通信)活动
- 使用什么电池，然后对其做一些假设能力在应用中
DECT-ULE通信运行方式及其消耗
以下信息是根据我们的详细测量电池续航时间：
- 冬眠-电池供电的ULE器件通常在此模式下花费>99%的寿命，消耗1.7µ因此，此处的占空比有效为100%。交流供电设备通常不处于休眠状态，它们消耗~7mA
- 分页-许多ULE设备很少会被中心分页-只有当它们醒来并发送Keep Alive(“心跳”)或报告事件(例如，警报，温度)时才会被中心分页。然而，有些设备必须在短时间内提供(如警笛、门锁、音频设备)。此类设备必须以很短的时间间隔唤醒，并检查来自集线器的传入页面。每次这样的唤醒成本约75µC(当使用DHX101时)。因此，对于1.28s的最大延迟，该活动将使平均电流增加65µa。通常，对于可分页设备，这些唤醒构成了最大的电荷消耗。
- 保持生机(“心跳”)—虽然ULE协议不要求设备以任何特定的时间间隔向集中性“签入”，但系统设计者喜欢从系统中的设备获得定期反馈。每笔Keep Alive交易花费约2mC(总交易时间约100mS)。这，以每小时一次(典型)的速度，该活动将贡献24*2/86400 = 0.5µa -在大多数情况下可以忽略不计。
- 集线器应用程序没有响应的32字节数据事务这是用于发送简单警报或事件报告的典型事务。成本(和交易时间)与Keep Alive相同- 2mC (100mS)。这包括消息的发送和来自Hub的消息已收到的确认
- 需要从集线器应用程序响应的32字节数据事务在大多数情况下，设备在发送数据包后不会保持活动状态——一旦它收到数据包成功传递的确认，它就可以返回休眠状态。上面提到的关于Keep Alive和Data的2mC已经说明了这个简单的确认。但是，如果Device应用程序希望从Hub应用程序获得进一步的指令，那么它必须保持1秒左右的清醒状态才能获得此响应。例如，一个ON-OFF开关可能需要等待，直到集线器确认目标设备已经接收到这条指令-然后闪烁一个LED作为确认!这里的成本约为12mC
- 音频连接-这是“电路模式”操作，每10mS帧有一个Tx和一个Rx插槽。所涉及的消耗很大程度上取决于设备到集线器的距离。在我们的计算中，我们假设音频连接激活时的标称平均电流为45mA。注意，这只说明了通信链接活动。如果扬声器连接到DHAN/DHX91 SPK输出进行免提操作，这将大大增加(20-40mA)在这种模式下的平均电流。这个“增量”应该添加到“非ule”消费者预算中
- 非ule消费者预算除了ULE SOC (DHX91)进行的ULE通信活动外，ULE设备还包括传感器、外部mcu、led和其他部分(或全部)处于活动状态的电路。他们对平均值的贡献应该计算/测量
通信用例细节和电池容量
下面输入用例详细信息和电池类型/容量。几种常见电池类型的电池容量可以使用下拉菜单选择:AAA, AA, CR2, CR123, 2xCR2032(并联)。容量估算假设有效电池续航时间降至2V(此时ULE SOC运行不能保证)，且设备在室温下运行。如果这两个假设中的任何一个不正确(即应用程序中有另一个设备不能容忍低至2V的电源或操作温度远低于室温)，则应在“其他”字段中输入较低的容量。
