phase shift correction

[florentbr]

Something is not right with the phase correction and/or calibration process.

In Mk2_3phase_RFdatalog_temp, the function processCurrentRawSample corrects the phase difference with an IIR EMA filter by delaying the Current channel. Alpha is set to alpha=0.002, but by my count, it should be at least 0.85 to obtain a 1/6 delay when sampling 6 channels. lpf_gain is zero, so the correction is disabled by default.

Then, looking at cal_CTx_v_meter the function processCurrentRawSample is no longer delaying the current, but the voltage and the delay is now applied with a FIR 2-Tap filter. i_phaseCal is set to max, so the phase correction is disabled here too. With 6 channels, i_phaseCal should be at least 256/6 .

There's f_phaseCal but it's not used.

I don't see how the metering can be accurate with no phase correction.
A sample is 104us, so there's at least a 104us phase delay between voltage and current.

[FredM67]

Hi Florent,
Je vais répondre en français ;-)
Il s'agit de corriger la réponse des pinces. Faster Control Algorithm Updated (March 2021).
À la base, cela a été fait pour les monophasés.
Pour le tri, j'ai fait quelques essais (ca prend un temps fou), normalement c'est désactivé, mais il se peut très bien que, suite à une erreur de "merge" et/ou erreur d’inattention, cette correction soit malheureusement active.

Alors oui, il peut sembler étonnant que les calculs soient corrects (en tout cas suffisant pour les besoins de routage) sans même tenir compte du décalage de 104 us entre tension et courant.
Pour le coup, j'ai fait des tests plus poussés sous Windows, en prenant des sinusoïdes parfaites, même échantillonnage, ...
J'ai alors comparé les valeurs P = U x I théoriques (comme si on mesure exactement en même temps U et I), puis avec ce décalage de 104 us sans correction puis avec plusieurs types de correction en approximant les fonctions sin/cos au 1er degré, au 2eme degré (impossible de faire des vrais calculs flottants, ca prendrait bcp trop de temps).
Et bien curieusement, au final, les calculs sans correction étaient presque les meilleurs ! Le très très faible gain ne justifiait pas le temps perdu en calcul.
En gros, ce qu'on perd d'un côté (partie ascendante de la sinusoïde) est presque récupérer de l'autre côté (partie descendante).

Si tu t'y connais dans ce domaine, je suis preneur :D

Par contre, une chose critique est à garder à l'esprit: un atmega328, c'est très pourri, c'est lent. Les calculs en nb entier sont à privilégier au maximum. Chaque calcul se rapportant à une mesure ou une paire de mesure et meme pour chaque fin de cycle les calculs globaux DOIVENT tenir dans 104 us au grand maximum !
C'est parfois un peu hardcore !

Fred

[florentbr]

normalement c'est désactivé,

La fonction calcule le filtre mais ne l'applique pas au résultat.
J'ai vu plusieurs instructions pour flottant dans l'ASM (flag "-O2").

au final, les calculs sans correction étaient presque les meilleurs

Pour différentes simulations de filtres avec un délais de 104us j’obtiens:
Sine, amplitude RMS error: IIR_EMA:0.15% FIR_2Tap:0.08% IIR_Allpass:0.00%
Square, amplitude RMS error: IIR_EMA:0.93% FIR_2Tap:0.75% IIR_Allpass:0.00%

Un filtre FIR 2-Tap à interpolation n'a que très peu d'impact sur l'amplitude s'il est appliqué à une sinusoïde.
Vu que le courant est souvent distordu, il est donc préférable d'appliquer le filtre seulement sur la tension.
De plus, l’atténuation qui est négligeable est corrigée par la calibration finale.

En gros, ce qu'on perd d'un côté (partie ascendante de la sinusoïde) est presque récupérer de l'autre côté (partie descendante).

Effectivement, l'erreur est négligeable avec une sinusoïde parfaite (0.05%):

