[Nut-upsdev] Powercom support and sponsorship

[Morozov Alexey]

Dear All,
Our software engineers checking your questions and will reply next week.


Sincerely yours
--
Alexey Morozov
distribution manager 



-----Original Message-----
From: Arjen de Korte [mailto:nut+devel at de-korte.org] 
Sent: Tuesday, November 10, 2009 11:58 AM
To: Morozov Alexey
Cc: Alexander Gordeev; nut-upsdev at lists.alioth.debian.org
Subject: Re: [Nut-upsdev] Powercom support and sponsorship

Citeren Morozov Alexey <morozov at pcm.ru>:

> Kindly please work out in detail your questions.

1) Value too large for defined data type

Feature reports 0x11 (UPS.PowerSummary.ConfigVoltage), 0x19
(UPS.Battery.ConfigVoltage), 0x1c (UPS.Input.ConfigVoltage) and 0x20
(UPS.Output.ConfigVoltage) should return an 8 bit (1 byte) value
according to the report descriptor. When we retrieve them, we get more
than that (probably two bytes, but the actual value can't be reported).
Either the report descriptor needs to be fixed, or reading the feature
report should return the correct amount of data.

-> NUT won't be able to read nominal input-, output- and battery voltage

Input reports 0x0a (UPS.PowerSummary.RemainingCapacity) and 0x15
(UPS.Battery.Test) both return 2 bytes while the report descriptor says
these should be 8 bit (1 byte), the same as the the corresponding
feature reports.

-> NUT won't be able to use these reports

2) Erroneous value retrieved for report

Reports 0x12, 0x1a, 0x1d and 0x21 all return '212' as value. I very much
doubt that UPS.PowerSummary.Voltage, UPS.Battery.Voltage,
UPS.Input.Voltage and UPS.Output.Voltage are the same (since these
should be measured values).

-> NUT won't read the input-, output- and battery voltage

3) Suspicious value read

The input report and feature report 0x0e
(UPS.PowerSummary.RunTimeToEmpty) don't match (0x0e 0x64 0x10 and 0x0e
0x80 0x09 respectively). While technically not wrong, it is doubtful
that this really is the case.

Looking at the values read in the input reports, there might be an issue
with ordering of data:

   [0a] 0c 10 (expected 64)
   [0e] 64 10 (expected 80 09)
   [15] 80 09 (expected 01)
   [14] 01 09 (expected 0c 10)

Looking at the actual and expected values, it looks like the data for
the input reports is outputed with the next input report. Also, the
number of bytes returned in the reports seems to be fixed at 2, while
this should depend on the actual size of the reports (1 byte for 0x0a
and 0x15 and 2 bytes for 0x0e and 0x14).

There is a small chance that this could be an issue with libusb, USB
controller and/or operating system, so for the moment I would call this
suspicious only. Alexander, could you post what you're using right now?
Is this a *BSD or a Linux system?

-> NUT only uses input reports as a trigger to read feature reports,
so if the number of bytes is correct, there would be no issue.

Best regards, Arjen

PS  It would be helpful if I could have a Powercom unit too for
debugging the above.
--
Please keep list traffic on the list