Seeking your opinion on ways to report both Altitude and Pressure sensors for the DPS310 as well as Temperature from dbus-sensors.

[Bruce Mitchell]

On 6/2/2021 09:34, Bruce Mitchell wrote:
> On 6/2/2021 09:21, Ed Tanous wrote:
>> On Wed, Jun 2, 2021 at 9:14 AM Bruce Mitchell
>> <bruce.mitchell at linux.vnet.ibm.com> wrote:
>>>
>>> On 6/2/2021 09:03, Ed Tanous wrote:
>>>> On Wed, Jun 2, 2021 at 8:58 AM Bruce Mitchell
>>>> <bruce.mitchell at linux.vnet.ibm.com> wrote:
>>>>>
>>>>> On 6/2/2021 08:39, Ed Tanous wrote:
>>>>>> On Tue, Jun 1, 2021 at 8:43 AM Bruce Mitchell
>>>>>> <bruce.mitchell at linux.vnet.ibm.com> wrote:
>>>>>>>
>>>>>>> Hello Ed,
>>>>>>>
>>>>>>> It has been suggest I seeking your opinion on ways to report both
>>>>>>> Altitude and Pressure sensors for the DPS310 as well as 
>>>>>>> Temperature from
>>>>>>> dbus-sensors before going to far down the road.  Thus that is 
>>>>>>> what I am
>>>>>>> attempting to do in the email, others on the mailing list input is
>>>>>>> desirable as well.
>>>>>>
>>>>>> Thanks for discussing this before getting too far along.  I haven't
>>>>>> worked on any systems with physical pressure sensors, but I'm excited
>>>>>> to see new things get added.
>>>>>>
>>>>>>>
>>>>>>> As I see it, Altitude and Pressure are different in that
>>>>>>>         1) Altitude is computed base off of essentially a policy
>>>>>>
>>>>>> I have no idea what this means.....   In what way is altitude a
>>>>>> "policy"?  Can you elaborate a little?
>>>>>>
>>>>>
>>>>> I view a mechanism is something like update a FLASH part with
>>>>> an image provided.
>>>>>
>>>>> I view a policy is what decides if the the update of the FLASH part
>>>>> with the specific image is allowed.
>>>>>
>>>>> I the case if Pressure and Temperature I view them as mechanism,
>>>>> merely a simple reading and possibly some well defined computations
>>>>> that are universal.
>>>>>
>>>>> With Altitude computed from Pressure there are several ways to
>>>>> compute the Altitude and they are not universal.  So I see it as
>>>>> a policy of which Pressure to Altitude model is chosen and why.
>>>>
>>>> Sounds like I interpreted your intention correctly. (I think).
>>>
>>> I believe you did.
>>>
>>>>
>>>>>
>>>>>>>         2) Pressures is a read measurement which is a mechanism
>>>>>>>         3) Temperature is a read measurement which is also a 
>>>>>>> mechanism
>>>>>>
>>>>>> I'm really struggling with the above to understand what you're 
>>>>>> getting
>>>>>> after, so if I go down the wrong path, please forgive me.
>>>>>>
>>>>>> I think what you're saying is that altitude is calculated based on
>>>>>> pressure + some transfer function to determine an altitude?  And that
>>>>>> transfer function might be fungible depending on the platform?
>>>>>>
>>>>>> If I got the above right (big if) I would probably expect a new
>>>>>> pressure sensor type to be added that reports a pressure sensor, then
>>>>>> we'd put the transform code in something that looks a lot like CFM
>>>>>> sensor (which oddly enough has a hardcoded 0 for altitude in its
>>>>>> algorithm for systems without pressure sensors).  Considering how
>>>>>> related a pressure sensor is to altitude, I could see putting them in
>>>>>> the same application if you wanted;  It might simplify the code some.
>>>>>>
>>>>>>
>>>>>> I think overall a better picture of what you're wanting to accomplish
>>>>>> would be a good place to start, then we can iterate from there on 
>>>>>> what
>>>>>> pieces we need that are new.
>>>>>
>>>>> I have Temperature, Pressure, possibly Humidity sensors all which are
>>>>> variables to different models to compute Altitude from.  I do not 
>>>>> have a
>>>>> true Altitude sensor.
>>>>
>>>> This sounds exactly like the CFM sensor, and Exit air temp sensor;
>>>> Most systems don't have exit air temp sensors, but they have input
>>>> power and individual fan speeds, which can be put into models to
>>>> determine CFM and ultimately exit air temperature.  I would expect
>>>> Altitude to do something very similar in code (although with a
>>>> completely different algorithm).
>>>>
>>>
>>> So the DPS310 has 2 sensors in it a Pressure and a Temperature sensor.
>>> Do I create a Pressure reading and a Temperature reading for the DPS310
>>> and then add Altitude to it as well?
>>>
>>> Or do I create 3 separate things,  one for each Pressure, Temperature,
>>> and Altitude?
>>
>> Assuming in this case "things" are intended to mean "entity manager
>> exposes records" you would create one config record for the DPS310
>> itself (which would in turn create 2 sensors).  This is one "record"
>> because physically it's one part, and can't be separated, similar to a
>> TMP421.  After that, I would create another config record for the
>> "Here's the math to combine these into an altitude".  It might just be
>> a type and a name, depending on how many inputs go into the transfer
>> function to convert pressure+temperature into an altitude.
>>
>> If the math to combine into an altitude isn't system specific, I could
>> be convinced that the math should go into a single record within the
>> DPS310 exposes and have that live in the daemon itself, but I don't
>> have enough detail on how these are usually deployed to know that.
>>
> 
> I prefer the the 2 record solution, it keeps the DPS310 self-contained.
> And keeps the Altitude self-contained, to the models can evolve and 
> change; also if every a true altitude sensor were created it would help 
> keep better abstraction from the DPS310.
> 
>>>
>>> Also I believe I should be looking to the CFM sensor and Exit air
>>> temperature sensor as reference examples.
>>>
>>>>>
>>>>> I am being asked to provide Altitude.
>>>>>
>>>>> Personally I believe the desired feature is how much cooling a 
>>>>> parcel of
>>>>> air per unit of time.  Thus I would think air Temperature, 
>>>>> Humidity, and
>>>>> Density (probably compute-able from Pressure, but I have not 
>>>>> checked on
>>>>> the specifics) would be the important factors.
>>>
> 
> Thank you Ed!

I would appreciate Gerrit reviews on a small addition for the
Nisqually Backplane entity-manager: Adds support for DPS310 Sensors
https://gerrit.openbmc-project.xyz/c/openbmc/entity-manager/+/43416

This is record 1 of 2, record 1 is a prerequisite for 2.

Getting this merged up stream is preferable to patching
it in downstream.

Thank you.

-- 
Bruce