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

[Rob Power]

I came up it was configuration descriptor (not string descriptor) which is
a bit different... by the way I'm not sure it explains the dimension
mismatch.

On the other side, string langid descriptor (line 0052) seems to be empty,
is that possible?


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

> 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/1a8a53ba/attachment.html>