Deep Sleep and Battery Consumption.

[jcaron]

@hm97 said in Deep Sleep and Battery Consumption.:

@rcolistete said in Deep Sleep and Battery Consumption.:
''There is a cycle delay in the sensor data sent, so 2nd LoRaWan package uses data sent in #1 cycle.''

can this explain why I am having a relatively high airtime? The first reading I sent to TTN gives me an airtime of about 103ms while all the following readings give me an airtime of ~413.7ms. So when you said the LoRaWAN package uses data sent in #1 cycle is that to say that it is sending more data in the subsequent readings and thus takes more airtime?

What @rcolistete means is that if you use the method they gave, then there's always an offset of one sleep cycle between data collection and sending it: each time you send the data you collected during the previous cycle. This allows you to run data collection in parallel to the RX windows delays: when you send data over LoRaWAN, the device always waits at least 1 second, then listens for a downlink in RX1, then waits another second, then listens for a downlink in RX2. So that always takes at least 2 seconds (unless you receive a downlink in RX1).

With the traditional get data-then-send method, your total awake time is time to boot + time to get data + time to send-and-wait-for-RX. With the parallel method, the total awake time is time to boot + max(time to get data, time to send-and-wait-for-RX). If time to get data is significant, as is the case for some sensors, this can save quite a bit of awake time on each cycle. The drawback is that you get the data one cycle later.

[hm97]

@jcaron

I'm not sure I follow. The TTN rules are actually stricter than the EU rules (EU rules say you are allowed 1% airtime, so that's 864 seconds per day).

Then in that case I will just go with the limiting factor.

However the airtime goes up with the frame size, and deep sleep is pretty much useless and probably counterproductive at that rate, you can forget running on battery.

This is important for me. I don't quite understand why the airtime is going up. I tested yesterday, setting my Data rate as 3 in the socket options (SF9 / 125 kHz). However, looking at the metadata from TTN, the first sensor value that got sent actually used the set data rate and the airtime was 103ms. The subsequent messages had an airtime of 413.7ms and used SF11. Why does the frame size go up after the first message? and why is it changing my data rate after the first message?

deep sleep is pretty much useless and probably counterproductive at that rate, you can forget running on battery.

I am planning on running this on battery soon. Do you think it will last at least a week with an interval of one message per 20mins. I think the time it is active is about 10 seconds from boot up after deep-sleep until it records and goes back to sleep.

Isn't the data rate/SF shown in TTN logs?

Yes, it is, upon looking more carefully, the metadata does show this info thanks.

[hm97]

@jcaron I see, Thanks @rcolistete. I'm not entirely sure how I would implement this though so for now, I will stick with what I have but I will get back to this should I need to but this sounds quite useful.

[jcaron]

@hm97 I don't remember if the TTN logs show message size? I have a hard time reconciling SF9BW125 and 103 ms airtime.

There are two things that have an influence on airtime:

• The data rate (SF and BW)
• The amount of data sent

When you join, the network (TTN) can send various settings to the node to control which channels, data rates, etc. are used. Some are sent right away in the join answer, others are sent in MAC commands piggybacked to downlinks (which are themselves sent in response to uplinks).

So you can have:

• Join request
• Join accept -> some settings are sent to the node
• First uplink -> uses one SF
• Network replies with a downlink (empty data, only MAC commands) and changes more settings
• Second uplink -> uses different SF due to new settings

If ADR is enabled, it is also possible for the node to change settings spontaneously, so IIRC that takes quite a bit more time (and should go towards faster data rates unless frames get lost).

I don't quite reconcile the airtime values you get with those computed with TTN's airtime calculator, but the ratio seems indeed to be coherent.

At one message per 20 minutes with 10 seconds awake, counting 20 µA sleeping and 100 mA awake, you should get:

((20 * 60 - 10) * 0.02 + 10 * 100) / (20 * 60) = 0.85 mA average current.

To last a week, you need 0.85 * 24 * 7 = 142.8 mAh.

Pack a 2500 mAh battery and you should be quite safe :-)

