Mike_green
Posts: 8
Joined: Wed Oct 17, 2018 6:36 am

Raspiraw and AR0144 sensor

Mon Oct 22, 2018 8:50 am

Hi there!
We've got an ar0144 sensor and we trying to make it work with Pi by modifying raspiraw.
We've got some problems with it and thus stands next questions:

-Does it matter, if this sensor has global shutter?

- We set next settings for our sensor:

Code: Select all

.width         = 1280,
.height        = 800,
.encoding      = 0,
.order         = BAYER_ORDER_GBRG,
.native_bit_depth = 12,
.image_id      = 0x2C,
.data_lanes    = 2,
.min_vts       = 832,
.line_time_ns  = 23077,
.timing        = {0, 0, 0, 0, 0},
.term          = {0, 0},
.black_level   = 0,

.i2c_addr =             0x10,
.i2c_addressing =       2,
.i2c_data_size =        2,
.i2c_ident_length =     2,
.i2c_ident_reg =        0x301A,
.i2c_ident_value =      0x5820,

.vflip_reg =            0,
.vflip_reg_bit =        0,
.hflip_reg =            0,
.hflip_reg_bit =        0,

.exposure_reg =         0,
.exposure_reg_num_bits = 20,

.vts_reg =              0,
.vts_reg_num_bits =     16,

.gain_reg =             0,
.gain_reg_num_bits =    10
-Does timing = {0,0,0,0,0} matters for us?

-We've got next stack trace, and no thoughts what is cause for CRC_ERROR:

Code: Select all

1666553.717: unicam_int_callback: instance=1 status = 0x8
1666553.736: unicam_int_callback: bytes_written = 1920, lines_done = 1
1666553.762: unicam_int_callback: Frame Start, time = 1666553705, frame_int_req=1, frame_int_ready=0
1666557.726: unicam_int_callback: instance=1 status = 0x21
1666557.745: unicam_int_callback: bytes_written = 385920, lines_done = 201
1666557.758: unicam_int_callback error: CRC error
1666557.772: unicam_int_callback: Line Interrupt 201
1666561.734: unicam_int_callback: instance=1 status = 0x21
1666561.757: unicam_int_callback: bytes_written = 770064, lines_done = 401
1666561.767: unicam_int_callback error: CRC error
1666561.782: unicam_int_callback: Line Interrupt 401
1666565.742: unicam_int_callback: instance=1 status = 0x21
1666565.762: unicam_int_callback: bytes_written = 1153920, lines_done = 601
1666565.774: unicam_int_callback error: CRC error
1666565.789: unicam_int_callback: Line Interrupt 601
1666569.748: unicam_int_callback: instance=1 status = 0x31
1666569.760: unicam_int_callback: Rounding lines done to frame height
1666569.781: unicam_int_callback: bytes_written = 1536000, lines_done = 800
1666569.792: unicam_int_callback error: CRC error
1666569.804: unicam_int_callback: Frame End
1666569.821: cm_process_thread: events 0010
1666569.832: cm_unicam_event - enter
1666569.843: cm_unicam_event: FRAME_END complete
1666569.853: cm_unicam_event - exit
Could you give us a clue what should we do to make it work correctly?

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7150
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Raspiraw and AR0144 sensor

Mon Oct 22, 2018 9:32 am

Mike_green wrote:
Mon Oct 22, 2018 8:50 am
Hi there!
We've got an ar0144 sensor and we trying to make it work with Pi by modifying raspiraw.
We've got some problems with it and thus stands next questions:

-Does it matter, if this sensor has global shutter?
No, that should make no difference at all. It still sends out the normal CSI data, although possibly with slightly changed timing.
Mike_green wrote:- We set next settings for our sensor:

Code: Select all

.width         = 1280,
.height        = 800,
.encoding      = 0,
.order         = BAYER_ORDER_GBRG,
.native_bit_depth = 12,
.image_id      = 0x2C,
.data_lanes    = 2,
.min_vts       = 832,
.line_time_ns  = 23077,
.timing        = {0, 0, 0, 0, 0},
.term          = {0, 0},
.black_level   = 0,

.i2c_addr =             0x10,
.i2c_addressing =       2,
.i2c_data_size =        2,
.i2c_ident_length =     2,
.i2c_ident_reg =        0x301A,
.i2c_ident_value =      0x5820,

.vflip_reg =            0,
.vflip_reg_bit =        0,
.hflip_reg =            0,
.hflip_reg_bit =        0,

.exposure_reg =         0,
.exposure_reg_num_bits = 20,

.vts_reg =              0,
.vts_reg_num_bits =     16,

