HopeRF RFM95 - SX1276 - does not sleep

[clavisound]

Hello there.

first time user of RadioLib, so maybe I am doing something wrong.

To my understanding, RadioLib does not put to sleep the HopeRF RFM95 SX1276 module. After transmitting, I have 2mA of current from the HopeRF. ATmega is on Deep Sleep.

I defined all the pins NS/CSS, IRQ/DIO0, RST, DIO1.

[StevenCellist]

Well... there's radio.sleep().

[tomtor]

This is interesting.

I have some experience with rfm95 low power configuration: https://www.thethingsnetwork.org/forum/t/hope-rfm95-98-power-usage-in-sleep-mode/6269/19 and LMIC.

I use my own deep sleep routines.

Today I did some experiments with LMIC on my AVR128DB28 RFM95W board: https://github.com/tomtor/STM32-RFM95-PCB/blob/master/AVR128DBLora/AVR128DBLora.ino

And with radiolib: https://github.com/tomtor/STM32-RFM95-PCB/blob/master/AVR128_RadioLib/AVR128_RadioLib.ino on the same hardware.

LMIC uses 2uA and RadioLib 140uA while in the same deep sleep routine.

The radio.sleep() call works, because without it power usage is over 1mA.

I spend already quite some time on it, but have not found the cause yet (some port pins must be left in a different state), but I intend to do. That's part of the fun.

@jgromes Nice library!

[StevenCellist]

140uA of current feels like CS/NSS may not be pulled strong enough? Bit of a guess but somewhat aligns with troubles I've had using Heltec boards and their weird examples.

[tomtor]

CS/NSS measures 3.3V when sleeping, it is really weird.
The power consumption is constant, even in POWER_DOWN sleep mode.

[HeadBoffin]

CS is a low signal, so off is high. I get ~2uA on the STM32WL and similar on a deep sleeping ESP32 so it's not a RL issue as such, more likely just finding the magic words!

[tomtor]

I found the issue, adding before the sleep:

pinModeFast(PIN_PD4, INPUT);

results in a 2uA sleep current. PIN_D4 is the unused DIO2_PIN.
It is specified in LMIC, but cannot be given as Module parameter in RadioLib.

That's not a real issue, the user just has to configure the pin as input without pullup if DIO2 is connected to a pin on the controller.

[jgromes]

@clavisound generally, RadioLib does not do anything you don't tell it to. The reason is that the library does not know what your use case is. It probably makes sense for you to put the module to sleep. For other users, it might not because their usage is not constrainted by power, but needs the radio to react quickly.

Since this is not really an issue, I will move this thread to discussions.

[jgromes]

I don't see a reason in LoRaWAN world why someone will prefer standby vs sleep

You have not mentioned this is about LoRaWAN - RadioLib has a lot more use cases than that. And even for LoRaWAN, we prefere to leave as much control as possible up to the user.

What if i submit a PR with #define DEFAULT_TO_SLEEP?

I don't think that's a good idea. Just more build-time configuration for the user to be aware of without much gained IMO. What is preventing you from calling sleep from your code?

[clavisound]

Ok, fair enough. User code probably would be fine. Some μS and bytes of 'bloat' 😛 .

[HeadBoffin]

Some μS and bytes of 'bloat'

The code has to go somewhere so it's not uS or bloat and this way the developer has control.

Or write a patch that you apply to each release. Or fork if. Or keep up the work on SlimLoRa.

[clavisound]

@HeadBoffin I thought the joke about 'bloat' was clear with the smiley and the '' (quotes).

One instruction vs two is not "has to go somewhere". One jump in AVR is 4 bytes more flash space. The developer has many ways to have control. Via #define as I already proposed or via code external of library as jgromes wants (I wrote: Ok fair enough), or via patch (ugly) of fork (again ugly). You can also do it the Apple way: construct your own chip along with the software. But why we are getting philosophical?

I prefer to join forces, not to disintegrate. I am trying to help with fun, not to criticize.

Yes, I will continue to develop SlimLoRa* because it needs 10kB of flash vs 60kBytes of RadioLib. I have some devices with 32kBytes of flash, I am sure other peoples do. It's a great starting point. Just recently it also works with 500Khz μCU.

* I don't get why you reference SlimLoRa in this discussion. To my knowledge is the first time we encounter. I don't sell anything to steal costumers from RadioLib and I don't bash RadioLib or the developers. This is like ad hominem discussion. (to be fair: ad library)

Have a nice day, if you want to help with SlimLoRa you are welcome, it's very simple code :)

[HeadBoffin]

It wasn't a smiley and language is open to interpretation ...

This is like ad hominem discussion

"directed against a person rather than the position they are maintaining"

So not even a little bit, or against a library. Think language, think global internet. I genuinely hope you continue working on SlimLoRa because I know many people need a small MCU stack but as you are here, it looked for a moment that you may have dropped interest in SlimLoRa. Maybe language got in the way of the message?