On Dec 21, 2013, at 11:36 PM, Ariel Wainer wrote:> On 21/12/13 21:31, Ariel Wainer wrote: >> >> Ok, I did this, here is how it went (approximately): >> t=0 power on the UPS, with some load. >> t=2 min unplug the UPS from mains, alarm goes off. >> t=33 min low battery alarm goes off. >> t=35 min ups powers down. >> > > Ok, trying to make sense of the capture (again: it's all guessing, I > have no experience with usb protocol): > > Up until packet #255/131 seconds in the pcap file, the payload is 0x03, > then it changes to 0x01 , and then it changes again to 0x02 at packet > #3975/2081 seconds. > > It seems like: > 0x01 = AC failed > 0x02 = Battery low. > 0x03 = AC is okAlso, there is an Interrupt Out transfer at #4115/2154 (repeated at #4117) that sends a 0x01 down to the UPS. I assume it turns off at that point, or shortly thereafter?> It looks simillar to the UPS implementation example from > http://www.usb.org/developers/devclass_docs/pdcv10.pdfWell... the first few pages of Appendix A are boilerplate USB descriptors. The report descriptor (A.6) is where things start to differ. Your UPS doesn't have Usage Page 0x84, 0x85 or 0x86 in its report descriptor - it only has 0xFFA0, which is in the vendor-specific range, and the two Usage fields are just 8-byte unstructured buffers (also with vendor-specific IDs). It might be possible to tell usbhid-ups to match on the 0xFFA0 usage page, and ignore all of the other HID PDC definitions. I'll poke around the code. -- Charles Lepple clepple at gmail
On 22/12/13 16:48, Charles Lepple wrote:> > Also, there is an Interrupt Out transfer at #4115/2154 (repeated at #4117) that sends a 0x01 down to the UPS. I assume it turns off at that point, or shortly thereafter?Sorry for the the delay, If I remember correctly, that's what happened.>> It looks simillar to the UPS implementation example from >> http://www.usb.org/developers/devclass_docs/pdcv10.pdf > Well... the first few pages of Appendix A are boilerplate USB descriptors. The report descriptor (A.6) is where things start to differ. Your UPS doesn't have Usage Page 0x84, 0x85 or 0x86 in its report descriptor - it only has 0xFFA0, which is in the vendor-specific range, and the two Usage fields are just 8-byte unstructured buffers (also with vendor-specific IDs).It seems that its very poorly and implemented in a very non-standard way. I mailed the reseller a few days ago, still no answer.> It might be possible to tell usbhid-ups to match on the 0xFFA0 usage page, and ignore all of the other HID PDC definitions. I'll poke around the code.Ok, let me know if you need anything else. I tryed the instructions at http://www.networkupstools.org/docs/developer-guide.chunked/ar01s04.html , but it didn't work. As a matter of fact, the generated C files did not compile, they had garbage in the middle. Hand editing the sources to make it compile resulted in a non-working driver anyway, probably because of the not implemented usages. Happy $HOLYDAY ;)
On Dec 26, 2013, at 9:40 PM, Ariel Wainer wrote:>> It might be possible to tell usbhid-ups to match on the 0xFFA0 usage page, and ignore all of the other HID PDC definitions. I'll poke around the code. > > Ok, let me know if you need anything else. I tryed the instructions at > http://www.networkupstools.org/docs/developer-guide.chunked/ar01s04.html > , but it didn't work. As a matter of fact, the generated C files did not > compile, they had garbage in the middle. Hand editing the sources to > make it compile resulted in a non-working driver anyway, probably > because of the not implemented usages.Could you please send the debug output? (if it is more than ~ 30KB gzipped, just send it directly to me.) I was going to use the debug output from the earlier thread to generate those C files, but yeah, there are some additional bits needed. If nothing else, it would be good to improve the diagnostics for that script.> Happy $HOLYDAY ;)Thanks, same to you! -- Charles Lepple clepple at gmail