IBIS4 image sensor, no integration.

[Boscoe]

I don't think I'll find some one who's had much experience with this particular sensor so I'm more asking if some one could have a little read of the datasheet to see if there's something I've missed.

My problem is no integration of the pixels. No matter what I set the integration time the pixels are always stuck at the black level. I know this because I can set offset going into the ADCs so the pixel voltage is in the range of the ADC and the values never change based on whether the sensor is covered or exposed to light.

This is my current setup of the registers. Below is the datasheet. If anyone has any advice that would be amazing! Thanks.

https://www.onsemi.com/pub/Collateral/NOII4SM6600A-D.PDF

Code: [Select]

// Memory for the 15 registers
reg [15:0] no_registers [0:15] = '{
// SEQUENCER register
16'b0000_000100000000,
// NROF_PIXELS register
16'b0001_000011101111, // 239 for 480 width
// NROF_LINES register
16'b0010_001010000000, // 640 2
// INT_TIME register
16'b0011_100000000000, // 1ms int time for 640x480
// DELAY register
16'b0100_000000001000, // Delay the pixclk by 6 clocks
// X_REG register (start position)
16'b0101_000000100101,
// Y_REG register (start position)
16'b0110_000000110110,
// IMAGE CORE register
16'b0111_000000000000,
// AMPLIFIER register
16'b1000_000000010000,
// DAC_RAW_REG register
16'b1001_000000000000, // Needs adjusting on test 10000000
// DAC_FINE_REG register
16'b1010_000010000000, // Needs adjusting on test
// DAC_DARK_REG register
16'b1011_000010000000, // Might need to change 10000000
// ADC register
16'b1100_000000000000, // Can play with the gamma
// Reserved
16'b1101_000000000000,
// Reserved
16'b1110_000000000000,
// Reserved
16'b1111_000000000000
};

[Boscoe]

Any one?

I've contacted On Semi for some help but they weren't much use. Just said they can't help much as I'm using a custom board - expected not much more tbh. I am getting an NDA signed, however, to access some more information.

[Boscoe]

I have read the serial lines directly going into the sensor on the update and they do correspond to what i set in the code. I also believe it's okay because I can change things like the amplifier gain and it works.

One interesting note when I did turn up the amplifier gain. The image returned was alternating white and black stripes suggesting only half the rows were gained up, which I could not explain. I can explain a different way however. The sensor has a non destructive readout mode and 4 sub modes to that. One of the 4 is described as follows:

...In setting 3, the row that is read out by the left pointer is
reset and read out (first Y_CLOCK), and the row that is read
out by the right pointer is read out without being reset
(second Y_CLOCK)....

This looks like it could fit what I saw in the image. I find almost all of this datasheet difficult to interpret due to poor English, typos and the large amount of ambiguity in almost all of the descriptions which obviously is the opposite of how a datasheet should be. Anyway, this description sounds like the image I saw; row reset then read out (black row due to reset) next row just read out normally (white row).

This doesn't make sense when comparing the values for the registers. Even if I set register zero (which determines this behaviour) to all zeros (normal electronic shutter mode) I still get this effect. I can verify the values on the scope too.

I have changed the sensor and measured every single pin before and after the change. The pin values and overall results are identical so I'm sure it's not a hardware issue or a faulty sensor.

I'll be waiting over the weekend to get the NDA sorted with OnSemi however I not sure the information they'll give will help anyway. I'm still at a completely dead end here - very frustrating.

[Boscoe]

Hi eev149, thank you for your reply I really appreciate it.

* Are you sending the 16 bit SPI data out to the device MSB first?
"To upload the sequencer registers, a dedicated serial to parallel interface (SPI) is implemented. 16 bits (4 address bits + 12 data bits) must be uploaded serially. The address must be uploaded first (MSB first), then the data (also MSB first)."

Yes this is what I have done and verified on the scope. Each bit matches to what I designed. Most of the time to see correlation in my settings and the sensors behaviour.

* Did you check the SPI clock polarity / clock phase / timing to ensure that you're sending proper SPI data?

Yes, as above.

* Are you sending the SPI registers configurations while the IC is held in reset (at least to initialize them)?  It is required?

I'm not, I don't think the sensor should be in reset. "... on the rising edge of signal REG_CLOCK and become effective immediately." I assume this means the device would not be in reset.

* Did you check that the power supplies and BIASING / DECOUPLING pins are all appropriately connected so there is bias / power applied as needed whether through certain value resistors or not and that proper decoupling capacitors exist where specified? VHIGH_ADC, VLOW_ADC and all the rest?

