Hey everyone! Just a couple things, first I wanted to say thanks for all the help so far, this is an awesome community filled with very helpful people. Second, I am still waiting for my ttgo modules to come in, I am going to set up a couple of relays as I live pretty far away from all my collegues that are also getting into this. I was curious about the power usage as I was hoping to easily add solar charging to a custom enclosure I am designing for relay stations. any info on that would be great!
Later today I’ll reply with links to the esp32 and NRF52 power measurements spreadsheets - which I bet will help a lot.
You can find more about repeaters on the main discussion thread: https://meshtastic.discourse.group/t/headless-base-station-repeater/
More on relaying messages can be found here: https://meshtastic.discourse.group/t/how-do-multiple-mesh-networks-interact-if-at-all
My T-beam with firmware 0.7.x draws about 70mA (strong fluctuations) in average while running and connected via BT and about 140mA while transmitting over the LoRa radio.
The nrf52840 prototype boards in the 22dbm version draw about 9mA while receiving and connected via Bluetooth without any power optimizations.
Yep - that right there in a nutshell is why I had to do the “your ESP32 periodically will sleep bluetooth for long periods of time (default 15 mins)”. Because while in this mode (which is called ‘light sleep’ state in the power management section of the meshtastic dev docs), the ESP32 is effectively off (but the lora radio is on and will wake the main CPU if a packet comes in).
To get a few days of runtime, it was essential to have the ESP32 be mostly in this light-sleep state.
The NRF52 is amazing wrt power consumption, so for those boards I think there will be effectively no need for the light-sleep state. Because we can leave bluetooth always alive for nearly ‘free’. On a NRF52 I think the only time we should turn off bluetooth is when the node is operating as a repeater/router.
I’m was not having too much success with earlier versions, but 0.9.1 is working with minimal hassle.
A minor inconvenience is sleep mode, " . . . will wake the main CPU if a packet comes in" - doesn’t wake & any messages sent while a node is asleep are lost. The only way to wake from sleep that I can find is the GPIO38 button. But that’s no big deal. Bluetooth is much improved. Thanks for all your hard work.
Just a suggestion, and a fairly obvious one at that . . . Could auto-detection of power applied at the USB be used to disable sleep mode while power is present?