James Feist james.feist at linux.intel.com
Sat Apr 21 04:19:07 AEST 2018

```On 04/19/2018 06:30 PM, guhan balasubramanian wrote:
> Hi James,
>
> Thank you for the reference implementation.
> I see that you are using the GetAttributes function in sensorutils.cpp,
> that accepts the Min and Max value and outputs mValue, bValue, rExp and
> bExp. This is exactly what I was looking for.
>
>
> 1. When I plug in values from Tom's example (in this thread), I don't
> seem to get the expected values for B. When min and max are (-127 ,
> 128), I am getting M=1 and B=-1 (including bSigned) where according to
> Tom's calculation, it is M=1 and B=-127. Am I interpreting the output of
> B correctly?
>
Hi Guhan, in the algorithm in that example, the goal is a best fit
around 0. If you look at byte 21 of the type 1 sdr you can see that you
can specify the number format as unsigned, 1's complement, or 2's
complement. If we want to maximize the number of possible readings for
an 8 bit range of 255 we want to set M such that it is as low as
possible. This is so that the jumps between each 8 bit reading are as
small as possible based on the standard slope equation y = Mx+B. Since
the range of a signed bit using 2's complement is from -128 to 127 it is
shifting the slope equation by 1 (B = -1), and keeping M as 1. Hope this
helps!

> 2. Any reference document/spec for this algorithm, if available, would
>
Sorry, I don't really have a reference document. I just used the
equation in section 36.3 of the IPMI spec:

y = L[(Mx + (B * 10^k1)) * 10^k2]

> Thanks,
> Guhan
>
> On Fri, Apr 13, 2018 at 8:41 AM, James Feist
> <james.feist at linux.intel.com <mailto:james.feist at linux.intel.com>> wrote:
>
>     There is an RFC I posted that calculates the M, B, and exponents from
>     the D-Bus sensor endpoints:
>     https://gerrit.openbmc-project.xyz/#/c/8521/
>     <https://gerrit.openbmc-project.xyz/#/c/8521/>
>
>     We were hoping to roll this into host-ipmi sometime in future.
>
>     Thanks,
>
>     James Feist
>
>     On 04/12/2018 07:41 PM, guhan balasubramanian wrote:
>
>         Hi Tom,
>
>         Thanks for the explanation. But I still see some concerns in
>         this conversion logic.
>
>         For input, we have 4 given parameters as
>               1. Min and Max values of the sensor (y)
>               2. the Min and Max values of the byte value (x - assuming
>         this is always 0 to 255).
>
>         For output, we have 4 paramters to calculate
>               1. multiplierM (M)
>               2. offsetB (B)
>               3. bExp (k1)
>               4. rExp (k2)
>
>         We have two equations to compute 4 variables in this logic.
>
>
>         On Sat, Mar 10, 2018 at 9:45 AM, Tom Joseph
>         <tomjose at linux.vnet.ibm.com <mailto:tomjose at linux.vnet.ibm.com>
>         <mailto:tomjose at linux.vnet.ibm.com
>         <mailto:tomjose at linux.vnet.ibm.com>>> wrote:
>
>              Hello Guhan,
>
>              The updated sensor-example.yaml has the Rexp field as well.
>         These
>              values are  calculated based on the minimum and maximum
>         value of the
>              sensor.
>
>              If a temperature sensor has a range of -127 - +128, means y
>         is -127
>              to +128 and the range of x is 0-255.
>              By substituting x = 0 and y = -127 (k2 is the decimal
>         precision and
>              assume in this case as whole nos) implies Bexp = -127.
>              Similarly substitute x = 255 and y = 128 and M is evaluated
>         as 1.
>
>
>         In the above example, with 2 values [(0, -127) and (255, 128)]
>         for (x,y) we were able to calculate M and B. We are assuming k2
>         as 0 since we are taking only whole numbers for our ranges (y
>         values). But we are still assuming the values for k1 as 0.
>
>
>              Regards,
>              Tom
>
>
>              On Saturday 10 March 2018 08:01 AM, guhan balasubramanian
>         wrote:
>
>                  Hi,
>
>                  According to the IPMI spec, we represent all sensor
>                  (Volt, Temp, Amp, etc.) as 1-byte.
>
>                  Since we represent them as 1-byte, we use a
>             linearization formula
>                  to convert to actual value as follows:
>
>                  y = (M*x + B*10^(k1))*10^(k2)
>
>                  where x is the 1-byte value that is filled in the get
>             sensor
>
>                  We see in the ipmitool example on how an example of
>             3.36 V is
>                  represented as 1-byte.
>
>
>             and k2 are
>                  populated for each sensor?
>
>                  In the openbmc repo, I believe these values are present
>             in the
>                  config.yaml of phosphor-ipmi-sensor-inventory (based on the
>                  following sample).
>
>                  0xF1:
>                    sensorType: 0x01
>                    path: /xyz/openbmc_project/sensors/temperature/temp1
>                  *multiplierM*: 511
>                  *offsetB*: 0
>                  *bExp*: 0
>                    serviceInterface: org.freedesktop.DBus.Properties
>                    interfaces:
>                      xyz.openbmc_project.Sensor.Value:
>                        Value:
>                          Offsets:
>                            0x0:
>                              type: int64_t
>
>
>                  Thanks,
>                  Guhan
>
>         With the given information, do you think there is a generic way
>         (algorithm) where we can compute all the 4 variables M, B, k1
>         and k2?
>
>         Thanks,
>         Guhan
>
>
```