[Nut-upsuser] Tripp Lite SMART3000RM2U (protocol 3003) running time and charge?
Stefan Bruda
stefan at bruda.ca
Mon May 19 23:12:29 UTC 2014
Hello,
First of all thank you so much for the information.
At 22:43 -0400 on 2014-5-15 Charles Lepple wrote:
>
> On May 15, 2014, at 9:39 PM, Stefan Bruda wrote:
>
> > What bugs be though is that I cannot seem to be able to read the
> > remaining run time on battery. The battery charge is also widely
> > inaccurate (it drops to zero really fast and stays there). I read
> > somewhere that the usb.debug numbers may hold the key to this (at
> > least to the running time that is), but I don't know what to do with
> > them (and I can no longer find that piece of information...).
>
> Here's where the battery.charge variable is calculated:
>
> https://github.com/networkupstools/nut/blob/master/drivers/tripplite_usb.c#L1099
>
> battery_charge = (unsigned)(s_value[5]);
>
> (In that file, the 3003 protocol is denoted by "tl_model == TRIPP_LITE_SMARTPRO".)
>
> Due to the command prefix characters in the protocol, the
> ups.debug.S hex values are actually indexed from 1 as follows:
>
> 1 2 3 4 5 6 7
>
> ups.debug.S: 31 30 30 00 28 30 0d '100..0.'
>
> Hence, your s_value[5] yields 0x28 == 40%.
Thank you. I do not remember the exact number but the battery level
was nowhere near 40% at the time (more like 80%). Furthermore the
above line was obtained while charging; when on battery s_value[5]
falls to 0 almost immediately and stays there.
Therefore as far as my UPS is concerned s_value[5] is wildly
incorrect.
> That said, a lot of information was either observed empirically, or
> taken from this email:
>
> http://lists.alioth.debian.org/pipermail/nut-upsuser/2005-September/000218.html
>
> You will note that neither battery charge nor runtime is listed
> there.
>
> It is possible that a better value for the state-of-chage could be
> calculated, similar to the other protocols:
>
> https://github.com/networkupstools/nut/blob/master/drivers/tripplite_usb.c#L1129
Many thanks for the pointer. I tried something like the above but the
"B" message is not answered (errors are spit by libusb too). However,
I did notice that the battery voltage is available in the 3003
protocol (as a response to the "D" message), so I computed the battery
charge percentage starting from that, along the following line:
------ begin patch ------
--- tripplite_usb.c.original 2014-05-19 16:20:58.251634449 -0400
+++ tripplite_usb.c 2014-05-19 16:53:54.806609602 -0400
@@ -1098,8 +1098,8 @@
- /* This may not be right... */
- if(tl_model == TRIPP_LITE_SMARTPRO) {
- battery_charge = (unsigned)(s_value[5]);
- dstate_setinfo("battery.charge", "%u", battery_charge);
- }
}
@@ -1167,9 +1167,22 @@
hex2d(d_value+1, 2) * input_voltage_scaled / 120);
bv = hex2d(d_value+3, 2) * battery_voltage_nominal / 120.0 ;
-
+ // bv is 48V nominal rather than 12V
+
dstate_setinfo("battery.voltage", "%.2f", bv);
+ if(tl_model == TRIPP_LITE_SMARTPRO) {
+ if (bv / 4 >= V_interval[1])
+ bp = 100;
+ else if (bv / 4 <= V_interval[0])
+ bp = 10;
+ else
+ bp = (int)(100*sqrt((bv / 4 - V_interval[0])
+ / (V_interval[1] - V_interval[0])));
+ dstate_setinfo("battery.charge", "%3d", bp);
+ }
+
/* - * - * - * - * - * - * - * - * - * - * - * - * - * - * - */
ret = send_cmd(m_msg, sizeof(m_msg), m_value, sizeof(m_value));
------ end patch ------
This is against NUT 2.7.1 and so will probably not apply cleanly on
the current latest and greatest. I would not apply it as is anyway
since it is quick and dirty and I am sure that it may be simplified
(the conditional in particular is probably not needed...).
The result seems to be quite a bit off compared with the output of
Poweralert, as follows: 90% Poweralert = 50V = 79% as reported by the
modified NUT. A bit afterward the voltage falls to 49.2V (= 73% in
the modified NUT) but Poweralert still reports 90%. Later still (but
not much later) Poweralert gets down to 80% = 48.4V = 67% as per the
modified NUT. I have not tested anything lower than this.
In related matter:
1. The voltage as read by NUT is precisely the voltage read by
Poweralert. So if the voltage is in direct relationship with the
remaining charge (which it should, however roughly) then all is needed
is some computation to figure it out.
1. The nominal voltage of the battery pack is 48V rather than 12V
(hence the division of bv to 4), but I am assuming that the
relationship between the voltage and the charge still holds (since
these are the same batteries, just that they are connected in series).
2. The UPS I am experimenting on has an external battery pack
connected to it (BP48V24-2U, which contains no less than 8 batteries!)
so overall I seem to have three parallel packs each consisting in four
batteries in series. This may (or may not) be the reason of the
calculations being off.
3. In any case the calculations are nonetheless a way better estimate
than s_value[5].
Please let me know if more information is needed.
I know that everything is largely a guess, but if anybody has any
better idea on how to calculate the remaining capacity I would be more
than happy to hear it and try it out. Any pointer is much
appreciated.
> However, calculating runtime usually requires the UPS to do a
> battery test, and observe the voltage while under load. This unit
> might not be capable of doing that.
Understood. Many thanks.
Best regards,
Stefan
--
If it was so, it might be; and if it were so, it would be; but as it
isn't, it ain't. That's logic. --Lewis Carroll, Through the Looking-Glass
No HTML emails and proprietary attachments please <http://bruda.ca/ascii>
More information about the Nut-upsuser
mailing list