I have added some custom channels in the Gateway and Node Modules.
I am able to receive the data from these new channels and can see the data on App server,
But I think as the Ack is not being received, my module keeps sending the same packet via other channels till it’s retry count!
I have added the same channels in network-server.toml as below, @brocaar can you look into the issue and help me to fix it?
LoRaWAN regional band configuration.
Note that you might want to consult the LoRaWAN Regional Parameters
specification for valid values that apply to your region.
See: https://www.lora-alliance.org/lorawan-for-developers
[network_server.band]
name=“IN_865_867”
LoRaWAN network related settings.
[network_server.network_settings]
# Extra channel configuration.
#
# Use this for LoRaWAN regions where it is possible to extend the by default
# available channels with additional channels (e.g. the EU band).
# The first 5 channels will be configured as part of the OTAA join-response
# (using the CFList field).
# The other channels (or channel / data-rate changes) will be (re)configured
# using the NewChannelReq mac-command.
#
[[network_server.network_settings.extra_channels]]
frequency=864865200
min_dr=0
max_dr=5
[[network_server.network_settings.extra_channels]]
frequency=866800000
min_dr=0
max_dr=5
[[network_server.network_settings.extra_channels]]
frequency=866200000
min_dr=0
max_dr=5
[[network_server.network_settings.extra_channels]]
frequency=866400000
min_dr=0
max_dr=5
.
.
.
.
.
Hi @tushar,
two weeks ago I tried adding some non-standard channel frequencies in EU868 band and it worked well.
In short, I had to adjust the GW channel config (which is crucial - you can not choose frequecies randomly/freely). Then adjust the .toml as you did and also adjust frequencies in the device profile on app server (if using ABP).
Luckily, my device does support NewChannelReq command so after reactivating the device the server sent few downlinks with custom channel config and device accepted it.
If in doubt I would start with your device’s live LoRaWAN frames log where we could see the exact RF settings used for uplinks/downlinks.
You will need to watch multiple messages in sequence which should lead you to things to check, for example:
Server does send NewChannelReq commands, does the device confirm this setting?
If not:
a) Device does not accept such commands (possible with ABP). If it does not accept such commands, are you sure you have properly set the channel plan in the device itself?
b) Device didn’t receive the downlink at all.
One thing I already see is that the device did send the message on one of the IN default cahnnels with SF12. Server tries to respond on the same channel but with SF 10, which means you have RX1 DR offset of -2.
Are you sure about this? Because I can also see the DLsettings=02 in RXParamSetupReq, which I think is a RX1 DR offset 0, so there seems to be some configuration out of sync.
This downlink message has to be sent with devices default parameters, is the RX1 DR offset of -2 your devices default value after restart/powercycle?
Let us first fix the Data rate offset, I guess the issue is in chirp-stack server configuration.
But the thing is that other nodes having default channels are able to receive the ack!
I have this settings and I am using ABP,
Search RXParamSetupReq in LoRaWAN specification, there is RX2 frequency, RX2 datarate, but also RX1 DR offfset.
Your device profile seems quite standard to me, the DR offset we were seeing is probably set in the NS config file.
It can work like this, I actually tried it too - I had default parameters in device profile and adjusted parameters (RX1 DR offset and RX2 DR) in NS config file. After re/activation the server sent custom channel config to device on default channels. After device acked the config it started working with custom channel config.
If device was reset I had to re-activate the device because it didnt know custom config anymore, but server kept using it.
