I have a 8 channel gateway on the US915 region. I have two devices, both OTAA, each on a different set of channels. I would like to configure one to switch to the other set of channels, so they are both on the same set. How would I enable this functionality? Is the functionality for this device specific? I came across this thread but this seems to focus on the EU region.
[[network_server.network_settings.extra_channels]] is an option but I would like the device to only work within the specific channel sub band, after join attempts on the entire 64 channel uplink spread. Any explanation would be helpful.Thanks for your time.
LinkADRReq requesting the end-device to change channel
# Enable only a given sub-set of channels # # Use this when ony a sub-set of the by default enabled channels are being # used. For example when only using the first 8 channels of the US band. # Note: when left blank, all channels will be enabled. # # Example: # enabled_uplink_channels=[0, 1, 2, 3, 4, 5, 6, 7] enabled_uplink_channels=
So what I understand its that you have the server well configured (as Brocaar said) but you have to devices that are configured on a different sub set of channels and the gateway only supports 8.
The problem in 915 is that CFList does not exist, so devices do not know which subset needs to be used. In EU we have 3 fixed channels, and then CFList tells us wich 5 channels we have to use. That are the extra channels in the other post
I don’t really know if there is an automatic process to select channels in 915, what we do is sell devices that can change the subset with a configurator so the client can select what subset of 915 want.
An US915 device should try all channels for OTAA. This means that initially there will be some packet loss, but after a successful OTAA, LoRa Server will use the mac-commands to communicate the enabled channels (
enabled_uplink_channels) to the device, which should match the channels to which your gateways are configured
Well, last time I tried this it did not work, but that was around one year ago.
RisingHf devices seems to want the channels configured before anything at least in the version I was trying for 915
Apologies for reviving this thread, but I’ve come across an issue like this again. I am attempting the fix you described brocaar, but loraserver does not seem to be taking this config option. I am using version from November 8th, could it be an out of date issue?
This setup is in a docker compose project. I am also using a Sentrius Laird RG191 gateway with devices from Netvox, specifically RB11E.
The end devices seems to be configured on the second set of US915 and will join on the second set of channels, then it will send an initial uplink, the resulting downlink will contain an adr command to set the channel mask to 0-16. I would like to keep the device on specifically the second set of channels. Setting
enable_uplink_channels=[8,9,10,11,12,13,14,15] does not seem to resolve this issue. Any advice or help would be appreciated, thank you.
If anyone happens to find this thread, my issue with above is that it seems that the loraserver.toml file needs all configuration parameters filled in. My mistake. Simply having only the configuration parameters you need is not enough.
Parameters that are not provided will fallback to the defaults. It might be that you did not restart LoRa Server after changing the config file? (see for example this config file https://github.com/brocaar/lora-gateway-os/blob/master/layers/loraserver/meta-loraserver/recipes-loraserver/loraserver/loraserver/config/us915_1.toml)
From what I remember, I did restart the docker service in an attempt to make the changes. I used a loraserver.toml file similar to whats above. I believe I am correctly reading the config file because I intentionally malform a config parameter and that shows up on the debug logs. Perhaps it could be me malforming the config file in some other way?