[Nut-upsdev] megatec_usb: Ippon BackComfoPro (06da:0003 Phoenixtec Power)

[Roman Mamedov]

Hello.

I've been experimenting with the USB connection of an Ippon BackComfoPro
800. This is the device "06da:0003 Phoenixtec Power Co., Ltd". The
current SVN version of NUT does not work with this device. The
megatec_usb driver can't get a proper reply to a Q1 request, failing
with an error message about "short read (14 bytes)" instead.

I have found the reason for this. The function run_query in megatec.c
uses ser_get_line to get information from the UPS. The ser_get_line
function has an "endchar" parameter, and "\r" is currently passed
there. As a result, ser_get_line only returns the received characters
up to the first "\r" (hex 0d) back to run_query.

The problem is, the data returned by my UPS is for some reason
sprinkled with these "\r" characters right in the middle of useful
data. Here is a hex dump of what is being returned by get_data_phoenix:

28 32 31 37 2e 30 20 32 30 30 31 30 30 31 0d 37 2e 30 20 30 32 32 20 35
30 2e 31 20 31 33 2e 38 20 32 35 2e 30 20 30 30 30 30 31 30 30 31 0d 37
2e 30 20 30 32 32 20 35 30 2e 31 20 31 33 2e 38 30 2e 31 20 31 33 2e 38

As you can see, there is an "\r" after just the first 14 characters,
because of which ser_get_line returns only what is before it, causing a
"short read". However, the complete response from the UPS, with the
"\r" bytes ignored, looks OK:

(216.6 20010.0 1.0 22.0 50.1 13.8 25.0 00001001

I have determined that the UPS is properly detected and works quite well
if I pass '\0' instead of '\r' as the endchar parameter to
ser_get_line. A sample patch is attached. Please consider adding some
kind of workaround for the described issue.

The only significant remaining problem is that Output voltage is being
reported as 1.0 volt. I guess the voltage for USB protocol might be
reported as a fraction of input voltage, or maybe that's because I am
mixing an older version of NUT with the newest megatec_usb driver.

Also, get_ups_info (the "I" query) fails with a "short read", but it's
not really a concern, since it does not prevent the driver from starting
and it works fine after that.

-- 
With respect,
Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nut-ippon-comfopro-800.patch
Type: text/x-patch
Size: 581 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20081220/19ddb313/attachment.bin