Nut upsuser - Apr 2013 - blazer driver: Possible bugs with battery packs

Hello all,

long time away from this list, glad to be around again!

I have this Powercom Vanguard VGN VGD-20K31. Some details of this model:

* 3-phase input, single phase output
* Model has 240V / 12V9AH x 20 x 2SET, plus another set of 20 batteries. 
All in all, 3 sets
* Serial connection to Windows 2k3 server with UPSMon

Now I was strongly considering replacing the bundled no-good upsmoon 
crap, with NUT, in order to enable shutdown of other systems powered the 
same ups, using a NUT master-slave installation.

So, I installed NUT on a XP system (for test) and connected this UPS 
serially. NUT version is the latest for Windows, Beta 2.6.5-4 for Windows.

ups.conf:

[ups1]
driver = blazer_ser
port = com1
offdelay = 240

I can see that the blazer_ser driver is at version 1.55.

So here is where the problems begin, due to the fact that the device 
does not provide a battery.charge indication. Specifically, without 
providing a runtime cal, I get the following data:

battery.charge: 60
battery.voltage: 270.00
battery.voltage.high: 293.69
battery.voltage.low: 234.95
battery.voltage.nominal: 271.1
device.mfr: UPS
device.model: Model 20K
device.type: ups
driver.name: blazer_ser
driver.parameter.pollinterval: 2
driver.parameter.port: com1
driver.version: 2.6.5-3780M
driver.version.internal: 1.55
input.current.nominal: 86.0
input.frequency: 49.9
input.frequency.nominal: 50
input.voltage: 226.0
input.voltage.fault: 0.0
input.voltage.nominal: 230
output.voltage: 230.0
ups.beeper.status: disabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.firmware: Ver  ST1.0
ups.load: 26
ups.mfr: UPS
ups.model: Model 20K
ups.status: OL
ups.temperature: 11.0
ups.type: online

Notice the battery.charge estimation, which is clearly incorrect! 
According to the UPS specs, if no extra cabin is installed runtime is 
"...About 6 min Full loal / 15min Half load". This is for 2 packs. 
Taking into account the 3rd pack which is connected, I increased these 
values by 50%. So I inserted a "runtime = 540,100,1350,50". However, 
doing so produced problematic figures:

battery.charge: 0
battery.runtime: 1
[...]
driver.parameter.runtimecal: 540,100,1350,50

I have tried fiddling with all information, lowering runtime cal to the 
stock values (for 2 strings instead of 3). Nothing...

Then I examined the source code of blazer_ser.c. There might be a 
problem there, although not sure.

By that time I had 2 issues:

1) When runtimecal is not specified, I have a battery.charge value of 60 
instead of 80
2) With runtimecal specified, battery.charge drops to zero.

I have not investigated (2), but I did do some digging regarding one above.

When running with -DDDDD, I get the following:

Network UPS Tools - Megatec/Q1 protocol serial driver 1.55 (2.6.5-3780M)
    0.000000     debug level is '5'
    0.000000     w32_serial_open (com1)
    0.000000     setting initial state on com1
    0.000000     000007D0 = w32_serial_open (com1)
    0.000000     Warning: no locking method is available: No error [? 
????????-?
???????????? ?? ??????-?. ]
    0.000000     vmin_ 0, vtime_ 0
    0.109369     action 0
    0.109369     vtime 0, vmin 1

    0.109369     ReadTotalTimeoutConstant -2, ReadIntervalTimeout -1, 
ReadTotalTi
meoutMultiplier -1
    0.109369     vmin_ 1, vtime_ 0
    0.109369     action 0
    0.109369     vtime 0, vmin -1

    0.109369     ReadTotalTimeoutConstant -2, ReadIntervalTimeout -1, 
ReadTotalTi
meoutMultiplier -1
    0.218737     send_to_all: SETINFO device.type "ups"
    0.218737     send_to_all: SETINFO driver.version "2.6.5-3780M"
    0.218737     send_to_all: SETINFO driver.version.internal "1.55"
    0.218737     send_to_all: SETINFO driver.name "blazer_ser"
    0.218737     Trying megatec protocol...
    0.328106     send: 'Q1'
    0.328106     w32_serial_read : ulen 512, vmin_ -1, vtime_ 0, hEvent 
