All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: Sensor readings as 1-byte
@ 2018-04-13  2:41 guhan balasubramanian
  2018-04-13 15:41 ` James Feist
  0 siblings, 1 reply; 6+ messages in thread
From: guhan balasubramanian @ 2018-04-13  2:41 UTC (permalink / raw)
  To: Tom Joseph; +Cc: openbmc

[-- Attachment #1: Type: text/plain, Size: 2735 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 6780 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Sensor readings as 1-byte
  2018-04-13  2:41 Sensor readings as 1-byte guhan balasubramanian
@ 2018-04-13 15:41 ` James Feist
  2018-04-20  1:30   ` guhan balasubramanian
  0 siblings, 1 reply; 6+ messages in thread
From: James Feist @ 2018-04-13 15:41 UTC (permalink / raw)
  To: guhan balasubramanian, Tom Joseph; +Cc: openbmc

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/

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@linux.vnet.ibm.com 
> <mailto:tomjose@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>
>>
>>     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
> 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Sensor readings as 1-byte
  2018-04-13 15:41 ` James Feist
@ 2018-04-20  1:30   ` guhan balasubramanian
  2018-04-20 18:19     ` James Feist
  0 siblings, 1 reply; 6+ messages in thread
From: guhan balasubramanian @ 2018-04-20  1:30 UTC (permalink / raw)
  To: James Feist; +Cc: Tom Joseph, openbmc

[-- Attachment #1: Type: text/plain, Size: 4379 bytes --]

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?

2. Any reference document/spec for this algorithm, if available, would be
really helpful.

Thanks,
Guhan

On Fri, Apr 13, 2018 at 8:41 AM, James Feist <james.feist@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/
>
> 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@linux.vnet.ibm.com
>> <mailto:tomjose@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>
>>>
>>>     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
>>
>>

[-- Attachment #2: Type: text/html, Size: 6126 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Sensor readings as 1-byte
  2018-04-20  1:30   ` guhan balasubramanian
@ 2018-04-20 18:19     ` James Feist
  0 siblings, 0 replies; 6+ messages in thread
From: James Feist @ 2018-04-20 18:19 UTC (permalink / raw)
  To: guhan balasubramanian; +Cc: openbmc

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@linux.intel.com <mailto:james.feist@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@linux.vnet.ibm.com <mailto:tomjose@linux.vnet.ibm.com>
>         <mailto:tomjose@linux.vnet.ibm.com
>         <mailto:tomjose@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
> 
> 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Sensor readings as 1-byte
  2018-03-10  2:31 guhan balasubramanian
@ 2018-03-10 17:45 ` Tom Joseph
  0 siblings, 0 replies; 6+ messages in thread
From: Tom Joseph @ 2018-03-10 17:45 UTC (permalink / raw)
  To: guhan balasubramanian, openbmc

[-- Attachment #1: Type: text/plain, Size: 1804 bytes --]

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.

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


[-- Attachment #2: Type: text/html, Size: 4524 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Sensor readings as 1-byte
@ 2018-03-10  2:31 guhan balasubramanian
  2018-03-10 17:45 ` Tom Joseph
  0 siblings, 1 reply; 6+ messages in thread
From: guhan balasubramanian @ 2018-03-10  2:31 UTC (permalink / raw)
  To: openbmc

[-- Attachment #1: Type: text/plain, Size: 1159 bytes --]

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

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

[-- Attachment #2: Type: text/html, Size: 2826 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2018-04-20 18:19 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-04-13  2:41 Sensor readings as 1-byte guhan balasubramanian
2018-04-13 15:41 ` James Feist
2018-04-20  1:30   ` guhan balasubramanian
2018-04-20 18:19     ` James Feist
  -- strict thread matches above, loose matches on Subject: below --
2018-03-10  2:31 guhan balasubramanian
2018-03-10 17:45 ` Tom Joseph

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.