ModalAI Forum

@voxl-phoenix , this may be a hardware issue because VOXL2 will boot just fine without M0173 camera front end plugged in (if the hardware is OK). It is possible that one of the camera connectors (where M0173 plugs in) has broken off or is loose, causing a hardware failure. If you would like a better diagnosis, please share a video of the voxl2 not booting, so we can see the LEDs (i realize there are green leds on top and bottom, but the way your image shows, you can see both of them. Also, in this non-booting state, does the VOXL2 show up as any USB device when plugged into a linux machine using the main USB C connector? Alex

@voxl-phoenix , I think you also mentioned that you tried swapping the cables between tracking and imx412 camera, right? If so, it seems something got damaged in the IMX412 camera during connecting / disconnecting. For disconnecting the cables, we suggest using a special tool, please see https://docs.modalai.com/micro-coax-user-guide/#-proper-cable-and-adapter-handling- . Also, it is hard to say for sure where exactly the issue is - M0173 board or IMX412 camera. the only good way find the cause is to replace components one at a time. Just to elaborate on the symptoms that you are seeing : voxl-camera-server -l command essentially probes all the cameras (based on the sensormodule files located in /usr/lib/camera). Probing involves turning the camera on via the reset GPIO and attempting to talk to the camera via I2c interface. If the camera responds, the probe is successful, otherwise failed. In your case, the probe of IMX412 failed, which means either the camera could not be turned on for various reasons or the i2c communication was not working. If you have another tracking camera AR0144, you could connect it instead of the IMX412 and see if the probe succeeds. You would need to add /usr/share/modalai/chi-cdk/ar0144/com.qti.sensormodule.ar0144_1.bin file to /usr/lib/camera (which is the AR0144 sensormodule for the camera slot 1, where the IMX412 is currently connected). Then if you run voxl-camera-server -l and detect two AR0144 cameras (3 cameras total) then i2c communication and power should be working). Alex

@Federico-Wyrwal , please check the instructions for setting up EIS, specifically https://docs.modalai.com/camera-video/electronic-image-stabilization/#minimal-software-setup The latest drivers can be downloaded from here Please let me know if you have any other questions. Alex

@Ted-Ferris What SDK are you on?

@brianaustin great to hear, thanks for the update!

@Eric-Katzfey , @MikeD and I were able to resolve the issue by swapping pins 2 and 3 on the MCBL-00091. We found the following post on the forum: https://forum.modalai.com/topic/3511/serial-port-closed-and-other-hitl-errors. One of the posts notes that in order to use the MCBL-00091, pins 2 and 3 need to be swapped. This appears to be documented here: https://docs.modalai.com/cable-userguides/#m0163-4-pin-jst-to-4-pin-jst-cross-over-example. Thanks for your help!

@Kessie Excellent, glad to hear you got it working! And thanks for adding the details on what you had to do to the posting!

@Eric-Katzfey Or update to a newer compiler. I just tried this one: https://developer.arm.com/-/media/Files/downloads/gnu/14.2.rel1/binrel/arm-gnu-toolchain-14.2.rel1-x86_64-aarch64-none-linux-gnu.tar.xz and it fixes that issue. But then it fails on a couple of other issue in septentrio.cpp that are easy to fix. So the solution is probably to upgrade the compiler and then fix the new reported errors in septentrio.cpp.

After trying the web interface as well as command line I am still not able to successfully flash the image. I keep getting the same error above. Regardless of what position the switch is on the device only shows up in QDL mode. If there is no other method for force flashing the device (There does not appear to be any physical switch or button other then the one) do I need to submit an RMA? This device worked fine and was finally able to get the cameras and everything working and it just stopped allowing adb and not showing up on my Linux PC. bummer

@astro_phil , unfortunately if the device is not automatically being detected by VOXL2, you may be on your own in terms of building the kernel module for it. Please search the forum for building kernel modules, as some users have tried this. Specifically, this one : https://forum.modalai.com/topic/3841/voxl2-kernel-version/ and maybe a few others as well. Alex

Hi @wetherbeej Oh yikes.. You should really work with us on that change. There is a high likelihood to damage your VOXL 2 and the MEMs sensors are likely all broken now from the extra reflow cycles. Flash provisioning is all done over QFIL tools, not PCAT.

Hi @Alex-Kushleyev , Thank you very much for such a detailed reply, we will carefully refer to your suggestions to make the purchase. thanks again!

@jklre , one way to achieve what you need is to set up a VPN client on VOXL2 (and VPN server on your linux server) and create a adb TCP bridge via adb forward or reverse (which you already found). Your VPN client would connect to the VPN server on your linux server via the ADB TCP tunnel. The VPN client / server would then take care of proper data routing (just like regular VPN). I believe guys from Ascend Engineering were able to to achieve this : https://ascend-engineering.gitbook.io/modalai/sharing-internet-over-adb but it requires initial internet connection to set up. Your best bet may be to get all the dependencies downloaded to your linux server, then push them to voxl2 via ADB, and add a local package source for apt on voxl2 (so that it can find new packages) and install. Similarly for python modules, you should be able to do an offline install, i think.. Alex

@voxl-phoenix J19 has pins for 2 UARTs. We put GNSS on one and RC on the other. So if you are able to hook up everything correctly, configure the TBS crossfire receiver correctly, and configure PX4 correctly then it should work.

@Peter-Milani Nothing available for the public just yet but I can tell you we're working extremely hard on this and hope to start publishing builds soon

@Dhatchayani-L It appears that your board is booting into QUSB_BULK mode, which will require following the unbricking process to resolve: https://docs.modalai.com/voxl2-unbricking/#unbricking-your-voxl-2

Hi @cobbp It's the 2.96V directly from the Snapdragon PMIC as you noted, and SD Cards from UHS I and onward negotiate their link speeds and I/O voltage. So, a proper 1.8V SD card will internally use that 2.96V and create the 1.8V I/O rail. For cards that operate at "3.3V", they are claimed to be supported in the Snapdragon chipsets at this lowered ~3V rail. The slot on M0062 actually accepts UFS or uSD. For more details on just the SD portion, please see this design where we opened our Schematics. In this case, this is just uSD, but otherwise matches the M0062 exactly for uSD functionality: https://docs.modalai.com/voxl2-dev-test-board/ Hope this helps!

@Vinny Thank you for your info. I will review with my team and see if it makes sense for us to pursuit that direction/option. Best Regards, -Henry

@tom Is there a way to voxl-logger the outputs from voxl-inspect-cpu and play it so that I can see the graphs on voxl-portal? Currently I can only voxl-inspect-cpu or view the graphs in real-time on voxl-portal, but I would like to record the data when the drone flies and review it post-flight