Hi, I’m using a rak4631 device in mode “is_router true” with a general channel (factory settings, long/fast, EU868) to route all our messages independent of the client channel settings (at least long/fast and EU868 are identical). RAK4631 is running firmware-rak4631-18.104.22.168ab874
Since the router is powered by battery connected to solar panel, I would like to obtain information about the battery level somehow. When changing the channel settings to the factory settings, I cannot see the RAK in my node list (which is expected), but messages are still transferred by the router, so all seems to work well.
Is there a way to obtain frequent information about the battery level of the router somehow? Thanks, Christian
There is no is_router in 2.0, there is a device mode.
If you have the same config but no keys then that device will not share telemetry with your mesh.
Somehow, the is_router command was taken by the FW 2.0 device. Device is still working. There was no hint in the documentation, that this is not working any more for 2.0. What is the correct command to put the device in the correct device mode?
Do you have any recommendation how to set the router devices such that if someone would find the router that he cannot access any messages but at the same time, the router shares telemetry with my mesh?
I found this documentation: Device Configuration | Meshtastic
And I guess, that is what I have to do, right? Namely, “meshtastic --set device.role ROUTER”
Thanks, that’s helpful. I configured the device correspondingly by using the “meshtastic --set device.role ROUTER” command. Actually, after sending the command, the device was still accessible by Bluetooth. Is the mentioned sleep mode of BT starting after some delay? I used the “meshtastic --set bluetooth.enabled false” command to turn BT off, such that the device is invisible for others.
I understand that you want your router-node to forward all messages with same configuration without beeing seen, but you also want telemetry of tthe router node itself.
as i understand it should work like this:
so you can set the router node to some other private channel in same configuration.
like this it will forward all messages with same configuration, including default.
and then you set 1 other node on the same private channel to read the telemetry data of the router.
Basically an “admin” channel to “speak to the router” for config changes and telemetry.
I’ve not yet read into 2.0 so my knowledge is rather old at this point but I think there was something in the documentation to describe exactly that
Thanks kilroy, that’s a practical workaround, good idea. @roland, I actually do not need to administrate the router remotely, but I think this could be combined with kilroy’s proposal of a seperate private channel in same configuration.
@garth I tested the ROUTER Mode of FW version 22.214.171.124. It seems that the power consumption is much higher after activating ROUTER mode, than it was before (CLIENT mode). Actually, two of our RAK devices that worked before with the solarpanel lost battery level pretty fast. Any idea what the reason could be? Shall we try the combined ROUTER & CLIENT mode?
our settings are as follows:
meshtastic --set lora.hop_limit 7
meshtastic --ch-set tx_power 10 --ch-index 0
meshtastic --set device.role ROUTER
meshtastic --set bluetooth.enabled false
All settings were used before exept for the ROUTER setting. Without ROUTER setting battery level was stable between 85-92% for >10 days and dropped when ROUTER was selected.
7 hops creates a lot of mesh activity while not really improving messaging delivery. I would use 3 unless you have used the simulator and determined that extra hops are actually useful
Thanks, we have approx. 25 clients in our channel and through that 3 hops might not be enough. But we will test it, it’s good to avoid too much unnecessary traffic.
Do you have experience with the ROUTER settings? Is this setting helpful in the mesh to give the transmission to routers priority? I got the impression, that the power management of the router setting is problematic with my RAK4631 device.
You can see in the graph at the bottom here that hops greater than 4 are probably not helping much for message delivery and is likely increasing traffic and using more battery.
The new SNR based flood routing preferences ROUTER nodes by delaying retransmission on nearby nodes so the ones at the edge have a chance to rebroadcast first.
Also I don’t think this command is doing anything
meshtastic --ch-set tx_power 10 --ch-index 0
meshtastic --set lora.tx_power 10 would be the right command
I am not seeing any power savings from router mode on my RAK device, but router mode is not using more battery than client either so I would try reducing the hop count.
I reduced hop count of my devices, seems to work now pretty nice. Interestingly, I see now sometimes the text “Max Retransmission Reached” below a message, but message was still received by others in the network.
We would like to better understand the rules and algorithms used to build the mesh network. How routers are prioritized (by a short delay in retransmission of the other clients?) and how the hop count works actually.
We have quite some distance, which we would like to bridge, i.e., 15 km, which we do with 3-4 routers. Each router serves up to 10 devices and the 3 routers are lined up at the shore of a lake from north to south. So, if a message is sent from a client very much in the north of our network, it will go to router 1 → router 2 → router 3 and from there to the clients in the south. From our understanding this might be at least 4 hops. That’s the reason why we thought a hop limit of 3 or 4 could be problematic. But I guess, we do not fully understand how the mesh network is created. Maybe you can send us a link to a more basic introduction. That would be great.
You should be able to import your nodes with locations into the simulator and run some simulations.
You can find some info here as well Mesh Broadcast Algorithm | Meshtastic
You may need to increase the hop limit from 3, but jumping straight to 7 is likely to cause issues.
If router 1 can really only reach router 2 and router 3 really only router 2, then yes, you need one hop per router. Note that the hop count only is decremented from the first receiving node. With three routers (0, 1, 2) and three nodes in range of router 2 (node 3, 4 and 5), three hops will suffice, as you can see from the simulator below.
Like Garth said, if you need more I would advise to increase it to 4 first, as setting it to 7 will cause a lot of unnecessary transmissions and will indeed influence power consumption.