Nut upsuser - Jun 2017 - [HCL] Cyber Power Systems CP1500AVRLCDa supported by usbhid-ups

On 5/30/2017 10:47 PM, Charles Lepple wrote:
> On May 22, 2017, at 11:13 AM, Mike <the.lists at mgm51.com> wrote:
>>
>> On 5/21/2017 10:39 AM, Charles Lepple wrote:
[snip]
> Even though the CPS sub-driver has been written already, I would like to
take a look at the raw "explore" mode output:
> 
>
http://new.networkupstools.org/docs/developer-guide.chunked/ar01s04.html#_writing_a_subdriver

When I ran:

drivers/usbhid-ups -DD -u root -x explore -x vendorid=0764 auto

it balked at "auto":

Network UPS Tools - Generic HID driver 0.41 (2.7.4)
USB communication driver 0.33
   0.000000     Error: too many non-option arguments. Try -h for help.


so I added a -a parameter to point to the ups name configured in
ups.conf, and that worked.  The output from that command is zipped and
attached.


[snip]
> 
> If it were the input voltage, I would recommend experimenting with a
variac, but you are probably not going to see much of a range on the output
before the buck/boost circuits kick in. So it's still an option, but it
might not be worth the trouble for an UPS in service (or if you don't have a
variac handy).

Here's the results of the varying voltage tests:

input   output       UPS        output.voltage  input.voltage
to UPS  from UPS     display
119.9   120.4        119            136.0          120.0
115.2   115.6        114            138.0          114.0
127.3   128.0        127            136.0          127.0
135.5   136.4        135            136.0          135.0
100.4   100.5        100            140.0          100.0
 94.9   105.1         95            137.0           96.0
120.7   121.1        120            142.0          118.0
140.8   122.8        139            136.0          139.0
121.7   122.1        121            136.0          120.0


Notes:

1) the input to UPS was measured by a Kill-A-Watt device, the output
from UPS was measured by a HP 974a DVM.  Prior to these tests, I ran
them from the same source, and they tracked pretty well, with the 974a
usually about 0.5 volts higher than the Kill-A-Watt.  For the purpose of
this test, I figured that would be OK.

2) output.voltage and input.voltage were from the upsc command

3) the readings were taken about 30 to 45 seconds apart.  That's how
long it took me to set a new voltage on the Powerstat.

4) when I went down to 95 volts, the "AVR" kicked in to boost the
voltage without going to battery.  This was indicated by a "click"
from
the UPS and an indication on the UPS display.

5) When I went up to 140 volts, the UPS switched over to batteries.

Hope this helps.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ups-test.zip
Type: application/octet-stream
Size: 2576 bytes
Desc: not available
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170603/fad12f74/attachment.obj>

On Jun 3, 2017, at 2:21 PM, Mike <the.lists at mgm51.com>
wrote:
> 
> On 5/30/2017 10:47 PM, Charles Lepple wrote:
>> On May 22, 2017, at 11:13 AM, Mike <the.lists at mgm51.com>
wrote:
>>> 
>>> On 5/21/2017 10:39 AM, Charles Lepple wrote:
> [snip]
> 
>> Even though the CPS sub-driver has been written already, I would like
to take a look at the raw "explore" mode output:
>> 
>>
http://new.networkupstools.org/docs/developer-guide.chunked/ar01s04.html#_writing_a_subdriver
> 
> 
> When I ran:
> 
> drivers/usbhid-ups -DD -u root -x explore -x vendorid=0764 auto
> 
> it balked at "auto":
> 
> Network UPS Tools - Generic HID driver 0.41 (2.7.4)
> USB communication driver 0.33
>   0.000000     Error: too many non-option arguments. Try -h for help.
> 
> 
> so I added a -a parameter to point to the ups name configured in
> ups.conf, and that worked.  The output from that command is zipped and
> attached.
Heh, that's embarrassing that the "-a" has been missing for so
long. Noted.
> 
> [snip]
>> 
>> If it were the input voltage, I would recommend experimenting with a
variac, but you are probably not going to see much of a range on the output
before the buck/boost circuits kick in. So it's still an option, but it
might not be worth the trouble for an UPS in service (or if you don't have a
variac handy).
> 
> 
> Here's the results of the varying voltage tests:
> 
> input   output       UPS        output.voltage  input.voltage
> to UPS  from UPS     display
> 119.9   120.4        119            136.0          120.0
> 115.2   115.6        114            138.0          114.0
> 127.3   128.0        127            136.0          127.0
> 135.5   136.4        135            136.0          135.0
> 100.4   100.5        100            140.0          100.0
> 94.9   105.1         95            137.0           96.0
> 120.7   121.1        120            142.0          118.0
> 140.8   122.8        139            136.0          139.0
> 121.7   122.1        121            136.0          120.0
This is starting to come back to me - I think we saw this with several other CPS
devices.

Here's an excerpt from the CP1500AVRLCDa HID descriptor:

