@Eric-Katzfey , Please excuse me for the confusion caused by me. Goal - my goal is to achieve continuous video stream from lepton camera connected through USB cable. the USB port I am using is Microhard. Issues I faced - During my initial testing, I was able to stream the lepton video through VLC, but the camera stream kept on getting interrupted (the camera stream ended), once I restart the uvc-service and the stream-service , it starts again. This observation was in loop. I wanted your help to solve this issue. Once you asked for the log file, I tried to replicate this test, but the stream was not working through VLC. I attached the log file. To verify the camera is working fine I tried with ffplay, the stream was working fine. I verified the MIPI camera, I was able to see the video on the voxl-portal, but while using the stream-service, it was not working on VLC. Now, I would like your help to solve the following problems Get the video stream on VLC Get the video stream to work continuously with out any interruption. Also it would be great if you clear one more query of mine, whether I can setup the USB port with any camera(which supports USB protocol), If I make necessary changes to the codes or UVC-service and Stream-service. Thank you for your patience and looking forward to response.

Hardware: VOXL2, M0154 (2023 revision), SKU TF-M0054-4-V1-C11 Software: voxl-suite 1.6.5, system-image 1.8.08-M0054-14.1a-perf, kernel 4.19.125 Camera: FLIR Boson (FLIR vendor ID 09cb), connected via UVC/USB2 directly to VOXL2's internal USB2 host port (not via M0153 MIPI adapter) Comparison unit: an older VOXL2 M0054 (2021) with the same setup DOES NOT show this problem. SYMPTOM Board hard-freezes (not a clean reboot) within ~30-100s of the camera actively streaming, when the camera is connected directly to the internal USB2 port (no hub in between). Freeze is total: kernel logging, journald, and an independent on-device background process (unrelated to camera/USB) all stop simultaneously with zero warning in dmesg/journal beforehand. No panic, no watchdog trace, no lockup/stall message — just silence. The board does not self-recover; only a manual power cycle brings it back. Confirmed via app-level logs too: buffered log writes already visible on a live tail -f are lost from disk after recovery, showing the whole system (including the kernel's own writeback) stopped instantly with no chance to flush. Observed at the moment of freeze: power LED stays solid on; camera's own LED goes dark — suggesting the camera's specific USB port power rail is what actually loses power, not the whole board. This problem happens repeatedly on two different M0154 boards, but does not happen on M0054 boards. REPRODUCTION Connect Boson camera directly to VOXL2 internal USB2 port (no hub). Stream from the camera (e.g. continuous V4L2 capture). With no USB-C cable to a host connected: board freezes within roughly 30-100 seconds, unrecoverable without power cycle. With USB-C cable connected then disconnected mid-stream: also reproduces (sometimes as a clean PMIC SMPL/UVLO reset with automatic reboot, sometimes as the hard freeze above — inconsistent). WORKAROUND FOUND Placing a plain bus-powered USB2 hub (Genesys Logic 4-port, 05e3:0610) between the camera and the internal port fixes it completely — board survives indefinitely, with or without a USB-C cable connected. This points to the internal USB2 rail feeding that port not having enough local current/transient capability for the Boson's direct USB draw; the hub's own local bulk capacitance/current-limited power switch appears to absorb what the internal rail can't. ANOTHER WORKAROUND Connect any device to the USB-C output - it can be a laptop, a USB storage device or even a USB hub with nothing connected to it. In such a case, there will be no resets. ADDITIONAL NOTES No working hardware watchdog was found on this unit: /dev/watchdog does not exist, and msm_watchdog logs "wdog absent resource not present" at boot — so any future hang, from this or any other cause, also won't self-recover. Docs note M0154 is the revision where the USB-C port's host-mode support was brought to parity with VOXL2 Mini (M0054 didn't support USB-C host the same way) — asking in case that host-mode rework touched this same internal USB2 power path. Separately, after extended testing, this unit's USB-C debug port has stopped enumerating on a host entirely (no lsusb/adb activity at all, even after full power cycle) — possibly unrelated connector/PHY damage from repeated stress, flagging in case it's relevant to the same root cause. QUESTION: Is there a known current/power budget limitation on VOXL2's internal USB2 port when powering the Boson directly (vs. via the M0153 MIPI adapter path), and did anything on that specific power rail change between M0054 and M0154?

Hi @tom, That's exactly what I was looking for, thank you!

@qqa , we have document how to achieve folder-level encryption on VOXL2 here : https://docs.modalai.com/enabling-file-encryption/ . Please let us know if you have any other questions.

