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.