Collection(Physical)
    Report ID(16)
        Usage(LowVoltageTransfer)
        Logical Minimum(97)
        Logical Maximum(103)
        Feature(Data,Variable,Absolute)

        Usage(LowVoltageTransfer)
        Input(Constant,Variable,Absolute)

        Usage(HighVoltageTransfer)
        Logical Minimum(136)
        Logical Maximum(142)
        Feature(Data,Variable,Absolute)

        Usage(HighVoltageTransfer)
        Input(Constant,Variable,Absolute)

    Report ID(18)
        Usage(Voltage)
        Feature(Constant,Variable,Absolute)

        Report Size(8)
        Logical Minimum(0)
        Logical Maximum(255)
        Unit(SI Linear: ...)
        Unit Exponent(0)

Basically, it is saying that you can set each of LowVoltageTransfer and
HighVoltageTransfer to a number between 97--103 and 136--142, respectively (per
the Feature). You can also read back the value (Input). Both of these are set in
Report 16.

The HID descriptor uses a stateful parser to keep track of things that don't
change between each Input, Feature or Output element. So the HighVoltageTransfer
Input has the same range as the HighVoltageTransfer Feature.

However, I don't believe that parser should be completely reset between each
Report ID. So the Voltage Feature inherits the last range (136-142) from the
HighVoltageTransfer Input. This confuses the NUT HID parser, which is only
expecting an integer between 0 and 6, inclusive. I suppose we should have a
range check for that.

Progress has been slow on patching the HID descriptors:
https://github.com/networkupstools/nut/issues/169

On the other hand, since Report ID 16 doesn't look as broken as ID 18,
adjusting the high and low transfer voltages might not be hard:
https://github.com/networkupstools/nut/issues/438
> 4) when I went down to 95 volts, the "AVR" kicked in to boost the
> voltage without going to battery.  This was indicated by a
"click" from
> the UPS and an indication on the UPS display.
In non-explore mode, does the driver report the AVR status? (No need to set
things back up if you have torn it down already, just curious.)

Regarding the battery.mfr.date thing, I should have checked on the source code
earlier. It is just retrieving a number from UPS.PowerSummary.iOEMInformation,
and using that as a USB string index. Looks like a typo - none of the other DDL
entries for CPS show anything that looks like a date. The CPS HID code was
forked from the APC HID code, and APC has their own algorithm for encoding
battery dates (which is what I thought I was remembering).

Does OpenBSD have something like FreeBSD's usbconfig? You could try
retrieving other string descriptors to see if this is something that got moved
(and iOEMInformation happened to point to the right string), or if it is just a
mistake in the source code.

   usbconfig -u	0 -a 1 dump_string 3

On 6/4/2017 4:46 PM, Charles Lepple wrote:
[snip]

>> 4) when I went down to 95 volts, the "AVR" kicked in to boost
the
>> voltage without going to battery.  This was indicated by a
"click" from
>> the UPS and an indication on the UPS display.
> 
> In non-explore mode, does the driver report the AVR status? (No need to set
things back up if you have torn it down already, just curious.)
With 120 volt input to the UPS:

	ups.status: OL


With 97 volt input to the UPS and AVR displayed on the UPS' display:

	ups.status: OL BOOST


> 
> Regarding the battery.mfr.date thing, I should have checked on the source
code earlier. It is just retrieving a number from
UPS.PowerSummary.iOEMInformation, and using that as a USB string index. Looks
like a typo - none of the other DDL entries for CPS show anything that looks
like a date. The CPS HID code was forked from the APC HID code, and APC has
their own algorithm for encoding battery dates (which is what I thought I was
remembering).
> 
> Does OpenBSD have something like FreeBSD's usbconfig? You could try
retrieving other string descriptors to see if this is something that got moved
(and iOEMInformation happened to point to the right string), or if it is just a
mistake in the source code.
> 
>    usbconfig -u	0 -a 1 dump_string 3
I haven't explored to see if OpenBSD has the equivalent (or similar)
command.  On the other hand, I did have a test system set up with
FreeBSD 11.0 (AMD64), nut-2.7.4_1 from the FreeBSD pkg.  :)

dmseg excerpt for the UPS:

	ugen1.2: <CPS> at usbus1


Result of the command, where "n" is incremented in a loop:

	# usbconfig -u 1 -a 2 dump_string n
	STRING_0x00 = 0x04, 0x03, 0x09, 0x04
	STRING_0x01 = <CP1500AVRLCDa>
	STRING_0x02 = <CTHGN200xxxx>
	STRING_0x03 = <CPS>
	STRING_0x04 = <PbAcid>
	STRING_0x05 = <BF01512BA31>
	STRING_0x06 = <read error>
	STRING_0x07 = <read error>
	STRING_0x08 = <read error>
	STRING_0x09 = <read error>
	STRING_0x0a = <read error>

I wasn't sure how high I should go with "n," so I stopped at 10.

Is that what you were looking for?