Linear CCD, how to get it working?

[Dajgoro]

I am trying to read a linear ccd chip, the TCD1201, and of course, it is not working.
I read the datasheet a couple of times, but there is not a decent explanations what do the various pins exactly do. I know what phy1 and 2 do, but there is also: boost pulse, shift gate and reset gate. What do this signals exactly do?
I tried looking at the timing diagrams, and I wrote a program for the 8051 mcu to simulate that, but then when I look at the various graphs, the SH pulse appears outside of the image frame, and yet, on another graph is shown with phy1. So how should this signals be operated in order to get a image?

Even in this messy state it is somehow sensitive to light, but it is a mess.

[Dajgoro]

Datasheet:
http://www.datasheet4u.com/download.php?id=377030

[fcb]

These are non-trivial.  I suggest reading around the competitors devices and the theory behind CCD's.

Also, respect the weird voltages that CCD's often run at.

[kxenos]

From what I see, RS and BT is your clock, normally 1MHz.. These signals could be the Q and Q' outputs of a flip-flop. Then you have the F1 and F2 signals which have half the frequency of RS and BT. So you can make them with an other flip-flop connected as a freq. divider from the first one. The SH is like an enable pulse which is normally high. When you want to clock the readings out, you pull it low and then count 2096 pulses in the RS or BT lines.

[Dajgoro]

I did check the datasheet of other models, and manufacturers, but that didn't help.

On another page of the datasheet all of the pins except form the analog outputs seem to be inputs, so I guess they should be manually driven. Another mystery is that the datasheet says, minimum clock frequency 0.01MHz, max 1MHz, while on the timing diagrams there are exact timing requirements for every event. So since I am using a mcu, I can't drive the signals at 1MHz, and also my a/d converter is not as nearly that fast.

I already tried making the SH pulse high while not operating the ccd, and leaving it low while operating, and them letting the mcu drive the four signals as shown in the diagram, but it didn't work very well.

[kxenos]

Did you try the typical circuit?

[Dajgoro]

That is more of less what I have...

[Dajgoro]

I sorta got something...
I somehow managed to get the output, but the entire output is just from the pixel near pin 1, the rest of the array doesn't show any sensitivity to light.

The clock of f1 and f2 is 10kHz, and that is the fastest that my current setup goes (I had to overclock the 8051).

I attached photos from the scope, the top waveform is f1.
2V, 10us / div


So what could be wrong here?

[Dongulus]

What do your waveforms look like in a smaller time base? Try to get the something similar to the scale of what the datasheet has. What are you triggering on? Trigger on the falling edge of the SH signal if you can to make sure that you are looking at the waveforms at the end of the integration time. Note in the timing diagrams that the first real data output occur after 32 cycles of F1/2 after the end of integration time.

Maybe try delaying RS with respect to BT by a single clock cycle. For some reason the timing specifications list a minimum delay time between BT falling and RS rising. 

Edit. These oscope displays are 2V/div? Are you running off 5V. Judging by the scope images it looks like close to 3.3V.

[Dajgoro]

What do your waveforms look like in a smaller time base? Try to get the something similar to the scale of what the datasheet has. What are you triggering on? Trigger on the falling edge of the SH signal if you can to make sure that you are looking at the waveforms at the end of the integration time. Note in the timing diagrams that the first real data output occur after 32 cycles of F1/2 after the end of integration time.

Maybe try delaying RS with respect to BT by a single clock cycle. For some reason the timing specifications list a minimum delay time between BT falling and RS rising. 

Edit. These oscope displays are 2V/div? Are you running off 5V. Judging by the scope images it looks like close to 3.3V.

I set the scope to trigger when the mcu starts scanning.
When I set it to show the entire scan on the screen, I get the same level everywhere, it acts like I connected a regular photo diode.

I could try poking a bit more with the timing, but I can't fine tune it a lot since the 8051 is not the fastest mcu around. I could use a PIC, but I don't have a pic that has 2k of ram to store the scan results, while the 8051 system that I am currently using has a 64k ram chip.
The datasheet says that it can work at 10kHz, so this should work as well.

I am running the circuit at 5V, the outputs are driven by a XC9572 CPLD which is connected to the 8051-s bus, and acts as a programmable peripheral.

[Dongulus]

I found this in a google search. The OP was having trouble running this on an arduino. Some of the suggestions were pointing to making sure that the f1 and f2 signals cross at above 2.5V.

[nes]

I used these devices before and I found it was a bit of a pain to get working correctly.

From memory, the inputs need to be driven right to the rails though I can't remember what I used for a level shifter. The output has to have at least the emitter follower the data sheet recommends. You also have to pay careful attention to the phase of your sample and hold circuit in relation to the clock. The pulse width required for the SH signal is proportional to the ambient light and varies over quite a wide range.

