Power: The drone runs on a 4S battery. The VOXL 2 receives its power via the VOXL mini ESC power module 5V output.

Cameras: The C29 M0173 front end. There's also a VL53L1X on the M0173 front end that's part of the C29 config, though not with a Lepton as shown in the front-end documentation, but as a single "rangefinder" as described in the rangefinder documentation.

Custom expansion: A custom hat board carries a connector that interfaces your MCBL-00022 harness and an AWUS036EACS USB Wi-Fi dongle. The hat also has connectors which interface four VL53L8CX ToF sensors modules (also your design, i don't have the PN for them) behind an I2C switch (the one you recommend). That is the extent of the expansion.

The issue I observed: I'm scoping four signals: the RC TX → VOXL RX and VOXL TX → RC RX UART lines (J19), VDC_5V_LOCAL (J19), and VDC_5V_LOCAL_USB1 tapped at the hat connector. The event I see most often — it's intermittent, not something I can reproduce on demand — is: some seconds after boot, VDC_5V_LOCAL_USB1 and VOXL TX → RC RX UART lines will drop to 0V (not at the same time). Sometimes, they will drop in sequence (USB first then UART), sometimes only the UART line will drop. Most of the time, the rails recover, but not always. Often the dropouts will sequence and loop several times before settling to an on-state, but i have seen one instance where the sequence continued until a hard reset. In my early testing, I gathered this dmesg log that shows the USB drop and never recover. I pulled this log by waiting until the system settled, then plugging in ADB and pulling the log. Up through this point, I was not booting the system with ADB USB plugged in. You will also note some I2C errors that may be related as well.

voxl2:/$ dmesg | tail -50
[   12.676813] RTW: send eapol packet 2/4
[   12.680712] RTW: recv eapol packet 3/4
[   12.681049] RTW: send eapol packet 4/4
[   12.681976] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[   12.694729] RTW: set pairwise key camid:0, addr:96:0a:86:95:48:21, kid:0, type:AES
[   12.698837] RTW: set group key camid:1, addr:96:0a:86:95:48:21, kid:1, type:AES
[   13.816400] CAM_ERR: CAM-ISP: cam_ife_hw_mgr_print_acquire_info: 710 Successfully acquire single IFE[5 -1] with [0 pix] [0 pd] [1 rdi] ports for ctx:3
[   13.816636] CAM_ERR: CAM-CRM: cam_req_mgr_cb_add_req: 2742 req 1 not found in in_q
[   13.816707] CAM_INFO: CAM-CSIPHY: cam_csiphy_core_cfg: 1137 START_DEV: CSIPHY_IDX: 3, Device_slot: 0, Datarate: 288000000, Settletime: 2800000000
[   13.824654] CAM_INFO: CAM-ISP: cam_vfe_bus_ver3_init_hw: 3659 Overriding clock gating at bus input
[   13.824658] CAM_INFO: CAM-ISP: cam_vfe_top_ver3_init_hw: 246 Disable clock gating at IFE top
[   13.824666] CAM_ERR: CAM-ISP: cam_ife_mgr_start_hw: 4510 ->Config HW, 000000004aa04450
[   13.824902] CAM_INFO: CAM-SENSOR: cam_sensor_driver_cmd: 1089 CAM_START_DEV Success, sensor_id:0x2975,sensor_slave_addr:0x7a
[   13.847257] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4927 CSID:5 UNBOUNDED_FRAME
[   20.591666] i2c_geni a88000.i2c: i2c error :-107
[   20.593507] i2c_geni a88000.i2c: i2c error :-107
[   20.594852] i2c_geni a88000.i2c: i2c error :-107
[   20.596673] i2c_geni a88000.i2c: i2c error :-107
[   20.597879] i2c_geni a88000.i2c: i2c error :-107
[   20.599128] i2c_geni a88000.i2c: i2c error :-107
[   25.123398] devfreq-qcom-fw 18590000.qcom,devfreq-l3:qcom,cdsp-cdsp-l3-lat: Successfully started CDSP L3 governor
[   33.762024] vdd_tof: disabling
[   33.762027] vdd_hap_boost: disabling
[  101.387966] boot log copy done
[  203.746453] perf: interrupt took too long (2516 > 2500), lowering kernel.perf_event_max_sample_rate to 79250
[  340.249040] perf: interrupt took too long (3156 > 3145), lowering kernel.perf_event_max_sample_rate to 63250
[  373.019947] usb 1-1: USB disconnect, device number 2
[  373.034133] RTW: rtw_ndev_uninit(wlan0) if1
[  373.069021] RTW: rtw_dev_unload: driver not in IPS
[  374.084355] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[  374.964444] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[  374.964742] usb usb1-port1: attempt power cycle
[  376.152225] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[  377.032323] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[  377.032473] usb usb1-port1: unable to enumerate USB device
[ 2523.780849] CAM_WARN: CAM-ISP: __cam_isp_ctx_apply_req_in_activated_state: 2567 Reject apply request (id 75392) due to congestion(cnt = 2) ctx 0
[ 2523.780918] CAM_WARN: CAM-ISP: __cam_isp_ctx_handle_buf_done_fail_log: 721 Prev Req[75391] : num_out=1, num_acked=0, bubble : report=1, detected=0
[ 2523.780920] CAM_WARN: CAM-ISP: __cam_isp_ctx_handle_buf_done_fail_log: 723 Resource Handles that fail to generate buf_done in prev frame
[ 2523.780924] CAM_WARN: CAM-ISP: __cam_isp_ctx_handle_buf_done_fail_log: 736 Resource_Handle: [RDI_0][0x3006] Sync_ID: [0x7]
[ 2523.780927] CAM_ERR: CAM-ISP: __cam_isp_ctx_rdi_only_apply_req_top_state: 3664 Apply failed in Substate[EPOCH], rc -14
[ 2523.780930] CAM_WARN: CAM-ISP: __cam_isp_ctx_apply_req: 5173 Apply failed in active Substate[EPOCH] rc -14
[ 2523.780933] CAM_WARN: CAM-CRM: __cam_req_mgr_send_req: 781 APPLY FAILED pd 1 req_id 75392

How I attempted to capture more detail -
I composed some scripts that readout journal logs and oscilloscope captures when a drop triggers the scope and they all get timestamped to my dev machine reference so I can see hardware and software failure signatures in sequence with each other. The journals are read out over ADB, so I am now booting the system with ADB plugged in. After making these changes to my test setup, I spent over a week power cycling the system, and frustratingly... NO DROPS OCCURED on either rail. After this I switched to some other system testing while I mulled over what it was that I changed about the problem by probing deeper at the system. Then while looking more generally at the few early logs from when the issue was presenting, I noticed the lines below.

[ 5208.508965] usbpd usbpd0: Type-C Source (medium - 1.5A) connected
[ 5209.718132] msm-usb-ssphy-qmp 88e8000.ssphy: USB DP QMP PHY: Update TYPEC CTRL(3)
[ 5209.780341] msm-dwc3 a600000.ssusb: DWC3 exited from low power mode
[ 5210.198394] android_work: sent uevent USB_STATE=CONNECTED
[ 5210.252727] android_work: sent uevent USB_STATE=DISCONNECTED
[ 5210.335246] android_work: sent uevent USB_STATE=CONNECTED
[ 5210.342185] configfs-gadget gadget: high-speed config #1: c
[ 5210.342377] android_work: sent uevent USB_STATE=CONFIGURED

When i plug in ADB to pull the logs, usbpd is negotiating as a power source. So now, ostensibly, I'm powering some of the USB system via my dev machine and offloading the power system on the VOXL. This is unexpected and up to that point I would have assumed that as long as battery power is present, the system would default to battery as the source. If accurate, this would explain why I no longer see the issue presenting while booting with ADB plugged in.

Since this revelation, I unplugged ADB during boot. I've run the power power sequence several times and while I haven't seen the dropouts return in the confirming quantity I was hoping for, I do see the UART dropping again sometimes. This is a recent development so I will gain some more statistics when I return to the lab next week.

A tangential observation -
When testing the rails, I observe a large deregulation on the VDC_5V_LOCAL and VDC_5V_LOCAL_USB1 busses when the forward LIOW2 tof ranges. Both rails are dropping up to 200mV during that period. Originally I expected this was the problem and that the eFuse was triggering due to this, but have not been able to confirm that theory due to the stochastic nature of issue occurence.

What is your recommendation for me to check next?