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