Yes, I have been through all of them, schematic, layout and the populated PCB, checked all resistor values, voltage and continuity.

* Did you check the ANALOG OUTPUTS to see if the analog values look as expected given the settings?  It should be used to sanity check the resultant ADC values.  You should be able to get a nice row of luminance data on a DSO similar to the way you could see a line of NTSC video, etc.  Maybe some things would be easier if you set it to generate only one analog output ?  I don't know if you need to use both ADCs and both analog outputs for your application.  It looks to me like the two analog outputs have to externally be connected to drive the two ADCs since that appears to me to be where the signal actually comes into the ADCs.  Did you verify that the analog output values are as expected and that they are connected to the ADCs?

Yes I have been observing the analogue outputs. When I have the OUT1/2 signal connected to the ADC_IN1/2 the voltage would be maximum (no integration) but I could get the signal to lower into the ADC's range by setting the DAC_RAW (DC offset) reg to 0.

* Try setting BLACK bit in SEQUENCER and see if the output tracks the configured DAC_DARK voltage?

That's a good idea I'll try that this afternoon.

* Can't you use the ADC register's BITINVERT bit to see if you can cause the output pixels values to invert or not on command?  That may tell you something.

I have done this, BITINVERT does work.

* Why is SEQUENCER:INT_TIME set to that value?  Does it have to be <= NROF_LINES in the given mode?

I have tried everything from 0 to 4095, doesn't seem to have any effect.

* IMAGE_CORE TEST MODE two bits allow either the odd or even columns to be forced to Vdd level.  This can produce a possibility of every or every other column's pixels being set to the maximum value so it should be considered to generate test output to see if it makes sense when in the test mode.

I have them set to 00 for normal operation.

* DAC_RAW_REG should be checked at different values

Have tried throughout the entire range (0-255).

* DAC_FINE_REG should be checked at different values

Have tried throughout the entire range (0-255).

* DAC_DARK_REG Try at 10000000 or ...?

Have tried throughout the entire range (0-255).

* Note on Power On Behavior At power on, the chip is in an undefined state. It is advised that the power on is accompanied by the assertion of the SYS_CLOCK and a SYS_RESET pulse that puts all internal registers in their default state (all bits are set to 0).
Serial to Parallel Interface (SPI) To upload the sequencer registers, a dedicated serial to parallel interface (SPI) is implemented. 16 bits (4 address bits + 12 data bits) must be uploaded serially. The address must be uploaded first (MSB first), then the data (also MSB first).
The elementary unit cell is shown in Figure 9. Sixteen of these cells are connected in series, having a common SPI_CLK form the entire uploadable parameter block. Dout of one cell is connected to SPI_DATA of the next cell (maximum speed is 20 MHz). The uploaded settings on the address/data bus are loaded into the correct register of the sensor on the rising edge of signal REG_CLOCK and become effective immediately.
On power-on, all the internal register of the IBIS4-6600 are reset to 0. All the sensor registers must to be loaded before the sensor is brought out of reset.

I have the sensor in reset for 1s at power on before anything is loaded. I have also tried asserting the REG_CLK before clocking anything in via SPI to clear the shift register but made no difference. Where did you read the sensor settings need applying before bring out of reset?

Many thanks again, I appreciate the effort going through the datasheet and understanding the function of a device like this.

From last night having the OUT1/2 and the ADC_IN1/2 signals unconnected I was getting a varying output that correlated to the amount of light the sensor was exposed to. I did however still got strange results. ADC gain and integration time made no difference to the exposure. The contrast was ridiculously high, obtaining grey on the output was challenging. The DAC reg settings didn't make any difference on the digital output. A calibration procedure is outlined in the datasheet to set the black point offset, you need to keep the sensor in the dark for this, no matter what I set the DAC_RAW register I could not get any output other than zeros output. I did not get time to observe the analogue output at this point, will try that later on.

[Boscoe]

Unfortunately I didn't have time to test today but will do in the week sometime.

Yes the image sensor industry is very frustrating. From my experience I've learnt the industry is split in two, one side being the consumer market where I have had zero success in even gaining part numbers apart from a few Sony sensors and the OmniVision parts. The Sony sensors are horrendously expensive to buy in samples and the Omni parts were too small for me. On there other hand we have the machine vision side, the sensors are much more available however are still very expensive. The best company in this sector is CMOSIS with good data sheets just an email away however with a 4MP sensor coming in at £600 from Mouser I didn't bother. This IBIS sensor was in the middle ground but also ultimately useless to me now as the only shutters you can buy are repair units from eBay which have no documentation and don't fit into my design physically. So all in all there's nothing other than very expensive or very small/outdated parts!

