Just sharing two observations in deployments in large buildings with many obstacles and over 50-60 nodes.
1. Using a Moteino M0 instead of a regular Moteino seems to reduce the number of retries being attempted by the node. I'm assuming this is because of the faster processor of the M0. Wondering how running it on a board with an even faster processor or running the RFM69 library directly on the Pi (Python?) would affect the performance.
2. Sometimes the nodes that are further away lock out and always transmit all the number of retries. I've added a function to generate a random retry wait time in the sendWithRetry() function which seems to fix this problem.
bool RFM69::sendWithRetry(uint16_t toAddress, const void* buffer, uint8_t bufferSize, uint8_t retries, uint8_t retryWaitTime) {
uint32_t sentTime;
retryWaitTime = random (20,70); // generate random retry wait time between 20-70ms
for (uint8_t i = 0; i <= retries; i++)
{
send(toAddress, buffer, bufferSize, true);
sentTime = millis();
while (millis() - sentTime < retryWaitTime)
{
if (ACKReceived(toAddress)) return true;
}
}
return false;
}
You can seed the random function with an analog pin in the initialize function to make it more random, but in practice that doesn't seem necessary. I think this makes sure that the transmissions from individual nodes are almost never at the same time, giving room for the ACK to be received. If I have 3 retries, adding this function almost gives only 1 or 2 retries maximum when signal is low and only very rarely do I get 3 retries from nodes which are located so far away that the average RSSI is already close to -90.