[Nut-upsdev] Re: PowerCom USB units...

Eric Ashley eashleyfl at yahoo.com
Tue Feb 6 05:22:54 CET 2007


Thanks Peter,

That matches what I've been seeing.  I'm pressing Ultra to get PowerCom
to release the info about their specific usage.  My units are based on
the PowerCom Black Knight Pro series so maybe they're using the same
mechanism as the serial versions were.  I'll look into that since the
BNP series mostly worked correctly with the KIN1500AP driver for
serial.  I'll see what I can come up with, since PowerCom doesn't seem
to be in any hurry to forward their info.

I'll follow-up if I make any progress.

Thanks again,
Eric

--- Peter Selinger <selinger at mathstat.dal.ca> wrote:

> Eric Ashley wrote:
> > 
> > I did actually test descriptor 0 with indices 0 through 8 and got
> the
> > following:
> > 
> > ./get_descriptor 002 008 1 0 0 128 0 0
> > Can't get endpoint 128 descriptor 0x00 index 0: error sending
> control
> > message: Broken pipe
> > 
> > Just to make sure, I just checked again working all the way up to
> index
> > 31, with all returning "Broken pipe."  My most interesting data was
> for
> > descriptor 0x21 and 0x22, though I can't make any sense of the
> bytes
> > returned. 
> 
> I can. They are, respectively, the HID descriptor and report
> descriptor specified in the USB definition. The problem is not that
> we
> cannot read this data ("newhidups -DD -u root -x explore" already can
> read and parse it). This is only static data, intended to specify the
> device's capabilities. The main problem is that the device does not
> seem to implement the capabilities that those descriptors specify, at
> least not in a standard way. 
> 
> Unless the output of newhidups (see above) proves otherwise. 
> 
> -- Peter
> 
> > Hopefully, PowerCom will come across with the data. 
> > Otherwise I'll USBSNOOP the Windoze interface to determine what
> it's
> > processing.
> > 
> > When these units return a value on a particular descriptor, except
> > 0x03, will return the exact same data no matter what index I
> specify. 
> > The same 18 bytes is returned on descriptor 1 index 0 or index 128.
> > 
> > Thanks again,
> > Eric
> > 
> > --- Peter Selinger <selinger at mathstat.dal.ca> wrote:
> > 
> > > Yes, the iCute is 0d9f/0002, but the other two devices I
> mentioned
> > > are
> > > 0d9f/0001. They look very similar to yours. 
> > > 
> > > * the thread on nut-upsuser with subject "Newpoint 200897 UPS"
> > >   (December 2006).
> > > 
> > > * the thread on nut-upsuser with subject "Gentoo Ultra USB UPS"
> in
> > >   July/August 2006 [possibly the same as your device?]
> > > 
> > > We never got them to work yet.
> > > 
> > > Jon got the most interesting output from descriptor 0, which is
> the
> > > one you did not test. For descriptor 0, the index actually
> > > matters. Here's what he got:
> > > 
> > > index   response                                        meaning
> (what
> > > happens)
> > > 0       ?
> > > 1       UIS Ablerex                                    
> Manufacturers
> > > name
> > > 2       Ablerex USB Interface 049e                      Product
> > > 3        (246.5 140.0 246.5 024 50.0 27.0 25.0 
> > > 00001000.        Volt_in ?? Vol_out %cap Hz      ?? ?? ??
> > > 4       USB No Ack                                      Test for
> 10
> > > secs
> > > 5       USB No Ack                                      Test 
> > > disconnect from mains
> > > 6       USB No Ack                                     
> Disconnect
> > > mains
> > > 7       USB No Ack                                      Toggle
> beep
> > > on/off ?
> > > 8       USB No Ack                                      Toggle
> beep
> > > on ?
> > > 9       USB No Ack                                      Toggle
> beep
> > > on ?
> > > 10      USB No Ack                                      ?
> > > 11      USB No Ack                                      Reconnect
> > > mains
> > > 12         JP 01053T                                    ?
> > > 13      #240.0 0.0 024.0 50.0.                          Volt_in
> > > 14              breaks the pipe
> > > 
> > > Could you check descriptor 0? -- Peter
> > > 
> > > 
> > > Eric Ashley wrote:
> > > > 
> > > > Thanks for the tips.  Unlike the PowerCom iCute mentioned last
> > > month,
> > > > my units (1000VA and 1025VA-LCD) identify themselves with
> vendor
> > > 0x0d9f
> > > > and productid 0x0001.
> > > > 
> > > > I ran get_descriptor for descriptors 1 through 128 inclusive,
> > > indexing
> > > > 0 through 8 incl.  These units, except for descriptor 3, will
> > > always
> > > > return the same value regardless of index so I'm guessing that
> the
> > > > descriptor index is ignored for the most part.  However, for
> > > descriptor
> > > > 3, index 0 returns data; indices 1 through 3 produce a
> "Connection
> > > > timed out" error, and any other indices produce "Broken pipe",
> > > which is
> > > > also the error returned by non-supported descriptors.
> > > > 
> > > > The real data seems to be in descriptor 0x22 (see below).  Does
> > > this
> > > > data look similar enough to an existing unit that's supported
> for
> > > me to
> > > > try an existing driver?  If not, how do I go about trying to
> decode
> > > the
> > > > data?
> > > > 
> > > > Thanks,
> > > > Eric
> > > > 
> > > > --------------- get_descritor output ---------------
> > > > 
> > > > Bus 002 device 008 configuration 1 interface 0 altsetting 0
> > > endpoint
> > > > 128 descriptor 0x01 index 0:
> > > > 
> > > >  12 01 00 01 00 00 00 08 9f 0d 01 00 00 01 01 02 03 01
> > > > 
> > > >  ..................
> > > > Bus 002 device 008 configuration 1 interface 0 altsetting 0
> > > endpoint
> > > > 128 descriptor 0x02 index 0:
> > > > 
> > > >  09 02 22 00 01 01 00 40 00 09 04 00 00 01 03 00 00 00 09 21 00
> 01
> > > 00
> > > > 01
> > > >  22 af 00 07 05 81 03 08 00 fa
> > > > 
> > > >  ..".... at ...........!....".........
> > > > Bus 002 device 008 configuration 1 interface 0 altsetting 0
> > > endpoint
> > > > 128 descriptor 0x03 index 0:
> > > > 
> > > >  04 03 09 00
> > > > 
> > > >  ....
> > > > Can't get endpoint 128 descriptor 0x03 index 1: error sending
> > > control
> > > > message: Connection timed out
> > > > Can't get endpoint 128 descriptor 0x03 index 2: error sending
> > > control
> > > > message: Connection timed out
> > > > Can't get endpoint 128 descriptor 0x03 index 3: error sending
> > > control
> > > > message: Connection timed out
> > > > Can't get endpoint 128 descriptor 0x03 index 4: error sending
> > > control
> > > > message: Broken pipe
> > > > Can't get endpoint 128 descriptor 0x03 index 5: error sending
> > > control
> > > > message: Broken pipe
> > > > Can't get endpoint 128 descriptor 0x03 index 6: error sending
> > > control
> > > > message: Broken pipe
> > > > Can't get endpoint 128 descriptor 0x03 index 7: error sending
> > > control
> > > > message: Broken pipe
> > > > Can't get endpoint 128 descriptor 0x03 index 8: error sending
> > > control
> > > > message: Broken pipe
> > > > Can't get endpoint 128 descriptor 0x04 index 0: error sending
> > > control
> > > > message: Broken pipe
> > > > Can't get endpoint 128 descriptor 0x05 index 0: error sending
> > > control
> > > > message: Broken pipe
> > > > Can't get endpoint 128 descriptor 0x06 index 0: error sending
> > > control
> > > > message: Broken pipe
> > > > Can't get endpoint 128 descriptor 0x07 index 0: error sending
> > > control
> 
=== message truncated ===



 
____________________________________________________________________________________
The fish are biting. 
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php



More information about the Nut-upsdev mailing list