After searching the forum and the internet, and finding nothing, I am hoping for some insight from the community on this odd problem.
Using DFROBOT’s Solar Power Manager (Solar Power Manager 5V - DFRobot) and a 3.7vdc 2000mAh plug-in battery, it has been possible to run the MKR WAN 1310 for remote operation. Sensing and transmission works well. Graphs show the battery voltage varying with the rising and setting of the sun. BUT, upon a continuous series of badly overcast skies, the battery, naturally, completely discharges, the charge controller, and the MCU shut down.
At issue is that, once the sun comes up again and the battery recharges, the MCU does not restart. It was necessary to double-press its reboot button. Had expected the MCU to restart itself once voltage returned to normal.
For those more experienced: Is this normal? Is there a way to ensure automatic restart under these circumstances?
Good questions. Thank you. I did work on that prior to rebooting the MCU.
Both power LEDs on the DFROBOT controller and the MCU came on once the overcast cleared and the battery recharged. I verified the voltage entering the controller from the solar cell and the battery. Also verified that no signal was coming from the MCU by moving the receiver close to the MCU and verifying that the receiver was working. Nothing happened until I double-pressed the reboot button on the MCU.
Things go south when you run out of power.
Maybe it's better to concentrate on fixing that first.
Size matters... 2Ah ain't much. The battery should be able to bridge a couple of days without recharging. Did you test that first.
How big is your panel. Cheap black epoxy?
The solar charger seems to be capable of delivering 900mA (panel depending).
A common (flat) 2Ah battery shouldn't be charged with more than 10% of it's capacity.
Note that a solar panel output drops to 10% or less of it's capacity on a bad day.
I use the better quality white panels, commonly used for outdoor cameras (eBay etc.).
20x20cm, 5volt/400mA.
So
Pick a battery capacity that can bridge three nights without recharging
pick a solar panel size capable of topping up the battery almost every day.
I built a water meter system which uses a MKRWAN 1310 to transmit the meter count to a base station using LoRa. It’s all designed to be extremely low power, but the 3.7V LiPo battery still only lasts a few weeks.
I manually recharge the battery with a portable charger into the USB port, but I never have to hit the reset button. It just starts up again at some point.
However on my system the LiPo is directly powering the MCU and being charged by it. It sounds as if your battery is charged by the DFROBOT module which then feeds 5V to the board. I don’t know if this would make a difference, but it might.
Are you using deep sleep techniques in the code to save power? I use the Adafruit Sleepydog library so the thing spends 99% of its life asleep. Again, I have no idea if this would make any difference to the start-up, but it might.
Gradually going through these responses while checking my wiring. Many thanks to all.
Regarding “double-press reset”: From Grok: Double-pressing the reset button on the Arduino MKR WAN 1310 enters bootloader mode. This temporarily reprograms the board's microcontroller to act as a USB mass storage device, making it appear as a new COM port (often labeled as "Arduino MKR Zero (Programming Port)" or similar) in the Arduino IDE. It's a common fix for USB connectivity issues, like when the board stops showing up in the port menu after repeated uploads or disconnections, allowing you to upload new sketches again. A single press just resets the microcontroller and USB communication without entering this mode.
From this perspective, my double-press reset may have helped. Not sure. Will test that. Also rewrote setup() in this way based on Shannon’s comment in mkr1000 does not restart when power back again - #5 by gusoen , since the serial monitor and plotter are not used.
Serial.begin(9600);
Wait(1000); // give time for device to settle
It is misleading to say "temporarily". The board remains in this state persistently until one of the following events occurs:
The board is reset
The board is power cycled
A new sketch is uploaded
This is also misleading. In embedded systems, and in this context, the term "program" or "reprogram" generally means flashing a program binary to the memory of the chip. That is not what happens when you do a double reset. It only puts the board into a different mode where it runs code that was flashed to a special area of memory at the factory.
This is completely false. The board acts as a USB CDC device, just the same as it does normally when running your sketch program. It is possible to write a program that will cause the board to act as a USB mass storage device, but that would generally be done in your sketch program, not in the bootloader.
You would never change the bootloader to that behavior while working with Arduino sketch projects, since the Arduino upload system relies on the standard bootloader that produces a USB CDC serial port device.
And Grok immediately contradicts its previous statement . If the board was acting as a USB mass storage device, it would appear as a drive, not a port.
I'm used to hallucinations from AI, but this response is exceptionally low quality. And I usually see hallucinations from challenging requests, whereas this is a very basic subject matter. If you are going to use an LLM, you might want to consider switching to a different service.
This part is correct.
As I explained above, the double reset is expected to put the board into a state where it remains persistently waiting for a sketch upload, not running your sketch program. So we would expect a double reset to actually cause harm in the case where you want your sketch program to run.
We might expect a single reset to help in the case where the board or program somehow went into a bad state (e.g., a hang), as this will cause the sketch program to restart.
Not sure if it fixed the problem. Setting up an experiment to see. The code for the experiment will do away with all the sensors and actuators that are connected to the system and just have it send a simple message. That will eliminate things that do not impact the problem at hand.
// Wait for a specific number of milliseconds. // delay() is blocking so we do not use that. // This approach does not use hardware-specific timers. void Wait(long milliseconds) { long beginTime = millis(); uint8_t doSomething = 0; while ((millis() - beginTime) <= milliseconds) doSomething++; }
I might be missing something, but that Wait function will block just as much as using delay().
That won’t hurt after Serial.begin() in setup(), but if you’re using the wait function exactly as you’ve written it inside loop() and expecting it not to block, well it will zip around inside that while statement every time you call it, and nothing except incrementing dosomething will happen at the same time.
You would need to replace dosomething with your entire sketch code for it not to block.
After doing some tests on my own MKRWAN 1310, I can confirm that I get the same behaviour as @soothingmist. If you very, very slowly increase the Vin voltage to 4.6V, the board will enter bootloader mode (slow pulsing from the built-in yellow LED), and the sketch will not be running.
Increasing the voltage to 5V doesn’t do anything - the board remains in bootloader mode until you either remove the supply or press the reset button.
If the supply voltage rises quickly through and above 4.6V, the problem does not occur and the board starts up as normal.
Presumably the DFRobot solar controller is doing this slow voltage rise as its solar supply recovers.
The actual sketch content has no effect on this - I could see the problem when running a simple blink sketch with a LED connected to one of the digital pins.
So @soothingmist might need to use a reset controller as @jremington suggested earlier in the thread.
Many thanks for this assessment. And to all of you for your input. The process of discussion between people often leads to unexpected insights.
It is true that Wait() does block the MCU’s single-thread code processing. From other reading I had gotten the impression that delay() stopped other hardware functioning on the board as well, whereas Wait() only stopped the code’s progress. My impression may be wrong.
The idea of an external reset capability is certainly interesting. It sounds like an external circuit that would sense power restoration and then emit the appropriate reset signal. Is there a link to something like that? Am wondering if I am working with a good MCU for the intended application if it cannot power up and regain itself after power drops out and is then gradually restored.
Yes. I see. Great! An external circuit for sending the reset signal. A great idea that has a realistic implementation.
Looks like some soldering would be needed. That works well for someone with sufficient eyesight and steady hands. Perhaps this signals a roadblock for me or maybe that I need an MCU that recovers well under various power-out/recovery conditions.
Another good option! Avoid the dead-power problem altogether.
Had avoided more expensive solar and battery combinations because of cost considerations. Independent LoRaWAN networks are expensive just to get started. LoRaP2P offers a good alternative for many applications. Had gotten to where a basic basestation/relay/sensor network can be constructed for under $US200. Perhaps this is a bit ambitious for continuous operation and at least a larger battery should be considered.
. If the board was acting as a USB mass storage device, it would appear as a drive, not a port.