Question about pressure sensor driver data processing

Question about pressure sensor driver data processing

[Jean-Baptiste Maneyrol]

Hello,

I have a question concerning a pressure sensor driver I am currently writing.

The formula to get the real pressure in Pa for this sensor is quite complex. It depends on the measured temperature and would be far better done in floats rather than in integers.

The formula is too complex to be expressed with only scale and offset factors. And the factors are not fixed since it depends on the temperature.

Would it be acceptable to have a driver than returns the raw data without processing? Meaning data that have no unit and require a processing done in userspace? That would be much more efficient for sure, but it would not output really useful data without the processing.

Or a driver that return an input processed data and a raw data that have no unit and requires the processing? If we can return raw data, we should be able also to add buffer/trigger support to the driver. Otherwise that would be quite tricky to return the processed data in the buffer.

Thanks for your feedback.
JB

Re: Question about pressure sensor driver data processing

[Jonathan Cameron]

On Tue, 18 Feb 2020 15:59:26 +0000
Jean-Baptiste Maneyrol <JManeyrol@invensense.com> wrote:

> Hello,
> 
> I have a question concerning a pressure sensor driver I am currently
> writing.
> 
> The formula to get the real pressure in Pa for this sensor is quite
> complex. It depends on the measured temperature and would be far
> better done in floats rather than in integers.
> 
> The formula is too complex to be expressed with only scale and offset
> factors. And the factors are not fixed since it depends on the
> temperature.
> 
> Would it be acceptable to have a driver than returns the raw data
> without processing? Meaning data that have no unit and require a
> processing done in userspace? That would be much more efficient for
> sure, but it would not output really useful data without the
> processing.

Whilst it isn't nice, we have examples where this is already the case.
The heart rate sensors are similar in that they have very complex
conversions.

It is certainly better than being unable to support the driver at all,
but it does mean you won't ever be able to use it with generic code.

Generic code tends to assume the scale is constant as well, so probably
wouldn't work anyway :)

> 
> Or a driver that return an input processed data and a raw data that
> have no unit and requires the processing? If we can return raw data,
> we should be able also to add buffer/trigger support to the driver.
> Otherwise that would be quite tricky to return the processed data in
> the buffer.

Hmm. It is messy so if you actually expect to add buffered support, then
we will need special code in userspace for this device anyway.
We do have devices that jump through a complex conversion then pack
it into a buffer, but that is also somewhat of a hack.

For now at least, go with the raw output only.  It may be one of those
exceptions where we do support both processed and raw outputs in the
longer term if there is clear need for generic code with this device.

Jonathan
> 
> Thanks for your feedback.
> JB

Re: Question about pressure sensor driver data processing

[Jean-Baptiste Maneyrol]

Hi Jonathan,

I will send first a generic driver returning processed pressure data and raw temperature data and without any buffer/trigger support.
I think this is the most valuable features for this driver.

Afterward, I am interested to add buffer support using hrtimer trigger.

Thanks for your feedback.
JB



From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>

Sent: Wednesday, February 19, 2020 19:38

To: Jean-Baptiste Maneyrol <JManeyrol@invensense.com>

Cc: linux-iio <linux-iio@vger.kernel.org>

Subject: Re: Question about pressure sensor driver data processing

 


 CAUTION: This email originated from outside of the organization. Please make sure the sender is who they say they are and do not click links or open attachments unless you recognize the sender and know the content is safe.



On Tue, 18 Feb 2020 15:59:26 +0000

Jean-Baptiste Maneyrol <JManeyrol@invensense.com> wrote:



> Hello,

> 

> I have a question concerning a pressure sensor driver I am currently

> writing.

> 

> The formula to get the real pressure in Pa for this sensor is quite

> complex. It depends on the measured temperature and would be far

> better done in floats rather than in integers.

> 

> The formula is too complex to be expressed with only scale and offset

> factors. And the factors are not fixed since it depends on the

> temperature.

> 

> Would it be acceptable to have a driver than returns the raw data

> without processing? Meaning data that have no unit and require a

> processing done in userspace? That would be much more efficient for

> sure, but it would not output really useful data without the

> processing.



Whilst it isn't nice, we have examples where this is already the case.

The heart rate sensors are similar in that they have very complex

conversions.



It is certainly better than being unable to support the driver at all,

but it does mean you won't ever be able to use it with generic code.



Generic code tends to assume the scale is constant as well, so probably

wouldn't work anyway :)



> 

> Or a driver that return an input processed data and a raw data that

> have no unit and requires the processing? If we can return raw data,

> we should be able also to add buffer/trigger support to the driver.

> Otherwise that would be quite tricky to return the processed data in

> the buffer.



Hmm. It is messy so if you actually expect to add buffered support, then

we will need special code in userspace for this device anyway.

We do have devices that jump through a complex conversion then pack

it into a buffer, but that is also somewhat of a hack.



For now at least, go with the raw output only.  It may be one of those

exceptions where we do support both processed and raw outputs in the

longer term if there is clear need for generic code with this device.



Jonathan

> 

> Thanks for your feedback.

> JB

Re: Question about pressure sensor driver data processing

[Matt Ranostay]

On Wed, Feb 19, 2020 at 10:38 AM Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:
>
> On Tue, 18 Feb 2020 15:59:26 +0000
> Jean-Baptiste Maneyrol <JManeyrol@invensense.com> wrote:
>
> > Hello,
> >
> > I have a question concerning a pressure sensor driver I am currently
> > writing.
> >
> > The formula to get the real pressure in Pa for this sensor is quite
> > complex. It depends on the measured temperature and would be far
> > better done in floats rather than in integers.
> >
> > The formula is too complex to be expressed with only scale and offset
> > factors. And the factors are not fixed since it depends on the
> > temperature.
> >
> > Would it be acceptable to have a driver than returns the raw data
> > without processing? Meaning data that have no unit and require a
> > processing done in userspace? That would be much more efficient for
> > sure, but it would not output really useful data without the
> > processing.
>
> Whilst it isn't nice, we have examples where this is already the case.
> The heart rate sensors are similar in that they have very complex
> conversions.

Don't forget the chemicals sensors that depend on temperature as well. Although
to be fair most of those take input into the 'sensor hub' to do the
calculations in their
black box.

- Matt

>
> It is certainly better than being unable to support the driver at all,
> but it does mean you won't ever be able to use it with generic code.
>
> Generic code tends to assume the scale is constant as well, so probably
> wouldn't work anyway :)
>
> >
> > Or a driver that return an input processed data and a raw data that
> > have no unit and requires the processing? If we can return raw data,
> > we should be able also to add buffer/trigger support to the driver.
> > Otherwise that would be quite tricky to return the processed data in
> > the buffer.
>
> Hmm. It is messy so if you actually expect to add buffered support, then
> we will need special code in userspace for this device anyway.
> We do have devices that jump through a complex conversion then pack
> it into a buffer, but that is also somewhat of a hack.
>
> For now at least, go with the raw output only.  It may be one of those
> exceptions where we do support both processed and raw outputs in the
> longer term if there is clear need for generic code with this device.
>
> Jonathan
> >
> > Thanks for your feedback.
> > JB
>