Heltec LoRaWAN ESP32 V3 - heltec_vbat() returns very low value even with a charged battery attached, and display is blank.

[peterbosch]

I have a Heltec LoRaWAN ESP32 V3. Definitely V3, that's printed near the antenna socket. [Edit: It's V3.2]

I have GND and one of the 3V3 pins connected to an Hc-sr501 Infrared PIR Motion Sensor and its output connected to GPIO_NUM_2. (Note - this works.) Nothing is connected to GPIO_0, 1 or 37 (Button and two VBat pins.)

When running the following code, nothing shows on the screen and heltec_vbat returns a very low - and inconsistent - value, like 0.04 to 0.25V.

Help?

#define HELTEC_POWER_BUTTON   // must be before "#include <heltec_unofficial.h>"
#include <heltec_unofficial.h>

// Configuration parameters
// Frequency in MHz. Keep the decimal point to designate float.
// Check your own rules and regulations to see what is legal where you are.
// #define FREQUENCY           866.3       // for Europe
#define FREQUENCY           905.2       // for US

// LoRa bandwidth. Keep the decimal point to designate float.
// Allowed values are 7.8, 10.4, 15.6, 20.8, 31.25, 41.7, 62.5, 125.0, 250.0 and 500.0 kHz.
#define BANDWIDTH           250.0

// Number from 5 to 12. Higher means slower but higher "processor gain",
// meaning (in nutshell) longer range and more robust against interference. 
#define SPREADING_FACTOR    9
// Transmit power in dBm. 0 dBm = 1 mW, enough for tabletop-testing. This value can be
// set anywhere between -9 dBm (0.125 mW) to 22 dBm (158 mW). Note that the maximum ERP
// (which is what your antenna maximally radiates) on the EU ISM band is 25 mW, and that
// transmissting without an antenna can damage your hardware.
#define TRANSMIT_POWER      5

#define PIR_PIN GPIO_NUM_2 // GPIO2 for PIR sensor interrupt

void enterDeepSleep() {
  // Configure EXT0 wake-up on GPIO2
  esp_sleep_enable_ext0_wakeup(PIR_PIN, 1); // Wake on HIGH signal

  // Display sleep message
  both.println("Entering deep sleep...");
  delay(1000); // Allow user to read the message
  display.displayOff();

  // Enter deep sleep
  esp_deep_sleep_start();
}

void setup() {
  Serial.begin(115200);
  delay(1000); // Allow Serial Monitor to initialize

  heltec_setup();
  heltec_ve(true);  // Ensure display brightness


  // Print the wake-up cause for debugging
  esp_sleep_wakeup_cause_t wakeup_reason = esp_sleep_get_wakeup_cause();
  Serial.print("Wake-up cause: ");
  Serial.println(wakeup_reason);

  RADIOLIB_OR_HALT(radio.begin());    // Set radio parameters
  both.printf("Frequency: %.2f MHz\n", FREQUENCY);
  RADIOLIB_OR_HALT(radio.setFrequency(FREQUENCY));
  both.printf("Bandwidth: %.1f kHz\n", BANDWIDTH);
  RADIOLIB_OR_HALT(radio.setBandwidth(BANDWIDTH));
  both.printf("Spreading Factor: %i\n", SPREADING_FACTOR);
  RADIOLIB_OR_HALT(radio.setSpreadingFactor(SPREADING_FACTOR));
  both.printf("TX power: %i dBm\n", TRANSMIT_POWER);
  RADIOLIB_OR_HALT(radio.setOutputPower(TRANSMIT_POWER));

  float vbat = heltec_vbat(); // Read battery voltage
  int batteryPercent = heltec_battery_percent(vbat);

  // Check if wake-up was caused by EXT0 (PIR sensor)
  if (wakeup_reason == ESP_SLEEP_WAKEUP_EXT0) {
    // Wake-up action: Handle motion detection

    String message = "Motion detected! \nBat: " + String(batteryPercent) + "%, " + String(vbat) + "V";
    both.println(message);

    RADIOLIB_OR_HALT(radio.transmit(message.c_str()));
    both.println("Message sent.");
  } else {
    both.printf("Cold boot.\n");
    both.printf("Vbat: %.2fV (%d%%)\n", vbat, batteryPercent);
  }

  display.display();
  // Enter deep sleep after setup or wake-up actions
  delay(1000);
  enterDeepSleep();
}

