On Jan 8, 2013, at 6:41 PM, Rob Power wrote: > I still didn't have figured out exactly all the blazer_usb code, I hope I'll > have more time to study it tomorrow or during the week and to recheck the > sniffed files; meanwhile if this new info may be useful somehow and there's > something more I can try I'm always available.
It's a little easier if you consider the evolution of these devices. They started off as serial-only, with a small microcontroller that reads one-line ASCII commands. For instance, on a serial-only version of your UPS, the Upsilon2000 software would send a Q1 command (ending with '\r'), and the UPS would reply with something like: 227.7 22 7.7 012 50.1 13.0 --.- 00001001\r (This is what blazer_ser does.) The USB models are generally the original serial models bolted to a simple USB-to-serial chip. In the case of your UPS, the Q1 gets translated to a request for USB string index 3, which happens to be the first index that isn't listed in the generic USB device descriptor (iManufacturer is usually 1, and iProduct is often 2). The UPS returns the Q1 reply in the response to the string index request (the gray shaded area in the USBlyzer output). The first two bytes are the size, and a constant 3 to indicate a string descriptor, then the string itself follows in UTF-16 encoding. You quoted the krauler_command() function earlier, so I think you came to this conclusion already-- but I'm just making sure we're on the same page. There is an outer loop to try the megatec protocol (Q1) as well as some variants, but given the additional translation layer, the krauler_command() function responds to the megatec variant's commands with the string descriptor fetches. It should not make it to the other variants, if I am not mistaken. > PS: about -DDDDD gave me the debug output, but UPS is not recognized; might > the output together with sniffed data be enough useful to figure out how the > communication works with that UPS? Should be possible, although at this point I suspect that the NUT driver is missing a step in the initialization sequence. Is there a way to get USBlyzer to dump the very beginning of the USB conversation, starting from device enumeration of the UPS? In particular, it would be interesting to see the fetch of string descriptor 0. The reason is that this portion of the output indicates that the usb_get_string() function is failing: 0.197751 send: Q1 0.201620 read: error sending control message: Protocol error You can add a few debugging statements to that function, but I'm pretty sure that those error messages come from lines 240 and 261, respectively: http://trac.networkupstools.org/projects/nut/browser/tags/v2.6.5/drivers/blazer_usb.c#L240 http://trac.networkupstools.org/projects/nut/browser/tags/v2.6.5/drivers/blazer_usb.c#L261 Here's a silly question: did you ever try running the driver without any langid_fix value? -- Charles Lepple clepple@gmail _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
