Nut upsdev - Jun 2017 - NUT namespace: RFC for new variable addition

On May 24, 2017 1:08:09 PM GMT+02:00, Charles Lepple <clepple at
gmail.com> wrote:
>On May 24, 2017, at 5:11 AM, Arnaud Quette <arnaud.quette at
gmail.com>
>wrote:
>> 
>> Hi all,
>> 
>> here is another one, related to ATS (automatic transfer switch) this
>time.
>> 
>> in order to track "dephasing" between input sources (1 and
2), I'd
>like to add a new variable: "input.phase.shift"
>> 
>> 
>> Details and implementation can be found on:
>> https://github.com/networkupstools/nut/pull/433
>> 
>> Comments and feedback warmly welcome.
>
>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.
>_______________________________________________
>Nut-upsdev mailing list
>Nut-upsdev at lists.alioth.debian.org
>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
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)...

Jim
--
Typos courtesy of K-9 Mail on my Redmi Android

On May 24, 2017, at 7:56 AM, Jim Klimov <jimklimov at cos.ru>
wrote:
> 
> On May 24, 2017 1:08:09 PM GMT+02:00, Charles Lepple <clepple at
gmail.com> 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.

Hi,

am 24 Mai schrieb Charles Lepple:
>>> 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?
>>> 
>> 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)...
"phase offset" or "phase difference" is used for thre-phase
systems,
AFAIK. And yes, 120 degrees.

CU
Gernot

(hmmm, finally hitting the Sent button...)

2017-05-24 13:56 GMT+02:00 Jim Klimov <jimklimov at cos.ru>:
> On May 24, 2017 1:08:09 PM GMT+02:00, Charles Lepple <clepple at
gmail.com>
> wrote:
> >On May 24, 2017, at 5:11 AM, Arnaud Quette <arnaud.quette at
gmail.com>
> >wrote:
> >>
> >> Hi all,
> >>
> >> here is another one, related to ATS (automatic transfer switch)
this
> >time.
> >>
> >> in order to track "dephasing" between input sources (1
and 2), I'd
> >like to add a new variable: "input.phase.shift"
> >>
> >>
> >> Details and implementation can be found on:
> >> https://github.com/networkupstools/nut/pull/433
> >>
> >> Comments and feedback warmly welcome.
> >
> >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.
> >_______________________________________________
> >Nut-upsdev mailing list
> >Nut-upsdev at lists.alioth.debian.org
> >http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
>
> 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)...
>
Jim is right, this is very tied to ATS. I don't see that applying to 3ph
UPS, since there is only 1 source.
The point for ATS is that a source may be the main, and the other a UPS.
Hence the potential phase shift.
The nominal value is 0

cheers,
Arno
-- 
Eaton Data Center Automation Solutions - Opensource Leader -
http://42ity.org
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20170614/9b753a53/attachment.html>

On June 14, 2017 2:38:16 PM GMT+02:00, Arnaud Quette <arnaud.quette at
gmail.com> wrote:
>(hmmm, finally hitting the Sent button...)
>
>2017-05-24 13:56 GMT+02:00 Jim Klimov <jimklimov at cos.ru>:
>
>> On May 24, 2017 1:08:09 PM GMT+02:00, Charles Lepple
><clepple at gmail.com>
>> wrote:
>> >On May 24, 2017, at 5:11 AM, Arnaud Quette <arnaud.quette at
gmail.com>
>> >wrote:
>> >>
>> >> Hi all,
>> >>
>> >> here is another one, related to ATS (automatic transfer
switch)
>this
>> >time.
>> >>
>> >> in order to track "dephasing" between input sources
(1 and 2), I'd
>> >like to add a new variable: "input.phase.shift"
>> >>
>> >>
>> >> Details and implementation can be found on:
>> >> https://github.com/networkupstools/nut/pull/433
>> >>
>> >> Comments and feedback warmly welcome.
>> >
>> >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.
>> >_______________________________________________
>> >Nut-upsdev mailing list
>> >Nut-upsdev at lists.alioth.debian.org
>> >http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
>>
>> 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)...
>>
>
>Jim is right, this is very tied to ATS. I don't see that applying to
>3ph
>UPS, since there is only 1 source.
>The point for ATS is that a source may be the main, and the other a
>UPS.
>Hence the potential phase shift.
>The nominal value is 0
>
>cheers,
>Arno
http://www.apc.com/us/en/faqs/FA156201/ explains a bit of the hassle
--
Typos courtesy of K-9 Mail on my Redmi Android