@bendraper , have you considered running a docker container (VM) on your Windows machine with a minimal Linux kernel that would use the Linux drivers for NCM and create the proper network connection between VOXL2 and Linux container. Then you could potentially set up the routing table in Windows so that it can access the device via the Linux container and linux container may need to have some networking magic down as well to pass through the communication?

Alex

@Igor , sorry, we are working on restoring it.

@Gerhold-Ten-Voorde , have you considered adding a spacer between the camera sensor PCB and the current lens holder? At least for testing purposes, that should work.

I will check if we can share the lens holder part numbers.

Alex

OK, some updates..

the reason why the resolution 9216x6944 was not accepted for snapshot is that the camera pipeline has a list of allowed resolutions and that resolution was not one of them. I could add the resolution 9216x6944 to the list, but actually another resolution (9216x6912) was already supported, so i updated the ov64b driver to include that. The latest driver is available here : https://storage.googleapis.com/modalai_public/temp/ov64b/20260417/ov64b_20260417.zip

this driver has the following resolutions : 9248x6944, 9216x6944 9216x6912 and the other lower resolutions. You can use 9216x6912 since it's compatible with misp and isp snapshot.

I also added 9216x6912 resolution to the supported misp resolutions in camera server (dev branch) as well as allowed using misp with snapshot (previously it would throw an error since we thought that previously they were not compatible).

Actually, snapshot does work with raw_preview + misp, but here is a warning that gets printed continuously:

WARNING: preview buffer pool for Cam(hires), Frame(30) has 0 free, skipping request

we can work around this warning by adding the following line to the voxl-camera-server.conf for the ov64b camera. this limits the number of buffers that are queued up for the streams and resolves the warning.

"max_request_queue_depth": 6,

So with these changes, you should be able to use two configurations

preview + raw_preview + misp + snapshot small_video + snapshot

Please use the latest camera server from dev branch.

Right now, if you enable misp + small+video + snapshot, it does not work properly, but i will try it figure it out. Here is an example set up for small video + snapshot, but you can easily change it to use misp by disabling small_video and enabling preview + misp (and set auto exposure to "auto" from "isp" (auto will use misp auto exposure)).

Please try it out. I do agree that the ISP output has better overall image quality than MISP, also related to pretty significant lens shading of this small lens on ov64b. We will work on improvements of misp image processing.

For now, you just need to decide whether you need both RAW bayer and ISP JPG, in which case you cannot use small_video for streaming (until i resolve the issue). This means slightly worse image quality for live streaming. But if you are ok with ISP jpg, you can disable misp and use small_video stream for streaming.

By the way, i did not see any artifacts in the jpeg from ISP. Can you please let me know if the artifact is in every frame and where exactly it is located? or is the occurrence and location random?

{ "type": "ov64b", "name": "hires", "enabled": true, "camera_id": 1, "fps": 30, "en_preview": false, "en_misp": false, "max_request_queue_depth": 6, "preview_width": 9216, "preview_height": 6912, "en_raw_preview": true, "en_small_video": true, "en_large_video": false, "en_snapshot": true, "ae_mode": "isp", "gain_min": 100, "gain_max": 1600, "misp_width": 1600, "misp_height": 1200, "misp_venc_enable": false, "misp_venc_mode": "h265", "misp_venc_br_ctrl": "cqp", "misp_venc_Qfixed": 38, "misp_venc_Qmin": 15, "misp_venc_Qmax": 50, "misp_venc_nPframes": 29, "misp_venc_mbps": 30, "misp_venc_osd": false, "misp_awb": "auto", "misp_gamma": 1, "misp_zoom": 1, "ae_desired_msv": 110, "exposure_min_us": 20, "exposure_max_us": 33000, "exposure_soft_min_us": 5000, "ae_filter_alpha": 0.6, "ae_ignore_fraction": 0.2, "ae_slope": 0.05, "ae_exposure_period": 1, "ae_gain_period": 1, "small_video_width": 1600, "small_video_height": 1200, "small_venc_mode": "h264", "small_venc_br_ctrl": "cqp", "small_venc_Qfixed": 30, "small_venc_Qmin": 15, "small_venc_Qmax": 40, "small_venc_nPframes": 9, "small_venc_mbps": 2, "en_snapshot_width": 9216, "en_snapshot_height": 6912, "exif_focal_length": 3.1, "exif_focal_length_in_35mm_format": 17, "exif_fnumber": 1.24, "snapshot_jpeg_quality": 75 }

@rddrone , you are absolutely right, the snapshot feature was broken. We somehow missed it.

I just fixed it :

https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/commit/6e02fdf2fe6a893b1c9e102a346050dece3e1a7d

and removed references to old buffer groups

https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/commit/b84e10c326ad5abd4077c71f28c6d6a4522cc8a0

Please try it out!

Alex

@yaoyuh, sorry for the delay. It looks like we have the lenses in stock, so you could fill out the contract form for a custom order and mention part number "M10000513 - Lens for M0161 Camera without IR filter".

https://www.modalai.com/pages/contact-us

Also, you can remove the IR filter from your current lenses. You have to be a bit careful so that the pieces of filter are not spread in your work space. My suggestion would be to first place a small piece of tape on top of the filter which will keep all the pieces together if the filter breaks during removal. The filter has a rectangular shape and is attached to the back side of the lens with an adhesive in 4 corners. It should be possible to just pry it off from the back of the lens (after completely removing the lens from the camera module). When you remove the lens from the camera module, you should cover it up so that dust does not get inside and on the sensor itself.

Please note that removing the filter from the lens is not an official guideline, but you could do it at your own risk.

Please see the following post where we also discussed removing the IR filter from AR0144 (which was actually more difficult because the filter there has a round shape) : https://forum.modalai.com/topic/4826/msu-m0149-1-ir-filter

Alex

@Anthony-Kang , we are looking into this. However, initial attempts to enable Intra Refresh on VOXL2 via the OMX api did not succeed either for h264 or h265. Also h265 does not work with fixed Macro Blocks (Coding Tree Units instead), so it seems the OMX structures for this param would not work with h265.

Alex

@Alan_S The voxl-vtx repository is currently private, the source code for both voxl-vtx and voxl-vrx are contained within.

@Alex-Kushleyev Hi Alex,

Thank you for the clarification.

That makes sense regarding the accel parsing—agreed that a 4 LSB discrepancy on a 20-bit value is negligible compared to in-flight noise, but it’s good to see it will be corrected.

Appreciate you taking the time to investigate and confirm.
Igor

@Jesus-Cardenas Flat builds should be available now!!

Flat builds should be available now!!

@RoyAzriel , we were temporarily out of stock on some components and C29 configuration of Starling 2 Max is available again.

The TOF sensor kit (M0177 + M0171 + TOF Sensor) will plug in directly into M0173 camera front end and the Front camera mount already has a spot to mount for the TOF sensor. So you should be able to turn C28 into C29. See C27 here for reference how the TOF sensor is connected : https://docs.modalai.com/voxl2-coax-camera-bundles/#kit-pictures-and-descriptions

Alex

@ZuraNeb Perfect! Thank you!

I forgot to post the resolution, oops.

It was indeed turtle mode. That channel was not mapped on my remote, and I ended up having to adjust the relevant PX4 parameters to disable turtle mode entirely.

Thank you for the assistance!

@boron Please submit an RMA, https://modalai.com/rma and just refer to this thread. Include your shipping information and we'll send you a new one