Slow to send ACK on ESP8266

[steveww]

I am using the Adafruit HUZZAR ESP8266 board with an RFM69HW module. It is listening for packets then forwarding them on via WiFi to MQTT. The sensor is using sendWithRetry to send its data. I noticed that the send always failed but the data was still getting through. After much investigation I noticed that the ESP gateway was typically taking 1005ms to send its ACK. Of that 1000ms is the collision timeout. It all gets hung up on the canSend() function. This intensive loop stops the ESP from doing its background tasks. I tried using yield() or delay(1) at the top of the canSend() function. Both improved the situation, using yield() gave a typical ACK response of 400ms; still a bit long. However using delay(1) gave an ACK response time of 5ms; much better.

You may want to consider adding this tweak to your library.

[LowPowerLab]

Not sure how this can be improved in the lib since this is architecture dependent. Also adding more delays in the lib is not a good idea, sounds like you can do it in your sketch.

[jLynx]

I didn't want to open another issue as there seems to be a few related to this currently. I am having a few issues. I have this working perfectly on a ATMega328p, but when using an ESP32 or ESP8266, the ACK responses to the ATMega328p are sometimes very slow or non existent. Was there any solutions found on how to get the library working more reliably on the ESP8266/32?

I am using the latest release of this library (1.5.1). This is my code on the "receiver" ESP side

void loop()
{
  if (radio.receiveDone())
  {
    if (radio.ACKRequested())
    {
      radio.sendACK();
      Serial.println("ACK sent");
    }
  }
}

If someone could point me in the right direction, that would be perfect! (cc https://github.com/LowPowerLab/RFM69/issues/105)

[devdrik]

I didn't want to open another issue as there seems to be a few related to this currently. I am having a few issues. I have this working perfectly on a ATMega328p, but when using an ESP32 or ESP8266, the ACK responses to the ATMega328p are sometimes very slow or non existent. Was there any solutions found on how to get the library working more reliably on the ESP8266/32?

I am using the latest release of this library (1.5.1). This is my code on the "receiver" ESP side

void loop()
{
  if (radio.receiveDone())
  {
    if (radio.ACKRequested())
    {
      radio.sendACK();
      Serial.println("ACK sent");
    }
  }
}

If someone could point me in the right direction, that would be perfect! (cc #105)

You need a delay(1) in the canSend() method. Since #150 you can inject it yourself. Looks like #168 even added the possibility to set a ESP8266 flag to achieve the same (thanks for that by the way). So if you use a version of the lib that includes #168 and set ESP8266, you should be good to go.

[jLynx]

@devdrik that is what I am currently using, but still has the issue I described above. Here is an example:

07:51:04.594 -> received from node 2, message[10000000], RSSI -66
07:51:04.641 -> ACK sent
07:51:04.641 -> received from node 2, message[10000000], RSSI -65
07:51:04.688 -> ACK sent
07:51:05.682 -> received from node 2, message[10000000], RSSI -63
07:51:05.682 -> ACK sent
07:51:05.682 -> received from node 2, message[00000000], RSSI -64
07:51:05.729 -> ACK sent
07:51:06.722 -> received from node 2, message[00000000], RSSI -65
07:51:06.769 -> ACK sent
07:51:07.758 -> received from node 2, message[00000000], RSSI -63
07:51:07.758 -> ACK sent

What this is doing is transmitting when a button is pressed and then again when its released. As you can see it failed to get the ACK quick enough so ended up transmitting the message 3 times for the button press and then 3 times for the button release. When I use another ATMega328p as the "receiver" (instead of the ESP), I don't run into this issue at all as its rock solid.

[jLynx]

Scratch that, problem solved for the ESP8266 (I am yet to test again with the ESP32). Basically the issue was that the fixes you mentioned above @devdrik were not in the current latest release (My mistake for thinking they were). So after trying master it now responds instantly all the time.

@LowPowerLab Would it be possible for you to do another release so silly people like me don't get caught up on this problem?

[LowPowerLab]

@jLynx Thanks for the suggestion, and sorry for the slow response. This is done: https://github.com/LowPowerLab/RFM69/releases/tag/1.5.2