@Eric-Katzfey I've seen this gps_dump uorb not get recored because the default is to request optional logging. https://github.com/modalai/px4-firmware/blob/8d26285b2362354092aca88716c70d48a3c62ea2/src/modules/logger/logged_topics.cpp#L73
change to add_topic fixes that.

@groupo if you want to do something like PPK processing on raw GPS phase data then you need to change the GPS driver submodule. Upstream default explicitly disables msgs such as UBX_RXM_RAWX. I don't know why. Would be useful functionality to have the dump param turn on raw data for devices that support it.

Only other useful data without code change is satellite_info that will give carrier to noise ratio to diagnose GPS issues. But it's only published if GPS_SAT_INFO is set to 1 and recorded if bit 5 of SDLOG_PROFILE is high.

@groupo From the description it's hard to tell if the GPS stopped communicating or stopped getting a usable solution. L1 GPS is very easily degraded by RF interference from high speed signals on wires or communications devices. Look at the jamming_indicator field in the sensor_gps uorb to get a better sense of if you have a RF interference issue. Value much above 40 indicate too much interference. Grounding and shielding the wires from the voxl2 to the GPS can improve this.

There is a bit more confusion in that px4 health checks by default need > 7 satellites in use to say system has GPS (==> GPS working but not good enough), or EKF2 can reject good GPS and report no global position in situations where vibration or magnetic interference is the underlying problem.

I'd recommend sharing more details from the sensor_gps output or a ulg file so folk can help further.

@restore Unfortunately that looks to be a PX4 issue unrelated to VOXL2. Your vehicle is lightly loaded hovering below 20% throttle. The combination of low throttle and relatively high vertical acceleration vibration while descending in altitude mode triggered a false landing detection.

@Eric-Katzfey https://github.com/modalai/px4-firmware/pull/42

@Eric-Katzfey the test deb file was just voxl-dev branch with the one line change to accept (0x02|0x01) protocol bytes with the error output shortened below 80 characters + debug print bools and macros in DSM parsing forced on. I can fly that one line change on a Sentinel to look for any unexpected consequences. It'd be great to coordinate on how to get such a change merged into the dev branch and a non-debug deb to Chase.

@Chase-Riley I didn't realize that had changed in V1.0. If you have access to a an alternative px4 fmu you could use the QGC pairing function to change the spektrum mode connected to that fmu and then plug it back into the voxl2. That could help check if one of the three options is more reliable. I'm not sure why you saw different data packets on a restart. Need to resolve that or try a different transmitter.

@Chase-Riley In the first of these two runs you were getting 0x01 protocol byte like I see on my DX7 transmitter. In that state with this binary you should see rc_input uorb messages and be able to try the Radio Calibration tool tab on QGroundControl.

In the second run you're seeing 0x00 protocol byte and unfortunately I'm not sure what that means.

If you can get the first case working repeatedly using one of the voxl-bind-spektrum options -t -f -s then we're on the path to a fix. Which did you use and have you tried them all?

@Darshit-Desai the recommendation to learn about tf, urdf, and xacro in ROS was because that's a way to achieve what you're asking for. If you get the launch and config files right then ROS tools such as rviz will do what ever you want without writing any code.

@Chase-Riley Here's a debug deb to try while you're working out building custom voxl-px4 voxl-px4_1.14.0-2.0.50_DSMDEBUG_arm64.deb
It'll print out a bunch of info if you stop the service systemctl stop voxl-px4 and run voxl-px4 manually in a shell. If the 0x01 protocol byte is the issue you're having, then this version will start publishing RC data to uorb/mavlink. Otherwise, at least you'll be able to see what the raw data packets look like.

@Eric-Katzfey changing to accept 0x01 or 0x02 in rx_buf[1] appears to make my DX7 transmitter work. input_rc -> RC_CHANNELS shows up and starts/stops when powering the transmitter on/off. Any thoughts on if this is an acceptable change?

} else if (((newbytes != DSM_FRAME_SIZE) || ((rx_buf[1] & 0x0F) != 0x02)) && (! first_correct_frame_received)) {

to

} else if (((newbytes != DSM_FRAME_SIZE) || (((rx_buf[1] & 0x0F) != 0x02) && ((rx_buf[1] & 0x0F) != 0x01))) && (! first_correct_frame_received)) {

INFO  [muorb] SLPI: Spektrum RC: Read no bytes from UART
INFO  [muorb] SLPI: Spektrum RC: Read 16 bytes from UART
INFO  [muorb] SLPI: Spektrum RC: DSM message parsed successfully
INFO  [muorb] SLPI: Spektrum RC: Publishing input_rc
INFO  [muorb] SLPI: 0xff 0x01 0x06 0x08 0x17 0x42 0x0a 0x00 0x0d 0xfd 0x00 0xa9 0x10 0xaa 0x1b 0x57
INFO  [muorb] SLPI: Spektrum RC: Read no bytes from UART
INFO  [muorb] SLPI: Spektrum RC: Read 16 bytes from UART
INFO  [muorb] SLPI: Spektrum RC: DSM message parsed successfully
INFO  [muorb] SLPI: Spektrum RC: Publishing input_rc
INFO  [muorb] SLPI: 0xff 0x01 0x06 0x08 0x17 0x42 0x0a 0x00 0x0d 0xfd 0x00 0xa9 0x10 0xaa 0x1b 0x57

@Chase-Riley if needed, I can send you a deb file that will print out lots of debugs. Not safe for flying but hopefully it could help understanding what's happening.