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

[Rob Power]

Hi guys!
I finally had time to make those small checks: you were right Chris, the
error comes from where you supposed: there's a usb protocol error when
krauler_command tries to read usb strings.
I changed the code as follow to have some debug:

line 252:
                        if (langid_fix != -1) {
                                /* Apply langid_fix value */
*                                upsdebugx(3,"blazer_usb.c, line 254: about
to launch usb_get_string (langid: %#x)",langid_fix);*
                                ret = usb_get_string(udev,
command[i].index, langid_fix, buf, buflen);
                        }
                        else {
*                                upsdebugx(3,"blazer_usb.c, line 257: about
to launch usb_get_string (no langid fix)");*
                                ret = usb_get_string_simple(udev,
command[i].index, buf, buflen);
                        }

                        if (ret <= 0) {
*                                upsdebugx(3,"blazer_usb.c, line 260: ret
<=0 error, ret: %d", ret);*
                                upsdebugx(3, "read: %s", ret ?
usb_strerror() : "timeout");
                                return ret;
                        }

and I got the following output (complete log is attached, though it's there
aren't other changes):
   0.197176     Trying megatec protocol...
   0.197284     send: Q1
   0.197326     blazer_usb.c, line 254: about to launch usb_get_string
(langid: 0x409)
   0.201535     blazer_usb.c, line 260: ret <=0 error, ret: -71
   0.201780     read: error sending control message: Protocol error
   0.201903     blazer_status: short reply
   0.201946     Status read 1 failed
   0.201988     send: Q1
   0.202126     blazer_usb.c, line 254: about to launch usb_get_string
(langid: 0x409)
   0.205532     blazer_usb.c, line 260: ret <=0 error, ret: -71
   0.205769     read: error sending control message: Protocol error
   0.205815     blazer_status: short reply
   0.205938     Status read 2 failed
   0.205982     send: Q1
   0.206041     blazer_usb.c, line 254: about to launch usb_get_string
(langid: 0x409)
   0.209529     blazer_usb.c, line 260: ret <=0 error, ret: -71
   0.209763     read: error sending control message: Protocol error
   0.209809     blazer_status: short reply
   0.209932     Status read 3 failed

The same happens while trying mustek protocol, and similar output came
without specifing any langid_fix (ret value = 71, too).
So it's confirme: usb_get_string (and usb_get_string_simple), invoked by
blazer_status in blazer.c, both ends with -71 return code, giving the
"read: error sending control message: Protocol error" message..
After that, blazer_status returns the "blazer_status: short reply" error.

I tried to search for more specific info on -71 error code, but found no
hints on the Internet; I just think it comes from here (
http://www.libusb.org/browser/libusb/libusb/libusb.h#L1361) and it's an
error code, but I can't understand what "71" value stands for  or where it
comes from exactly.

Flavio, thanks a lot for the sniffing! I'm having a look right now, trying
to understand something about the first data exchanges; I hope Chris (or
someone else, too) could find out something more.


2013/1/11 flavio <gigafrav at gmail.com>

> Sorry for the late but I had some trouble finding and installing UPSilon
> software :) Now I managed to capture all the usb traffic. I started
> USBlyzer before starting the installation of software and stopped after a
> complete tour of the program.
>
> I shared the ULZ and HTML file on google-docs :
>
> https://docs.google.com/file/d/0B-R2BvGl0W6DOWs4c3F5VndwMjg/edit
>
> https://docs.google.com/file/d/0B-R2BvGl0W6DSzNyNG9kdTVUdDg/edit
>
> Tell me if ther'is allo information you need, and not esitate to ask more
> sniffing ;)
>
> 2013/1/11 Charles Lepple <clepple at gmail.com>
>
>> On Jan 10, 2013, at 10:05 PM, Rob Power wrote:
>>
>> > (Small parenthesis: the information command response should start with
>> # while it starts with P#; not relevant now but weird).
>>
>> The "P" is really a length byte of 0x50 (but the device is returning far
>> less than 80 bytes for that transfer).
>>
>> --
>> Charles Lepple
>> clepple at gmail
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20130113/d8a1c506/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logs.zip
Type: application/zip
Size: 2330 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20130113/d8a1c506/attachment.zip>