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 at
Thu Jun 3 01:58:32 AEST 2021

On 6/2/2021 08:39, Ed Tanous wrote:
> On Tue, Jun 1, 2021 at 8:43 AM Bruce Mitchell
> <bruce.mitchell at> 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.

More information about the openbmc mailing list