> ## Content Index
> Fetch the complete content index at: https://sreekars-journal.labvion.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# I have readings. What do they mean?
- URL: https://sreekars-journal.labvion.com/pq-07-numbers-but-no-units-yet/
- Published: 2025-06-26T12:30:00.000Z
- Updated: 2026-10-29T08:51:43.000Z
- Description: One preserved line gives me a count and its input-voltage equivalent: 13190 and 1648.75 millivolts. At the raw sampler's stated scale of 0.125 millivolts per count, the multiplication agrees exactly. The result is 1.64875 V, close to the intended midpoint. This is the kind of small calculation
- Author: Sreekar
- Tags: Power meter, #Import 2026-10-29 10:08

One preserved line gives me a count and its input-voltage equivalent: 13190 and 1648.75 millivolts. At the raw sampler's stated scale of 0.125 millivolts per count, the multiplication agrees exactly. The result is 1.64875 V, close to the intended midpoint. This is the kind of small calculation I enjoy following because it stops a number being merely a number on the screen. It tells me what the ADC saw at its input, before I attach a sensor scale or a final physical label.

There are several conversions hidden between the ADC's answer and the quantity I want. First comes the raw digital code. Then comes the voltage represented by that code under the selected range. Then I have to account for any shift in the sensor signal and the relationship between that signal and the original quantity. Those stages can be written in one expression, but I find them easier to follow separately. Otherwise I can get an answer with no idea which part of the expression gave it its meaning.

I'm using a numerical example to make the first conversion less vague. The calculation links the raw count to input voltage. The selected conversion scale is 0.125 millivolts per count. A raw value of 12,000 would represent 1,500 millivolts, or 1.5 volts, at the ADC input. The multiplication is easy. The important part is knowing why that step size applies. A different configured range changes it, so I can't treat 12,000 as a voltage without knowing the setting used to obtain it.

Now suppose, still in the same example, that the signal has a midpoint of 1.65 volts. The difference between 1.5 volts and that midpoint is minus 0.15 volts. That doesn't mean the original quantity was minus 0.15 volts. It means the small signal is 0.15 volts below its middle value. I would still need the sensor's relationship to the original quantity. Keeping the stages separate stops me jumping from the code straight to a physical conclusion that the code alone doesn't support.

The order matters too. If I apply a calculation to the shifted signal before accounting for its midpoint, I may be measuring the shift along with the part I actually wanted. If I apply a calibration multiplier without understanding the units underneath it, I can make a number look reasonable while leaving the mistake intact. That’s why I want the intermediate values visible while learning. A final result that looks wrong is much easier to investigate when I know the values that produced it.

The line belongs to the current-sensor investigation dated 26 June 2025, which is still marked In Progress. Its channel description and printed labels do not line up cleanly, so I keep the demonstrated arithmetic separate from identifying every signal column. The raw sketch itself is clear about its own route: A0 is read first, then A1, and each count is passed through computeVolts. That gives me a reliable way into the explanation. Conversion into input volts is one relationship; deciding which sensor signal those volts represent is another.

There’s another difference between seeing movement and understanding movement. A signal can vary because the quantity being measured varies, but it can also vary because of a connection problem or noise. A small change on the screen doesn't tell me which explanation applies. I don't want to become so pleased that the values are changing that I stop asking whether they should be changing in that way. The next useful question is about the relationship between the input and the output, rather than whether the program prints something at all.

The ADC configuration and the circuit need to stay together in my notes. I can imagine saving a list of raw values and discovering later that I don't know the range, channel or program version. The numbers would still exist, but part of their meaning would be missing. That’s an unexpectedly interesting part of measurement: the information beside a reading can be necessary to understand the reading itself. The value alone isn't always enough, even when it has plenty of digits.

I also want to avoid using calibration as a way to escape this stage. Calibration should connect the instrument's output to a reference under known conditions. It shouldn't be a rescue button I press whenever I don't understand the conversion. If the raw value has become volts incorrectly, adjusting a later multiplier might hide the problem at one point and make it harder to recognise somewhere else. There’s more satisfaction in finding the right route through the calculation than in finding any multiplier that makes one display look believable.

For now, the useful output is a sequence I can explain: raw code, ADC-input voltage, signal relative to its midpoint, and the quantity inferred from the sensor. I don't have to put every intermediate value on the finished display. I do want access to them while working out the circuit. The display is still the fun-looking part, but I'm starting to enjoy this part too. There’s a whole chain of meaning inside a number that, a moment ago, I was ready to copy onto a screen and call finished.

The intermediate value is worth keeping visible. I can trace the arithmetic confidently while leaving the next physical interpretation at the stage the actual circuit and calibration support.