@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.

@Eric-Katzfey we are using A doodle radio Just found that reboot -f works. It's interesting weird that the network interface seems to not go down but all the services do - and don't come back.

UPDATE I've simplified my snippet and I'm now able to "connect" to the VOXL2 via MAVSDK. It's still now working as I would expect it to, but first, here's my new script: #!/usr/bin/env python3 import asyncio from mavsdk import System target_ip="192.168.1.187" target_port=14550 async def connect_to_drone(): print("Connecting to VOXL2...") # Create a System object with specific system ID and component ID # These match the IDs we're using in the heartbeat sender print("Creating System object...") drone = System() # Different connection string formats to try print("Connecting to drone...") await drone.connect(system_address=f"udp://{target_ip}:{target_port}") print("Waiting for drone to connect...") timeout = 60 # Extended timeout start_time = asyncio.get_event_loop().time() try: async for state in drone.core.connection_state(): print(f"Connection state: {state}") if state.is_connected: print(f"Connected to drone!") return drone # Check if we've timed out current_time = asyncio.get_event_loop().time() if current_time - start_time > timeout: print(f"Connection timed out after {timeout} seconds") break await asyncio.sleep(1) except Exception as e: print(f"Connection error: {e}") return None async def main(): # Try to connect to the drone drone = await connect_to_drone() # If connected, do something with the drone if drone and drone.core: try: # Print basic information info = await drone.info.get_version() print(f"Version Info: {info}") except Exception as e: print(f"Could not get info: {e}") if __name__ == "__main__": # Run the asyncio loop asyncio.run(main()) When I run this script I see only 3 logs: Connecting to VOXL2... Creating System object... Connecting to drone... When I adb shell and run voxl-inspect-mavlink mavlink_from_gcs I now see that the VOXL2 is receiving a heartbeat: ID Mavlink MSG Name Counter Hz 0 heartbeat 5 1.1 But like I mentioned above, the code doesn't execute past await drone.connect(system_address=f"udp://{target_ip}:{target_port}"). I've tried udpout and nothing changes.

@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

@brianaustin great to hear, thanks for the update!

@Ted-Ferris What SDK are you on?

@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!

Hi @Amir-Avni, Does your silkscreen on VOXL2 show M0154 or M0054? If M0054, it's 'hard coded' as an output only... behind a uni-directional level shifter..... If it's M0154, there's a directional level shifter in front of that GPIO that allows us to (with a kernel tweak) switch between UART and SPI. By default we are configured for UART use case, and the level shifter is set to allow an INPUT, by setting GPIO 67 low (as default), which is setup in device tree here, see "67" in modalai,gpio-init-output-low https://gitlab.com/voxl-public/system-image-build/meta-voxl2-bsp/-/blob/v1.8.02/recipes-kernel/linux-msm/files/dts/common/m0xxx-modalai-gpio.dtsi?ref_type=tags#L12 To enable VOXL2 J10 pin6 (gpio46) as an input, make sure gpio67 is set to low

@andrevs01 , The documentation links I provided describe how to get M0065 board running in PX4 as a standard actuator that supports 8 PWM outputs. If you are familiar with PX4, GCS, Actuators, then look through those documentation pages and follow the setup. However, i don't have the full information about your hardware, so i don't know if you need some customizations: are you using voxl2 on a flying drone? if so, are you using a modalai ESC or another ESC? Are you planning to use M0065 board to generate pwm output for your ESC (if you are using a standard ESC that accepts PWM as control input) do you need to use PX4 for your application? the reason why I ask is that you can use M0065 pwm outputs without PX4 if you don't need PX4 at all. Alex

@valvarez , yes, this is the expected correct behavior. I believe you were initially using older M0065 firmware (version 1) as well as older PX4 build which was working with that version of M0065 (VOXL2 IO board). However that release had some issues that were fixed and you should not use firmware version 1. The older PX4 version used a different (old) driver for the voxl2-io board, and you can tell that because the debug print was very short and it accepted SW version 1: SLPI: Detected M0065 protocol version. SW: 1, HW: 35 If you see that, it means you are using outdated (buggy) software. The latest (stable) firmware is verion 2 and the corresponding PX4 driver will require that version and print out a lot more information about the board and the VOXL2_IO params. Alex

@Eric-Katzfey In my case I am receiving data as @Alex-Kushleyev explains with stty -F /dev/ttyHS2 115200 cat /dev/ttyHS2 [image: 1739568773345-e1b7860f-60b8-4441-a7f9-c4147a44b66c-image.png] and in the script in /usr/bin/voxl-px4-start I see that section @Eric-Katzfey [image: 1739568629179-6bd3d8f4-b89b-4fa6-ad40-5c58260d333b-image.png] but when it comes to running voxl-px4 it autodetects with different bauds to the GPS. Is it necessary to change it somewhere else? [image: 1739568685057-e7941c5d-6d4b-4a0c-b5ab-a9e4130ef09b-image.png] I have no problems with the MAG. It detects it perfectly. I have the RX and TX of the GPS connected exclusively to the J9 of the 5G, and the rest, to the J19. I also have the RX and TX of the IO Board connected to the RX and TX of the J19. I have also tried disconnecting the IO Board and leaving only the GPS on the J9. SOLVED: I change in the file voxl-px4-start from M0052 to M0054. Thanks!!!

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

@smilon we're still working on it but slower than I had originally planned. we're using it on a feature light product right now without camera support, once we have camera support in place I'll try to get some preview releases in place, 'hoping' that's in Q1/Q2 but as an optimistic engineer speaking

@Gary-Holmgren , oh yeah, I almost forgot about the issue of not being able to use the DSP uart ports while PX4 is running.. To work around that, you could potentially connect M0065 board to one of the UART ports that are actually connected to CPU and access it directly from linux use /dev/ttyHSx devices You can find the linux uart ports here : https://docs.modalai.com/voxl2-linux-user-guide/#uarts - you will need an expansion board, but even something like M0141 or M0151 will do (which is probably the simplest). However, it sounds like maybe you are close to figuring out he pwm output via px4, so perhaps this is not needed, but you can keep it in mind. Alex

@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

@Jetson-Nano, can you please clarify what exactly you are asking?

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!

@rogerli or @McMason Were either of you successful in getting the VOXL2 to connect to the NV Trip2? Working the same issue on my end.