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
