That would be perfectly fine if we could access all settings of a remote node within the apps via the mesh. No CLI, no computer, no pip3 mess to worry about.
While having full settings via Bluetooth has been a game-changing feature and I will never be thankful enough for that, in my opinion walking to remote nodes should be done mostly to update firmware and fix hardware, not to change settings.
Probably most of the people don’t even know what ‘CLI’ means…
On my solar powered remote node, bluetooth is disabled, for power saving reasons. Another remote node will be in ~ 30 km distance, quite an effort to have to travel so far just to change a parameter. I guess i’m not the only one… That’s why i don’t understand that this is so much down on the priority list.
Indeed my mesh behaves strange / unreliable since some time. That time is pretty close to the moment i started using the admin stuff. I’m just disabling the function again, when i can reach the nodes, live…
Firmware update is not going to work over Lora.
Hence I wrote
walking to remote nodes should be done mostly to update firmware and fix hardware, not to change settings
Because very few people have the need for this currently. And the biggest factor is this:
The developers work on what they’re passionate about and frankly what they want to see in the project. Does this mean it’ll never happen? No, but we very well can’t force them and nor should we, especially for something that is essentially a low priority ticket item. Open an issue, if there isn’t one already, in the python repo and then just want and see what happens.
I made the sticky in the meeting about getting the admin channel more reliably, so I do like this feature but the Python API needs a lot of work for it to be functional.
There are a number of issues with remote administration in the Python CLI, I expect the admin channel settings functionality will be working elsewhere first, it already works in the android app to send the shutdown and reboot admin messages.
The biggest issue is that the python API lets you send random assortments of various settings “over the admin channel” because that is how it worked in 1.2. One of the main reasons that 1.2 had to be re-written was that the config was a monolith that became to large to send as a single packet, so to send any commands for settings over the mesh they need to be sent with these individual config packets so they take up less air time. These are the logical groups of settings in the docs, apple, android and webui.
It also makes a bunch of extra channel calls wanting a response that create an ack storm (which we think causes the timeouts you are getting)
I have a lot of the plumbing in place in the apple apps (every settings change uses an admin message already, just locally) and will be adding some remote configuration functionality at some point, it is being worked on in the new C# command line but it is fundamentally broken in the python CLI and if it is going to work there someone needs to pick it up since it is not a simple fix.
I just noticed by a power measurement that the TX power from the RAK4631 on 2.0.12. is 0 dBm (or even less) INDEED! So maybe that remote parameter request result has been correct?
Just for confirmation i erased the flash again and re-installed 2.0.12 and applied the settings.yaml. Still, 0 dBm!
Then i took a different hardware RAK4631. Same result!
I read something about a power issue in the new release 2.0.13. Will check that now…
Confirmed! 20 dBm = 20 dBm, from now on!
did 2.0.13 bring back the dBm?
Yes! And somehow the power cunsumption even dropped by ~ 15 %. Strange…
Did you verify this result with a reception from other devices?
For me is:
I used 2.0.13 and for now, I got 3 devices on my table:
2x RAK
1x T-Beam
I connected to one of RAK now via BT and observe:
T-Beam: RSSI -11, SNR 7,8
RAK: RSSI -44, SNR 6,5
No, i measured the output voltage of the TX with an oscilloscope in which the internal 50 Ohm termination resistor was enabled.
Setting to 20 dBm results in:
V2.0.12: 86 mV at 50 Ohm, is ~ 150 µW
V2.0.13: 2,25 V at 50 Ohm, about 100 mW. About 28 dB more Signal!
It’s better. Thank you.
@SR7673 may you also check with this firmware https://github.com/meshtastic/artifacts/raw/b3c17dad4709f2fc334bc107d73c94f86abfd7b1/pr/pr2025-firmware-2.0.7.2a84d39.zip
Why? Do you expect advantages?
I’m asking because I need to know does this firmware has a bug. I use this build for my solar node located in mountains.
If it’s affected, I need to upgrade FW on this node ASAP when weather conditions will be acceptable for going to this location.
OK, i’m going to test that for you. First i need to build the UF2 file…
Will be back soon.
I confirm, with this uf2 file the output power is below 0 dBm. So it is worth to upgrade.
Congratulations! You will have a much improved range soon! Go on!
Holy Rosin!
@garth @caveman99 we got 44 km LOS range with around of zero power output!
Did you remember this pics:
Thank you for measurement!
What type of antenna did you use? And what frequency?
