Re: ROHM BM1390 support

[Matti Vaittinen <mazziesaccount@gmail.com>]

Hi dee Ho - and a big "Thank you" :)

On 6/4/23 16:28, Jonathan Cameron wrote:
> On Tue, 30 May 2023 11:20:59 +0300
> Matti Vaittinen <mazziesaccount@gmail.com> wrote:
> 
>> Hi dee Ho peeps,
>>
>> Once again I am trying to learn from more experienced sensor folks :)
> 
> (Someone get Matti some nice simple devices to add support for - he needs
> a rest!) :)

I don't really mind technical challenges :) But what I would really like 
to have in our company - and what I do really appreciate getting from 
you - is someone who I can discuss with to clarify these things :)

>> I am currently working (also) on ROHM BM1390 pressure sensor. The sensor
>> can measure pressure ranging 300 - 1300 hPa. Measurement times can be
>> around 20 - 160 mS depending on the amount of samples being averaged.
>> There is also an IIR filter included in sensor with 3 different settings
>> titled as "weak", "middle" and "strong". Unfortunately the exact maths
>> is not explained.
> 
> Gah.  We all love this sort of dumbing down in datasheets.
> There is a picture though... Hmm. Anyone remember enough about filter
> design to tell me if you can go from a 63% point on a step response (in time domain)
> to a 3DB in frequency?  I'd go with probably not but it's been far too many years
> since I did any of this so I could be wrong.

I haven't been dealing with this type of maths since my university 
studies - and I think I participated last related courses somewhere 
around 2003 or so. Whoah - I just realized that's 20 years ago! Where 
did the time go? I did send a question about 3DB boundary frequencies to 
the HQ though. I wouldn't bet on it but who knows, maybe I can get the 
actual filter types and the frequencies from there.

> I'd kick this into the long grass - pressure sensors that aren't the type that you
> connect to a pipe tend to be for measuring slow changes, so I'd just set it to
> the middle value and not worry about making it configurable.

I was considering just having the IIR disabled by default, but maybe the 
"middle" setting would indeed be the best way to go.

> Can revisit later.
>   
>> Furthermore, the sensor can be configured to store
>> maximum of 4 measured pressure samples in a HW FIFO.
>>
>> The sensor can also measure temperature and error for temperature
>> measurement is told to be +/- 2C when temperature is in a range of 25 C
>> - 85 C. On the other hand, operating temperature for the device is said
>> to be -40 C - 85 C.
> 
> Helpful to have a sensor with no defined precision in the range
> in which the device is meant to operate. *sniggers*
> I wonder if it's a typo as the operating range matches the storage range
> which is unusual.

I am not sure. The data-sheet does specifically mentions that the 
temperature value is signed. It sounds like the sensor was really 
designed to be used in negative temperatures (degrees C).

But yes, the error limit spec is indeed ...

Furthermore, the +/-2 C is (IMO) insane unless it means the error is 
"systematic" and can be compensated to some extent after calibration. I 
don't think the +/- 2 means it is "in spec" to have measurements jumping 
up to 4 C in a range of 25 C - 85 C... Well, this is just my thinking 
though.

>> Now, the temperature measurements are not stored in a FIFO.
>>
>> Here comes my question - what do you see as the typical use-cases for
>> such a sensor? Or, to be more exact, do you think "quick" changes in
>> temperature are expected to be measured with this type of sensor?
> 
> My understanding of pressure sensors is a bit weak so the following might
> not be accurate...
> 
> No. Temp stuff on pressure sensors is normally there for temperature compensation
> algorithms.
> 
>> I am
>> asking this because I would like to support using the hardware FIFO and
>> I am wondering if reading the temperature at FIFO flush and populating
>> also the temperature channel values corresponding to all (up to 4)
>> pressure measurements would be the best approach?
>>
>> Other options is to not support using FIFO when temperature is scanned.
> 
> A third is only let the temperature be read from sysfs.  That's fairly common
> in devices like this where the temp sensor isn't expected to be read as often
> as the others and maps to what we can actually control.  (scan_index == -1)

I thought of this as well. It however gets somewhat "hairy" to allow 
direct mode access when buffering is used - and I am not sure how 
convenient it is for users to stop the pressure measurement when 
temperature is measured.

The problem of allowing buffering pressure values when raw-reading 
temperature values comes from the fact that:
a) start/stop for temp/pressure measurement is common and
b) if data-ready IRQ is not used we don't have any information about 
when the temperature measurement is completed. Finally,
c) the sensor must not be accessed when FIFO is read.

I guess all of these a), b), and c) could be worked around - but the 
result might not be completely trivial. Thus, stuffing the temperatures 
in buffer seem simpler for driver and user - although it does waste some 
bytes. Well, since the sensor is not _really_ high speed thing the 
memory consumption should still (probably) stay sane. So, if the 
use-case is not such that temperature changes several degrees / second - 
then I think I will just stuff the temperatures in buffer as well.

> IIRC some of the IMUs do this as again temp not expected to change much, but
> it if has radically different stable values it will affect precision calibration.
> 
>>
>> I have a gut feeling that the users who measure pressure are often also
>> interested in getting the temperatures. Hence I would like to allow
>> getting both. "Cheating" by using the same temperature value (measured
>> when FIFO is flushed) should be Ok if temperature is not changing
>> rapidly as even with the slowest measurement speed collecting 4 samples
>> should finish in well under a second - and mentioned accuracy for the
>> temperature sensor is such that small temperature changes are probably
>> going unnoticed anyways.
> 
> Fifo normally only of interest at high rates anyway, not that it makes much
> practical difference when implementing the driver.
> 
>>
>> Here I would love to have an opinion from more experienced IIO
>> developers/users - and potentially a hint how similar sensors have been
>> handled previously. (I would assume not storing some slowly changing
>> values in a HW FIFO is quite common because HW FIFOs won't come without
>> a cost).
> 
> I don't really mind if you either go with
> 1 - fill it copies of same temperature.
> 2 - only have temp via sysfs (this I know we've done a bunch of times)

So, I'll start with 1 :)

> 
> The mess of switch between fifo and non fifo depending on whether the
> temp sensor is in the scan strikes me as too fiddly to make sense.
> 

Agree!

Thanks once again Jonathan, You're really helpful!

Yours,
	-- Matti

-- 
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~