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
Is there someone who can help me figuring out how to fix the deep sleep mode?
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?
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
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
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 support@heltec.cn
#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() {
Serial.begin(9600);
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 = Serial2.read(); // 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
flashcount++;
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 ));
break;
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 ));
break;
}
kw = global[14];
trans[1] = kwh;
trans[2] = kw;
LoRa.begin(BAND, PABOOST); // Sending via Lora start
LoRa.beginPacket();
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
esp_deep_sleep_start();
}
}
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.
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 ). 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?..
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!
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…
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.
… 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 ).
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.
@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).
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
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 “Worst” case for me would be to set up an own Gateway.
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.
). 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?.. 
).