Re: Sensor result representation.

Davidoaia, Bogdan M <bogdan.m.davidoaia@...>

Hi Marcus,

As you pointed out, there is no fixed rule for sensor value type. The reason for the flexibility is that each driver computes values using their own formula, so it may be more convenient to use a certain type.

We didn't want to use double everywhere, because floating point operations come with a cost. However some sensors, such as the Grove temperature sensor uses logarithm to compute values, so doubles are needed.

I'm reluctant to enforce a fixed type to be returned by the drivers, as this may result in some conversions and loss of precision if apps require types different from the default.

As a compromise, the sensor API could offer a function for converting a generic sensor_value struct to a specific value type. This way, the app can decide what type it wants to use, without having to write the code for converting between value types.

What are your thoughts on such an approach?


-----Original Message-----
From: Marcus Shawcroft [mailto:marcus.shawcroft(a)]
Sent: Friday, November 25, 2016 4:10 PM
To: devel(a)
Subject: [devel] Sensor result representation.


The sensor.h public API provides a mechanism for a sensor drivers to publish results in one of four different formats:


There is no guidance (that I could find) on which data format a driver should return for any given sensor channel. This flexibility in the API has been exploited to a degree, looking at just temperature sensors in the current tree we have:

dht, bmg160,tmp007,tmp112, hp206chts221dsc1009, bma280, mpu6050, mcp9808, lis3mdl, sht3xd, bmi160, bme280 all returning temperature values formatted as INT_PLUS_MICRO.


lsm6ds0, lps25hb, th02, lsm9ds0 all returning temperature values formatted as DOUBLE.

Having different drivers return data for the same channel type in different formats implies that every application written to consume such data needs some kind of demuxing code or, more likely, it will be built to work against a specific flavour of driver... either way this situation is not ideal.

Is there a reason we have designed in this degree of flexibility?

If not then perhaps for each channel type in sensor.h we should define the data format returned by all drivers supporting that channel type?

I raise this issue now while there are relatively few drivers, because tighting API behaviour now is going to be significantly easier in the short term than it will be in the medium / long term when we have more drivers and more divergence in behaviour.


Join to automatically receive all group messages.