Esp32 issue

Sounds like the surge in current that occurs when the ESP32's wireless circuitry is activated is loading down your supply and causing the voltage to drop. How much current can your supply output and what's the current rating on your lm2596 buck converter board?

What current resistors have you on the LED's.. Depending on vision an LED can light with a few milliamps..

Assume 2 forward volts and a 3.3v supply each led will need 270 ohm resistors to keep the current low.
I'm thinking more that the LED's are robbing the wifi..

Which IDE are you using to program the ESP?

Do you have any code to force tasks to Core 0 or Core 1?

Is your code written to call a value from WiFi just when it is needed and your code waits for the value?
Or,
Is it written to grab the new value via WiFi as soon as the previous value was used? Or,
well before the next value will be needed?

Use external driver ICs for the display to offload current from ESP32 GPIOs; ensure display refresh timing is reliable (e.g., using timers or tasks) to avoid software interruptions.
maybe you can read Why Use STM32 Instead of ESP32?

Network delays range well into the eye response producing unwanted visual effects
in display appearance to human eye. Even in non networked environments in tight
code loops.

A technique I have used on simple non networked character oriented displays is create a display
buffer that replicates the display under use. Then in code loop display buffer data is checked
to see if a change is needed comparing char for char in the buffer. If it is the display is written
and buffer updated. If no change is needed actual display not written. This eliminated a lot
of visual "artifacts" in tight code loop excessive un-needed write activity. Given most char
displays have their own async controller on the modules compounding the problem. But works
as well on limiting write thrashing on bare display solutions.

Given you are working with bare 7 seg LEDs another consideration is modern leds can
glow at very low currents, so digit to digit timing can produce unwanted effects. Like
changing from one digit to another then updating seg data. Better yet turn off digit,
update segment drives, then turn digit back on.

In closing I think the network activity will definitely affect real timing of other processes
on an ESP32, so using FreeRTOS and creating a priority task can help in this as well.
This is not trivial to setup for first time user, at least its not been for me recently learning
multi-tasking, but very effective for handling multiple processes. At least if you are using
dual core part run the display code on the other core. As a new learner I am working on a
solution with many near simultaneous processes, using FreeRTOS dramatically simplified
code and managed this. But its not a 1 hour fix.....to develop.

One other development aspect of ESP32, its largely an open source driver environment. So
updates to the IDE can cause compile problems because one developer made changes to
his lib. So you might have to revert to earlier lib versions and keep track of all that implies.

I use both C and block language (Tuniot) to do programming. Check out Tuniot, it includes
multitasking blocks easily configured. Here is a series done by author on youtube showing
how rapid it is to create projects.


Nodered also another way of doing this.

ESP32 drive levels allowed :




Regards, Dana.