What commands did you use to start each one? I would try qshell mb12xx start -X -b 4 -a 0x66 and qshell mb12xx start -X -b 4 -a 0x70

Hi @Eric-Katzfey Thank you for your help! I got it to work on J19 through PX4.

@Robbie-McCue Thank you for your feedback I will look into this.

Hi @wilkinsaf Thank you for this post! I had the same issue and was able to solve it using these steps.

@Raiyan-Alam said in Is there a way to power this Wi-Fi Adapter + Radio using this specific ModalAI UART adapter board?: rfd900x Hi @Raiyan-Alam, My suggestion: keep the Wi-Fi adapter on USB and feed the RFD900X separately. You can pull an extra 5V feed using this power module cable, which splices off a 5V red JST SFHR connector: https://docs.modalai.com/cable-datasheets/#mcbl-00095 Splice from that into the RFD900X's 5V input. For the M0151, don't power the RFD900X off USB but pull it directly from the power module supplying VOXL 2 instead.

@Engineer123 You can download all the necessary flat build files from our page: [modalai.filecloudonline.com](link url). Go into flat builds folder and download the m0054(154-1) flat build file With regards to actually flashing the flat build, and using modal-qdl repo: Make sure to put the flat build file properly in a correct folder as mentioned by the doc (./qdl/qfil_app/modalai). Make sure the file is unzipped (it should be m0054(154-1)/ all the files, NOT m0054(154-1)/m0054(154-1)/....) Some users have seen a higher qdl success rate when they ran install_dependencies.sh and run.sh with sudo commands. So sudo might work better Confirm that the voxl is in edl mode

Hi @isagmz That is indeed a cap. It is a 4.7uF 25V 0603 in support of the 5V input rail when sourced by J5. [image: 1782190949170-0a20b27c-498c-4971-be16-f9c02719c08f-image.png] We have so much margin on the 5V power rail, I would not worry about one cap missing. My best advice is to clean up that area to make sure there is no FOD or ripped up pads that can cause a short on that 5V rail from the broken cap, and just keep developing. Let us know if you have any other issues. Thanks!

@Alex-Kushleyev Thanks. On the both drones, we used them exactly out of the box, no modifications. The issues we experienced before installing the ALFA adapter on the first drone. For example for the 5/8 message, the model MRB-D0012-4-V4-C28-M36-T8-K2 is using the daughter board with the BOTS chip (I think it's board MDK-M0213-1-00).

@andrek Thanks for catching it! We just updated flat builds and now it contains m0054-2!

@WesleyHavocAI Thanks for catching it! We just updated flat builds and now it contains m0054-2!

@tom got it, I think you indirectly answered my question by giving me the last valid configuration. Am I looking in the right place?: voxl sdk 1.5.0 -> system image 1.8.04 -> recipes-kernel/linux-msm/files/dts/common/m0xxx-modalai-gpio.dtsi : &soc { voxl_gpio { ... modalai,gpio-init-output-high = <0 1 53 56 57 85 86 87 88 89 124 152 157 159>; modalai,**gpio-init-output-low** = <36 37 **46** 54 55 67 82 83 84 131 153 154 155>; modalai,gpio-init-input = <48 49 50 51 52 110 111 112 113 114>; status = "ok"; }; ... }; So settings for gpio pin 46 on sentinel w/ spektrum receiver should be direction:out, value:0 assuming they aren't overwritten somewhere else.

@PatkirkMartin No, as I said a UART mapped to the applications processor would also work. PX4 has a split architecture on VOXL2 with all flight critical operations happening on the DSP and support functions such as Mavlink, logging, and data manager are on the applications processor. But there is flexibility to move functions between them as needed. So, to match the ELRS receiver with the Mavlink module you could run it on the applications processor instead of the DSP. However, you would need an expansion board that exposes such a connector.

Thanks @Eric-Katzfey ! Here is the pinout for the dev board "UART" port that includes i2C_SCL and I2C_SDA. [image: 1778773646212-0cda71eb-2c0f-4b1b-ba91-8b3862fc9763-image.png] The dev board pins 1-6 matching to J19 pins 1-6 We will give the COMPASS_DISBLMSK parameter a shot and see if that works.

@Plingaas02 Regarding odometry in voxl-mavlink-server, it will not modify timestamps on this message. There will be, potentially, VIO odometry messages going to the flight controller from voxl-vision-hub via voxl-mavlink-server and flight controller odometry messages being routed out to the GCS and to the onboard stream. The odometry messages coming from PX4 will have the DSP monotonic timestamp which is different than the Linux monotonic clock and these will drift with respect to each other over time. PX4 runs the timesync service so it can correct the incoming messages from VIO.

Hi @austin-c Sorry I missed this message somehow. I will email you to kick this off with your team.

@austin-c , The GPS driver is built for SLPI as well as APPS PROC, so you could connect it to a apps-proc UART and start the driver on the apps proc side of PX4. This was done on RB5 : https://docs.modalai.com/Qualcomm-Flight-RB5-linux-user-guide/ https://docs.modalai.com/voxl2-linux-user-guide/ Regarding magnetometer, just like with the GPS driver, you should be able to enable the mag driver to build for apps proc. Since the apps proc i2c uses standard posix interface, it should just work. However, i don't think we have ever tried it. Alex

@restore There are a few examples of code that listens for Mavlink messages in our SDK. For example, in voxl-mpa-tools, take a look at the source code for voxl-inspect-mavlink.c. https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-tools/-/blob/master/tools/voxl-inspect-mavlink.c?ref_type=heads Probably would be a good idea to run voxl-inspect-mavlink on the mavlink_onboard and mavlink_to_gcs pipes to see which one has the desired Mavlink message in it. Then create your own application that listens for the Mavlink message on that pipe.