You have to keep the device shielded from the ambient light as the whole circuit is sensitive to it. I think a black box with a pinhole in it worked for me while experimenting.

[Dajgoro]

Ok I'll try rebuilding the circuit to include a signal buffer, and those signal amplifiers.
What does exactly SH do, and how do I adjust it correctly, and when do I trigger it?

[nes]

Ok I'll try rebuilding the circuit to include a signal buffer, and those signal amplifiers.
What does exactly SH do, and how do I adjust it correctly, and when do I trigger it?

Again this is from memory, I used these on a project a long time ago. I think the SH signal on these is dual function, controlling both the integration time (analogous to the shutter on a film camera), and gating the collected charge into the bucket brigade ready to clock out. The total period that SH is low (including the period where you read the samples out) controls the sensitivity of the array.

You can do a simple auto exposure control by taking the mean of all the samples and adjusting the total SH low period to keep it within a useful range.

The dead time between SH going low and the clock starting is necessary and the duration of the SH high period is important too I seem to recall.

If a well gets saturated with too much light, the charge (or depletion?) bleeds into the adjacent wells. Also, if the SH high period is too short, you get a higher contrast image at the expense of smearing if the image is moving.

I think these devices were meant for barcode scanners, the output intended to be sampled and quantised into binary with a simple op-amp/comparator circuit. They are very sensitive, but not particularly linear over the useful range.

[kony]

The total period that SH is low (including the period where you read the samples out) controls the sensitivity of the array.
...
I think these devices were meant for barcode scanners, the output intended to be sampled and quantised into binary with a simple op-amp/comparator circuit. They are very sensitive, but not particularly linear over the useful range.

Sorry, but this is misinterpretation. Time the shutter signal is low simply gives integration time of CCD array, not its sensitivity. Also, note that BT and RS signals must be running even if you have gone in reading beyond last usable pixel (important if you are using fixed read-out clock frequency).

These devices were ment to be used in flat-bed and handheld scanners, so linearity of individual pixels is not bad. What is bad is that pixels have up to 20% non-uniformity in their sensitivity to light and small deviations in dark offset voltages, so it must be compensated lately.

How do you generate clock signals ? Are you changing outputs by OR/AND masking port value, or setting by bitwise operations ? In second case it might getting you in trouble simply because not meeting timing requirements (crossing of clock signals above 2,5V level). Also, are you including some buffering in signal path ? Clock pins have relatively high capacitance.
EDIT: Please, show me BT and RS signals on one oscillogram - two periods fitted on screen. Precise timing of these two is also critical.

Bellow attached image is one video data frame - sensor lit with red LED - hence the prarrabolic curve due to its irradiation characteristic, the smal notch in the middle is hair put across the sensor - some 11 odd pixels wide. Beware, that this sensor is quite sensitive - in this case I was using 10ms integration time and LED could be barely seen at all - all placed in black carton box. Even LCD monitor with dark image (text terminal showing nothing) standing nearby is capable of saturating it !


I'm messing with this device right now, so feel free to send me any questions about it.

[Dajgoro]

Thanks for the reply.

Ok, so here what my system does so far.
When not scanning, I set SH to high, and when I start scanning I set SH to low, but that is one of the issues, I don't know exactly when should I pull sh low and high, I noticed that there is a difference, but I didn't figure it out. Once SH is low, I start clocking f1 and f2, along with rs and bt for the entire 2094 elements. When I switch the phase, I start the a/d conversion, when that is done I switch rs and bt, and when that is done I switch the phase, increment the data pointer, and start another a/d conversion, and the process repeats. I store all of the data in the ram. The 8051 goes through the data and prints a simple bar like printout via serial port to my putty client. So the thing I noticed is that when I don't print out the result I can see that I get some output from the ccd, but it is only from the top pixel all along the scan, but when I do print out the result it won't work, so the only thing that is different in both scenarios is the amount of time I keep the SH line high, because while printing out the 8051 is busy, so it won't generate any clock, and sh is held high.

So that is why I ask what exactly should I do with sh, and when should I assert it in my setup to get a decent readout.

[kony]

Thanks for the reply.

