I understand now @Alex-Kushleyev thanks for the explanation

@AidanGallagher , I have updated the IMX412 drivers to support stable 4040x3040 60FPS. Just for full disclosure, the camera in this mode is slightly overclocked from 2.1Gbps / lane to 2.2Gbps MIPI bit rate (voxl2 supports up to 2.5Gbps) in order to allow sufficient time between EOF and SOF. This is within 5% of the camera spec and seems to work fine.. If you do not feel comfortable using this mode, don't :). (only the specific 4040x3040 60fps mode has been changed). We are going to continue testing this mode because it allows doing things like EIS at 4K60 without losing any vertical stabilization margin. If there are any issues with it, I will report back. By the way, for best image quality, even if you don't need 4K output, but lets say 1080p, in the case of unstabilized video (no EIS), you should select 3840x2160 input and 1920x1080 output. The debayering process loses sharpness, so going from 1920x1080 RAW -> 1920x1080 RGB is going to be worse quality than 3840x2160 RAW -> 1920x1080 RGB. For unstabilized video you do not need the full frame because the top and bottom will be cropped out anyway, so reduce the waste and not select the full frame resolution (4040x3040). You can experiment using the different input resolutions to see what output quality (sharpness) you get. There is currently no option to do output sharpening when using MISP, but we will look into in the future. The down side of using higher resolution input is increased GPU usage (should not be an issue) and longer readout time (the rolling shutter artifacts will be more pronounced). https://storage.googleapis.com/modalai_public/temp/imx412_test_bins/20250409/imx412_fps_eis_20250409_drivers.zip - 4056x3040 @ 30 16.5ms readout time - 4040x3040 @ 30, 60 16.5ms readout time - 3840x2160 @ 30, 60, 80 11.8ms readout time - 1996x1520 @ 30, 60, 120 5.5ms readout time - 1936x1080 @ 30, 60, 90, 120, 240 4.0ms readout time - 1996x480 @ 30, 480 1.8ms readout time - 1996x240 @ 30, 800 0.9 - 1.0 ms readout time

@LR The 5G configuration on Starling 2 is a fairly new offering so there may not be fully representative docs live.

Hi @Tamilselvan , you can look at our Starling 2 drone, which comes with either 2 or 3 tracking cameras that can be used for VIO : https://www.modalai.com/products/starling-2 . This drone is designed for indoor navigation but also flies well outdoors. For longer flight times you might want to consider looking at Starling 2 Max. Video using triple camera VIO on startling 2 : https://www.youtube.com/watch?v=12DWDV7XCiE You could build your own drone using components similar to Starling 2, if you wanted. The main camera documentation for Starling Front End board (M0173) is here : https://docs.modalai.com/M0173/ which supports several camera options. M0173 plugs into VOXL2 directly and enables those camera configurations. If you have a custom build drone, you would need to set up PX4 tuning and VIO (Open VINS) to work with your particular camera geometry. For standard drones we have default configuration files that are provided for convenience (so it will be more work to set up the SW after you build a custom drone). Alex

Ok, thanks!

@paul-ammer , sorry for the delay. Initial version of the document that addresses latency in wifi streaming has been published : https://docs.modalai.com/camera-video/low-latency-video-streaming/ There is a lot of information there, please take a look and let me know where you get stuck. I suggest starting to experiment without updating the camera drivers (as discussed in the document), so you reduce number of variables at the beginning. You can also use the Qualcomm ISP pipeline (using hires_front_small_encoded stream) and we can discuss what MISP can be used for at another time. In general, you will find that the majority of the delay is going to be on the receiver side, with some additional delay possible in the server side after the camera pipeline (buffering of the encoded frames before sending them out - I believe gstreamer rtsp server adds some delay. voxl-streamer is based on gstreamer). Regarding the earlier question of unused streams: yes it is true that if streams like large_video, etc, are enabled but not used, they will not consume significant resources, however, if enabled, the stream specifications (dimensions) will play a role when the camera pipeline selects the camera operating mode, which should satisfy requirements of all streams. The most extreme case is when you enable the snapshot at highest possible resolution (but use the snapshot very rarely), and your video streaming resolution is relatively low - the camera pipeline will have to select the camera mode that provides the largest image size (which will be the slowest in terms of latency) and then will downscale to get the video stream of the desired (small) resolution. Please let me know what other questions you may have. I will continue updating the document in order to clarify things and based on feedback. If other users have questions, feel free to follow up in this thread. Alex

