Current consumption

[geraldm]

Hi All,

An update.

I have managed to capture in time down to mS the entire LoRa AU915 cycle we need to achieve our goal.

Assuming, Deep Sleep, to wake, process DS18B20 Data, Process ADC Batt V data, idle, TX and back to deep sleep.

The attached are all the data points with deep sleep to receive starting at data point 571 and going back to deep sleep at 9288, this equates to 8.717 seconds total cycle.

This is the best we have achieved with optimised current with SF8.

I cannot load/attach the excel file, but can send as PM for review.

We are struggling to optimise and achieve any further gains/reduction, but if someone has an idea, please share, maybe a old stable version where boot time is significantly smaller which is critical in this case to conserve battery life.

Regards

Gerald

[jcaron]

@geraldm can you add a time stamp (time since boot is fine, with at least 0.1s precision, ideally ms) to your logs and provide the logs for one cycle? This would help determining exactly where the time is spent.

Also, your Send_Data thread is not very efficient, looping like that. Instead, just switch the loop to a single test that everything is ready, and call it at the end of the other processing threads. It shouldn’t change the total time much but it should use a bit less current.

[geraldm]

@jcaron

Shall add log in the morning. Hopefully that should help align a process with time.

OK on Send_Data thread efficiency, shall review and measure.

The data points are a good baseline to work with, any delta are hopefully gains.

Regards

Gerald

[jcaron]

@geraldm My guess is that the spike at 6 seconds is the LoRa TX, and the much smaller spikes at 7 and 8 are the RX1 and RX2 windows.

This would mean a lot of time is spent getting the data from the sensor. Also I wonder what all the tall but very narrow spikes between 4 and 8 seconds are. The time to go to sleep is puzzling. Timestamped logs will tell us more.

It's commented in your code, but I suppose you have run wifi_on_boot(false) at some point (and that likewise, pybytes is disabled)?

IIRC there have been dramatic variations in startup times between firmware versions, though I don't remember which versions are good or bad in that respect. There should be some discussion on the topic elsewhere in the forum.

[geraldm]

@jcaron said in Current consumption:

Also, your Send_Data thread is not very efficient, looping like that. Instead, just switch the loop to a single test that everything is ready, and call it at the end of the other processing threads.

Hi, I am not sure I fully understand Your comment on the in-efficient loop, s/w ignorance on my part?

Regards

Gerald

[jcaron]

@geraldm In your code, you have 4 threads running:

• one tries to get the temperature
• one tries to read battery levels
• one tries to setup LoRaWAN
• one tries to send the data

Each of the first three run until they have done their work and set a global with the result. The last one (Send_Data) is a while loop which continuously tests if all other threads have done their work (by testing the global variables set by each), and then sends the data. This means it hogs the CPU, which both increases power consumption and slows down the other threads (IIRC all threads run on the same core, only networking runs on the other core).

Instead of doing that:

• Change the Send_Data function to only do the test once (remove the while True:). If the test is successful, send data and go to deep sleep as it currently does. If not, just return (remove the _thread.exit() at the end).
• Do not start a thread with this function.
• At the end of each of the 3 other threads, after setting the global, call Send_Data. If any of the other threads hasn't finished working, it will do nothing. It all three threads have done their work, it will send the data.

An alternative would be to use some kind of lock, but I think this would be overkill here.

[rcolistete]

What about building a Pycom firmware with your modules, including main.py ? Or at least using .mpy files ?

The time to load modules is decreased a lot. See section "4.2. Tempo e RAM gastos para importar módulos" of "Using WiPy3" tutorial (but in portuguese, I need to create an english version...).

[geraldm]

@jcaron Thanks. Shall review with team in the morning. I understand. We have a good consumption baseline now, any gains will soon be realised.

Shall post results.

Regards

Gerald

[geraldm]

@rcolistete, thanks.

Will take a closer look. Need to translate. To help others too, English would help. I see the time to awake and sleep again a great to be a challenge to Pycom products.

I have one brand device I have dissected and tested, it’s complete cycle is barely 1.01 seconds. SF7BW127 with only 2 spikes of current worth noting for that duration. Also, newer processes have deep sleep down to 0.1 microamps, a significant factor delta to 25.4 microamps exhibited by LoPy L01.

Anyway we continue to innovate.

Regards

Gerald

[jcaron]

@geraldm As discussed in another thread, it's difficult to combine the flexibility of a high-level language like (micro)python on a device with 2 fast cores, Wi-Fi, BLE, and more with the optimisation available when programming in C (or even assembler) on a controller optimised for very low power applications. Different MCUs have different power profiles, performance, RAM/flash capabilities, sleep modes, etc.

A LoPy is probably overkill for most LoRa applications where you just get a few bits of data from a sensor or two and send them over LoRaWAN (the small PIC on the Pysense or Pytrack is probably more than enough for that!). But it enables you to quickly prototype things, and if you need to, you can do a lot more with it than you can in simpler LoRa devices.

Note that 1.01 seconds cannot be a complete cycle for a LoRaWAN-compliant device (unless it always receives a response in RX1 from the network). It is a requirement for the device to be awake during both RX1 and RX2 unless it received a downlink in RX1. And RX1 is at least 1 second after end of transmission, and RX2 is always 1 second later. RX2 is also quite a bit longer as it needs to accommodate the slower data rate of SF12.

But yes, with a carefully chosen MCU and optimised firmware, you can get down to just over 2 seconds at the fastest data rates, with most of it actually spent sleeping!

[geraldm]

@rcolistete, great news, early days.

We have built a firmware version resulting in a on and on air reduction from 8.92s to approx. 4.87s. Some cycles even down as low as 3s. The consumption profile changed to a point that we calculated a battery life from 2.1yrs to 4.6 years.

We came across many anomalies and errors, no single error was the deal breaker, it ended up being a week long research, try, load, research, try and load again and again. The results and time to current profile is consolidated.

I will try to load a graph soon.

Thank you everyone who contributed.