ESP32 Forum

Hi all,
I want use the ESP32 for my application and I am trying all features, which I am using (UDP, TCP, Multicast, ...).

I have problem with the receiving UDP. I cannot receive UDP data in AT application. I tried register server with the port and no data received. I tried multicast IP and port, too, but no changed.

Could you help me please?
Thank you very much!
Best Regards,
Vilem

I'm also having the same problem.

Using the latest AT firmware (built from current GitHub source), I am able to change the multicast group using AT+CIPSTART="UDP","228.5.6.1",6789 (tried with CIPMUX=0 and 1) but it never receives any data from others in the group - it does however transmit fine.

Am I missing something? Is it possible to license the code to libat_core for our project? I have made multicast work quite reliably using the IDF, so I don't understand why the AT firmware seems to not work for this application.

Thanks!

Hi,
I solved this problem using MDNS command "AT+MDNS=1,"espressif","_iot",8080" it register to multicast group. After start MDNS, I used stop "AT+MDNS=0" and the multicast group should be still register. It is my hack for it

Now, I am working on own solution - connection between ESP32 and MCU via SPI. I want use TCP/IP stack on MCU not in ESP32.

Best regards.
Vilem

Interesting... I will give that a try today.


Sounds like an interesting project. I still need to get the AT firmware working over SPI. I have done all the config and it builds, but haven't tested it yet. Remoting the IP stack should be possible, but haven't tried that yet. For our project, the ESP has much more ram and flash than our primary MCU we use for realtime operations (Kinetis K24) - so we are looking at moving some things the other direction. We will use the ESP for OTA updates of both processors, so that will be my next challenge once multicast is working.

Thanks!

I tried the MDNS trick before joining the multicast group - in my case it made no difference. Data is still not received, but can send data to others. Very weird. I'd rather not write my own firmware to handle this, but if the AT lib won't work, and there is no source available, it looks like we will have to.

Oh, one additional thing, I am using the same address and port as MDNS (224.0.0.251 and port 5353).

Interesting... Yes, following those steps, I do see data coming in, but it is spotty - probably 25% of the packets sent are seen, and of course I see the MDNS traffic from other devices. So, yes, this proves it "works" but I need to reliably use other UDP addresses and ports. Shame it doesn't seem to work as needed. We will most likely have to write custom firmware for this.

Thanks for the help - it allowed me to fully evaluate things.