Shop OBEX P1 Docs P2 Docs Learn Events
Why are there 3 bytes when sampling with an LED on? — Parallax Forums

Why are there 3 bytes when sampling with an LED on?

captainvipcaptainvip Posts: 5
edited 2011-05-22 12:30 in Accessories
Hi,
I am using the colorpal to detect color reflected back. A couple of questions after reading the documentation and implementing it with an MSP430:

1. What is the range of its color sensing capabilities?
2. When do we use Low Sensitivity and High Sensitivity?
3. Why are the bytes outputted from sensing with a color on (lets say RED) 3-digit hexes?
4. How can I take ambient light into consideration?

Thanks and any help will be greatly appreciated,
Vipin

Comments

  • kwinnkwinn Posts: 8,697
    edited 2011-05-22 09:35
    captainvip wrote: »
    Hi,
    I am using the colorpal to detect color reflected back. A couple of questions after reading the documentation and implementing it with an MSP430:

    1. What is the range of its color sensing capabilities?
    2. When do we use Low Sensitivity and High Sensitivity?
    3. Why are the bytes outputted from sensing with a color on (lets say RED) 3-digit hexes?
    4. How can I take ambient light into consideration?

    Thanks and any help will be greatly appreciated,
    Vipin

    1 - Look at the graph on page 2 of the PDF. The sensor range is approximately 400 to 980 nM
    2 - Page 10 top paragraph "for low-ambient conditions with external color illumination"
    3 - Not sure what you mean. The output is 8 bits as 2 hex digits per color so 6 hex digits for rgb
    4 - By following the calibration procedure ambient light is measured and can then be subtracted from the measurements.
  • captainvipcaptainvip Posts: 5
    edited 2011-05-22 10:41
    Hi Kwinn,
    Thanks for your reply. So I am guessing that the sensor has to be basically next to the object to detect the light? What i meant by the 3 Hex digits was that when we use the "m" command, it returns me 9 bytes which the document then says shold be read as 3 HEX digits, so for example, if it returns the following bytes,

    0x30,0x42,0x46 0x30,0x41,0x34 0x30,0x31,0x32

    According to the documentation, I would decode it as by using the ASCII Table:
    0x0BF 0x0A4 0x012

    Therefore the net result of my sample would be,
    0xBFA412.

    Now what is the point of the first byte which is usually 0x30(an ASCII '0'), i mean why even bother sending it. The reason I am concerned is because occasionally when the light reflected back is of high intensity, the first byte becomes 0x31/0x32.

    Thanks,
    Vipin
  • kwinnkwinn Posts: 8,697
    edited 2011-05-22 11:18
    if it returns the following bytes,

    0x30,0x42,0x46 0x30,0x41,0x34 0x30,0x31,0x32

    According to the documentation, I would decode it as by using the ASCII Table:
    0x0BF 0x0A4 0x012

    Therefore the net result of my sample would be,
    0xBFA412.

    That's correct. Converted to decimal that would be rgb intesities of 191,164, and 18 respectively.
    Now what is the point of the first byte which is usually 0x30(an ASCII '0'), i mean why even bother sending it. The reason I am concerned is because occasionally when the light reflected back is of high intensity, the first byte becomes 0x31/0x32.

    I could not find any reference to that first byte in the data sheet but it makes sense that that is a status byte. Any intensity over 0x0FF would indicate an intensity above the maximum range. Since the adc used in the ColorPAL is 10 bits it is most likely using the 2 msb's for that hex digit. In other words if that digit is not 0 the light intensity is too high and the reading invalid.
  • captainvipcaptainvip Posts: 5
    edited 2011-05-22 11:47
    Thanks KWinn. The issue has been resolved! :-)
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-05-22 11:48
    Kwinn is right, as the ColorPAL document explains on page 9: the results are returned as ten bits of data in three hex digits. You can normalize the results to eight bits, if you like, by incorporating the white- and black-balance readings for each RGB component, and using this formula:
    adjusted := (reading - black) * 255 / (white - black) #> 0 <# 255

    -Phil
  • captainvipcaptainvip Posts: 5
    edited 2011-05-22 12:19
    Thanks for all the help. Now am I correct in assuming that the sensor will not detect the color of something 1 feet away in normal ambient conditions?

    Vip
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-05-22 12:30
    Now am I correct in assuming that the sensor will not detect the color of something 1 feet away in normal ambient conditions?
    Yes, that's a correct assumption. To do that, you would need something like the TCS3200-DB, a longer focal-length lens to narrow the acceptance angle, and a bright, controlled illumination source. Ambient lighting -- especially if it's time-varying -- cannot be depended upon for accurate color determination. That said, however, crude discrimination between, say, red and green may still be possible with the '3200 and ambient lighting, although I have not tried it.

    -Phil
Sign In or Register to comment.