Hi KrisK,
Thanks for testing and sharing your test data.
Yes, with sendWithRetry you probably achieve ~0% message loss. But sendWithRetry basically means that you take packet loss into account. sendWithRetry actually does re-transmissions for you in case a packet is not ACKed. If you would be sure that every SENT packet is RECEIVED by the receiver, you do not need to use sendWithRetry. You would use plain radio.send function which does not do any re-transmissions.
That's why I use radio.send. With radio.send on the SENDER side, I just send a packet with increasing packet counter in it. On the RECEIVER side, I check the packet number received in the packet sent by the SENDER. If there is a gap between the previously received packet # and the current packet #, I know that the previous packet from SENDER did not make it to the RECEIVER (or possibly was silently dropped by the receiver). And this is where I see the 1% packet loss.
In you send your packets with relatively big delays between each packet, let's say 50ms or more, you can afford using sendWithRetry. But if you want to send a packet every 20ms (like I do), you cannot use sendWithRetry. Simply just because the round-trip-time is around 8ms. Timeout waiting for an ACK would take some additional time (10ms at minimum). So, basically, you are at 18ms, which is around the time you would send a new packet anyway (I do it every 20ms).
Let's say you lost 1 packet out of 100 (1%). If you would re-transmit (with retries set to 1) in case a packet is not ACKed by the sender; and we assume that every 1% of the re-transmitted packets is lost too, you will effectively need to send 100 x 100 packets to see 1% of not delivered messages. In your case, you use sendWithRetry with 6 retries. It means you theoretically need to send 100 x 100 x 100 x 100 x 100 x 100 x 100 = 10^14 packets to see 1% of not delivered messages.
It would be interesting to see the packet loss if you would use plain radio.send function instead of sendWithRetry. You would see ~1% packet loss, I believe. You don't even need to send any ACKs back to the SENDER. Just check for a gap in the packet numbers on the RECEIVER side.
It is interesting that I see this behavior with any packet frequency (20ms, 100ms, 1s), even with RSSI being ~-30 on each side. And even more interestingly, ACK packets are lost only in about 0.1% cases.
Thanks,
Peter