Seeking your opinion on ways to report both Altitude and Pressure sensors for the DPS310 as well as Temperature from dbus-sensors.
bruce.mitchell at linux.vnet.ibm.com
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 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.
More information about the openbmc