Pico with sony ILX554B sensor

Posted by: @dhananjaya1

↑

Can someone introduce a way to connect and program for Pico with sony ILX554B sensor and after that display the output of that signal as a plot from color display? 

Since it's SONY, that is likely a camera sensor. To use it on a PICO would require library support for both the PICO and the sensor. I have been looking at switching my esp32 cams to PICO and the news is not good yet. You might want to check out Arducam to see if there PICO offering has support for that sensor.

Hi @dhananjaya1,

  I haven't heard of a ILX554B sensor before, but a quick search shows that it is "2048-pixel CCD Linear Sensor (B/W) for Single 5V Power Supply Bar-code Reader", and looking a little closer shows it needs to be supplied with the CCD shift register clocking and in return it will provide an analogue voltage output via a sample/hold amplifier, so that you can progressively sample all 2048 bits by feeding them to an analogue to digital converter. Clocking rates of up to 2Mhz are mentioned.

Unfortunately, my quick search revealed only 1 Arduino project, and that looked flawed, partly due to the participant being inexperienced.

At first glance, it looks a feasible microcontroller project, providing you are reasonably experienced in both digital and analogue design, as well as basic software, plus have adequate test gear including oscilloscope, etc. I do not think it is a good beginner's project. I must leave you to decide how appropriate it is for you.

It probably could use a Pico, but there are a number of issues that would make it a challenge, not least of which being the sensor is 5V device and the PICO is 3.3V max. In many Arduino projects, the only interface is via a bus like I2C, which is easy to interface ... the requirements in this case are feasible but more involved. Other microcontrollers might be more accomodating but 3.3V is the common choice, plus the CCD clocking and  A/D requirements need to be carefully considered.

Whilst there are certainly people on this forum with the skills to interface a microcontroller to that sensor, I (personally) think that would be a significant task, which they would need to be personally involved with, in a 'hands on' environment. I doubt if it is practical to offer more than limited advice on specific points in this forum.

I hope this helps you decide whether to pursue your challenge. I do not want to discourage you, but taking on an over ambitious project can be even more discouraging in the long run, if it runs into a brick wall.

Best wishes, Dave

@zander yeah, it's CCD (charged coupled device)sensor.  I'm looking for make a spectrometer using it with pico.

@davee thank you sir, I appreciate your response. I'm going to make a spectrometer using that sensor and pico. I know it's not easy. I used to convert 3.3v to 5v by level converter. But there is many noises. If I can easily make proper clock pulses with different delays according to the data sheet it would be nice. Also it seems to be pico working frequently and level converter frequency matching is also needed.

If I can make a mycropython code as this arduino code. That would be helpful. 

This is the arduino code for ccd driving and analog read.

#define CLK_SPEED 222 // Clock speed, 20uS to process CLK HIGH so don't use anything greater than 222 here
#define arraySize 2088 // Number of samples to read
#define clk 5 // Clock pin
#define rog 11 // Read Out Gate pin
#define capture A1 // Analogue capture pin

int sampleArray[(arraySize + 1)]; // Store every sample

void setup() {
pinMode(clk,OUTPUT); // Clock
pinMode(rog,OUTPUT); // Read Out Gate
pinMode(capture,INPUT); // Analogue capture pin

Serial.begin(115200); // Baudrate
delay(1000); // Delay time
}

void loop()
{
Serial.println("\nStart readout\n"); // initializing readout
digitalWrite(rog,HIGH); // ____________________
digitalWrite(clk,HIGH); //
delayMicroseconds(1000); //
digitalWrite(clk,LOW); //
delayMicroseconds(1); // setting rog and clk high/low with delay
digitalWrite(clk,HIGH); // to setup clock timing regarding to datasheet
delayMicroseconds(3); //
digitalWrite(rog,LOW); //
delayMicroseconds(5); //
digitalWrite(rog,HIGH); //
delayMicroseconds(3); // ___________________
for(int i = 0; i < arraySize; i++ ) // readout until arraySize is reached
{
digitalWrite(clk,LOW);
delayMicroseconds(1);
sampleArray[i] = analogRead(capture); // Read pixel (It takes about 15uS to read & store analogue value)
digitalWrite(clk,HIGH);
delayMicroseconds(1); // Delay time
}
for(int i = 0; i < arraySize; i++ ) // printout until arraySize is reached
{
Serial.println (sampleArray[i]); // printout on serial port
}
}

