LowPowerLab Forum

Hardware support => RF - Range - Antennas - RFM69 library => Topic started by: akstudios on July 23, 2019, 12:59:42 PM

Title: Some RFM69 observations
Post by: akstudios on July 23, 2019, 12:59:42 PM
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.

Code: [Select]
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.
Title: Re: Some RFM69 observations
Post by: Felix on July 23, 2019, 04:19:33 PM
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.
The SPI clock is not faster so I don't believe that has anything to do with it. Perhaps the larger GND plane of the M0 accounts for better reception. But it will depend on antennas and other factors.

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.
Thanks for sharing that. It's perhaps one way to deal with this issue. And it couples into the first question - and how well the receiver can reach the gateway. It the gateway is always responsive and there are no collisions then workarounds like this may not be required. But that's always a big IF.

There is also a separate issue with serial buffering of the gateway - I've seen it happen on the Pi where the Pi does not process the serial fast enough and the node times out trying to reach the gateway. I hope to release some changes for the PiGateway sample (https://github.com/LowPowerLab/RFM69/blob/master/Examples/PiGateway/PiGateway.ino) sketch to illustrate how to take care of that problem.
Title: Re: Some RFM69 observations
Post by: akstudios on July 23, 2019, 04:42:12 PM
The SPI clock is not faster so I don't believe that has anything to do with it.

Oh, I assumed the SPI clock is a factor of the main oscillator frequency. But maybe the serial processing is slightly faster then? The only difference is like you said - a larger ground plane. Didn't realize it would make that big of a difference.

There is also a separate issue with serial buffering of the gateway - I've seen it happen on the Pi where the Pi does not process the serial fast enough and the node times out trying to reach the gateway. I hope to release some changes for the PiGateway sample (https://github.com/LowPowerLab/RFM69/blob/master/Examples/PiGateway/PiGateway.ino) sketch to illustrate how to take care of that problem.

Would there be a difference in speed if you use the USB interface directly as opposed to the serial RX/TX lines on the Pi? Even disabling bluetooth, serial debugging and anything else that may affect the RX/TX pins, the serial processing does have limits.
Title: Re: Some RFM69 observations
Post by: Felix on July 23, 2019, 09:04:06 PM
The ground plane matters when used with antennas that need it (like the wire monopole).
The SPI clock is limited to 4mhz. That is really way faster than the serial clock on the AVR Moteinos - which can become a bottleneck - but IMO it is not, if properly coded/buffered.
Title: Re: Some RFM69 observations
Post by: akstudios on July 29, 2019, 12:19:45 PM
The SPI clock is limited to 4mhz.

Correct me if I'm wrong, but I assumed the SPI clock on the SAMD21 is a lot faster than 4MHz. Are you limiting it to 4MHz in code? Or is this more of a limitation on the RFM69 instead? 4MHz seems plenty, but just trying to understand here.

Also, it seems that the USB interface on M0 is also faster compared to FTDI on AVR Moteinos, which is why I was under the impression this was helping with minimizing packet losses when using M0 as a gateway node (apart from obviously larger ground plane)
Title: Re: Some RFM69 observations
Post by: Felix on July 29, 2019, 12:28:40 PM
It's good to always check the DS (https://www.semtech.com/uploads/documents/sx1231h.pdf) first.

In this case section 2.4.5. Digital Specification specifies: Max SPI_CLOCK is 10Mhz.
I started development with 8mhz and eventually decided to clock it down to 4mhz. I felt it was safer and I have no reason to change this now, regardless of CPU (it is not the limiting factor!).

MoteinoM0/SAMD21 has USB speed serial (baud is irrelevant), which is way different than FTDI - which emulates a UART serial - this requires a baud and can go up to 2mbps. We use 115200 but you can always try 1mbps if you'd like, I believe it should work (nice even fractional clock based on the MCU speed) of as long as both sides play nice with that fast clock (assuming Pi should also handle higher UART clocks).

Last time I tried an M0 serial on the Pi's USB, it locks up as soon as you try to send data to the M0. I have to investigate further - I did find some other online links that talked about that. Maybe the latest raspbian behaves different. The fallback would be GPIO serial instead of USB serial, I would certainly believe the M0 can handle 1 or even 2mbps.