Just an idea… if your battery is a normal 3.7V-ish lithium battery, it might be OK to connect MrBoost straight to the battery, before MrBuddy. It’s allowed input is 2.5 to 4.5V so would need to check your circuitry of course. But the battery is probably better able at handling spikes than through MrBuddy.
WiFi LoRa 32 V3: Send sensor data via LoRa, then go back to deep sleep
2 Likes
I was originally thinking the other way round as the code really doesn’t do anything exciting. But happy to be proved wrong.
You could make each box four state - nothing, code, sensor, code+sensor.
The schematic shows it is effectively connected directly along with some smoothing caps: https://cdn.sparkfun.com/datasheets/Prototyping/SunnyBuddy-v13a.pdf
After the last week of getting the reflow (solder) oven profiles sorted to get components where the data sheets use µm not mm for the pad dimensions, I’m with you - I believe they call it AA in some quarters. So don’t worry, this sort of 
happens to all of us.
When the next big invoice payment lands & we’re past Chinese New Year I’m so getting all the other sensors I don’t already have to play along.
1 Like
And maybe one more idea, but may need some confirmation by someone else: you could try adding a capacitor over the lines powering your Heltec board. If there’s a spike, the cap may be able to keep the board alive. No idea on values though, just another idea that popped up.
1 Like
Okay, did a quick test with sending every hour. Worked great, nice values, no re-joins. Going to charge the 2200mAh battery up over night and then hook everything back on tomorrow, let’s see how long my system will stay alive for now.
1 Like
A cap of reasonable size would not hurt.
But please take a look at the code. According to the results of @jsteiwer, it is not switching the boost converter off and on again which causes the re-join, just reading the sensor values. Why would there be any spike just by doing an analogRead()? There could possibly be a division by zero in the conversion of the ADC value, depending on some values.
I would really like to see a graphical representation of the Heltec FSM. I am pretty sure that some things in the code could be done multiple times. And I have not checked if it would hurt to execute some parts of @jsteiwer’s code more than once. In the implementation of LoRaWAN.cycle(), a timer is started. When the timer expires, the Heltec implementation triggers a transition to different states, depending on some checks wrt. the LoRaWAN MAC status. Please note that the FSM implementation is inside the loop(). Each state could be visited multiple times. When the state stays the same (no transition), the code for this state will be executed in every round of the loop. And is it really (logically) OK to go to sleep while a timer is active? Or are they (Heltec) avoiding this somehow? And are we sure we do not schedule the same timer twice without stopping it first? Could it be that the timer normally does not expire before going to sleep, but when you do more random stuff in your own code, the timer finally expires and some code is executed that does cause problems or causes transitions to unexpected states? All this is just what I understood from briefly browsing the code, no deeper analysis done, I could be wrong here.
Is there anybody around who understands the Heltec LoRaWAN code well enough and has not just copied the example implementation? I really have no intention to dig deeper into the Heltec code, because I would never use it anyway. @bns, your RadioLib LoRaWAN implementation is so much better, thanks again.
Given the fact that @jsteiwer mentioned the production board will use an SX1278 anyway, we’ll need her to switch to RadioLib either way… so I guess it’s time to copy the sensor logic to one of the RadioLib LoRaWAN examples. Which are not perfect yet, maybe that @nmcc can provide a copy of his Heltec × RadioLib work if it’s any usable in this case.
And @ksjh thanks for the compliments 
For my use, would this code of yours be most suitable as a starting point?
No, this one:
Where you include a node.saveSession() on line 157.
1 Like
I checked, there isn’t in the user code.
I wouldn’t bother - the LoRaMac-node code base is pretty ancient - somewhere in the middle of LW v1.0.2 - v1.0.3 has most of the good stuff, v1.0.4 adds in the dreaded DevNonce, v1.1 is a more secure version of v1.0.4.
And the state machine in the loop isn’t helpful - most peeps just want to wake up, read some sensors, send them, wait for downlink, process any user side response and sleep. So for me the Join is in the setup() and the loop() allows you to work on the stuff you want.
Which is why I’ve not just knocked out a RadioLib example I’m happy with as the checking for results looks a bit too FSM for me. But if you like that sort of thing, there is always the fun of explaining how LMIC picks up “events” and how you never appear to tell it when you want the next send and consequently how you sleep. See my first foray in to LoRaWAN summer 2019 at https://github.com/descartes/Arduino-LMIC-example and then I tried Heltec but let’s not get in to that.
1 Like
Yes, exactly. The simpler the better 
Will ask my colleague how he plans on handling the LoRaWAN transmissions on the SX1278 when the PCB arrives. We do have a code that sends data to a LoRaWAN gateway using functions of radio, but I’d have to ask my colleague if that one has already been used with the SX1278.
Anyway, I started the battery “stress” test at 12:40 today. Data is sent every hour, the whole system is in deep sleep otherwise (the sensors are off during that time), and there are no re-joins between transmissions (at least that’s what my short [2h] test showed yesterday). Let’s see for how long 2200mAh will keep my system alive now.
Update: The system stayed alive for 93 hours (almost 4 days) on the 2200mAh battery, without the solar panel attached to the Sunny Buddy. It’s actually still alive, just skipped one packet.
The new PCB has arrived, and I will take it home with me today, let’s see if I can get that thing running.
Update 2: The system is still running (without the solar panel, so this is especially sweet as it means with the panel the live time can be increased even further 
). There’s a problem getting Arduino to work on the new PCB, something strange is going on, but I’ll hand my PCB to my colleague on Monday and let him flash Arduino on it, as he managed to get it working on his. I’ve tried a lot myself to get it working but I simply do not have the capacity right now to try even further. Anyways, I hope you’re enjoying you weekend; I will, as German weather has finally decided that it’s time for spring. 
Update 3: Electronics my beloathed. I took a perfboard and soldered some connectors on, you know, to replace the less stable breadboard, and now the sensor values are completely off. I will check if during sending time anything even goes on, but it’s so weird because it’s plugged in exactly as before, just on a more secure basis than loosely plugged into the breadboard. It’s beyond my understanding. Hopefully it can be resolved, otherwise I have to go back to the breadboard.
Update 4: The values were completely wrong, so I plugged everything back to the breadboard, but the parameters did not go back to the correct values. I’m so tired of this…
Update 5: I plugged in the temperature sensor wrong. The DS18B20 I’m using has brown, green, white cables instead of classic black, red, blue, so I had gotten something mixed up, which caused the other problems.
4 Likes
Hey guys, I don’t have a new problem, I just wanted to give you a little update of how my project has been going on since you all helped me so much.
- The program is working great, measuring and sending works reliably.
- I got to test my sensor node at a partner university in Thailand.
- There were some weird sensor behaviors that I could not yet reproduce, and afterwards the sensors worked reliably again, so
- I did a lifetime test: measuring + sending every 5 minutes, using only the 2200mAh battery … lasted 16 days, and I got 4,549 packets through (so 0.48mA per packet).
- As some sensors are not working great (turbidity), we will create some sensors ourselves (cooperation with two other research groups from our department). Excited for that.
- We have a new PCB for one of our projects which will get updated even more, and it might be used in my project.
Again, thank you all for the help when I got started with this project. I’m excited for what I’ll create in the future and I’ll try to give you an update you once in a while.
3 Likes
Not an update I expected, but sure one I like to see!
Sounds like a success on your behalf, happy to hear that it’s working that well. One thing I do wonder however, is how you got 36,200 packets through at a 5min rate in 16 days… my math may fail at times but I am unsure how this would work
And feel free to send a pic of the final result, would love to see how it turned out. Either way: congrats!
1 Like
It’s actually 4,549 packets, when I selected the rows and to get the number of packets my spreadsheets program calculated rows*columns, sorry. Got too excited with the value to cross-check it. 
Meaning the consumption is 0.48mA per packet.
Here is a picture of the node installed in the wastewater treatment plant in the Hospital of Tropical Medicine, Bangkok.
And here’s one of the inside of the sensor node.
2 Likes
Ahh, that checks out 
still a solid result nonetheless!
1 Like
Congratulations and thank you for the update and photos. 
I can imagine that the “Dupont” connectors (jumper wires) connected to the WiFi LoRa might not be very reliable. In harsh environments, it would be better to use some latching or locking connectors, even cheap ones would probably be better than “Dupont”. Something like JST XH or KF2510 should be sufficient to improve the reliability of your sensor connections. You might need to build an adapter (custom PCB or stripboard) between the WiFi LoRa and the latching connectors.
Hello everyone, I hate to revive this old topic but I’m encountering an annoying issue that directly relates to this code.
When I use my original working code, I now receive the following error message:
/private/var/folders/c2/wdw0wh7d61g7mrvq9ygp3jcr0000gn/T/.arduinoIDE-unsaved2024111-60417-jmt6cw.4dee/sketch_dec1d/sketch_dec1d.ino:250:12: error: no matching function for call to 'McuClass::begin()'
250 | Mcu.begin();
| ~~~~~~~~~^~
In file included from /Users/jsteiwer/Documents/Arduino/libraries/Heltec_ESP32_Dev-Boards/src/LoRaWan_APP.h:8,
from /private/var/folders/c2/wdw0wh7d61g7mrvq9ygp3jcr0000gn/T/.arduinoIDE-unsaved2024111-60417-jmt6cw.4dee/sketch_dec1d/sketch_dec1d.ino:6:
/Users/jsteiwer/Documents/Arduino/libraries/Heltec_ESP32_Dev-Boards/src/ESP32_Mcu.h:59:7: note: candidate: 'int McuClass::begin(uint8_t, uint8_t)'
59 | int begin(uint8_t board_type,uint8_t ex_32k);
| ^~~~~
/Users/jsteiwer/Documents/Arduino/libraries/Heltec_ESP32_Dev-Boards/src/ESP32_Mcu.h:59:7: note: candidate expects 2 arguments, 0 provided
exit status 1
Compilation error: no matching function for call to 'McuClass::begin()'
Because this isn’t really an error message I can work with (given that, as you all witnessed in this very thread, the code used to work just fine), I decided to take theLoRaWAN example from Heltec and paste the code snippets I need from my old code in there one by one.
If I compile the example code as is, there are no issues. As soon as I add any other library, be it OneWire, DallasTemperature or EEPROM, I get the following error message:
Library Heltec ESP32 Dev-Boards has been declared precompiled:
Using precompiled library in /Users/jsteiwer/Documents/Arduino/libraries/Heltec_ESP32_Dev-Boards/src/esp32s3
In file included from /Users/jsteiwer/Library/Arduino15/packages/esp32/hardware/esp32/3.0.5/cores/esp32/esp32-hal.h:75,
from /Users/jsteiwer/Library/Arduino15/packages/esp32/hardware/esp32/3.0.5/cores/esp32/Arduino.h:36,
from /Users/jsteiwer/Documents/Arduino/libraries/OneWire/OneWire.cpp:147:
/Users/jsteiwer/Documents/Arduino/libraries/OneWire/util/OneWire_direct_gpio.h: In function 'void directModeInput(uint32_t)':
/Users/jsteiwer/Library/Arduino15/packages/esp32/hardware/esp32/3.0.5/cores/esp32/esp32-hal-gpio.h:68:34: error: 'GPIO_IS_VALID_GPIO' was not declared in this scope; did you mean 'RTC_GPIO_IS_VALID_GPIO'?
68 | #define digitalPinIsValid(pin) GPIO_IS_VALID_GPIO(pin)
| ^~~~~~~~~~~~~~~~~~
/Users/jsteiwer/Documents/Arduino/libraries/OneWire/util/OneWire_direct_gpio.h:214:10: note: in expansion of macro 'digitalPinIsValid'
214 | if ( digitalPinIsValid(pin) )
| ^~~~~~~~~~~~~~~~~
/Users/jsteiwer/Documents/Arduino/libraries/OneWire/util/OneWire_direct_gpio.h: In function 'void directModeOutput(uint32_t)':
/Users/jsteiwer/Library/Arduino15/packages/esp32/hardware/esp32/3.0.5/cores/esp32/esp32-hal-gpio.h:68:34: error: 'GPIO_IS_VALID_GPIO' was not declared in this scope; did you mean 'RTC_GPIO_IS_VALID_GPIO'?
68 | #define digitalPinIsValid(pin) GPIO_IS_VALID_GPIO(pin)
| ^~~~~~~~~~~~~~~~~~
/Users/jsteiwer/Documents/Arduino/libraries/OneWire/util/OneWire_direct_gpio.h:240:10: note: in expansion of macro 'digitalPinIsValid'
240 | if ( digitalPinIsValid(pin) && pin <= 33 ) // pins above 33 can be only inputs
| ^~~~~~~~~~~~~~~~~
exit status 1
Compilation error: exit status 1
I have no idea what to do with this error message, as the code at this point is really just the LoRaWAN example code and one singular other library. All libraries I have installed are up-to-date. I fear it’s the LoRaWAN_App.h library itself that’s causing the issues.
While the 2.x.x versions cause the above error, all 1.x.x versions cause the following error:
/private/var/folders/c2/wdw0wh7d61g7mrvq9ygp3jcr0000gn/T/.arduinoIDE-unsaved2024111-60417-aawynk.nfmir/sketch_dec1c/sketch_dec1c.ino:15:10: fatal error: LoRaWan_APP.h: No such file or directory
15 | #include "LoRaWan_APP.h"
| ^~~~~~~~~~~~~~~
compilation terminated.
exit status 1
Compilation error: LoRaWan_APP.h: No such file or directory
Thank you already in advance for any ideas on how to fix this issue.
Well hello there, welcome back!
A while ago now, Heltec updated both their platform and their libraries, both resulting in breaking changes. It looks like you updated (one or both of) those.
Depending on the time you have available, you could
a. Check out the current examples to see if they compile and then port over your changes, or
b. Move over to RadioLib which is independent of Heltec’s platform & libraries, meaning that they can’t break your stuff as now happened.
Hi Steven,
I did check the current examples already; they do compile but once I add libraries for my sensors I immediately get the above described error messages. Also, as I described, regardless of the Heltec library version, the issue persists or if I go down to the 1.x.x versions, then supposedly LoRaWAN_APP.h doesn’t exist.
I took a look at the RadioLib repo and found this code here. It has both LoRaWAN and deep sleep, which are the two main functionalities I need from an example code. Tomorrow, I will try compiling that one and then add my changes to it, one by one. Thanks for suggesting this library! I will report back once I’ve tested it, hopefully with success.
I added all the relevant sensor code parts to the RadioLib code, and it compiles successfully. Tomorrow, I will re-assemble my sensor node and test the sending at work. Let’s hope the sending will go smoothly.