Be sure to check the current during deep sleep. There have been quite a few cases where it was way more than 20 µA (more like several mA), and that would kill your battery life completely.

Add monitoring of the battery voltage. It's quite crude, but it will give you a rough idea of where you stand.

[hm97]

@jcaron

Be sure to check the current during deep sleep. There have been quite a few cases where it was way more than 20 µA (more like several mA), and that would kill your battery life completely.

yes I have seen some of these posts and I have an odd feeling I might find my system dying too quickly but how do i check the current during deep sleep? do you mean using an ammeter? Unfortunately I don't have access to that currently.

I will setup a function that returns the battery voltage. Do I need to do anything on the hardware side before it can read the voltage to me? or is it all just in the code? (don't want to accidentally mess up my system, I have almost no experience with circuitry)

[hm97]

@jcaron sorry i could not edit my previous post but just to add, the LoPy4 datasheet indicates under their power consumption section (section 10) that the deep sleep power consumption under 5V (not sure what the voltage entails) is 19.5mA which is very high and the LoRa Transmit is 105mA. I'm not sure if this power consumption they are talking about is the same one we are talking about but was just confused when I saw that.

https://docs.pycom.io/gitbook/assets/specsheets/Pycom_002_Specsheets_LoPy4_v2.pdf

[jcaron]

@hm97 That's a typo. It should be µA, not mA (for deep sleep). Though as I wrote earlier, you need to check it, there have been instanced where it did end up being mA.

LoRa transmit depends on TX power settings and a few other things, but the device is not transmitting the whole time its awake, just when it's actually sending the frame (the airtime, from a few ms to a few seconds depending on frame size, SF, BW). It's also listening for a short time during the RX1 and RX2 windows.

The usual power profile during the awake period is something like:

• boot, takes 1-2 seconds, very irregular with quite a few spikes.
• data collection, depends on lot on what you are doing
• LoRA TX, >100 mA for the duration of transmit
• idle waiting for RX1, about 30 mA, 1 second (unless the network says more)
• RX1, short spike at 40 mA or so
• idle waiting for RX2, about 30 mA, 1 second

Overall, the average during awake time is probably around 50 mA or so, but it can vary quite a bit depending on various parameters (mostly TX duration). 100 mA average is probably a worst case.

Again, measuring your power profile during a cycle is strongly recommended. Measuring deep sleep current just requires a multimeter and a resistor. Measuring the active cycle requires a bit more hardware, but if you don't have the budget, even something very cheap like this can reveal a wealth of information.

Nordic recently announced their new power profiler, I wonder if it's usable for any device or if there any sort of coupling with their own.

[hm97]

@jcaron said in Deep Sleep and Battery Consumption.:

Overall, the average during awake time is probably around 50 mA or so, but it can vary quite a bit depending on various parameters (mostly TX duration). 100 mA average is probably a worst case.

so is that 100mA for the whole awake time or 100mA for just the LoRa TX transmit period? because in your breakdown you also have current draw during RX1 and RX2? do I add this to the 100mA?

[jcaron]

@hm97 current is like a speed, it’s a an instantaneous value which varies up or down over time, and you can average it. So you get a curve that varies during the whole awake time between 30 and over 100 mA.

You can then integrate this (multiply each value by the time the current stays at that value) to get mAh (or mAs or anything that is amperes x time), which is what is important when it comes to battery capacity. If current is a speed, this would be the distance travelled, or the length of wire out of spool. This one can only increase over time.

It’s like the difference between power (measured in W) and energy (measured in Wh or more commonly kWh). The only difference here is the voltage factor. If you have a 1000 W heater that runs for 8 hours, then it will have used 8000 Wh (8 kWh).

[hm97]

@jcaron

So you get a curve that varies during the whole awake time between 30 and over 100 mA.

Ah I see. I think I confused myself when I saw the LoRa transmit in the documentation of 105mA and thought it was somehow the overall current draw of the awake time because it was similar to the 100mA you had mentioned before but I get it now. So the current draw is about 100mA (conservative) on average over the awake time.

You've been a really great help. Thanks for all your patience :)