power_error = 1 - cos(104 / 10000 * pi) # 0.0005

Par contre c'est 2% d'erreur sur la puissance pour un gradateur à 50%.

L'impact devrait être réduit si la régulation ne fait que du saute mouton sur des périodes 50Hz.
Par contre pour du découpage de phase, c'est probablement non négligeable.

[florentbr]

If you're interested in optimizing the ADC interrupt, here are a few suggestions:

1 - Use a Circular Linked List for the channels instead of a switch.

It should significantly reduce inlining, branching, and processing time, provided the pointer is not constantly reloaded due to a lack of register (register pressure).

#define _ADMUX  (1 << REFS1 | 1 << REFS0 | 1 << ADLAR)

struct adc_ctx_t {
    struct adc_ctx_t* next;
    uint8_t index;
    uint8_t admux;
    int32_t macc_segment;
    ...
};

static adc_ctx_t _channels[6] = {
    { .next = _channels + 1, .index = 0, .admux = _ADMUX | 2 },
    { .next = _channels + 2, .index = 1, .admux = _ADMUX | 3 },
    { .next = _channels + 3, .index = 2, .admux = _ADMUX | 4 },
    { .next = _channels + 4, .index = 3, .admux = _ADMUX | 5 },
    { .next = _channels + 5, .index = 4, .admux = _ADMUX | 0 },
    { .next = _channels + 0, .index = 5, .admux = _ADMUX | 1 }
};
static adc_ctx_t* _ctx = &_channels[0];

ISR(ADC_vect)
{
    uint16_t adc_raw = ADC;

    ADMUX = _ctx->admux;

    if ((ctx->index & 1) == 0) { // even=voltage, odd=current
        // process voltage channel
    } else {
        // process current channel
    }

    _ctx = _ctx->next;
}

2 - Use left-aligned ADC conversion (ADLAR=1).

When left-aligned, the ADC conversion becomes a fraction, which greatly simplifies the math.

Updating the bias with a low-pass filter (EMA 1/16-bit) requires just a single addition once you have the unbiased value:

static uint32_t bias_16q16 = ((1UL << 15) - 1) << 16;

uint16_t adc_raw = ADC;  // left aligned

int16_t value = adc_raw - (uint16_t)(bias_16q16 >> 16);

bias_16q16 += value;

_ctx->macc_segment += ((int32_t)value * value) >> 8;  //  V*V or I*I, drop lower 8-bits (result is 20-bits left aligned)

For the squared accumulation, shifting by 8 bits incurs no performance penalty, unlike misaligned multi-bit shifts which are more costly.

For filtering, it provides a 6-bit fixed-point (Q10.6) at zero cost:

static int16_t x_prev = 0;
const uint8_t factor = 256 * 1/6;

int16_t y = x + (int16_t)(((__int24)(x_prev - x) * factor) >> 8);
x_prev = x;

3 - Remove floating point math

The interrupt currently makes multiple calls to libgcc floating-point functions. These are expensive and can be replaced with integer math, reducing the processing time by an order of magnitude.

    avr-objdump -d -S -l .pio/build/basic/firmware.elf > firmware.lst

The ADC interrupt is __vector_21

     a06:	0e 94 84 10 	call	0x2108	; 0x2108 <__mulsf3>
     a1a:	0e 94 b4 0e 	call	0x1d68	; 0x1d68 <__addsf3>
     a42:	0e 94 7f 10 	call	0x20fe	; 0x20fe <__gesf2>
     ab2:	0e 94 b3 0e 	call	0x1d66	; 0x1d66 <__subsf3>
     e36:	0e 94 20 0f 	call	0x1e40	; 0x1e40 <__cmpsf2>
     eea:	0e 94 42 0e 	call	0x1c84	; 0x1c84 <__mulsi3>
     77a:	0e 94 cf 0f 	call	0x1f9e	; 0x1f9e <__floatsisf>
     7a2:	0e 94 97 0f 	call	0x1f2e	; 0x1f2e <__fixsfsi>

