Boost Color and Distance Sensor readings

[treczoks]

The Boost color- and distance sensor arrived, and was immediately put to test.

According to Jorges document, I activated the sensor with

[90:84:2B:05:B1:C6][LE]> char-write-req 0e 0a004101080000000001

So with sensor mode 08 (The 0a004101080000000001), I should get messages like 08 00 45 <PORT> <COLORCODE> <HIGHDISTANCE> ff <LOWDISTANCE>.

and it spewed a lot of messages like

Notification handle = 0x000e value: 08 00 45 01 05 01 ff 02 
Notification handle = 0x000e value: 08 00 45 01 03 01 ff 02 
Notification handle = 0x000e value: 08 00 45 01 05 01 ff 02 
Notification handle = 0x000e value: 08 00 45 01 03 01 ff 02 
Notification handle = 0x000e value: 08 00 45 01 05 01 ff 02 
Notification handle = 0x000e value: 08 00 45 01 05 01 ff 02 
Notification handle = 0x000e value: 08 00 45 01 03 01 ff 02

Looks good, but some things are really off here. According to the BOOSTreveng docu, the distance should be something like "Inch" and "Partial Inch" for the <HIGHDISTANCE> and <LOWDISTANCE> readings. But I get values that don't really match this...

My setup: I have installed the sensor in a dummy train engine, pointing down. My "color tags" are tiles 2x2 on the sleepers, and the distance between the front of the sensor and the sensor and the tile is one plate. Other readings would be a dark bluish grey sleeper with no tiles on it at 2 plates distance, and the floor (light wood) at three plates distance.

Between the sleepers, I get a reading (last four bytes) of 0a 01 ff [08..09] - White (which is OK for the light floor), but one inch and something distance?

On a sleeper, I get 03 04 ff [02..03] - Blue, but four inches? And sometimes I get even color 07, yellow.

On the red tile, I get 09 00 ff 07, on the yellow tile 07 00 ff [09..0a], on the blue tile 03 00 ff [01..02], on the green tile [05|00] 01 ff 02, on the black tile 00 0a ff [01..02], and on the white tile 0a 00 ff 09.

So the colors are good, except for the green, which is a bit shaky, but the supposed distance values make absolutely no sense. I also tried mounting the sensor a bit higher, but the results are similarly off.

Could this be due to the short distance?

At the moment, my project idea does not look that good - I need not only see one color, but read a "string" of different tiles encoding a number, but it seems to be impossible to get a decent reading. Or the values in the notifications mean something entirely different...

Could anybody who has worked with the sensor enlighten me?

[David Lechner]

21 minutes ago, treczoks said:

So with sensor mode 08 (The 0a004101080000000001), I should get messages like 08 00 45 <PORT> <COLORCODE> <HIGHDISTANCE> ff <LOWDISTANCE>.

Try this: 08 00 45 <PORT> <COLOR CODE> <DISTANCE> <LED COLOR> <REFLECTED LIGHT>.

<COLOR CODE> is a value 0 to 10, same as mode 0

<DISTANCE> is a value 0 to 10, same as mode 1; there are no units of measurement here since using IR to measure distance is not that accurate

<LED COLOR> is a value 0 to 10, same as mode 5; this value is write-only, so reading it returns -1; only red/green/blue (9/5/3) are valid values for setting the LED color, anything else will turn off the LED

<REFLECTED LIGHT> is a value 0 to 100, same as mode 3

Basically, this mode (8) looks like a way to read multiple values more efficiently than using each mode individually. Because of this, the color of the LED in this mode is not as "pure" as other modes (and "off" is not completely off) since it is constantly switching modes.

When writing to the sensor using this mode, you still need to specify the 4 data values. Only the 3rd one <LED COLOR> is actually used. The others are ignored (so just set them to 0).

[treczoks]

3 hours ago, David Lechner said:

<DISTANCE> is a value 0 to 10, same as mode 1; there are no units of measurement here since using IR to measure distance is not that accurate

Ah, OK. When they use IR to measure distance, and 10 is the maximum, then reading of 0a for black makes sense.

3 hours ago, David Lechner said:

<LED COLOR> is a value 0 to 10, same as mode 5; this value is write-only, so reading it returns -1; only red/green/blue (9/5/3) are valid values for setting the LED color, anything else will turn off the LED

Do I understand this correctly that the LEDs cycles through R/G/B and the sensor only measures brightness/reflection?

3 hours ago, David Lechner said:

<REFLECTED LIGHT> is a value 0 to 100, same as mode 3

If the LEDs cycle through several different colors, does the reflected light ... well ... reflect the average value?

Looks like I really have to start working on a program instead of dealing with the gatttool shell to provide a bit of filtering.

At the moment I'm not sure if the best way to encode a certain amount of information on the rails is using a set of multicolored tiles and let the LED color-cycle, or use a barcode-like system with only two colors (or maybe a third to indicate a start/attention signal).

[David Lechner]

I think we would need a high-speed camera to guess what the sensor is doing in this mode (to measure how long the LED is on or off and which color). I'm afraid I don't have any better guesses to answer your questions.

Which programming language will you be using?

I think using two colors to encode information would work well. If the color sensor can read 10 colors, this gives you 10 * 9 = 90 combinations. Perhaps a bit fewer if the color sensor has trouble with some colors (in certain lighting conditions) like the EV3 color sensor.

[treczoks]

3 minutes ago, David Lechner said:

Which programming language will you be using?

That question is still open. There is a node.js thing for all those devices by Mr Hobbles that looks good, but I'm not really into these typescript things. I thought about using python for this, but I'm still looking for the right protocol stack. If all else fails, fallback is always c/c++...

Quote

I think using two colors to encode information would work well. If the color sensor can read 10 colors, this gives you 10 * 9 = 90 combinations. Perhaps a bit fewer if the color sensor has trouble with some colors (in certain lighting conditions) like the EV3 color sensor.

I originally thought about getting the four best discernible colors, and let them each represent two bits, so, with a starter code (a fifth color) thrown in for good measure.

With this, I could e.g. easily do 14 bits over one piece of track. Well, I'd be happy with 6 or 8 bits, though. Which should be more than enough for encoding all the track blocks for a layout. One big question is if the sensor is fast enough for a train at a reasonable speed.