microbuilder opened a new issue #1296: Issues with `sensor_color_data` in `sensor/color.h` URL: https://github.com/apache/mynewt-core/issues/1296 Using the [existing TCS34725 driver](https://github.com/apache/mynewt-core/tree/master/hw/drivers/sensors/tcs34725) to evaluate light levels (lux) and color temperature (kelvin), I've spotted a few issues with the existing implementation of `sensor_color_data` in the generic [sensor API](https://github.com/apache/mynewt-core/tree/master/hw/sensor). The current `sensor_color_data` struct is highly dependant on the internals of the TCS34725 and probably not generic enough to be useful with other color sensors, and also has overly narrow types in some cases. ## Current Implementation Issues 1. `r`, `g`, `b`, and `c` data are present, but `uint16_t` might not be an ideal scale here. Two standard alternatives are: - `uint8_t` for hex style colors (#RRGGBB), 8-bit per channel with 'c' potentially useful as alpha. - `float` with a range of 0...1.0 which provides for an extremely wide color range at the expense of 3 extra bytes, but this would offer a more professionally useful range and is easily standardised with any sensor. (This would be my preference since it can be converted to 8-bit easily, but is the more expensive option of the two.) 2. `uint16_t` is too small for`scd_lux`, since this can easily extend beyond 65535 lux, and `float` would be a better choice since there is a wide range of values <1.0 for low light that are relevant (down several decimal places). 3. RGBC data is present, but what about other types of 'color' sensors like [AS7262 6-Channel](https://www.adafruit.com/product/3779) light sensor, which measures 450, 500, 550, 570, 600, and 650nm wavelengths (red, orange, yellow, green, blue, and violet)? Measuring specific wavelength ranges is common for agriculture, for example (photosynthesis measurements), and it's worth considering solutions to return color data in specific wavelength ranges (basic spectrometry, etc.) - Should there be a new sensor data type, or can we extend 'sensor_color_data' to be more flexible here??? 4. Some of the very vendor-specific fields here should perhaps be moved up to the driver level, rather than existing in the generic sensor API? https://github.com/apache/mynewt-core/blob/master/hw/sensor/include/sensor/color.h#L32 I appreciate all the work of course that went into the sensor API, I'm just trying to highlight some of the issues I'm running into using the existing driver in the real world, and thinking about how I can possible implement a driver for the AS7262 ([datasheet](https://www.mouser.com/ds/2/588/AS7262_DS000486_2-00-1082195.pdf)) which currently won't fit in the existing design, but represent a common use case for light and color sensors (specific wavelength measurements outside generic RGB). I'm happy to help on this, but I was hoping to get some discussion started first and hear other opinions on what 'color' sensor data should constitute.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
