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

[Arjen de Korte]

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