RN2483: downlink problems in RX2?

End Devices (Nodes)
1

We run more than 50 nodes based on RN2483. They work fine with various networks (TTN, Swisscom, Loriot, others). We mostly use OTAA.

Recently we discovered that there are issues with SOME, BUT NOT ALL RN2483 when trying to join using SF11: join_request is received by the gateway close by, the gateway responds with join_accept on 869525000, SF12, in RX2, but the join_accept message is not received / decoded by the RN2483, i.e. join denied. (We observed the gateway traffic using tcpdump.)
We are still figuring out how many RN2483 are actually affected, imagine 5 out of 10 devices on my desk. Note that these devices work fine when joining using SF7, SF8 (downlink in RX1).

More observations:

  • Radioing :slight_smile: directly from one RN2483 to another on 869525000, SF12 works fine (even if the same devices would not join in RX2).
  • However, so far I was never able to see the join_accept message with a RN2483 programmed as a sniffer on 869525000, SF12, even if the join was successful!

Could be a timing / frequency mismatch issue? Any ideas? Similar observations?
Thanks a lot!

2

is there a difference in firmware versions ?

3

Firmware was also my first thought. This sounds very much like the issues I had with v0.9.5. After upgrading to v1.0.1 everything seemed fine.

4

Good point. Firmware is 1.0.1 on all of them.

5

Gateways transmit with IQ inverted to make sure other gateways do not receive the transmission, did you listen with ‘radio set iqi on’?

6

No, I did not ‘radio set iqi on’. Thank you, I was not aware of that! Will test this again soon.

7

Hi everyone,
we have the same problem of delay during join procedure even with different development board. End device could not receive join accept during OTAA. (Tested on both SF9 and SF12)

8

The original post is not about delays, it is about failures when joining.

What is your delay issue? Keep in mind joins take 5 (answer in RX1 window) or 6 (answer in RX2 window) seconds.

9

Thanks for correct me. As you mentioned, it is downlink problem. because end device could not receive join accept during OTAA even with delay. The RX1 and RX2 window are the same values which you wrote. I think all are about latency problem in downlink.

10

Hi, just wondering if this issue has been resolved ? Or updates ?

11

Status update one year later:

  • Some RN2483 modules have problems receiving downlink messages at SF12, long messages in particular.
  • JoinAccept messages in EU868 can be VERY LONG at SF12 (1.97 seconds!) -> joining often fails.
  • The issue is probably due to an inaccurate crystal oscillator.
  • Updating RN2483 with firmware 1.0.3 does not solve the issue.
  • We assume that the issue is solved with the release of RN2483A (to be confirmed yet).
1 Like
12

Thanks for the update, experiencing the same. Hope the A version will resolve. Any idea when you would be able to test this ? Im gonna replace the RN2483 with the A version soon too, so if I got an update will let you know too :slight_smile:

1 Like
13

anyone know if RN2483A resolves this issue?