Jim Klimov
2017-May-24 11:56 UTC
[Nut-upsdev] 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-upsdevIt 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
Charles Lepple
2017-May-24 12:46 UTC
[Nut-upsdev] NUT namespace: RFC for new variable addition
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.
Gernot Zander
2017-May-24 14:06 UTC
[Nut-upsdev] NUT namespace: RFC for new variable addition
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
Arnaud Quette
2017-Jun-14 12:38 UTC
[Nut-upsdev] NUT namespace: RFC for new variable addition
(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>
Jim Klimov
2017-Jun-14 18:25 UTC
[Nut-upsdev] NUT namespace: RFC for new variable addition
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, >Arnohttp://www.apc.com/us/en/faqs/FA156201/ explains a bit of the hassle -- Typos courtesy of K-9 Mail on my Redmi Android