Peter Selinger wrote:
Charles Lepple wrote:
On 7/24/06, Phil DeBoest <[EMAIL PROTECTED]> wrote:
HID descriptor retrieved (Reportlen = 459)
Unable to get Report descriptor (-75)
Phil,
This looks a lot like the problem mentioned here:
http://lists.alioth.debian.org/pipermail/nut-upsdev/2005-November/000318.html
Peter,
Do you know where the problem turned out to be in the aforementioned
message? If it is a wrong value for desc->wDescriptorLength, we could
start a "quirks" table, and override the descriptor length for that
particular UPS (and for some of the APCs, if we are still seeing that
problem).
--
- Charles Lepple
Indeed, the cause of this bug was isolated here:
http://lists.alioth.debian.org/pipermail/nut-upsdev/2006-February/000705.html
As it turns out, there are two ways of retrieving report 0x21 (the HID
descriptor) from the UPS: either by requesting report 0x21 directly,
or by requesting report 0x02, which will have a copy of report 0x21
tucked onto its end. Normally, the two ways are supposed to give the
same result. However, on some buggy UPS's (notably Tripp Lite, and
some APC), only the second method works. "lsusb" always uses the second
method, whereas NUT has always used the first.
I have just committed some changes to the development branch that
hopefully solve this problem. Now I retrieve the HID descriptor in two
different ways, and when in doubt, use the second value (the same as
"lsusb"). I have also made libusb_open() more tolerant in case the
actual report descriptor is shorter than expected; so this should no
longer fail.
Phil, James, Justin, could you test this? Thanks, -- Peter
Peter Selinger wrote:
> Charles Lepple wrote:
>> On 7/24/06, Phil DeBoest <[EMAIL PROTECTED]> wrote:
>>> HID descriptor retrieved (Reportlen = 459)
>>> Unable to get Report descriptor (-75)
>> Phil,
>>
>> This looks a lot like the problem mentioned here:
>>
>>
http://lists.alioth.debian.org/pipermail/nut-upsdev/2005-November/000318.html
>>
>> Peter,
>>
>> Do you know where the problem turned out to be in the aforementioned
>> message? If it is a wrong value for desc->wDescriptorLength, we could
>> start a "quirks" table, and override the descriptor length for that
>> particular UPS (and for some of the APCs, if we are still seeing that
>> problem).
>>
>> --
>> - Charles Lepple
>>
>
> Indeed, the cause of this bug was isolated here:
>
>
http://lists.alioth.debian.org/pipermail/nut-upsdev/2006-February/000705.html
>
> As it turns out, there are two ways of retrieving report 0x21 (the HID
> descriptor) from the UPS: either by requesting report 0x21 directly,
> or by requesting report 0x02, which will have a copy of report 0x21
> tucked onto its end. Normally, the two ways are supposed to give the
> same result. However, on some buggy UPS's (notably Tripp Lite, and
> some APC), only the second method works. "lsusb" always uses the second
> method, whereas NUT has always used the first.
>
> I have just committed some changes to the development branch that
> hopefully solve this problem. Now I retrieve the HID descriptor in two
> different ways, and when in doubt, use the second value (the same as
> "lsusb"). I have also made libusb_open() more tolerant in case the
> actual report descriptor is shorter than expected; so this should no
> longer fail.
>
> Phil, James, Justin, could you test this? Thanks, -- Peter
Thanks Peter (and Charles)! That seemed to do the trick. The driver now
loads and upsd is able to retrieve information from it. Some of the
information seems a bit suspect, though. For example, it says the
battery voltage is 0, and, even less likely, the output voltage is
177.0. (I'm in the US, so nominal is 120). Surely it wouldn't be
indicating peak voltage instead of RMS? Since the computers connected to
the UPS continue to function without smoking, I doubt the output voltage
is actually that high.
The display on the UPS itself indicates everything is normal. Is this
likely a parsing issue, or should I investigate further with the UPS
itself? I could hook it up to a Windows box, install the software that
came with it, and see what it reads. Any other suggestions?
Here's the output of upsc:
battery.charge: 100
battery.type: PbAc
battery.voltage: 0.0
battery.voltage.nominal: 12.0
driver.name: newhidups
driver.parameter.port: auto
driver.version: 2.1.0
driver.version.data: TrippLite HID 0.1 (experimental)
driver.version.internal: 0.30
input.frequency: 59.8
input.voltage: 120.1
input.voltage.nominal: 120
output.frequency.nominal: 60
output.voltage: 177.0
output.voltage.nominal: 120
ups.beeper.status: enabled
ups.delay.reboot: 65535
ups.delay.shutdown: 65535
ups.mfr: Tripp Lite
ups.model: TRIPP LITE UPS
ups.power.nominal: 1000
ups.serial: 692195 A
ups.status: OL CHRG
Phil
Davis Brown is committed to providing Exceptional Client Service. For a review
of the supporting principles, go to www.lawiowa.com/about/exceptional
To ensure compliance with requirements imposed by the IRS in Circular 230, we
inform you that, unless we expressly state otherwise in this communication
(including any attachments), any tax advice contained in this communication is
not intended or written to be used, and cannot be used, for the purpose of (i)
avoiding penalties under the Internal Revenue Code or (ii) promoting,
marketing, or recommending to another party any transaction or other matter
addressed herein.
This electronic transmission and any documents accompanying this electronic
transmission contain confidential information belonging to the sender. This
information may be legally privileged. The information is intended only for
the use of the individual or entity named above. If you are not the intended
recipient, you are hereby notified that any disclosure, copying, distribution
or the taking of any action in reliance on or regarding the contents of this
electronically transmitted information is strictly prohibited.
_______________________________________________
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
