Nut upsdev - Feb 2008 - usbhid-ups using wrong value for battery voltage for Pulsar Evolution 500?

I suspect that the battery is failing on my Pulsar Evolution 500 (it
is several years old now) but I can't seem to get a valid battery
voltage from the UPS.

The following tests were done using NUT 2.2.1, but I first noticed
this with the trunk, and reproduced it with the current
branches/Testing as well.

The only two values I have seen for battery.voltage are 120.0 and 119.0, e.g.:

$ upsc evo | grep battery      # full upsc output attached.
battery.voltage: 120.0
battery.voltage.nominal: 120

At first I wondered if there was a unit conversion error, but then I
pulled the plug, and noticed that the voltage did not go down (even
when the UPS shut off due to an apparently low battery - the charge
was much higher than it should have been, and there was no OB+LB
status, but that's another issue).

Then, I started looking into the MGE subdriver and the debug output:

mge-hid.c, line 344:
        { "battery.voltage", 0, 0,
"UPS.PowerSummary.Voltage", NULL,
"%.1f", 0, NULL },
        { "battery.voltage.nominal", 0, 0,
"UPS.BatterySystem.ConfigVoltage", NULL, "%.0f",
HU_FLAG_STATIC, NULL
},
        { "battery.voltage.nominal", 0, 0,
"UPS.PowerSummary.ConfigVoltage", NULL, "%s",
HU_FLAG_STATIC,
mge_battery_voltage_nominal },

Here are some of the UPS.PowerSummary lines from running with "-DD":

Path: UPS.PowerSummary.PowerSummaryID, Type: Feature, ReportID: 0x26,
Offset: 0, Size: 8, Value: 1.000000
Path: UPS.PowerSummary.FlowID, Type: Feature, ReportID: 0x26, Offset:
8, Size: 8, Value: 4.000000
Path: UPS.PowerSummary.ConfigVoltage, Type: Feature, ReportID: 0x27,
Offset: 0, Size: 16, Value: 120.000000
Path: UPS.PowerSummary.Voltage, Type: Feature, ReportID: 0x2b, Offset:
16, Size: 16, Value: 119.000000

And some flow information:

Path: UPS.Flow.[4].ConfigFrequency, Type: Feature, ReportID: 0x14,
Offset: 8, Size: 8, Value: 60.000000
Path: UPS.Flow.[4].ConfigActivePower, Type: Feature, ReportID: 0x14,
Offset: 16, Size: 16, Value: 350.000000
Path: UPS.Flow.[4].ConfigApparentPower, Type: Feature, ReportID: 0x14,
Offset: 32, Size: 16, Value: 500.000000
Path: UPS.Flow.[4].ConfigCurrent, Type: Feature, ReportID: 0x14,
Offset: 48, Size: 16, Value: 4.160000
Path: UPS.Flow.[4].ConfigVoltage, Type: Feature, ReportID: 0x15,
Offset: 0, Size: 16, Value: 120.000000
Path: UPS.PowerConverter.Output.OutputID, Type: Feature, ReportID:
0x1c, Offset: 0, Size: 8, Value: 1.000000
Path: UPS.PowerConverter.Output.FlowID, Type: Feature, ReportID: 0x1c,
Offset: 8, Size: 8, Value: 4.000000

So I'm wondering if the "UPS.PowerSummary.FlowID" being equal to 4
means that the voltage in "UPS.PowerSummary.Voltage" is really the
power converter output voltage (Volts AC) instead of the battery
voltage (Volts DC).

Any ideas?

Could this be related to the "Evolution 650" bug mentioned in
mge-hid.c? (On the other hand, I suspect that if I added my model to
that function, it would only fix the battery.voltage.nominal)

Debug output is attached.

-- 
- Charles Lepple
-------------- next part --------------
A non-text attachment was scrubbed...
Name: upsc-evo-2.2.1.txt.gz
Type: application/x-gzip
Size: 658 bytes
Desc: not available
Url :
http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20080224/c5130026/attachment.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: usbhid-ups-DD-2.2.1.txt.gz
Type: application/x-gzip
Size: 2540 bytes
Desc: not available
Url :
http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20080224/c5130026/attachment-0001.bin

Charles Lepple wrote:
> I suspect that the battery is failing on my Pulsar Evolution 500 (it
> is several years old now) but I can't seem to get a valid battery
> voltage from the UPS.
What is the actual battery voltage you would expect? Something like 12 V?
> The following tests were done using NUT 2.2.1, but I first noticed
> this with the trunk, and reproduced it with the current
> branches/Testing as well.
> 
> The only two values I have seen for battery.voltage are 120.0 and 119.0,
e.g.:
> 
> $ upsc evo | grep battery      # full upsc output attached.
> battery.voltage: 120.0
> battery.voltage.nominal: 120
I can't say that I'm really surprised here. My 'Evolution 650'
will
report battery voltage (nominal 12 V) in 1 V increments. So the only
practical reported values are probably 12 and 13 V here. I was rather
shocked to find that it has such a lousy resolution.
> At first I wondered if there was a unit conversion error, but then I
> pulled the plug, and noticed that the voltage did not go down (even
> when the UPS shut off due to an apparently low battery - the charge
> was much higher than it should have been, and there was no OB+LB
> status, but that's another issue).
[...]
> Could this be related to the "Evolution 650" bug mentioned in
> mge-hid.c? (On the other hand, I suspect that if I added my model to
> that function, it would only fix the battery.voltage.nominal)
It might need a /10 conversion for *both* values here, or it is
reporting something completely different. Maybe Arnaud can tell?

I also noticed in the debug output you showed, that the device is reporting

Path: UPS.PowerSummary.DelayBeforeStartup, Type: Feature, ReportID:
0x29, Offset: 0, Size: 24, Value: -10.000000

The value '-10' looks odd here. I would not expect this to go lower than
'-1'. Maybe this has to do something with the "Set startup delay,
in ten
seconds units for MGE". According to the HID PDC specification, the
values that are changed here are in one second units, so we may need
some conversion here too.

Best regards, Arjen

Charles Lepple wrote:
> Could this be related to the "Evolution 650" bug mentioned in
> mge-hid.c? (On the other hand, I suspect that if I added my model to
> that function, it would only fix the battery.voltage.nominal)
I checked with Arnaud. The 'Pulsar Evolution' series doesn't support
measurement of the 'battery.voltage(.nominal)' and instead returns what
NUT regards as 'output.voltage(.nominal)'. I changed the
'mge-hid.c'
subdriver to only use the 'UPS.PowerSummary.(Config)Voltage' for
models/series that are known to use this as 'battery.voltage(.nominal)',
so it should be fixed now (r1339).

Best regards, Arjen