Prevent ESP32 shutting down before transmission

[DylanGWork]

Hi,

I have been attempting to use this function: bit_t os_queryTimeCriticalJobs(ostime_t time);

No matter how I've used it it's never returned a True, is this because the library halts other processes before transmission or am I using this function wrong?

I have been finding I need to use VtaskDelay before going to sleep or I risk messages not being sent, this function seems like a perfect solution.

I have also attempted to use vTaskSuspend on the sendmessages function and vTaskResume when required during certain states, it's worked for 1-2 messages but then failed to transmit while still running through the same outputs (EV_TXSTART etc that happens on successful transmits).

I'm attempting to get more efficient with my code but having a few setbacks when it comes to optimising sleep cycles while maintaining a reliable network.

Any recommendations on how I can better manage detecting whether the lorawan message has finished transmitting so I can shutdown ASAP?

Cheers, Dylan

[cyberman54]

This is my code, not used with the ttn-esp32 library, but with native LMIC, so it should work as a workaround here, too.

// wait until LMIC is idle

  ESP_LOGI(TAG, "Waiting until LMIC is idle...");
  for (i = 100; i > 0; i--) {
    if ((LMIC.opmode & OP_TXRXPEND) ||
        os_queryTimeCriticalJobs(sec2osticks(wakeup_sec)))
      vTaskDelay(pdMS_TO_TICKS(1000));
    else
      break;
  } 

[manuelbl]

My plan is to offer easy-to-use deep sleep once the underlying library supports it. Unfortunately, LMIC still doesn't really support it even though it's high on the priority list there. And I'm not aware of any other suitable library that I could easily integrate.

Accessing any LMIC functions directly is dangerous, even as a workaround. Since the library mostly runs in a separate RTOS task, results are likely inconsistent.

I haven't looked into the details yet. So I can't give you any details about the behavior you are seeing. As a workaround, I would recommend to wait for 7s from the time a message has been submitted until you go to sleep. This is based on the general mechanics of LORA and the current TTN v3 settings: When you submit a message, it takes some time to transmit the message. After the transmission has ended, there are windows during which the device has to listen for incoming messages. One starts 1s after the transmission, the other one starts 5s after the transmission (current TTN v3 settings). So overall, the device needs to be awake for about 7s.

[cyberman54]

7 secs is too short, if the device receives MAC commands in the RX window, and responds to them (e.g. ADR).

[DylanGWork]

Hi all,

Thanks for the replies.

I managed to get this version working for the deepsleep cycles using a small fix which seems to have made it stable (It's been working for a few weeks now).

I believe your spot on with the different RTOS tasks running for the library as I have the vTaskList at several point in my code (but not anywhere in the LMIC library) and the tasks listed are exactly the same between working and non-working instances. I believe there must be a task that is running in a time that I am not checking.

I have removed the need to pause and unpause the lorawan library for now, however it could be useful in the future to address edge cases.

[BryanMM]

@DylanGWork Hi, may i ask if you did some tests about the power consumption of your device while its sleeping? Thanks.

[manuelbl]

Despite the missing support in the underlying LMIC library, I've added support for going into deep sleep and for powering off the ESP32 while retaining the state of the current TTN session.

It should considerably simplify these use cases. It takes care of all the details like when can the device go to sleep (if MAC commands need confirmation), what needs to be saved, handling the clock (very important) etc.

Any feedback is appreciated.

[BryanMM]

@manuelbl I managed to use those functionalities to go into deep sleep and back to normal operation mode, but i noticed that the deep sleep current consumption is quite high (1.8mA), so I'm trying to find out other user's findings about that consumption, to check if i did something wrong or not.

[manuelbl]

I will do some power consumption tests in the next few days and will report them back here.

What was the setup you have measured? Does it include the LoRa chip and/or voltage regulator and/or BMS chip and/or USB-to-UART bridge?

[BryanMM]

I'm currently using a wireless stick lite from heltec. It has the usb serial chip and the sx1276 modem from what i recall.

[DylanGWork]

Great work! Coincidentally I will be performing a lot of power consumption tests on my firmware/hardware over the next few weeks. Good timing for this addition, I'll test it extensively over the next week or so :) My hardware setup is the LoRa1276 module being connected to the VCC line with regulator that allegedly has 60nA quiescent current. We want to switch to a CC68 or 1262 depending on circumstance at some stage, but that's a whole different line of work!

[DylanGWork]

I've finally gotten around to testing power consumption in deep sleep.

I am getting about 55uA while in full deep sleep including putting the lora module to sleep while connected to VCC, so I'd say it's working a treat. Cheers!