Hi @dhananjaya1,

   I suspected you were interesting in using it to make a spectrometer. Whilst the performance specification of spectrometers depends upon the information being sought, for most applications the optical signal range (i.e. weakest detectable light level to strongest level) would be more demanding upon the analog performance of the device when used as a bar code reader, which is essentially a series of light/dark sectors to produce a binary pattern, as Sony indicated. Of course, the device might naturally be of a higher quality/capability than the bar code application requires, but I would expect it to require careful hardware construction as a spectrometer sensor.

In particular, although it has internal clock drivers which makes the job easier, it will still be necessary to ensure the clocking signals do not 'corrupt' the analog output signal, presuming you are interested in detecting relatively small light level changes corresponding to the finer detail of your spectrum. Hence, the 'usual' simple breadboard methods may be not be sufficient for a good result.

-----------

As I mentioned, the Pico is 3.3V, whilst the CCD is 5V. This includes the A/D conversion of the analogue output signal. Are you attenuating this signal to ensure it does not exceed the range of the A/D converter input?

----------

I have only glanced at your code, but I note you have delays down to 1 microsecond. The Arduino reference at

https://www.arduino.cc/reference/en/language/functions/time/delaymicroseconds/

includes:

Notes and Warnings

Furthermore, coding like:

delayMicroseconds(3); //
digitalWrite(rog,LOW); //
delayMicroseconds(5); //
digitalWrite(rog,HIGH); //

using the digitalWrite() function can cause problems. Assuming digitalWrite() function is implemented as a function, then it will consist of a considerable number of processor instructions, further modifying the timing.

Sorry, I don't know how much the timing uncertainities will affect the performance of the device, but I suspect it could affect the signal acquisition times, possibly making the resulting signal noisier than it should be. If I was trying to develop such a product I would either expect to need to move to more precise timing methods, e.g.:

• program this code at the assembler/machine code level, knowing the excution time of each instruction ... with simple processors this is feasible, but it can be difficult with more complex processors that employ optimisation techniques
• Use specific timing/PWM generators commonly built-in to the processors
• Use a 'custom' timing generator ... this might be discrete 74 series or similar logic, a CPLD/FPGA or a separate simple processor (e.g. 8051), programmed  to do nothing more than generate the pulse sequence

In addition, depending upon your requirements, you may find the analogue to digital converters built into microcontrollers to insufficient for the task, and hence consider adding a separate external converter. Please note, I am not saying that you need an external device, merely that would be a consideration in a full system design cycle.

Please understand, I can only suggest possible concerns. Whilst I think these concerns are realistic, quantifying their extent of their effect requires studing the specific design, taking measurements using test gear, and so on, which is obviously beyond the support that can be provided for free over a forum like this one. That is your responsibility. 

----------------

I would recommend you split your project into two parts:

1. Data acquisition
2. Data presentation

The first part is concerned with driving the CCD ... i.e. commanding it to acquire an 'image' and convert to an array of 2000+ data points. If you need to do data averaging, you will do this repeatedly for a number cycles.

The second part converts the acquired numeric data into a convenient form, e.g. a spectrograph for presentation.

The first part may have critical timings and require close machine control as discussed above. Arduino C++ functions may be too slow. Python is unlikely to improve on C++, and could be much slower still.

The second part is 'more relaxed', as processor timings will only change the delay between the acquiring the data and presenting it to the user, which are likely to be relatively short. This part could probably be implemented in Python if you prefer.

Whilst a single processor probably could do both parts, using more than 1 processor may be preferred if it removes performance compromises.

-------------

I wish you luck in your project but I think it is largely now down to you.

Best wishes, Dave

(By the way, if you present any program code in the future, I recommend you take care to paste it as described in the forum instructions above, and use the Preview option at the bottom of the message box to ensure it will appear corrrectly, before hitting ADD REPLY. )

@davee thank you sir. 

Is this code okay with ccd read and analog read?

This is micropython code I made. 

The range in that code is used for testing

