@veye_xumm when i run ./make.sh i get

i2c_read.c: In function ‘main’: i2c_read.c:112:42: error: passing argument 4 of ‘i2c_rd’ from incompatible pointer type [-Wincompatible-pointer-types] 112 | i2c_rd(fd, device_addr,reg_addr, &value, num); | ^~~~~~ | | | unsigned char (*)[512] i2c_read.c:20:68: note: expected ‘unsigned char *’ but argument is of type ‘unsigned char (*)[512]’ 20 | static int i2c_rd(int fd, uint8_t i2c_addr, uint16_t reg, uint8_t *values, uint32_t n)

@veye_xumm can you specify what I need to do?

@veye_xumm said in Can't get v4l2 to work, rasbperry pi 4b, rpi os x64, 6.12.57-v8+:

make

deleted the folder raspberrypi_v4l2
reinstalled by github

c927e276-18bd-4eae-8f78-c5f81705ce1a-изображение.png

I have no idea why it doesn't work.

096ba0ad-8b6b-4b2c-8b35-7dcaabb7cdb8-изображение.png

Which one do I use?

@nkos Cheers!

@john
We compared the baseboards of the J401 and J401B and found no differences. Regarding the earlier issue with the J401, we suspect that the USB hub chip, which is mounted on the same I2C bus as the camera, was intercepting responses for the I2C address 0x3b. This aligns with your hypothesis.

Could you visually inspect the J401B and check if there are any version or sub-model changes in the USB hub chip compared to the J401?

Regarding your intention to test the response issue at address 0x22, you do not need to recompile the device tree blob (dtb). You can directly use the command i2cdetect -y -r i2cnum to perform the test.

@veye_xumm Hi,
Firmware update does not solve the problem, after software reset auto exposure mode works normal

@nimadibaj
You have implemented the function of writing 0xff to 0x000b. Similarly, proceed to write the subsequent registers as well.
The method for writing the subsequent registers is the same as that for writing the 0x0b register, but they must be written in sequence.
Addr--->data
0x10 0xDE
0x11 0xC2
0x12 0x00
0x13 0x00

@nkos I will attempt to build a 6.x version system based on the original BSP approach.

@veye_xumm

Hello my friend.
We are sending I2C commands via a FPGA.

1_ Writing 0xff to 0x000b solved our problem. Thank you. Please give us a command to save this change.

2_ We are trying to change video frame rate (now is 30fps and we need 25fps).
by these commands we cannot do this :
0x10 0xDE
0x11 0xC2
0x12 0x00
0x13 0x00
(sending Two byte, then sending next two byte and ... ).

Please guide me. Thanks a lot.

@deepcamera

Only ISP-related parameters can be persistently saved after power-off through the paramsave command. Therefore, I recommend that you reconfigure your desired parameters in the startup script during program design.

As for which commands can be saved, you can refer to the veye_mipi_i2c.sh source code. If the corresponding read/write functions contain operations like './i2c_write $I2C_DEV $I2C_ADDR 0x10 0xDA', it indicates that the function's register belongs to the ISP category and can be saved using paramsave.

@lpcq2000 抱歉现在MCU bypass模式已经不再被支持了。我们的资料有一些迟滞，回头会更新到上面。

@siderat I think this one will work.

@barbanevosa
Please refer to part8:
https://wiki.veye.cc/index.php/Mv_series_camera_appnotes_4_jetson/

@stiwana

@stiwana said in MV-MIPI-GMAX4002M compatibility with Jetson Xavier NX, Orin NX:

Can I use the commonly available RPi-zero Mipi camera FPC to connect the camera to Jetson Orin NX?

Yes.

@stiwana said in MV-MIPI-GMAX4002M compatibility with Jetson Xavier NX, Orin NX:

Is there anything else I can do to increase the low-light performance? Did i miss another setting that can help?

To improve performance in low-light conditions, the main methods are:

Use a lens with a smaller F-number. In either automatic or manual exposure mode, extend the exposure time to the maximum duration you can tolerate. (Note that the exposure time cannot exceed the reciprocal of the frame rate, so you may need to adjust it accordingly based on your specific situation.) Increase the gain.

@stiwana said in MV-MIPI-GMAX4002M compatibility with Jetson Xavier NX, Orin NX:

I do notice that at higher gain the images get these fixed patterns probably due to the FPNU or PRNU of pixel array. Is there a way to do a calibration on the image sensor to make the image response more uniform?

Sorry, we don't offer this algorithm yet.

@stiwana said in MV-MIPI-GMAX4002M compatibility with Jetson Xavier NX, Orin NX:

Is there any gstreamer pipeline I can use to get 12 bit image stream out and display it as 8bit in real time?

Sorry, we don't provide this kind of program either.

@veye_xumm sorry for necro-posting, but this method stopped working. on fresh system I have Failed to set I2C address after running make.sh under mv_tools_rpi/sources on rpi5. do you know if something has changed there?

@lozinski Sorry, we currently do not have products that meet your requirements. The VEYE-LVDS-327 has been discontinued for a long time.

@mparem
https://github.com/veyeimaging/rk35xx_orangepi/releases/tag/v1.2_mvcam_tablet_cm5
Please try this image file on cm5-tablet.

@barbanevosa
The issue occurs because the camera sensor outputs a resolution of 3088 × 2064, but the receiving side (V4L2 buffers) aligns each line to a stride of 3136 bytes for memory alignment. When OpenCV is used directly with cv2.CAP_V4L2, it applies the width setting (3088) both to the sensor and to the buffer interpretation. Since the actual buffer has padding (3136 vs. 3088), OpenCV misinterprets the data layout, which results in visible image artifacts (stripes).

We recommend using a GStreamer pipeline to handle the stride and alignment internally, so that OpenCV receives a clean image with the correct resolution.

@veye_xumm 好的 一定

@jhaijun 不好意思我们这个论坛是只针对我们公司自己产品的。 sony 机芯的话确实没有搞过。

@goooofy 好的。