Low power consumption for solar router nodes

Support
1

I often hear that operators have not configured their solar nodes for minimum power consumption, especially ESP32 devices.

As a result, the battery of solar cells is empty after just a few hours instead of days. In addition, a much larger solar system is required or more expensive hardware.

With the correct settings, a node consumes between 15-35mA, depending on the load. An 18650 Li-Ion battery should last for 3-4 days. To do this, you must deactivate all consumers that are not required. The devices consist of different components, all of which consume electricity.

Why is the node powered by solar at all?

Either you want a router or repeater in an exposed location, e.g. on the roof or mountain, where you have no power connection. Or you want to supply your client with a rechargeable battery via solar power even during power outages. In my opinion, combining the two does not lead to minimal power consumption. I recommend separate nodes for client and router or repeater.

A router or repeater serves as a gateway and requires no display, no LED, no Bluetooth, no WiFi, no serial debug, no MQTT. Its task is to forward data.

The display can be switched off after 1 second or, better still, completely, for which the device must be configured as a ROUTER. Disable LED heardbeat switches off the LED. Bluetooth and WiFi can be deactivated because configuration is possible via USB or a second admin channel. Serial Debug is also a power guzzler. MQTT can be ignored and rebroadcast limited to LOCAL_ONLY. Power Saving must be activated to get below 20mA for reception. Depending on the position of the neighboring nodes, the TX transmission power can be reduced to 14-19dB or in combination with a better antenna and ideal position of the node.

The battery should be connected directly to the battery connection and not via 5V USB. The 5V voltage converter sometimes consumes too much power.

If you have extra devices for routers, you can use CLIENT_MUTE to reduce consumption. Serial debug, MQTT and transmission power can also be reduced here and rebroadcast LOCAL_ONLY can be configured. Bluetooth remains activated and Power Saving is presumably deactivated.

What are your experiences and tips?

3 Likes
2

Great points, and excellent analysis!

I do NOT disagree, however, I’ve yet to move my rooftop from Router_Client to simple Repeater…I’m an isolated mesh and my rooftop has the most accessible point on the whole mesh, so it stands to reason to set it as a repeater…however…

I’m not keen on not being able to “see” it…I would love it if we could get an option to have a router-repeater optionally show up on the nodes list…even if the update time was something like every 24 hours or maybe only as needed. It could respond to a location request but maybe not initiate any unsolicited outbound broadcasts - other than those packets being forwarded/repeated.

I also use the range-test module quite a bit, and having the node hidden from the node-list would preclude the ability to do that.

Another reason, I’ve got an environmental chip in my rooftop node, so it’s a bit of a pseudo “weather station” for the mesh, so making it disappear completely is less than ideal.

I feel like there’s a missing piece in the roles available to us. We could use a role that would make it clear this is a fixed, unmanned node, with all of the qualities of a router/repeater while still maintaining a presence, even if only tenuously, on the node list. Maybe that role IS Router_Client and if that’s the case, I’m exactly where I need to be. It still feels like there oughta be a flag one could set to mark any node of any kind “unmanned” for lack of a better term.

Great post, thanks for starting it!
Pol

1 Like
3

“I also use the range-test module quite a bit, and having the node hidden from the node-list would preclude the ability to do that.”

Repeater with Rebroadcast ALL_SKIP_DECODING and “Zero Hop Repeater” enabled should work for invisible repeater in the middle …

1 Like
4

Ah nice, and thank you! I hadn’t considered it from that direction…but that would allow a multi node range-test so long as the intermediary nodes are all using that zero-hop config… :thinking:

Thanks for sharing, I’m digesting your low-power solar code now…looks awesome, BTW! Think I’ll have to do some experimenting this weekend!

Regards,
Pol

1 Like
5

Hack the software to only relay messages that are different length than automatic messages,
ie only relay human typed messages.
Don’t waste PV energy on ping/telemetry messages.

1 Like
6

