(r8) TCS3200 < IoT_Course

Tags: view all tags
---+ TCS3200 Color Sensor
---++ Introduction

The TCS3200 color sensor comes on PCBs with slightly different layout:

| <img alt="d546fed5-1ee1-4daf-9233-1a845b81fe2d.jpg" height="600" src="%ATTACHURL%/d546fed5-1ee1-4daf-9233-1a845b81fe2d.jpg" title="d546fed5-1ee1-4daf-9233-1a845b81fe2d.jpg" width="600" /> | <img alt="ColorSensorTCS3200-600x600-3829067542.png" height="600" src="%ATTACHURL%/ColorSensorTCS3200-600x600-3829067542.png" title="ColorSensorTCS3200-600x600-3829067542.png" width="600" /> |
The main difference between these modules is that one of them pulls out the TCS3200 OE (Output Enable) line, while the other one does not.

The TCS3200 uses an array of 64 photo cells, where 16 of the cells are equipped with a red, green or blue filter respectively, while the remaining 16 cells have no filter at all.

<img alt="th-954080829.jpeg" height="160" src="%ATTACHURL%/th-954080829.jpeg" title="th-954080829.jpeg" width="486" />

The control signals S2 and S3 allow selecting cells with a particular filter:

| *S2* | *S3* | *filter color* |
| 0 | 0 |  red  |
|  1  | 0 |  clear  |
| 0 |  1  |  blue  |
|  1  |  1  |  green  |
The color intensity measured is converted into a frequency, which is output on the OUT line, if the output enable is active (which for the module on the left is always the case).

<img alt="tcs3200Block.png" height="285" src="%ATTACHURL%/tcs3200Block.png" title="tcs3200Block.png" width="790" />

The output frequency is passed through a frequency divider which scales down the frequency output on the OUT line as follows
| S0 | S1 | frequency scaling |
| 0 | 0 |  power down, sleep mode  |
| 0 |  1  |  2 %  |
|  1  | 0 |  20%  |
|  1  |  1  |  100%  |
This means that with a setting of 2% the frequency is divided by a factor 50.

The LED control line allows switching the illumination LEDs on and off.
---++ Cabling

The following table shows the cabling of the TCS3200 (the model on the left photo)
| *TCS3200* | *!WeMos bus* | *GPIO* |
| S0 | D3 | 17* |
| S1 | D4 | 16* |
| S2 | D8 | 05 |
| S3 | D5 | 18 |
| OUT | D6 | 19 |
| LED | D7 | 23 |
| OE | put to GND on the module | |
| Vcc | 3.3V | |
| GND | GND | |
* GPIO 16 and 17 cannot be used on the !LilyG0 T7 V1.4. Because of this, S0 can be jumpered to GND and S1 to +3.3V via a 5K resistor, resulting in fixed frequency scaling of 2%.
---++ Understanding the module and developing a driver for it

The software is available on github: https://github.com/uraich/TCS3200-MicroPython
---++++ First steps

A driver in !MicroPython is usually implemented as a Python class. The object creation method !__init__ initializes the chip. In case of the TCS3200, the GPIO lines used to control
   * the filters (S2 and S3)
   * the frequency divider (S0 and S1) if used
   * the output enable (if available)
   * the LEDs
must be initialized with their respective pins numbers as output signals, and the OUT pin must be initialized as input with internal pull-up.

To have a first preliminary check, we can implement, kin addition to the !__init__ method, a method that switches the LEDs on and off. I prefer to also have a debug method allowing me to switch debugging messages on and off.

This is implemented in the *led.py* program. Another short !MicroPython program: *switchOffLeds.py* is provided to switch the LEDs off. This can be run on the ESP32 from the command line using the shell script *switchOffLeds*. Make sure that execute permission is given for the script.

To ease development, the driver and the application using it, are combined in the same file. Once the driver is sufficiently tested, these two parts will be separated in two distinct files. The driver will be uploaded to the /lib folder on the ESP32 to make it permanently accessible.

In Python there are no public and private variables. There is however a convention that variables whose names start with the '_' character to be considered private.

Very often, classes have variables that are accessed through getter and setter functions. These can be implemented with the decorators:
   * !@property
   * !@prop_setter, where prop is the name of the property to be set
---++++ Towards reading the frequency of the OUT signal

In order to better understand the TCS3200 it is necessary to get a feeling for the frequencies it emits. To measure this frequency, we must be able to set the filter and the frequency divider. This is done in the program *filter_and_freq.py*. The test program sets debugging mode, and it writes and reads back the filter and frequency divider settings.
---++++ Reading the raw signal

The outSignal.py application sets up the filter to <i>clear </i>and the frequency divider to 2%. After this, it reads out the raw signal with the method<i> testOut. </i>This method sets up an empty data list named _values_, and it then polls the OUT line during 100 ms at a sampling frequency of 10 kHz (a sample every 100 us). The data acquired are saved in <i>values </i>and returned by the _testOut_ method. <i>outSignal </i>finally prints out the result. The <i>testOut </i>method has been implemented for test only and is not strictly necessary. However, it gives a visual impression of the signal to be treated and is therefore interesting for a better understanding.

You can save these values to a file on the PC with

ampy run outSignal.py &gt; resultData.txt

and finally, plot the with gnuplot.

Here are the plots when a black and when a white paper is placed in front of the sensor. You clearly see the much higher output frequency for a white paper.

The black paper:

