VEYE-MIPI-IMX462 - manual gain not consistent

[milank]

@veye_xumm
Hi,

$ ./veye_mipi_i2c.sh -r -f hdver
hardware version is 0x 7
release date is 2023- 2- 7

This is the init script of the camera:

./veye_mipi_i2c.sh -w -f videoformat -p1 PAL
sleep 3
./veye_mipi_i2c.sh -w -f sharppen -p1 0
sleep 1
./veye_mipi_i2c.sh -w -f irtrigger -p1 1
sleep 1
./veye_mipi_i2c.sh -w -f lowlight -p1 0 # fixed 25 fps
sleep 1
./veye_mipi_i2c.sh -w -f wdrmode -p1 0 # back light mode off
sleep 1
./veye_mipi_i2c.sh -w -f denoise -p1 0xc
sleep 1
./veye_mipi_i2c.sh -w -f daynightmode -p1 0xfe # B&W mode
#sleep 1
#./veye_mipi_i2c.sh -w -f mshutter -p1 0x41 # fixed 40 ms
sleep 1
./veye_mipi_i2c.sh -w -f new_expmode -p1 1
sleep 1
./veye_mipi_i2c.sh -w -f new_mshutter -p1 40000 # fixed 40 ms
sleep 1
./veye_mipi_i2c.sh -w -f new_mgain -p1 23 # 0.1 - 0.3

Milan

[veye_xumm]

@milank
The phenomenon is indeed quite strange. We have checked the program and there is no function to dynamically adjust exposure or gain in manual mode.
Could you please confirm whether your program has called the i2c script and configured parameters during nighttime operation?
Are there any other devices mounted on the i2c bus besides the camera?

[milank]

@veye_xumm

yes, this is weird.
No other devices are connected to the I2C port (pi4, I2C-1 on pins 3 and 5).
The camera is operated in automated mode overnight, without rebooting in the morning.
The script can be ran only manually.
I have also another example, see below. Here, it happened twice in series.

[veye_xumm]

@milank

@milank said in VEYE-MIPI-IMX462 - manual gain not consistent:

The camera is operated in automated mode overnight,

I think you mentioned last time that the camera was set to manual mode instead of automatic mode.

[milank]

@veye_xumm
I mean automatic operation (start and stop capture).
According to the script, the exposure is in manual mode.

[veye_xumm]

@milank May I ask how often do you take a photo and measure the brightness?

[milank]

@veye_xumm

The camera runs in the continuous streaming mode, 25 fps.
250 frames (10s series) are used for creating the maxpixel frame.
Maxpixel frames are then used for creating the graph on the picture.

[milank]

@milank

the same procedure runs on many installations using the IP camera without strange phenomenons like on the picture.
This is the attempt to replace them by a MIPI camera.

[veye_xumm]

@milank Can you tell us about your curve generation method?

[milank]

@veye_xumm
for this, please see:
https://github.com/CroatianMeteorNetwork/RMS/blob/master/Utils/PlotFieldsums.py

[veye_xumm]

@milank

I have provided a script in the attachment which can read the sensor registers.
Can you please add a monitoring program in your system to monitor the following registers of the sensor: 0x14, 0x20, 0x21, 0x22, and 0x09.

The usage of the script is: ./veye_inner.sh -r -f sns_reg -p1 [sns_reg_addr].

Especially pay attention to whether the registers of the sensor have changed when a sudden change in brightness is detected.

veye_inner.sh.txt

[milank]

@veye_xumm

fine, understood, now it is running in the background for spoken registers.
I will come back with the results once I see the spike again.

[milank]

@milank
Another change has been detected last night, around 20:44:25 UTC.
Unfortunatelly, no change detected in spoken registers.
The reading interval was set to 5 seconds.
I am also attaching two full BMP images just before/after the change of brightness. 

