@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
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

@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

@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.

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

@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

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.

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

@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.