Join Errors with RN2xx3

I am having trouble joining over otaa.

LoRa Module: RN2903
Gateway: Basic Station running as a docker container on a RAK2243 PiHat on a Pi4.

My node and gateway are quite close at the moment (3 meters) for this stage of development. Is this too close?

Before sending the otaa join request, I set the radio sf to sf7 as I’ve read that the default sf12 can cause issues. This my configuration…

RN2903_cmd("mac set deveui " HWEUI "\r\n");
RN2903_cmd("mac set devaddr 00000000\r\n");
RN2903_cmd("mac set appskey 00000000000000000000000000000000\r\n");
RN2903_cmd("mac set nwkskey 00000000000000000000000000000000\r\n");
RN2903_cmd("mac set appkey " APPKEY "\r\n");
RN2903_cmd("mac set appeui " APPEUI "\r\n");
RN2903_cmd("mac set ar on\r\n");
RN2903_cmd("mac set rxdelay1 5000\r\n");
RN2903_cmd("mac set adr off\r\n");
RN2903_cmd("mac save\r\n");

then before joining, I
RN2903_cmd(“mac pause\r\n”);
RN2903_cmd(“radio set sf sf7\r\n”);
RN2903_cmd(“mac resume\r\n”);

My gateway receives the join request and appears to receive

And it appears that the join server accepts the request

But the RN2903 sends back
Rx: ok
Rx: denied
meaning that the join procedure was unsuccessful.

Is the problem that the RN2903 does not receive it in time? Are there any suggestions as to how I can look further into the problem?

I will add this in case it helps as well:
Could this be a timing issue with the end node?

As a side note, sometimes after joining over abp, my first confirmed tx results in a mac error even though the payload arrives at the application. subsequent unconfirmed tx (mostly I just used uncnf) usually arrive fine, though on occasion, I see an invalid payload. Does this happen if the frame count is off? or would that cause the gateway to ignore since the MIC would fail?

Thank you for any suggestions.

Yes 3m are too close, 5-10m with a brick wall normally suffices.

But I think you have other issues, as you are on SF10, SNR -11.75 and RSSI -117 and TX 20 something. I would have a careful look at my antennas.

1 Like

Thank you so much for the help!

I moved the gateway to the other side of a wall, and raised my sf to sf10, and now I am above the noise floor snr 11.5 rssi -46… but the downlink still has TX Power of 28.15 SF10BW500. Is that part of the issue?

Are you fixing your SF to SF10? If you are may I ask why?

When I had the gateway at about 3 m, and tried the sf7 for the join request, it was received by the gateway but as you pointed out under the noise floor, and with very weak signal… maybe due to reflections and being too close?

After your comment, the only way I could put more space between was to move it into another room and when I attempted to join at sf7 nothing reached the gateway. So I tried sf10 and that join request reached the gateway and was forwarded, but my node never gets the return message.

The point @Johan_Scheepers was making was the your antennas are providing the results of slightly damp string - you should check the connections - particularly checking if the SMA connector is male to female, not female to female.

@Johan_Scheepers @descartes
Thank you both for your help; I see your responses to quite a few posts, it’s really appreciated. I am now able to join over otaa, thrilling to see it working. I tried a number of different things, and I want to nail down exactly which part helped the most. I happen to have a spare RN2903 and a RAK 2243, so I replaced both of those because their antennas had no noticeable damage with solid connections.

The thing that made the most difference was moving the gateway a full 5 meters away. It is line of sight at the moment. Do I have the right understanding that when it is too close, the reflections nearby create so much noise that the adr predicts that to reach the node it would be necessary to use too high of a sf/power that overwhelms the node? If you a have moment, I would love to have the right understanding of what was going wrong when the node and gateway are too close.

Thank you!

Basically if the two devices are too close you’re in danger of overloading the receiver circuits of the gateway. That leads to malformed messages, but also to channel bleed in which case the gateway reports receiving data on a different (nearby) frequency. Because the network server instructs the gateway to respond on the frequency reported for the uplink, the downlink transmission will not be received by the node which is listening on the original frequency.

1 Like