From 2f30ea2a7bc003899a1a515e104c155a8e6d4d83 Mon Sep 17 00:00:00 2001 From: Hermes Date: Mon, 12 Oct 2026 13:27:20 +0200 Subject: [PATCH] hilink: record module-input voltage measurement and set the next physical gate --- .../USB-HS-INVESTIGATION.md | 100 +++++++++++++----- 1 file changed, 71 insertions(+), 29 deletions(-) diff --git a/devices/ssc338q_fpv_openipc-urllc-aio/USB-HS-INVESTIGATION.md b/devices/ssc338q_fpv_openipc-urllc-aio/USB-HS-INVESTIGATION.md index 157007b..5446f0a 100644 --- a/devices/ssc338q_fpv_openipc-urllc-aio/USB-HS-INVESTIGATION.md +++ b/devices/ssc338q_fpv_openipc-urllc-aio/USB-HS-INVESTIGATION.md @@ -17,6 +17,14 @@ USB 2.0 EHCI port (`Sstar-ehci-1`). high-speed negotiation on this board. - **Verified on hardware (2026-10, Piotr):** changing the input supply capacity did not improve negotiation. Supply-headroom tuning is ruled out. +- **Verified on hardware (2026-10, Piotr):** the radio is a custom + carrier/module assembly, **not** a drop-in USB dongle: a four-wire host + harness/pad connection, two RF pigtails, and visible local regulation on + the carrier. +- **Verified on hardware (2026-10, Piotr):** 5.13 V measured directly at the + module input, inside the common 4.75–5.25 V input range. The earlier + "3.3 V fed into the 5 V input" hypothesis is therefore ruled out **at + module ingress** (upstream of the carrier's local regulation). - RF/FEC configuration is not a USB fix and is out of scope for this issue. - This document contains no credentials, pairing or RF-access material. @@ -29,13 +37,19 @@ remaining software-adjacent candidates that are cheap to test: - **Ruled out:** wifibroadcast/OpenIPC configuration, RF/FEC settings, ordinary userspace timing, a simple USB-device rebind, a full - HCD/UTMI re-initialization (done on hardware, no change), and - input-supply-capacity tuning (done on hardware, no change). + HCD/UTMI re-initialization (done on hardware, no change), + input-supply-capacity tuning (done on hardware, no change), and + wrong-voltage-at-module-ingress (measured 5.13 V at the input, within the + 4.75–5.25 V range). - **Remaining fault domain:** the USB **high-speed physical path / signal - integrity / rework** — D+/D− routing and symmetry, controlled impedance - and stubs, series/ESD components on the pair, connector and solder + integrity / rework** — D+/D− routing and symmetry across the carrier, + harness/pads and intervening components, controlled impedance and stubs, + series/ESD/common-mode components on the pair, connector and solder integrity, or PHY-side / device-side silicon-level hardware — exactly the - boundary detailed in the hardware section below. + boundary detailed in the hardware section below. The supply findings above + rule out only those two specific points: power **quality** downstream of + the measured input — supply noise/ripple and the carrier's local regulator + output — remains untested and stays inside this open fault domain. Two caveats stay attached to this classification: it does not prove that every conceivable undocumented analog register in the vendor PHY block is @@ -43,6 +57,10 @@ irrelevant (the audited paths cover what the shipped source programs, not the full register space), and it does **not** claim any high-speed success — the fault is unresolved; only its domain is now sharply bounded. +Operating posture while the fault stands: keep the existing +4096 kbit/s limit appropriate to full-speed operation; do not raise it on +the assumption of high-speed throughput until HS is actually demonstrated. + ## Audited sources Audited 2026-10-02. Everything the firmware ships is stock upstream of this @@ -205,37 +223,61 @@ All tuning is compile-time; there are no runtime knobs in this repo. ## HiLink D+/D- hardware / rework investigation boundary +Assembly as observed (2026-10, Piotr): the radio is a custom +carrier/module — not a drop-in dongle — connected to the host by a +**four-wire harness/pad** connection, with **two RF pigtails** and visible +**local regulation** on the carrier. The pad assignments have **not** been +documented yet; nothing below assumes one. + With the software and software-adjacent candidates ruled out (see the conclusion above), the remaining fault domain is the USB **high-speed physical path / signal integrity / rework**, explicitly outside software scope: -- D+/D- pair routing on the HiLink carrier: continuity and symmetry from the - SSC338Q pads to the module socket; controlled impedance along the pair; - stubs or test points hanging off it; series resistors / ESD protection - parts on the pair; connector and solder joint integrity. +- D+/D- pair routing on the HiLink carrier and through the four-wire + harness: continuity and symmetry from the SSC338Q pads to the module + pads; controlled impedance along the pair; stubs or test points hanging + off it; series resistors / ESD protection / common-mode chokes or other + intervening components; via, connector/harness and solder joint integrity. - HS chirp failure with FS working is the classic marginal-analog signature: the same pair carries FS traffic fine while the HS chirp (a short, amplitude-critical burst at reset) is missed by the host squelch detector. -- Concrete next hardware diagnostics, cheapest first (1-2 need the port or - module to be reachable — the radio is a directly attached module, so this - may mean a rework socket or a piggyback cable): - 1. Try a **known-good HS USB device** (any USB 2.0 flash disk) on the same - port. HS on the disk but not on the radio points at the - module/device side; FS on both points at the board-side pair. - 2. Try the **same RTL8812EU module on a different known-good HS host** - (a PC). HS there isolates the fault to this board's physical path. - 3. Measure D+/D- continuity and symmetry against the SSC338Q pads, and - inspect series/ESD parts and connector solder under magnification. - 4. With suitable equipment, capture the HS chirp amplitude/eye at the - host-side connector against the USB 2.0 electrical limits. -- Any board rework (series resistor changes, pair shortening, shielding) - invalidates prior software observations; re-verify from the on-device - commands below after any hardware change. -Evidence status: the platform-driver re-probe (step 5 below) and the -input-supply-capacity change were performed on hardware (2026-10, Piotr) — -both completed with no improvement, recorded above. The register-read +**Next physical gate (before any rework):** + +1. **Macro photographs of both sides** of the carrier/module. +2. **Identify all four host pads** — determine which are VBUS, GND, D+, + D- (the four-wire harness implies the classic set, but the actual + assignment must come from tracing, not assumption). +3. **Trace D+/D- end to end**, identifying every intervening component — + series resistors, ESD arrays, common-mode chokes, vias, connectors, + harness wires — and where the pair leaves the board. + +**Safety rule for all continuity/ohmmeter work:** only with **all power +removed and rails discharged** (unplug, then verify the rails are at 0 V +before touching meter probes to pads). No powered measurements are proposed +at this stage. + +Further isolation diagnostics, only **after** the gate above (all of them +need rework access — the radio is pad-connected, not socketed, so this may +mean a temporary rework socket or piggyback harness): + +- Try a **known-good HS USB device** (any USB 2.0 flash disk) on the same + host pads. HS on the disk but not on the radio points at the + carrier/module side; FS on both points at the board-side pair. +- Try the **RTL8812EU carrier on a different known-good HS host** (a PC). + HS there isolates the fault to this board's physical path. +- With suitable equipment, capture the HS chirp amplitude/eye at the host + pads against the USB 2.0 electrical limits. + +Any board rework (series resistor changes, pair shortening, shielding) +invalidates prior software observations; re-verify from the on-device +commands below after any hardware change. + +Evidence status: the platform-driver re-probe (step 5 below), the +input-supply-capacity change, and the module-input voltage measurement were +performed on hardware (2026-10, Piotr) — none improved negotiation, and the +ingress voltage is in range; all recorded above. The register-read diagnostics (steps 1-4 below) have not been reported yet; no HS negotiation has been observed at any point, and this document does not claim any. @@ -272,8 +314,8 @@ number `n` sits at byte offset `2*n`, except odd `n` which sits at `2*n - 1` devmem 0x1F284880 8 # UHC+0x40 bit7: 0x00/0x80 ``` Expected if healthy: bit7 clear. If bit7 is set, a previous enumeration - failure latched FS; replug the module (root-hub reinit clears it) and - repeat. + failure latched FS; disconnect/reconnect the module's power (the + root-hub reinit on disconnect clears it) and repeat. 3. **Port / line state** (all UHC0 = EHCI bank, `hcd->ehc_base`; bit semantics as used by the driver: `hub.c:4998` enable=bit2, `urb.c:532` connect=bit0, `message.c:88` csc=bit1, `hub.c:5801-5802` line state)