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

[Rob Power]

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 <clepple at gmail.com>

> 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/20130109/a947493e/attachment.html>