-
Notifications
You must be signed in to change notification settings - Fork 19
Description
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)