These are from:

• The energy bucket being handled as a floating-point value.
• The filter compensating for the behavior of the current transformer (CTx) as a high-pass filter (HPF).

Previously, I assumed the low-pass filter (LPF) was just used to align the voltage. However, based on the comments, it's meant to compensate for the CT behavior. I don’t recall observing this effect. Perhaps it's due to a weak bias resistor or lack of a hardware RC filter.

Do you have any insights on this behavior?

4 - Use Assembly on the critical path.

GCC does not optimize or inline 16/32-bit multiplications.

I use ASM to square the values and to apply filtering.

// Multiply accumulate two channels, U*U for RMS voltage, U*I for active power.
// Discard the lowest byte since the result is 20bits left aligned.
ctx->macc_segment += mul16x16_ms24(voltage, value);  // accumulator += (voltage * value + 0x80) >> 8;

// FIR filter, 2-Tap interpolate:
// y[n] = x[n] + (x[n-1] - x[n]) * factor), factor = sampling_period_ratio
int16_t voltage_delayed = voltage;  // x[n]
voltage_delayed += mul16_q8(ctx->voltage - voltage, ctx->delay_factor);  // += (x[n-1] - x[n]) * factor
ctx->voltage = voltage;  // x[n-1] = x[n]

#define OPTIMIZED_ASM  1

/**
 * Multiply two 16-bits and return the most significant 24-bits.
 * Rounding to the nearest integer.
 * 	I24 = (I16 * I16 + 0x80) >> 8
 */
static inline __int24 mul16x16_ms24(int16_t a, int16_t b)
{
	#if OPTIMIZED_ASM == 0
		return ((int32_t)a * b + 0x80) >> 8;
	#else
		__int24 result;
		asm volatile (  // 21 cycles
            // a_hi * b_lo
            "mulsu %B[a], %A[b]      \n\t"
            "movw  %A[res], r0       \n\t"
            "sbc   %C[res], %C[res]  \n\t"  // -1 if negative result (carry flag)
            // b_hi * a_lo
            "mulsu %B[b], %A[a]      \n\t"
            "sbc   %C[res], r1       \n\t"  // -1 if negative result (carry flag)
            "add   %A[res], r0       \n\t"
            "adc   %B[res], r1       \n\t"
            "adc   %C[res], r1       \n\t"  // add carry + remove r1 added by sbc
            // a_hi * b_hi
            "muls  %B[a], %B[b]      \n\t"
            "add   %B[res], r0       \n\t"
            "adc   %C[res], r1       \n\t"
            // a_lo * b_lo
            "mul   %A[a], %A[b]      \n\t"
            "lsl   r0                \n\t"
            "adc   %A[res], r1       \n\t"
            "clr   r1                \n\t"
            "adc   %B[res], r1       \n\t"
            "adc   %C[res], r1       \n\t"
            : [res] "=&r" (result)
            : [a] "a" (a), [b] "a" (b)
		);
		return result;
	#endif
}

/**
 * Multiply a 16-bits signed with an 8-bits unsigned fraction.
 * Rounding to the nearest integer.
 *  I16 = (I16 * Q8 + 0x80) >> 8
 */
static inline int16_t mul16_q8(int16_t value, uint8_t fraction)
{
	#if OPTIMIZED_ASM == 0
		return ((int32_t)value * fraction + 0x80) >> 8;
	#else
		int16_t result;
		asm volatile (  // 9 cycles
            "mulsu %B[val], %[frac]  \n\t"
            "movw  %A[ret], r0       \n\t"
            "mul   %A[val], %[frac]  \n\t"
            "lsl   r0                \n\t"
            "adc   %A[ret], r1       \n\t"
            "clr   r1                \n\t"
            "adc   %B[ret], r1       \n\t"
            : [ret] "=&r" (result)
            : [val] "a" (value), [frac] "a" (fraction)
		);
		return result;
	#endif
}

