Closed fredlcore closed 3 years ago
Maybe I should rephrase my question: Is it possible to continuously query the color sensor? The callback function on the one hand moslty seems to be called only when there is a change of color, but there are exceptions where the same color is reported back to the callback function. To use some kind of hysteresis, it would be good if one could query the color register every x milliseconds and then decide if the color has been read steadily enough. So is there a way to force read the color sensor?
Hi @fredlcore. Thanks for reporting that issues. Maybe i used the wrong Mode for detecting the color sensor values. The available Modes are described in the following documentation : https://github.com/sharpbrick/docs/blob/master/devices/duplotrainbasecolorsensor.md
The modes for which the different hardware devices are currently hard coded in the following function: https://github.com/corneliusmunz/legoino/blob/434b74fe6717640a9d054ef7533d68c764e33a5d/src/Lpf2Hub.cpp#L627
For the DUPLO_TRAIN_BASE_COLOR_SENSOR
i use no specific mode assignment which means, that i use the standard Mode 0
which is the COLOR
mode. Maybe we should use here better the Mode 1
which is the ColorTag
mode. Maybe you can add the following line in your code and do some test again:
case (byte)DeviceType::DUPLO_TRAIN_BASE_COLOR_SENSOR:
return 0x01;
Regarding the option to continuously query the color sensor: This is maybe possible but in my point of view not so optimal. But it should be possible. I will try to test it
Thanks, @corneliusmunz! It works! At first I was disappointed because it didn't recognize any color changes, but it seems to be that the train has to be moving (before I was just holding the tile over the sensor). Now there is no jittery and then I also don't need to query the sensor. Thanks a lot!
@fredlcore Many thanks for testing it! I will change the Mode in the next version of the library
Thanks!
I have not been able to emulate satisfactingly the behavior of my Duplo train when it comes to playing sounds based on the color tiles. The color scanner not only sends the color when driving over a tile, but now also reacts to any changes in the floor texture where the tracks are being laid out. For example, we have a wooden floor and this is often detected as "yellow" and therefore activates the "horn" sound. This does not happen when the train is running on its own.
I assume that there must be some kind of delay of some sort that needs to be addressed programmatically. Maybe this is not something that could/should be done directly in your library, but since this is the first go-to point and others might have this issue as well, it would be a good place to present a solution, I think.