<img alt="black.png" height="607" src="%ATTACHURL%/black.png" title="black.png" width="1306" />

The white paper
---++++ <img alt="white.png" height="670" src="%ATTACHURL%/white.png" title="white.png" width="1326" />
---++++ Measuring the frequency

In order to measure the frequency, the time elapsed for the detection of a number of OUT signal cycles is measured. The number of cycles to be used is set in the _cycles variable. Of course, we again need getter and setter methods to control _cycles. We attach an interrupt handler to the OUT pin (_cbfwhich stands for _callback function)_. The number of cycles, already measured, is saved in the _cycle (without the "s"). This value is set to zero when the interrupt handler is started (connected to _cbf). When the first rising edge of the signal is seen, the current system clock in us is saved in _start_tick. For each rising edge of the OUT signal, _cycle is incremented until the value In _cycles is reached, in which case the system clock is saved in _end_tick. The duration between the start of the measurement and the moment the number of requested cycles has been seen is then

duration =_end_tick - _start_tick

and the frequency in Hz is 1000000 * _cycles / duration. The factor 1000000 comes from the fact that the duration is measured in us while the frequency is calculated in Hz.

This program is implemented in *meas_freq.py.*

It shows that for clear filters, the frequency divider set to 2% and a white target, I measure a frequency of 2.349 kHz. When using a black target, the frequency drops to 380 Hz.

<img alt="freq_result.png" height="355" src="%ATTACHURL%/freq_result.png" title="freq_result.png" width="621" />

This teaches us an important lesson: The time between two rising edges for the white target is just 435 us. If we change the frequency divider to 20% this time would be reduced to 43 us, which is simply too short an interval for our interrupt handler. The program can handle a 20% frequency divider setting for the black target, in which case the interval is 263 us (1000000/3800), but it will crash for the white target because it will receive new interrupts while the old ones have not been entirely treated.

If we want to read the OUT signal at full speed, then an external high speed counter is needed. Otherwise, we can fix the S0 and S1 signals to 0 and 1 respectively and therefore fix the frequency divider to 2%. This liberates 2 GPIO lines for other purposes.
---++++ Timeouts

There is still a problem with the *meas_freq.py* program.<br />The code:

<verbatim>    while tcs3200._end_tick == 0:
        time.sleep_ms(10)</verbatim>

will wait forever, if the number of cycles to be measured, is never reached. This can happen e.g. if the OUT signal is assigned a wrong GPIO pin. The problem can be solved by starting a timeout counter when the measurement is started. This counter can be used to raise an exception if reaching the _cycles limit takes too long.

<b>timeout.py </b>is the same program as <b>meas_freq.py </b>with the timeout counter added. The timeout is set to 2s. The number of cycles to be measured is set to 10000 in order to provoke the timeout.
---++++ Calibration

The formula for the calculation of rgb values is given by:

component = max * (Fv - Fb) / (Fw - Fb) where the variables have the following meaning:
   * component: value of the color component measured
   * max: maximum value the color component can reach. For many color representations, this is 0xff or 255
   * Fv: frequency measured for the color component
   * Fb: frequency measured for a black target
   * Fw: frequency measured for a white target
This means that we must measure the frequencies of each color component for a black and a white target. This is done in *calibration.py*.
---++++ Detecting colors

Once the calibration is done, we have all the tools needed to measure rgb values. We must use the methods that were used to measure the frequencies for black and white targets for the measurement of colored targets. The rgb values are calculated with the formula shown in the calibration section.

In order to check the validity of the measurements, we can display the rgb values on the WS2812 LED ring. The rgb.py test program does exactly this. Place a colored target in front of the TCS3200 and the same color will be displayed on the WS2812 LED ring.
---++++ The driver

Finally, the application can be separated from the driver part and stored in a file named tcs3200.py. This file must be copied to the ESP32 (I use its lib directory).

from tcs3200 import TCS3200

imports the class with all its methods and its class variables. Now we can re-write all our test programs as short applications, making use of the driver. This essentially means to just copy the main part of the test programs into separate files. You find the driver on the github repository in the folder name driver.
---++ Comments

%COMMENT%
Attachments
Topic attachments
I	Attachment	History	Action	Size	Date	Who
jpeg	Color-sensor-1-2639300876.jpeg	r1	manage	33.0 K	2022-05-16 - 12:21	UliRaich
png	ColorSensorTCS3200-600x600-3829067542.png	r1	manage	467.7 K	2022-05-16 - 12:21	UliRaich
png	black.png	r1	manage	46.3 K	2022-06-28 - 15:37	UliRaich
jpg	d546fed5-1ee1-4daf-9233-1a845b81fe2d.jpg	r1	manage	24.6 K	2022-05-16 - 12:28	UliRaich
png	freq_result.png	r1	manage	45.0 K	2022-05-16 - 15:12	UliRaich
png	tcs3200Block.png	r1	manage	29.0 K	2022-05-16 - 12:47	UliRaich
jpeg	th-1275146919.jpeg	r1	manage	6.1 K	2022-05-16 - 12:17	UliRaich
jpeg	th-1714714185.jpeg	r1	manage	5.3 K	2022-05-16 - 12:17	UliRaich
jpeg	th-954080829.jpeg	r1	manage	10.1 K	2022-05-16 - 12:17	UliRaich
png	white.png	r1	manage	90.1 K	2022-06-28 - 15:37	UliRaich
Topic revision: r8 - 2022-06-28 - UliRaich