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

[Ed Tanous <edtanous@google.com>]

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

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

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