That looks to be correct.
But one place where I think you might have a problem is:
You realise that each set of hardware will have a different “m” and a different “c”. You can do nothing about the slope - it depends on component tolerances that you have no control over. All you can do is spend a lot of money on very tightly specified parts. Plus, there is no guarantee that these will not change over time.
There’s also no guarantee that your offset value will not change over time, but you can do something about that.
There are many methods to remove the offset (the “2029”):
- Measure it with another analog input, and subtract.
- Use a high-pass filter to allow the 50 Hz and all harmonics through but remove the d.c.
- Use a low-pass filter to obtain the d.c. only component, then subtract that number.
- As well as accumulating the squares to get the rms, accumulate the raw numbers also, then at the end of the averaging period, use the maths to remove the average (= d.c.) component.
We don’t use (1) because we don’t have a spare analog input. If you have one, you could use it.
We used to use (2) in emonLib, but it took a long time to settle and gave false readings while it was doing so, and it couldn’t be pre-set to start near to the final value.
We use (3) in emonLib, because it can be initialised to the nominal value, then it corrects itself quickly.
We use (4) in emonLibCM, but subtract the nominal d.c, first, just to keep the numbers smaller.
There’s no great difference between (3) and (4) in the accuracy of the result, but (4) runs a lot faster in software because less maths is done per sample, and then only involves integer multiplication and addition. The time-consuming floating-point division etc needed by the filter is not required, and what remains is only done once per reporting interval.