@dhananjaya1 fyi @davee The sensor as Dave pointed out is "2048-pixel CCD Linear Sensor (B/W) for Single 5V Power Supply Bar-code Reader". I am keying on 2 things there, B/W and Bar-code. The OP said he was making a 'spectrometer' I googled spectrometer and found 'a spectrometer can separate white light and measure individual narrow bands of color, called a spectrum.' I think a CCD that only reads Black and White is not going to work. As a long time photographer I know how color digital photography works, and in fact the detector whether it be CCD (seldom used) or CMOS (mostly used) only records the intensity level of light, in other words it is only Black and White. We get color by using something called a Bayer mask. We record the amount of Red, Green, Blue light as numbers that is then used to turn on the same color pixels on your screen.

Unless you have a Bayer mask in front of the sensor then I doubt it will do what you want. The fact it is designed for bar code reading tells me it is indeed a B/W detector.

Good luck.

Hi @dhananjaya1,

  Sorry, I don't think I can give any definitive answers as to whether code will work without building the project myself ... and sorry, but I am not planning on doing that at the moment.

I have only glanced at the data sheet, but CCDs work on a cyclic basis of sensing the light for a period, during which time photons striking the detectors cause the internal capacitors to be charged, then each of the charge capacitors are read in turn, the output voltage being proportional to the amount of charge collected in that particular capacitor.

The amount of charge collected in each capacitor is tiny, and the charge must be passed along the chain to the output circuit in a manner reminescent of a chain of people passing a bucket of water to their neighbour in the chain.

Remembering there are 2000+ neighbours in the  CCD chain, if each neighbour in turn spills just a little water, say 0.1% of a bucketful, then at many of the buckets will be empty before they reach the end of the line, even if they started full! CCDs have the same problem!!

All of this is analog electronics, so timing and 'clean' noise-free electronics is critical ... delays and noise will allow charge leakage and the values will be corrupted.

I am not certain of the exact timings needed ... I haven't studied the data sheet and it will depend on factors like the light levels to be detected, as well as the CCD design. I would expect each 'snapshot' (shutter open) time to be a small fraction of a second, then the data for each 'snapshot' would need to be clocked out promptly ... maybe at a rate of 1-2 million data values per second.

This is probably much too fast for common Arduinos (like a UNO) to perform adequately.

Sorry to be vague, but these are exactly the kind of experiments needed to determine exactly how well it will perform.

-------------------------------

Ron @zander. Actually, the general principle of this project is relatively sound, although I have no idea how succcessful it will be, as is it taking a commercial device optimised for one purpose and using it a completely different purpose. Plus, the electronics and hardware support needed are quite demanding, in particular, poor wiring practices, inappropriate clocking timing, etc could easily create so much electrical noise that the desired signal would be buried in 'mush'.

The device has 2000+ 'pixels' in a single line formation. 

These 'pixels are relatively colour agnostic ... that is like monochrome camera, or black and white film, they can detect light over a reasonably wide 'colour range' ... I haven't read the specs for this device, but typically it would cover the visible spectrum and extend some way into UV and/or infra red, assuming there are no additional filters.  (Of course the sensitivity will vary with light wavelength.)

