[SOLVED] Timing issue with 2.3.1, RF24 and Mega 2560

[Yveaux]

@flyingdomotic it's likely this issue : https://github.com/mysensors/MySensors/issues/1134

[FlyingDomotic]

@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...

[Yveaux]

@flyingdomotic said in Timing issue with 2.3.1, RF24 and Mega 2560:

I perhaps not properly got the idea...

Perhaps not. The issue states it has to be added to MyTransport.cpp, exactly at this line: https://github.com/mysensors/MySensors/blob/development/core/MyTransport.cpp#L730

[FlyingDomotic]

@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]

@flyingdomotic I suspect it might have the same failure cause, when a node/gateway switches from receive to transmit (for the PONG response) too fast, preventing the hardware ACK from being transmitted to the sending node (the PING).
Especially this code looks suspicious: https://github.com/mysensors/MySensors/blob/development/core/MyTransport.cpp#L786
Try enabling that code on the fast node first.

You could also try adding a delay after reception of a message to assure there's time for the hardware ACK just before the return statement here: https://github.com/mysensors/MySensors/blob/development/hal/transport/RF24/MyTransportRF24.cpp#L148

[FlyingDomotic]

@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)?

[mfalkvidd]

@flyingdomotic the code contribution guidelines are available at https://www.mysensors.org/download/contributing

But I doubt the delays were sprinkled randomly around the code for no reason, so while it seems to work based on your limited testing, performing the proposed change will probably break communication for a lot of people.

For the log decode, maybe your tool could be merged with https://www.mysensors.org/build/parser ?
An alternative might be to publish it as a google spreadsheet?

[Yveaux]

@flyingdomotic I agree with @mfalkvidd. The delays follow the original nrf24 datasheet closely. If it works for you, it might break operation for many other users.
Your changes likely mask the real issue.
Did you try my suggestions?

[FlyingDomotic]

@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!

[mfalkvidd]

@flyingdomotic I agree that references to relevant part of the datasheet for each delay would be good. Now they are just magic numbers. Without such references, understanding, reviewing, extending and maintaining the code is extremely hard.

For [solved], edit your first post and change the headline (you might need to scroll up to see the headline if you are on mobile)