I guess the point of fixing ESP32 over consumption is to allow people to use what hardware they have already bought, or what hardware they can afford to buy (where I live I can have two TTGO LoRa32 for the price of a single Wisblock unit). Also, versatility is nice. It is quiet nice to have a target that can be used either for bluetooth, or for WiFi, or for remote relay, depending on situations.
From your lines, I understand that ESP32 power usage is harder to get right than NRF52 power usage. That said, do we agree to consider desirable to improve ESP32 target power usage, if someone steps in for it ?
Most users don’t want the size of panel and batteries necessary to run an ESP32 on solar. It costs considerably more to make an ESP32 work badly for solar when you can buy a single NRF52 board with a built in solar charger. Spending $80-100 to use a $20 board does not make sense when the Meshtastic starter kit is $25.
do you think led blinking could be restricted or disabled for “remote relay” usage ? That would avoid waking up the MCU, and avoid powering the leds. I don’t see a setting for that in the power-management related documentation page.
“Presence relaying” was unclear, sorry. I mean that nodes periodically broadcast their GPS positions (or only their presence online) to the mesh. Although I could not find where it is described in the docs, I assume these “presence messages” are repeated in the mesh like other messages. Is there a setting to disable such “presence messages” repeating on low power nodes ? A setting would be optimal, because certainly some people will want to keep them and use more power (presence signaling / position broadcasting is definitely a fantastic feature for some cases), while others will happily disable them to save battery life and focus on messaging.
Basically, what I would like to have is a way to setup a relay node so that it does absolutely nothing but the bare minimum required to propagate messages.
I will have a deeper read about the power management state machine page, thank you. Do you know if someone has tried to breakdown where the power goes on their nodes ? What goes to MCU, to radio listening, radio Tx, peripherals etc. ? In particular, I would like to have an idea about how much power is used for LoRa radio listening. If I can, I would be happy to help better understand what is going on these TTGO ESP32 / Lora boards.
In my opinion, power optimization benefit every users, even those who are not on solar, but on battery. If they can have a battery life of 7 days instead of 2 days, I am sure they will enjoy it in many ways.
In my country, a ESP32 LoRa32 device costs less than $20 delivered, and that board includes screen and wifi modules. Last time I checked, a wisblock costs $38 delivered, without screen and without wifi.
NRF52 is certainly a nice design, with low power usage, but ESP32 also has some merits, and if things can be improved on this target, it would be great for many users.
7-8 days for a t-beam has never been real unless your node is not in range of any other nodes. The lora radio can’t look at the different lora packets and then only wake up if it is a message, it wakes up when a packet arrives so in a network with any traffic the router never sleeps. The majority of the time a lilygo device being used as a router runs at 50-60mA. You can do solar with large panels and ESP32 but don’t do your calculations expecting extended durations at 10mA.
I see. Very interesting and valid point, thank you.
Is it correct, however, that in an area with low activity on the very device Lora settings (SF, frequency, …), the device should be able to stay asleep as long as there is no incoming packet with this very settings ? I am thinking about remote area with very low radio, and probably no problem finding a free LoRa sub-band.
Do we know what power does the LoRa radio module takes to listen to packets ? Is this a significant ? Is this also different on TTGO boards and on Wisblock boards ?
Ultimately, has it been envisioned to sync the clocks of the mesh devices so that they can all fall gradually asleep when nothing happens, until they all wake up every 15 minutes (for instance) to listen to each others and see if there is anything in the mail ? If not, sleep 15 more minutes. If yes, stay awoken for 2 minutes, then sleep for 1 minutes, then 2, then 5, then 10, then 15.
Off course, I can understand that this is some heavy trade off, in particular when alternative hardware offers better power requirement.
Some of the reasons esp32 and solar is challenging / requires ‘a lot’ is some boards do not reset after a brown out. And as stated the sleep issues. And that is a major issues for remote nodes, even if it is just on the roof of a home. Hardware choices (Other than 24/7 solar 99.9999% of the time) can help on the brownout issues.
Personally I’ve done three #VanLife builds that all included Solar setups, and not just to charge a phone and run a fan. Think operating microwaves. Concerns about panel sizes are certainly valid in some use cases, but for the majority of mine they are the least important.
I recommend learning about the 80% / 20% ‘rules’.
Nodes that can operate inexpensively 20 percent of the time could, in some situations, provide 80 percent of the ‘value’.
When I think about most of this stuff a big area of concern is not just cost, but over all availability. Used solar panels are showing up all over the place for a fraction of the original costs, same with batteries. I think in a lot of situations the biggest ‘cost’ is the person or people that have the ideas, and the skill to implement them.
A used home / commercial soar panel, secured to an existing roof like structure, a use car battery and a $10 charge/load controller can be the starting point for introducing over a Billion people the huge wealth of information technology has amassed and makes accessible with inexpensive devices.
The inaccurate battery display problem for the heltec is solved.
If you use the newest WiFi webUI you can change the ADCmultiplier ratio, so no need to recompile the sourcecode anymore.
You find this under ‘Settings’ > ‘Power’ > ‘ADC Multiplier Override ratio’
You can calculate the value simple, if the battery is fully charged (4.23 Volt) and the display gives another lower value, divide 4.23 by the displayed value which gives you the new ADC multiplier.
I’m thinking about using a helltec 2.1 as a repeater. The current used in repeater mode is between 40 and 50 mA. When sending it is about 160 mA.
I did no accurate measurement and used a simple USB-tester.
Better and solved are two different things. Batteries get warm and charge really slow with heltec for me still so I am not comfortable using them with a battery.
Agreed, the heltec-2.1 board’s charging current is low, about 100mA.
For a solar relay you preferable have a charging current as big as the solar panel can generate.
I ordered one of these to experiment with:
for my solar powered relay. The solar panel is 5W (20V/0,25A).
I will use this with a 10000mAh LiIon battery.
About the Wisblock, i’m not confident I will be happy with it.
The connectors look so fragile and you need an extension board if you want to connect something more than I2C.
I prefer something where I can poke in with my soldering iron
In case other readers wonder, this issue may be specific to heltec devices, it is not happening with TTGO LoRa32 boards, at least not with current latest version.
For people already owning a board with a defective charging circuitry, but happy with the board otherwise, you may want to keep the board and simply bypass the charging circuit with a TP4056 module (very cheap, very common hardware).
You do not need to use the charging facility of the LoRa board if it does not suit solar charging.
In my experiments, I use either a small TP4056 board (this costs about $3 for 5 units delivered) with a custom resistor to ensure better efficiency with my small panels, or a ready to use small CN3791 MPPT board ($3 per unit delivered).
Connect this straight to the battery, bypassing the lora board included charger, and you are good to go.
1- TP4056 is not a MPPT charger. So the maximum charge current is the current delivered by the panel while a MPPT charger can charge with more current than the panel delivers. So it is more efficient which will be important in periods with less and/or weaker sunlite.
2- TP4056 typically want 5 Volt input upto 8 Volt(absolute maximum).
With a solar panel of 12-18V it will burn out.
3- A TP4056 on itself does not have protection for draining the Lion below save value, the battery will be damaged soon.
I had thought of using Bluetooth as a trigger for turning on Wifi. When paired it enables wifi for 5 mins
If we served the meshtastic.apk from the Esp32 it might look something like this:
You see a sign at burning man, we’ve got this network blah blah. If you’d like to participate pair your BT with [Meshtastic-BT-Address] Once you’ve paired then look for wifi hotspot [mesh-ssid] connect to it.
Users can then access the wifi for 10mins to use the WebUI, or download the .apk to save their battery.
The Waveshare is OK, I found it doesn’t correctly restart following a flat battery. So once it’s discharged you have to visit the node to press the button. OK for some use cases, but no good for mine.
