Problem with lego color sensor 2.0

[xavierjean02]

Hello,
I'm currently trying to write a low level driver in Ada for the lego RGB color sensor 2.0. I saw the communication protocol in Lejos (and in the open source firmware) code and I wrote the corresponding code of the initialization sequence in Ada. As far as I understood the initialization procedure is :
- reset
- send sensor mode
- read calibration values

To reset you set and reset the clock every miliseconds twice, and you wait 100 ms.
To send sensor mode you send the corresponding byte (between 13 and 17) whith the least significant bit first.
To read calibration values you receive bytes containing calibration data from the sensor, you compute a CRC and you compare it with the received CRC.

My problem comes when I read those bytes : when I put my finger on the sensor I receive 0x00, when I remove it, I receive 0xff. It's troubling because it seems that the sensor already works and sends absurd values. When I force the data pin in analog mode I only read 0. The RGB led is always off (even if I send a mode such as COLOR_RED). When in the initialization is it supposed to be turned on ?

Lego color sensor doesn't seem to need 9V alimentation, so I left the default 5V alimentation.

Has anyone got the same problem ?
Thanks by advance

Xavier

[gloomyandy]

When you send the mode data are you also toggling the clock line? You also need to keep the clock and data lines stable for a short period. The easiest way to debug this would probably be to attach a scope to the cable between the NXT and the sensor and run either the standard firmware or leJOS then run your code and compare the two. That is pretty much what I did when I wrote the leJOS driver...

[xavierjean02]

When you send the mode data are you also toggling the clock line? You also need to keep the clock and data lines stable for a short period. The easiest way to debug this would probably be to attach a scope to the cable between the NXT and the sensor and run either the standard firmware or leJOS then run your code and compare the two. That is pretty much what I did when I wrote the leJOS driver...

Yes I do, and the stable period in both your code and the standard firmware is 30us, I tried also longer and shorter periods without any success...
I'm gonna try with a scope

Thanks
Xavier

[xavierjean02]

I couldn't have access to a scope with memory so I couldn't see what I sending. But as usual I could see I was sending things (I have up and down levels on clock and data lines, so I suppose I'm talking to the sensor ).

In the standard firmware It seems that the clock line is pull-up whereas the data line is pull-down. But in your driver both are pull-down. Do you think it's a problem ? (I presume it's not, but...).

Do you think that the sensor expects precise stable time (exactly 30 us) or that we can give stable data and clock for a longer time (for example 1 ms) ?

Xavier

[gloomyandy]

Hi,
I don't have a memory scope either but I was able to see the pulse train by setting a trigger hold off/delay and using a single trigger. I'm not sure what you mean by the clock line is pull up though can you explain?

[xavierjean02]

Hi

In fact my question on pull up/down was stupid because at every moment in the initialization procedure you control the clock (you set it manually to 0 or 1). So there is never any floating value, and no need for pull up/down...
I'll try your trick with the scope maybe tomorrow.

Thank you very much !
Xavier

[xavierjean02]

Hi,
Finally I found the solution. It was mainly a problem in the timer configuration.
Now the driver is independant from any timer. There's still a lot of things to do to make the driver clean, but I hope we will publish a release soon, with other drivers in ada/ravenscar.
Thanks for your advices (and for the driver's source in Lejos )
Xavier