WiFi LoRa 32 V3: Send sensor data via LoRa, then go back to deep sleep

ksjh · February 3, 2024, 8:09pm

I do not want to confuse @jsteiwer, so this is more for @bns: The buck-boost I linked uses a TPS63070 or a clone of this chip. The datasheet of the TPS63070 states that the enable pin must not be left floating. So, the board needs to use a pull-up resistor. I have some of these cheap modules in my lab. If I wanted to use these in low standby power applications, I would simply remove the pull-up resistor and connect the ENABLE pin (of the module) to GND via a high-value resistor. An additional connection to the ENABLE pin could then be used to switch the module on and off. So, DIY off-by-default is very easy.

EDIT: In case you want to do this with exactly this model: Remove the resistor marked in red. It is 10 kOhm. But this module uses a tantalum input capacitor, it might go up in flames.

bns · February 3, 2024, 7:58pm

That shouldn’t be necessary!

@jsteiwer this is the setup I’d use for the Tindie regulator, with the Enable pin tied to any normal GPIO that has no pullup/pulldown resistor, just a simple pin.

ksjh · February 3, 2024, 8:22pm

@jsteiwer Depending on the GPIO pin, you may want to/can/should also isolate this pin to reduce current draw before going to sleep: https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/api-reference/system/sleep_modes.html#configuring-ios-deep-sleep-only

jsteiwer · February 3, 2024, 10:33pm

Okay, just to make sure I don’t mess up the connection, it should look like this, right?

I’m mainly concerned about where I have to take the GND for the breadboard from to get the controller to shut down the sensors right. Technically it should matter because GND is 0V but I’m worried about it aka driving myself crazy out of fear of breaking things.

@ksjh I looked at that link, and I think I have a better understanding now of how I should get things to work. Please correct me if I’m wrong anywhere in the pseudo-code below.

// board wakes up resp. duty cycle is starting
digitalWrite(GPIO, HIGH); // turn that enable pin ON -> 3.3V
// sensors sampling data
// send data via LoRaWAN (step will later be optimized to sample hourly but send data less frequently)
digitalWrite(GPIO, LOW); // turn that enable pin OFF -> 0V
rtc_gpio_isolate(GPIO); // prevent pin from stealing power
// board goes to sleep resp. duty cycle state = sleep

That’s roughly what it should look like, right?

Thank you in advance for any corrections and feedback.

bns · February 3, 2024, 10:43pm

There’s one battery providing one true ground within the system, to which everything can be hooked up. The diagram you’ve drawn is perfectly fine!

If you want to be a bit more sure before hooking up vital components, just connect the battery to the buddy thingy, connect the Vin/Gnd of the regulator, connect a simple LED through a resistor to the 5V of the regulator and any Gnd, and then use a jumper to connect the Enable pin to Gnd and 3.7V (and also keep it floating) and you should see the LED do things.

jsteiwer · February 3, 2024, 10:48pm

Thank you, I will try that tomorrow morning.

jsteiwer · February 4, 2024, 2:26pm

I have tried the test with the LED now. Everything is connected properly, the LED just behaves inverse to how I want it to behave. Essentially, the LED is on during deep sleep (so for 60sec) and briefly turns off when the board wakes up, and then goes back on when deep sleep starts.

What that tells me is that while my connections are correct, something in the code is not yet right. I have confirmed via measuring that the LED gets 5V during deep sleep and 0V when awake.

Connections:

short leg (cathode) on LED (-) connected to GND of the Sunny Buddy
long leg (anode) on LED (+) to 5V on the controller
En pin on controller to GPIO46 on board (pin has no pull-ups/downs or other functions)
GND on controller to GND on the Sunny Buddy
Battery and power supply are also connected properly

This is the code I’m using:

github.com

JuliaSteiwer/IoT-Water-Quality-Monitoring/blob/main/Deep%20Sleep/LED_blink_04022024_1305.ino

// LED is supposed to be off during deep sleep (60sec) and turn on when board wakes up
// in reality, the LED is on during deep sleep and off when the board wakes up

#define GPIO 46

#define uS_TO_S_FACTOR 1000000  /* Conversion factor for micro seconds to seconds */
#define TIME_TO_SLEEP  60        /* Time ESP32 will go to sleep (in seconds) */

RTC_DATA_ATTR int bootCount = 0;