000007CC
    0.374978     w32_serial_read : characters are available on input buffer
    0.374978     w32_serial_read : Reading 1 characters
    [...]
    0.546844     w32_serial_read : Reading 1 characters
    1.546786     w32_serial_read : total characters read = 47
    1.546786     read: '(229.5 000.0 230.0 023 49.9 2.25 07.0 00000000'
    1.546786     send_to_all: SETINFO input.voltage "229.5"
    1.546786     send_to_all: SETINFO input.voltage.fault "0.0"
    1.546786     send_to_all: SETINFO output.voltage "230.0"
    1.546786     send_to_all: SETINFO ups.load "23"
    1.546786     send_to_all: SETINFO input.frequency "49.9"
    1.546786     send_to_all: SETINFO battery.voltage "2.25"
    1.546786     send_to_all: SETINFO ups.temperature "7.0"
    1.546786     send_to_all: SETINFO ups.beeper.status "disabled"
    1.546786     send_to_all: SETINFO ups.type "online"
    1.546786     send_to_all: SETINFO ups.status "OL"
    1.562410     Status read in 1 tries
    1.562410     Supported UPS detected with megatec protocol
    1.671779     send: 'F'
    1.671779     w32_serial_read : ulen 512, vmin_ -1, vtime_ 0, hEvent 
000007CC
    1.703027     w32_serial_read : characters are available on input buffer
    [...]
    2.781090     w32_serial_read : total characters read = 22
    2.781090     read: '#230.0 086 271.1 50.0'
    2.781090     send_to_all: SETINFO input.voltage.nominal "230"
    2.781090     send_to_all: SETINFO input.current.nominal "86.0"
    2.781090     send_to_all: SETINFO battery.voltage.nominal "271.1"
    2.781090     send_to_all: SETINFO input.frequency.nominal "50"
    2.781090     Ratings read in 1 tries
    2.890459     send: 'I'
    2.890459     w32_serial_read : ulen 512, vmin_ -1, vtime_ 0, hEvent 
000007CC
    2.921707     w32_serial_read : characters are available on input buffer
	[...]
    3.077948     w32_serial_read : Reading 1 characters
    4.077890     w32_serial_read : total characters read = 39
    4.077890     read: '#UPS             Model 20K  Ver  ST1.0'
    4.077890     send_to_all: SETINFO ups.mfr "UPS"
    4.077890     send_to_all: SETINFO ups.model "Model 20K"
    4.077890     send_to_all: SETINFO ups.firmware "Ver  ST1.0"
    4.077890     Vendor information read in 1 tries
    4.077890     No values provided for battery high/low voltages in 
ups.conf

    4.077890     send_to_all: SETINFO battery.voltage.low "234.95"
    4.077890     send_to_all: SETINFO battery.voltage.high "293.69"
    4.077890     Using 'guestimation' (low: 234.953333, high:
293.691667)!
    4.077890     battery runtime exponent : 1.322
    4.077890     battery runtime nominal  : 540.0
    4.077890     send_to_all: SETINFO battery.charge "0"
    4.093514     battery runtime estimate : 0.0
    4.093514     No charge time specified, using built in default [43200 
seconds]

    4.093514     No idle load specified, using built in default [10.0 %]
    4.093514     send_to_all: SETINFO ups.delay.start "180"
    4.093514     send_to_all: SETINFO ups.delay.shutdown "240"
    4.093514     send_to_all: ADDCMD beeper.toggle
    4.093514     send_to_all: ADDCMD load.off
    4.093514     send_to_all: ADDCMD load.on
    4.093514     send_to_all: ADDCMD shutdown.return
    4.093514     send_to_all: ADDCMD shutdown.stayoff
    4.093514     send_to_all: ADDCMD shutdown.stop
    4.093514     send_to_all: ADDCMD test.battery.start
    4.093514     send_to_all: ADDCMD test.battery.start.deep
    4.109138     send_to_all: ADDCMD test.battery.start.quick
    4.109138     send_to_all: ADDCMD test.battery.stop
    4.218507     send: 'Q1'
    4.218507     w32_serial_read : ulen 512, vmin_ -1, vtime_ 0, hEvent 