.gain_reg =             0,
.gain_reg_num_bits =    10
-Does timing = {0,0,0,0,0} matters for us?
Unless you need some strange timings for the PHY timings then no. The defaults have worked with almost every sensor I've encountered.
If you are using a continuous clock mode (ie not dropping the clock lane to LP mode) then you will want to set both term1 and term2 to 1.
Mike_green wrote:-We've got next stack trace, and no thoughts what is cause for CRC_ERROR:

Code: Select all

1666553.717: unicam_int_callback: instance=1 status = 0x8
1666553.736: unicam_int_callback: bytes_written = 1920, lines_done = 1
1666553.762: unicam_int_callback: Frame Start, time = 1666553705, frame_int_req=1, frame_int_ready=0
1666557.726: unicam_int_callback: instance=1 status = 0x21
1666557.745: unicam_int_callback: bytes_written = 385920, lines_done = 201
1666557.758: unicam_int_callback error: CRC error
1666557.772: unicam_int_callback: Line Interrupt 201
1666561.734: unicam_int_callback: instance=1 status = 0x21
1666561.757: unicam_int_callback: bytes_written = 770064, lines_done = 401
1666561.767: unicam_int_callback error: CRC error
1666561.782: unicam_int_callback: Line Interrupt 401
1666565.742: unicam_int_callback: instance=1 status = 0x21
1666565.762: unicam_int_callback: bytes_written = 1153920, lines_done = 601
1666565.774: unicam_int_callback error: CRC error
1666565.789: unicam_int_callback: Line Interrupt 601
1666569.748: unicam_int_callback: instance=1 status = 0x31
1666569.760: unicam_int_callback: Rounding lines done to frame height
1666569.781: unicam_int_callback: bytes_written = 1536000, lines_done = 800
1666569.792: unicam_int_callback error: CRC error
1666569.804: unicam_int_callback: Frame End
1666569.821: cm_process_thread: events 0010
1666569.832: cm_unicam_event - enter
1666569.843: cm_unicam_event: FRAME_END complete
1666569.853: cm_unicam_event - exit
There have been a couple of sensors we have encountered that the CSI2 receiver peripheral just doesn't like the CRCs, but the image data is fine.
vc.ril.rawcam ignores the errors and delivers the buffers back to the application (I thought it passed on a corrupt flag, but can't see that at the moment).
Mike_green wrote:Could you give us a clue what should we do to make it work correctly?
What exactly is the issue?
Do you get buffers back? Is there anything in those buffers? Is this just that the exposure time or gains are set too low? Where has your register set come from to set the sensor up?
You have got the correct setup for 12 bit Bayer data, so I assume you are telling the sensor to stream 12 bit Bayer, otherwise it'll try displaying the embedded metadata.
Have you tried decoding the sensor metadata? Add "-m" to your command line and it should dump out the registers as they applied to that frame.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Mike_green
Posts: 8
Joined: Wed Oct 17, 2018 6:36 am

Re: Raspiraw and AR0144 sensor

Mon Oct 22, 2018 4:29 pm

6by9 thanks a lot for your answering!
6by9 wrote:Do you get buffers back? Is there anything in those buffers?
Yes, we,ve got buffers back with some data. We worried about CRC_ERROR, but as you said that it's OK.
6by9 wrote:Is this just that the exposure time or gains are set too low?
It seems that it is.
6by9 wrote:Where has your register set come from to set the sensor up?
We,ve got this from sensor's datasheet.
6by9 wrote: Have you tried decoding the sensor metadata? Add "-m" to your command line and it should dump out the registers as they applied to that frame.
No, we haven't. Thanks for this, we'll try.

We've tried to decode data from buffer, but the quality of images are awful.

Here is what we've got:
Image

And how should it be(photo from phone):
Image

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7150
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Raspiraw and AR0144 sensor

Mon Oct 22, 2018 4:54 pm

Mike_green wrote:
Mon Oct 22, 2018 4:29 pm
6by9 wrote:Where has your register set come from to set the sensor up?
We,ve got this from sensor's datasheet.
Do you have a decent contact within OnSemi? I know from other projects that they have a decent dev kit which allows you to attach their modules and view the output within Windows. It also allows easy tweaking of settings, and shows the exact register set in use. I'm surprised they're selling you modules without that level of support.
Mike_green wrote:Here is what we've got:
Image

And how should it be(photo from phone):
Image
The image links are broken (the forum doesn't embed images very well). Try posting them on a cloud provider of some form (DropBox, GoogleDrive. Imgur, Flickr, etc), and post a link to that.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Mike_green
Posts: 8
Joined: Wed Oct 17, 2018 6:36 am

Re: Raspiraw and AR0144 sensor

Tue Oct 23, 2018 8:03 am

6by9 wrote: Do you have a decent contact within OnSemi? I know from other projects that they have a decent dev kit which allows you to attach their modules and view the output within Windows. It also allows easy tweaking of settings, and shows the exact register set in use. I'm surprised they're selling you modules without that level of support.
Unfortunately no, it is how it is.

Second try to upload images)
What we've got: https://drive.google.com/open?id=1_fsbj ... iQwNFhAbM2
Image

What we have to get: https://drive.google.com/open?id=1jYEnq ... YRE6ZRy-Dy
Image

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7150
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Raspiraw and AR0144 sensor

Tue Oct 23, 2018 8:54 am

Mike_green wrote:
Tue Oct 23, 2018 8:03 am
6by9 wrote: Do you have a decent contact within OnSemi? I know from other projects that they have a decent dev kit which allows you to attach their modules and view the output within Windows. It also allows easy tweaking of settings, and shows the exact register set in use. I'm surprised they're selling you modules without that level of support.
Unfortunately no, it is how it is.
That's a shame as they are generally very helpful.
Mike_green wrote:Second try to upload images)
What we've got: https://drive.google.com/open?id=1_fsbj ... iQwNFhAbM2
Image