The spectroscopic capabilty is provided by placing an optical device between the light source and the camera, such as a prism or a defraction grating, which splits the light into a 'rainbow' like pattern which is imaged onto the detector. Thus each of the 'pixels' can only get light of a particular colour. (Albeit, this is oversimplifying the optical situation into an 'ideal case.)

--------

Hope this helpful .. sorry, but as I said previously, this is a relatively complex project, needing well controlled clocking and analog-to-digital conversion. Furthermore, the CCD is a 5V (mainly) analog device running at RF frequencies with low level signals, whilst the PICO is 3.3V digital device. All of the interconnections must be converted without compromising the waveforms or introducing noise. Simple (but poor) practices that can usually be tolerated by Arduinos and other microcontrollers due to their digital nature are not appropriate to an an analog CCD device.

Best wishes, Dave

@davee Ah, I missed that, so the actual spectrum splitting will be done by a standard prism and the crude bar code reader will measure each spectrum component. I haven't looked at the datasheet, but I bet the individual 'pixels' are only 8 bit since that is more than enough for bar code reading. To put that into perspective my semi-pro DSLR is 14 bit (also the pro model is 14 bit). The closest analogy I can come up with is using a box of crayons with only 8 colours to represent the entire color spectrum. 

@zander thank you for your information and help💪🧡

@davee yeah, it's right!. Thank you sir!

Hi Ron @zander and @dhananjaya1,

  Yes Ron, you are now beginning to understand the principle ... the precise optical arrangement to be adopted has not been discussed but spectrometers using direct eyeball observation, and subsequently photographic plates, have a history of more than 2 centuries. https://astro-canada.ca/les_spectrometres-spectrometers-eng

This project involves replacing the photographic plate/film with an electronic sensor.

The 'pixels' are of the same basic type as the CCD camera sensors. Each 'pixel' includes a capacitor which acquires charge from photoelectrons during the 'shutter open' period. (The 'shutter' is electronic based switching, rather than a metal plate, but the effect is roughly the same.)

Then, after the 'shutter' is closed the charge in each capacitor is output from the device, in a sequence of analogue voltages which are proportional to the charges on the respective capacitors. This is done by making the capacitors associated with the pixels into an analogue charge shift register. The charge is converted into a voltage using a sample and hold amplifier at the end of the chain. It is up to the user to provide an external analogue to digital converter, if they want their data in digital form.

Thus, as far as the sensor is concerned, it is not a case of 8-bit versus 14-bit, but how accurately the output voltage represents the amount of light that fell on the particular 'pixel' whilst the 'shutter' was open. This voltage may be 'distorted' by many factors, including:

• sensitivity and dark (thermal) noise of the photodiode in each 'pixel' responsible for converting photons into charge
• 'dark charge' ... charge may be acquired by thermal electron tunnelling as well as by photo electrons during the 'shutter open' period, and also into each of the charge capacitors during the 'shutter closed' phase. This will depend upon many factors including internal device design, silicon device manufacture and temperature
• charge transfer losses and smearing ... the charge from each 'pixel' must be transferred along the whole line of 'pixel capacitors' in a shift register fashion. Each transfer risks loosing some charge, especially to the immediate neighbours .. think of a line of people trying to put out a fire (as per some old movies), each with a bucket, transferring the water by pouring it from their bucket into their immediate neighbours bucket. 
• noise from electrical clocking, etc. needed to make the device work

Note that some of these factors are time dependent ... the longer it takes to read the data, the more it will be distorted. Of course, the rate at which the device can clock the data out is also limited, so there is likely to be a rather small 'Goldilocks' range between going fast enough to read the data before it is lost and slow enough for the device to function.

.....

The 'number of bits' question is down to the external A/D converter used by system designer ... but of course, not many (none?) microcontrollers offer 14-bit 2Msample/sec converters with a 5V input range ....

--------

In summary, the sensor suggested is feasible in principle, but I have no idea if its characteristics are of sufficient quality to make a useful instrument. Furthermore, the questioner did not provide a specification for the final instrument, so I have no idea what 'quality' is required or expected.

Clearly, the 'intended' use of the sensor as a bar code reader is much less demanding than that of a sensitive spectrophotometer, but that doesn't tell me anything about its potential capability of more demanding roles. It may be even be down to chance as to whether you get a 'good' one or a 'poor' one, as the difference would not have been tested on a production line, providing a 'poor' one could do the bar code task.

Best wishes,

Dave

@davee I don't know of a single camera that uses CCD, they all use CMOS. Other than that the operation is similar. The 'output' of a DSLR sensor is a series of numbers, most today being 14 bits long (probably stored in a 16 bit unsigned int) Of course there are 3 for each pixel, RGB and somewhere in there is stuff like luminance, saturation and hue. For my camera each of the luminance etc has 8 color sliders. So as you can tell there is a lot going on between the sensor and the human eye.

I remain curious about this project but have my doubts about the tech.

Hi Ron @zander,

  I am not a historian, but my failing memory suggests that the early solid-state camera sensors were all CCD ... the most famous example probably being the RCA video camera used on the moon ... providing perhaps the only golf game I have ever watched with interest. 😀 

I recall reading that it in more recent years, one person pioneered using the CMOS approach ... and as a result of his efforts, CCD's popularity as a camera sensor has plummetted.

I appreciate contemporary camera sensors, even the 'almost no cost' one usually fitted to the EXP32 CAM, let alone the 'posh' ones you are more familiar with, does a lot of high speed arithmetic to produce its digital output, as well as including optical filters etc to differentiate RGB and so on..  However, that does not apply to this CCD.

I entirely share your sentiment "I remain curious about this project but have my doubts about the tech."

Best wishes and take care my friend. I hope you are recovering from your ailments of 2022 and that 2023 is treating you more kindly. Dave