Ok, so here what my system does so far.
When not scanning, I set SH to high, and when I start scanning I set SH to low, but that is one of the issues, I don't know exactly when should I pull sh low and high, I noticed that there is a difference, but I didn't figure it out. Once SH is low, I start clocking f1 and f2, along with rs and bt for the entire 2094 elements. When I switch the phase, I start the a/d conversion, when that is done I switch rs and bt, and when that is done I switch the phase, increment the data pointer, and start another a/d conversion, and the process repeats. I store all of the data in the ram. The 8051 goes through the data and prints a simple bar like printout via serial port to my putty client. So the thing I noticed is that when I don't print out the result I can see that I get some output from the ccd, but it is only from the top pixel all along the scan, but when I do print out the result it won't work, so the only thing that is different in both scenarios is the amount of time I keep the SH line high, because while printing out the 8051 is busy, so it won't generate any clock, and sh is held high.

So that is why I ask what exactly should I do with sh, and when should I assert it in my setup to get a decent readout.

Starting A/D conversion immidietly after Clk transision is wrong. Look at datasheet on page 7. You need to wait at least 100ns till you can read valid data (and even more, if using higher readout clock frequency). Do you use emitor-follower or any other signal buffer ? Output impedance varies and sensor really does not like to be loaded more than needed. Also how long does take you one conversion to complete and handle the data ?
If You don't need actual image data, just disable ADC and let it running on some reasonable integration time.
How exactly looks timing of your RS and BT signals - show me it on oscilloscope, both on one image, then RS and Clock 1.

I strongly recommend you using CPLD or even small FPGA for this purpose, micro really does not fit it so much. As a absolute nebwie in a world of programmable logic, I was able to get it running in less than two hours (some basic counters and coparators in Verilog).

[Dajgoro]

I don't have the emitter followers yet, but I do plan to add them, for testing I disconnected everything, and hooked it up to my scope through a x10 probe.
I was thinking about letting a cpld do the timing, but then who controls the a/d converter? The cpld and the mcu should be synced, which would be kinda tricky to do.

I already uploaded the scope images, look at the first page.

[kony]

Scope probe should be fine, just beware of proper grounding.

I have already checked oscilloscope shots, but it is not exactly what I'm asking for (okay, there is RS and clock, but could you please choose shorter timebase (trigged on falling edge on clock in the middle of image). Is it trully 2 volts per DIV ? This sensor is spec'd for 5V operation only !

What's tricky about syncing ADC ? Are you trying you to tell me you are not capable of handling external interrupt request? I don't think so . Just generate rising edge from PLD in time you should start the conversion. But beware, that ADC in micro might not be fast enough, also you'll have to subtract offset from signal.

I'm getting digital o'scope borrowed from my collegue in a two days or so, I'll then provide you examples for what should you have implemented (if datasheet is not enough for you).

[nes]

I think these devices were meant for barcode scanners, the output intended to be sampled and quantised into binary with a simple op-amp/comparator circuit. They are very sensitive, but not particularly linear over the useful range.

Sorry, but this is misinterpretation. Time the shutter signal is low simply gives integration time of CCD array, not its sensitivity. Also, note that BT and RS signals must be running even if you have gone in reading beyond last usable pixel (important if you are using fixed read-out clock frequency).

These devices were ment to be used in flat-bed and handheld scanners, so linearity of individual pixels is not bad. What is bad is that pixels have up to 20% non-uniformity in their sensitivity to light and small deviations in dark offset voltages, so it must be compensated lately.

Ah, my mistake. I was experimenting with several different linear CCDs at the time, so I am probably confusing it with a different one.

I was using an FPGA to generate the control signals and had to drive the phi inputs with slightly less than 50% duty cycle, though 180 degress out of phase. I know one of the timer modules in AVR devices has a mode that does exactly this. I guess it should be possible with other microcontrollers too.

[kony]

I've tried it even with simple inverter to deviate second clock line - 5ns signal propagation delay didn't seemed to bother it so much. But I really woudn't use it this way in any other case than just tinklering on a breadboard.

EDIT: You've mentioned that 10kHz clockrate is used ? That's about 100ms integration time - at this times it is fucking sensitive, I mean - really - no way you'll get along with LCD screen nearby without proper shielding made from black carton, it'll be driving it safely to saturation. And if you overexpousure it too much, next few scans will be corrupted too (charge remaining in pixels).
Also a good point is to have sensor half-covered by aluminium tape, when not sure if you are getting only a gibberish or some to at least some degree valid data out from it. Also, are you sure you are measuring on video output (OS) and not on dark offset correction output (DOS)? Stupid mistakes like this happens and it will comply with diagrams you provided - just clamping pulses and very faint response to strong overexposure or covering the sensor.

[Dajgoro]

EDIT: You've mentioned that 10kHz clockrate is used ? That's about 100ms integration time - at this times it is fucking sensitive

You mean 100us?

no way you'll get along with LCD screen nearby without proper shielding made from black carton, it'll be driving it safely to saturation. And if you overexpousure it too much, next few scans will be corrupted too (charge remaining in pixels).

