This gives more data than I can cope with so I haven’t come to any particularly conclusions except that 100mA LiPo battery on a simple device seems sufficient even in the UK and the deployed devices with that size battery work OK unless foliage get in the way. In some instances this replacement may occur well before end of battery life.įor solar, test nodes have an INA3221 on them so we can measure the solar output, the flow in or out of the battery and the device usage. I’ve not yet had a mass deployment reach end of battery life but no one is talking to me about changing the batteries as the cost of many of the devices is sufficiently low they are adding new features and so the old device will be replaced with new one rather than have it’s batteries changed. It only takes a few minutes on the bench with a variable power supply & a multimeter to determine lowest operational voltage for purchased devices. So generally device status once a day, for battery it’s a single byte scaled over the working range (1.8 to 1.4 in the example above) to give some level of over-accuracy. I’m trying to factor in some consideration of usage based on the message count.įor deployed devices I schedule different payloads on different ports depending on use case / requirements.
I transmit battery V with each test device payload with a couple of decimal places and I’ve got several algorithms looking for the blip at the half way point and then the beginning of the end where the reported voltage is about to drop off a cliff. I generally deploy with Energizer Lithium batteries - they have a long shelf life, that is they self-discharge slower than the node uses them and are less temperature sensitive - so won’t freeze (not an issue in the UK, global warming is real). And for some devices, you’d like a whole lot of other information too. And then we have a situation where until more network servers support this functionality, they won’t include it. I’m not sure the detail on what was expected to put in to the battery level value was overly considered as it is rather generic - as you say, the chemistry and the devices usage will all massively vary so I suspect it’s up to the manufacturer of the device to decide based on what it is and what they recommend for power. In the meanwhile, you’ll need to add it to your payload and process it yourself.īut the measurement of battery value is rather vital to many of our nodes so hopefully it will be incorporated in to v3 at some stage. I don’t know if it is in v3, someone else may know.
#MAC BATTERY INDICATOR SOFTWARE#
But my main question is whether 0% (or 1 in the MAC byte) is generally meant to be “the battery is completely drained” or “the battery is now at the lowest point that it can support normal operation of the device”? I realize that a device with a “completely drained battery” can’t even send this message, but if “completely drained” is the intended meaning of 0% (1), then it essentially means that the end user must just “know” what battery percentage is the “lowest operational value” for every difference device (of course, the software can be configured for this, too).īattery level - http integration LoRaWAN End-Device Status says not implemented and I’ve not seen it anywhere and I think TTN are working on v3 rather than changes to the current stack. So my question is what is typically being measured here? Of course there are many ways to measure remaining battery life, often highly dependent on the battery chemistry being used. I could find nothing in the LoRaWAN specs that define the meaning in any more detail. It’s generally up to the hardware/firmware of a given device to decide what value to write into this “register”.
The LoRaWAN MAC Battery Level reporting capability reports battery level as a value from 1 to 254, which is typically “scaled” to 0-100% for use in device management displays. So be it, but I’m curious to know what has been done. I get the feeling that the answer to this question is “it’s up to the hardware manufacturer”.
0 kommentar(er)