What we have to get: https://drive.google.com/open?id=1jYEnq ... YRE6ZRy-Dy
Image
Is this a mono or Bayer sensor?
That half looks like you're trying to unpack to 10 bit Bayer in Unicam which is known not to work (it chops off the 2 MSBs instead of shifting down by 2 bits). Unpacking and repacking only works when you go up in sample size.
Can you post your register set and command line? I have access to OnSemi's product portal and have grabbed the relevant datasheet for analysis. If you can't post it publicly then can you email it to me ([email protected]<this domain>)?
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Mike_green
Posts: 8
Joined: Wed Oct 17, 2018 6:36 am

Re: Raspiraw and AR0144 sensor

Wed Oct 24, 2018 2:04 pm

6by9 wrote:Is this a mono or Bayer sensor?
We've got mono one.
6by9 wrote:Can you post your register set and command line?
Here is our register set https://github.com/d-r-q/raspiraw/blob/ ... 44_modes.h, and command line kind of "raspiraw -o {path}"

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7150
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Raspiraw and AR0144 sensor

Wed Oct 24, 2018 2:52 pm

Mike_green wrote:
Wed Oct 24, 2018 2:04 pm
6by9 wrote:Is this a mono or Bayer sensor?
We've got mono one.
OK, I have now got the ISP running with mono input (ie not demosaicing it) - there's a weird interaction in the hardware between that and another block. It needs a couple of patches to be pushed to allow you to select it. I'll try to get those pushed in the next few days.
Reality is that demosaicing a mono image has surprisingly little effect!
Mike_green wrote:
6by9 wrote:Can you post your register set and command line?
Here is our register set https://github.com/d-r-q/raspiraw/blob/ ... 44_modes.h, and command line kind of "raspiraw -o {path}"
So you're running solely off the default register settings except 0x301A (the reset register)? In some ways I'm not surprised that doesn't work.

Using 0x301A as the id register also sounds like a bad idea. 0x3000 is chip_version_reg, and should read back as 0x0356 (probably need to byte swap that due to the way 16 bit reads work over I2C).

Looking further at your repo,

Code: Select all

static void raw12_to_raw8(const uint8_t *raw12, size_t input_len, uint8_t *raw8) {
    for (int i = 0, j = 0; i < input_len; i += 3, j += 2) {
        raw8[j] = (uint8_t) ((raw12[i] << 4 & 0xFF) | (raw12[i + 2] & 0xF));
        raw8[j + 1] = (uint8_t) ((raw12[i + 1] << 4 & 0xFF) | (raw12[i + 2] >> 4));
    }
}
looks highly dubious and may well account for your woes. You appear to be truncating off the 4 most significant bits of the image, which will result in very weird things. Seeing as you only want 8 bit data, then you may as well use

Code: Select all

        raw8[j] = raw12[i];
        raw8[j + 1] = raw12[i + 1];
and ignore any messing around with the least significant bits that it packs together.

Alternatively add "-hd" to the command line and use dcraw from https://github.com/6by9/dcraw to process the images.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Mike_green
Posts: 8
Joined: Wed Oct 17, 2018 6:36 am

Re: Raspiraw and AR0144 sensor

Thu Oct 25, 2018 6:48 am

