Record PD power-cycling test through the hub

Three PD unplug/replug cycles each caused one full USB-C detach; the
link flapped ~3 times and settled within 5-12 s with no intervention.
Treated as a service-level requirement (yukart decision 24), not a
host fix.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
mikkeli
2026-10-09 00:18:50 +09:00
parent 314ff3c6a7
commit 98fb9f306a
+21 -1
View File
@@ -76,4 +76,24 @@ Options:
| **PD hub with one data port** (on hand) | Full PD from the car charger, through to the tablet | Tablet → hub's USB-C host/PD port, charger → hub's PD-in, Orin USB-C → hub's data port. Same gadget/NCM setup, nothing changes on the Orin. Some hubs briefly re-enumerate when PD power appears or disappears (ignition), so the app should reconnect | | **PD hub with one data port** (on hand) | Full PD from the car charger, through to the tablet | Tablet → hub's USB-C host/PD port, charger → hub's PD-in, Orin USB-C → hub's data port. Same gadget/NCM setup, nothing changes on the Orin. Some hubs briefly re-enumerate when PD power appears or disappears (ignition), so the app should reconnect |
| Reverse roles: Orin USB-A host + tablet USB tethering | ~4.5 W at most (5 V, USB-A) | Tablet becomes the router, tethering has to be enabled by hand on Android, and it needs `never-default` on the Orin so the Orin's traffic doesn't leave via the tablet | | Reverse roles: Orin USB-A host + tablet USB tethering | ~4.5 W at most (5 V, USB-A) | Tablet becomes the router, tethering has to be enabled by hand on Android, and it needs `never-default` on the Orin so the Orin's traffic doesn't leave via the tablet |
The **PD hub** is the practical choice. Test whether the tablet reconnects cleanly when the hub's PD input is cut. The **PD hub** is the practical choice, and it's now in use.
### PD power cycling through the hub (tested 2026-10-09)
Setup: tablet → hub (USB-C host/PD), car-style charger → hub PD-in, Orin USB-C → hub data port.
Three PD unplug/replug cycles while pinging the tablet every 0.5 s:
| Cycle | USB-C detach (Orin) | Link stable again | Ping lost |
|-------|---------------------|-------------------|-----------|
| 1 | 00:14:29.3 | 00:14:36.1 | 3.1 s + 1.5 s |
| 2 | 00:14:38.5 | 00:14:43.6 | 3.1 s + 1.5 s |
| 3 | 00:14:51.4 | 00:15:02.0 | 11.8 s |
- **Each cycle caused exactly one full detach** (`fusb301_detach`), not one per transition. The hub resets its data port on one of
the two PD edges; which one can't be seen from the Orin side.
- Each detach follows the same pattern: re-attach after about 0.5 s, then the `l4tbr0` bridge ports flap about three times over 5–10 s
(the tablet re-creating its USB network) before settling.
- Recovery is automatic every time: the same DHCP lease, normal ping (~3 ms) afterwards. Nothing needs fixing on the Orin.
Consequence: in the car, expect a link outage of up to about 12 s at every ignition change. That is a requirement for the services
(failure detection and redelivery; project-yukart ARCHITECTURE decision 24), not something to fix in the host setup.