Change retryWaitTime (in sendWithRetry) from uint8_t to uint16_t

[Steinarr134]

I have a node that is busy with i2c communication so it won't respond to
radio communication right away.

The application isn't time sensitive so I don't mind waiting a second
for it to respond but wasn't able to increase the wait time above 255

[LowPowerLab]

IMHO a retry of more than 50ms is not really justified because a transmission will never take more than that (except in special situations at very low baud rate). This would also increase RAM usage for all compilations.
For very long ACK waits I suggest sending the packet with send() in the sketch, then waiting for a packet and check if it's an ACK. Even so in my opinion the radio has highest priority, and to put a very long hold on the radio because of a slow i2c sensor is probably not a great idea in general. I always take care of radio comms first then deal with other priorities, maybe that's a better place to optimize rather than increase the wait time up to 65 seconds, it seems not optimal.

[Steinarr134]

Alright, I hadn't considered that it would increase the RAM usage, I don't have the knowledge or experience on that front.

I figured the library should rather support a broader spectrum of situations, ideal or not, but it's your call and I won't be offended either way.

[LowPowerLab]

Really just looking into the best interest of keeping the library lean and compact. The sendWithRetry() delay is only there to accommodate relatively short and immediate ACKs/replies. For special cases I suggest overriding the class and function locally with a variant that accepts the unsigned int, then if that's not compiled it won't penalize the RAM.

[philfifi]

Long time to ACK might be caused by the senACK method waiting for canSend(), waiting for low noise level. You might want to check this option : #84