qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2] hw/sensor: Add lsm303dlhc magnetometer device


From: Kevin Townsend
Subject: Re: [PATCH v2] hw/sensor: Add lsm303dlhc magnetometer device
Date: Mon, 20 Sep 2021 16:22:28 +0200



On Mon, 20 Sept 2021 at 15:52, Peter Maydell <peter.maydell@linaro.org> wrote:
>> Why "lsb" ?
>>
>
> In my head, using LSB seemed more precise since I know exactly what value will
> be set to the registers, and exactly what I will get back when reading versus passing
> in a float that's needs to be conveted as a 'best-fit' scenario in 0.125°C steps?

My question was really, "what does 'lsb' mean here"?  I would usually
assume "least significant bit", but that makes no sense in this context.

Ha, sorry. Least significant bit, yes. It gets used in sensor and IC datasheets all
the time and basically means '1 bit', so if the DS says 0.125°C per LSB it means
that value for 1 bit, or to multiply the integer by the 1 LSB value.

Conversion factors from raw units to standard SI units are almost always
indicated this way, though, such as 'LSB/Gauss', etc.

Well, given that the device specifically changes the value it
shows the guest based on guest-programmable gain settings,
it does seem to me to be more natural to specify the values
in some way that represents the "real world data" that the
sensor is measuring. Ideally we would then if/when we add more
magnetometer implementations have them all use the same units,
for consistency. This is the first magnetometer we have, so this
is where we get to pick the convention.

Sounds reasonable.

We have two options here:

- Gauss (standard SI unit)
- micro Tesla (0.01 Gauss)

They've both widely used; but I think uT might be slightly more common.


> In that case, should I accept floating point inputs, however, or stick to integers?
> When dealing with magnetometers the values can be very small, so it's not the
> same as a temp sensor where we can provide 2300 for 23.00C.

What sort of range and precision requirements are we talking about
here? If we can avoid having to use float that would be nice...

Well, taking the LSM303DLHC as an example, we have 1100 LSB per Gauss
at a range of +/- 1.3 Gauss, so 1 bit is: 0.0009090909091 Gauss.

If we use micro Tesla (uT) we get 11 LSB per uT so the smallest value is
0.09090909091 uT ... which we could represent with something like
1000 = 1.000 uT

That gives us +/- 1.3 G = +/- 130 uT = +/- 130,000, for example.

This would require a 32-bit integer, though, to take into account the full
range of +/-8.1 G (+/- 810 uT) = +/- 810,000.
 
There are devices with a much wider range, like the MLX90393, which can
measure up to +/- 50 mT (50,000 uT), so +/-50,000,000.

That's the largest range I'm aware of personally, with +/- 1-8G (or 100-800 uT)
the most common.

>>
>> > +
>> > +    object_property_add(obj, LSM303DLHC_MSG_PROP_TEMP, "int",
>> > +                lsm303dlhc_mag_get_temperature,
>> > +                lsm303dlhc_mag_set_temperature, NULL, NULL);
>>
>> What units is this in?
>
>
> LSB where 1 LSB = 0.125 C, documented elsewhere, but as per the above
> I can change this to degrees if you can clarify if this should be in float or something
> integere based with a specific scale factor.

Our existing temperature sensors use integer properties whose
value is "temperature in degrees C, units of 0.001 C".
Consistency with that would be best. (We should write these
conventions down somewhere. Not sure where...)

That's similar to what I propose above, based on chosing micro Tesla as the
base unit, and not Gauss, so units of 0.001 uT.

Kevin

reply via email to

[Prev in Thread] Current Thread [Next in Thread]