# Do you always need to clock out the old pixels when reading from a camera?

I'm writing a program to work with a TSL1401R-LF Linescan Module. It works by reading in a 1 X 128 array of pixels. I've gotten the camera to work properly and my readPixels() method is able to read in the pixels accurately.

However, I'm forced to run a timming() method prior to my readPixels() method or else the program fails. The timming() pretty much does exactly the same thing as the readPixels() method except it doesn't store the outputted values. When I comment it out and only use readPixels() my image becomes saturated and I only get values of 1023 even when a dark object is in the way of the cameras.

This might make more sense when looking at the actual code:

void timming()
{

digitalWriteFast(SI, HIGH);
delayMicroseconds(10);
digitalWriteFast(CLK, HIGH);
delayMicroseconds(10);
digitalWriteFast(SI, LOW);
delayMicroseconds(10);
digitalWriteFast(CLK, LOW);
delayMicroseconds(10);

for(int i = 0; i < 129; i++)
{
digitalWriteFast(CLK, HIGH);
delayMicroseconds(delayTime);
digitalWriteFast(CLK, LOW);
delayMicroseconds(delayTime);
}

}

{
digitalWriteFast(SI, HIGH);
delayMicroseconds(10);
digitalWriteFast(CLK, HIGH);
delayMicroseconds(10);
digitalWriteFast(SI, LOW);
delayMicroseconds(10);
digitalWriteFast(CLK, LOW);
delayMicroseconds(10);

for(int i = 0; i < 128; i++)
{
digitalWriteFast(CLK, HIGH);
delayMicroseconds(delayTime);
digitalWriteFast(CLK, LOW);
delayMicroseconds(delayTime);
}

digitalWriteFast(CLK, HIGH);
delayMicroseconds(delayTime);
digitalWriteFast(CLK, LOW);
delayMicroseconds(delayTime);

delayMicroseconds(20);
}


TL;DR

Basically what I'm asking if there is a way to get my program to work without having to use the timming() method.

• Add the datasheet link again. There are other ways : some cameras have a shutter pulse; lengthen or shorten it according to light condition, to avoid saturating your pixels. But I don't know if your sensor does. – Brian Drummond Jul 7 '16 at 21:10
• I've added it, the explanation on integration time is on pages 8 and 9. That's where I was told to do the clocking of n+1 pixels on startup. – sgmm Jul 7 '16 at 21:14
• As far as I can see, it's not about clocking out the old pixels but controlling the integration time. The "simple" interface comes at a cost : you have to jump through hoops to control the whole thing through only 2 pins. There are better ways than loop/digitalWrite but they would normally involve special purpose hardware or an FPGA. If you're stuck with an Arduino you can still control the integration time by adjusting delayTime separately for the first 18 cycles (reset) and remainder(integration). Or clock them as fast as you can, then wait an appropriate time before the next frame. – Brian Drummond Jul 7 '16 at 21:43
• @BrianDrummond that's what I thought at first too, but reducing the integration time is supposed to make the pixels darker since the sensor has less time to charge. I know this because as I made delayTime smaller I got lower and lower values. So if the timming() method is just their to increase the integration time then I shouldn't be getting saturated value. Right? Sorry if I'm not getting it, this is my first timer working with a camera. – sgmm Jul 7 '16 at 21:50
• The timing() method is there to DECREASE the integration time. Else the pixels have been integrating and integrating and integrating and integrating and integrating for however long since the last time you did a readPixels(). – Richard Crowley Jul 7 '16 at 21:56

• But isn't their a way to stop the integration time at the end of the readPixels() so that the values don't become saturated? Also do you know what the datasheet is talking about when it says that the integration time ends at the HOLD positive pulse. – sgmm Jul 8 '16 at 14:33
• Couldn't you just send an impulse to the SI at the end of the readPixels() method? – sgmm Jul 11 '16 at 16:41