Why is that? If on an average day my panel puts out more than enough energy I would think simply having enough battery to sustain it through cloudy days/weeks and bad weather would work
Does anyone happen to know if/which header pins could be used to reset the board? It would be a simple thing to let a wire with a button hang down from the mounting location in the tree should a reset be required.
1 Like
That would be fantastic. Or have them just reset when power is applied.
Because a bigger panel would make the most of sporadic sunlight, charging the battery faster. It really adds reliability, particularly to T-Beams, which do not restart on their own after a brownout.
I agree on the larger panel. Also to the problem, You might think about using some low power radio controlled switch that could be used to do the reset. I have one than turns on lights in my chicken coop. I use a small 12 volt battery for the lights and the switch. So if you had power (from the solar panel) you could remotely reset your system. Just a thought and would eliminate tree climbing. Personally I think the solution is a larger battery and a larger panel. I am planning to do that here on my farm. Putting the system on the the top of my greenhouse on a pole. Cheers - Dennis
1 Like
Interesting thread, though I’m late to the party. Yesterday I allowed one radio to run flat (both radios on the bench), to see how it responded to restored power. I let it charge for an hour to see if it would wake up – nothing. I had to press the “pwr” button (which surprised me-- I could have sworn when I first put a battery in the unit when I got it, it powered up immediately.) I’m surprised the AXP192 charge control chip on the board doesn’t offer some way to restart the board when power returns.
Your panel is not providing enough power to be considered “powered” but it will charge the battery.
1 Like
are you sure that it did not go to deep sleep. In that case it will wake up after (default) 1 year AFAIR. I have shortened the sds_secs to 1800 so that it wakes up after a while and then continues if the battery has enough level
1 Like
I bet you are right, I forgot about this setting
In my case there is no solar panel, I just let the battery die to see what would happen when I re-applied power via the USB connector, thinking this would simulate many cloudy days in a row followed by sun.
Seems like the tbeam is especially not suited for solar, I had to pull the battery to get it to reset.
did you wait sds_secs before you pulled the battery ?
No, that would be a year
That is why i changed it to smaller value. Anyway, TBeam should react when you press the middle button, though I am not sure without testing. I think it matters if ESP32 deepsleeps on waking up with that button. I think I have seen this in code.
Still you need to have the batteries over that minimum level, otherwise it goes sleeping again.
It behaves pretty inconsistently and is a hardware issue [Bug]: Solar powered T-Beam V1.1 not waking up after battery run down from no sun · Issue #1470 · meshtastic/Meshtastic-device · GitHub I would just use a NRF52 for solar since you need a solar management board or second microcontroller to do solar effectively on a tbeam and the esp32 uses 10-20x more power.
Agreed.
Without modifications, a tbeam isn’t suited for an unattended solar installation if the configuration is expected to run out of go-juice.
On the flip side, if the battery is of significant size and the solar panel is also sized to charge on the most cloudy dates – then the tbeam would be just great.
There’s two issues: one is how much power a given device requires. But the other issue is my concern: will a device automatically restart after loss of power. Just using a lower power processor does not necessarily address this.
None of the other devices get hung like this in my experience.
I am wondering if there is a way to send test messages periodically and if there is no expected response, then an external “watchdog” will reset the board by turning the power off and on.
I imagine this as an external device that is protocol-aware.
Of course it only makes sense for hard to reach locations. And then you may need a watchdog for your watchdog.
Rather have a simple HW-watchdog getting reset periodically by TBeam GPIO and if not then resetting TBeam. Does not have to be protocol aware and will work locally. Now where does that gadget get its power…
2 Likes