[FredM67]

Hi Florent,

A huge thank you for your researches and suggestions.
Since the system is running properly and all the intermediate work (calculations, ...) fit inside the 104us from an ADC conversion, I didn't try to optimize further the code.
But well, I'll implement your suggestions, as soon as I find some free time !

If you're interested in optimizing the ADC interrupt, here are a few suggestions:

1 - Use a Circular Linked List for the channels instead of a switch.

It should significantly reduce inlining, branching, and processing time, provided the pointer is not constantly reloaded due to a lack of register (register pressure).

#define _ADMUX (1 << REFS1 | 1 << REFS0 | 1 << ADLAR)

struct adc_ctx_t {
struct adc_ctx_t* next;
uint8_t index;
uint8_t admux;
int32_t macc_segment;
...
};

static adc_ctx_t _channels[6] = {
{ .next = _channels + 1, .index = 0, .admux = _ADMUX | 2 },
{ .next = _channels + 2, .index = 1, .admux = _ADMUX | 3 },
{ .next = _channels + 3, .index = 2, .admux = _ADMUX | 4 },
{ .next = _channels + 4, .index = 3, .admux = _ADMUX | 5 },
{ .next = _channels + 5, .index = 4, .admux = _ADMUX | 0 },
{ .next = _channels + 0, .index = 5, .admux = _ADMUX | 1 }
};
static adc_ctx_t* _ctx = &_channels[0];
ISR(ADC_vect)
{
uint16_t adc_raw = ADC;

ADMUX = _ctx->admux;

if ((ctx->index & 1) == 0) { // even=voltage, odd=current
    // process voltage channel
} else {
    // process current channel
}

_ctx = _ctx->next;

}

Good point... there's something to gain, even it's not huge.

2 - Use left-aligned ADC conversion (ADLAR=1).

When left-aligned, the ADC conversion becomes a fraction, which greatly simplifies the math.

Updating the bias with a low-pass filter (EMA 1/16-bit) requires just a single addition once you have the unbiased value:

static uint32_t bias_16q16 = ((1UL << 15) - 1) << 16;

uint16_t adc_raw = ADC; // left aligned

int16_t value = adc_raw - (uint16_t)(bias_16q16 >> 16);

bias_16q16 += value;

_ctx->macc_segment += ((int32_t)value * value) >> 8; // VV or II, drop lower 8-bits (result is 20-bits left aligned)
For the squared accumulation, shifting by 8 bits incurs no performance penalty, unlike misaligned multi-bit shifts which are more costly.

For filtering, it provides a 6-bit fixed-point (Q10.6) at zero cost:

static int16_t x_prev = 0;
const uint8_t factor = 256 * 1/6;

int16_t y = x + (int16_t)(((__int24)(x_prev - x) * factor) >> 8);
x_prev = x;

Great point. I didn't think about that !

3 - Remove floating point math

The interrupt currently makes multiple calls to libgcc floating-point functions. These are expensive and can be replaced with integer math, reducing the processing time by an order of magnitude.

avr-objdump -d -S -l .pio/build/basic/firmware.elf > firmware.lst

The ADC interrupt is __vector_21

     a06:	0e 94 84 10 	call	0x2108	; 0x2108 <__mulsf3>
     a1a:	0e 94 b4 0e 	call	0x1d68	; 0x1d68 <__addsf3>
     a42:	0e 94 7f 10 	call	0x20fe	; 0x20fe <__gesf2>
     ab2:	0e 94 b3 0e 	call	0x1d66	; 0x1d66 <__subsf3>
     e36:	0e 94 20 0f 	call	0x1e40	; 0x1e40 <__cmpsf2>
     eea:	0e 94 42 0e 	call	0x1c84	; 0x1c84 <__mulsi3>
     77a:	0e 94 cf 0f 	call	0x1f9e	; 0x1f9e <__floatsisf>
     7a2:	0e 94 97 0f 	call	0x1f2e	; 0x1f2e <__fixsfsi>

