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/

[davygravy]

I experienced this behavior of UDP packet flooding on ESP32-CAM-MB AI-THINKER also. While customizing an app/firmware for RTSP (https://github.com/rzeldent/esp32cam-rtsp), I noticed on the serial monitor suddenly a flood of errors

20:32:45.903 > [110276][E][WiFiUdp.cpp:183] endPacket(): could not send data: 12
20:32:45.909 > error sending udp packet

I found it so strange that I hadn't seen a single such error before ... I mistakenly thought for while that I'd clobbered a line of code somewhere... but diff didn't show anything.

Finally I discovered that it was related to the spare/test router (an older 802.11n Cisco Valet Plus flashed with FreshTomato) that I was using in my workshop/office to test the ESP32 wifi reconnect/OTA and camera restart modifications I was working on. When I shut the test router down and connected to the regular routers, the errors disappeared.

Incredulous, I replicated the behavior 2 more times just to make sure I wasn't seeing some sort of incredible fluke behavior.

It WAS just the extra router - perhaps interference or some sort of channel impingement. I did not have to mitigate the issue with any changes to code.

But it did clarify and underline a problem I'd been having with one such module that is pointed to my back yard: that unit was on the back of my garage next to the underside of the soffit (aluminum), and I'd been getting a lot of annoying dropouts from it. I suspected interference from the aluminum, and I lowered it by 6 inches - problem solved. I would not be surprised if the UDP flooding would have been visible had that module been connected via serial monitor, as well.

While the PCB antenna on these units is a limiting factor, I do have ESP32-CAM's (four in all) working reliably and like champs, ATM. YMMV.

[brainrecall]

I've been working with this for awhile, and I believe the problem is not entirely related to software. Using the ESP-IDF with my branch, I've been running 4 cameras for multiple months, but I'm running them at relatively low frame rates and resolutions.

UDP is supposed to be fire-and-forget, but Wi-Fi at a low-level isn't, there's some back-and-forth to ensure at least any packet sent from a device makes to to the access point, otherwise the losses would be so great it wouldn't be practical. That means the ESP32 has to have fairly good transmission AND reception to work. Interference on a channel can give it heartburn, as you saw. I have all my cameras on external antennas, the onboard antenna is really only good for periodic messages like MQTT, high bandwidth constant-traffic needs a better antenna for reception and transmission.

I'm suspecting the issue is more fundamental. Even with external antennas and directly using the latest ESP-IDF environment I would on occasion get a dropped frame or even a crash (white screen, or simply nothing). Now, granted, it did take 3 or 4 months of continuous 24/7 operation to see them, but they did occur. I took a glance at the wiring diagram for the ESP32-CAM, and I think I see a possible problem. https://github.com/SeeedDocument/forum_doc/blob/master/reg/ESP32_CAM_V1.6.pdf

There is a 3.3V regulator that supplies both the ESP32 and the camera module. There is only 110nF of capacitance on that rail. I think that is far too little. (Granted, there is a 10uF capacitor, but that's on the 5V side, and the regulator may not be fast enough to keep up with sudden demand from, say, transmitting a packet.) I'm experimenting with adding a 10uF cap I had laying around (soldering right to the 3.3V and Gnd pins of the ESP32-CAM module) to see if that helps. So far so good.

This is just a theory, but I'd thought I'd mention it.

[SnowSakuraKo]

I have the same issue. it used to work but error appears for a sudden. Now the RTSP stream cannot open.
Error message: error sending udp packet

It's wired because the issue is not there at first :)

I tried yield() and delay(), they don't work.

[druckgott]

My solution was to power up with 5V and to remove rx/tx connection. Only Power Supply then the rtsp stream works.
Combined with this: (the plastic cover on the edge), It now works perfekt.
https://www.reddit.com/r/esp32/comments/r7kqtt/esp32cam_super_fast_frame_rate_when_putting_the/