[Nut-upsdev] blazer_usb vs. Ippon Smart Power Pro 1400

Alexey Loukianov mooroon2 at mail.ru
Sun Jan 24 21:41:02 UTC 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

24.01.2010 13:49, Arjen de Korte wrote:
> Citeren Alexey Loukianov <mooroon2 at mail.ru>:
> 
> You may have used the modified driver you made before. You made some  
> changes to the 'cypress' subdriver to make it work with you 700  
> device, which are known to be incompatible with 0665:5161 USB to  
> serial converters (at least with the one I have here).
> 

Maybe. My experiments with 'cypress' type of controller showed up that the
correct write-read procedure for the device I have is following:

1. Write command in 8-bytes chunks on control pin.

2. Read up data from the pin 0x81 in 8-byte chunks, checking each chunk for the
occurrence of the CR character ('\r'). Any attempts to read another 8-bytes
chunk after the one with '\r' inside without sending a new command will lead to
the ETIMEDOUT error (and to device hang in case libusb 0.1.8 is used).

Some additional results obtained during testing:

1. Ippon Smart Power Pro 1400 and Ippon Back Power Pro 700 both do not support
'I\r' command. But instead echoing unsupported command back they behave
differently: SPP1400 returns no bytes producing ETIMEDOUT error, BPP700 returns
an empty string (a string starting with '\r' character and followed by 63 '\0'
characters).

2. SPP1400 response to unsupported command lacks the '\r' terminating character.
Here are two examples of the output from the debug utility:

[lexa2 at lx2linux Ippontest]$ ./ippontest
Examining device 1005/b113 (bus 001, dev 010)...not matched, skipping.
Examining device 05e3/0608 (bus 001, dev 009)...not matched, skipping.
Examining device 0ac8/3450 (bus 001, dev 002)...not matched, skipping.
Examining device 1d6b/0002 (bus 001, dev 001)...not matched, skipping.
Examining device 0665/5161 (bus 002, dev 011)...matched, going on.
Using cypress subdriver (Cypress usb-to-serial).
Trying to claim interface...success!
send: Q1
read loop:  in 8 bytes ... in 8 bytes ... in 8 bytes ... in 8 bytes ... in 8
bytes ... in 8 bytes ...done.
read 48 bytes: (219.0 218.5 216.2 005 50.1 27.2 25.0 00001001~0
interpreted string (46 bytes): (219.0 218.5 216.2 005 50.1 27.2 25.0 00001001
Result: (219.0 218.5 216.2 005 50.1 27.2 25.0 00001001
send: R
read loop:  in 8 bytes ...done.
read 8 bytes: R01001~0
interpreted string (6 bytes): R01001
Result: R01001
....

[lexa2 at lx2linux Ippontest]$ ./ippontest
Examining device 1005/b113 (bus 001, dev 010)...not matched, skipping.
Examining device 05e3/0608 (bus 001, dev 009)...not matched, skipping.
Examining device 0ac8/3450 (bus 001, dev 002)...not matched, skipping.
Examining device 1d6b/0002 (bus 001, dev 001)...not matched, skipping.
Examining device 0665/5161 (bus 002, dev 013)...matched, going on.
Using cypress subdriver (Cypress usb-to-serial).
Trying to claim interface...success!
send: F
read loop:  in 8 bytes ... in 8 bytes ... in 8 bytes ...done.
read 24 bytes: #220.0 006 24.00 50.0~00
interpreted string (21 bytes): #220.0 006 24.00 50.0
Result: #220.0 006 24.00 50.0
send: W
read loop:  in 8 bytes ...done.
read 8 bytes: W50.0~00
interpreted string (5 bytes): W50.0
Result: W50.0
....

Strangely enough the response to the unknown command 'M\r' is different (i.e.
the UPS behaves like it is a supported command that should be answered):

[lexa2 at lx2linux Ippontest]$ ./ippontest
Examining device 1005/b113 (bus 001, dev 010)...not matched, skipping.
Examining device 05e3/0608 (bus 001, dev 009)...not matched, skipping.
Examining device 0ac8/3450 (bus 001, dev 002)...not matched, skipping.
Examining device 1d6b/0002 (bus 001, dev 001)...not matched, skipping.
Examining device 0665/5161 (bus 002, dev 013)...matched, going on.
Using cypress subdriver (Cypress usb-to-serial).
Trying to claim interface...success!
send: F
read loop:  in 8 bytes ... in 8 bytes ... in 8 bytes ...done.
read 24 bytes: #220.0 006 24.00 50.0~00
interpreted string (21 bytes): #220.0 006 24.00 50.0
Result: #220.0 006 24.00 50.0
send: M
read loop:  in 8 bytes ...done.
read 8 bytes: C~0.0~00
interpreted string (1 bytes): C
Result: C

- -- 
Best regards,
Alexey Loukianov                          mailto:mooroon2 at mail.ru
System Engineer,                            Mob.:+7(926)218-1320
*nix Specialist

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJLXL5uAAoJEPB9BOdTkBULTc8IAIcCkay3mHFnQ2Hg8weXPVlv
C++JNE3RhHGytLScibzHEwU/yvWxZ4pblxcYrbw5LYqhj/OUl8JLhcJUZ5niXCkB
vSFXVe+tLW3lPWftTyCWI/7UhH83/SP5mZNMOv3DwdAjdh1yoDlDY3I8kKTtYOnM
IkBk6NuDaTnCyh3ovAApFEUfTJ6NsMf8NIJDSVDJgw8bsbIqqIdPED2CxbcA9r0W
uiwhErZiGnXu7yFA8PZBxuo8S5QvmnSyet4VDlim25gHFjL9/xp5Cu1xLBLk6Lb2
NYRnQil9vkqxiQSSFCpDLz+sxM/FsN5UyOn2GdHNQLVUhZlDmoNFETxc9skfGgs=
=cQJF
-----END PGP SIGNATURE-----



More information about the Nut-upsdev mailing list