On May 24, 2017, at 7:56 AM, Jim Klimov <[email protected]> wrote:
>
> On May 24, 2017 1:08:09 PM GMT+02:00, Charles Lepple <[email protected]>
> wrote:
>> I don't think "dephasing" is common usage, but "phase shift" should
>> suffice.
>>
>> Also, how does this apply to 3-phase systems? Is it nominally 120
>> degrees?
>>
>> Strange that this has not come up before.
>
> It was my impression too. However it seems the 'phase shift' usually refers
> to lag between Amperage and Voltage waves, while this issue is (if I get it
> correctly) about two separate ATS inputs fluctuating on their own different
> clock-offsets. Should be same freq (50 or 60) though, or likely assumed so -
> which might not be guaranteed in real life either ;) On the other hand, if
> the freqs differ, this reported skew degree will vary over time (if detected
> and reported honestly)...
Then maybe I am not understanding what the original variable name
("input.phase.shift") is referring to. We can always go back and update the
documentation to clarify, but variable names really shouldn't change once
merged. I think this is a little too close to "input.phases".
It does seem from the MIB that this refers to two different inputs, rather than
multiple phases of the same input (my mistake).
Most of the Google search results I see for "dephasing" are related to quantum
systems or medical imaging, aside from the Eaton MIB itself.
NUT is basically middleware for power devices. If we just publish everything
that the device reports without understanding what we are reporting, there is
little added value. In particular, if another device has a similar value to
report, I think we need a description that is good enough to match another
vendor's description of the same value.
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
