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