ESP32 Problems

(Maedman) #1

Hello guys!

I try to collect Data from a smart meter using an ESP32 with LoRa. To give the node a decent lifetime i wanted to use the deep sleep - but it actually is not working properly if you can believe the very very low powerconsumption in the data sheets.

If I power the ESP32 externally and measure the voltage via an oszilliscope, i get the following voltage on an shunt (2.3 Ohms, I will do it with some lower resistance later this week)
Every 4 secs the ESP32 is waking up due a external wake-up. After this, he reads the serial port, where the data from the smart meter is inserted. After reading the Data he is sending via LoRa and then he should go to sleep.

I hope I could make clear what I am trying to do :slight_smile:

Is there someone who can help me figuring out how to fix the deep sleep mode?

Thank you!!

Best regards,


what ESP32 with lora is that ?

(Maedman) #3

Its the WIFI LoRA 32 from Heltec (V1)


The Heltec and TTGO Wifi LoRa 32 boards were not designed for (very) low power usage. It is not only the microcontroller that plays a role here but also the onboard voltage regulator, battery charger, USB to serial, OLED display, LoRa chip and other components like LEDs and pullup/pulldown resistors. Therefore you will never reach as low (not even near) as the power consumption that is specified in the ESP32 datasheet for deep sleep, for the overal hardware configuration.

(Ultra) low power is a complex subject where many factors play a role and it starts with the hardware.

There are several articles available on the web about ESP32 and low power applications, but the overall hardware setup will allways play an essential role.

You will have to be more specific than “deep-sleep is not working properly”.

Do you mean that you are trying to measure the current usage of the Heltec board with oscilloscope by measuring the voltage on a series resistor (not shunt, a shunt is connected in parallel) connected between the 3.3V pin and an external 3.3V power supply?

(LoRaTracker) #5

Your sending data every 4 seconds with LoRa ?

(Maedman) #6

Thank you for your reply!
I know, that there might be some better options reguarding (ultra) low power designed boards, but I want to get the most out of my heltec esp32 board for now.
I dont use the OLED or internal pull up/downs. The LED is blinking, when powering with 5V externaly. If I power the board with 3.3V its still working, but the LED is not blinking anymore. The input power has no effekt on the current/ voltage I am measuring.

You where right, I conntected the current by using a series resistor connected between 3.3V and external 3.3C power supply.

To be more specific reguarding the deep-sleep problem:
Looking at the oscilloscope picture in my 1. post, the ~71mV is the current, that represents the sleep time. I expected the current is sleep mode is much lower as it is e.g. while sending via LoRa (last peak is sending via Lora). I can show you my code here, maybe you can understand that better :slight_smile:

(Maedman) #7

Yes, I am sending only the relevant information every 4 secounds at the moment. Due to the small data size I calculated, that there should be no problem with regulations in germany or even TTN Fair access policy :slight_smile:

(Maedman) #8

Here is the code, where I am only reading the data, sending via LoRa and going to sleep afterwards. I know, that there are no security aspects in sending yet, I will dive into that after fixing the power consumption.

#include <LoRa.h>
int  serIn;             // var that will hold the bytes-in read from the serialBuffer
byte datagram[1000];    // array that will hold the different bytes
int  serindex = 0;      // index of serInString[] in which to insert the next incoming byte
float trans[2];         // array for LoRa-Transmission
// Next 7 definitions: Reading information out of Data-Telegram
float global[15];
int a = 0;
int b = 0;
int c = 0;
int d = 0;
float kwh = 0;
float kw = 0;
// Pin definition of WIFI LoRa 32
// HelTec AutoMation 2017
#define SDA     4    // GPIO4  -- SX127x's SDA
#define SCK     5    // GPIO5  -- SX127x's SCK
#define SCL     15   // GPIO15 -- SX127X's SCL
#define MISO    19   // GPIO19 -- SX127x's MISO
#define MOSI    27   // GPIO27 -- SX127x's MOSI
#define SS      18   // GPIO18 -- SX127x's CS
#define RST     14   // GPIO14 -- SX127x's RESET
#define RST_LED 16   // GPIO16 -- OLED reset pin
#define LED     25   // GPIO25 -- LED Light pin
#define DI00    26   // GPIO26 -- SX127x's IRQ(Interrupt Request)

