Using the TSL1401 with an Arduino/Teensy

forwardsockficus

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)


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

forwardsockficus

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).

Phil Pilgrim (PhiPi)

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

forwardsockficus

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)

-forwardsockficus

Phil Pilgrim (PhiPi)

What is the elapsed time between SI pulses?

-Phil

forwardsockficus

We have a 10 ms delay between reads (which is 10.000 usec).

Phil Pilgrim (PhiPi)

forwardsockficus wrote:

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

forwardsockficus

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

Phil Pilgrim (PhiPi)

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

forwardsockficus

We were getting between 9993-10000 uSec

The delay time is printed on the left in microseconds.


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

- forwardsockficus

Phil Pilgrim (PhiPi)

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

forwardsockficus

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?

forwardsockficus

These are the specs for the controller we are using, I am not sure if this answers your question though.

Phil Pilgrim (PhiPi)

forwardsockficus wrote:

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

forwardsockficus

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.

Phil Pilgrim (PhiPi)

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

forwardsockficus

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.