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

@Achyut-Sapariya That all looks normal, I'd recommend submitting an RMA and our team can diagnose the issue: https://www.modalai.com/pages/rma

@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

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

@Eric-Katzfey Yes the Mavlink Packets will be sent form PX4 running on the VOXL2 through the Trip Module and then to the Doodle, and vice versa for the data flow from the GCS to PX4. My understanding is that the Trip is just running a extension of Mavlink to allow for specific gimbal and camera commands. Also it is performing Video compression.

Hi @Chase-Riley Your best bet might be to start a new thread, that will help ensure you get more eyes on it for the best person on our side to help you along! Thanks!

@Chase-Riley the recommended approach is to use J18 ESC port directly: https://docs.modalai.com/voxl2-external-flight-controller/#voxl-2-connecting-an-external-flight-controller

@daniel-p-nikolov said in Issue recognizing camera MSU-0107 using M0135 dual camera board: Tried various setups, however, it does not see any camera connected to the VOXL2. Reply @daniel-p-nikolov I would recommend doing a custom camera config setup. What you can do here is run voxl-configure-cameras C and then vim into /data/modalai/custom_camera_config.txt and then proceed to edit the file for this port and position - so in this case it would be J7 lower info is hires, imx412, and false. Then proceed to rerun voxl-configure-cameras C again and then rerun voxl-camera-server and see if cameras are detected. There could be a mismatch occuring of the port and such when using the non custom script. Zach

@perfx I'd recommend reaching out to Ascend Engineering, they're ModalAI product experts and they'll be able to help you out: https://www.ascendengineer.com/

Hi @Alex-Kushleyev , Thank you for your suggestion. Now I understood. how to use my existing stereo, and tracking cameras on voxel-2.

@arcj can you share your working tflite configuration with M0014 and the configuration that is not working with M0025?

@Jetson-Nano Please take a look at the following links: https://docs.modalai.com/M0169/ https://docs.modalai.com/M0178/#requirements https://docs.modalai.com/voxl2-coax-camera-bundles/#mdk-m0173-1-01 [image: M0173_C26_Config.png] M0169 was built to support the new TOF sensor using the existing (at that time) flex cables and interposers, but those were not designed to carry 5V from VOXL2, therefore M0169 requires additional connector to supply 5V (which can be taken from the same APM that is supplying 5V to VOXL2). TOF V2 sensor can output much higher IR power compared to TOF V1, and the existing interposers / power rails were not designed for that, so an additional 5V input to M0169 is required. Now, with M0173 (aka Starling 2 Front End), the front end plugs into VOXL2 and makes use of the available 5V on VOXL2 (which was not possible using older interposers and extension cables). M0171 / M0178 is able to pull 5V directly from VOXL via the Starling 2 Front End. M0178 is basically an M0171 with a tab for mounting. In order to use M0178 / M0171, you have to use M0177 flex that is connected to M0173 camera front end (which plugs into VOXL2). So there is basically two options for connecting TOF V2 to VOXL2: VOXL2 -> (M0135 or M0076) -> (M0074 or M0036 extender) - > (M0169 + 5V power) -> TOF V2 VOXL2 -> M0173 -> M0177 - > (M0171 or M0178) -> TOF V2 I know that is a lot of board numbers, but hopefully that makes sense.. Alex

@John-Nomikos , 1.4 GB/s is certainly impossible for SD card write speed, so there is definitely some trickery going on here. Because VOXL2 has a lot of RAM, the cache can be substantial, but I thought that sync command would solve that issue, but apparently not. In case of writing on top of an existing file, i believe this is a bad test case because as you are changing contents of an existing file (overwriting on top of existing data), the file system needs to be updated to remove references to old data and i think it can be a bit tricky in case of these unstructured overwriting with various block sizes, etc - so this is probably why that process is slower. If you find a reliable way of testing the SD card write speed in the SD card slot, please let us know! I will play around with it as well. Alex

@John-Nomikos Edit: I swapped SD card readers (the original was UHS-I, this one is now UHS-II) and now am seeing 150-200 MB/s for both hats. Speed difference was likely caused by the card reader and not the voxl2. Still weird that there was a speed difference, but oh well

@Alex-Kushleyev, no need for super low-latency FPV, just using a higher megapixel sensor to stabilize down to what we can consistently stream down the radio link. Some form of digital gimbal would be great too, where we can steer the field of view to a specific region