No ack received by sender with esp8266

[2ni]

I'm using the examples Struct_send/receive with an esp8266. The sender can send the data and I get it on the receiver. So far so good.
But on the sender side I only get an ack, if I add a delay in the function sendACK (RFM69.cpp line 294):
while (!canSend() && millis() - now < RF69_CSMA_LIMIT_MS) {receiveDone(); delay(1);}

With that change it works like a charm, without it just waits for RF69_CSMA_LIMIT_MS milliseconds and then returns, ending in the sender printing "... nothing".
Does this issue ring a bell to someone?

[LowPowerLab]

Thanks for the question, please ask this in the forum where there is a lot more exposure and might solve your code questions quickly. This space is reserved for reporting documented issues. If there is an actual issue you can document we can re-open this or a new Repo issue. FWIW others are using this with ESP8266 without problems, please check your settings.

[chris03]

Looks similar to #49 where the delay(1) was added in canSend()

[mamama1]

just wanted to follow up on this. i have esp8266 at both ends and as soon as i added delay(1) to canSend(), Acks were working perfectly. Before that, I had the same issue.

I'm using very basic, stripped down gateway and node example.

Will test this with ESP8266 on one and 328p on the other end later.

i don't think, this issue should stay closed, unless you decide not to support esp8266 at all.

if this issue really is only settings/code (not library) related, it might come handy to new users to have working examples for the esp8266 included in the library.

[rrobinet]

FYI, I am using the RFM library (of the 4/10/2016) since two years now on Wemos Lolin D1 and pro (retired) without any problems. Robert On 08 Feb 2019, at 02:01, mamama1 <notifications@github.com<mailto:notifications@github.com>> wrote: just wanted to follow up on this. i have esp8266 at both ends and as soon as i added delay(1) to canSend(), Acks were working perfectly. Before that, I had the same issue. I'm using very basic, stripped down gateway and node example. Will test this with ESP8266 on one and 328p on the other end later. i don't think, this issue should stay closed, unless you decide not to support esp8266 at all. if this issue really is only settings/code (not library) related, it might come handy to new users to have working examples for the esp8266 included in the library. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#105 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABL9zTmsu1G-88KfXoFR_2CUjCX-cIPzks5vLMxPgaJpZM4UGLTP>.

[lrusnac]

@mamama1 would you mind sharing your sketches? I am trying with delays and yield but I can't get the ack to be received on the node, the message goes through but the sender thinks it fails

[rrobinet]

Sorry but I don't have a simple example. In my case I have a "Wemos Lolin D1 retired " as central coordinator with Moteino as remote Motes I use the RFM library for both platforms The basic set-up for the ESP8266 is in my case: #define IS_RFM69HW true // Only for RFM69HW high power #define RFM_SS D0 // Use D0 (GPIO16) as SS #define RFM_INTPIN D8 // One if a free GPIO supporting Interrupts (GPIO15) const byte RFM_INTNUM = digitalPinToInterrupt(RFM_INTPIN); // RFM69 Interrupt number and static RFM69 RADIO (RFM_SS,RFM_INTPIN,IS_RFM69HW,RFM_INTNUM); //Create a Coordinator RFM69 Instance So check the Interrupt pin and the RFM transceiver type you are using with the correct setting (High or Low power) I recommend the following libraries (the one I am using): ESP8266 2.4.2 RFM69 library of 4/10/2016 I know by experience that software library update can be a nightmare (especially with ESP8266 and ESP32) so once it works, I avoid to do unnecessary updates I am not quite sure that the current ones are still compatible. For RFM69 library, try my version of https://github.com/rrobinet/RFM69_Libary For ESP8266 https://github.com/esp8266/Arduino/releases/tag/2.4.2 Robert On 20 Aug 2019, at 00:13, leo <notifications@github.com<mailto:notifications@github.com>> wrote: @mamama1<https://github.com/mamama1> would you mind sharing your sketches? I am trying with delays and yield but I can't get the ack to be received on the node, the message goes through but the sender thinks it fails — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#105?email_source=notifications&email_token=AAJP3TPQ2DBBZAFLS2TGVNTQFMLILA5CNFSM4FAYWTH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4UONGQ#issuecomment-522774170>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAJP3TKQAV56HZRQVNDBFWTQFMLILANCNFSM4FAYWTHQ>.

[ElVasquito]

Hey @rrobinet, I tried your version, but I couldn't make it work. First it crashed about the IRAM_CACHE_ATTR, I changed that and although it doesn't crash anymore, no packets were received at all.
So a big thank you to the OP and to the OP of issue #49. Today I've been struggling all day with this. Up to now, 3:59am. I couldn't understand why 'some' of the packets were not ack'ed, and were retried many times by the node (a Nano). Everything worked perfectly if instead of the NodeMCU I used a Mega2560 as the gateway. First I shorted the wires on the modules, then changed them altogether by shielded ones, lowered the baud rate, and tried MANY things without success, until I found these posts that were a Godsend. That delay(1) tip that changed it all. With 1ms I still got one or two retries every 10-15 packets. With 2ms, I got no Acks lost AT ALL. Is it possible to include this delay somewhere in the sketch instead of having to modify the library? Or even better... solve it without adding a delay?
As previously pointed out, this should definitely be considered for a working ESP8266 example.