Problem is I am not getting anything when I should, it is like that the device is in complete dark.
But one particular thing is that when f2 is active, the output level gets a a bit higher, but still nowhere close to saturation. When I got working for that single pixel I had to put a 60W light bulb in front of it to saturate (before saturating I could see the 50Hz ripple form the light bulb).

Also a good point is to have sensor half-covered by aluminium tape, when not sure if you are getting only a gibberish or some to at least some degree valid data out from it.

I covered the thing with black electric tape while testing, but that didn't help.

Also, are you sure you are measuring on video output (OS) and not on dark offset correction output (DOS)? Stupid mistakes like this happens and it will comply with diagrams you provided - just clamping pulses and very faint response to strong overexposure or covering the sensor.

I tried scanning both of them, but I didn't get anything useful.

[kony]

EDIT: You've mentioned that 10kHz clockrate is used ? That's about 100ms integration time - at this times it is fucking sensitive

You mean 100us?

No way ! integration time of sensor is given as a time between two following falling edges of SH! Roughly 105ms at 10kHz it is !

Let's simplify it a little bit for explanation.
Each pixel behaves as a capacitor, which, when stroked with foton loses some fraction of its charge, otherwise it will stay intact.
At the beggining, when you set SH signal to high, all capacitors are charged to defined voltage level, then, after falling edge, voltage is disconected and pixels begins to integrate.
At the same time, rising edge of shutter caused that all charges stored in pixels from previous integration period are pushed into the analog pipeline.
There is a sampling amplifier on the end of pipeline. Each clock pulse causes one shift in analog pipeline trowards the amplifier. But the amplifier has sampling capacitance on its input - and this has to be discharged - this is reason why you need to generate RS pulse just before clock transition - to dischard voltage stored on its input.
After you have shifted all pixels, you might wait to integration time ellapse, or just start new integration period - so basically data what are you reading out is image registered on sensor during previous integration period.
Both RS and BT signals are used for some housekeeping inside sensor, so they must be provided continuously no matter what. (charge pumps for biasing and so on)

You have some pixels covered with lightproof material on beginning of array to help you with compensating for dark voltage of pixels (which is dependent on many factors, but temperature mostly).

But one particular thing is that when f2 is active, the output level gets a a bit higher, but still nowhere close to saturation.

Higher for saturation ? No, nooo. When saturated, you'll get lowest possible voltage on sensor output !

Also, confirm, that 2V/div scale on your oscilloscope is out of callibration, otherwise you're feeding in  3,3V logic.

Is it clear ?

Sorry for typos and mis-spelling if any, it's not my native language and I'm getting really tired now.

[Dajgoro]

"Higher for saturation ? No, nooo. When saturated, you'll get lowest possible voltage on sensor output !"

Yup, I covered the thing completely with black electric tape, and then I tried again, and it sorta worked. The thing that was bugging me all along is that when overexposed it began working the other way. So when I would put that 60W light bulb it would start climbing again.

Ok, so now I have it sorta working, but I am still not sure how to adjust the exposure.

What I understood so far is that SH sorta resets the charge holders, but what controls the exposition time, and which signals transfers the charge to the bucked brigade?
Because if it was shifting and transferring all along I would get a blurry image.

Btw, the datasheets of such devices are a disaster, it only tells you which pins are for what, and some timing information, with absolutely no info on what does which signal do, and that is why I am having so many issues.

[kony]

What I understood so far is that SH sorta resets the charge holders, but what controls the exposition time, and which signals transfers the charge to the bucked brigade?
Because if it was shifting and transferring all along I would get a blurry image.

Btw, the datasheets of such devices are a disaster, it only tells you which pins are for what, and some timing information, with absolutely no info on what does which signal do, and that is why I am having so many issues.

Belive it or not, it is again SH signal ! It is absolutlely clear from timing diagram and i have mentioned it already (not once). SH signal transfers charge from pixels to pipeline AND resets the pixels.
Period of SH signal gives you integration time -> eposure.
You'll need faster clock to get usable results (usable integration times), and by faster I mean at least 20 times ! Good luck if you are still trying to use old crusty 8051 for it. You must read whole sensor before you start new integration period, so what limits you right now is readout clock and timing speed. (I have hit the other end trough - it seems like reasonable maximum clock frequency is somwehre around 500kHz, due to sensor nature of function.)

What's that about shifting all along, I don't get it. Is it that you are shifting whole image frame from all 2096 pixels in analog shift register to output ? Yes, you are and there is nothing wrong about it.


Stop whinning about datasheet, it is perfectly fine - all information needed is included. Yes, it is not a cookbook, but there is a reason why it is called datasheet, right ?