03/15/2023 20:44:11 reg addr 0x14 val is 0x53
03/15/2023 20:44:11 reg addr 0x20 val is 0x1
03/15/2023 20:44:11 reg addr 0x21 val is 0x0
03/15/2023 20:44:11 reg addr 0x22 val is 0x0
03/15/2023 20:44:12 reg addr 0x9 val is 0x11
03/15/2023 20:44:17 reg addr 0x14 val is 0x53
03/15/2023 20:44:17 reg addr 0x20 val is 0x1
03/15/2023 20:44:18 reg addr 0x21 val is 0x0
03/15/2023 20:44:18 reg addr 0x22 val is 0x0
03/15/2023 20:44:18 reg addr 0x9 val is 0x11
03/15/2023 20:44:24 reg addr 0x14 val is 0x53
03/15/2023 20:44:24 reg addr 0x20 val is 0x1
03/15/2023 20:44:24 reg addr 0x21 val is 0x0
03/15/2023 20:44:25 reg addr 0x22 val is 0x0
03/15/2023 20:44:25 reg addr 0x9 val is 0x11
03/15/2023 20:44:30 reg addr 0x14 val is 0x53
03/15/2023 20:44:30 reg addr 0x20 val is 0x1
03/15/2023 20:44:31 reg addr 0x21 val is 0x0
03/15/2023 20:44:31 reg addr 0x22 val is 0x0
03/15/2023 20:44:31 reg addr 0x9 val is 0x11
03/15/2023 20:44:36 reg addr 0x14 val is 0x53
03/15/2023 20:44:37 reg addr 0x20 val is 0x1
03/15/2023 20:44:37 reg addr 0x21 val is 0x0
03/15/2023 20:44:37 reg addr 0x22 val is 0x0
03/15/2023 20:44:38 reg addr 0x9 val is 0x11
03/15/2023 20:44:43 reg addr 0x14 val is 0x53
03/15/2023 20:44:43 reg addr 0x20 val is 0x1
03/15/2023 20:44:43 reg addr 0x21 val is 0x0
03/15/2023 20:44:44 reg addr 0x22 val is 0x0
03/15/2023 20:44:44 reg addr 0x9 val is 0x11

[milank]

@milank

[veye_xumm]

@milank
Hi, we guess it might have something to do with an "extra" gain in ISP, which is a bug in new_expmode that doesn't completely turn off the automatic control of the image in ISP.
You can try to configure it with this command and then test it again

. /veye_mipi_i2c.sh -w -f brightness -p10

BTW,since you are using the camera to capture the starry sky, it is recommended that you run the following script to turn off the automatic bad point correction.

./i2c_write 10 0x3b 0x0007 0xFE
./i2c_write 10 0x3b 0x0010 0xDB
./i2c_write 10 0x3b 0x0011 0x9F
./i2c_write 10 0x3b 0x0012 0x00
./i2c_write 10 0x3b 0x0013 0x00
./i2c_read 10 0x3b 0x0014 1

[milank]

@veye_xumm
fine, thank you, I will test, my init script now looks like:

./veye_mipi_i2c.sh -w -f new_expmode -p1 1
sleep 1
./veye_mipi_i2c.sh -w -f new_mshutter -p1 40000 # fixed 40 ms
sleep 1
./veye_mipi_i2c.sh -w -f new_mgain -p1 23 # between 20 and 25
sleep 1
./veye_mipi_i2c.sh -w -f brightness -p1 0
sleep 1

special code for sky imaging, to turn automatic bad point correction off

./i2c_write 10 0x3b 0x0007 0xFE
./i2c_write 10 0x3b 0x0010 0xDB
./i2c_write 10 0x3b 0x0011 0x9F
./i2c_write 10 0x3b 0x0012 0x00
./i2c_write 10 0x3b 0x0013 0x00
sleep 1
./i2c_read 10 0x3b 0x0014 1
./veye_mipi_i2c.sh -w -f paramsave

[veye_xumm]

@milank Okay, looking forward to the results of your test.

[milank]

@veye_xumm
Hello,
now, it seems that this additional line did the trick.
No brightness drop seen anymore.
Thank you for your help.

[veye_xumm]

@milank OK. You are welcome.