RAK7249 Wrong Downlink Frequency US902-928

Issue: RAK7249 is sending downlink messages with same frequency as received uplink messages.

Node - Adafruit Feather 32u4 with Arduino LMIC and jumper from Pin 6 to IO1, per Adafruit instructions
Gateway - RAK7249 set to US902-928 frequency plan

LoRa® Server: ChirpStack deployed on AWS


I suspect this to be the root cause of my not being able to achieve a successful OTAA join, or to receive downlink messages when connecting with ABP. In both OTAA and ABP tests, I can see uplink messages being passed to my ChipStack server, and in OTAA, JoinAccept messages being sent to the gateway. In the gateway LoRa packet logger, I can see both the uplink and downlink messages, but when there is a join request at, say 904.1MHz, the downlink JoinAccept message is shown as being broadcast at that same frequency instead of one of the appropriate downlink frequencies (923.3-927.5MHz for Rx1 or 923.3MHz for Rx2).

Things I have tried prior to noticing this frequency issue:

  • Verified EUIs and keys, but this is obviously valid, as JoinAccept messages are being sent from ChirpStack
  • Increasing the LMIC clock error: LMIC_setClockError(MAX_CLOCK_ERROR * 5 / 100);
  • Trying a different node (same hardware, just a physically different device)

Also, I had previously had the gateway configured to use The Things Network and I had been able to achieve successful OTAA joins with that configuration.

I’d much appreciate any additional guidance.

Dear Michael,

You need to make sure that there are some things, that the frequency band is consistent, that the triples used are the same.

Which chirpstack is used? Can I use it?

Best regards!

Hi Nicholas,

I followed the ChirpStack setup process outlined here. https://doc.rakwireless.com/quick-start/rak7249-macro-outdoor-gateway/aws-ec2-chirpstack-rak7249-gateway

“You need to make sure that…”

  • “…the frequency band is consistent.” Where are all the places I should be checking? I know that my node is the correct band, and I think I’ve set the gateway to the correct frequency band. I’ve included screenshots of some of what might be relevant configuration pages on the gateway. (Separated into separate posts, since I’m apparently limited to one image per reply.) I noticed that there are a few features enabled that I’m not using, including the MQTT Bridge and built-in server. Is the fact that these are enabled a problem?

  • “…the triples used are the same.” I’m new to LoRaWAN, so I’m not sure what this refers to. Can you elaborate?

The actual downlink frequency is commanded entirely by the network server. The most the gateway itself could do is decide “I’m not allowed to transmit on that frequency” and refuse. The gateway will never transmit on a frequency other than what the network server commands it to.

This is a configuration problem with your cloud instance of chirpstack, likely that is set to a bandplan other than US915.

The problem is not with the gateway at all.

Oh, thanks so much for that input! I would have spent all day looking in the wrong place. I’ll see if I can figure out what’s going on in the ChirpStack server settings and report back in case anyone else has a similar issue.

The ChirpStack setup instructions on the RAK website don’t include setting the frequency plan in the ChirpStack configuration file. You can find information about there here. If you’re not using the EU868 band, you need sudo nano /etc/chipstack-network-server/chirpstack-network-server.toml to edit your config file and change name='EU_863_870' in the LoRaWAN regional band configuration to your frequency plan (name="US915" in my case). Also make sure read permissions are enabled for other users. If they are not already set, sudo chmod o+r /etc/chipstack-network-server to enable them. As silly as it is, it took me forever to realize that starting the server with sudo systemctl start chirpstack-network-server was not loading the correct config file and was switching to defaults because read permissions were not enabled.

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