Sensor readings as 1-byte
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.
>
> I still had some concerns, can you please help with the following,
>
> 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
> be really helpful.
>
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
> readings
> (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
> reading command.
>
> We see in the ipmitool example on how an example of
> 3.36 V is
> represented as 1-byte.
> https://computercheese.blogspot.com/2013/10/ipmi-sensor-reading-conversion-formula.html?q=sensor
> <https://computercheese.blogspot.com/2013/10/ipmi-sensor-reading-conversion-formula.html?q=sensor>
>
> <https://computercheese.blogspot.com/2013/10/ipmi-sensor-reading-conversion-formula.html?q=sensor
> <https://computercheese.blogspot.com/2013/10/ipmi-sensor-reading-conversion-formula.html?q=sensor>>
>
> Can any one please help on how the values for M, B, k1
> 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
> sensorReadingType: 0x01
> *multiplierM*: 511
> *offsetB*: 0
> *bExp*: 0
> mutability: Mutability::Write|Mutability::Read
> serviceInterface: org.freedesktop.DBus.Properties
> readingType: readingData
> 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
>
>
More information about the openbmc
mailing list