Yes, that is correct (or it will use the CFList on OTAA join).
Hello,
iâm a little bit lost with this topic:
I have my enabled_uplink_channels = [] in the loraserver.toml
No extra channels.
No gateway profile (not a good idea i know) but it seem that everything works with the default Mac address in global_conf.json.
And when iâm connecting one of my end device, which is using 8 channels, i received every frames that i send 
Iâm using the EU_Band and i really donât understand what is the point of the enabled_uplink_channels field in loraserver.toml
Thanks in avance 
To give you and example which would apply to the US915 band:
By default there are 64 + 8 uplink channels defined for the US band. Most devices only support 8 + 1 channels. Therefore a devices will hop over all 64 channels for OTAA activation, this means there will be packet-loss initially. By configuring the enabled_uplink_channels to for example channels 0 - 7, LoRa Server knows which channel-mask to send to your device. Either using the LinkADRReq channel-mask, or the CFList channel-mask (LoRaWAN 1.1).
On other words, when configured correctly it gives LoRa Server the information how to configure your device through mac-commands (or the CFList in LoRaWAN1.1).
The gateway-profile gives LoRa Server the information how to configure your gateway(s).
Of course the channel-configuration in loraserver.toml and the gateway-profiles (must be used together with the LoRa Gateway Bridge!) must overlap.
It does not restrict LoRa Server in which frames are accepted. All frames received are processed (when they contain valid data).
1 Like
Ok i think i get it !
Just to be sure, in ABP mode, in the device profile, should i enter every channels wich the device use?
And the channel-configuration and the gateway-profiles does not affect the ABP mode, itâs only to expand the OTAA capabilities.
Am i right?
And the channel-configuration and the gateway-profiles does not affect the ABP mode, itâs only to expand the OTAA capabilities.
Only the channel-configuration. The gateway-profiles are only there to configure your gateways. It doesnât change the way how LoRa Server is operating.
(e.g. when you configure 16 channels in LoRa Server and only configure 8 channels in your gateway-profile and LoRa Gateway Bridge is configured to reconfigure the packet-forwarder then you basically have a malfunctioning network as you will have packet-loss on 8 channels).
Itâs a little bit hell in my brain now
If i configure my loraserver.toml to get 8 channels (3 default EU + 5 extra) and i configure 8 channels in my gateway profile, i will not have mismatch?
But, if i want to use 16 channels, i have to configure the 16 channels in the loraserver.toml and create 2 gateway profiles (iâm using the IC880A so i can listen only 8 channels) , i will be able to listen all of 16 channels?
Iâm not sure that the lora-gateway bridge is reconfiguring the packet forwarder, how can i check that?
1 Like
Have you seen this documentation? https://www.loraserver.io/lora-app-server/use/gateways/. If this is not clear, please let me know how it can be improved
Again: the gateway-profile only affects the gateway itself. With or without gateway-profiles, LoRa Server operates the same. It is just an easy way to push the same config (gateway-profile) to a group of gateways, instead of updating each gateway individually.
If I understand correctly, the channel mask sent to the end devices (as configured in the loraserver.toml file) is independent of the gateway channel configuration. In which case, a network that contains both 8 channel and 16 channel gateways wouldnât work very well.
For example if you configure the loraserver.toml to use only 8 out of the 16 possible channels then there will never be lost uplinks, but half of the channels on the 16 channel gateways would be unused.
Alternatively, if the end devices are configured to use 16 channels, then when they are only around 8 channel gateways half of their uplinks will be lost.
Is there any way around this?
That is correct.
Please note that it also allows you to for example configure 50% of your gateways on channels 0-7 and the other 50% on 8-15 when you have a dense network of gateways or any other kind of mix that you can think of
That would definitely work for a dense network. But the network I am working on will be quite sparse with only 1-2 gateways in range for most up links. I think the only solution is to limit all of the devices to 8 channels.
Could you please explain how to setup the lora gateway bridge? Youâve mentioned setting up gateway channels using the gateway-profile in the web interface. And this is to be consistent with enabled_uplink_channels[] in loraserver.toml. What needs to be done in lora-gateway-bridge.toml?
I have tried uncommenting [[packet_forwarder.configuration]] and uncommenting mac=âgatewaymacâ. The logs says âapply configuration errorâ error=âload config file error: read file error: open : no such file or directoryâ.
Thanks
You must also uncomment and configure base_file, output_file and restart_command. LoRa Gateway Bridge will then read the base_file merges the configuration from the Gateway Profile and writes this as output_file after which it executes restart_command.
The use of
base_file="/etc/lora-packet-forwarder/global_conf.json" and
output_file="/etc/lora-packet-forwarder/local_conf.json" has me confused.
Do i need to create these files first so they can be found? I see an error in the logs: ââŚ/global_conf.json: no such file of directoryâ. Does global_conf.json already exist elsewhere and I need to enter a different path?
Once local_conf.json has been written to, does it need to be copied to the gateway manually?
Thanks
First of all, this only works when you run the LoRa Gateway Bridge on the gateway. The idea here is to automate the configuration update & restart
Usually the Semtech packet-forwarder comes with a couple example configurations for your gateway. These you can use as base_file. The output_file usually is named local_conf.json.
The Semtech packet-forwarder will first read the global_conf.json after which it also applies configuration found in local_conf.json. You will find more information here: https://github.com/Lora-net/packet_forwarder/.
Hi brocaar,
can u share global_conf.json for US band.
I am trying to activate one of my devices on loraserver.
When turning my device on I can see joinRequest being sent through the registered gateway and joinAccept being sent back.
Even though the joinAccept is being sent my device does not get activated but it sends joinRequest again just to receive joinAccept again and keeps looping this way.
At lora server in lorawan frames shows downlink join accept at 125khz channel but device shows joining denied,actually downlink join accept at 500khz right is it any mistake?
i used version lorawan 1.0.2
thanks for help advance
I would recommend to delete any gateway profile you had setup to your Gateway in Gateway Configurations, and then restart the packet forwarder.
The gateways Iâm currently using support 16 channels (IBTS Kerlink), however, our current LoRaServer configuration is set to only 8 channels. Should I configure each channel; in the loraserver.toml, manually?
We are unsing US915 band, by the way,
Here I add an excerpt of the loraserver.toml regarding that section.
enabled_uplink_channels=[0,1,2,3,4,5,6,7]
Extra channel configuration.
//[[network_server.network_settings.extra_channels]]
//frequency=867100000
//min_dr=0
//max_dr=5
...
...
...
...
And the rest goes on like this as this as every extra channel isn´t used. So, my doubt lies in adding each channel individually in this file.
For the US band, use the enabled_uplink_channels. So when your gateway is configured for channels 0 - 15 (first 16 channels), update this to:
enabled_uplink_channels=[0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15]
Many thanks! Does it matter if Iâm using LoRaServer version 2.4? Or is the same for all versions?