search for: get_descriptor

Joel Peshkin wrote: > > I hacked in the following additonal changes... > > Index: newhidups.c > =================================================================== > RCS file: /cvsroot/nut/nut/drivers/newhidups.c,v > retrieving revision 1.1.1.1.8.6.2.21 > diff -u -r1.1.1.1.8.6.2.21 newhidups.c > --- newhidups.c 7 Nov 2005 22:14:20 -0000 1.1.1.1.8.6.2.21 > +++

...itial detection process sometimes succeeds in 1 out of 5 "Q1" commands, but that's about it (which is better than what the krauler subdriver can do... absolutely nothing). So, what needs to be done to obtain more information? I don't seem to get anything readable out of the "get_descriptor" tool. What command line parameters should I use? Be aware that I'm still almost completely ignorant about this USB stuff... -- Carlos Rodrigues

tags 354429 + upstream thank 2006/2/26, suicune@eml.cc <suicune@eml.cc>: > Package: nut > Version: 2.0.1-3 > > > This is the spam message: > drivers/usb/input/hid-core.c: ctrl urb status -32 received > > I never once saw this message until after I installed and configured > nut. > > Spam begins during boot and continues infinitely until reboot or nut is >

.... As soon as the UPSmart was stopped, the values returned would stay the same and wouldn't update. Observing the usb chatter in wireshark showed that the UPSmart program received and sent an URB_INTERRUPT to 0x81 EP. This was happening in a pattern of receive/send URB_INTERRUPT followed by 5 GET_DESCRIPTOR request/respond. The UPS is cheap and cheerful, details can be found here https://www.jaycar.com.au/650va-390w-line-interactive-ups-with-lcd-and-usb/p/MP5205 The badge on the front says 'DIGITECH Computer', model MP5205 I opened the case up and removed the comms board, but there's not...

...to obtain info from Liebert whether those two values plus ups.status are actually *all* the data the UPS offers.) -- UPS has changed bus ID from 2:2 to 2:6 after the experiment. (Note that I pulled the cable *twice* to verify some detail ...) 2. RECLAIMED STATE -- entered by running "get_descriptor 002 006 0 0 0 128 0x22 0" (code at lists.alioth.debian.org/pipermail/nut-upsdev/2005-August/000088.html, output below) -- /proc/bus/usb/devices (excerpt below) now lists "(none)" as driver -- lsusb -v now lists the entire spiel (output below) -- no change for newhidups driver...

...39;re not related to GitHub issue #674 (https://github.com/networkupstools/nut/issues/674), right? > Observing the usb chatter in wireshark showed that the UPSmart program received and sent an URB_INTERRUPT to 0x81 EP. This was happening in a pattern of receive/send URB_INTERRUPT followed by 5 GET_DESCRIPTOR request/respond. This was the same thing I got to, the last time I looked into that (after #307, there have been some other topics on the lists or on GitHub, I can't remember exactly now). > The UPS is cheap and cheerful, details can be found here > https://www.jaycar.com.au/650va-390w-...

Hi Peter, I've forwarded your mail to upsdev as it will be of interest for several people that are working on it. As I'm also on vacation (again) for a week and 1/2 as of this evening, I don't think I'll have the time for it before I get back.... I've not yet audited the patches, but these are queued on the Alioth tracker:

...(Q1, I, F - descriptors 0x3, 0xc and 0xd respectively) I sometimes get non-usual responses - "UPS No Ack". So the data gets stale rather often. By the way, this is the only thing I get when doing "non-informative" requests. Example: tornado:/home/alex/development/nut/tools# ./get_descriptor 002 003 1 0 0 0x81 3 3 Bus 002 device 003 configuration 1 interface 0 altsetting 0 endpoint 129 descriptor 0x03 index 3: 60 03 28 00 32 00 31 00 37 00 2e 00 30 00 20 00 31 00 36 00 35 00 2e 00 30 00 20 00 32 00 31 00 37 00 2e 00 30 00 20 00 30 00 30 00 30 00 20 00 35 00 30 00 2e 00 30 00 20...

...ns... ok Notification: (3 bytes) => 07 0C 01 then sits and does nothing. It looks like it's stuck in kernel space, so I'm guessing it's waiting for something from the UPS. Lastly, the Solaris libusb document (/usr/sfw/share/doc/libusb/libusb.txt) notes that the function usb_get_descriptor_by_endpoint is 'Not implemented for Sun plugins', and by my reckoning, this is what NUT uses quite a bit - the libusb code for usb_get_descriptor_by_endpoint seems to just use a usb_control_msg, in the same format as NUT uses in newhidups. So. on the off chance someone comes along again a...

Hi, I've been trying (unsuccessfully) to interact with the above UPS using its USB/HID interface and have come to the conclusion that it's not going to be as "easy" as I'd first thought :( My attempts have all been on FreeBSD-5 (kernel as of today) using NUT v2.0.2 and fiddling with newhidups -- I tried the simple approach of adding the IDs and "seeing what

Hello everybody, After succeeded in "tuning" nut-2.0.0's hidups and 2.0.3's newhidups on customized Linux kernels, we are now facing a new challenge : trying to install nut-2.0.5 on a RedHat ES4 which is based on a 2.6.9 kernel. I picked up the 2.0.5 source package and follow the INSTALL doc until step 6. So far so good. RH ES4 is managed by udev, therefore I presume we

Peter Selinger wrote: > Hm. I need more information, as NUT seems to garble the values even > before I can see them. I am not so worried about the date and > temperatures (although, strangely, the battery replacement date > appears to be Sept 25, 2001, which makes no sense). But the voltage is > definitely important. > > [...] > Thanks Peter - I'll send the new

Greetings all, Anyone done any work on these products? I have several (a couple of different models) that are rebranded Ultra in the US. Using explore with usbhid returns some significant quantities of data and I've done some captures with usbsnoop. I've also asked Ultra to get me the HID definition that was used for them, in the hopes I don't have to usbsniff all the setting