000007CC
    4.265379     w32_serial_read : characters are available on input buffer
    [...]
    5.437187     w32_serial_read : total characters read = 47
    5.437187     read: '(229.5 000.0 231.0 024 49.9 2.25 07.0 00000000'
    5.437187     send_to_all: SETINFO output.voltage "231.0"
    5.437187     send_to_all: SETINFO ups.load "24"
    5.437187     send_to_all: SETINFO battery.voltage "270.00"
    5.437187     send_to_all: SETINFO battery.runtime "0"
    5.437187     send_to_all: DATAOK
    5.437187     dstate_init: sock \\.\pipe\blazer_ser-ups1 open on fd 1992
    5.437187     send_to_all: SETINFO driver.parameter.pollinterval
"2"
    5.437187     send_to_all: SETINFO device.mfr "UPS"
    5.437187     send_to_all: SETINFO device.model "Model 20K"
    [...]

Now, please bear with me, my C skills are long gone and forgotten, plus 
my understanding of UPS operation is next to non-existent. In any case 
though from above, I see that NUT receives the following info:

    1.546786     send_to_all: SETINFO battery.voltage "2.25"
    [...]
    5.437187     send_to_all: SETINFO battery.voltage "270.00"

I think I found 2 problems, one of them an issue and another a bug.

The issue first. According to the values above, NUT tries to autodetect 
the number of battery packs. LThe battery packs detection code in 
blazer.c is as follows:

