1500ms between esp_now_send() and callback function being called?

[hdsjulian2]

So i am sending a message to a recipient who has a hw_timer_t interrupt timer running. It takes more or less exactly three timer cycles between esp_now_send() is called and the callback function is triggered. (i call millis() before sending and in the first line of the callback function and output the difference. it's always the same.) I'm wondering why?

On the receiver's side there is a hw_timer_t running with 500ms, so this is basically three hardware interrupt cycles. If I change this timer to 600ms, it takes 1839ms. So I very much assume there is a connection between the timer and the way the message is received.

If I delay(50); sending the message, it takes 798ms.

How is this possible? Or is there - maybe - another solution stuck somewhere in hundreds of lines of code at a non-obvious position?

If anyone is interested, the entire code can be viewed here. The sender is actually the client in this setup. Its code is here.

https://github.com/hdsjulian/sparkles/t ... ent-config

The recipient is the main device. its code is here.

https://github.com/hdsjulian/sparkles/t ... ain-config

[MicroController]

Does anything change if you make messaging::msgSendTime volatile?

[hdsjulian2]

the problem was fixed.

here's the problem: I was searching for a hangup in esp_now_send but there was none.
I did however call a LED function in esp_now_recv (on the sender's side) that was in turn calling a delay()
Turns out that receive callbacks are capable of blocking the entire system, therefore also esp_now_send.

It didn't have anything to do with the recipient's side after all and it was a bug that took me almost all weekend to fix.
Thanks for trying to help