Does anyone use ESPNOW communication with this library?

[jakezilla]

I'm building a system comprised of 8 ESP32 based modules communicating with ESPNOW. All devices unicast to a single 'main module' and then that main module unicasts back out to whichever module needs new data. ESPNOW unicast has built in acks and retries. All the modules except for the display module are running a fairly simple main loop() doing things like driving RGB LEDs or reading a sensor value.

Compared to the simple modules, the display module has significantly less range. Sometimes the display module will not ack the ESPNOW communications, but I can tell by the data it is displaying it did indeed get the communication. To me it is acting like the ESPNOW receive process is getting interrupted before it can ack, even though it did get the data, but I don't know for sure.

I thought since this library used DMA, that having issues with that sort of blocking wouldn't be possible?

I'm currently using a Waveshare P4 64x32 matrix display, so I'm not trying to drive a ton of data to the display. I also tried swapping out the ESP32 and the two modules act identically. At this point I'm leaning towards adding another ESP32, one for coms, one for display, or getting an ESP32-S3 and trying to set up the dual core similarly.

[mrcodetastic]

It is worth raising this issue at the esp32.com forum to see what they think.

There is nothing the library can do here. It creates a DMA loop and the rest is managed by the esp32 silicon.

Perhaps there is some bug in the esp32-idf or there is some bizarre silicon limitation.

What specific variant of the esp32 are you using, the "original" esp32?

[jakezilla]

I didn't mention it in the first comment, but thank you for making this great library!

I'm running it on the "original ESP32 (released 2016)". https://a.co/d/9Xizn1H

I do have double buffering on, but to test I commented out mxconfig.double_buff = true; and display->flipDMABuffer();. It still exhibited the same behavior.

I'll do some digging and see if anyone on the esp32 forums has seen anything with DMA impacting ESPNOW coms.

[jakezilla]

I just split the code between two projects, one with the ESPNOW stuff and one with everything for driving the display. I added a quick and dirty UART communication scheme to go between the two. Programmed two ESP32 boards and connected GND, RX and TX between them.

The system works perfectly. No range issues, no ack issues; just as I'd expect it to function.

So yeah, I'm leaning towards thinking there is some undocumented interaction or limitation between DMA and their implementation of ESPNOW. Or, at least one I don't know about or understand.

Thanks again for the library and the help!

[mrcodetastic]

Glad you like the library. Thanks for your kind words.

Do you mind posting some basic espnow tx and Rx example code? I wouldn't mind learning about this more. I have a bunch of esps I want to have communicate between over the air.

[jakezilla]

Sure thing! I started with this tutorial and it was a great place to start IMO.
https://randomnerdtutorials.com/esp-now-esp32-arduino-ide/

At the beginning of the article they have links to more advanced tutorials. A few things to note that I don't see discussed often:

• Setting up all devices to just send to the Broadcast address is very easy since you don't need to know MAC addresses of any of the modules. But, there is no ack or retry when transmitting to the Broadcast address, so if a module misses the message, there is nothing built into the system to catch it.
• The automatic ack/retry behavior is nice, but I do have an issue with it. You are told that the message send was successful or not, but I don't see any way to identify if any retries were needed. This means that with an intermittent connection, the transmit time can start to vary quite a bit, and that is bad for my system because timing is essential for me.
• Changing WiFi channels to try and avoid interference was hard to figure out and there is some old info floating around out there on the interenet. This is the code I use to change to a different, less congested WiFi channel, defined by "WIFI_CHANNEL". Note, this must be the same value in the esp_wifi_set_channel() function as well as the peerInfo.channel. It also must be the same on every module that you wish to communicate between. The default channel (0) should work for most people, but I was getting interference in some locations.

  WiFi.mode(WIFI_MODE_STA);
  WiFi.setSleep(WIFI_PS_NONE); // should be default, but might help
  WiFi.disconnect();
  ESP_ERROR_CHECK(esp_wifi_set_channel(WIFI_CHANNEL,WIFI_SECOND_CHAN_NONE));
  if (esp_now_init() != ESP_OK)
  {
    Serial.println(F("Error initializing ESP-NOW"));
    ESP.restart();
  }
  esp_now_register_send_cb(OnDataSent);
  esp_now_register_recv_cb(OnDataRecv);

  memcpy(peerInfo.peer_addr, broadcastAddress, 6);
  peerInfo.channel = WIFI_CHANNEL;
  peerInfo.encrypt = false;
  if (esp_now_add_peer(&peerInfo) != ESP_OK)
  {
    Serial.println(F("Failed to add broadcastAddress"));
  }
  memcpy(peerInfo.peer_addr, mainESPAddress, 6);
  peerInfo.channel = WIFI_CHANNEL;
  peerInfo.encrypt = false;
  if (esp_now_add_peer(&peerInfo) != ESP_OK)
  {
    Serial.println(F("Failed to add mainESPAddress"));
  }

[mrcodetastic]

Thank you so much for this!