Color sensor 88007 is returning values > 255 in rgbMode

[dkurok]

I've played arround with the ColorDistanceSensor-implementation from @highstreeto today.
Using the ExampleColorDistanceSensor.cs and have it run a little bit longer in await TestMode(colorDistSensor, colorDistSensor.ModeIndexRgb) for better checking what it returns, I mentioned that it receives red, green and blue values GREATER than 255! (try over a clear white surface for getting fast to it).
The "SharpBrick.PoweredUp.Cli.exe device list" gives this for the RGB-sensor
Mode 6: Name: RGB I, Symbol: RAW, Capability: Input
- DataSet: 3x Int16, TotalFigures: 5, Decimals: 0
Input Mapping: Absolute
Raw Min: 0, Max: 1023
Pct Min: 0, Max: 100 (scaling)
SI Min: 0, Max: 1023 (pass-through)
So the values can be up to 1023! (10 Bit)
But does this make sence?? Wouldn't it be better if the implementation in sharpbrick.poweredUp would "normalize" these values into a range of 0..255 for further working with the RGBV-values in a .NET-manner? Or should it be the library-users responsibility to normalize?
Interesting enough:
You can determine the light that the Hub'S LED shines:
And for this "device list" gives:
Port: 0x32 / 50
- IOTypeId: RgbLight / 0x0017 / 23
Revision: SW: 1.0.0.0, HW: 1.0.0.0
Capabilities: Output
ModeCombinations: []
- Mode 0: Name: COL O, Symbol: , Capability: Output
- DataSet: 1x SByte, TotalFigures: 1, Decimals: 0
Output Mapping: SupportFunctionalMapping20 Discrete
Raw Min: 0, Max: 10
Pct Min: 0, Max: 100 (scaling)
SI Min: 0, Max: 10 (pass-through)
- Mode 1: Name: RGB O, Symbol: , Capability: Output
- DataSet: 3x SByte, TotalFigures: 3, Decimals: 0
Output Mapping: Absolute
Raw Min: 0, Max: 255
Pct Min: 0, Max: 100 (scaling)
SI Min: 0, Max: 255 (pass-through)
So here they restrict it to 0..255 (8 bit)

[tthiery]

Yeah. Duplicate of #126

[tthiery]

Problem is: this scaling is integral part of the LWP. I did not realize at the beginning which led to the unfortunate decision to have input data type == output data type. We will fix this by making the output a double. Decimal might be another choice but has a price on memory.

[tthiery]

This is by the way the trigger for the v4 release in the first place.

[tthiery]

Wow. Sorry. Completely misread this thread. Good question. Well, same answer... We implement first of all LWP and powered up devices. They create a 1024 discrete color spectrum. Do I like it. Nope. Is a helper method maybe useful? Maybe. Will the endpoint use 1024 for the si endpoint? Yes

[tthiery]

Same story for other color sensors btw

[highstreeto]

Yeah, I noticed that behavior too.

I added that in my PR for the docs repo.

[tthiery]

Good First Issue:

Create an extension method which translates the 0-1000 value to a realistic RGB scale from 0-255.