So I'm guessing this has to do with the following I noticed in the changelog: 1.7.4 (voxl2_SDK_1.1.3) BSP: add voxl-fysnc-mod kernel module add voxl-gpio-mod kernel module --- GPIO now exporting to /sys/class/gpio convert SE13 from 4W to 2W UART, freeing GPIO36/37 add voxl-platform-mod kernel module --- see /sys/module/voxl_platform_mod/parameters add new target 'M0054-2' support (same rootfs as M0054-1) new kernel new devcfg.mbn In system image 1.7.1 (SDK v1.1.2) on the drone that has no rc issues, recipes-kernel/linux-msm/files/dts/common/m0xxx-modalai-gpio.dtsi has: &soc { b2b_conn_gpio_init { compatible = "modalai,voxl-b2b"; pinctrl-names = "default"; pinctrl-0 = <&tck22912G_ctrl_pin &b2b_pin7 &b2b_pin9 &b2b_pin17 &b2b_pin19 &b2b_pin38 &b2b_pin40 &hs_b2b_pin41 &hs_b2b_pin42 &hs_b2b_pin43 &hs_b2b_pin44 &hs_b2b_pin46 &hs_b2b_pin47 &hs_b2b_pin50 &hs_b2b_pin51 &hs_b2b_pin78 &hs_b2b_pin79 &hs_b2b_pin80 &hs_b2b_pin81 &hs_b2b_pin82 &j10_lvl_shf_ctrl_pin>; status = "ok"; }; rc_in_enable_init { compatible = "modalai,voxl-rc-in"; pinctrl-names = "default"; pinctrl-0 = <&rc_in_3v3_en_pin>; status = "ok"; }; }; In image 1.7.4 (SDK 1.1.3), recipes-kernel/linux-msm/files/dts/common/m0xxx-modalai-gpio.dtsi: &soc { voxl_gpio { compatible = "modalai,voxl-gpio"; pinctrl-names = "default"; pinctrl-0 = <&tck22912G_ctrl_pin &b2b_pin7 &b2b_pin9 &b2b_pin17 &b2b_pin19 &b2b_pin38 &b2b_pin40 &hs_b2b_pin41 &hs_b2b_pin42 &hs_b2b_pin43 &hs_b2b_pin44 &hs_b2b_pin46 &hs_b2b_pin47 &hs_b2b_pin50 &hs_b2b_pin51 &hs_b2b_pin78 &hs_b2b_pin79 &hs_b2b_pin80 &hs_b2b_pin81 &hs_b2b_pin82 &hs_b2b_pin95 &hs_b2b_pin96 &j10_lvl_shf_ctrl_pin &rc_in_3v3_en_pin &ds2_led_red &ds2_led_green &ds2_led_blue &id_som_1 &id_som_2 &id_mai_3 &id_mai_4>; 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>; status = "ok"; }; voxl_fsync { compatible = "modalai,voxl-fsync"; pinctrl-names = "default"; pinctrl-0 = <&camera_sync_110 &camera_sync_111 &camera_sync_112 &camera_sync_113 &camera_sync_114>; status = "ok"; }; }; And then in image 1.8.06 (SDK v1.6.3) that is on the drone with the bind issues, recipes-kernel/linux-msm/files/dts/common/m0xxx-modalai-gpio.dtsi: &soc { voxl_gpio { compatible = "modalai,voxl-gpio"; pinctrl-names = "default"; pinctrl-0 = <&tck22912G_ctrl_pin &b2b_pin7 &b2b_pin9 &b2b_pin17 &b2b_pin19 &b2b_pin38 &b2b_pin40 &hs_b2b_pin41 &hs_b2b_pin42 &hs_b2b_pin43 &hs_b2b_pin44 &hs_b2b_pin46 &hs_b2b_pin47 &hs_b2b_pin50 &hs_b2b_pin51 &hs_b2b_pin78 &hs_b2b_pin79 &hs_b2b_pin80 &hs_b2b_pin81 &hs_b2b_pin82 &hs_b2b_pin95 &hs_b2b_pin96 &j10_lvl_shf_ctrl_pin &rc_in_3v3_en_pin &ds2_led_red &ds2_led_green &ds2_led_blue &id_som_1 &id_som_2 &id_mai_3 &id_mai_4 &camera_sync_110 &camera_sync_111 &camera_sync_112 &camera_sync_113 &camera_sync_114>; modalai,gpio-init-output-high = <0 1 53 56 57 67 85 86 87 88 89 124 152 157 159>; modalai,gpio-init-output-low = <36 37 54 55 82 83 84 131 153 154 155>; modalai,gpio-init-input = <48 49 50 51 52 110 111 112 113 114>; status = "ok"; }; voxl_fsync { compatible = "modalai,voxl-fsync"; pinctrl-names = "default"; status = "ok"; }; }; So the gpio initialization process changed and rc_in_enable_init was removed between SDK v1.1.2 and v1.1.3, and between SDK v1.1.3 and v1.6.3, GPIO pin 67 got moved from modalai,gpio-init-output-low to modalai,gpio-init-output-high and GPIO pin 46 got removed from modalai,gpio-init-output-low. https://gitlab.com/voxl-public/system-image-build/meta-voxl2-bsp/-/commit/538c324713548174c8c1694680e9cba7f2d47bcb https://gitlab.com/voxl-public/system-image-build/meta-voxl2-bsp/-/commit/ccd3893e062b03d05885da5a279be2f8d2f6c97c Idk which change is responsible for the binding issues. I'd like to avoid flashing v1.1.3 to narrow it down. Can someone explain how the pins are meant to function for my set-up (M0094 + M0054, rc already bound)?

