I have attached two .gz files of the driver output with the -DDDD option. One is for when the unit is on the line AC and the the other is when it is on battery so that there are at least two points of reference. In earlier tests, I did note that when the unit was placed on battery that the upsstats.cgi screen reported that the input voltage from 119V to 120V and did not go to zero as I expected it would. I also noted that the output voltage remained at 136V. I do have a old General Radio variac kicking around with no line cord or sockets that I can cobble something together with if these files do not provide enough data. On Wed, Mar 26, 2014 at 9:22 AM, Charles Lepple <clepple at gmail.com> wrote:> On Mar 23, 2014, at 11:12 PM, Bill S wrote: > >> The output of the driver is below. The incorrect voltage of 136 is >> shown at 0.265256. It should match input voltage of 119 as shown at >> 0.265219 but it doesn't. The voltages displayed on the UPS LCD panel >> information however are equal and match the input voltage provided by >> the driver. There might be other incorrect values in the usbhid-ups >> output but that is the one that has caught my attention so far. > > Unfortunately, there aren't many driver failure modes which would easily explain this value. Typical UPS firmware issues include using the wrong HID Usage code (the "Path:" in the debug output) or using the wrong combination of units and exponent so that the values are off by some power of ten. > > We might get a little more insight with a higher debug level (please save the output to a file, and send it to the list as a gzip'd attachment), but that seems to be what the UPS is reporting for that value. > > Another possibility is that when the UPS is in a passthrough mode, the driver should just copy the input voltage to the output voltage, and ignore the reported output voltage. I don't think this is how the USB HID PDC standard was intended to work, but it would probably make for a simpler implementation in the UPS. You would need to do a bit of testing to determine if, for instance, the ACPresent bit could be used for this purpose, or if it needs to be combined with other bits. (The UPS.Output.ff010043 path is non-standard, so maybe this would tell us something about this case, too.) > > It might be helpful to test with a variac, and ramp the voltage up and down to see which bits change as the UPS goes from battery to boost to passthrough. > > -- > Charles Lepple > clepple at gmail > > >-------------- next part -------------- A non-text attachment was scrubbed... Name: CP1500PFCLCD.ac.txt.gz Type: application/x-gzip Size: 2501 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20140326/2ce8433d/attachment.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: CP1500PFCLCD.bat.txt.gz Type: application/x-gzip Size: 2452 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20140326/2ce8433d/attachment-0001.bin>
On Mar 26, 2014, at 2:15 PM, Bill S wrote:> I have attached two .gz files of the driver output with the -DDDD > option. One is for when the unit is on the line AC and the the other > is when it is on battery so that there are at least two points of > reference. > > In earlier tests, I did note that when the unit was placed on battery > that the upsstats.cgi screen reported that the input voltage from 119V > to 120V and did not go to zero as I expected it would.Hmm, I wonder if it just wasn't polling fast enough? From the AC file: 0.263461 Report[get]: (3 bytes) => 0f 77 00 0.263469 Path: UPS.Input.Voltage, Type: Feature, ReportID: 0x0f, Offset: 0, Size: 16, Value: 119 On battery: 0.082947 Report[get]: (3 bytes) => 0f 00 00 0.082957 Path: UPS.Input.Voltage, Type: Feature, ReportID: 0x0f, Offset: 0, Size: 16, Value: 0> I also noted that the output voltage remained at 136V.This value (136) is suspiciously a Logical Minimum that was set elsewhere in the HID Report Descriptor. AC: 0.263726 Report[get]: (3 bytes) => 12 77 00 0.263735 Path: UPS.Output.Voltage, Type: Feature, ReportID: 0x12, Offset: 0, Size: 16, Value: 136 Note that 0x77 == 119 decimal. Battery: 0.083198 Report[get]: (3 bytes) => 12 78 00 0.083207 Path: UPS.Output.Voltage, Type: Feature, ReportID: 0x12, Offset: 0, Size: 16, Value: 136 I will have to consult the NUT code and the HID documentation to see whether the issue is in the HID parser or the UPS HID descriptor. -- Charles Lepple clepple at gmail
On Thu, Mar 27, 2014 at 10:40 PM, Charles Lepple <clepple at gmail.com> wrote:> On Mar 26, 2014, at 2:15 PM, Bill S wrote: ><<Snip>>> > Hmm, I wonder if it just wasn't polling fast enough? > > From the AC file: > > 0.263461 Report[get]: (3 bytes) => 0f 77 00 > 0.263469 Path: UPS.Input.Voltage, Type: Feature, ReportID: 0x0f, Offset: 0, Size: 16, Value: 119 > > On battery: > > 0.082947 Report[get]: (3 bytes) => 0f 00 00 > 0.082957 Path: UPS.Input.Voltage, Type: Feature, ReportID: 0x0f, Offset: 0, Size: 16, Value: 0 >Based on what you said, I pulled the plug again looking for a possible delay and what I found was that I needed to hit "refresh" in the browser to have it update. Once I did that it read "On Bat" and zero volts input in red. I was expecting it to update on it is own. My mistake. The output was still "136V" <<Snip>>
I just noticed what I think is another incorrectly reported value. I found that on the second screen of upsstats.cgi, the one with bar graphs, that the reported battery voltage is 16.0V even though the battery charge is at 100% and the UPS is on AC power. I would have thought it should be more than 25V.