2
\$\begingroup\$

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);
  }

}

void readPixels()  
{
  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);
    pixelsArray1[i]=analogRead(Cam1Aout);
    pixelsArray2[i]=analogRead(Cam2Aout);
    pixelsArray3[i]=analogRead(Cam3Aout);
    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.

Datasheet: http://datasheet.elcodis.com/pdf/58/61/586128/tsl1401r-lf.pdf

\$\endgroup\$
  • 1
    \$\begingroup\$ 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. \$\endgroup\$ – Brian Drummond Jul 7 '16 at 21:10
  • \$\begingroup\$ 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. \$\endgroup\$ – sgmm Jul 7 '16 at 21:14
  • \$\begingroup\$ 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. \$\endgroup\$ – Brian Drummond Jul 7 '16 at 21:43
  • \$\begingroup\$ @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. \$\endgroup\$ – sgmm Jul 7 '16 at 21:50
  • \$\begingroup\$ 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(). \$\endgroup\$ – Richard Crowley Jul 7 '16 at 21:56
1
\$\begingroup\$

I suspect that the answer is quite simple: run readPixels() twice in quick succession. As it stands, if you don't run timing(), when you run readPixels() the 1401 has been sitting there integrating for some unknown (but very long) time, so of course your pixel values are saturated. So timing() resets the pixel integrators to zero, and then readPixels() can properly acquire data. However, running readPixels() the first time will have the same effect.

Of course, when you do this you'll need to disregard the first set of values produced by readPixels(), since they will be a uniform 1023.

So the answer to your title question is - of course.

\$\endgroup\$
  • \$\begingroup\$ 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. \$\endgroup\$ – sgmm Jul 8 '16 at 14:33
  • \$\begingroup\$ No. Integration is halted for the 18 clock cycles following the receipt of an SI pulse. That's it. The rest of the time the integrators are integrating. It's up to the user (you) to control the integration time. If the pixels are saturating, reduce illumination. If you won't do that, simply ignore the results of the first readPixels(). This is not a high-class, flexible camera. It has a minimal interface, so you get a very limited range of operational modes (that is, one). On the data sheet, "Hold" is also called "System Reset" on Figure 10. \$\endgroup\$ – WhatRoughBeast Jul 8 '16 at 22:03
  • \$\begingroup\$ Couldn't you just send an impulse to the SI at the end of the readPixels() method? \$\endgroup\$ – sgmm Jul 11 '16 at 16:41
  • \$\begingroup\$ Well, maybe. The data sheet is not forthcoming. But what do you have against a dummy read cycle, anyways? \$\endgroup\$ – WhatRoughBeast Jul 11 '16 at 21:36
  • \$\begingroup\$ It's basically doubling the total runtime of my program. I'm trying to make it fast so that I can get a high frame rate. \$\endgroup\$ – sgmm Jul 12 '16 at 14:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.