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

@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

Hi,
during testing of the new HW version of this camera, I can observe ocassional sudden random changes (decrease) in the gain or the shutter, set by new_mgain and new_mshutter parameters.
This is an astronomy application showing the sky luminosity during the night, see the yellow marking. Because the sky is monitored by other cameras too, I can confirm that no such change in luminosity occured.
Any advice?
Milan

@veye_xumm
Yes, I got it now, no problem. Just ordered the correct one.
I assume FW cannot be upgraded by the user, right?

@veye_xumm

I understood that this is i2c.sh release version, not the HW version.

This maybe needs to be mentioned more explicitelly, to be clear.
This explains the camera behaviour.
Maybe that the script could find out the hw version itself and report if not as expected?
Thank you, anyway.

Milan

Currently, I am using the script like:

./veye_mipi_i2c.sh -w -f videoformat -p1 PAL
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 10
sleep 1
./veye_mipi_i2c.sh -w -f brightness -p1 0x07
sleep 1
./veye_mipi_i2c.sh -w -f contrast -p1 0xa0
sleep 1
./veye_mipi_i2c.sh -w -f paramsave

Milan

Hi,

I tried to follow the instructions for setting the manual gain and shutter by using the new manual exposure mode. Camera confirms that automatic exposure is not used, both new_mgain and new_mshutter are set.
However, I can see that some autoexposure algorithm is still in effect, is there detailed guidance how the command sequence should look like?

Milan

@veye_xumm
I have happened to turn-off the wifi and switch to ethernet, just to see if there is any effect. To my surprise, camera is now providing a picture without these artefacts.
No idea if this is just a HW conflict or RF interference on the FFC cable.

Milan

@veye_xumm

Thank you.
I reseated, no success.
I bought a new FFC cable, and sadly, the issue persists.

Milan

@veye_xumm
Yes, it is Pi4 4GB RAM

$ uname -a
Linux raspberrypi 5.15.32-v7l+ #1537 SMP Wed Mar 30 17:15:45 BST 2022 armv7l GNU/Linux

$ ./veye_mipi_i2c.sh -r -f hdver
hardware version is 0x 5
release date is 2020- 8-14

$ modinfo veyecam2m
filename: /lib/modules/5.15.32-v7l+/kernel/drivers/media/i2c/veyecam2m.ko
license: GPL v2
description: veyecam2m sensor v4l2 driver
author: xumm <www.veye.cc>
srcversion: 39B6CA03CC15515713EC3FC
alias: of:NTCveye,veyecam2mC*
alias: of:NTCveye,veyecam2m
depends: v4l2-async,videodev,v4l2-fwnode,mc
intree: Y
name: veyecam2m
vermagic: 5.15.32-v7l SMP mod_unload modversions ARMv7 p2v8

The capture code is taken from veye driver examples.

Milan

Hello,

I am testing the camera for astronomical application.
The gstreamer pipeline is:
v4l2src io-mode=dmabuf device=/dev/video0 ! video/x-raw,format=UYVY,width=1920,height=1080,framerate=25/1 ! v4l2convert capture-io-mode=dmabuf output-io-mode=dmabuf ! videoscale ! video/x-raw,width=1280,height=720 ! appsink sync=1

Ocassionaly, I get artefacts like the picture below. Any idea how to get rid of this?

(the green bar in the middle)

Milan