Shop OBEX P1 Docs P2 Docs Learn Events
Using the TSL1401 with an Arduino/Teensy — Parallax Forums

Using the TSL1401 with an Arduino/Teensy

We have a TSL1401 Linescan Camera and are trying to use it with a Teensy/Arduino. The problem is that our bootleg setup makes it very difficult to diagnose our problem. We have wired the A0 to pin 0, Vdd to 3.3V, GRND to GRND, CLK to pin 2, SI to pin 3, +5V to Vin.

We seem to be getting weird values when we try running code we found on the internet, and we are unable to tell whether our wiring, code, or camera are the problem. We are not seeing any visible change when we change what the camera sees.

Code we tried:
Codebase 1
Codebase 2

Here is an example of our output (we are only having it print out some of the center pixels)
YuWu0GC.png

Is there anything we can use to test the camera to make sure it is working properly?

Comments

  • In case you read this Phil, we messaged you on another account, but we are unable to login to see if you replied (We get a message about permission issues).
  • Here's the text of my message:

    First, please understand that I'm not a C programmer. However, a couple things come to mind:

    1. If you're printing from a byte array, you should not be getting values like 283, 290, etc. So something odd is happening in your printout routine.

    2. You have to realize that just calling the capture routine will not get you the current pixel values. What it gives you are the pixel values integrated over the time since the last call to the capture routine. IOW, you have to call the capture routine twice, separated by the desired integration time. It's usually best to keep calling the capture routine at regular intervals to keep the optical sensors from becoming saturated.

    From your description of the wiring, it sounds right, although you do not need to connect +5V, just Vcc, which can be anywhere between 3.3V and 5V.

    -Phil
  • Hey Phil,
    We didn't screen shot the correct code. However, still are getting seemingly random numbers between zero to 90 when we hold the camera in pitch darkness. Also, we have our capture routine running a loop with a delay between each capture for about 10 milliseconds.
    Our current output (we took out the +5V)
    LugXWcv.png
    -forwardsockficus
  • What is the elapsed time between SI pulses?

    -Phil
  • We have a 10 ms delay between reads (which is 10.000 usec).
  • We have a 10 ms delay between reads (which is 10.000 usec).
    That's not the integration time, though. You also have to include the time it takes to perform a read. IOW, the SI-to-SI time is the integration time.

    -Phil
  • forwardsockficusforwardsockficus Posts: 10
    edited 2018-05-12 04:07
    We are having trouble getting it to work, and we do not know enough about how it works to determine what we are doing wrong. Here is a rough outline of what we have gathered from reading and tried:

    - Send a pulse to the SI pin
    - Delay 8333 uSec for exposure
    - Analog read out the values from A0 with CLK pulses

    We also tried:

    - Send pulse to SI
    - Read out to clear garbage with CLK pulses
    - Wait 8333 uSec
    - Send pulse to SI
    - Read out actual values with CLK pulses

    If you could briefly describe the protocol we should be following to communicate with the camera we think that would be helpful. We don't know PBASIC, so we are having trouble translating the example code to work with the Teensy.

    Thanks Phil
  • Your readout takes a certain amount of time. This time is added to the time between readouts to make up the total integration time. What I need to know is the total time between SI pulses. That's what determines the integration time. If it's too long, the sensor's dark current will become a dominant factor when the lens is blocked from incoming light.

    -{hil
  • forwardsockficusforwardsockficus Posts: 10
    edited 2018-05-12 04:54
    We were getting between 9993-10000 uSec

    The delay time is printed on the left in microseconds.
    MvJxRbm.png

    Sorry about all the questions, thanks for being so helpful.

    - forwardsockficus
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2018-05-12 17:44
    How many bits of resolution does your ADC have? What kind of response do you get if you shine a light onto the array?

    -Phil
  • We weren't seeing a change in the values when we shined a light on it or covered the lens to make it dark. How do we know/check how many bits of resolution our ADC has?
  • These are the specs for the controller we are using, I am not sure if this answers your question though.

    xc115Fq.png
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2018-05-13 23:07
    How do we know/check how many bits of resolution our ADC has?
    It'll be in the specs for the ADC. If the ADC is built into the micro you're using, the specs will be part of the micro's datasheet.

    Are you sure that the array you're printing out is the same array that the ADC is filling from the TSL1401? Without seeing your entire program, it's kinda hard for me to tell what's going on.

    Also, do you have an oscilloscope? If you do, take a look at the AO pin on the TSL1401. Use SI as the trigger. That will at least tell you if you're getting output from the imager.

    -Phil
  • I put the specs in the reply above, and I think it says that there 16 bits of resolution for analog input and 13 usable bits. I am fairly sure it is the same array. I do not have access to an oscilloscope right now, but I might be able to get my hands on one in a couple days.
  • If you have 16 bits of resolution, you're reading more than a byte's worth of data for each pixel. Are you saving that data into a byte array? If so, which eight bits of the 16 are you saving?

    -Phil
  • Oh ok, I think this might be getting close to our problem. We were not aware of how resolution might affect us. It looks like the code we were following was using analogRead(a0) which is 10 bit resolution and then divides that by 4 and stores the remaining number into a byte. So that would mean it is discarding the rightmost 2 bits.
Sign In or Register to comment.