Ack Packet Error

Hi,
We are encountering an unusual issue. In the 868 MHz band, we successfully send confirmed packets in the uplink and correctly receive downlink acknowledgment packets.

However, after switching to the 915 MHz band and selecting the 915_1 subband, we configured some devices, and everything worked properly.

The problem arises when we delete a device from the EU application and add the same device to the US application. While the uplink transmission works fine, the downlink acknowledgment encounters the following error:
error=“downlink frame from proto error: get data-rate index error: lorawan/band: data-rate not found”

It appears that the second window (2 seconds) retains the EU parameters, causing the gateway to respond with the reported error.

Log Events

The two events in the logs are:

  1. OK Downlink
    us915_1/gateway/XXX/command/down {“downlinkId”:4213496517,“downlinkIdLegacy”:“AAAAAAAAAAAAAAAA+yTaxQ==”,“items”:[{“phyPayload”:“YLwFMQUgGgCMjbRp”,“txInfoLegacy”:{“frequency”:926300000,“power”:20,“timing”:“DELAY”,“context”:“AAAAAAAAAAAA3AAARDxXRw==”,“loraModulationInfo”:{“bandwidth”:500,“spreadingFactor”:9,“codeRateLegacy”:“4/5”,“polarizationInversion”:true},“delayTimingInfo”:{“delay”:“1s”}},“txInfo”:{“frequency”:926300000,“power”:20,“modulation”:{“lora”:{“bandwidth”:500000,“spreadingFactor”:9,“codeRate”:“CR_4_5”,“polarizationInversion”:true}},“timing”:{“delay”:{“delay”:“1s”}},“context”:“AAAAAAAAAAAA3AAARDxXRw==”}},{“phyPayload”:“YLwFMQUgGgCMjbRp”,“txInfoLegacy”:{“frequency”:923300000,“power”:20,“timing”:“DELAY”,“context”:“AAAAAAAAAAAA3AAARDxXRw==”,“loraModulationInfo”:{“bandwidth”:500,“spreadingFactor”:12,“codeRateLegacy”:“4/5”,“polarizationInversion”:true},“delayTimingInfo”:{“delay”:“2s”}},“txInfo”:{“frequency”:923300000,“power”:20,“modulation”:{“lora”:{“bandwidth”:500000,“spreadingFactor”:12,“codeRate”:“CR_4_5”,“polarizationInversion”:true}},“timing”:{“delay”:{“delay”:“2s”}},“context”:“AAAAAAAAAAAA3AAARDxXRw==”}}],“gatewayIdLegacy”:“rB8J//4QD+M=”,“gatewayId”:“ac1f09fffe100fe3”}

  2. Wrong Downlink
    us915_1/gateway/XXX/command/down {“downlinkId”:4086755823,“downlinkIdLegacy”:“AAAAAAAAAAAAAAAA85bx7w==”,“items”:[{“phyPayload”:“YH0Q3gUgAAAA9/6aN4+mXTW1jJZhMoeyiWDF/Wh/”,“txInfoLegacy”:{“frequency”:923900000,“power”:20,“timing”:“DELAY”,“context”:“AAAAAAAAAAAA3AAAPGHoAw==”,“loraModulationInfo”:{“bandwidth”:500,“spreadingFactor”:9,“codeRateLegacy”:“4/5”,“polarizationInversion”:true},“delayTimingInfo”:{“delay”:“1s”}},“txInfo”:{“frequency”:923900000,“power”:20,“modulation”:{“lora”:{“bandwidth”:500000,“spreadingFactor”:9,“codeRate”:“CR_4_5”,“polarizationInversion”:true}},“timing”:{“delay”:{“delay”:“1s”}},“context”:“AAAAAAAAAAAA3AAAPGHoAw==”}},{“phyPayload”:“YH0Q3gUqAAADAAIAcAMQAP8BprnqEw==”,“txInfoLegacy”:{“power”:20,“timing”:“DELAY”,“context”:“AAAAAAAAAAAA3AAAPGHoAw==”,“loraModulationInfo”:{“bandwidth”:125,“spreadingFactor”:10,“codeRateLegacy”:“4/5”,“polarizationInversion”:true},“delayTimingInfo”:{“delay”:“2s”}},“txInfo”:{“power”:20,“modulation”:{“lora”:{“bandwidth”:125000,“spreadingFactor”:10,“codeRate”:“CR_4_5”,“polarizationInversion”:true}},“timing”:{“delay”:{“delay”:“2s”}},“context”:“AAAAAAAAAAAA3AAAPGHoAw==”}}],“gatewayIdLegacy”:“rB8J//4QD+M=”,“gatewayId”:“ac1f09fffe100fe3”}

It seams like the node preserve EU parameters for the second windows. Is it possible?
Thanks

Which version are you using? And did you re-activate (OTAA) the device after changing the region?

Hi, I’m running ChirpStack using Docker with the following images:

  • chirpstack/chirpstack:4
  • chirpstack/chirpstack-gateway-bridge:4

I’m utilizing three gateway bridges: two with the semtech_udp protocol (one for the EU and one for US915_1), and one with the Basic Station protocol (also for US915_1).

Both the EU and US gateways are WisGate Edge Pro models. The EU gateway is connected to the EU Semtech bridge, while the US gateway is connected to the Basic Station US915_1 bridge.

To troubleshoot, I attempted to clear all device address entries in Redis, but this did not resolve the issue.

Currently, everything works correctly when the US gateway is connected to the semtech_udp bridges. Therefore, it appears that the problem is related to the Basic Station bridge. I haven’t yet tried reconnecting the gateway to the Basic Station bridge to see if the problem reoccurs.

I haven’t tried reactivating OTAA since the nodes uses ABP. I have reactivated all the nodes and reset the counters that retain the previuos EU value upon deletion and recreation. It seems this data is stored in Redis with the keys.

Thanks for your help
Pierpaolo

    chirpstack/chirpstack:4
    chirpstack/chirpstack-gateway-bridge:4

This doesn’t tell which version you are using, :4 means that it will pull the latest v4 version at that time available.

You need to re-activate the device in ChirpStack after changing the region configuration. Either using the ABP activation or by sending a new join-request.