Also don’t mess with the hop_limit, it can get into an infinite loop if you don’t decrement it, ie msg stuck on network.

You could only relay messages where the hop_start was 7, ie originally inteded to be long range msg. Or anything above the default 3.

7

There are typologies, e.g. in caves, where a chain of more than 7 repeaters is required. Zero Hop Repeater" is intended for this situation.

Your assertion about “infinite loop” is only true if the message is forwarded in the meshnet for longer than 10 minutes (FLOOD_EXPIRE_TIME).

Before a message is forwarded, the system checks whether this message has already been forwarded - first check if their recentBroadcasts table contains the (from, id) pair that.

I agree with you that you should only play with Hop Limit if you want to use it consciously. In principle, the hop limit should be limited to 3.

It would have been nice if the header of Meshtastic supported other typologies and also contained the ID of the repeater, as DisasterRadio does, for example.

8

I have the idea of two additional features to reduce the sending of messages. How you detect automatic messages?

  1. PortNum filter

This corresponds to your idea of not routing e.g. ATAK or waypoints etc. You could also filter certain intervals per message type (PortNum) per sender, e.g. only forward position or telemetry every 60 minutes per node.

  1. Sender/receiver filter

The idea here would be to operate a private gateway that only forwards messages from/to its own nodes.

This could be a solution for very large mesh networks with many nodes in order to reduce the sending of messages for solar nodes.

9

If you look at debug window you can see which automated msg has what length and simply ban those lengths.

FLOOD_EXPIRE_TIME is only effective if the table is not getting full.

Another idea, when battery is low don’t forward broadcast msgs, only p2p ones, ie destination is not FF.

1 Like
10

Hint from GUVWAF at Discord: “A router you can still see. A repeater is invisible unless you already had it in the NodeDB, then you can traceroute it to see if it’s still reachable.”

1 Like
11

I tried setting one of my nodes as a repeater to test this, and sadly, once it’s in repeater mode it doesn’t respond to location requests or traceroutes as long as its in repeater mode. This is true even if it’s already been in your list. Toggling it back to client gets it responding again, but not in repeater mode.

Best,
Pol

1 Like
12

Thank you for this very helpful information.

I’m planning a rooftop node but is not a very good position (two-story building). From my understanding it will be better to not use router or repeater in my location so I am trying to understand the better settings for a solar rooftop heltec in client mode.

I have disabled the leds and setup the admin channel. I’m planning to enable power saving as soon as I can tune the ADC multiplier and then I will switch to a remote admin node settings.

Are there other settings I should take care of? My personal devices are using some private channels that are not loaded on the roof node, I’d like to keep it as broadcast all to help the community.

Thank you

13

Power saving enabled with Bluetooth timeout 1s force light sleep after 1s. Bluetooth disabled and serial disabled for light sleep.

First let LED on to notify light sleep. For 30 seconds you can’t watch LED ticks. The node will wakeup every 30 second to handle tasks.

You can also buy a USB multimeter to monitor current consumption. During sleep voa USB port the current drops to 5mA or so.

Screenshot_20240708-090107
Screenshot_20240708-0901071080Ă—1067 75.5 KB

14

Position requests won’t work, traceroute should still work unless you set the rebroadcast mode to ALL_SKIP_DECODING.

15

Why position request don’t work with light sleep? MCU wakeup should triggert by LoRa RX event.

16

I was responding to @polamnus who was talking about REPEATER role.

1 Like
17

Thank you very much.

I sticked with the default value for waiting BT bot other than that it seems to work great.

Even with LED off, it will blink every 30s when it gets out of the light sleep.

My USB multimeter cannot measure less than 0.01A so I have a strange behavior with time tracking, but the mAh counter seems accurate.

I did a first test of 35minutes and recorded 12mAh. In that test I had 3 TX event, clearly visible by the power consumptions going to 0.09-0.10A for about 10s

1 Like
18

21mA per hour via USB is good. If you connect the LiIon directly via the battery connector, then in my experience this reduces the consumption by 3mA.