[Nut-upsdev] [blazer_usb] Support for TECNOWARE ERA LCD (FGCERALCD0K85)
Rob Power
robpwr at gmail.com
Wed Jan 9 19:36:11 UTC 2013
@Flavio: It would be great! About the software, I used usblyzer: it has 30
day full working trial on windows and you can export as html or other
formats.
It should have an option (menu "Capture->Capture hot-plugged") to start
sniffing when you connect a device; this may be useful to dump initial usb
connection as Chris was suggesting.
Otherwise you may run a windows virtual machine on Linux host and use
wireshark (
http://webcache.googleusercontent.com/search?q=cache:wAiv8nIyAsUJ:wiki.wireshark.org/CaptureSetup/USB+&cd=1&hl=it&ct=clnk
)
from linux host to capture, but may be a bit more complicated to set up.
@Chris and everyone:
I forgot to report, I'm on Ubuntu Server 12.04 LTS, i386,
kernel: 3.2.0-35-generic-pae
$ uname -a
Linux server_name 3.2.0-35-generic-pae #55-Ubuntu SMP Wed Dec 5 18:04:39
UTC 2012 i686 i686 i386 GNU/Linux
Attached is debug output without langid_fix: exactly the same output.
I tried before and output seemed the same, to be sure I didn't missed
anything I double-checked and there aren't significative changes.
About the code, I had almost understood part of the process (string request
usage) but I was not understanding what the first 2 bytes were.
But I'm still trying to figure out how UPSilon2000 works:
in Q capture, ignoring string 3 (Q1) commands, we have (tell me if I'm
wrong)
Status: beep = 1 (capture n. 0005-0002)
Asking for string 13 --> output: ..#.2.3.0...0. .0.0.2. .1.2...0.0.
.5.0...0... (Unknown command)
Status: beep = 1 (capture n. 0013-0010)
Asking for string 7 --> output: ..U.P.S. .N.o. .A.C.K. (should be Q
command)
Asking for string 12 --> output: P.#. . ..... (Unknown command)
Status: beep = 0 (capture n. 0024-0023)
...
Status: beep = 0 (capture n. 0024-0023)
Asking for string 7 --> output: ..U.P.S. .N.o. .A.C.K. (should be Q
command)
Status: beep = 1 (capture n. 0040-0039)
in TL command we have
Status: test = 0 (capture n. 0016-0015)
Asking for string 13 --> output: ..#.2.3.0...0. .0.0.2. .1.2...0.0.
.5.0...0... (Unknown command)
Asking for string 5 --> output: ..U.P.S. .N.o. .A.C.K. (should be TL
command)
Status: test = 1 (capture n. 0028-0027)
....
Asking for string 12 --> output: P.#. . ..... (unknown command)
Status: test = 1 (capture n. 0028-0027)
.....
and in CT
...
Again string 13 (with no status change)
Asking for string 11 --> output: ..U.P.S. .N.o. .A.C.K. (should be CT
command)
Status: test = 0
again string 12
So I was wondering: ups seems to answer commands (like Q, TL, CT) with "Ups
No Ack" string, while our driver seems to understand as a "message not
received", or am I wrong?
I still don't understand this part, maybe first
What are commands represented by string 12 and 13? Is it just casualty that
they show up before and after the selected command strings? May the
protocol work somehow like this:
ask string 13 (Meaning: "hey, I'm sending you a manteinance command")
ask string <command number> (Meaning: "do this/do that")
expecting "ups no ack" response
ask string 12 (Meaning: "hey, have you done last thing I asked?")
PS: I hope I may eventually make some tries adding debug options to the
code in next days (more probably next week). What values do you suggest to
print out? "buf" variable for example?
2013/1/9 flavio <gigafrav at gmail.com>
> I have the same UPS at home, I can do some other sniff with a Window
> laptop, what software I can use to do the sniff ?
>
> Flavio Astorino
>
> 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
>>
>>
>>
>>
>> _______________________________________________
>> Nut-upsdev mailing list
>> Nut-upsdev at lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20130109/043bf223/attachment-0001.html>
-------------- next part --------------
Network UPS Tools - Megatec/Q1 protocol USB driver 0.09 (2.6.5)
0.000000 debug level is '5'
0.172627 Checking device (1D6B/0001) (005/001)
0.172833 - VendorID: 1d6b
0.172850 - ProductID: 0001
0.172861 - Manufacturer: unknown
0.172872 - Product: unknown
0.172884 - Serial Number: unknown
0.172895 - Bus: 005
0.172906 Trying to match device
0.172940 Device does not match - skipping
0.172968 Checking device (1D6B/0001) (004/001)
0.173010 - VendorID: 1d6b
0.173024 - ProductID: 0001
0.173035 - Manufacturer: unknown
0.173046 - Product: unknown
0.173058 - Serial Number: unknown
0.173069 - Bus: 004
0.173080 Trying to match device
0.173094 Device does not match - skipping
0.173113 Checking device (1D6B/0001) (003/001)
0.173153 - VendorID: 1d6b
0.173166 - ProductID: 0001
0.173177 - Manufacturer: unknown
0.173189 - Product: unknown
0.173200 - Serial Number: unknown
0.173211 - Bus: 003
0.173222 Trying to match device
0.173235 Device does not match - skipping
0.173253 Checking device (0001/0000) (002/002)
0.180477 - VendorID: 0001
0.181921 - ProductID: 0000
0.182762 - Manufacturer: unknown
0.183318 - Product: unknown
0.183613 - Serial Number: unknown
0.183867 - Bus: 002
0.184116 Trying to match device
0.184395 Device matches
0.188481 send_to_all: SETINFO ups.vendorid "0001"
0.188756 send_to_all: SETINFO ups.productid "0000"
0.188875 send_to_all: SETINFO device.type "ups"
0.188998 send_to_all: SETINFO driver.version "2.6.5"
0.189114 send_to_all: SETINFO driver.version.internal "0.09"
0.189160 send_to_all: SETINFO driver.name "blazer_usb"
0.189280 Trying megatec protocol...
0.189323 send: Q1
0.193466 read: error sending control message: Protocol error
0.193662 blazer_status: short reply
0.193775 Status read 1 failed
0.193817 send: Q1
0.197489 read: error sending control message: Protocol error
0.197726 blazer_status: short reply
0.197844 Status read 2 failed
0.197888 send: Q1
0.201483 read: error sending control message: Protocol error
0.201718 blazer_status: short reply
0.201841 Status read 3 failed
0.201882 Trying mustek protocol...
0.201977 send: QS
0.202025 read: QS
0.202156 blazer_status: short reply
0.202295 Status read 1 failed
0.202387 send: QS
0.202428 read: QS
0.202538 blazer_status: short reply
0.202579 Status read 2 failed
0.202676 send: QS
0.202716 read: QS
0.202807 blazer_status: short reply
0.202847 Status read 3 failed
0.202940 Trying megatec/old protocol...
0.203036 send: D
0.203077 read: D
0.203167 blazer_status: short reply
0.203254 Status read 1 failed
0.203300 send: D
0.203405 read: D
0.203446 blazer_status: short reply
0.203548 Status read 2 failed
0.203641 send: D
0.203727 read: D
0.203773 blazer_status: short reply
0.203864 Status read 3 failed
0.203954 Trying zinto protocol...
0.204001 send: Q1
0.207476 read: error sending control message: Protocol error
0.207731 blazer_status: short reply
0.207834 Status read 1 failed
0.207929 send: Q1
0.211474 read: error sending control message: Protocol error
0.211774 blazer_status: short reply
0.211867 Status read 2 failed
0.211961 send: Q1
0.215470 read: error sending control message: Protocol error
0.215772 blazer_status: short reply
0.215865 Status read 3 failed
0.215959 No supported UPS detected
More information about the Nut-upsdev
mailing list