LoRa Mac 1.0.3 US915 device

Hello fellow developers,

We are currently working on debugging an issue with one of our lora devices that is supposed to operate in US915 region. We are using using LoraMac 1.0.3 on the device and TTIG gateway for US915. The issue is that the device is not capable of joining/finding the gateway for many retries. The device is able to find the gateway and join the network when it tries channel 9 and DR 4, otherwise the gateway is not picking any uplinks. After joining the network the device is still not able to send uplinks. It manage to send uplinks to the gateway but doesnt get any response.

Personally I don’t want to mess too much with the LoraMac library and trying to debug the device itself and the gateway. Has anyone have had similar problem or could provide any tips on where to check?

Gateway does not pick any uplinks except when the device joins on channel 9 and DR 4. Once in network, the device is able to send uplinks but do not receive any downlinks from the gateway.


It sounds like you may not be correctly using the same bandplan as TTN, in particular the same sub-band.

There is no such thing as a channel 9 on which DR4 is valid (that said, the “channel” in an uplink report is not necessarily a LoRaWAN channel, it may simply be an ordinal numbering of the sub-ifs supported by a gateway configuration)

As actually defined by the LoRaWAN spec:

  • Upstream – 64 channels numbered 0 to 63 utilizing LoRa 125 kHz BW varying from
    DR0 to DR3, using coding rate 4/5, starting at 902.3 MHz and incrementing linearly
    by 200 kHz to 914.9 MHz

Of these, TTN uses only the 2nd group of eight from 903.9 - 905.3 at DR0-3 only aka channel 8-15

  • Upstream – 8 channels numbered 64 to 71 utilizing LoRa 500 kHz BW at DR4
    starting at 903.0 MHz and incrementing linearly by 1.6 MHz to 914.2 MHz

Of these, TTN uses only 904.6 at DR4 aka channel 65

These are pretty normal choices - a gateway with a single concentrator chip cannot cover all legal frequencies but only such a sub-grouping, and this is the one TTN has chosen to use

TTN bandplans can be seen in terms of explicit frequency and datarate here:


One thing to keep in mind is that the LoRaWAN spec suggests that nodes which don’t know anything about the network they are trying to join should try all possible channels. Only about 1/8 of those would actually be supported by a TTN gateway, making the process rather inefficient. If a node knows it is trying to join TTN, it should use only the channels TTN supports.