Dimmer - LUT accuracy

[florentbr]

I had a quick look at your LUT.
They are close to the ideal model:

One thing I don't like is that the duty level is only 8 bits.
It's a 7.8 watts step/error for a 2000 watts heating element.
The step would be negligible with a 12bits resolution or over.

The code I use to convert the duty to a phase delay:

/*
    AC phase delay table (sine square distribution).
    power_ratio = sin(2 * pi * delay_ratio) / (2 * pi) - delay_ratio + 1
    index 0  ≈   0% power ≈   5% phase angle ≈ 95% phase delay
    index 39 ≈  50% power ≈  50% phase angle ≈ 50% phase delay
    index 79 ≈ 100% power ≈  95% phase angle ≈  5% phase delay
*/

#define TRIAC_RESOLUTION   ( 12 )  // bits
#define TRIAC_MAX          ( (1 << TRIAC_RESOLUTION) - 1 )

#define TABLE_PHASE_LEN    ( 80 )
#define TABLE_PHASE_SCALE  ( (TABLE_PHASE_LEN - 1) * (1UL << (16 - TRIAC_RESOLUTION)) )


static const uint16_t TABLE_PHASE_DELAY[TABLE_PHASE_LEN] {
    0xefea, 0xdfd4, 0xd735, 0xd10d, 0xcc12, 0xc7cc, 0xc403, 0xc094,
    0xbd6a, 0xba78, 0xb7b2, 0xb512, 0xb291, 0xb02b, 0xaddc, 0xaba2,
    0xa97a, 0xa762, 0xa557, 0xa35a, 0xa167, 0x9f7f, 0x9da0, 0x9bc9,
    0x99fa, 0x9831, 0x966e, 0x94b1, 0x92f9, 0x9145, 0x8f95, 0x8de8,
    0x8c3e, 0x8a97, 0x88f2, 0x8750, 0x85ae, 0x840e, 0x826e, 0x80cf,
    0x7f31, 0x7d92, 0x7bf2, 0x7a52, 0x78b0, 0x770e, 0x7569, 0x73c2,
    0x7218, 0x706b, 0x6ebb, 0x6d07, 0x6b4f, 0x6992, 0x67cf, 0x6606,
    0x6437, 0x6260, 0x6081, 0x5e99, 0x5ca6, 0x5aa9, 0x589e, 0x5686,
    0x545e, 0x5224, 0x4fd5, 0x4d6f, 0x4aee, 0x484e, 0x4588, 0x4296,
    0x3f6c, 0x3bfd, 0x3834, 0x33ee, 0x2ef3, 0x28cb, 0x202c, 0x1016};


static uint32_t lookup_phase_delay(uint32_t duty12, uint16_t period)
{
    uint32_t slot  = duty12 * TABLE_PHASE_SCALE + (TABLE_PHASE_SCALE >> 1);
    uint16_t index = slot >> 16;
    uint32_t a     = TABLE_PHASE_DELAY[index]
    uint32_t b     = TABLE_PHASE_DELAY[index + 1];
    uint32_t delay = a - (((a - b) * (slot & 0xffff)) >> 16);  // interpolate a b

    return (delay * period) >> 16;  // scale to period
}

The 0% and 100% needs to be handled separately.
The lookup is interpolated without FPU.
The error is under 0.001 compared to the ideal model.

[mathieucarbou]

Wow thanks a lot!!

About that (8-bit vs 0-100%) - I first started to use 255 bits and a slider in the app going from 0-255. The problem is that sometimes moving from a position to another was creating some flickering: I do not explain that but using "baby steps" was not creating a smooth brightness (I am saying brightness because I am testing with light bulbs) compared to using 0-100% and consequently have bigger steps. I tested both with the Robodyn (BTA16 and a Random SSR 60DA) and in both case I have sone little flickering at some position I do not have otherwise. I didn't research further as to why. I need to fix first this 550us delay that must be added to correct match the triac firing time with the zero cross.

The MycilaDimmerV3_100_LUT.h is what I am using currently, the MycilaDimmerV3_255_LUT.h is what I would like to use but has some little flickering for some positions, or steps where nothing change and then a sudden change.

Please note that these V3 algorithm are the ones used in the Dimmable Light lib where the discussion started ;-)

[mathieucarbou]

When you say:

One thing I don't like is that the duty level is only 8 bits.
It's a 7.8 watts step/error for a 2000 watts heating element.
The step would be negligible with a 12bits resolution or over.

Yes I agree.
I would need to update the code to also compute a more correct delay depending in the input value, like you do.

[mathieucarbou]

Adding as references discussions related to this:

1. How to tweak the brightness => delay (linearised or not) fabianoriccardi/dimmable-light#58
2. Publish energy to MQTT #18

[florentbr]

About that (8-bit vs 0-100%) - I first started to use 255 bits and a slider in the app going from 0-255. The problem is that sometimes moving from a position to another was creating some flickering: I do not explain that but using "baby steps" was not creating a smooth brightness (I am saying brightness because I am testing with light bulbs) compared to using 0-100% and consequently have bigger steps.

I don't understand your 8-bit vs 0-100%. Are you maybe talking about discrete values 0-255 (integer) vs continuous values 0.0-1.0 (float) ?

You are probably aware, but the perceived brightness is not linear like the power.
It requires a Gamma correction, something like duty ^ 1.7 or duty ^ 0.7.

If it's related to the slider then maybe the requests are piling-up and are delaying the interrupts handling the dimming. Make sure that the slider's events are throttled by a timer to limit the requests. Use your scope in persistence mode
and toggle a pin in the ZC interrupt to see how delayed and stable it is from the actual ZC when the slider is moved.

I opened an issue with the library about the usage of IRAM:
fabianoriccardi/dimmable-light#44

in both case I have sone little flickering at some position I do not have otherwise.

Flickering can have multiple causes:

• Dimming relying on interrupts not served at the right time.
• ZC not properly calibrated.
• ZC sync happening on the falling edge instead of the rising edge due to a non square signal (opto-isolator slew rate).
• ZC connected to a floating input (input should be pulled-up internally).
• Not enough current or voltage driving the SSR/MOC (ESP32 outputs 3.3v 5mA max by default).
• Pulse rise/fall time updated during the dimming and not at the zero crossing.

I need to fix first this 550us delay that must be added to correct match the triac firing time with the zero cross.

It should be as simple as adding 550 to each value in delay50HzLUT, but I think the underling lib is clipping the beginning and the end of the period.

fabianoriccardi/dimmable-light#21

[mathieucarbou]

Thanks for the tips! I will have look at all that soon.

I was talking about the discrete values used in my case as indexes in the table. I need to fix my algorithm to account for all that, plus do an interpolation between each indexes also.

Thanks for the pointers I will have a look at these issues. I saw the one with the IRAM already.

Like you said, a lot of things to verify ;-)