The two values share an array index, but they do not come from one simultaneous call. The final sketch reads A0 and then A1 for every entry. Later, their calibrated values are multiplied into sum_p. That’s the precise place where the relationship between voltage and current enters the result. I can see why the multiplication looks tidy in software while its physical interpretation still depends on when each reading represents the signal.
The multiplication is the easy-looking part. Instantaneous power involves voltage and current at the same time. If the program instead combines a voltage from one time with a current from a later time, it is calculating a product of two different moments. Both individual readings might be reasonable. The pair can still represent a relationship different from the real one. That’s the part I hadn't been giving enough attention to when thinking of the voltage channel and current channel as two independently finished measurements.
A simple picture helps. Imagine two ideal sine waves that are genuinely in step, one representing voltage and one current in a resistive example. At each moment, the signs and positions match in the way the ideal model predicts. Now shift the current waveform along the time axis before multiplying it by voltage. I haven't changed the magnitudes of the individual waves. I have changed which points are paired. The average product changes because the relationship between the paired values has changed.
There’s a clean way to attach numbers to that picture. At 50 Hz, one cycle lasts 20 milliseconds. A one-millisecond shift is one twentieth of a cycle, or 18 degrees. In a simplified model using point samples of pure sine waves with a fixed relative shift, the average product contains the cosine of that phase shift. Cosine of 18 degrees is about 0.951. An ideal in-phase pair would therefore appear different if I deliberately paired points with that delay.
The extreme examples make the same idea easier to see. A quarter-cycle shift in that ideal model is five milliseconds at 50 Hz. It puts the waves 90 degrees apart, so the mean product is zero even though neither waveform has disappeared. A half-cycle shift changes the sign of the relationship. I don't expect those examples to describe the actual setup. They are useful because they show how information about timing can change a power result without changing the RMS magnitude of either separate waveform.
That last distinction is important. If I take a complete ideal sine wave and shift it in time, its RMS stays the same. Multiplying the separate RMS values therefore doesn't reveal every pairing problem in the instantaneous-product calculation. The channel displays can each look plausible while the derived power or power factor needs investigation. A neat set of voltage and current numbers isn't enough to settle the relationship between them. This is where looking at quantities one at a time can hide a question that only appears when I combine them.
The position within the wave matters to the individual difference too. Near a peak, a short shift can change a sine value less than the same shift near a steep crossing. That means a few pairs that happen to look close don't settle the question for the whole cycle. I want the simplified drawing to show the full relationship over time, rather than choose a convenient instant that makes the two readings appear interchangeable.
The timer around the entire collection does not give every pair a timestamp. It records the beginning and end of acquisition, which is useful for the overall interval but different from identifying the effective time of each channel conversion. That’s why I keep the timing relationship beside the phase-shift calculation. The code provides the sequential order; the waveform and effective conversion timing determine what that order means for the product.
The actual ADC doesn't have to behave exactly like the simplified point-sample picture for the question to matter. The conversion mode, how the program requests results and the effective time represented by each reading all need attention. I can't take a nominal conversion interval and announce that it is the exact voltage-current delay. The software sequence and the converter's behaviour have to be understood together. I also can't conclude that the effect is negligible without inspecting those details or obtaining a suitable check.
Even a timestamp needs a clear meaning. A time recorded at the start of a loop doesn't automatically identify the effective time of every conversion inside that loop. I would need to know what event the timestamp marks and how that event relates to the reading. Otherwise I could add time information without actually answering the question of when the two signals were represented.
The overall count is clear in the final file: 400 entries in each channel array, filled by A0 and A1 calls in that order. The remaining timing issue is different from the count. I need to distinguish the duration of the complete collection from the displacement between the two readings associated at each index. Knowing one does not automatically give the other.
Waveform shape adds another reason not to use the ideal sine example as a universal correction. For a smooth ideal pair with a fixed delay, the maths is straightforward. A real load and a real sensing arrangement can produce a more complicated relationship. The sensor paths themselves may also affect what reaches the ADC. I need to understand what the measurement supports before applying a simple phase adjustment as if it solves every case. A useful teaching example should make the question clearer, not make the real signal disappear behind a convenient assumption.
There are possible ways to investigate or design around timing differences, but I haven't demonstrated a completed fix here. Better acquisition choices, a documented timing model or an appropriate comparison might be part of the work. The first step is to know what is happening now. I don't want to add a correction merely because I have learnt the word phase. A correction has to correspond to a real, understood effect. Otherwise I could make one example look better while making the interpretation harder everywhere else.
The software relationship is clear enough to put on a timeline: request A0, request A1, repeat, then process corresponding array entries. A voltage value and its current partner are paired by index. The acquisition timer marks the whole collection rather than every effective conversion instant. That distinction gives the timing explanation a concrete beginning. It’s more informative than judging the power-factor output by whether the final decimal looks believable.
The particular finding is simple enough to state: the program pairs sequential readings. Understanding that pair needs more than recognising the multiplication sign, and that is exactly where the timing explanation belongs.