@chiu-pk The LED status is good, this receiver should be recoverable assuming the wiring is correct. Could the M0184 firmware update have caused the receiver to lose its previous binding/configuration? Yes some updates will unbind the receiver. If you want to put the receiver back in bind mode and voxl-elrs doesn't work, hold the button for 5 seconds and it should enter bind mode indicated by the led status rapid double blink Is it expected that voxl-elrs ping gets no response while the receiver is waiting for binding? voxl-elrs ping should work in both cases, but to be sure try to bind and see if it works Is there a recommended recovery/reflash or reconfiguration procedure for the M0184 in this situation? Try to get voxl-elrs working if possible, if not then using the expresslrs configurator pointed to our custom fork of ELRS with a USB serial adapter that supports 420000 baud will allow you to update https://docs.modalai.com/elrs-configurator/

Hello @ישראל-בן-שלמה , Please see some options below and the recommendations at the end. For reliable VIO, we recommend dual tracking cameras. The tracking cameras are very light, so the extra 3 grams will give you lots of safety margin AR0144 is probably the best option since this is what we use. 2.2g with 80mm coax cable OV7251 camera (M0014) is probably the smallest (it is lower resolution also 640x480 vs 1280x800 for AR0144). ov7251 is EOL but it looks like we have some in stock. the weight of M0014 module is 0.5g (with the flex cable). However, to connect it to VOXL2 / mini, you would need an interposer like M0076 (0.6g) ( or M0135 (1.0g) IMX214 (M0025 module, https://docs.modalai.com/M0025/ ) may be the lightest 4K camera we have (0.7g with flex cable), but it is very old and sensor + lens quality is very far from our newer (and heavier) IMX412- and IMX664-based camera modules. Flir Boson 320 is a bit heavy too. The one i have with lens is about 23g. Most of the weight is the lens, i think. for connecting Boson to a Voxl2 Mini, you should use M0194 ( https://www.modalai.com/products/m0194 ) Boson → M0201 → coax → M0194 → VOXL 2 Mini J6 or J7? you can plug in another camera into M0194, such as AR0144 (coax version) or the IMX412 (coax version) The best option in terms of support (no EOL components) and hardware quality, would probably be: VOXL2 Mini (11g) M0195 (5.0g) -- see C43 configuration : https://docs.modalai.com/M0195/ Boson + M0201 + coax -> plugs directly into M0195. weight of M0201 + 80mm coax is 1.7g + 0.7g = 2.4g. Need to add weight of Boson! one or two AR0144 (M0166) -- 2.2g with 80mm cable (each) hires camera (IMX412) M0161 : 8.5g with 800mm coax cable Minimal Config VOXL2 Mini (11g) M0194 plugged into J7 (1.4g) + 80mm coax (0.7g) + M0201 (1.7g) + weight of Boson M0166 AR0144 (2.2g with 80mm coax) plugged into M0194 M0076 (0.6g) plugged into VOXL2 mini J6 M0025 IMX214 camera (0.7g) plugged into M0076 ** note that this is mixing the coax and non-coax cameras, but i think this should work. we would need to give this a quick test to make sure. Alex

Please update your VINS to our master branch here: https://gitlab.com/voxl-public/voxl-sdk/services/voxl-open-vins-server For epoch-synced cams, tracking AR0144, please use: https://gitlab.com/voxl-public/voxl-sdk/services/voxl-open-vins-server/-/tree/synced-timestamp?ref_type=heads

Hello. Can a Starling 2 drone autonomously fly while flying over the pipe inside a sewer? The drone must fly autonomously in a dark place to inspect cracks or internal conditions while flying along the water pipe. I'm not sure if this feature can run on Starling, so I'm asking for help!

Hello everyone, I am looking for some expert advice on a VOXL 2 companion computer setup for a long-range platform. I have two main integration challenges: Challenge A: VIO at Higher Altitudes To solve the motion blur and pixel density issues at higher altitudes, I am planning a 6-camera configuration. I want to use 4 downward-facing sensors (2 daylight + 2 IR) equipped with narrow-angle lenses, alongside 2 standard wide-angle sensors (front and rear). Could you advise on the best supported sensors (e.g., IMX series) for this? Has anyone successfully tuned the voxl-qvio-server for narrow-angle lenses, and what were the altitude limits you achieved? Challenge B: LAN Integration & WireGuard The payload data flow will be: External RTSP Camera -> Ethernet -> VOXL 2 (WireGuard encryption) -> Ethernet -> Digital RX. Because VOXL 2 lacks multiple LAN ports, I will need a miniature industrial Ethernet switch. Does ModalAI have any tested hardware recommendations for this? Furthermore, what is the best practice for routing this VPN traffic through the VOXL 2 Ubuntu environment without bottlenecking the CPU? We are currently evaluating the VOXL 2 for a broader fleet deployment and want to ensure the ecosystem can support this custom optics requirement. Any feedback on off-the-shelf solutions or standard configurations for this use case would be greatly appreciated. Thank you!

Hi, This post is quite old now, so going to mark it as resolved. If it is not, please start a new topic in the correct category for your needs. Thanks!