Hi @dan64 That is not the standalone Modem board variant and many other components are missing to make this work. We do not currently sell the "standalone" version of the M0090 (5G) or M0130 (4G LTE), so sadly your efforts will hit a dead end.

@Thasindu-Wickrama Hey man, I am planning to do the same on a VOXL2 powered custom build drone. Did you have any success?

@jakkkobo Thanks for the quick reply. JS, Kim

@Jetson-Nano To install the new voxl-io-server try dpkg --force-all -i voxl-io-server_0.0.5-202502191136_arm64.deb.

@Morten-Nissov Likely should all be off, it's been a while since I've had one of these come across my desk. I'll see if I can find one to reference.

@James-Strawson The failed batteries include both types, with a higher occurrence among the Gaoneng packs.

Hi @sssagara, Great to hear that it worked! I checked with our team and we suspect that the capacitor was not damaged due to a crash, but potentially a finger nail clipped it off during battery removal. Please take a note and see if that was a possibility. We will certainly work on addressing it in the future. Alex

Hi @Jetson-Nano Please see this cable page for more guidance. https://docs.modalai.com/cable-datasheets/#mcbl-00085 Doodle is one of those applications which we give customers enough to start trying it, but we encourage a custom solution to fit your application(s). Thanks! Vinny

@astro_phil px4 version: 1.14.0-2.0.68

@astro_phil can you please share a video of the issue and the esc params that you are using? Thanks! Alex

@Alex-Kushleyev After updating voxl-portal, it indeed worked. It is peculiar, because I didn't notice the tracking camera freezing before, only the calibration overlay. Thanks for the quick support!

@Alex-Kushleyev Thank you very much!

@voxl-phoenix , The M0134 ESC can work at 15A per channel (continuous) with 3S battery, however it needs direct air flow to cool it down. The limiting factor is going to be heat / temperature of the ESC, so I cannot answer your question conclusively. For example, if you enclose the ESC (no air flow) and then run 4 motors at 10-15A, then practically any ESC will overheat. If you already have the M0134 ESC, I suggest that you first figure out the maximum continuous current draw with your motor / propeller. You can do this test using our voxl-esc tools, specifically the test i would recommend is the power ramp test : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-tools/doc/low_kv_motor_tuning.md?ref_type=heads#power-ramp-test (since your motor is not low kv, you can ignore the main topic of that document, but you can see the results of the power ramp test). The maximum current should be at the maximum applied power. If you share your test plot, i can confirm that it looks OK. The power ramp test will slowly ramp ESC output power from 10 to 100% (or whatever you set it to) and will also show the RPM and current drawn. Note that ESC temperature is also provided. If you have your drone frame, you could mount the ESC, motors, propellers and secure the drone to a desk or something heavy (so that it does not fly away), then you can actually these tests on all 4 motors and monitor ESC temperature in these conditions. The tests can be run for a lot time, simulating RPMs at hover or higher RPMs. Even though the drone would be strapped down (not actually flying), most of the air flow over the ESC is usually coming from the propellers, so that would be a good estimate of ESC performance / temperature during flight testing. ESC Temperature: the critical ESC temperature would be above 105C, although i would not recommend operating above 80-90C (during normal flight) - that probably means you do not have sufficient cooling. We typically like to see the ESC around 50-60C (or less) during non-aggressive flight. If you would like an ESC that will certainly be able to handle your motors / propellers (while still needing cooling, but not as much, due to lower resistance Mosfets and other design features), you should try our FPV ESC : https://docs.modalai.com/voxl-fpv-esc-datasheet/ https://www.modalai.com/products/m0138 If you are not familiar with the voxl-esc tools, I suggest that you check the documentation there because the tools can be used to fine tune the performance and analyze performance / prevent crashes, since you can run tests and analyze data in a test environment. If you have any more questions, let me know. Alex

@Gus-Meyer It looks to be some kind of configuration issue rather than a hardware issue. If I turn on the board while pressing the S2 switch, the USB connection is recognized. But I'm assuming this puts it in some particular mode where the device isn't used normally, because I do not receive an IP on the ethernet device under this circumstance.