These are from:

• The energy bucket being handled as a floating-point value.
• The filter compensating for the behavior of the current transformer (CTx) as a high-pass filter (HPF).

Previously, I assumed the low-pass filter (LPF) was just used to align the voltage. However, based on the comments, it's meant to compensate for the CT behavior. I don’t recall observing this effect. Perhaps it's due to a weak bias resistor or lack of a hardware RC filter.

Do you have any insights on this behavior?

Well, as mentioned, there's no HW RC filter ! that's the reason of this SW filter.
For the 3-phase version, this filter does not really seem to matter, but it was somehow necessary for the single-phase version, mainly because of the Linky. In the past, it worked fine with the old white meters.
In the 3-phase case, since we've to sum up all 3 phase, and each phase must be calibrated, we need some additional math at the end of each cycle. I took a like more in details, I think, we could replace these calculation with some Q16.16 integer math without loosing anything. So the "deal" would be to use a uint16_t powerCal_fixed calculated from f_powerCal * 65536.0F + 0.5F.
This can be done by the compiler, or I can simply get rid of the f_powerCal values and replace it directly with powerCal_fixed. I simply need to update to doc how to calculate these values from the log. So for 0.051562F, I'd have 3379 instead, and then

// Replace this:
f_energyInBucket_main += (l_sumP[phase] / n_samplesDuringThisMainsCycle[phase]) * f_powerCal[phase];

// With this pure int32_t calculation:
int32_t avgPower = l_sumP[phase] / n_samplesDuringThisMainsCycle[phase];
int32_t energyContrib = (avgPower * powerCal_fixed[phase]) >> 16;
energyInBucket_fixed += energyContrib;  // Add to fixed-point bucket

Correct?

4 - Use Assembly on the critical path.

GCC does not optimize or inline 16/32-bit multiplications.

I use ASM to square the values and to apply filtering.

// Multiply accumulate two channels, UU for RMS voltage, UI for active power.
// Discard the lowest byte since the result is 20bits left aligned.
ctx->macc_segment += mul16x16_ms24(voltage, value); // accumulator += (voltage * value + 0x80) >> 8;

// FIR filter, 2-Tap interpolate:
// y[n] = x[n] + (x[n-1] - x[n]) * factor), factor = sampling_period_ratio
int16_t voltage_delayed = voltage; // x[n]
voltage_delayed += mul16_q8(ctx->voltage - voltage, ctx->delay_factor); // += (x[n-1] - x[n]) * factor
ctx->voltage = voltage; // x[n-1] = x[n]
#define OPTIMIZED_ASM 1

/**

• Multiply two 16-bits and return the most significant 24-bits.
• Rounding to the nearest integer.
• I24 = (I16 * I16 + 0x80) >> 8
  */
  static inline __int24 mul16x16_ms24(int16_t a, int16_t b)
  {
  #if OPTIMIZED_ASM == 0
  return ((int32_t)a * b + 0x80) >> 8;
  #else
  __int24 result;
  asm volatile ( // 21 cycles
  // a_hi * b_lo
  "mulsu %B[a], %A[b] \n\t"
  "movw %A[res], r0 \n\t"
  "sbc %C[res], %C[res] \n\t" // -1 if negative result (carry flag)
  // b_hi * a_lo
  "mulsu %B[b], %A[a] \n\t"
  "sbc %C[res], r1 \n\t" // -1 if negative result (carry flag)
  "add %A[res], r0 \n\t"
  "adc %B[res], r1 \n\t"
  "adc %C[res], r1 \n\t" // add carry + remove r1 added by sbc
  // a_hi * b_hi
  "muls %B[a], %B[b] \n\t"
  "add %B[res], r0 \n\t"
  "adc %C[res], r1 \n\t"
  // a_lo * b_lo
  "mul %A[a], %A[b] \n\t"
  "lsl r0 \n\t"
  "adc %A[res], r1 \n\t"
  "clr r1 \n\t"
  "adc %B[res], r1 \n\t"
  "adc %C[res], r1 \n\t"
  : [res] "=&r" (result)
  : [a] "a" (a), [b] "a" (b)
  );
  return result;
  #endif
  }

