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

[Bruce Mitchell <bruce.mitchell@linux.vnet.ibm.com>]

On 6/2/2021 11:52, Guenter Roeck wrote:
> Hi,
> 
> On Wed, Jun 2, 2021 at 11:18 AM Bruce Mitchell
> <bruce.mitchell@linux.vnet.ibm.com> wrote:
>>
>> Forwarded to an expanded the To and Cc Lists.
>>
>> On 6/2/2021 09:21, Ed Tanous wrote:
>>> On Wed, Jun 2, 2021 at 9:14 AM Bruce Mitchell
>>> <bruce.mitchell@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@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@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.
>>>>
>>
> 
> Again, I am obviously missing the entire discussion leading to this point, so
> my response may just be noise. If so, my apologies. Anyway, here is my $0.02:
> 
> Altitude can not be measured on its own with a sensor. It can, for example. be
> estimated from air pressure (maybe taking other information or sensors into
> account), or it can be provided (calculated) using GPS. Therefore, "altitude"
> measurements don't belong into the kernel but need to be calculated in user
> space from information which may or may not be provided by the kernel.
> How to do that is outside the scope of kernel development.
> 
> A kernel driver for DPS310 should report pressure and temperature data,
> not anything else that may be derived from it.
> 
> Thanks,
> Guenter
> 

You are correct Guenter, we are not talking kernel space here.
But the user land "driver" dbus-sensors with entity-manager as well this 
is all part of OpenBMC which is built on OpenEmbedded and Yocto.

I believe Ed and I are in agreement with "A kernel driver for DPS310 
should report pressure and temperature data, not anything else that may 
be derived from it."

Thank you for you validation of our conclusion; much appreciated.
(It is far easier when build something for the first time to get done 
correctly.)


-- 
Bruce