sendBytes hangs indefinitely waiting for the confirmation

[andrzejtokarski]

When this is called:
ttn_response_t result = ttn.sendBytes(message->getBytes(), message->getLength(), 1, true, 12);
And the message is not successfully sent it seems to never time-out. Is there a way to configure RN2483 retries and timeout behaviour?

I see that default is #define TTN_RETX "7" but this blocks execution for a very long time without any feedback.

[jpmeijers]

After investigating this issue it seems like you are correct. The problem is that the RN2483 module does not give any feedback during the time it retries.

My recommendation would be that we set #define TTN_RETX "0" and then:

• Let the sendBytes function return TTN_ERROR_SEND_COMMAND_FAILED after the first failed attempt. Then the user's application can handle retries.
  -or-
• We handle retries in the library, allowing debugPrint's to update the user why the send command is taking so long.

Both these solutions will transmit a new packet with an incremented frame counter. If we let the RN2483 handle retries, the frame counter in the retry packets is (as far as I know) the same. Using incremented frame counters for retries seems more secure to me.

My preferred solution is setting TTN_RETX to 0 and let the user's application handle retries. Fail fast!

[jpmeijers]

The timeout implemented in #210 can actually cause an issue for long retry delays. Looking for a clean solution now, however setting TTN_RETX 0 will solve it too.

[andrzejtokarski]

Is there a way to distinguish a send the failed because of bad connection form the one that was aborted by the RN2483 because of duty cycle limitation?

[jpmeijers]

When the send fails because of duty cycle restrictions, the module responds with no_free_ch. The TTN library returns TTN_ERROR_SEND_COMMAND_FAILED.

When the send fails because no acknowledgement was received, the module responds with mac_err. The TTN library returns TTN_ERROR_UNEXPECTED_RESPONSE.

[andrzejtokarski]

Thank you! 👍
i think I was slightly mislead by the naming of errors.