PWM fluctuations with Wi-Fi STA

[volgunov-ad]

I use PWM to control the lights.
If I turn on Wi-Fi in STA mode, at low duty PWM there are noticeable non-periodic faint fluctuations of light. If I turn on AP mode Wi-Fi, everything is normal, the light is constant.
ESP-IDF v.4.4.4, micropython 1.20

[volgunov-ad]

I use a 12V bulb connected to ESP32-PICO-MINI-02 via an IRLB8314 MOSFET (same situation with other transistors) with a driver based on two transistors in a two-cycle emitter repeater scheme

[davefes]

I suggest monitoring the supply voltage across the 12V bulb with an oscilloscope, maybe the WiFi is drawing random extra current.

[volgunov-ad]

Right now I don't have a good enough oscilloscope to check the voltage. But I connected a 24V LED strip with an appropriate power supply and did not see any light fluctuations.

[volgunov-ad]

No, now I looked closer and found that even at 24V there is a noticeable oscillation, although smaller

[robert-hh]

Which PWM frequency and duty cycle have you set when it happens? Is there any WiFi activity when the fluctuations happen?

[volgunov-ad]

This happens at different frequencies, tried both 1 kHz and 50 kHz, same thing.
This effect disappears at about duty_u16(5000)

[volgunov-ad]

At larger duty, it is probably impossible to distinguish these fluctuations with the eye.

[volgunov-ad]

Wi-Fi activity is present, MQTT client is working, but if Idisable it, nothing changes.

[volgunov-ad]

If I call machine.reset(), the oscillations stop completely for a while while the reboot is in progress
Apparently it's the Wi-Fi that's affecting it.
When I connect the device to the ESP in AP mode, there are fluctuations

[davefes]

Try a 1000uF electrolytic capacitor on the 3V3 supply on the ESP32 to help remove any voltage fluctuation caused by WiFi activity.

[volgunov-ad]

I only found 2 capacitors 470 uF. Installing them in the 3.3V circuit did not change the situation in any way
I have a feeling that Wi-Fi is interfering with the PWM specifically at the software level, taking up CPU time. Could this be the case?

[robert-hh]

I have tested the PWM with & without WiFi. Test condition freq=1250Hz, duty_u16=5000 and duty_u16=100. Output load to GND 560Ohm. ESP32 test board is an Wemos ESP32 Lite. ESP-IDF 4.4.2
Both frequency and duty cycle are very stable. When WiFi is started, the frequency drops a little, by 6 mHz.
The output amplitude is stable without WiFi. With WiFi active, there are small variations of the output amplitude. Pk-Pk variation is 34mV at an average amplitude of 3.366V.
Is the power supply of the ESP32 stable? Are the transistors for driving the bulbs saturated, when switched on?

[volgunov-ad]

So there's probably a problem with my circuitry, I'll think about it.

[xuancong84]

The PWM is hardware driven, using the crystal as clock source.

Nope, MicroPython PWM (for ESP8266 at least) is done by software, so if you do machine.disable_irq(), your PWM output will be either 0 (0V) to 1 (3.3V).

[robert-hh]

This discussion is about ESP32.

[xuancong84]

This discussion is about ESP32.

Sorry, so do you have any solution or resolution for the fluctuating PWM on ESP8266?😅 I suspect the Wifi handler runs critical loops at times which causes PWM to missing cycles. However, if I use Arduino C++ on ESP8266, Wifi function does not cause fluctuation on PWM output. So the problem is definitely solvable on MicroPython side.

[robert-hh]

No solution, sorry.

[volgunov-ad]

I changed the transistor connection scheme, used a different driver and supplied 5V to the gate. Now everything is stable

[xuancong84]

I have found the partial solution on ESP32 for sending infra-red remote-control signals.

Emitting infra-red (IR) remote-control signal requires turning on and off PWM pulses (of fixed frequency) at specific time intervals. Very often, this was interrupted by Wifi/BLE/etc interrupts, and the signal was corrupted, leading to randomly failed attempts.

ESP-IDF does provide functions for enabling and disabling interrupt by mask, as well as getting enabled interrupt masks. These functions are respectively: esp_cpu_intr_enable(), esp_cpu_intr_disable(), and esp32_intr_get_mask(). Thus, if we disable all interrupts except PWM (I presume PWM interrupt number is 18) and run the critical-section job for sending IR pulse, the resulting PWM IR pulse should be intact, minimizing the chances of failure. The code is in my commit (xuancong84@83877c0), you can pull in the changes made in modesp32.c.

In general, perfectly solving this problem is not possible because in a complex situation with potential Wifi/BLE/hardware-IO/etc inputs at any time, you have to sacrifice some for others. So if the PWM is perfect, then you will end up with randomly failed Wifi/BLE/hardware-IO/etc reception. However, if the period is short, you can use my trick to ensure at least that during this short period, PWM signal is stable and uniform.

[volgunov-ad]

For IR remote-control you can use RMT https://docs.micropython.org/en/latest/library/esp32.html#esp32-rmt

[xuancong84]

Thanks, that is really useful. How about reading the pulses? Also, is it portable to ESP8266?

[xuancong84]

I found that ESP32 supports hardware PWM (as long as you do not use up all the 8 high-speed PWM channels). Thus, PWM output is stable even after machine.disable_irq() and there is no PWM fluctuation due to Wifi/BLE. However, ESP8266 does not support hardware PWM, PWM pin outputs either high or low after machine.disable_irq(). So is there a way to disable specific interrupt numbers on ESP8266? Thanks!