yukart/orin-nano-env-setup
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

USB report: unplug and replug of hub PD measured separately

Browse Source 
Unplug causes the full USB-C detach (~3.5 s total). Replug causes no
detach but ~10 s of disruption: the tablet goes silent while the Orin's
link stays up, then reconnects its gadget once. Only an app-level
heartbeat would see the replug outage.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
mikkeli
2026-10-09 00:25:46 +09:00
parent 98fb9f306a
commit 264cc68ff2
1 changed files with 17 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/impl/reports/USB-TABLET-LINK.md
+17 -2
View File
@@ -89,11 +89,26 @@ Three PD unplug/replug cycles while pinging the tablet every 0.5 s:
| 2 | 00:14:38.5 | 00:14:43.6 | 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 | | 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 - **Each cycle caused exactly one full detach** (`fusb301_detach`), not one per transition. The separate-edge test below shows
the two PD edges; which one can't be seen from the Orin side. it is the unplug.
- 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 - 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. (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. - Recovery is automatic every time: the same DHCP lease, normal ping (~3 ms) afterwards. Nothing needs fixing on the Orin.
#### Each edge separately (same day, one 60 s window each)
| | PD unplugged (00:23:04) | PD plugged back (~00:24:12) |
|---|---|---|
| USB-C detach on the Orin | **yes**, full detach and re-attach | **no** |
| Orin link (`l4tbr0` ports) | flapped twice, stable after 3.4 s | stayed up; one short gadget reconnect at 00:24:21.6 (0.7 s) |
| Ping lost | 3.1 s | 5.0 s while the Orin's link was **up**, then 0.3 s and 1.5 s |
| Total disruption | ~3.5 s | ~10 s |
- Unplug: the hub cuts its data port, so the Orin sees a real disconnect, and recovery is quick.
- Replug: no disconnect on the Orin's side. The tablet stops answering for about 5 s (most likely renegotiating power and switching to
charging), then re-creates its USB network once. **The Orin's interface state does not reveal this outage**, so only an
application-level heartbeat catches it.
- Exact replug time isn't known; the first failed ping is used as its marker.
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 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. (failure detection and redelivery; project-yukart ARCHITECTURE decision 24), not something to fix in the host setup.