/**

• Multiply a 16-bits signed with an 8-bits unsigned fraction.
• Rounding to the nearest integer.
• I16 = (I16 * Q8 + 0x80) >> 8
  */
  static inline int16_t mul16_q8(int16_t value, uint8_t fraction)
  {
  #if OPTIMIZED_ASM == 0
  return ((int32_t)value * fraction + 0x80) >> 8;
  #else
  int16_t result;
  asm volatile ( // 9 cycles
  "mulsu %B[val], %[frac] \n\t"
  "movw %A[ret], r0 \n\t"
  "mul %A[val], %[frac] \n\t"
  "lsl r0 \n\t"
  "adc %A[ret], r1 \n\t"
  "clr r1 \n\t"
  "adc %B[ret], r1 \n\t"
  : [ret] "=&r" (result)
  : [val] "a" (value), [frac] "a" (fraction)
  );
  return result;
  #endif
  }

Great point too ! My knowledges in ASM are far from enough to implement such things..... Thx for the advice.

Fred

[florentbr]

Well, as mentioned, there's no HW RC filter ! that's the reason of this SW filter.

Just to clarify in case we're talking about different things: this isn't about filtering noise or delaying samples. It's about compensating for the current transformer (CT) behaving like a high-pass filter between full ON and flat OFF states.

See "Faster Control Algorithm Updated (March 2021)"
https://openenergymonitor.org/mk2pvrouter/tech-notes.html

I'm interested in the theory behind this behavior, whether it's due to a design limitation or if it's inherent to the CT.

I think, we could replace these calculation with some Q16.16 integer math without loosing anything.

I'd suggest using a 16-bit fractional format (Q16), since the calibration factor is less than 1.

I32 = I32 * Q16 => I32 = (I32 * U16 + (1U<<15)) >> 16
The + (1U << 15) is the rounding to the nearest integer.

A drop-in replacement would be:

powerCal[phase] = (uint16_t)(0.051562 * (1L<<16));

energyInBucket_main += mul32_q16(l_sumP[phase] / n_samplesDuringThisMainsCycle[phase], powerCal[phase]);

/**
 * Multiply a 32-bits with a 16-bits unsigned fraction (Q16).
 * Rounding to nearest integer
 * I32 = round(I32 * U16 / (2^16))
 */
int32_t mul32_q16(int32_t value, uint16_t fraction)
{
    // int32_t result = ((int64_t)value * fraction + (1U<<15)) >> 16; 
    int32_t result = (int32_t)(value >> 16) * fraction;
    result += ((uint32_t)(value & 0xffff) * fraction + (1U<<15)) >> 16;
    return result;
}

or cheaper with assembly :
https://github.com/feilipu/avrfreertos/blob/master/freeRTOS11xx/include/mult32x16.h

It won't work with (avgPower * powerCal_fixed[phase]) >> 16;, the multiplication is truncated to 32 bits.
You could cast to 64 bits first with (int64_t)avgPower, but two multiply is likely cheaper.

Regarding resolution, you'll lose a bit compared to a float (23 bits). For an exact match, you'd need a Q24. However, the difference is probably insignificant overall.

I would also remove the division by n_samplesDuringThisMainsCycle[phase]. It only makes sense when calculating average power, not when accumulating energy. However, since it's tied to the averaging and limit checks, it might require some effort.

[FredM67]

Well, as mentioned, there's no HW RC filter ! that's the reason of this SW filter.

