JoinAccept not being received by device (RN2903)

Devices
1

Have a RPI3B with Chirpstack setup according to the chirpstack debian setup guide.
Using gateway and packet forwarder from github.com/lora-net and set for AU915.
Set LORAWAN version 1.1

With RN2903 device with AU firmware I send joinRequest.
This is received by the Lora server and a JoinAccept is sent.
The JoinAccept is received by the gateway but the RN2903 indicates “join denied”.
The journal for the gateway is captured below:

In the Gateway global_conf.json file, the uplink freq of 917.8 is configured for one of the 8 channels, however the downlink freq of 926.3 is not configured. Also, the RN2903 does not have a channel option for 926.3
I am unsure if the downlink frequencies are configured the same as the uplink frequencies so I am unsure if this is a problem or not.

Any ideas where to look for the problem would be well received.

2 
Aug 16 09:46:38 ttn-gateway ttn-gateway[381]: INFO: Received pkt from mote: 00000000 (fcnt=0)
Aug 16 09:46:38 ttn-gateway ttn-gateway[381]: JSON up: {"rxpk":[{"tmst":4073115132,"chan":5,"rfch":1,"freq":917.800000,"stat":1,"modu":"LORA","datr":"SF10BW125","codr":"4/5","lsnr":-3.5,"rssi":-123,"size":23,"data":"AAAAAAAAAAAAajEbAAujBAAWKRM/Yxg="}]}
Aug 16 09:46:38 ttn-gateway ttn-gateway[381]: INFO: [up] PUSH_ACK received in 1 ms
Aug 16 09:46:38 ttn-gateway ttn-gateway[381]: INFO: [down] PULL_RESP received  - token[55:29] :)
Aug 16 09:46:38 ttn-gateway ttn-gateway[381]: JSON down: {"txpk":{"imme":false,"rfch":0,"powe":27,"ant":0,"brd":0,"tmst":4078115132,"freq":926.3,"modu":"LORA","datr":"SF10BW500","codr":"4/5","ipol":true,"size":33,"data":"IPXEfpwVgX0Tyux3G1Mv9mWyfWcPHoORwLk4pPxcKW0S"}}
Aug 16 09:46:38 ttn-gateway ttn-gateway[381]: INFO: tx_start_delay=1497 (1497.000000) - (1497, bw_delay=0.000000, notch_delay=0.000000)
Aug 16 09:46:38 ttn-gateway ttn-gateway[381]: INFO: [down] PULL_ACK received in 0 ms
3

Are you sure your RN2903 device supports LoRaWAN 1.1? I don’t think it does which probably explains your issue.

4

Also tried with LoRaWAN 1.02 with LoRa Server and same result.
Also now using the Rak_common_gateway setup with V1.0.2. and the same result.

Also, dont understand about the Server sending downlink on 926.3 MHz when there is nothing that indicates the RN2903 supports that frequency.

5

I had some trouble with these modules (RN2483 firmware 1.0.5) (with TTN not chirpstack) but just in case, would you mind change default DR for joining (mac set dr 5 or something like that)? Mine was setup with default SF12 (dr 0) and forum says better to start with SF7 and let increase if not working

worth trying that, saved my day :slight_smile:

6

As far as I know, RN2903 does not support AU915 (and US915): only AS923 (if you find any firmware that does support AU915, let me know), and definitely not LoRaWAN 1.1.

1 Like
7

Tried with SF7, still no luck

8

With RN2903, using standard microchip code SA1.0.3 Jan 23 2018. This supports AU915 and all the channels seem correct.

9

I am now trying with a new Gateway (RAK7244) with standard RAK frirmware and no third party firmware. Trying with a SAMD21 and RFM95 and Arduino LMIC stack. Same result. The application server received the JoinRequest and then sends the joinAccept. The Gateway indicates that the JoinAccept was transmitted, but the JoinAccept is not received (or decoded) by the SAMD21.

I am using two completely different sets of software and hardware and getting the same result. Both Server and SAMD21 set to LoRaWAN 1.0.2, RevA.

i am using OTAA and have set the AppEUI to 0 because I cannot find any reference in the Server of where to set that. The DevEUI and AppKey must be correct otherwise the Server would not generate the joinAccept. The gateway seems to be working as it received and sends the same number of packets.

Any ideas?

11

I am having the same problem

12

I got a sizable batch of RN2903A last year that had about 10% exhibiting the same problem. Troubleshooting showed that the problem is due to the RX path not working. To test this, you can join with ABP (which needs TX only), then try sending downlinks. They won’t be received by the radio.
Previously, I have not seen this problem during our production, so it’s seems to only affect some batches.
I conclude, it’s a RN2903A hardware defect that Microchip is not catching during their production tests for some batches.