void loop() {
  heltec_loop();
  heltec_led(100);
  // This will never run as the ESP32 reboots after deep sleep
  both.println("Unexpected execution in loop()");
  delay(1000);
}

[mschorer]

Hey,

i ran into the exact same issue ... yesterday ... :

• VBAT: the VBAT_CTR polarity changed: HIGH enables routing vbat to the adc
• display power: the display's VCC is wired to VEXT - VEXT has to be enabled ...

The source of confusion - which also got me for a day - is that
the schematic named V3.2 Schematic diagram on the product site obviously is the 3.1 schematic.
The correct schematic is https://resource.heltec.cn/download/WiFi_LoRa_32_V3/WiFi_LoRa_32_V3.2_Schematic_Diagram.pdf from the Downloadable Resources.
Rop, you also got that wrong ...

So i changed heltec_unofficial.h:

...
float heltec_vbat() {
  pinMode(VBAT_CTRL, OUTPUT);
  digitalWrite(VBAT_CTRL, HIGH);
  delay(5);
  float vbat = analogRead(VBAT_ADC) / 238.7;
  // pulled up, no need to drive it
  pinMode(VBAT_CTRL, INPUT);
  return vbat;
}
...
void heltec_display_power(bool on) {
  #ifndef HELTEC_NO_DISPLAY_INSTANCE
    if (on) {
      #if defined(HELTEC_WIRELESS_STICK) || defined(HELTEC_V3FIX)
        // They hooked the display to "external" power, and didn't tell anyone
        heltec_ve(true);
        delay(5);
      #endif
      pinMode(RST_OLED, OUTPUT);
      digitalWrite(RST_OLED, HIGH);
      delay(1);
      digitalWrite(RST_OLED, LOW);
      delay(20);
      digitalWrite(RST_OLED, HIGH);
    } else {
      #if defined(HELTEC_WIRELESS_STICK) || defined(HELTEC_V3FIX)
        heltec_ve(false);
      #else
        display.displayOff();
      #endif
    }
  #endif
}
...

and add in my code:

#define HELTEC_V3FIX

[peterbosch]

Excellent - thank you, Markus. This battery issue is solved.

However, the display issue remains - your change moves heltec_ve(true); // Ensure display brightness from the 5th line of my void setup() code into the header file under HELTEC_V3FIX. This is arguably better, and I made the changes, but materially does not change what I'm doing. I would think that my device is faulty, except that when I unplug it from USB Power, the display briefly lights up, with the correct output for a detection, and then goes dark again. Some sort of voltage spike? While it's on USB Power, the display is still always dark.

I'll be looking at this more closely today. Also, I just got a new device in, and I'll try the same code on that device to see what happens.

I'll mark this "fixed" and create a new post for the display issue if the new device exhibits the same behavior.

Again, thanks!

[mschorer]

Hey,
@display: yes, the change does make a difference:
if you add it to the header, it ensures, that it's called before the display is inited etc ...

It will work "your way", if you also call the display setup functions explicitly after the display is powered:

    heltec_ve(true);
    display.init();
    display.setContrast(255);
    display.flipScreenVertically();

[peterbosch]

...and that's why I adopted your approach. :-)

Thanks for your help - it is much appreciated! Can I venmo you a cup of coffee?

[mschorer]

@venmo: Thanks for the offer - but i had to check what venmo is first ... no, thanks ... ;-)

You're welcome!