Thanks again Robert Wall. In your previous post you said:

**“** So I would suggest the integer that is closest

to n/50 × 5588 is a good number - *n* being the number of mains cycles. You get 93.133 samples per cycle, so 1397 samples will almost exactly fit 15 cycles of your 60 Hz mains, giving you a sample of length of ¼ s. **”**

Did you mean n/60 x 5580? Because 15/60 x 5588 = 1397 samples?

Leading me to believe that I should replace the 1480 with 1397. Earlier I had thought that the 1480 would be replaced with a higher value sampling rate, such as was mentioned earlier as:

**“** calcIrms( ) - approx 5588 current samples per second.”

Bill.Thomson was right, I didn’t intentionally set the font larger and bolded.

Robert Wall, you also said:

**“** You have no control over that. It samples as fast as it can, doing the minimum amount of maths, until it’s got the number of samples you specified. **”**

This leads me back to thinking that the number of samples is almost arbitrary.

In your discussion of the working part, you said:

**“** Here is the working part. It reads the input, filters the standing bias out, squares it and accumulates the sum:”

*// Digital low pass filter extracts the 2.5 V or 1.65 V dc offset,*

*// then subtract this - signal is now centered on 0 counts.*

Does the sketch extract the 2.5 v, as a hard value or does the sketch sense the value of the bias that I have set. I ask this because I didn’t use precision resistors, so my bias is a little less than 2.5 vdc. Could that affect performance as well?

I had mentioned that I would like to eventually get to measuring both voltage and current. You said:

**“** When you do that, all this becomes irrelevant! The calcVI( ) method watches for zero crossings of the voltage and counts mains cycles, so the problem no longer exists. **”**

Hopefully by then, when I switch over to the EmonLib for voltage and current, I’ll have much of this tried and true. Stephen