On May 22, 2014, at 10:03 AM, Stefan Bruda wrote: >> >> 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. > > Yes, as it appear as 48V in the output of upsc.
Good. > >> 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. > > I am game, but what would a more appropriate value be? I am new to > the intricacies of reverse engineering Tripp Lite UPSes so I don't > really know how to proceed... ;-) I am not even terribly familiar > with the properties of lead-acid batteries (such as the variance of > the internal resistance and the such). Sorry, I wasn't clear. I meant to say that the voltage value read from the UPS is a voltage scaled to match a single 12V battery, and that there is a multiplier in the "V" response which determines the battery_voltage_nominal value. See attached. Still doesn't have the writable V_interval values, but I probably won't have time to test that until later. Don't worry about the battery physical properties for now - the problem there is that we don't have enough information from the UPS to do a proper calculation. With the V_interval[] settings, you can tweak the new state-of-charge calculation to match what you see via upsc when the battery is fully charged, so that's better than nothing. > It should apply, but somebody more familiar with the thing should > verify the code. For instance is this only applicable to tl_model == > TRIPP_LITE_SMARTPRO (as in my code)? How about tl_model == > TRIPP_LITE_SMART_0004? This one supposedly also responds to a "D" > message with (again supposedly) the same kind of response, but maybe > s_value[5] is better in this case. In my patch I simply did not care > about it and I would not know whether to care or not since I don't > have access to this kind of UPS. Any modification would be a matter > of wild guesses for me (though I am not sure whether others have better > foundations for their guesses either ;-) ). > > I believe that the other type is left in the dark anyway when it comes > to the battery charge (so this code will at least not do any harm for > TRIPP_LITE_SMART_0004), but I might be wrong (I did not cover more > than 10% of the code really). I think we can strike a balance between trying to improve the TRIPP_LITE_SMARTPRO case, without intentionally breaking TRIPP_LITE_SMART_0004. If someone with a Protocol 0004 unit steps up to help with testing, we can try and fix that case then. Here, s_value[5] seems to be an ASCII digit: http://lists.alioth.debian.org/pipermail/nut-upsuser/2009-June/005154.html >> 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. > > From what I see in the code V_interval[] is hard coded rather than > being read from the UPS. Oh, I see, you mean that various users will > set this to whatever works for their UPS, right? Yes, I believe this > to be a very good idea, so that people can effectively modify the > parameters without recompiling the code. Yes, the latter case: although fully draining a lead-acid battery isn't recommended too often, one could conceivably log the battery.voltage values while the UPS drains the battery to the LB threshold (we'll call that 10%), then get the fully-charged voltage, and use those for the V_interval settings. Re-reading the comments, the "Tripp Lite source" refers to an old open-source package from Tripp Lite which decodes the values from their serial UPSes. It had a table of voltage-to-charge values, and the dv/dq calculation was an interpolation of those values. >> 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. > > Well, I seem to recall that it is mentioned in the documentation that > the value is not to be trusted (I am not sure whether it is this value > or overall the output of the driver which is labelled as > experimental). The granularity of having an "experimental" flag for the entire driver isn't optimal, but maintaining even more detailed information is tough, as well. Hence, the recommendation to test everything. > I have been running NUT for several years with this > UPS without caring about that value -- as long as a battery critical > event turned my machines off I was happy. :-) The reason I started > investigating this is that I wanted to see whether the mentioned > external battery pack is taken into consideration by the UPS and I > discovered that I have no means of seeing if it is so. > > This all being said, I cannot vouch whether my code is useful or not > -- please keep in mind that I only have one UPS to play with so the > result is not necessarily portable. Same here: as far as Tripp Lite hardware, I only have an old OMNIVS1000, which is apparently different than an OmniVS1000 (!) that has a different USB ProductID, and talks to usbhid-ups. This is where the "no warranty" clause of the GPL kicks in :-) >> 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 have commented out the line and upsc seems to behave as before. I > have not performed any other test but this should be enough to show > that the line is not useful, right? I think so. I'll try to add a fall-back option to re-enable that if necessary, but I believe the OS X kernel is already setting this, and the UPS does not react well to setting it a second time. > In case it matters by the way this is all happening on a box running > kernel version 3.12.13 with Gentoo patches. The NUT I am playing with > is the stock Gentoo unstable variety, meaning version 2.7.1 with some > Gentoo patching on top. Thanks, that is a useful data point. Does Gentoo have an easy way (short of installing the whole OS) to see what those patches are? I assume they are kept in a version control repository, but I don't know enough of the portage-related vocabulary to quickly search for that. Gentoo would be a good addition to the NUT Buildbot, but the build farm hardware is somewhat memory-constrained at the moment. -- Charles Lepple clepple@gmail
tripplite_usb_battery_charge.patch
Description: Binary data
_______________________________________________ Nut-upsuser mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