Just to clarify in case we're talking about different things: this isn't about filtering noise or delaying samples. It's about compensating for the current transformer (CT) behaving like a high-pass filter between full ON and flat OFF states.

See "Faster Control Algorithm Updated (March 2021)" https://openenergymonitor.org/mk2pvrouter/tech-notes.html

I'm interested in the theory behind this behavior, whether it's due to a design limitation or if it's inherent to the CT.

Yes, that's exactly about that. Maybe, it could be solved through some additional hardware, but well, I'm not an electronic specialist !

I think, we could replace these calculation with some Q16.16 integer math without loosing anything.

I'd suggest using a 16-bit fractional format (Q16), since the calibration factor is less than 1.

I32 = I32 * Q16 => I32 = (I32 * U16 + (1U<<15)) >> 16 The + (1U << 15) is the rounding to the nearest integer.

A drop-in replacement would be:

powerCal[phase] = (uint16_t)(0.051562 * (1L<<16));

energyInBucket_main += mul32_q16(l_sumP[phase] / n_samplesDuringThisMainsCycle[phase], powerCal[phase]);
/**

• Multiply a 32-bits with a 16-bits unsigned fraction (Q16).
• Rounding to nearest integer
• I32 = round(I32 * U16 / (2^16))
  */
  int32_t mul32_q16(int32_t value, uint16_t fraction)
  {
  // int32_t result = ((int64_t)value * fraction + (1U<<15)) >> 16;
  int32_t result = (int32_t)(value >> 16) * fraction;
  result += ((uint32_t)(value & 0xffff) * fraction + (1U<<15)) >> 16;
  return result;
  }
  or cheaper with assembly : https://github.com/feilipu/avrfreertos/blob/master/freeRTOS11xx/include/mult32x16.h

It won't work with (avgPower * powerCal_fixed[phase]) >> 16;, the multiplication is truncated to 32 bits. You could cast to 64 bits first with (int64_t)avgPower, but two multiply is likely cheaper.

Regarding resolution, you'll lose a bit compared to a float (23 bits). For an exact match, you'd need a Q24. However, the difference is probably insignificant overall.

I would also remove the division by n_samplesDuringThisMainsCycle[phase]. It only makes sense when calculating average power, not when accumulating energy. However, since it's tied to the averaging and limit checks, it might require some effort.

After a couple of tries yesterday, it turned out, there's no way to go full on integer math. The replacement of the float multiplications with integer math does not seem to gain so much, and it'll add complexity.
Maybe I'm wrong.
As of now, the division by n_samples is needed for the diverter itself, and for the serial output. After some heavy refactoring of this part, it might be possible to get rid of it. But at the end, we'll need it anyway for the serial/telemetry output.
As I mentioned, all these calculations done on each step fit each in the 104us window available during each ADC conversion.

The one thing I'd like to implement is the suggestions 1 and 2. That looks cool. I've created a branch for that, and added you as contributor on the repo. Feel free to implement it if you want to ;-)

[florentbr]

After a couple of tries yesterday, it turned out, there's no way to go full on integer math. The replacement of the float multiplications with integer math does not seem to gain so much, and it'll add complexity.
Maybe I'm wrong.

The cost of the float multiply is likely insignificant compared to the division.
The advantage is that you don't have to deal with saturation.
On the other hand, a 32-bits * float will truncate one byte of data.

Benchmark on an atmega328p (-Os):

# 16-bits
  0.44 us | I16 = I16
  0.82 us | I16 = I16 + I16
  0.88 us | U8 = (I16 == I16)
  0.88 us | U8 = I16 < I16
  1.07 us | I8 = ((I16 < 0) - (I16 < 0))
  1.07 us | I8 = ((I16 >> 15) - (I16 >> 15))
  1.32 us | I16 = I16 * I16
  3.21 us | I16 = ((32)I16 * U16) >> 16
  3.21 us | I16 = ((32)I16 * U8) >> 8
 13.14 us | I16 = I16 / U16
 14.15 us | I16 = I16 / 999
 14.21 us | I16 = I16 / 99
 14.34 us | I16 = I16 / U8

