[Nut-upsuser] Tripp Lite SMART3000RM2U (protocol 3003) running time and charge?

[Charles Lepple]

On May 19, 2014, at 7:12 PM, Stefan Bruda wrote:

> Hello,
> 
> First of all thank you so much for the information.

No problem, glad it is useful.
> [...]
> Therefore as far as my UPS is concerned s_value[5] is wildly
> incorrect.

So it turns out that the RM15002U also does not report anything useful for s_value[5]:

http://lists.alioth.debian.org/pipermail/nut-upsuser/2007-January/002076.html

We really should ask the author of tripplite_usb what he was thinking :-)

> 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 ;

Does battery_voltage_nominal get set correctly? Theoretically, it should be 48, since the 2nd and 3rd digits of ups.debug.V are 08, and that gets multiplied by 6.

Might be useful to have an intermediate value that doesn't scale to actual battery voltage for the charge calculation, since bv seems to be some sort of ratio relative to a 12V battery.

> -
> +               // 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...).

Not much has changed between 2.7.1 and 2.7.2+git, so it might not be that bad.

> 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.

It's going to be a rough estimate for sure, since it depends on the load, plus whatever internal resistance the battery has built up over time.

The UPS self test usually skips a lot of this complication when trying to calibrate for a low battery signal.

> 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).

Agreed.

> 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.

See above, but I think the current code is taking this into account.

> 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.  

Maybe what we do is expose the V_interval[] entries as options in ups.conf (or even upsrw variables), and use those in lieu of s_value[5] if they are set. Given how long this code has been this way, either nobody else has run into this (and s_value[5] has a different meaning) or nobody trusts battery.charge, and your code will be an improvement.

While you're in there, can you check to see if everything still works if you comment out the "usb_set_altinterface(udev, 0)" line from drivers/libusb.c? (You might need to unplug and re-plug the UPS to be certain.) I ran across an old patch which removed that line to make a TrippLite OMNIVS1000 work on OS X, but I'm not sure if that line is needed on other OSes.

-- 
Charles Lepple
clepple at gmail