[Nut-upsuser] Ablerex 625L USB version
Peter Selinger
selinger at mathstat.dal.ca
Sun Jan 28 08:24:14 CET 2007
No, it is all part of the report descriptor. A USB device might define
a variable called "Voltage", whose units are "Volts" (and not, for
example, millivolts, kilovolts, ...) and which can take values in the
range 0...250. At this point, you have not read any actual voltage
from the UPS yet. The only thing that has happened is that a certain
variable has been declared.
For example, the USB code for the physical unit "Volt" is
0x00F0D121. You see this in the line
Item(Global): Unit, data= [ 0x21 0xd1 0xf 0x00 ] 15782177
If you really want to know more about these variable descriptors, you
have to read the USB HID Power Device Class specification. It is at
http://www.usb.org/developers/devclass_docs under "Power".
But you don't really have to read this. NUT is already doing a good
job parsing the report descriptor. Your problem at this point is that,
after the device has declared all the variables, it does not allow you
to read their actual contents.
-- Peter
Jon Gough wrote:
>
> Peter,
> Looking at the data further down it has min and max values. These
> would seem to make sense for voltage (0 & 250), frequency (0 & 60),
> so is this data coming from the UPS, or is it just something in the
> system that expects these values?
>
> Regards
> Jon
>
> At 17:20 28/01/2007, Peter Selinger wrote:
> >Hi Jon,
> >
> >I can't figure out which version of NUT you are running, because you
> >have pruned that information from your output. Also, which patches, if
> >any, have you applied?
> >
> >What you are seeing from lsusb is not "data" from the UPS; it is
> >simply a detailed parsing of the report descriptor. For example, when
> >it says "Usage, data= [ 0x40 ] 64 Config Voltage", this simply means
> >that HID usage code 0040 corresponds to the "ConfigVoltage" item (see
> >e.g. libhid.c, line 1100).
> >
> >The error message "(75): Value too large for defined data type" may
> >indicate that the UPS is unhappy with the size of the buffer provided
> >by NUT (apparently 13). You can play with this by hacking a larger
> >buffer size. It should be easy to do this in the function
> >libhid.c:refresh_report_buffer(), by setting len to something bigger
> >(or smaller).
> >
> >If the buffer is too small, the device is supposed to fill it with
> >valid data up to the given size, instead of bailing out with an error
> >message. So it seems that the device is at least a little buggy.
> >Similar behavior has been observed in other cheap devices. (In fact,
> >one Belkin UPS that I own seems to have a dual bug: if you give a
> >buffer that is too large, then it will attempt to write random
> >contents from the firmware memory into the buffer, often crashing the
> >device).
> >
> >Alternatively, what would happen if you just ignored the error in
> >libhid.c after the call to get_report? Perhaps the buffer has been
> >filled with partial data in spite of the error message?
> >
> >Just some thoughts. -- Peter
> >
> >Jon Gough wrote:
> > >
> > > Peter,
> > > I have been trying with no luck to get the drivers working. I
> > > have done a "lsusb -v -d ffff:" to get the info from the USB
> > > regarding my UPS and it seems to be giving valid data. However, I am
> > > now confused with the "explore" option of the usbhid-ups program as
> > > the Report Descriptor is 632 byte long (which is confirmed by the
> > > lsusb program). But the lsusb program seems to be reading every other
> > > byte not each byte. What are the in between bytes for?
> > >
> > > I have included the output of the lsusb command below (sorry for
> > > the length) and it seems to read the output fine, but the NUT
> > > software seems to call libusb and get invalid responses. I notice in
> > > the latest output that the length of the data and the length being
> > > requested seem different (I put a couple of extra debugging statements in).
> > >
> > ><snip>
> > > Item(Local ): Usage, data= [ 0x40 ] 64
> > > Config Voltage
> > > Item(Global): Report Size, data= [ 0x10 ] 16
> > > Item(Global): Report Count, data= [ 0x01 ] 1
> > > Item(Global): Unit, data= [ 0x21 0xd1 0xf 0x00 ] 15782177
> > > Item(Global): Unit Exponent, data= [ 0x07 ] 7
> > > Item(Global): Logical Minimum, data= [ 0x00 ] 0
> > > Item(Global): Logical Maximum, data= [ 0xfa 0x00 ] 250
> > > Item(Main ): Feature, data= [ 0x02 ] 2
> > > Data Variable Absolute No_Wrap Linear
> > > Preferred_State No_Null_Position
> > > Non_Volatile Bitfield
> > > Item(Local ): Usage, data= [ 0x42 ] 66
> > > Config Frequency
> > > Item(Global): Report Size, data= [ 0x10 ] 16
> > > Item(Global): Report Count, data= [ 0x01 ] 1
> > > Item(Global): Unit, data= [ 0x01 0xf0 ] 61441
> > > Item(Global): Unit Exponent, data= [ 0x00 ] 0
> > > Item(Global): Logical Minimum, data= [ 0x00 ] 0
> > > Item(Global): Logical Maximum, data= [ 0x3c ] 60
> > > Item(Main ): Feature, data= [ 0x02 ] 2
> > > Data Variable Absolute No_Wrap Linear
> > > Preferred_State No_Null_Position
> > > Non_Volatile Bitfield
>
> <snip>
>
>
>
>
>
> ---
> avast! Antivirus: Outbound message clean.
> Virus Database (VPS): 000707-0, 27/01/2007
> Tested on: 28/01/2007 5:49:24 PM
> avast! is copyright (c) 2000-2007 ALWIL Software.
> http://www.avast.com
>
>
>
> --=====================_10221107==.ALT
> Content-Type: text/html; charset="us-ascii"
>
> <html>
> <body>
> <font size=3>Peter,<br>
> Looking at the data further down it has min and max values.
> These would seem to make sense for voltage (0 & 250), frequency (0
> & 60), so is this data coming from the UPS, or is it just something
> in the system that expects these values?<br><br>
> Regards<br>
> Jon<br><br>
> At 17:20 28/01/2007, Peter Selinger wrote:<br>
> <blockquote type=cite class=cite cite="">Hi Jon,<br><br>
> I can't figure out which version of NUT you are running, because you<br>
> have pruned that information from your output. Also, which patches,
> if<br>
> any, have you applied? <br><br>
> What you are seeing from lsusb is not "data" from the UPS; it
> is<br>
> simply a detailed parsing of the report descriptor. For example,
> when<br>
> it says "Usage, data= [ 0x40 ] 64 Config Voltage", this simply
> means<br>
> that HID usage code 0040 corresponds to the "ConfigVoltage"
> item (see<br>
> e.g. libhid.c, line 1100). <br><br>
> The error message "(75): Value too large for defined data type"
> may<br>
> indicate that the UPS is unhappy with the size of the buffer
> provided<br>
> by NUT (apparently 13). You can play with this by hacking a larger<br>
> buffer size. It should be easy to do this in the function<br>
> libhid.c:refresh_report_buffer(), by setting len to something bigger<br>
> (or smaller).<br><br>
> If the buffer is too small, the device is supposed to fill it with<br>
> valid data up to the given size, instead of bailing out with an
> error<br>
> message. So it seems that the device is at least a little buggy.<br>
> Similar behavior has been observed in other cheap devices. (In fact,<br>
> one Belkin UPS that I own seems to have a dual bug: if you give a<br>
> buffer that is too large, then it will attempt to write random<br>
> contents from the firmware memory into the buffer, often crashing
> the<br>
> device).<br><br>
> Alternatively, what would happen if you just ignored the error in<br>
> libhid.c after the call to get_report? Perhaps the buffer has been<br>
> filled with partial data in spite of the error message?<br><br>
> Just some thoughts. -- Peter<br><br>
> Jon Gough wrote:<br>
> > <br>
> > Peter,<br>
> > I have been trying with no luck to get the
> drivers working. I <br>
> > have done a "lsusb -v -d ffff:" to get the info from
> the USB <br>
> > regarding my UPS and it seems to be giving valid data. However, I am
> <br>
> > now confused with the "explore" option of the usbhid-ups
> program as <br>
> > the Report Descriptor is 632 byte long (which is confirmed by the
> <br>
> > lsusb program). But the lsusb program seems to be reading every
> other <br>
> > byte not each byte. What are the in between bytes for?<br>
> > <br>
> > I have included the output of the lsusb
> command below (sorry for <br>
> > the length) and it seems to read the output fine, but the NUT <br>
> > software seems to call libusb and get invalid responses. I notice in
> <br>
> > the latest output that the length of the data and the length being
> <br>
> > requested seem different (I put a couple of extra debugging
> statements in).<br>
> > <br>
> ><snip><br>
> >
> Item(Local ): Usage, data= [ 0x40 ] 64<br>
> >
> Config Voltage<br>
> >
> Item(Global): Report Size, data= [ 0x10 ] 16<br>
> >
> Item(Global): Report Count, data= [ 0x01 ] 1<br>
> >
> Item(Global): Unit, data= [ 0x21 0xd1 0xf0 0x00 ] 15782177<br>
> >
> Item(Global): Unit Exponent, data= [ 0x07 ] 7<br>
> >
> Item(Global): Logical Minimum, data= [ 0x00 ] 0<br>
> >
> Item(Global): Logical Maximum, data= [ 0xfa 0x00 ] 250<br>
> >
> Item(Main ): Feature, data= [ 0x02 ] 2<br>
> >
> Data Variable Absolute No_Wrap Linear<br>
> >
> Preferred_State No_Null_Position <br>
> > Non_Volatile Bitfield<br>
> >
> Item(Local ): Usage, data= [ 0x42 ] 66<br>
> >
> Config Frequency<br>
> >
> Item(Global): Report Size, data= [ 0x10 ] 16<br>
> >
> Item(Global): Report Count, data= [ 0x01 ] 1<br>
> >
> Item(Global): Unit, data= [ 0x01 0xf0 ] 61441<br>
> >
> Item(Global): Unit Exponent, data= [ 0x00 ] 0<br>
> >
> Item(Global): Logical Minimum, data= [ 0x00 ] 0<br>
> >
> Item(Global): Logical Maximum, data= [ 0x3c ] 60<br>
> >
> Item(Main ): Feature, data= [ 0x02 ] 2<br>
> >
> Data Variable Absolute No_Wrap Linear<br>
> >
> Preferred_State No_Null_Position <br>
> > Non_Volatile Bitfield</font></blockquote><br>
> <snip><br><br>
>
>
> <BR><BR>
> <TABLE width=400><HR>
> <P style="FONT: 9pt/11pt verdana"><a href="http://www.avast.com">avast! Antivirus</a>: Outbound message clean.
> <P style="FONT: 8pt/11pt verdana">Virus Database (VPS): 000707-0, 27/01/2007<BR>Tested on: 28/01/2007 5:49:24 PM<BR><FONT color=gray>avast! is copyright (c) 2000-2007 ALWIL Software.</FONT></P>
> <TBODY></TBODY></TABLE>
> <BR>
>
> </body>
> <br>
> </html>
>
> --=====================_10221107==.ALT--
>
More information about the Nut-upsuser
mailing list