ESP32 Multicast UDP High losses (receiving)

Question

I'm developing device base on ESP32 module that have a UDP socket open only to receive broadcast packets on one port (7890 to be exact). The problem is that the data losses are high - around 90%. My test setup is:

ESP32 - connected to WiFi network with open UDP receing task (code belowe)
PC connected to the same netwer via LAN with UDP terminal set to brodacast to remote: 192.168.10.255:7890
Mobile phone connected to WiFi with UDP terminal set to brodacast to remote: 192.168.10.255:7890

When I send something from PC or mobile phone there is no data lossage between Mobile phone and PC but ESP32 receive around 10% of data that I transmit from both of senders. If I change from multicast to unicast on PC or Phone to send data to ESP32, it work without problem.

I know that UDP does not guarantee the delivery but 10% efficiency seems for me to be super low, especially when it seems that there is no problem with busy network because PC and mobile received the data all the time.

Do you have any suggestion to the code or some setting that can be changed in menu config ? At the moment my application have only two tasks:

WiFi Task that after connection is just waiting for event
UDP Task that the code is below

Update 04.07.2018 (13:15)

Problem disappear when I don't initialize bluetooth. Sorry that I didn't mention previously about BT being initialized but I kept me initializing function from my normal program that have a lot more tasks (BT included) and totally forgot about this myself.

Anyway - do you think that there is some issue with sharing the resource or is it some physical interference ? I'm using ESP32-DevKitC that is on the breadboard, so no additional shielding is present.

#define PORT_NUMBER 7890
#define BUFLEN 100

void udp_task(void *pvParameter)
{
   struct sockaddr_in clientAddress;
   struct sockaddr_in serverAddress;
   struct sockaddr_in si_other;
   unsigned int slen = sizeof(si_other);
   unsigned int recv_len;
   char buf[BUFLEN];
   int sock;

   printf("UDP Task: Opening..\n");

   int ret;
   ret = UDP_List_Open(&clientAddress, &serverAddress, &sock);

   if(ret == 0)
   {
      printf("UDP Task: Open\n");
   }
   else
   {
      printf("UDP Task: Can't open\n");
   }


    while(1)
    {
        memset(buf,0,100);

        if ((recv_len = recvfrom(sock, buf, 100, 0, (struct sockaddr *) &si_other, &slen)) == -1)
        {
            printf("UDP error\n");
            break;
        }

        sendto(sock, buf, recv_len, 0, (struct sockaddr *)&si_other, sizeof(si_other));

        printf("UDP Task: Received packet from %s:%d\n", inet_ntoa(si_other.sin_addr), ntohs(si_other.sin_port));
        printf("UDP Task: Data: %s -- %d\n" , buf, recv_len);
    }

   while(1)
   {
      vTaskDelay(100 / portTICK_RATE_MS);
   }
}


int UDP_List_Open(struct sockaddr_in* clientAddress, struct sockaddr_in* serverAddress, int* sock)
{
    // Create a socket that we will listen upon.
   *sock = socket(AF_INET, SOCK_DGRAM, 0);
   if (*sock < 0)
   {
      printf("UDP List Open: Socket error\n");
      return 1;
   }

   // Bind our server socket to a port.
   serverAddress->sin_family = AF_INET;
   serverAddress->sin_addr.s_addr = htonl(INADDR_ANY);
   serverAddress->sin_port = htons(PORT_NUMBER);
   int rc  = bind(*sock, serverAddress, sizeof(*serverAddress));
   if (rc < 0)
   {
      printf("UDP List Open: Bind error\n");
      return 2;
   }

   return 0;
}

BT and Wifi are sharing the antenna. In your case, when the BT acquires the antenna, your socket is sending and there are no error, because you are not expecting a response, but nothing is leaving the esp. When BT is releasing the antenna your wifi has connection is sending again. I have kind of the same problem atm and looking for a solution. https://stackoverflow.com/questions/55865909/acquire-a-semaphore-for-the-esp32-antenna-bluetooth-wifi-dualmode — Dimfred, Apr 27 '19 at 17:38

Rudy · Answer 1 · 2018-07-03T17:39:40.283

-1

Even though UDP is considered fire and forget, (unlike TCP), unicast UDP through WiFi is reliable because reliability is built into the WiFi protocol. But this can work for Unicast only because there is one known recipient. Multicast UDP is unreliable because there are no checks and retries.

I had the same problem when I was trying to use multicast UDP with the ESP8266. It caused me to dig deeper into the issue. In the end I use UDP multicast for discovery but then switch to Unicast UDP for subsequent transfers.

See Multicast Wifi Problem Statement https://tools.ietf.org/id/draft-mcbride-mboned-wifi-mcast-problem-statement-01.html

edited Jul 03 '18 at 17:39

answered Jul 03 '18 at 17:34

Rudy

134
1
6

Thanks, My idea was the same: use server broadcast to discover the device and after that connect them with unicast, but discovery can take a lot of time with such losses (for ex. 15s interval in broadcast can end up in 150s of discovery time). I'm aware that UDP in multicast is not reliable but 90% of packet error rate (PER) seems to me too high, in every article they are mentioning 5, 10 or 15% of PER but not 90%. – Konrad Jul 04 '18 at 06:10
It really depends on the specific situation. How much activity is happening on that band of frequencies. The physical position of the radio (on both ends). I had a few modules active in my tests and some would have a harder time than others. And moving the radio changed things. – Rudy Jul 04 '18 at 13:03
At work we have a WiFi for testing, and on of the software developers told me that he knows when I use the microwave oven at lunch time because the WiFi stops working. When you switch to Unicast you see the difference. And as far as the radio transmissions go, there is no difference between multicast and unicast. The difference is in the retries. – Rudy Jul 04 '18 at 13:10
That is funny and terrible at the same time. Anyway, it turns out that the bluetooth is responsible for losses, I'm not sure though whether it is some software or physical issue. – Konrad Jul 05 '18 at 06:11

ESP32 Multicast UDP High losses (receiving)

1 Answers1