[rrobinet]

1. The IRAM_CACHE_ATTR is because you are using version 2.5.x of ESP8266, you should consider version 2.4.2 or patch the RFM library as for: https://lowpowerlab.com/forum/esp32-esp8266/isr-not-in-iram!/msg26926/#msg26926 I did recently upgrade the ESP8266 with version 2.5.2 and was confronted to this issue. When patched, this looks OK now, my ESP8266 coordinator is working fine since few days now. 2. There are several ways to connect the ESP8266 with RFM transceivers, and not all of them are working, so providing an example requires a RFM shield for ESP8266 design a swell (I have some of them but none are working perfectly because of the limited amount of IO pins and usage and interrupt restriction, and FTDI bridge issue at least for me while connecting it on my MAC). See my design attached which is the one I use (this one works with the library versions described earlier) 3. I do no add ack delays, and as far as I remember doing some Send / Receive tests between Moteino and ESP8266 was working fine . However I actually use an old RFM library version modified to negotiate a session key before transferring data which may slow down the data exchange. This version is derived from an old one as indicated in a my previous mail. Since that time the library did change a lot especially regarding the Interrupt routine which is the one that causes or was causing most of issues with Ethernet shield and ESP8266. and I don't want to take the risk of upgrading the RFM library (which is another reason , I don't want to provide an example) 4. The RFM library is made for Moteino and not for ESP8266 (for which each new version is a new problem), so there will not be a lot of support for that type of configuration Robert On 03 Oct 2019, at 09:02, ElVasquito <notifications@github.com<mailto:notifications@github.com>> wrote: Hey @rrobinet<https://github.com/rrobinet>, I tried your version, but I couldn't make it work. First it crashed about the IRAM_CACHE_ATTR, I changed that and although it doesn't crash anymore, no packets were received at all. So a big thank you to the OP and to the OP of issue #49<#49>. Today I've been struggling all day with this. Up to now, 3:59am. I couldn't understand why 'some' of the packets were not ack'ed, and were retried many times by the node (a Nano). Everything worked perfectly if instead of the NodeMCU I used a Mega2560 as the gateway. First I shorted the wires on the modules, then changed them altogether by shielded ones, lowered the baud rate, and tried MANY things without success, until I found these posts that were a Godsend. That delay(1) tip that changed it all. With 1ms I still got one or two retries every 10-15 packets. With 2ms, I got no Acks lost AT ALL. Is it possible to include this delay somewhere in the sketch instead of having to modify the library? Or even better... solve it without adding a delay? As previously pointed out, this should definitely be considered for a working ESP8266 example. � You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#105?email_source=notifications&email_token=AAJP3TLTZABXNBJQETEIQUTQMWKKHA5CNFSM4FAYWTH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAHGWOA#issuecomment-537815864>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAJP3TLXGQGYY4Q345XPW5TQMWKKHANCNFSM4FAYWTHQ>.

[ElVasquito]

Thank you, Robert for you thorough reply. I will try your modified library with session keys. I did found out about the IRAM_CACHE_ATTR issue, and modified it so it didn't crash anymore, but it still didn't receive anything from the node, so that's when I tried with the delay and things got a lot better. Now that I tested more, the delay is not perfect as some Acks get lost and packets resent anyway after a while.
2) I did not see the attached design you mention, I'm interested in checking the connections for your lib, please can you resend?
Thanks again!

[rrobinet]

Please give me your e-mail address I believe this pdf format is not supported by github and I will send it directly an continue to discuss this topic off-line Mine: rrobinet@hotmail.com<mailto:rrobinet@hotmail.com> On 03 Oct 2019, at 21:29, ElVasquito <notifications@github.com<mailto:notifications@github.com>> wrote: Thank you, Robert for you thorough reply. I will try your modified library with session keys. I did found out about the IRAM_CACHE_ATTR issue, and modified it so it didn't crash anymore, but it still didn't receive anything from the node, so that's when I tried with the delay and things got a lot better. Now that I tested more, the delay is not perfect as some Acks get lost and packets resent anyway after a while. 2) I did not see the attached design you mention, I'm interested in checking the connections for your lib, please can you resend? Thanks again! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#105?email_source=notifications&email_token=AAJP3TJCQMG3LVEUHGOX5WLQMZB2ZA5CNFSM4FAYWTH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAJJ3KY#issuecomment-538090923>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAJP3TKAKRYSAIOKA2F7WS3QMZB2ZANCNFSM4FAYWTHQ>.