[Nut-upsdev] usbhid-ups using wrong value for battery voltage for Pulsar Evolution 500?

[Arnaud Quette]

there are definitely wrong (at least fallback) declarations in mge-hid.c
as an example, we should try to map the below 2nd one as a fallback
since it's really the nominal *output* voltage, not the battery one:
	{ "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 },

gotta fix this.
Note that we have an internship that will soon finish a tool to query
the various HID data, and the various implementation (ex: the bounds
can be different across models), to have the complete data list with
descriptions and details.
I'll post this in the protocol section when available.

2008/2/25, Charles Lepple <clepple at gmail.com>:
> On Sun, Feb 24, 2008 at 4:18 PM, Arjen de Korte <nut+devel at de-korte.org> wrote:
>  > 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?
>
>
> I think so. It's a 1U rackmount unit.
>
>
>  >  > 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.
>
>
> Still, the battery charge value does not seem to correlate with the
>  120 and 119 values.
>
>
>  >  > 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?
>
>
> Indeed. The reason why I think it might be output voltage is due to
>  the flow ID, but I suppose it could be a /10 bug too.
>
>  I was hoping that Arnaud might be able to shed some light on it.
>
>
>  >  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.
>
>
> It has always been like that, but I haven't really played much with
>  setting the delays.

yep, this is due to the exponent 10, and so the 10 sec resolution.
not sure if the minimum can give us a bound...

Arnaud
-- 
Linux / Unix Expert R&D - MGE Office Protection Systems - http://www.mgeops.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
Free Software Developer - http://arnaud.quette.free.fr/