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

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

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.