The calibration pairs are literal differences between saved versions. The report and smaller RMS sketch contain 769.0 and 0.85. The final-named file contains 766.0 and 0.85, while another copy contains 625.0 and 30.0. I can compare those actual values without assuming that three files represent three successful recalibrations. The interesting part is where each factor enters the calculation and what physical relationship it is supposed to describe.
The temptation is to decide that the file with the most final-looking name must contain the right answer. That would be convenient, but a filename isn't a reference measurement. A number can be correct for one arrangement and wrong for another. Before deciding whether two constants disagree, I have to know whether they were meant to describe the same sensor, input settings, calculation and version of the circuit.
I'm keeping the comparison literal at first. These are the values written in these places. I don't know that every difference represents a new experimental discovery, a hardware change or a correction to an error. Any of those might be possible, but the possibility isn't the evidence. It’s better to leave a question beside the pair than build a whole explanation from the size of the numbers.
Even the close pair deserves context. The difference between 769 and 766 is 3, which is roughly 0.39% of 769. That’s only a comparison of the constants themselves. The program decides how a constant enters the result.
The pair containing 625 and 30 makes guessing from appearance even less useful. I shouldn't assume the second number has the same role or units just because it occupies a similar position in a saved file. I need to read the calculation and the settings around it. Otherwise I might describe a large change in calibration when the underlying meaning of the value has changed too.
I'm using a very small example to remind myself what a scale correction means. In this case, a reference quantity is 10 arbitrary units and an uncorrected calculation reports 9. A simple multiplicative correction for that point would be 10 divided by 9. That makes the arithmetic easy to follow.
The calibration guide supplies the adjustment method: old factor multiplied by reference reading divided by program reading. That gives a factor a reason, instead of making it an answer chosen because its digits look familiar. It also keeps scale separate from centre removal. The smaller RMS sketch subtracts fixed offsets, while the final file subtracts means from its stored collection. A changed factor and a changed centring method would affect different parts of the route. Tracing those operations is useful even when the historical comparison readings behind a particular constant are not preserved.
An offset error asks a different question. Adding or subtracting a middle value isn't the same operation as changing the scale. If I use a multiplier to disguise an offset problem at one point, the result elsewhere may still be wrong. That’s why I want the steps separated in the explanation: what the ADC returned, how the offset was handled, how the sensor relationship was used and where the calibration factor entered.
The reference reading needs its own record. Which quantity was compared? What did the reference instrument show, and what did the program show before adjustment? Which code and hardware produced those readings? Without that connection, the constant becomes a fact I can copy but can't defend. With it, I have a route back to the observation and can decide what another check would need to examine.
I also need to distinguish agreement at one point from understanding the whole operating range. The little 10-and-9 example only fixes one comparison. Different inputs could reveal something the single adjustment doesn't explain. I'm identifying why the supporting readings matter more than the final line containing a multiplier.
The files can be compared directly by their operations as well as their factors. The smaller RMS program uses fixed voltage/current offsets and separate 100 ms collections. The final-style files estimate means from stored arrays before their calibration multipliers enter. That’s useful context for the different numbers: a factor has to be read in the calculation that uses it. Copying just a pair of constants would preserve their digits while losing the route that gives them meaning.
This is a good question to bring to my mentor with the files open. We would have the actual lines to compare, and I could ask about the missing setup or reference rather than vaguely asking which number is right. If an older value was changed, the useful answer would include why. Then the explanation belongs with the version, rather than surviving only as something someone remembers telling me.
I can leave the versions distinct and still explain them clearly. The result is a calibration account that follows the calculation and its reference relationship, rather than a neat history guessed from filenames.