EU_868
+
1 Like
Or the power issue assumptions are not correct, I have not seen any issues and they have not affected all users.
Hmmm, well, my node is also for 433 MHz, RAK4631(L), just like the one of the other thread: Need help with range issues using Meshtastic on RAK4630 modules on 433MHz frequency - #4 by Crichton
Could that make a difference? We would not expect that. So maybe someone else who is using the RAK4631(H) model could do a serious power measurement. I don’t have modules for 866 MHz here…
But it should be easy to detect if there is a 28 dB change of power or not! Simply by watching the rssi reading in a fixed antenna configuration.
You can set your region to UNSET and see what 0 power looks like, won’t do anywhere near 44 KM in my experience. There may be an issue, but it seems to be pretty narrow as it is not affecting most users. RSSI is not always a great lora measurement, especially with a bunch of devices in the same room.
How can you know that?
Maybe even most users don’t know it. They just wonder why their signal doesn’t go as far as expected, just like i did, until i measured this morning…
1 Like
There are three people so far, I have 5000 app users and have sold a ton of RAK devices, it it was affecting everyone I would have heard about. 433 is limited to 12db so that is a factor as well.
1 Like
Aah, that’s why you don’t like that someone rises to idea to avoid using the RAK19007. I already guessed… 
Well, how many of these 5000 app user use the RAK4631? Doesn’t most of them use the TBeam or TTGO LoraV2.1-1.6? And how many of those who use the RAK4631 can do serious power measurement?. And how many of those who can do it, did it actually?
1 Like
You are having enough issues with meshtastic in general that adding custom hardware to the mix seems real likely to add even more confusion, has nothing to do with having sold RAK devices.
Yes yes, that’s right. And i agree, there can be additional problems if you don’t know what you do.
@SR7673 @IZ1IVA The --get and --set commands for remote nodes work again using the latest 2.1.1 CLI release.
2 Likes
Cheers, will try again soon!
Hello GUVWAF. Thanks for working on this!
I’ve updated the CLI and did a first test between a TBeam V1.1 and a TTGO LoRa V2.1-1.6 both running firmware V2.1.2
Obviously there is an answer to the request but the answer is not the right one.
Some examples:
meshtastic --dest ‘!2597765c’ --get device.role
Connected to radio
Requesting current config from remote node (this can take a while).device:
serial_enabled: true
node_info_broadcast_secs: 10800Completed getting preferences
or
meshtastic --dest ‘!2597765c’ --get bluetooth.enabled
Connected to radio
Requesting current config from remote node (this can take a while).bluetooth:
fixed_pin: 123456Completed getting preferences
or (here, there is much more output than just the value of the requested parameter)
meshtastic --dest ‘!2597765c’ --get lora.tx_power
Connected to radio
Requesting current config from remote node (this can take a while).lora:
use_preset: true
modem_preset: LONG_SLOW
region: EU_433
hop_limit: 7
tx_enabled: true
tx_power: 10
channel_num: 1Completed getting preferences
Afterwards i tryied to set the lora.tx_power to 6 dBm. After a few attempts this worked:
meshtastic --dest ‘!2597765c’ --set lora.tx_power 6
Connected to radio
Requesting current config from remote node (this can take a while).lora:
use_preset: true
modem_preset: LONG_SLOW
region: EU_433
hop_limit: 7
tx_enabled: true
tx_power: 10
channel_num: 1Set lora.tx_power to 6
Writing modified preferences to device
Waiting for an acknowledgment from remote node (this could take a while)
Received an ACK.
But then, when trying to check if the power has actually been changed i’m just getting
meshtastic --dest ‘!2597765c’ --get lora.tx_power
Connected to radio
Requesting current config from remote node (this can take a while).
Aborting due to: Timed out waiting for an acknowledgment
I tried several times without success. The signal level is 100% and i see on the display of my TBeam that the remote node has been active after the request. Also it is no duty cycle issue…
So, there seems to be some progress but it is just partly working so far and quite a struggle.
Maybe this helps to find some bugs in the code somewhere…
I think the timeout should depend on the setting (long_slow, long_fast etc) and on the number of hops.
Regards.
PS: After setting the power to 6 dBm remotely and checking that that parameter by connecting the remote node via cable and reading out via the CLI, it is actually confirmed that the power was set to 6 dBm! So setting the power actually worked!
You are requesting a config packet not an individual setting now, so do
meshtastic --dest ‘!c14b7b6f’ --get serial
It will return all the settings for serial and then you can send an admin message with your updated values.
A --get command will always show the full field, but the settings that are just the default are not shown. So e.g. if you use device.role and the role is not there, it is still the default (client). You can also just use --get device and the result will be the same.
I can’t replicate timeouts and you showed that --get worked before, so I’m not sure why it failed. However, when you used --set it mentioned that it received an ACK, so you can assume it is correctly set.
One thing you can try is adding the --no-time command, e.g.: meshtastic --no-time --dest ‘!2597765c’ --get lora.tx_power.
Despite the --no-time, i’m getting timeouts sometimes. It is no clearly reproducable.
Anyway, thanks for working on this!
I’m afraid it might be a lower-level problem of the TTGO LoRa V2.1-1.6 then, since it is still unclear to me if they can do proper channel activity detection. I have no issues testing between a T-Beam and RAK4631.
That sounds good. I will test it tomorrow.
Thanks again.
Now i’ve done a test between a TBeam V1.1 and a RAK4631 both running firmware 2.1.2:
meshtastic --dest ‘!9ef9e005’ --get lora
works
meshtastic --dest ‘!9ef9e005’ --set lora.tx_power 7
Got an ACK.
Then
meshtastic --dest ‘!9ef9e005’ --get lora
did not work (3 attempts). Then:
meshtastic --dest ‘!9ef9e005’ --reboot
works. Then:
meshtastic --dest ‘!9ef9e005’ --get lora
worked in the 3rd attempt.
Conclusion:
Still not without occasional trouble but a big progress and usable even beyond reboot and shutdown. 
Yesterday you changed the Tx power from 10 to 6 dBm after which it didn’t work. Now you set it to 7 dBm. Are you sure this is even enough considering insertion losses etc.? I would suggest testing with something else than the LoRa settings.
After doing a --set command, the node will already reboot. So shortly after that command, it will not be able to receive anything for a couple of seconds and afterwards it will start sending its NodeInfo and Device Metrics, etc. Trying to get the value shortly afterwards may be difficult. If you got the acknowledgment after setting, then you know it will be set.
If you have other nodes in range this makes it harder as well (especially since you set a hop limit of 7 on LongSlow), but it is not a problem of the CLI. I tested with only two nodes.
Yes yes, don’t worry, the distance is just a few meters. I can read on the display of the TBeam that the signal is (still) 100 %.
Yes, i know. I’m waiting until the remote node comes back on the local node (“0 seconds ago”…)
Yes, confirmed.
Yes but this is the real world in which the system has to work later. My recent tests were just over 1 hop though. (Just rarely my mesh does 4 hops, usually its 3 or below).