6by9 wrote: OK, I have now got the ISP running with mono input (ie not demosaicing it) - there's a weird interaction in the hardware between that and another block. It needs a couple of patches to be pushed to allow you to select it. I'll try to get those pushed in the next few days.
Reality is that demosaicing a mono image has surprisingly little effect!
Appreciate for your work and help!
6by9 wrote: So you're running solely off the default register settings except 0x301A (the reset register)? In some ways I'm not surprised that doesn't work.

Using 0x301A as the id register also sounds like a bad idea. 0x3000 is chip_version_reg, and should read back as 0x0356 (probably need to byte swap that due to the way 16 bit reads work over I2C).
Yep. Thanks for your explanation, it seems that we've got kind of cutted datasheet and this register just mentioned as part of embedded data without explanation what it is
6by9 wrote: You appear to be truncating off the 4 most significant bits of the image, which will result in very weird things.
Seems that wrong camera settings leads to "black quad" at input when using MSB and gives at least something using LSB. But thanks a lot in any case, we'll take it into account when we'll set up our camera.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7150
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Raspiraw and AR0144 sensor

Thu Oct 25, 2018 11:41 am

Mike_green wrote:
Thu Oct 25, 2018 6:48 am
6by9 wrote: So you're running solely off the default register settings except 0x301A (the reset register)? In some ways I'm not surprised that doesn't work.

Using 0x301A as the id register also sounds like a bad idea. 0x3000 is chip_version_reg, and should read back as 0x0356 (probably need to byte swap that due to the way 16 bit reads work over I2C).
Yep. Thanks for your explanation, it seems that we've got kind of cutted datasheet and this register just mentioned as part of embedded data without explanation what it is
It would be worth making contact with OnSemi. If you can get an account on https://www.onsemi.com/PowerSolutions/myon/login.do for the Image Sensor Portal then you'll get the information first hand. (Accounts have to be approved by their product management chain, it's not a free-for-all).
If you are buying through official channels then I'd expect your supplier to have access, or at least be able to progress a request. Note that the register definitions tend to be in an application note and not the main datasheet. I've been reading AND9322-D for the AR0144CS (there are a couple of versions of the AR0144).
6by9 wrote: You appear to be truncating off the 4 most significant bits of the image, which will result in very weird things.
Seems that wrong camera settings leads to "black quad" at input when using MSB and gives at least something using LSB. But thanks a lot in any case, we'll take it into account when we'll set up our camera.
[/quote]
Can you put one of your full captures from raspiraw on a sharing site and I'll see what I can extract from it? I'm suspecting that the exposure time and gains are just too low.
Having had a quick read of the datasheet, registers 0x3100 (aectrl_reg) and 0x3102 (ae_luma_target_reg) appear to be the ones that may be of most use to get some images.
0x3100 = 0x13 to turn all auto functions on, and then 0x3102 to control the target illumination (the default of 0x0500 for a 16 bit value looks very low). You might be lucky and get usable values. I don't know if you want AE/AGC in the final use case, but it's worth a shot.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Mike_green
Posts: 8
Joined: Wed Oct 17, 2018 6:36 am

Re: Raspiraw and AR0144 sensor

Fri Oct 26, 2018 8:16 am

6by9 wrote: It would be worth making contact with OnSemi. If you can get an account on https://www.onsemi.com/PowerSolutions/myon/login.do for the Image Sensor Portal then you'll get the information first hand. (Accounts have to be approved by their product management chain, it's not a free-for-all).
If you are buying through official channels then I'd expect your supplier to have access, or at least be able to progress a request. Note that the register definitions tend to be in an application note and not the main datasheet. I've been reading AND9322-D for the AR0144CS (there are a couple of versions of the AR0144).
Thanks, we'll try to make contact with OnSemi.
6by9 wrote: Can you put one of your full captures from raspiraw on a sharing site and I'll see what I can extract from it?
Well, here is one of our previous full captures, without your edits: https://drive.google.com/open?id=19NSaV ... gV9JUCFGTK

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7150
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Raspiraw and AR0144 sensor

Mon Nov 05, 2018 6:24 pm

FYI I'm merging support for disabling demosaicing into the firmware.
It's slightly magic number territory as it's sharing the same control as viewtopic.php?f=43&t=175711, but the diff

Code: Select all

diff --git a/raspiraw.c b/raspiraw.c
index a8b06ee..920a072 100644
--- a/raspiraw.c
+++ b/raspiraw.c
@@ -1505,6 +1505,12 @@ int main(int argc, char** argv) {
                vcos_log_error("Failed to create isp");
                goto component_destroy;
        }
