Error sending udp packet

[hubaksis]

Hi,

I receive lots of messages "error sending udp packet" in the console.
When I turned on 'Core debug level: Error' I started to receive an explanation:
[E][WiFiUdp.cpp:183] endPacket(): could not send data: 12
'12' in the errno.h means 'Out of memory'.

Frames are missing and there is constant 2 seconds delay all the time. The picture is not smooth.

CameraWebServer from Arduino examples works fine. Almost no delays. Stream is nice and smooth.
WEBSERVER also is really fast. No delay, no frames skipped.

What I have tried:

1. I tried to connect to the camera from my desktop and from my phone, the result is the same.
2. Also tried to comment out WEBSERVER part - it seams it doesn't influence on the memory usage.
3. Use SOFTAP mode. The result is the same, so my network configuration is not a culprit.

Hardware: bought here https://www.aliexpress.com/item/32964004777.html
I use esp32cam_aithinker_config. Others don't work.
When I upload the program I use the following config:
ESP32 Wroover module
80MHz
Partition Scheeme: Huge APP (3MB no OTA)
Core debug level: Error

Any idea why this is happening and how to fix it?
Thanks.

[romainbessugesmeusy]

I'm running into the same issue. I think it may be related to packet size and/or image size. Do you have any update on your side?

[bartlomiejcieszkowski]

I've tried to narrow down the problem, from the network logs in wireshark it looks like that the packet once in a time doesn't go out of ESP.

I stumbled upon similiar problem here
esp8266/Arduino#2285

and it looks like the udp lwip underneath doesn't care if the tx is full and would just ignore the packet and wont add it to a queue, hence missing packet in wireshark.

One of solutions is to add in platglue-esp32.h function udpsocketsend after endPacket:

delay(1);
or at least a
yield();

so the hw has a chance to pass on the data and make some space in tx for next packet.

With the delay it looks like it's lowering the unsent packets count.

There's also in the linked issue idea of adjusting buffer size in lwip, although it might just postpone the problem.

also from this issue
esp8266/Arduino#1988
there is a new lwip2 esp8266/Arduino#3783
but i havent tried it yet

[fmatray]

I also had this issue and the delay() mitigates the problem.

[Tony763]

For me adding -D PIO_FRAMEWORK_ARDUINO_LWIP2_HIGHER_BANDWIDTH to build_flags helped, but now I have log full of [W][rtsp_server.cpp:55] doLoop(): warning exceeding max frame rate of 237 ms

[patwiken]

I had the same issue but neither the delay or the -D PIO_FRAMEWORK_ARDUINO_LWIP2_HIGHER_BANDWIDTH solve the problem. Have you solved the problem?

[brainrecall]

I went looking at the CameraWebServer example from Arduino. What I noticed snuck down halfway into the .ino is s->set_framesize(s, FRAMESIZE_QVGA); so they are intentionally dropping the resolution to get smoother framerates. What resolution are you running with Micro-RTSP?

I've been investigating performance issues as well. The more I dig, the more I'm thinking that we're just pushing the ESP32 too hard.

[brainrecall]

I've been looking and I believe PIO_FRAMEWORK_ARDUINO_LWIP2_HIGHER_BANDWIDTH only applies to the esp8266. From what I can tell and find, there are no exposed options to change networking performance or behavior on the ESP32 Arduino framework. Simply, the ESP32 just doesn't have the community or time as the esp8266.

What I found is attempting to do a yield() does at least reduce the error, but moving to an external antenna seems mandatory to get something effective. Even then, I still see dropped packets at the client in a slightly noisy Wifi environment. I don't think the ESP32 can reliably blast this many packets at this rate.

[xenois]

Anyone found a solution for this? The problem still persists for esp32

[PhatHub]

Anyone found a solution for this? The problem still persists for esp32

Same here. I was following a project from [bnbe-club's RTSP streamer](rtsp-video-streamer-diy-14 and I went on to other ESP32-cam RTSP projects and they all had UDP errors.

Even the esp32 example web server was horrible, and the image would stop after about three or four frames.

Would it be better if we went away from Arduino and worked with platform.io versions instead?

[Tony763]

It will be a same, Platform.io still use Arduino core.
My ESP cam throws UDP errors when I supply 5V and it use internal LM1117 to convert it to 3.3V (Maybe some noise from it).
When I supply 3.3V directly (3.3V pin), there is no UDP error, but brownout sometimes trigger even if I use laboratory power supply. I can measure 2.8V at ESP Vin leg. I will try to trace all parts and traces on board to 5V pin and try to HW mood it.

PS: I use Platform.io

[PhatHub]

That's interesting. For some reason I though Platform.io used the IDF ecosystem.
I also have seen #28 PR for mitigating UDP flooding... adding yield() in the loop doesn't help?

[Tony763]

You can select if you want to use IDF or Arduino, but I think this library is not compatible with IDF.

With 5 V connected, yield did not help. You can slow down a frame rate to prevent UDP flooding but sole delay cannot be used.

I use this, but it needs update to prevent/fix behavior when millis get reset.

void delay2(int period)
{
    unsigned long time_now = millis();
    do
    {
        delay(1);
        yield();
    } while (millis() < time_now + period);

[PhatHub]

@Tony763 Ah okay. So it's a power issue. I'm looking at the schematic on "randomNerdTutorials" and the 3.3v is pushing pentuple duty between the ESP32 (VDD), 2.8v regulator, the 1.2v regulator, the camera's 3.3v line, and the SD card... not counting the LED.

That half volt sag is interesting too. Probably needs a fat capacitor?

Searching around, I saw a Reddit post by a "TonyP7" Was that you? 😆 It recommends capacitors that are far bigger than what I found in the schematics...

[PhatHub]

Okay. I figured out a small "fix" to my issue... there's a [theoretical] problem of interference between the antenna and the CSI clock line.
The "magic" repair is to place your finger firmly on the ESP32-CAM logo behind the PCB antenna.
The cause of the framerate increase is unknown, and the solution is not practical.
I've attempted to place aluminum duct tape on that part of the board, but it seems to require thicker metal for results comparable to my finger (at least 2mm thick aluminum). I clipped on a small piece of aluminum sheet and it worked better.

If I find again the forum where this "solution" was announced by accident, I'll link it here.

[PhatHub]

Found it: "ESP32-CAM, super fast frame rate when putting the finger on the ESP32-CAM label"
https://www.reddit.com/r/esp32/comments/r7kqtt/esp32cam_super_fast_frame_rate_when_putting_the/