Hi @Nathan-Sizemore No, that is a behavior we know about, but does not impact peripheral mode (due to a diode "OR" inside the circuits). We are taken steps to change this behavior on future designs to allow full OTG support. However, Voxl2 M0054 does not have that, and can only function as device/peripheral on that port. When a PC/Host plugs in, the VBUS from that host is then detected by the Power Mgmt ICs (PMICs) to enable proper peripheral mode. We know that this behavior of VBUS is not ideal, but as just mentioned we will improve it later.

@Eric-Katzfey I've been stuck on travel for the past month but happy to report that your solution worked! input_rc is publishing and I was able to calibrate in QGC.

@Tamas-Pal-0 That sounds like a good question for the PX4 community. We don't have any experience flying with a distance sensor but I'm sure others in the PX4 community do this all the time.

@Aks You should be able to run two. But, again, we have never tested.

Because on my voxl2 it seems that neither this configuration nor the 2TOF2 configuration is possible... [image: 1680703429182-screenshot-from-2023-04-05-16-02-47.png]

https://docs.modalai.com/voxl2-io/

@modaltb thank you for your answer. For so far I can see my program is the same. I'll take some more indepth look when I'm at work again. Is there some .so file I've got to include in my cmakelist? I've already tried every possible combination that's out there. Hope we can fix this soon.

Outstanding!

That's cool! We have never tried that tool. Do you have instructions or a pointer as to how it works?

I tried adding the .so file to the hellocl example, and got the following error: /usr/lib/gcc-cross/aarch64-linux-gnu/7/../../../../aarch64-linux-gnu/bin/ld: warning: libcutils.so.0, needed by /usr/lib/../lib/libOpenCL.so, not found (try using -rpath or -rpath-link) /usr/lib/../lib/libOpenCL.so: undefined reference to `property_get' and when adding it to our OpenCV application, OpenCV still cannot find any OpenCL devices. I suspect OpenCV needs to be recompiled with the .so file in the docker image. This issue is not immediately pressing, so if you intend to update the voxl-cross image I can wait for that instead of trying to create a fix.

Sensor ID 0x003D is a ToF right? Seems like you have a Tof and Tracking, but you are trying to use a configuration for tracking and hires (4). https://docs.modalai.com/voxl2-camera-configs/#c4---tracking-and-hires-only

Hi, we have it on our roadmap but not defined release, we're hoping to do this over summer time. There's a pending Ubuntu 20 release from Qualcomm that we can use but need to port it over to our platform etc.

Hi @Aks, That makes architectural sense to try out! Let us know how it works!

@Noe-Medrano scp is a basic linux utility so you should be able to find solid documentation on it's usage, but you can do the following to download a single file: scp root@VOXL2_IP:/data/px4/log/FILE_NAME HOST_PC_DIRECTORY

Hi @modaltb Travis, it took me a bit to have time to get back to this, but I've confirmed the problem. There was a short between input and ground in the small 4-pin GH connector I was using to connect to the VOXL2 IO board. Given I just found that laying around, I should have caught this earlier. Thanks for your help! I can confirm that the PX4IO app does see the R9SX input now. I'll also refer to your other post soon about trying to setup the Graupner GR-16 as I'll be moving to that this summer.

Hello @MartinP , I believe here is what is happening in your case: Your sensor (Lidar) is sending data continuously without any breaks (360 degree lidar?). Maybe the Lidar processes each measurement and sends it out right away, so perhaps there are small breaks between the data measurements The hardware UART buffer size in VOXL2 is set to 2048 (based on the data chunk size you get) You are using the High Speed uart port (HS in the ttyHS1), which uses DMA to transfer data to cpu (one cpu interrupt per buffer) Typically, the DMA-based UART hardware decides when to send the data to CPU when one of several conditions is met: there is a long enough break in the data stream that can be considered end of "packet" or the current data buffer is full (2048 in this case) Since it looks like the data from Lidar is coming without long breaks, I see several possible solutions: If possible, configure the Lidar to have a break between each scan (but you would need to know the minimum break size for UART hardware to trigger a rx interrupt to CPU) reduce the rx buffer size for UART (probably somewhere in the Device Tree) However, it would be helpful to understand what the data transmission from Lidar looks like. Also, please note that increasing the baud rate of the communication will probably not help. Significantly increasing the baud rate may result in potentially rx interrupt triggering on each measurement, which would not be very good for the CPU.

@m1baldwin With that platform release PX4 crashing causes ADB to crash as well, so that's one possibility. (This is fixed in future releases) If it was a camera issue, that would be low level device tree code causing the crash

Thanks for the response. It worked !!