+       status = mmal_port_parameter_set_uint32(isp->input[0], MMAL_PARAMETER_CAMERA_ISP_BLOCK_OVERRIDE, ~ (1<<11));
+       if (status != MMAL_SUCCESS)
+       {
+               vcos_log_error("Failed to set ISP_BLOCK_OVERRIDE");
+               goto component_destroy;
+       }
 
        status = mmal_component_create(MMAL_COMPONENT_DEFAULT_VIDEO_RENDERER, &render);
        if (status != MMAL_SUCCESS)
should disable demosaic in the ISP.

Apologies for not getting back to you sooner, but I've just had a look at your raw image and it looks fine, if a touch unexciting.
I've uploaded the raw file with mocked up header and the output of dcraw to Google Drive
https://drive.google.com/file/d/1-Utfkz ... sp=sharing
https://drive.google.com/file/d/1LBG63m ... sp=sharing
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Mike_green
Posts: 8
Joined: Wed Oct 17, 2018 6:36 am

Re: Raspiraw and AR0144 sensor

Wed Jan 30, 2019 6:38 am

6by9 wrote:
Mon Nov 05, 2018 6:24 pm
FYI I'm merging support for disabling demosaicing into the firmware.
It's slightly magic number territory as it's sharing the same control as https://www.raspberrypi.org/forums/view ... 3&t=175711, but the diff

Code: Select all

diff --git a/raspiraw.c b/raspiraw.c
index a8b06ee..920a072 100644
--- a/raspiraw.c
+++ b/raspiraw.c
@@ -1505,6 +1505,12 @@ int main(int argc, char** argv) {
                vcos_log_error("Failed to create isp");
                goto component_destroy;
        }
+       status = mmal_port_parameter_set_uint32(isp->input[0], MMAL_PARAMETER_CAMERA_ISP_BLOCK_OVERRIDE, ~ (1<<11));
+       if (status != MMAL_SUCCESS)
+       {
+               vcos_log_error("Failed to set ISP_BLOCK_OVERRIDE");
+               goto component_destroy;
+       }
 
        status = mmal_component_create(MMAL_COMPONENT_DEFAULT_VIDEO_RENDERER, &render);
        if (status != MMAL_SUCCESS)
should disable demosaic in the ISP.

Apologies for not getting back to you sooner, but I've just had a look at your raw image and it looks fine, if a touch unexciting.
I've uploaded the raw file with mocked up header and the output of dcraw to Google Drive
https://drive.google.com/file/d/1-Utfkz ... sp=sharing
https://drive.google.com/file/d/1LBG63m ... sp=sharing
Wow, Thanks a lot man! You really helped me! Sorry for not replied sooner, I was involved in another project. with your help it works fine, but i have no thoughts why auto exposure control doesn't work when i set 0x3100 = 0x13. It works only in manual mode when i set CIT and FIT. Do you have any thoughts?

And one more question, is there a way to reset sensor via csi2?

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7150
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Raspiraw and AR0144 sensor

Wed Jan 30, 2019 8:10 am

Mike_green wrote:
Wed Jan 30, 2019 6:38 am
Wow, Thanks a lot man! You really helped me! Sorry for not replied sooner, I was involved in another project. with your help it works fine, but i have no thoughts why auto exposure control doesn't work when i set 0x3100 = 0x13. It works only in manual mode when i set CIT and FIT. Do you have any thoughts?
I wouldn't normally, but I will have a look at the datasheet when I get to the office. AE modes have worked for me in the past with OnSemi sensors.
Have you altered the target brightness? 0x3102 (ae_luma_target_reg). As noted earlier in this thread, the default looks pretty low. What results do you get with your settings?
Mike_green wrote:And one more question, is there a way to reset sensor via csi2?
No. CSI-2 is purely unidirectional (sensor to receiver). All control goes via the I2C "CCI" interface, or external GPIOs for reset pins etc.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7150
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Raspiraw and AR0144 sensor

Wed Jan 30, 2019 10:54 am

6by9 wrote:
Wed Jan 30, 2019 8:10 am
I wouldn't normally, but I will have a look at the datasheet when I get to the office. AE modes have worked for me in the past with OnSemi sensors.
Have you altered the target brightness? 0x3102 (ae_luma_target_reg). As noted earlier in this thread, the default looks pretty low. What results do you get with your settings?
OK, running up OnSemi's dev tool with a similar sensor, using near defaults and setting 0x3100 to 0x0013 gives very dark images. Set 0x3102 to 0x4000 and it behaves sensibly.

Enable and decode the embedded metadata and you'll see the applied analogue gain in 0x3060, exposure time in 0x3012. On this sensor their algorithm appears to have an issue if auto dg is enabled in that it will latch at max dig gain. Set 0x3100 to 0x0003 to only enable auto ae and ag and it all behaves sensibly.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Return to “Camera board”