[Nut-upsdev] [blazer_usb] Support for TECNOWARE ERA LCD (FGCERALCD0K85)

[Charles Lepple]

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 at gmail



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20130108/e9e686ca/attachment.html>