Failure reading au915 device

ChirpStack (v4) Setup and configuration
1

Hello, good afternoon,

I am having problems with the communication of a device. I have a version 3.0 server with gateways and devices on the EU868 frequency. I need to read a gateway (US915) and devices (AU915) installed in Latin America. Since version 3.0 does not support multi-region, I created another version 4.8 server. However, after registering the gateway and the devices, I do not receive any data from them, only the join requests are received at the gateway. What should I configure in this case? I tried another v3.16 server and the same thing happens. In all three servers, configured for that frequency, the same issue occurs.

I hope you can help me, thank you.

2

US915 and AU915 are not the same frequency plan.
US915 gateway will not work with AU915 node.

May be you put in some screenshots to show the region of your gateways and devices?
To show the LoRaWAN Frame of your device too.

Only join request and no join accept means the join is not successful yet.

3

Yes, they are compatible as they use the same frequencies.
In version 4 of ChirpStack, configuring the bridge to AU915, I am able to establish the connection with the device and receive information. However, I do not receive information from other devices that are on the EU868 frequency. It is known that having the port configured to AU915, I will never receive information from gateways on EU868. My question is, which version of ChirpStack or configuration should I use to receive information from both AU915 and EU868 gateways?

4

You just have to use multiple gateway bridges, 1 for AU915 and 1 for EU868, then have the gateways forward to the correct gateway bridge, everything else will work normally.

US915 and AU915 are certainly not the same frequencies, look at the LoRaWAN regional parameters: RP002-1.0.4 Regional Parameters.

US915 uplink channels (902.3-914.9 MHz) are different from AU915 (915.2-927.8 MHz). Similarly, the downlink channels for both plans are not aligned.

Using a AU915 device in US915 gateway will cause all sorts of issues. Namely the one you are experiencing, where you can see the device send a join-request, but when the server sends back the join-accept, it will tell the device to either use frequencies the gateway is not looking for or frequencies that the device cannot support (depending on what region you have the gateway bridge set to), thus no more uplinks after the join-request will be seen.

1 Like
5

Good morning,
Thank you for your response.
Multitech had informed me that there shouldn’t be any issues with this, but it seems that is not the case. I have an additional question regarding the gateway bridge configuration.
In my docker-compose.yml file, I have the current configuration:

version: “3”

services:
chirpstack:
image: chirpstack/chirpstack:4
command: -c /etc/chirpstack
restart: unless-stopped
volumes:
- ./configuration/chirpstack:/etc/chirpstack
- ./lorawan-devices:/opt/lorawan-devices
depends_on:
- postgres
- mosquitto
- redis
environment:
- MQTT_BROKER_HOST=mosquitto
- REDIS_HOST=redis
- POSTGRESQL_HOST=postgres
ports:
- 8080:8080

chirpstack-gateway-bridge-eu868:
image: chirpstack/chirpstack-gateway-bridge:4
restart: unless-stopped
ports:
- 1701:1700/udp
volumes:
- ./configuration/chirpstack-gateway-bridge:/etc/chirpstack-gateway-bridge
environment:
- INTEGRATION__MQTT__EVENT_TOPIC_TEMPLATE=eu868/gateway/{{ .GatewayID }}/event/{{ .EventType }}
- INTEGRATION__MQTT__STATE_TOPIC_TEMPLATE=eu868/gateway/{{ .GatewayID }}/state/{{ .StateType }}
- INTEGRATION__MQTT__COMMAND_TOPIC_TEMPLATE=eu868/gateway/{{ .GatewayID }}/command/#
depends_on:
- mosquitto

chirpstack-gateway-bridge-au915_0:
image: chirpstack/chirpstack-gateway-bridge:4
restart: unless-stopped
ports:
- 1700:1700/udp
volumes:
- ./configuration/chirpstack-gateway-bridge:/etc/chirpstack-gateway-bridge
environment:
- INTEGRATION__MQTT__EVENT_TOPIC_TEMPLATE=au915_0/gateway/{{ .GatewayID }}/event/{{ .EventType }}
- INTEGRATION__MQTT__STATE_TOPIC_TEMPLATE=au915_0/gateway/{{ .GatewayID }}/state/{{ .StateType }}
- INTEGRATION__MQTT__COMMAND_TOPIC_TEMPLATE=au915_0/gateway/{{ .GatewayID }}/command/#
depends_on:
- mosquitto

chirpstack-rest-api:
image: chirpstack/chirpstack-rest-api:4
restart: unless-stopped
command: --server chirpstack:8080 --bind 0.0.0.0:8090 --insecure
ports:
- 8090:8090
depends_on:
- chirpstack

postgres:
image: postgres:14-alpine
restart: unless-stopped
volumes:
- ./configuration/postgresql/initdb:/docker-entrypoint-initdb.d
- postgresqldata:/var/lib/postgresql/data
environment:
- POSTGRES_PASSWORD=root

redis:
image: redis:7-alpine
restart: unless-stopped
command: redis-server --save 300 1 --save 60 100 --appendonly no
volumes:
- redisdata:/data

mosquitto:
image: eclipse-mosquitto:2
restart: unless-stopped
ports:
- 1884:1883
volumes:
- ./configuration/mosquitto/config/:/mosquitto/config/

volumes:
postgresqldata:
redisdata:

Currently, I have only enabled port 1700 for testing. When I configure port 1700 for the EU868 region, everything works fine. However, when I change the ports and use 1700 for the AU915 region, I receive the joinRequest from the device in the gateway frames, but the device does not receive any frames, and the joinRequest is not accepted.

What configuration should I adjust to make multi-region operation work correctly?

Thank you in advance for your help.

6

As long as both regions are enabled in your Chirpstack.toml and you have the two gateway bridges I believe that is all you have to do.

If you still using the US915 gateway I would assume that is where the issues are coming from, as the join-looping you are seeing is typically caused a band-mismatch between device->gateway->server. Although if Multitech assured you it should be compatible I wouldn’t doubt them - perhaps the model of gateway is capable of handling uplink / downlinks in both AU915 and US915 bands but I would assume that would require configuring it to the US915 bands, as a gateway only has 8 channels if they are set to the AU915 bands it will not receive all the messages from US915 devices.

I would recommend calling them and getting a little more information on how they handle this band mismatch, and if you need to make any changes to have your AU915 gateway support US915.

If you sort that out and are still having the same issue feel free to ask again, but for now that is the glaring issue and a reasonable cause for the join-looping, so I don’t see any point debugging elsewhere until you have confirmation on that.

If you want to confirm that this is not an issue with Chirpstack’s multi-region functionality, delete your second GW bridge and set the first gateway bridge to AU915, I guarantee you will see the same issues even when there is only one region involved.

1 Like
7

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.