@veye_xumm Thanks for the offer. While posting the Makefile I noticed I had -overlay.dtbo in the filenames. Compiling now.

@veye_xumm Thanks for having a look. I had already added those lines. However I still get the error.

As the raspberry folks have released a new kernel (20210430), I'm trying to compile the drivers for a new camera of @MK. Following the instructions, at the last build command I get the error:

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- zImage modules dtbs -j2
make[2]: *** No rule to make target 'arch/arm/boot/dts/overlays/csimx307-overlay.dtbo', needed by '__build'.  Stop.
make[1]: *** [scripts/Makefile.build:496: arch/arm/boot/dts/overlays] Error 2

What am I doing wrong? I've double checked that I did the four steps:

• add driver sources
• update Makefile and Kconfig
• add dts files
• change Makefile in dts folder

This problem seems to have solved itself, I cannot reproduce it.

I'll try to reproduce first. Unfortunately my disk was full just before midnight tonight (Murphy's law). Longer frames here are probably due to high CPU load in the rest of the pipeline. Better luck next night.

@veye_xumm Thanks, I forgot to update the script from Github

@veye_xumm Thanks for the quick fix! I've installed 2.39 and tested; the regular pattern of missed frames is now gone.

I've also tried with 2.39 in master mode, it gives a similar pattern. The regular pattern sometimes a somewhat longer read time (this pattern appears about every 48 frames) is very acceptable. Also, missing one frame in 2000 frames isn't a big problem.

Thanks again! Next problem in a next topic

@veye_xumm Changing to YUYV may be helpful for some programs that expect a grayscale image first. I noticed a new firmware version has an option for changing to YUYV. Is it already possible to enable this with an i2c command?

Another curiosity: I'm trying to record meteors at 720p@60fps, and somehow the system changed from 60fps to 30fps at exactly midnight. I didn't change anything during the capture since I was asleep. I also checked that the script on the raspberry kept running, also the raspberry did not reboot.
Could this be due to a nightly reboot of the camera? I did not specify it to reboot.

@veye_xumm Thanks for the quick reply and the workaround!

I tried setting the camera to master and redid the experiments. It seems that the cv2.CAP_V4L2 gives a slightly more constant framerate, so I'll skip gstreamer.