static double blazer_packs(const char *ptr, char **endptr)
135{
136	const double packs[] = {
137		120, 100, 80, 60, 48, 36, 30, 24, 18, 12, 8, 6, 4, 3, 2, 1, 0.5, -1
138	};
139
140	const char	*val;
141	int		i;
142
143	val = dstate_getinfo("battery.voltage.nominal");
144
145	batt.volt.nom = strtod(val ? val : ptr, endptr);
146
147	for (i = 0; packs[i] > 0; i++) {
148
149		if (packs[i] * batt.volt.act > 1.2 * batt.volt.nom) {
150			continue;
151		}
152
153		if (packs[i] * batt.volt.act < 0.8 * batt.volt.nom) {
154			upslogx(LOG_INFO, "Can't autodetect number of battery packs 
[%.0f/%.2f]", batt.volt.nom, batt.volt.act);
155			break;
156		}
157
158		batt.packs = packs[i];
159		break;
160	}
161
162	return batt.volt.nom;
163}

Like I said, the VGN has battery strings of 20 batteries each. I would 
then expect for battery.packs to be equal to 120 (20 batteries * 6 
plates per battery). This does not happen. batt.volt.nom is 271.4 and 
the cell has a voltage of 2.25 (see above) so the detection algorithm 
does not succeed when trying "120" as the packs[i] value...

I am not sure whether this is an issue or not. Or, if it is one, if the 
detection algorithm can be improved.

I did however try to override the number of battery packs, by setting 
"override.battery.packs = 120" in ups.conf. Nothing happened. Which 
brings me to the (possible) bug issue: override.battery.packs is not 
used anywhere at all in the blazer driver(s)!

Please contact me if you need more information, I definitely want to 
have this going!

BR,

Michael.-

Michail Pappas wrote:
> Hello all,
 > [...]
> Now, please bear with me, my C skills are long gone and forgotten, plus
> my understanding of UPS operation is next to non-existent. In any case
> though from above, I see that NUT receives the following info:
>
>     1.546786     send_to_all: SETINFO battery.voltage "2.25"
>     [...]
>     5.437187     send_to_all: SETINFO battery.voltage "270.00"
>
> I think I found 2 problems, one of them an issue and another a bug.
>
> The issue first. According to the values above, NUT tries to autodetect
> the number of battery packs. LThe battery packs detection code in
> blazer.c is as follows:
>
> static double blazer_packs(const char *ptr, char **endptr)
> 135{
> 136    const double packs[] = {
> 137        120, 100, 80, 60, 48, 36, 30, 24, 18, 12, 8, 6, 4, 3, 2, 1,
> 0.5, -1
> 138    };
> 139
> 140    const char    *val;
> 141    int        i;
> 142
> 143    val = dstate_getinfo("battery.voltage.nominal");
> 144
> 145    batt.volt.nom = strtod(val ? val : ptr, endptr);
> 146
> 147    for (i = 0; packs[i] > 0; i++) {
> 148
> 149        if (packs[i] * batt.volt.act > 1.2 * batt.volt.nom) {
> 150            continue;
> 151        }
> 152
> 153        if (packs[i] * batt.volt.act < 0.8 * batt.volt.nom) {
> 154            upslogx(LOG_INFO, "Can't autodetect number of
battery
> packs [%.0f/%.2f]", batt.volt.nom, batt.volt.act);
> 155            break;
> 156        }
> 157
> 158        batt.packs = packs[i];
> 159        break;
> 160    }
> 161
> 162    return batt.volt.nom;
> 163}
>
> Like I said, the VGN has battery strings of 20 batteries each. I would
> then expect for battery.packs to be equal to 120 (20 batteries * 6
> plates per battery). This does not happen. batt.volt.nom is 271.4 and
> the cell has a voltage of 2.25 (see above) so the detection algorithm
> does not succeed when trying "120" as the packs[i] value...
>
> I am not sure whether this is an issue or not. Or, if it is one, if the
> detection algorithm can be improved.
Mea culpa, I must have made an error here: batt.packs should be the 
correct number 120, after the snippet above completes! So no 
problem/issue there.

The problem with the miscalc when runtime values are entered have 
something to do with the fact that voltage is calculated to be 270V, 
which is lower than the nominal value of 271.4V, as reported by the UPS...

It feels as though a correction is only possible by adjusting 
override.battery.voltage.nominal. Any ideas as to some decent values I 
could use?

Plus, in which source file is override.battery.voltage.nominal read from?

BR,


Michael.-

On Apr 2, 2013, at 7:49 AM, Michail Pappas wrote:
> Plus, in which source file is override.battery.voltage.nominal read from?
The C code which reads "override.*" variables is drivers/main.c

Or did you mean which configuration file? ups.conf:
http://www.networkupstools.org/docs/man/ups.conf.html

Unfortunately, I am not familiar with the rest of the driver - perhaps someone
else can comment on recommended values.

-- 
Charles Lepple
clepple at gmail

On Apr 3, 2013, at 1:05 AM, Michail Pappas wrote:
> Thank you Charles, that is what I was looking for. One more question. Do
you what is the difference between an override.* and a default.* configuration.
Say,  default.battery.voltage.nominal and override.battery.voltage.nominal?
> 
> Although the (for example) blazer man page shows that these directives do
the same thing, in main.c there seems to be some difference:
> 
> 140/* cram var [= <val>] data into storage */
> 141static void storeval(const char *var, char *val)
> 142{
> 143	vartab_t	*tmp, *last;
> 144
> 145	if (!strncasecmp(var, "override.", 9)) {
> 146		dstate_setinfo(var+9, "%s", val);
> 147		dstate_setflags(var+9, ST_FLAG_IMMUTABLE);
> 148		return;
> 149	}
> 150
> 151	if (!strncasecmp(var, "default.", 8)) {
> 152		dstate_setinfo(var+8, "%s", val);
> 153		return;
> 154	}
ST_FLAG_IMMUTABLE means that the variable can't be changed later by the
driver or upsrw.
>> Unfortunately, I am not familiar with the rest of the driver - perhaps
someone else can comment on recommended values.
> 
> I also hope so :)

Remember to keep the list CC'd :-)

-- 
Charles Lepple
clepple at gmail