LoRaWAN node.downlink() / node.uplink() not more supported? (saving energy for ESP32)

[michapr]

Hi,

I only now have seen (after building new solar/battery powered sensors) that the seperate downlink / uplink functions in LoRaWANNode Class not available more?
As I have show using the ESP32 can be saved much energy for sensors (up to 35% if 6 sendings/hour (!!) ) if splitting this process and using light sleep while waiting for Rx window.
#964
you told there: ;)

that's why there is a separation possible from sendReceive() into uplink() and downlink()!

Is there now another method available to "split" this procedure?

[StevenCellist]

This split is indeed not available anymore. Implementing retransmissions for ADR to prevent an avalanche of downlinks in challenging environments meant that the split was not possible anymore.
As discussed in #1377, we have plans to bring this back in some shape or form, but at the moment we are tied up in other projects that must pay for food. You are most welcome to try out the solution presented in one of the comments there and see if that works (please report back if it does!). Otherwise maybe stick to your old version and check every now and then if there's no weird behaviour, or practice a few weeks / couple months of patience.

[michapr]

@StevenCellist looks like a great idea!
I have at first modified the ArduinoHal::delay - then thought about that this maybe not the best place.
So I have modified the LoRaWAN.cpp and have replaced the delay() calls with new lrDelay() function.

The result is really good, will show when finished (or tomorrow ;) ...).

Have seen one problem in this time, in very rare cases the device is hanging - looks like before the Rx-Window.
Have made a change, enabled debug, and waiting for next issue ...

This is what I have done:

void LoRaWANNode::lrDelay(uint32_t ms) {
//  vTaskDelay(ms / portTICK_PERIOD_MS);
  if(ms <= 50) {
    vTaskDelay(ms / portTICK_PERIOD_MS);
 } else {
    uint64_t start = millis();
	esp_sleep_disable_wakeup_source(ESP_SLEEP_WAKEUP_ALL);
	esp_sleep_enable_timer_wakeup((ms-2)*(uint64_t)1000);
	esp_light_sleep_start();
    if(millis() < start + ms) {
      vTaskDelay((start + ms - millis())/portTICK_PERIOD_MS);  // if there's still some time left, do normal delay for remainder
    }
  }
}

If this works, the sleep function could be moved to the user configuration and allow optional hardware-specific customization there.

[michapr]

All is working as expected - perfect.... !
Device is running since 20 hours about with some hundred deep sleep and subsequent transmission of values.
All the time without problems using the new delay procedure.

Here are the results:
Without new delay procedure (current solution):

With new lrdelay:

calculating the energy use (without additional sensor, including deep sleep current) we can get a great saving of energy:

(Tested with Heltec WSL V3 device and sleeping sketch compiled with 80MHz, powered from BAT input - without attached sensor)

It is the best solution I have seen - would be nice to realize it in next release, maybe outside the library for user defined solutions if special hardware.

(BTW: the "issue" above: The problem was in front of the computer - an error in the code :)) )

[jgromes]

@michapr this will only override the method ArduinoHal::delay in RadioLib ArduinoHal class. Any other calls to Arduino delay function are unaffected.

What I meant (sorry if that was confusing) is that within RadioLib, delays are used in places other than LoRaWAN. Sometimes for quite brief durations, but they are still there. With what I proposed above, all calls in RadioLib to Hal::delay will now use that user-provided method. Your implementation would actually work well with that, since it does not attempt sleeping below 50 ms.

But I don't see any real advantage in this over a separate lrDelay() function

The primary advantage is that your lrDelay() will not compile without FreeRTOS and is specific to ESP32. The solution I proposed gives the user the flexibility to define whatever sleep mechanism they desire. For you, it will be the contents of lrDelay. For someone using STM32, some STM32 sleep mode.

[michapr]

@jgromes - ok, I have understood it in principle ;)

The solution I proposed gives the user the flexibility to define whatever sleep mechanism they desire. For you, it will be the contents of lrDelay. For someone using STM32, some STM32 sleep mode.

You are right, I also thought more about a construct inside the lrDelay where user can insert instead of the ESP32 specific light_sleep the own sleep mechanism. Or can insert a switch like #if defined(ESP32) etc.
So same idea I think ;)

