IN865 Server sends NewChannelReq downlink with 867.1,867.3,867.5MHz frequency

Hello,

I am using IN865 Band. I have added custom channels in Gateway Profile with below frequencies:
865200000
866185000
866385000
866585000
866785000

But I am getting a strange issue that server send NewChannelReq with 867.1,867.3,867.5MHz frequencies as shown in attached image. but I didn’t enable this, and doesn’t know how to configure NewChannelReq downlink for device.

Please help me to get rid of this downlink problem, I didn’t want to send NewChannelReq downlink.

Thank You

Hi @mightyChamp

Please check your chirpstack-network-server configuration .toml file Extra channel configuration section

Add your custom frequency here and restart the server.

# 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.
  #
  # Example:
  # [[network_server.network_settings.extra_channels]]
  # frequency=867100000
  # min_dr=0
  # max_dr=5

  # [[network_server.network_settings.extra_channels]]
  # frequency=867300000
  # min_dr=0
  # max_dr=5

  # [[network_server.network_settings.extra_channels]]
  # frequency=867500000
  # min_dr=0
  # max_dr=5

  # [[network_server.network_settings.extra_channels]]
  # frequency=867700000
  # min_dr=0
  # max_dr=5

  # [[network_server.network_settings.extra_channels]]
  # frequency=867900000
  # min_dr=0
  # max_dr=5
1 Like

Hello,

Thanks for support. I have changed this configuration according to my channel frequency need.

But I am now getting my setted frequency by NewChannelReq downlink.
I don’t want to send NewChannelReq downlink.

Is there method to stop it?

Thank You

Hi,

Disable mac-command setting set to true in chirpstack-network-server configuration.

# Disable mac-commands
  #
  # When set to true, ChirpStack Network Server will not handle and / or schedule any
  # mac-commands. However, it is still possible for an external controller
  # to handle and / or schedule mac-commands. This is intended for testing
  # only.
  disable_mac_commands=true

Thanks dear, but I have doubt that will disabling mac command, will stop ADR functionality, too?

Yes, it will stop all mac-commands

So, it is not solution of my problem.
If I doesn’t define frequency in network-server config file, then application server doesn’t get these extra frequency data, and if I define network-server sends downlink to configure device for these extra frequency, it seems to impractical, as if thousands of nodes operate in a network, where device is on AC supply, not battery backup, then Each time Server will send NewChannelReq to device.

In OTAA mode NewChannelReq is perfect solution, but in ABP, it doesn’t mean, as already I have configured all extra channel in Node.

Is there any solution so I can disable NewChannelReq Only in ABP mode.
Thank You

Please help me regrading this.
Thank You

Please help me regrading this.
Thank You

This is only one time, after the device has been activated. If you want to use additional channels next to the default channels for your region, then you must add these to the extra_channels configuration, else these channels will never be used by your devices.

After the device has acknowledged the NewChannelReq mac-commands, the NS will stop sending these commands to your devices.

1 Like

As I mentioned that devices are not battery backup, So each day devices starts as new, and For Joining I used ABP method, and for extra channels, I hardcoded those extra channels in node.

If OTAA used for Joining, then sending extra channel frequency plans to node , seems meaningful.

But when use ABP and hardcoded extra frequency channels, then why I waste downlinks for reconfiguration of extra channels every day.

Thank You

Please note that the NS keeps a snapshot of the device configuration, but if the device starts as new (I assume that this means with a frame-counter reset), then the NS will re-sync the configuration with the device.

Having your devices lose their state rather than retain it is a violation of the LoRaWAN specification.

Your devices must retain state or they are not correctly implementing LoRaWAN.

Do things wrong, and you can expect all sorts of difficulties to result.