On top of all this getting information on SD UHS speeds is ridiculous with the i.MX6 processors from NXP being the only ones to have it without needing NDAs.

All in all I decided to abandon my digital camera project and just play with the sensors I had bought just to get an image out of them.

You're welcome.
The bit about sending the configuration register set before the part is taken out of reset is in the data sheet I looked at.  I agree that other comments on the data sheet do seem to clearly indicate that you can also send new configurations while the part is not in reset and that such reconfigurations take effect immediately.  So that made me think that there is some good reason why you have to upload at least an initial "correct / sane" configuration while the part is in reset to get the basic clocking / interface / timing defined appropriately and then you would be able to modify the relevant operational details parameters once the part is out of reset but clearly there are some settings you'd never modify "on the fly".
Since the default settings are all 0 bits it isn't obvious how the part would actually start to function after reset is deasserted with those settings even though they're later over-ridden.  I suppose it is possible that something "gets confused" and stays that way?

It is probably not useful but there is another implementation of another sensor that I gather is very different in size though is at least in the same "family" as yours so whether there is any architectural similarity and therefore something to be gained by perusing their implementation I don't know:
http://unaligned.org/bigcam/dw.php

Image sensors are interesting I have a couple different old VGA / 2MP kinds here I've been meaning to make up PCBAs for soon though I should find something much better / newer for more useful future experiments.  It doesn't help that most of the sensors aren't available from stock in low quantities from distributors and most of the data sheets for them aren't readily available and some of the CSP packages are not at all easy to deal with either and then there's MIPI now....  In comparison to some of the stuff I've seen from say OmniVision the ONSEMI part you have actually looks quite "easy" though still lacking in detail to facilitate implementation / programming.

I think it must be a rule in the image sensor industry that the data sheets / application notes must be disappointingly unclear / incomplete etc.  A good well documented reference design, reference manual, good sample code, and a few verilog models would be about what I'd be expecting to provide if I was the manufacturer.

Anyway it sounds like you're close in that at least you seem to be confident of the layout and the electrical design and can twiddle various settings and get the expected response in some ways.  So the rest of it can't be too much farther away from operating.

Yeah checking between the analog outputs and the ADCs seems fruitful to try to get the thing integrating and demonstrably sending the right digital values out corresponding to expected analog values.

I don't remember seeing anything about power supply sequencing / ramp rate requirements or whatever but that may be worth scanning though it shouldn't be an issue if you've followed the reference design etc.

Otherwise if the electronics are OK and the digital timing / IO is working and reading expected test mode (e.g. fully black or fully white) values and the ADC / analog is working with the fully saturated / other test condition values then I guess that's probably all working.  So then there might be something just with the programming of the exposure / region / reset / subsampling / whatever stuff somehow.
I suppose I'd try to simplify as much as possible e.g. one vs. two ADCs used or whatever and then go back and read the data sheet critically and try to think of some way you could be misinterpreting some description that is not so clear or reading too much into something etc.  Maybe try running it at a much slower clocking rate if that is even possible by your system design and datasheet, e.g. 1/16th or less of the maximum maybe, I don't know. 

I wasn't totally clear about how sometimes you said you got alternating black / white values out since it would make a big difference if those were adjacent column pixels vs. adjacent row pixels as to what could cause that.  But I assume you're clear about what you observed there and the possible attribution of it if it was different adjacent pixels in the same "X" row.

Hi eev149, thank you for your reply I really appreciate it.

>> "* Are you sending the SPI registers configurations while the IC is held in reset (at least to initialize them)?  It is required?"
I'm not, I don't think the sensor should be in reset. "... on the rising edge of signal REG_CLOCK and become effective immediately." I assume this means the device would not be in reset.

I have the sensor in reset for 1s at power on before anything is loaded. I have also tried asserting the REG_CLK before clocking anything in via SPI to clear the shift register but made no difference. Where did you read the sensor settings need applying before bring out of reset?

Many thanks again, I appreciate the effort going through the datasheet and understanding the function of a device like this.

From last night having the OUT1/2 and the ADC_IN1/2 signals unconnected I was getting a varying output that correlated to the amount of light the sensor was exposed to. I did however still got strange results. ADC gain and integration time made no difference to the exposure. The contrast was ridiculously high, obtaining grey on the output was challenging. The DAC reg settings didn't make any difference on the digital output. A calibration procedure is outlined in the datasheet to set the black point offset, you need to keep the sensor in the dark for this, no matter what I set the DAC_RAW register I could not get any output other than zeros output. I did not get time to observe the analogue output at this point, will try that later on.