Thanks for pointing out the wrong log.txt and info about port settings; I attached new ups.conf, lsusb output and new blazer_usb -DDDDD output with new settings, though it has no changes respect to the last one.
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. 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? 2013/1/8 Charles Lepple <[email protected]> > On Jan 7, 2013, at 8:27 PM, Rob Power wrote: > > TL (0x05) or CT (0x0b) code seems not to be used in the relative sniffed file > and 0x07 (Q in nut coding) seems to be related to "UPS No Ack" string). > > If I'm reading drivers/blazer_usb.c correctly, "UPS No Ack" causes the > read loop to retry (up to 10 times). This is similar to the USB-to-serial > converter code in tripplite_usb.c, where it looks to make sure that the > received buffer differs from what was sent the last time. But it's possible > that this UPS doesn't use Q, just Q1 (string index 3, which does return a > somewhat normal-looking buffer). > > { "test.battery.start.deep", "TL\r" }, > { "test.battery.start.quick", "T\r" }, > { "test.battery.stop", "CT\r" }, > > Looks like TL and CT are for battery testing. > > I hate to nitpick about log.txt, but it appears to have the results from > the original langid_fix setting (0x4095) instead of 0x409. Could you please > capture and send that again? Using -DDDDD worked well. (I remember you said > it didn't work, but we're looking for any small differences in the output > that might narrow down where the problem lies.) > > port was setted according to lsusb output: > $ lsusb > [...] > Bus 002 Device 002: ID 0001:0000 Fry's Electronics > > Actually, for the USB drivers in NUT, the port setting is ignored > (although the NUT core needs some value, so we usually use 'auto'). The > matching is done by the numeric USB VID:PID combination. > > What does 'lsusb -vvv -d 0001:0000' return? > > -- > Charles Lepple > clepple@gmail > > > >
_______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
