Hi Marcus,

After the first set of patches were merged I didn't start on the single value representation, partly because I was waiting to see if there would be any more feedback on the mailing list, and partly because of work related changes and winter holiday.

Since there was no feedback against the change, I will start working on it and hope to have the patch ready by next week.

Sorry if the delay on my part caused any inconveniences,

On Wed, Jan 4, 2017 at 8:09 PM, Marcus Shawcroft <marcus.shawcroft@gmail.com> wrote:
Re-send with updated email address for Bogdan...

On 4 January 2017 at 18:05, Marcus Shawcroft <marcus.shawcroft@gmail.com> wrote:
> On 29 November 2016 at 21:54, Davidoaia, Bogdan M
> <bogdan.m.davidoaia@intel.com> wrote:
> Hi Bodan,
>> If we want to define specific value types for each channel type, then we might as well have the same type for all the channels. As you also pointed out, using double is not really necessary for most drivers and the ones that need it can just return the values converted to _INT_PLUS_MICRO.
>> As such, we could eliminate the type field altogether and have the implicit type _INT_PLUS_MICRO (although this should be done as a separate step, as it will affect the apps that use the type field).
>> If you think this is ok and nobody has an objection to this change, then I can start working on it next Wednesday  as I am currently away with only access to email from time to time.
> Following up on this old thread.  Looking in the current tree we have
> no drivers using SENSOR_VALUE_TYPE_DOUBLE, the sensor.h API does still
> define SENSOR_VALUE_TYPE_DOUBLE and the type field used to distinguish
> the last two remaining value types.
> Is the intention that we continue along the path of moving to a single
> value representation?
> If so, are you intending to present further patches, if not, then I am
> happy to post patches to continue this work.
> Cheers
> /Marcus