void print_wakeup_reason(){
  esp_sleep_wakeup_cause_t wakeup_reason;

  wakeup_reason = esp_sleep_get_wakeup_cause();

  switch(wakeup_reason)
  {
    case ESP_SLEEP_WAKEUP_EXT0 : Serial.println("Wakeup caused by external signal using RTC_IO"); break;
    case ESP_SLEEP_WAKEUP_EXT1 : Serial.println("Wakeup caused by external signal using RTC_CNTL"); break;
    case ESP_SLEEP_WAKEUP_TIMER : Serial.println("Wakeup caused by timer"); break;

This file has been truncated. show original

Do you see anything that points to the reversal of the states? I did try switching LOW and HIGH but that just results in something weird. Should I try inverting the pin with something like digitalWrite(pin, !digitalRead(pin));?

Thank you in advance for your answers and help!

nmcc · February 4, 2024, 12:43pm

As seen on the back of an Army Tech: “If you see me running, try to keep up!”

The link to GitHub isn’t working, I think it may be this:

https://github.com/JuliaSteiwer/IoT-Water-Quality-Monitoring/blob/main/Deep%20Sleep/LED_blink_04022024_1305.ino

Edit: Turns out Discourse can’t cope with spaces in URLs!

bns · February 4, 2024, 2:11pm

Now this is where you find out that you do in fact need the inverted logic and need to add a pull-up resistor (Enable <-> 3.3V / 3.7V), because apparently my memory isn’t good enough. The “something weird” is a floating Enable pin because there isn’t any internal pull happening, making you completely free to add your own however you like.
Not at my desk so not able to verify right now, but given that it works one way round means it should also work the other way round! (And because I do have the same setup I’d also expect it to work )

jsteiwer · February 4, 2024, 2:58pm

Yes, that’s the link. Guess I’ll have to change the folder names so that doesn’t happen again.

Okay, I’ll check if I have one at home; if not, I will ask my colleague tomorrow if we have one at work.

Edit: So, I have a resistor of 100R (brown black brown gold, with gold being closest to the LED’s leg) between the 5V from the controller and the anode of the LED. With how you described the addition of the PUR, I will have to add it between the En and the Vin pins of the controller resp. between the cables leading to both. Which size of resistor would you recommend?

bns · February 4, 2024, 3:24pm

Something like 10k~100k would be good, you just want some tiny tiny current to keep it high.

jsteiwer · February 4, 2024, 4:23pm

Thanks, I have those at home!

Edit: I tried 100k, 10k, 22k, 47k, 1k, 100R … all to no avail. Could it perhaps be that the PUR needs to be between GND and En rather than Vin and En?

ksjh · February 4, 2024, 5:48pm

The schematic for the boost converter from Tindie can be found here:
https://oshwlab.com/gendor/5v-boost
The datasheet for the chip on this module, an FP6277 is available here:

According to those, the EN pin needs to be pulled to GND to disable the converter. The converter starts as soon as the voltage on this EN pin is above 0.96 V. According to the datasheet, the voltage on EN needs to be less or equal to VIN (input voltage of the module/chip).

So, an experimental setup without any ESP32 or sensor:

Connect the boost converter to the output of the Sunny Buddy (VIN to the positive output of the Buddy, GND to GND).
Connect the EN pin via a 10 kOhm resistor to the common GND.
Connect an LED via a 1 kOhm resistor between the 5 V output of the boost converter (long pin of LED) and commond GND (short pin of LED), i.e.,
5V — resistor 10k — +LED- — GND.
Connect an additional wire directly to the EN pin of the boost converter without any resistor.
When you now make an electrical connection between this wire and the 3.7 V rail (e.g., the VIN pin), your LED should be lit, otherwise it should be off. Do not touch any other contact to not short out anything with the wire.

Does this work?

jsteiwer · February 4, 2024, 7:53pm

Thank you for the explanation. I have tested putting the PUR between GND and En before I saw your reply, and that unfortunately did not work. I will try your proposed setup next and report back to you.

Just for clarification, the connection you want me to try should look like this one below, yes or no?

And if that were to work, then later, the open En connection would go to a GPIO pin that is configure with HIGH/LOW on the board and I would put the output of the sensor back to another GPIO pin, do I understand this right?

Thank you in advance!

ksjh · February 4, 2024, 8:06pm

Yes , looks good. And yes, the end of the violet wire you should touch to VIN can then be connected to a GPIO pin. When this GPIO is set to LOW, the LED should be off, when the GPIO is high, it should be on. For safety reasons, you can later also try to include a lower value resistor between the GPIO and the EN pin. It should even work with a value of 10 to 20 kOhm, but this is something to worry about later, once this basic setup in your diagram works as expected.

jsteiwer · February 6, 2024, 7:31am

Thanks! Okay, I’ll try that then. Will let you know if it worked!

secret thingy

Actually, I’m not home again until Thursday evening so I’ll send the info to my dad; he loves electrical builds and with the bad German weather:tm:, he is bored so this is like enrichment for him. I think in professional lingo this is called “out-sourcing”.

Edit: Okay, the tests are done; here are the results:

The voltage between GPIO46 and GND is 0.011 during deep sleep and 0V when awake. So no enabling signal.
The voltage between GPIO46 and (+) is 0.011V during deep sleep and goes up to like 1.5V when awake, so we do see an enabling signal there.
Connecting the board to the battery and the LED to +3.3V and GPIO46, we get the desired behavior of the LED being off during deep sleep and on when awake. We just don’t get a power supply of 5V at this stage.
Now, using only the controller from UK, the behavior is exactly inverted. The LED is on during deep sleep and off when awake.

This leads me to believe that I need to invert the output from GPIO46. My guess would be that I have to add a line of code like digitalWrite(GPIO, !digitalRead(GPIO)); - at least that’s how I understood the concept of inverting a pin from some Arduino manuals. Please correct me if I’m wrong though.

ksjh · February 5, 2024, 9:09pm

Mind you that GPIO46 is somewhat special, it is a strapping pin. Can you use another one?

Your results are all fine and dandy, but then we need do to some additional tests:

The experiment I suggested and for which you drew the diagram does not contain any ESP32. Therefore, there is no GPIO-whatever and no sleep. So you clearly conducted a different experiment.
Could you first try to do the simpler experiment without any ESP32 please?
After this has been done, could you please create a simple blinky program that does first set a GPIO as an output pin in setup(), then, in loop(), set the GPIO to HIGH, wait two seconds, set the GPIO to LOW and wait one second? Now connect the long lead of the LED via the 1 kOhm resistor to the GPIO and the short lead of the LED directly to GND. Just the LED in the first stage, no boost converter. The LED should now blink with two seconds on and one second off.
When this works as expected, exactly as the expected result above, you are ready to connect the module from UK to this GPIO pin like we discussed before. But please use just this blinky program, no deep sleep.

We cannot help to debug a larger complex program when not even the basics are working. Please try to solve the bigger problems in small steps. It makes exactly no sense at all at this stage to care about deep sleep. Get the basic IO stuff right first. And it is all but right now. Blinky is the way to start. We need to go round in circles, unfortunately.

I am pretty sure I have an explanation why your program does not work, but once you got the blinky working, you might discover the solution yourself. Understanding this is the first step to be able to tackle larger programs.

jsteiwer · February 6, 2024, 7:32am

Edited: So the second test my dad did was just the simple setup with only the controller and the LED, which had the inverse behavior. So that means that right now, that is inverted.

I will write the simple blinky program and try that on different GPIO pins. Btw, does it say anywhere that GPIO46 is a strapping pin? I looked at the pin layout and the manual, and there it says GPIO only. It’s really confusing that pins have extra features that aren’t listed in the pin layout or manual.

For me what’s also a little weird is that the connection without the controller produces the right behavior (light on when awake, off during deep sleep) but is inverted when the controller is involved. Well, I’ll try what you recommended when I’m back home and hopefully that gets me closer to a working solution.

ksjh · February 5, 2024, 10:51pm

Yes, this special GPIO functions thing is really annoying. I also made some mistakes once or twice regarding special GPIO pins when designing PCBs for new ESP32 variants. The Heltec documentation just says: Oh yeah, this is GPIO46, nothing really special.
But then you find the right documentation for the ESP32-S3 from the manufacturer:
https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/api-reference/peripherals/gpio.html
There is a small note for GPIO46 that this is a strapping pin. Then, you need to follow the link to the PDF of the datasheet for the ESP32-S3:

In this PDF, there is section 2.6. It explains the pullup/pulldown resistors for the strapping pins. And then it becomes somewhat convoluted. Basically, it means: When you use an external pullup resistor on GPIO46, i.e., a resistor between this GPIO pin and 3.3 V which is there when you boot the board, you cannot use the USB or serial port to upload new code to the board. It also explains that when you do not connect an external pullup resistor, there is a weak internal pulldown resistor that pulls the GPIO to GND. All this might affect the working of external components connected to this GPIO pin, or, even worse, external components connected to this pin might prevent you from uploading new code to the board until you disconnect those components. It’s a mess. If you can, better avoid those GPIOs.

bns · February 5, 2024, 10:56pm

GPIOs 2 and 4 up to and including 7 should be good to use! And are also in the RTC domain for holding-functionality during deepsleep if need be.