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

[Rob Power]

Just another extra consideration, while trying to decypher the sniffed data:
looking here (
http://www.beyondlogic.org/usbnutshell/usb5.shtml#StringDescriptors) seems
that usb descriptors starts with a byte expressing the length of the
descriptor itself.
Trying to look at what I think is descriptor 0 (ex. capture line 43, "Get
Descriptor (Cfg ind:0)" the content is:

09 02 22 00 01 01 00 A0 32 09 04 00 00 01 03 00
00 00 09 21 00 01 00 01 22 70 02 07 05 81 03 08
00 0A

Starting with "09" while length is 33 if I'm not wrong... do I missed
something?


2013/1/13 Rob Power <robpwr at gmail.com>

> 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/aa9d69e0/attachment-0001.html>