Nut upsdev - Dec 2008 - megatec_usb: Ippon BackComfoPro (06da:0003 Phoenixtec Power)

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

Citeren Roman Mamedov <roman at rm.pp.ru>:
> 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
No, this doesn't look OK at all. Although it looks like Megatec/Q1  
protocol, the data is damaged. The first three values should be  
(almost) identical, which clearly isn't the case. I suspect I know  
what is wrong though. Could you try the 'blazer_usb' driver from the  
SVN trunk? Run it with debugging enabled (-DDD, not higher!) and post  
the output here.

[...]
> 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.
No, this is because the data is damaged somehow.
> 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.
This is probably due to the same problem.

Best regards, Arjen
-- 
Please keep list traffic on the list