Shop OBEX P1 Docs P2 Docs Learn Events
TCS3200-DB Burnt Out? — Parallax Forums

TCS3200-DB Burnt Out?

bkirkbkirk Posts: 37
edited 2011-12-17 16:42 in Accessories
Does anyone have any idea how many readings a TCS3200-DB sensor should be able to take before it will be worn out? Or, alternatively, does anyone know what a warning sign is that the TCS3200-DB is wearing out? I am currently using one, and now all of the sudden its readings have become very inaccurate and it takes one reading about every 1 to 1.5 seconds, whereas before it could take multiple readings in that time frame.

I have not changed the code at all from what it was a few weeks ago, and at that time it was running smoothly (last time I ran it). I am certain it as not been physically damaged either.

Any ideas? Thanks!

Ben

Comments

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-12-15 15:51
    The board should never wear out. There's nothing in the board itself that determines the rate of the readings that it takes. That's solely the under the purview of the program that's controlling it. Which controller are you using it with (MoBo, Backpack, Spinneret, etc.)? What happens if you reload your program? (Please post your program here.)

    -Phil
  • bkirkbkirk Posts: 37
    edited 2011-12-15 16:51
    I reloaded the program and it didn't make a difference. More importantly than the speed, the color readings are not accurate, and this is what makes me think the sensor is burnt out. Do you know if the actual sensor is likely to burn out like that?
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-12-15 17:02
    No, the sensor is not likely to burn out unless subjected to abuse, such as overvoltage, reverse polarity, etc. However, regardless of the relative importance of the speed of the readings compared with their accuracy, the fact that they're taking longer to acquire is indicative of a programming issue. So again, I would request that you please post your program, at which time I'll be happy to take a look at it..

    Thanks,
    -Phil
  • bkirkbkirk Posts: 37
    edited 2011-12-15 17:53
    Can I just e-mail it to you? Thanks.

    Ben
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-12-15 19:50
    Ben,

    It would be preferable to post it here so that everyone can benefit from any solution that results. You don't have to list it in the post itself, if you don't want, but as an attachment to the post. In fact, if it's a long program, it's better to include it as an attachment.

    -Phil
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-12-16 20:53
    I'm a little incapacitated right now, so I hope my brief observation is adequate to solve the problem. Your variable CLEAR is a byte. But you're testing it for values exceeding 255, which it cannot.

    -Phil
  • bkirkbkirk Posts: 37
    edited 2011-12-16 21:48
    Phil,

    That's a good point. This code has the same structure as the one I'm currently using, but I guess the variables are out of date. I checked the actual code I have loaded and it does have CLEAR set as a word. I reduced some of the sample times, because I think the one set for 2500 could possibly produce numbers even too large for word-sized variable space under certain conditions. I'll see if it helps. If you see anything else, let me know. Thanks again!

    Ben
  • bkirkbkirk Posts: 37
    edited 2011-12-17 15:26
    Lowering the sample times appears to have done the trick. I think the largest one might have been producing values greater than 16 bits, so that was probably the issue. Glad I don't need to replace anything! Thanks again Phil.

    Ben
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-12-17 16:42
    Hey Ben,

    'Glad you got it to work!

    -Phil
Sign In or Register to comment.