Closed 2ni closed 6 years ago
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.
Looks similar to https://github.com/LowPowerLab/RFM69/issues/49 where the delay(1) was added in canSend()
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.
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 GitHubhttps://github.com/LowPowerLab/RFM69/issues/105#issuecomment-461653708, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABL9zTmsu1G-88KfXoFR_2CUjCX-cIPzks5vLMxPgaJpZM4UGLTP.
@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
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:
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:
@mamama1https://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 GitHubhttps://github.com/LowPowerLab/RFM69/issues/105?email_source=notifications&email_token=AAJP3TPQ2DBBZAFLS2TGVNTQFMLILA5CNFSM4FAYWTH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4UONGQ#issuecomment-522774170, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAJP3TKQAV56HZRQVNDBFWTQFMLILANCNFSM4FAYWTHQ.
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.
Robert On 03 Oct 2019, at 09:02, ElVasquito notifications@github.com<mailto:notifications@github.com> wrote:
Hey @rrobinethttps://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 #49https://github.com/LowPowerLab/RFM69/issues/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 GitHubhttps://github.com/LowPowerLab/RFM69/issues/105?email_source=notifications&email_token=AAJP3TLTZABXNBJQETEIQUTQMWKKHA5CNFSM4FAYWTH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAHGWOA#issuecomment-537815864, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAJP3TLXGQGYY4Q345XPW5TQMWKKHANCNFSM4FAYWTHQ.
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!
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.commailto: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 GitHubhttps://github.com/LowPowerLab/RFM69/issues/105?email_source=notifications&email_token=AAJP3TJCQMG3LVEUHGOX5WLQMZB2ZA5CNFSM4FAYWTH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAJJ3KY#issuecomment-538090923, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAJP3TKAKRYSAIOKA2F7WS3QMZB2ZANCNFSM4FAYWTHQ.
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?