LMIC, sleeping and duty cycle

[SmartNOOB]

Hello,

I’m running a BSfrance 32u4 node which sends a message every 10 minutes. After TX_COMPLETE, the device is put to sleep and wakes up triggered by a RTC module. It joines on SF11 and thus gets strong duty cycle limitations by LMIC. It takes about one minute after waking up to send the packet. It seems that this problem occurs because the LMIC timer does not run while sleeping.

I ensure that the device does not exceed the duty cycle limitations and I want to increase the interval after finishing testing. The device is battery powered and thus I don’t want it to idle before sending. Is there a way to tell LMIC to ignore the duty cycle?

[Couin]

First, make sure you use latest LMIC library.

I have already seen this problem somewhere :
https://www.thethingsnetwork.org/forum/t/lmic-plus-rfm95w-staying-awake-for-long-periods/7506/10

It seems here is one solution (see discussion in topic) :

@Charles

timer0_overflow_count+= 8 * 64 * clockCyclesPerMicrosecond();

Same thought here :

@aschroeder

After reading the linked infos I added
extern volatile unsigned long timer0_overflow_count;
to my sketch and after the deep sleep I inserted
timer0_overflow_count += 3E6;
Thats it! timer0_overflow_count comes from wiring.c in the arduino core and is used for micros().

[SmartNOOB]

Thanks. Now it works as expected

[Couin]

@SmartNOOB

Thanks. Now it works as expected

Are you still using SF11? How far your node is from gateway?

[SmartNOOB]

It is this node: https://ttnmon.meis.space/console/#device-46-2.7.2018-9.7.2018-eui-0004a30b002330f8

Last time it joined on SF 9. Maybe the current location (a few centimers difference) allows a better connection. Looking on TTNmon I found out that my node is currently sending minutely. Obviously the EEPROM was overwritten after flashing. I hope my Downlink configuration is received soon…

[Couin]

@SmartNOOB

https://ttnmon.meis.space/console/#

Is this your node with an external RTC?
I’m interested how much energy economy is made that way.

[SmartNOOB]

Yes, it is. It still consumes a lot of power in sleep. It is about 900uA, which means that it will only run 40-50 days if not sending: https://robin.meis.space/2018/04/20/a-low-power-node-for-ttnmon-using-avr/

There might be a solution by cutting of the RTCs power during sleep but I’m not sure if the interrupt signal is still issued if the RTC is running on its internal battery. AVRs are in my opinion the wrong platform for LoRa Nodes. It is better to use a controller with an internal RTC. They also have more storage and additional features which might become interesting for IoT applications.

I built a custom PCB based on an ESP32 which consumes about 60uA during sleep. It is still in testing and the software has to be improved but it works pretty good. The board is also much smaller and can be put inside a standard junction box and a cable passthrough for the antenna.

[Couin]

@SmartNOOB

Yes, it is. It still consumes a lot of power in sleep. It is about 900uA, which means that it will only run 40-50 days if not sending: https://robin.meis.space/2018/04/20/a-low-power-node-for-ttnmon-using-avr/

It’s strange, I get around 170µA using a sketch based on the one above (supplier says 300µA in deep sleep).

@brianbramer

#include “LowPower.h”

LowPower library is working fine. Using internal watchdog add around 5µA consumption.
Having an external RTC will give you much more accurate timing.
Moreover, on LoRa32u4 there’s an internal “VBat/2” bridge divider plugged on ADC12 (D9).

In the end, LoRa32u4 is still a “big” development board, your 60µA ESP32 board is a nice and more compact alternative.

[SmartNOOB]

My ESP32 board also has a voltage divider to measure the battery voltage and shutdown in case of low power. I think the high power consumption of my 32u4 Board is because of the RTC which is permanently connected to the battery instead of running on its own coin cell.