Something going on in background??

[pmulvey]

I have this code that simply ramps up and down my RGB LED. It works fine except that approx. every 5-10 seconds the LED gives a flicker as if some other activity is happening within the esp8266. Same issue with NodeMCU V3 and Wemos D1 Mini.

def RGBRamp():
pwm = machine.PWM(machine.Pin(13))
pwm.freq(60)
for i in range(1023, -1, -1):
pwm.duty(i)
time.sleep_us(1000)
for i in range(1024):
pwm.duty(i)
time.sleep_us(1000)

[pythoncoder]

This is rather odd. I managed to replicate it on the reference board using the onboard blue LED:

Code: Select all

import machine
import utime as time
def RGBRamp():
    pwm = machine.PWM(machine.Pin(2))
    pwm.freq(60)
    for i in range(1023, -1, -1):
        pwm.duty(i)
        time.sleep_us(1000)
    for i in range(1024):
        pwm.duty(i)
        time.sleep_us(1000)

while True:
    RGBRamp()

For the first minute or so there was occasional flickering, but after that it stopped occurring. I never saw it when running at a constant duty ratio. So the fault seems to be associated with PWM.duty().
[EDIT]
On reflection you are setting the duty ratio at a much higher rate than the pulse repetition period (16.7ms). I'm not sure what is the expected outcome of setting the duty ratio 16 times per cycle. With a frequency of 4KHz and a delay of 2ms I saw no flickering.

What I think is going on is that if you call pwm.duty() at exactly the "wrong" point in the PWM cycle you can get a single PWM cycle of incorrect width. With your very low PWM frequency this pulse is visible. With a higher frequency, even if bad pulses occasionally occur, they would be invisible because of their short duration. Proving this would take some effort.

PWM is normally used in systems having a filter which averages the result. This filter can be implicit - human persistence of vision or DC motor armature inertia. The PWM frequency is chosen to be much faster than the time constant of the filter. So a rare single pulse with incorrect width would have minimal effect.

If this explanation is correct, while technically a bug, I'm unconvinced it actually matters.

[pmulvey]

I ran up a piece of code on the Arduino IDE to do the same thing. There is no flicker here. Seems to be a micropython issue. Not having captured the flicker on a storage scope I am guessing (visually) that it has a duration of maybe around 10mS. Again not having tried it on a motor I suspect that it might produce an audible kick on the armature.

As a newbie to Python I'm wondering about the maturity of micropython. Certainly there seems to be only relatively crude IDEs available. I am using EsPy 1.0.0.7. and it is just adequate. Interesting bug... the Find option is permanently greyed out.

Also my DS18B20 returns 0 degrees and a bad CRC a couple of times a minute. I must check it on Arduino code.

[pmulvey]

I realise that it might not matter in most situations except if you created a mood light with it. Instead of calming you down it would probably drive you crazy!

[pythoncoder]

@pmulvey Given that I could detect no flickering with a 4KHz PWM frequency I can't see that it's a practical problem. Why would you ever want to run at 60Hz?

For what it's worth I'd describe MicroPython on a Pyboard as a very mature platform with four or five years development behind it. On new hardware such as ESP32 it may have a few rough edges.

[pmulvey]

Just tried using 4KHz PWM frequency and the flickering is just more frequent.

[pythoncoder]

Given that I can't replicate this, there must be a difference between our setups. I'm connected to the reference board (Adafruit Feather Huzzah) via a USB cable and using rshell. I see no evidence of flicker with the code I posted above (with 60 replaced by 4000 for a 4KHz rate).

[pmulvey]

Just revisited the strange PWM behaviour. I have modified the code to increment the duty cycle in steps of 3 rather than 1. All smooth now!

Code: Select all

def RGBRamp(RGBPin):
    pwm = PWM(Pin(RGBPin))
    pwm.freq(1000)
    for i in range(1022, 1, -3):
        pwm.duty(i)
        sleep_us(1000)
        
    for i in range(1, 1022,3):
        pwm.duty(i)
        sleep_us(1000)

[jimmo]

If you have a PWM frequency of 1000 Hz (i.e. a period of 1ms) and you change the duty cycle approximately every 1ms, you're going to see all sorts of issues as it never really gets to run a proper cycle.

For smooth animation you definitely don't need to be doing 1ms updates for smooth animation. Changing it in much larger intervals and sleeping for 20-30ms would be still pretty smooth.