Should we keep LED off during LoRa transmission?

[IoTThinks]

Some friends have discovered voltage drop much more when we turn on LED just before a TX.
The power consumption is minimal but the power spike is high.

It may impact the TX power of a LoRa transmission.

This happens in all modes and in main power / battery.

Should we off the LED before a TX?

If we want to keep the LED, then I suggest to keep the LED on/off atfer TX done.

In RAK4631, there is no LED code which is good.

What do you think?

[gjelsoe]

Kind of like the LED when transmitting.
But could it be as a user configurable option :

• Before TX
• After TX
• During TX
• OFF

[IoTThinks]

@gjelsoe Correct.
Need to delete and cleanup for child esp32 boards.
Child esp32 boards have overriden the same methods.

Then we can make improvement to the led to be configurable or less impact to TX power.

[gjelsoe]

Thinknode M5 is a bit different

  void onBeforeTransmit() override {
    expander.digitalWrite(EXP_PIN_LED, HIGH);   // turn TX LED on
  }
  void onAfterTransmit() override {
    expander.digitalWrite(EXP_PIN_LED, LOW);   // turn TX LED off
  }

But should be possible to make...

[IoTThinks]

@gjelsoe Yah these few boards can override the on off functions.

[kbrantley]

Thinking out loud a bit, what about the following for a runtime option?

powersaving led [rx|tx|both] [enable|disable]

Honestly I don't care that much about configuring the behavior for rx/tx; I'm actually 100% okay with:

powersaving led [enable|disable]

... but I can also see the value in being able to configure it independently for troubleshooting.

[IoTThinks]

Let me see.
on/off will be shorter than enable/disable.

The hard part is the cleanup all duplicated LED on/off at child ESP32 boards.
Let me check if the TX and RX quality is better if LED is off since the power save is minimal.

[gjelsoe]

Something like

enum class TxLedMode {
  FLASH_DURING_TX,
  FLASH_BEFORE_TX,
  FLASH_AFTER_TX,
  FLASH_OFF
};

class ESP32Board : public mesh::MainBoard {
protected:
  uint8_t startup_reason;
  bool inhibit_sleep = false;
  TxLedMode led_mode = TxLedMode::FLASH_DURING_TX;  // Default

  virtual void ledOn()  {
  #if defined(P_LORA_TX_LED)
    digitalWrite(P_LORA_TX_LED, HIGH);
  #elif defined(P_LORA_TX_NEOPIXEL_LED)
    neopixelWrite(P_LORA_TX_NEOPIXEL_LED, NEOPIXEL_BRIGHTNESS, NEOPIXEL_BRIGHTNESS, NEOPIXEL_BRIGHTNESS);
  #endif
  }

  virtual void ledOff() {
  #if defined(P_LORA_TX_LED)
    digitalWrite(P_LORA_TX_LED, LOW);
  #elif defined(P_LORA_TX_NEOPIXEL_LED)
    neopixelWrite(P_LORA_TX_NEOPIXEL_LED, 0, 0, 0);
  #endif
  }

  void handleLed(bool is_before) {
    switch (led_mode) {
      case TxLedMode::FLASH_DURING_TX:
        is_before ? ledOn() : ledOff();
        break;
      case TxLedMode::FLASH_BEFORE_TX:
        if (is_before) { ledOn(); delay(50); ledOff(); }
        break;
      case TxLedMode::FLASH_AFTER_TX:
        if (!is_before) { ledOn(); delay(50); ledOff(); }
        break;
      case TxLedMode::FLASH_OFF:
        break;
    }
  }

public:

#if defined(P_LORA_TX_LED) || defined(P_LORA_TX_NEOPIXEL_LED)
  void onBeforeTransmit() override { handleLed(true);  }
  void onAfterTransmit()  override { handleLed(false); }
#endif
};

And for ThinkNode M5 it would be

class ThinknodeM5Board : public ESP32Board {
protected:
  void ledOn()  override { expander.digitalWrite(EXP_PIN_LED, HIGH); }
  void ledOff() override { expander.digitalWrite(EXP_PIN_LED, LOW);  }

public:
  void begin() {
    led_mode = TxLedMode::ON_DURING_TX;
    ESP32Board::begin();
  }
};

Then onBeforeTransmit() and onAfterTransmit() would still be useable for other functions.

Untested AI Slob code :)

[IoTThinks]

Ok, need human to revise the code. :)

[neopiccolorat]

The blue led on the wismesh tag is going a bit crazy when we're not connected to it via bluetooth.
Even without any activity. It blinks more than when we're connected.

For devices like these, I would like to see either a way to deactivated/control the led activity (for battery saving purpose), and reduce their activity during regular transmissions (lora and bluetooth).

[IoTThinks]

Yes, I agree.
We should have a control to on/off battery saving mode for companion.