# 32-bits
  0.94 us | I32 = I32
  1.26 us | I16 = I32 >> 16
  1.32 us | I32 = I32 >> 8 
  1.51 us | U8 = (I32 == I32)
  1.70 us | I32 += I16
  1.70 us | I32 = I32 + I16
  1.70 us | I32 = I32 + I32
  1.89 us | I8 = ((I32 < 0) - (I32 < 0))
  1.89 us | I8 = ((I32 >> 31) - (I32 >> 31))
  3.52 us | I32 = (32)I16 * I16
  4.27 us | I32 += (32)I16 * I16
  4.27 us | I32 = I32 * I16
  4.65 us | I32 += ((32)I16 * I16) >> 8
  6.04 us | I32 = I32 * I32
  6.35 us | I32 += ((32)(I16<<3)*(I16<<3))
  6.92 us | I32 += ((32)I16 * I16)<<6
 16.28 us | I32 = ((64)I32 * U16) >> 16
 39.42 us | I16 = I32 / U16
 40.49 us | I32 = I32 / U8 

# float 32-bits
  1.76 us | I8 = ((F32 >> 31) - (F32 >> 31))
  3.21 us | F32 = I32
  4.21 us | U8 = (F32 < F32)
  4.21 us | U8 = (F32 == F32)
  5.22 us | I32 = F32
  6.98 us | F32 = F32 + F32
  7.98 us | I8 = ((F32 < 0) - (F32 < 0))
  9.62 us | F32 = F32 * F32
 12.39 us | F32 = I32 * F32
 17.29 us | I32 = I32 * F32
 32.06 us | F32 = F32 / F32

# Assembly
  1.13 us | ASM: I16 = round(I16 * Q8)
  2.14 us | ASM: I32 = I16 * I16
  2.39 us | ASM: I16 = round(I16 * Q16)
  2.45 us | ASM: I24 = (I16 * I16 + 0x80) >> 8
  4.97 us | ASM: I32 = round(I32 * Q16)
  5.28 us | ASM: I32 = round(I24 * Q24)
  6.92 us | ASM: I32 = round(I32 * Q24)

As of now, the division by n_samples is needed for the diverter itself, and for the serial output. After some heavy refactoring of this part, it might be possible to get rid of it. But at the end, we'll need it anyway for the serial/telemetry output.
As I mentioned, all these calculations done on each step fit each in the 104us window available during each ADC conversion.

I agree, if it's functioning well, there's no reason to alter it.
I chose a different approach because I needed those valuable cycles for other interrupts.

[florentbr]

I took a quick look at the original MK2 implementation and noticed that the current was read before the voltage. In this project, however, the current is read afterward. This likely explains why enabling the CT filter has a negative effect. It increases the delay rather than reducing it.

[FredM67]

I took a quick look at the original MK2 implementation and noticed that the current was read before the voltage. In this project, however, the current is read afterward. This likely explains why enabling the CT filter has a negative effect. It increases the delay rather than reducing it.

Well, that could be the reason.
I did invert the measurement, so I can proceed with the math that is exclusively related to the voltage, then proceed with voltage and current.
If current is measured first, I cannot do anything until I've the voltage !

But as I mentioned previously, I did some verification with theoretical sinuses. The goal was to see if it's a good idea to interpolate the sinus using some first, second or even 3rd degree approx... I came out, that the calculation without any post-treatment taking into account the 104us delay was somehow the best one.

If you want, I can search again for the prog I made to check that.

[florentbr]

If you want, I can search again for the prog I made to check that.

It likely won't help, as the filter appears to have been designed to address a real-world behavior rather than a simulated one.