@tom that was from ubuntu 20.04. Looking back up the terminal history I see the install script stopped at:
[ERROR] missing /data/modalai/sku.txt
[ERROR] please run voxl-configure-sku to make a new one
and didn't run the next setup steps. I didn't realize the flashing failed until seeing voxl-px4 couldn't start. And digging into that found this thread.

@Eric-Katzfey I saw a similar symptom last Friday on a voxl2 that seemed to have a corrupt partition for /dev/sda8.
Flashing to 1.3.5 wrote /data to / without sda8 mounted.
voxl-px4 failed depending on sscrpcd.service which failed depending on data.mount

voxl2:/$ mount /dev/disk/by-partlabel/userdata /data
mount: /data: wrong fs type, bad option, bad superblock on /dev/sda8, missing codepage or helper program, or other error.

voxl2:/$ fsck.ext4 /dev/sda8
e2fsck 1.44.3 (10-July-2018)
ext2fs_open2: Bad magic number in super-block
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/sda8

voxl2:/$ fdisk -l |grep sda8
The backup GPT table is corrupt, but the primary appears OK, so that will be used.
/dev/sda8 41480 16818695 16777216 64G unknown

Reflashing with ./install.sh --wipe-persistent fixed sda8 and made everything work.

@giladWDS could be worth checking /dev/sda8 is being mounted as /data without any errors.

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