0

My son and I are attempting to connect a TCS230 Color Sensor to an Arduino Nano using the tutorial at TopTechBoy.com (http://www.toptechboy.com/arduino/lesson-15-super-cool-arduino-color-sensor-project/) as guidance.

Everything seems to be working except that the conversion from pulseIn to RGB used on TopTechBoy is expecting a maximum pulse count of 102,400. Instead I am receiving pulseIn readings with a maximum of 2000.

Our Wiring

S0 - GND
S1 - 5V OE - No Connection (Tried GND)
GND - GND
S2 - D8
S3 - D7
OUT - D4
VCC - 5V

Our Code:

int S2 = 8;
int S3 = 7;
int OUT = 4;

void setup() {

Serial.begin(9600);
pinMode (S2, OUTPUT);
pinMode (S3, OUTPUT);
pinMode (OUT, INPUT);

}

void loop() {
  // put your main code here, to run repeatedly:
  int red , green, blue; 

  red = getRed(); 
  Serial.print("Red : "); Serial.println(red); 
  Serial.println("**********************");
  Serial.println();

  blue = getBlue(); 
  Serial.print("Blue : "); Serial.println(blue); 
  Serial.println("**********************");
  Serial.println();

  green = getGreen(); 
  Serial.print("Green : "); Serial.println(green); 
  Serial.println("**********************");
  Serial.println();

  delay(3000);

}


int getRed(void){ return getColor(0, 0, 19000, 24000); }


int getGreen(void){return getColor(1, 1, 13600, 19200);}


int getBlue(void){return getColor (0, 1, 16400, 21600);}


int getColor(int s2Value, int s3Value , int typicalPulseWidth, int maxPulseWidth){

  long divideForScale = typicalPulseWidth / 255 ;

  digitalWrite(S2, s2Value); 
  digitalWrite(S3, s3Value);

  unsigned int pulseWidth = pulseIn(OUT,LOW);

  Serial.print("Pulse Width : "); Serial.println(pulseWidth);

  unsigned int rColor = pulseWidth / divideForScale ; //401.5686274509804
  Serial.print("Response Color - Inverted : "); Serial.println(rColor);

  rColor = 255 - rColor ; 
  Serial.print("Response Color - Final : "); Serial.println(rColor);

  delay(500);

  return rColor ; 

}

The pulses appear correct, just out of scale. Red items produce short Red pulses and so on.

I tried to correct for the shorter pulses by using the Typical Output Frequency (f0) found on page 4 of the data sheet. I'm not sure if this is the right use of this frequency output spec.

http://www.unihedron.com/projects/darksky/tcs230-e33.pdf

Lowering the max possible pulses per second from 100,400 to around 20,000 gave us a little more variation between RGB values, but still the output is nothing like the expected color.

Can anybody offer some insight as to why the TCS230 pulse count is far fewer than the TTB code expects and what can I do to fix either the pulse count or the scale? Kind regards.

Output from Measuring a Blue RFID Keyfob: divideForScale : 74 Pulse Width : 673 Response Color - Inverted : 9 Respponse Color - Final : 246 Red : 246 **********************

divideForScale : 64
Pulse Width : 376
Response Color - Inverted : 5
Respponse Color - Final : 250
Blue : 250
**********************

divideForScale : 53
Pulse Width : 737
Response Color - Inverted : 13
Respponse Color - Final : 242
Green : 242
**********************

migrated from electronics.stackexchange.com Aug 19 '16 at 0:30

This question came from our site for electronics and electrical engineering professionals, students, and enthusiasts.

  • Do you have an oscilloscope? I think the first step is to fully read the technical documentation on the device (your link) and understand the information on the typical frequency at full resolution (which is pretty high.) It's easy to protoboard this device with a power supply and NO Raspberry pi 3 attached. Just hook up some selector switches so you can play with S1 to S4 and see what the scope sees. If you've done that, know it works okay without the Pi, then this is either an interfacing problem (good here) or a software problem (good elsewhere.) – jonk Aug 18 '16 at 21:56
  • No oscilloscope - I've never touched any of this stuff before this summer so please feel free to correct what I may not understand about the datasheet. We tried all of the S0 and S1 setting and it makes sense that 2% resolution would generate the longest pulse so that is what we are using - but even at 2%, pulseIn maxes out at 2000 or so. Why are the pulses so short? Is the 102,400 max pulse width from TTB.com correct? How can I find the correct max pulse width from the datasheet info? – Jordan Reddick Aug 18 '16 at 22:28
1

Connect S0 to 5V to get 100% OUTPUT FREQUENCY SCALING.

Currently, with S0 LOW and S1 HIGH, you get 2% OUTPUT FREQUENCY SCALING. Which would explain the 50 times to low values you get (100% / 2% = 50).

  • I tried increasing the resolution but the pulse width decreases as the resolution increases. S0 - Low and S1 - High for 2% resolution provides the longest pulses. – Jordan Reddick Aug 19 '16 at 16:56
  • I'm not really following, but the fact that you tried different S0, S1 combinations, means this isn't the solution. Maybe someone else knows. Best of luck. – Gerben Aug 19 '16 at 17:54
  • The reading from pulseIn was about 30 - 50 when S0 and S1 were both set to High. Perhaps resolution is not the correct word, but a higher output frequency seems to require a shorter pulse rate. The 2000 reading from pulseIn at 2% is the longest pulse we were able to get back from the unit. – Jordan Reddick Aug 20 '16 at 0:06
0

From the project page (a comment by Marius David) it seems some integer datatypes may not be the same on different platforms. If he is correct, you may be working with a 16 bit pulseWidth while 32 bits are needed.

Try using an unsigned long for the pulseWidth variable.

  • Good idea but no such luck. Issue persisted after changing pulseWidth type to unsigned long – Jordan Reddick Aug 19 '16 at 16:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.