// LoRa parameters
#define BAND    868E6  // band
#define PABOOST true
int  serialbyte;        // Byte to store serial input data

void setup() {
  Serial2.begin(9600, SERIAL_8N1, 34, 35);
  SPI.begin(SCK, MISO, MOSI, SS);
  LoRa.setPins(SS, RST, DI00);
  while (!Serial2) {
  Serial.println("Serial available");

void loop() {
  while (Serial2.available()) {
    while (Serial2.available()) {
      serialbyte =; // Read Buffer to clear
    delay(10);  // wait approx 10 bytes at 9600 Baud to clear bytes in transmission
// assume, that there is now a pause. Wait for start of transmission
  int flashcount = 0;
  while (Serial2.available()) {    //captive portal hängt sich hier auf
    if (flashcount == 400) {
    else if (flashcount > 500) {
      flashcount = 0;
    else {
      delay(5);  // wait 5 ms for new packets
  // We got some bytes. read until next pause
    // Serial.println("Reading serial data");
    //Serial2.setTimeout(500);   // Set Timeout to 500ms.
  serindex = Serial2.readBytes(datagram, 1000);

  if (serindex > 0) {
    Serial.print("Datagram received. Total Bytes: "); Serial.println(serindex);
    switch (serindex) {
      case 187:
        kwh =   (0.0001 * (datagram[20] * 16777216 + datagram[21] * 65536 + datagram[22] * 256 + datagram[23] * 1 ));
        for (b = 0; b < 15; b++) {
          if (b < 14) {
            global[b] = global[b + 1];
        global[14] = (0.1 * (datagram[82] * 16777216 + datagram[83] * 65536 + datagram[84] * 256 + datagram[85] * 1 ));
      case 320:
        kwh =   (0.0001 * (datagram[153] * 16777216 + datagram[154] * 65536 + datagram[155] * 256 + datagram[156] * 1 ));

        for (b = 0; b < 15; b++) {
          if (b < 14) {
            global[b] = global[b + 1];
        global[14] = (0.1 * (datagram[215] * 16777216 + datagram[216] * 65536 + datagram[217] * 256 + datagram[218] * 1 ));

    kw = global[14];
    trans[1] = kwh;
    trans[2] = kw;
    LoRa.begin(BAND, PABOOST);  // Sending via Lora start
    LoRa.print("$"); LoRa.print(trans[1]); LoRa.println("$");
    LoRa.print("&"); LoRa.print(trans[2]); LoRa.println("&");
    LoRa.endPacket();           // Sending via LoRa end
    esp_sleep_pd_config(ESP_PD_DOMAIN_RTC_SLOW_MEM, ESP_PD_OPTION_OFF);
    esp_sleep_pd_config(ESP_PD_DOMAIN_RTC_FAST_MEM, ESP_PD_OPTION_OFF);
    //esp_sleep_pd_config(ESP_PD_DOMAIN_RTC_PERIPH, ESP_PD_OPTION_OFF);
    esp_sleep_enable_ext0_wakeup(GPIO_NUM_34, 0); // Definition of external wake-up via GPIO 34, low

(LoRaTracker) #9

A packet every 4 seconds seems an awful lot, how big are these packets and how many are you sending a day ?

Every 4 seconds suggests 21,600 packets a day ?

(Maedman) #10
LoRa.print("$"); LoRa.print(trans[1]); LoRa.println("$");
LoRa.print("&"); LoRa.print(trans[2]); LoRa.println("&");

I only want to transmit 2 integers (trans1 and trans2) divided by symbols. It should be 12 Bytes=96 Bits of data per transmission. I found a excel sheet in the forum, where I could calculate the Time on Air. With Bandwith = 500kHz, SF=7 and CR= 4/5 i measured the transmission time of 4,38ms.

Am I right, or is there a mistake in my cosiderations?

The 4 secounds represents a maximum that is given by the electrical meter. Due to the fact, that my power consuption is that high at the moment I will not manage to send every 4 secounds when powering with a battery. I am aiming at a lifetime arround 1 year with batteries with 2Ah, but at the moment I am only at arround 50 days, what it way to low.

(Jeff Uk) #11

Every 4sec would be WAY over the TTN FUP, even if you can managed to contain withing duty cycle regs (and just 'cause you can bang up against the regs does not mean you should!!! Look to use 1/10th of regs dc limits max, and pref <1/100th, if you wish to be socially responsible…also design for the fact others quite possibly wont be responsible :wink: ). WRT powering device have you considered scavenging from the supply you are monitoring? A suitably sized ragowski coil attached to one of the meter legs with appropriate voltage regulation and small back up battery/charging circuit for when consumption is very low?.. :slight_smile:

(Maedman) #12

Thank you for that feedback, is there a mistake in my calculation?

The accuracy of 4s in the electrical meter data is just the technical maximum, not the aimed one. I have to figure out, which accuracy is best for getting all electrical cosumer in the household.

Good point! I will try to calculate a coil or some condensator plates near the meter.
What you mean with the ragowski coil with additional equipment? I only know about this, that I can measure currents with that kind of coil. This is really interesting!

(Jeff Uk) #13

As advised earlier 4s updates = >20,000 uplinks per day! (84k sec/day / 4) search forum for TTN Fair Use Policy wrt # of uplinks & downlinks, not just time on air…(30/10)

Coil output is typically a voltage proportional to consumed current (remember monitor one leg - live (best) or neutral - not both (doesn’t matter before or after meter) as mag fields will largely cancel and you can also use smaller core coil). That voltage will then need to be regulated (buck/boost converter, inc over voltage protection etc.) before feeding your telemetry/lora solution, and as noted during time of low meter current consumption coil will fall to or close to zero meaning no power for your solution hence need for a back-up battery and associated charger…

(Bsiege) #14

If i look at my gateway i think 43.8ms is more realistic.See many packets with 17 Bytes payload SF7BW125 using 51.5 ms. But for 4s updates you use the wrong technology anyway.

(Ud Lo Ra) #15

… but the code is LoRa and not LoRaWAN, so no need for respecting FUP, and likely the calculation is ok or not far…

Why you have to send static symbols when you could add them after receiving the data, if you really need them? This is wasted airtime (even if legal, responsible behavior suggests to avoid unuseful transmission), and battery (this maybe is more convincing :wink: ).

(Jeff Uk) #16

Maedman referenced TTN FUP…just clarifying and in case of any future plans to migrate across. Plus guidance wrt d.c. abuse or at least pushing the limits still holds what ever the solution. :wink:

(LoRaTracker) #17

Can you clarify ?

Your suggesting your intending to send these 2 integer packets every 4 seconds over TTN ?
Can you clarify the confusion ?

(Ud Lo Ra) #18

@Jeff-UK I agree, it was just a sort of indirect reminder to @Maedman that his reasoning is not within LoRaWAN but outside. Le me add other info and summarize:

  • sending 12 bytes every 4 seconds at SF/500 might be within LoRa rules, even if LoRa is not made for this, but:
  • SF7 500KHz is not among EU channels for LoRaWAN. You have to switch to SF7125, which is four times slower, so 4,38ms becomes at least 17ms, and is still not sufficient because:
  • “there are no security aspects in sending yet”: yes, but for this and other, LoRaWAN adds a 13 bytes header, so 12 bytes of payload become a 25 bytes packet (of which, 4 are not needed because just separators… you already know where the integers are by position).

(Maedman) #19

@LoRaTracker @Jeff-UK @UdLoRa

Thank you all for your answers!

That was just an theoretical calculation. At that time, I was not aware that also the number of transmissions are regulated at TTN, thats now my biggest problem :slight_smile:

thank you for that hint! I will check again the regulation!

You are right, I dont need the seperators in the end. I will recalculate it and change my code to SF7 125kHz. Lets see if I can stay into the borders of EU regulation :slight_smile: “Worst” case for me would be to set up an own Gateway.

(Maedman) #20

Okay, besides the talk about the frequency of sending my data, the problem with the ESP32 Board is still not solved. I measured again, because I found out, that I forgot to measure with the oszi against ground… it is looking like this now:

The time with the voltage of 198.01mV over 720ms is representing the time the LoRa module is on. Why is this not equal to the time on air/sending time? I am only switching it on for sending and turning it of after it.