Ad=s far I understand, we're speaking about radio ACK, which just confirm the right reception on the message, what could be sent. Then, that's gateway that can understand message contents.

If senders returns NACK, it just means that no radio ACK has been received from the other end within timeout (set to 1500 ms with MySensors' setup, running @ 250 kb/s, with 15 retries). That's exactly what happens when sending message and receiver off.

In the current issue, as you're on a repeater, you're in a good position to be in a position of receiving a message, and sending immediately another one (we can also have the same thing if implementing signature), were timing issues may happen.

I'll try to summarize, I do apologies if I didn't understand well:

• It seems that node 7 is properly discussing with gateway as soon as data is local,
• It seems that node 7 is not working properly when relaying data just received,
• It could also be possible that the second time node 25 sends the message, this may be due to not getting hardware ACK from node 7 to the sent message (remind that send timeout is 1500 ns, not so far from the 2 ms). Having a look to node 25 log could confirm this, showing a send ending with a NACK.

To fix the repeat of node 25, I would suggest adding a delay after receiving the message and before sending it to the gateway.

IMHO, when waiting for some time (1500 ns would be theoretically perfect giving current MySensors settings) after a write will cause issue for nodes that will write an answer to you, as you're still waiting after the original write, so you may think about waiting this delay before and after the write (the first one will ensure that the sender finished waiting for the ACK you sent to its write, the second one you received the ACK to your write).

As side effect, this could also fix the relay issue, as we're not protected against chance

@Snyfir: Maybe a timing issue in MySensors code? Are both node and gateway on the same kind of hardware?

It seems also (at least for me) that 2.3.1 may be more concerned by timing issues than 2.3.0, even if I don't saw in the code what could be the real cause. You may perhaps revert to 2.3.0 and see if you still have this kind of issue?

@grumpazoid: I had recently the same issue with a 2560 node and a Nano gateway. I fixed it putting a delayMicroseconds(1500) at (very) top of RF24stopListening function.

LOCAL void RF24_stopListening(void)
{
	// The following delay will allow this node to send an ACK to the last received message
	//	Value should be at least equal to ACR (1500 ms for 250 Kb/s transmission with 15 retries
	delayMicroseconds(1500);			//// *** FF_CHANGE *** //// 
	RF24_DEBUG(PSTR("RF24:SPL\n"));	// stop listening
	RF24_ce(LOW);
	// timing
	delayMicroseconds(130);
	RF24_setRFConfiguration(RF24_CONFIGURATION | _BV(RF24_PWR_UP) );
	// timing
	delayMicroseconds(100);
}

Don't know if your trouble is the same as mine, but hope this helps!

@Anticimex: Ok, I understand.

Would it be possible to imagine that, for gateways having more memory (as 2560 or ESP), in the same spirit as MY_RX_MESSAGE_BUFFER_FEATURE, having a sign buffer feature allowing this?

I should recognize that the event is not so frequent, so that's probably not a priority #1.

Making some extensive tests on message sending/receiving, I may have discovered some issue with signing.

This occurs when 2 nodes are requesting a nonce, while the first don't send signed message before second one asks for nonce.

Here's an example, with nodes 123 and 127:

0;255;3;0;9;891922 TSF:MSG:READ,123-123-0,s=1,c=3,t=16,pt=0,l=0,sg=1:
0;255;3;0;9;891936 TSF:MSG:SEND,0-0-123-123,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
0;255;3;0;9;891959 TSF:MSG:READ,127-127-0,s=0,c=3,t=16,pt=0,l=0,sg=1:
0;255;3;0;9;891974 TSF:MSG:SEND,0-0-127-127,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
0;255;3;0;9;891982 TSF:MSG:READ,123-123-0,s=1,c=1,t=16,pt=5,l=4,sg=1:1
0;255;3;0;9;892011 !TSF:MSG:SIGN VERIFY FAIL
0;255;3;0;9;892016 TSF:MSG:READ,127-127-0,s=0,c=2,t=2,pt=0,l=0,sg=1:
0;255;3;0;9;892022 !TSF:MSG:SIGN VERIFY FAIL
0;255;3;0;9;894198 TSF:MSG:READ,123-123-0,s=1,c=3,t=16,pt=0,l=0,sg=1:
0;255;3;0;9;894213 TSF:MSG:SEND,0-0-123-123,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
0;255;3;0;9;894243 TSF:MSG:READ,123-123-0,s=1,c=1,t=16,pt=5,l=4,sg=1:0
0;255;3;0;9;894272 TSF:MSG:ACK REQ
0;255;3;0;9;894277 TSF:MSG:SEND,0-0-123-123,s=1,c=1,t=16,pt=5,l=4,sg=0,ft=0,st=OK:0
123;1;1;0;16;0```

Is this a known issue? A restriction of current implementation?

@mfalkvidd: thanks for the pointer. For sure, I only did limited testing. However, I carefully read before the NRF24L01+ data-sheet, analyzed chronogram and tried to understand what may happens. But anyway, I must admit that I'm just a newbie in MySensors, and probably had wrong in the approach. Concerning Google spreadsheet, it's not able to understand VBA, and my code dirty code use it hardly

@Yveaux: I'm interesting by the reference in RF24 datasheet that may explain the delays I suppressed, to learn about my error, as I miss them. As of now, I'm thinking that RF24 with auto ACK is properly designed, with symmetrical switch delay of 130 us, except if you turn CE down before sending ACK of the just received message. As the ACK may be repeated, I choose to use the same delay as ARD, even if the probability is not so high. However, you're probably right telling that will break operations for other users. I'll let you decide if adding some delay at top of stop_listening function may help or not. And yes, I tried to apply your reco first, but it didn't worked. I suspect the other delays influencing the issue I had, but removing them all won't worked too. It only worked after adding delay before turning CE down.

Anyway, thanks to all for your help.

Last thing, is someone can tell me how to add [SOLVED] in front of my post, that'll be nice!

@Yveaux: I fixed the issue. I removed all delayMicroseconds in RF24.cpp (except those in RF24_standBy), and added a delayMicroseconds(1500) on very top of RF24_stopListening. I tested with a Nano gateway + Mega node, a Mega gateway and a Nano node, and a Nano node and a Nano gateway. Everything is running smoothly.

Modified file is available (I tried to upload it on forum,, but "Upload file" was returning an error on file type, only allowing images.

Does someone know how to propose the change for a new version of MySensors (sorry, I'm something new on that kind of process ;-)?

In addition, I wrote a small Excel tool to decode MySensors log, mainly on TSF:MSG and RF24:* (see example of output here under). If someone is interested, I can push it by mail, but I would prefer making it available more widely. Is there any already existing way to do this (other than putting on my personal github account)?

@Yveaux: ok, I was not doing change at the right place. However, even at the right place, nothing changed. If I correctly understood, the proposed change only deals with "software" ACK (meaning the receiver re-sends back the just received value to the sender), while the issue on ping is the "hardware" ACK (RF24 acks the correct reception at radio level). However, this probably means that sender is not ready to read the answer (in this case, the nonce from the gateway).

I started reading RF24 datasheet. The only required timing I found are the 10 us CE should stay high at minimum in order to switch from standby to send mode, the 4 us minimum between CE up transition and CSR down and the 100 ms at power up.

I also understood that PA+LN version needs 10 us (hopefully, this is hidden by the 10 us of CE transition to high).

Did I miss something?

@Yveaux: I added the delayMicroseconds(1500) at top of rf24.cpp, and recompiled both node & gateway, but nothing changed...

LOCAL bool RF24_sendMessage(const uint8_t recipient, const void *buf, const uint8_t len,
                            const bool noACK)
{
	uint8_t RF24_status;
	delayMicroseconds(1500);	// *** FF_CHANGE ***
	RF24_stopListening();

I perhaps not properly got the idea...