Sensor value calculation formula

[Emily Shaffer]

Tyler,

Sorry that I forgot. Yes, the scale is hardcoded for certain sensor types,
ie voltage is always millivolts. I have asked about this before but maybe
someone else on the list can give a better answer why that's the case.

Emily

On Wed, Mar 6, 2019, 9:19 PM Deng Tyler <tyler.sabdon at gmail.com> wrote:

> Hi Emily, thank for your kindly reply. I understood how it wok now. But I
> still have a question, which customized file can assign scale value to
> Dbus? It seems always equal -3.
>
> Tyler
>
> Emily Shaffer <emilyshaffer at google.com> 於 2019年3月7日 週四 上午11:46寫道：
>
>> Tyler,
>>
>> In the example you cited, ideally that DBus entry reads Value: 4986;
>> Unit: Volts; Scale: -3.
>>
>>
>> https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Sensor/Value.interface.yaml
>>
>> This essentially means the DBus entry is expressing 4986 millivolts,
>> or 4986*10^-3 volts.
>>
>> On Wed, Mar 6, 2019 at 7:39 PM Deng Tyler <tyler.sabdon at gmail.com> wrote:
>> >
>> > Hi Emily, thank for your reply and you are really help me a lot. I use
>> "GAIN_in1=5.0" in configuration file convert 2100 to 10500. Now Dbus store
>> value is 10500 and it mean 10.5V in ipmitool end. But I still have some
>> doubt about " DBus should be holding the value in units". There is a
>> example in openbmc sensor document as below:
>> > ====
>> > so for a DBus sensor value of 4986 meaning 4.986V, phosphor-ipmi-host
>> would encode it as
>> >
>> > x: 4986 / 20 = 249
>> > M: 20
>> > rExp: -3
>> >
>> > When ipmitool sensor list is called, the tool fetches sensor factors
>> and computes value as:
>> >
>> > y = 20 * 249 * 10^-3 = 4.98 (V)
>> >
>> > ====
>> > In above description, Dbus store value is 4986 but it is not real value
>> in unit. If user switch to REST or redfish for getting sensor then 4986
>> will be display in same time. Is it correct?
>> >
>> > Tyler
>> >
>> > Emily Shaffer <emilyshaffer at google.com> 於 2019年3月7日 週四 上午10:02寫道：
>> >>
>> >> It sounds like you may want to convert, on your sensor end, so that
>> >> you are expressing 12.0V in DBus. DBus should be holding the value in
>> >> units, rather than a raw sensor value. The alternative here would be
>> >> for you to put some context-aware conversion into host-ipmid or into
>> >> your handler on top of ipmitool, and that's not something anybody
>> >> wants :)  Later if you decide to switch to Redfish, you will have the
>> >> same problem, due to your value in DBus being a raw reading instead of
>> >> something in units.
>> >>
>> >> Is it possible for you to modify your code where the value is being
>> >> pushed to DBus?
>> >>
>> >> On Wed, Mar 6, 2019 at 5:54 PM Deng Tyler <tyler.sabdon at gmail.com>
>> wrote:
>> >> >
>> >> > Hi Emily, thank for your kindly reply. This is not typo. I want to
>> dispaly 12.0V in ipmitool and my raw data in Dbus is 2100.
>> >> > I know value x length is 1 byte. I concern that why raw data
>> calculate with M, rExp before response to ipmitool.
>> >> >
>> >> > Tyler
>> >> >
>> >> > Emily Shaffer <emilyshaffer at google.com> 於 2019年3月7日 週四 上午6:47寫道：
>> >> >>
>> >> >> Hi Tyler,Is this a typo? Do you mean you want to display 21.0 in
>> >> >> ipmitool? I don't know why there is scaling besides power of 10 on
>> >> >> your raw value. That is odd.Assuming it was a typo, what you want to
>> >> >> do is set the scale in the sensor info in order to perform /100
>> >> >> operation. Or you could set the unit, though that might be difficult
>> >> >> with a /100 (rather than increment of 1000).The scaling with m,
>> rExp,
>> >> >> etc is because the IPMI protocol has such a narrow field for sensor
>> >> >> data (1 byte, as you saw; this is value x).So my recommendation to
>> you
>> >> >> is to use the scale to do your 2100->21.0 rounding when displaying
>> >> >> output from ipmitool; and then to use your estimated maximum and
>> >> >> minimum y to try and figure out what kind of coefficients you want
>> to
>> >> >> use.  This doesn't need to be perfect; you will lose some precision
>> if
>> >> >> you choose exponents which give you a much wider range than you
>> need,
>> >> >> but otherwise the operation should be invisible at the other end.If
>> >> >> you really did mean you want 2100 -> 12.0 then that's a different
>> >> >> question, which may require some more massaging on one end or
>> another,
>> >> >> so let us know.
>> >> >>
>> >> >> Emily
>> >> >>
>> >> >> On Wed, Mar 6, 2019 at 5:33 AM Deng Tyler <tyler.sabdon at gmail.com>
>> wrote:
>> >> >> >
>> >> >> > Hi all:
>> >> >> >     Sensor reading, according to IPMI spec, is calculated as:
>> >> >> >
>> >> >> > y = L[(Mx + B * 10^(bExp)) * 10^(rExp)]
>> >> >> >
>> >> >> > y: the 'final value' as reported by IPMItool
>> >> >> > x: 8 bits, unsigned, reading data encoded in IPMI response packet
>> >> >> > M: 10 bits, signed integer multiplier, multiplierM in YAML
>> >> >> > B: 10 bits, signed additive offset, offsetB in YAML
>> >> >> > bExp: 4 bits, signed, bExp in YAML
>> >> >> > rExp: 4 bits, signed, rExp in YAML
>> >> >> >
>> >> >> >  ipmid calculate raw data by
>> >> >> > double value = variant_ns::get<T>(propValue) * std::pow(10,
>> sensorInfo.scale - sensorInfo.exponentR);
>> >> >> > auto rawData = static_cast<uint8_t>((value -
>> sensorInfo.scaledOffset) / sensorInfo.coefficientM);sue
>> >> >> >
>> >> >> > I am confused about why process raw data with M and rExp? M,
>> offsetB, bExp and rExp shall just responded to ipmitool and calculate with
>> raw
>> >> >> > data. I thought raw data only need calculated by scale if raw
>> data need to be adjust before respond to ipmitool.
>> >> >> > Now I met a problem, I have a raw data is 2100 and I want to
>> display 12.0 in ipmitool sdr command. I don't know how to assign M, rExp
>> and scale value in yaml.
>> >> >> > Could some one tell me how to translate sensor value? tks.
>> >> >> >
>> >> >> > Tyler
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Emily Shaffer
>> >>
>> >>
>> >>
>> >> --
>> >> Emily Shaffer
>>
>>
>>
>> --
>> Emily Shaffer
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20190306/e63e04b5/attachment.htm>