@Andrew-Jue Do you need voxl-vision-hub? If you aren't using VIO, obstacle detection, or offboard mode then you can disable it. And try setting en_external_ap_timesync in voxl-mavlink-server.conf to false. I think that will prevent it from intercepting those timesync messages. This is just for the onboard connection. If you use GCS connection then I think there is no intercepting of timesync messages to worry about.

@Andrew-Jue I'll take a look. Have you seen this page? https://docs.modalai.com/mavlink/ Can you try leaving voxl-mavlink-server running and try to connect to port 14550 as a "GCS" and see if that helps?

@Dronodev Using the M0065 on a UART on the WiFi add-on board may be the most straightforward way to do this. We've never tried to set one up like that but, in theory, it should work if configured correctly in px4. There is no direct way right now to send the RC channel PWM input out the VOXL esc PWM output. There are a number of different ways to approach that so we'll take a look and see if we can come up with something in the next couple of weeks.

@Andrew-Jue Unfortunately, we have never tried anything with a mocap system. I was just tracing through the code to try to see what kind of issues there might be. You can see how our voxl-mavlink-server application handles the timesync protocol here: https://gitlab.com/voxl-public/voxl-sdk/services/voxl-mavlink-server/-/blob/master/src/mavlink_services.c?ref_type=heads#L48

@Zachary-Lowell-0 An updated build can be found here: http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/voxl-px4_1.14.0-2.0.99-202504161252_arm64.deb

@Andrew-Jue I think there are a couple of issues. One is the timestamp issue. You can see here that px4 tries to align the timestamps with timesync information: https://github.com/modalai/px4-firmware/blob/2bbaa6875fedff9c9bc8282a35c4cbb5612046ea/src/modules/mavlink/mavlink_receiver.cpp#L1251. The next issue is that ekf2 doesn't deal with the mocap odometry directly, it relies on the local position estimator module to process that and that module is not included in our build.

@Andrew-Jue Have you made sure that no other service is running that can send odometry messages that conflict with to MAVROS ones? But, yes, you have a good point about the timestamps. PX4 on VOXL 2 runs on "DSP time", not apps proc time so there is a big delta (that moves over time) between standard Linux time and what PX4 uses. That's why we use the timesync protocol to align times between our applications (like VIO) on Linux with PX4 running on DSP.

@Andrew-Jue How is EKF2_EV_CTRL set in PX4?

@Rowan-Dempster No problem! Kind of primitive but effective

@Rowan-Dempster First of all, the CPU report for DSP is only an estimate. It's really tough to get a good CPU estimate due to the way it "sleeps" and it's parallel architecture. But I have seen that before where there is a difference of 10% between builds and I don't know what causes that yet. So I wouldn't be too worried about it. v1.20 only adds that debug print during startup so shouldn't be any extra risk above moving to v1.19.