Your solution is probably the better one from the point of view of an experienced programmer - I'm more of an amateur in this respect ;)

[HeadBoffin]

For those that a mid-way between amateur and @jgromes / @StevenCellist, can we make the delay a weak thingy so we can override its whatsit in the user code??

[jgromes]

@HeadBoffin weak linkage is a very C thing. In object-oriented C++ we have (runtime) polymorphism, in this case overriding as demonstrated above. But I do agree it can look intimidating, especially for people unfamiliar with OOP, that's why I proposed to add a more straight-forward way for the users to do this.

I imagine it as a method void LoRaWANNode::setSleepFunction(sleep_func_cb_t func); that the users could call to set their own sleep function, in this case it would look like node.setSleepFunction(lrDelay);. Then, if the user did this, we would call this function in LoRaWAN in some cases (e.g. Rx windows). If the user does not set it, we can just call the standard, platform-independent mod->hal->delay().

[HeadBoffin]

Continuing in a similar neophyte way, your polytunnel could have two functions signatures so that we can have delay(RadioLibTime_t ms, bool SleepIfFeasible) override OR make the parameter optional / have a default

That would leave the original delay intact and anywhere we want to drop in to a low power mode, we call it with the additional parameter. The code snippet above doesn't really have to be fully understood and with some appropriate #ifdef's can support a range of platforms.

I continue to mourn the loss of COBOL Ada for Embedded and rather than #ifdef's quite like the look of Zig if I could fine time To Learn Another Programming Language - most days is a hack fest of trying to remember what syntax I'm meant to type. Perhaps I'm getting too old for this after 46 years of pounding a keyboard.

[StevenCellist]

@michapr please save your sketch and setup - likely in a few days or week or so, there will be two additional improvements power-wise. It will be interesting to see how much effect that has on your setup & measurements.

[StevenCellist]

@michapr if you could update to the latest code on GitHub, please re-run your tests with the new sleepDelay function. I'm interested in the results!

[michapr]

@StevenCellist
Have just tried with same sketch, same device and settings - result: a bit better as before, nice !

Used in config.h :

void customDelay(RadioLibTime_t ms) {
  // this is just an example, so we use the Arduino delay() function,
  // but you can put your microcontroller to sleep here
  //::delay(ms);
  uint64_t start = millis();
	esp_sleep_disable_wakeup_source(ESP_SLEEP_WAKEUP_ALL);
	esp_sleep_enable_timer_wakeup((ms-2)*(uint64_t)1000);
	esp_light_sleep_start();
    if(millis() < start + ms) {
      vTaskDelay((start + ms - millis())/portTICK_PERIOD_MS);  // if there's still some time left, do normal delay for remainder
    }
}

BTW: Have updated my old solar sensor with new delay some days ago - and can see in battery usage that it is very effective!
(have used WiFi OTA update, activated by LoRaWAN scheduled uplink - a feature that is quite easy to realize with the ESP32 :)) ...)

[StevenCellist]

Hmm, not as much as I had expected, but a gain nonetheless :) good to see it's working well!

[michapr]

BTW: I have used the same device with same sketch (only other dev eui) with ChirpStack - results:

and at first transmissions after join:

Haven't changed any settings using SenseCAP M2 (Seed Technology) with integrated ChipStack Server.
Timings "interesting" for me....

[StevenCellist]

Chirpstack by default uses a 1sec Rx delay, but it looks like both those screenshots show a Chirpstack installation with a 3sec Rx delay (TTN uses a 5sec Rx delay). And you also see that Chirpstack uses SF12 for Rx2 window in the first screenshot given the very long receive period at the end.

[michapr]

Yes, right, in configuration can see 3sec Rx delay (cannot be changed in SenseCAP M2 Gateway). But why there is a different Rx2 window in some cases? Is this normal by LoRaWAN 1.1.0 spec? (I do not know, that's why asking ;) ...)

Anyway, the new delay function is working with other Rx delay also fine ;)
(only in the very long receive period in first picture not sure - sleep is here possible?)

[StevenCellist]

It's likely that your device received a downlink, e.g. for ADR. Then it doesn't need to open Rx2 :)