@Vinny Perfect, thanks!

@jmltt SDK testing for Sentinel ended at SDK 1.4.0 That doesn't mean that newer releases won't work, it just means we don't put it through the SW QA testing cycles that we do with our newer platforms. You likely won't see any major performance improvements on Sentinel with newer SDK releases but there may be some nice quality of life additions such as helper scripts, voxl-portal updates and others. If you have any questions about any specific packages feel free to ask.

@tonygurney , I am assuming that you are using the ESC hardware version M0134 (you can confirm using voxl-esc scan tool. Here is the datasheet for M0134. https://docs.modalai.com/modal-esc-datasheet/ This ESC has an option (via installing a 0 ohm resistor) to provide 3.3V to pin 1 of J3. This is the same voltage that is used for the MCUs that run on the ESC and should be used with caution (if this voltage rail is brought down by overloading, the ESC will shut down). Please see image below that shows where 0 ohm resistor should be (carefully) installed to enable 3.3V on pin1 of J3 (marked in red) [image: 1753107113526-m0134-diagram.jpg] If you actually wanted 5V (VAUX), that is available on the other side of the board via two test points at the edge of the board. This voltage rail is provided by a separate switching regulator. See the following section : https://docs.modalai.com/modal-esc-datasheet/#neopixel-led-support If you REALLY need 5V to be present on pin1 of J3, then you can add a small wire jumper from the VAUX test point directly to the pin1 of J3 (which is marked with a white dot). This pin 1 of J3 is normally disconnected. Please only do this if you are comfortable performing this type of soldering and we cannot guarantee the results :). Alex

@Eric-Katzfey Awesome, thanks for the feedback!

@groupo We also had this issue, but we had modified the sentinel and was found to be more due to vibrations https://discuss.px4.io/t/stopping-compass-mid-flight/42808

@AndriiHlyvko, I just ran into the same issue while testing Boson (in my case I was testing the 16-bit Boson streaming mode). The libuvc issue caused a crash, since i did not use a fixed version of libuvc. However, what actually caused the buffer overflow was the fact that Boson was reporting smaller buffer requirements for RAW16 during query (it was reporting width * height * 1.5 , just like for YUV, but actual frame size was width * height * 2, so uvc pipeline allocated smaller buffer and overflow happened with the full frame came in. Was this the same issue with your Boson tests or did you experience something else? Thanks! Alex

@Paul-Carff I believe the way to add channels is via the controller itself - the receiver on the VOXL2 should not require any update in config to take in more channels - from this point its configuring the controller to allow it to use more channels Zach

@soraminds , VOXL2 supports SoftAP mode (access point), so you can set up your drone(s) to be access points and that should allow your ground sensors to connect to the drone. See https://docs.modalai.com/sentinel-user-guide-connect-network/ , specifically see usage for voxl-wifi: voxl-wifi softap Usage -- voxl-wifi Description: Configure the Wi-Fi mode. Usage: voxl-wifi getmode Print the current Wi-Fi mode (softap or station) voxl-wifi softap <ssid> [password] Set Wi-Fi to 2.4ghz access point mode (ch6). Default password is '1234567890' voxl-wifi softap5 <ssid> [password] Set Wi-Fi to 5ghz access point mode (ch149). Default password is '1234567890' voxl-wifi station <ssid> [password] Set Wi-Fi to station mode and connect to the access point with the given SSID and password (if provided). voxl-wifi factory Set Wi-Fi configuration to factory defaults. This will set the Wi-Fi to 5ghz access point mode, with SSID 'VOXL-[MAC address]' and password '1234567890'.

@tom Thanks, Tom! We appreciate the support and the reassurance about VOXL 2's processing power. It's great to know there's room to explore its capabilities further. We'll definitely reach out if we have more questions—thanks again for being a resource we can count on!

@spiff And if you turn it off and power cycle does it show up with lsusb?

I suspected probably it is because of the fused local position by vision and searched in parameter. It sounds EKF2_GPS_CTRL is probably relevant. So, I set it to be 0 from 7. After trying that, my outdoor missions were all smooth without any accident. I then set it back to 7 and tried flying in position mode. This error happened again and with altitude mode was forced. So, anybody here know how to fix the problematic local position estimate? This is an AI drone and it shouldn't perform worse than drones without any vision.

@soraminds https://forum.modalai.com/post/19601

@tom I found the voxl-modem script in usr/bin, thanks! Swapping out the logic in the microhard_configure function with the v1.1.0 sdk revision worked for me. My only suggested change would literally be reverting to the exact same logic for that function as was used in the previous version. I'm assuming it was changed for a reason,but idk what that reason is. I guess my question was more "why did this change and can we just change it back?". Is that more something I should raise as an issue on the gitlab repo or should I just submit a merge request like you said and let you guys figure it out? Sorry not sure what best practices are when raising these kinds of things