lofence: RN2483 send timeout?

What firmware of the RN2483 are you running, 1.0.5 or an earlier version? And what settings did you use on TTN side for the device?

I’m having some issues where the RN2483 sometimes doesn’t give a response anymore to a TX command. It would do multiple rounds OK, and then suddenly it acknowledges the command to send an unconfirmed message, but after ~1 hour it still sits there with no response on the UART from the RN seemingly (I didn’t tap the UART yet directly from the RN in parallel, will try that). In the docs of the RN2483 there is a possible timeout response mentioned, so should it need to be set explicitly perhaps?

example:

Sleeping for 4320 seconds

Round: 3
Measuring
Measuring battery: 4684 mV
Measuring fence positive: 0 V
Measuring fence negative: 0 V

Transmitting
RN2483 wakeup and baud change
RN2483 RX clearing
RN2483 TX: mac join abp
RN2483 RX: ok
RN2483 RX: accepted
RN2483 TX: mac get upctr
RN2483 RX: 25
RN2483 TX: mac set pwridx 1
RN2483 RX: ok
RN2483 TX: mac tx uncnf 1 0003124C00000000
RN2483 RX: ok
RN2483 RX: mac_tx_ok
RN2483 TX: mac save
RN2483 RX: ok
RN2483 TX: sys sleep 86400000

Sleeping for 4320 seconds

Round: 4
Measuring
Measuring battery: 4658 mV
Measuring fence positive: 0 V
Measuring fence negative: 0 V

Transmitting
RN2483 wakeup and baud change
RN2483 RX clearing
RN2483 TX: mac join abp
RN2483 RX: ok
RN2483 RX: accepted
RN2483 TX: mac get upctr
RN2483 RX: 26
RN2483 TX: mac set pwridx 1
RN2483 RX: ok
RN2483 TX: mac tx uncnf 1 0004123200000000
RN2483 RX: ok

/edit: found some other references to this https://www.thethingsnetwork.org/forum/t/rn2483-timing/36278 https://www.microchip.com/forums/m1101599.aspx

So for now I’ve put a (naive) 5 second timeout in the rn2483_rx() function to cope with this. Will let it run again overnight and see how it behaves

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 17 (4 by maintainers)

Most upvoted comments

About a month passed and system still stable, no hanging devices after changing to my ADR algorithm. I had one device having an issue but it turned out the crystal had a connection issue and the clock didn’t get a signal so the device didn’t wake up after initial join and first measurement. I changed batteries of all six devices yesterday, all joined without issues and sent ~200 updates…

I used that mac save in my firmware but only every 100 uplinks to save the eeprom from wearing out, on a new start I increased the counter by 100 to be after any count between where the gateway might be… But I changed to a rejoin on a reset so no need to save for now…

no watchdog at first glance, but timeouts on the serial reads on many places like

        _serial.setTimeout(30000);
        receivedData = _serial.readStringUntil('\n');
        _serial.setTimeout(2000);