I have the same UPS at home, I can do some other sniff with a Window laptop, what software I can use to do the sniff ?<div><br></div><div>Flavio Astorino<br><br><div class="gmail_quote">2013/1/8 Charles Lepple <span dir="ltr"><<a href="mailto:clepple@gmail.com" target="_blank">clepple@gmail.com</a>></span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div>On Jan 7, 2013, at 8:27 PM, Rob Power wrote:</div><br><blockquote type="cite">

<span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><div>

<div><pre>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).<br></pre></div></div></span></blockquote></div><div>

<span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><div>

<div>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).</div>

</div><div><br></div><div><div>                { "test.battery.start.deep", "TL\r" },</div><div>                { "test.battery.start.quick", "T\r" },</div><div>                { "test.battery.stop", "CT\r" },</div>

</div><div><br></div><div>Looks like TL and CT are for battery testing.</div><div><br></div><div>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.)</div>

<div><br></div></span></div><div><blockquote type="cite">port was setted according to lsusb output:<div><div><div>$ lsusb</div><div>[...]</div><div>Bus 002 Device 002: ID 0001:0000 Fry's Electronics</div></div>
</div><br></blockquote></div><div>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.</div>

<br>What does 'lsusb -vvv -d 0001:0000' return?</div><span><font color="#888888"><br><div>
<span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-spacing:0px"><div>

-- </div><div>Charles Lepple</div><div>clepple@gmail</div><div><br></div></span><br>
</div>
<br></font></span></div><br>_______________________________________________<br>
Nut-upsdev mailing list<br>
<a href="mailto:Nut-upsdev@lists.alioth.debian.org" target="_blank">Nut-upsdev@lists.alioth.debian.org</a><br>
<a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev</a><br></blockquote></div><br>
</div>