DarwinFPV HiLink / SSC338Q internal RTL8812EU radio (0bda:a81a) negotiates USB Full-Speed instead of High-Speed.
Device: USB 2.00, Realtek 802.11ac NIC
Host: Sstar-ehci-1 / EHCI USB 2.0
Topology: direct port, no hub
Active speed: 12 Mbit/s
Kernel: 4.9.84
The kernel explicitly reports:
new full-speed USB device
not running at top speed; connect to a high speed hub
Controlled re-enumeration
With Ethernet management active, the device was unbound and rebound via /sys/bus/usb/drivers/usb/{unbind,bind}. It freshly negotiated 12 Mbit/s again.
This rules out a transient radio driver state and ordinary userspace/WFB timing. It does not yet prove that no kernel PHY tuning can help, because rebind does not reinitialize the entire SSC338Q PHY.
Active DT findings
compatible = Sstar-ehci-1
status = ok
dpdm_swap = 0
power-enable-pad = 0xffff (no controllable VBUS GPIO)
Next work
Locate the exact Sstar 4.9.84 EHCI/UTMI driver source used by this firmware and audit PHY high-speed chirp/squelch/tuning paths against the active Sstar-ehci-1 node.
If no device-specific software discrepancy is found, document the HiLink USB D+/D- hardware path and prepare a high-speed rework investigation.
Keep the current WFB profile at 4096 kbit/s until HS is demonstrated; do not treat RF/FEC settings as a fix for this producer-side USB bottleneck.
No credentials or pairing material belongs in this issue.
## Confirmed baseline
DarwinFPV HiLink / SSC338Q internal RTL8812EU radio (`0bda:a81a`) negotiates USB Full-Speed instead of High-Speed.
```text
Device: USB 2.00, Realtek 802.11ac NIC
Host: Sstar-ehci-1 / EHCI USB 2.0
Topology: direct port, no hub
Active speed: 12 Mbit/s
Kernel: 4.9.84
```
The kernel explicitly reports:
```text
new full-speed USB device
not running at top speed; connect to a high speed hub
```
## Controlled re-enumeration
With Ethernet management active, the device was unbound and rebound via `/sys/bus/usb/drivers/usb/{unbind,bind}`. It freshly negotiated `12` Mbit/s again.
This rules out a transient radio driver state and ordinary userspace/WFB timing. It does not yet prove that no kernel PHY tuning can help, because rebind does not reinitialize the entire SSC338Q PHY.
## Active DT findings
```text
compatible = Sstar-ehci-1
status = ok
dpdm_swap = 0
power-enable-pad = 0xffff (no controllable VBUS GPIO)
```
## Next work
1. Locate the exact Sstar 4.9.84 EHCI/UTMI driver source used by this firmware and audit PHY high-speed chirp/squelch/tuning paths against the active `Sstar-ehci-1` node.
2. If no device-specific software discrepancy is found, document the HiLink USB D+/D- hardware path and prepare a high-speed rework investigation.
3. Keep the current WFB profile at 4096 kbit/s until HS is demonstrated; do not treat RF/FEC settings as a fix for this producer-side USB bottleneck.
No credentials or pairing material belongs in this issue.
grzesiu
was assigned by piotr2026-10-02 16:26:16 +02:00
Investigation completed and published as PR #2: #2
Commit: e28472c5bd0268543ce49fa72ea4538832dde294 (remote branch and PR head verified). The audit found no device-specific discrepancy in the builder overlay, stock DT/config, Sstar EHCI/UTMI path, or speed-passive RTL driver. The PR adds the reviewed investigation record, safe diagnostics, full-HCD reinitialization procedure, true power-cycle limitations, and the D+/D- hardware/rework boundary.
Validation: claim-by-claim review against pinned openipc/linux revision 97b7fc4e; ci-matrix.py --self-test, lint self-tests, workflow shell lint, git diff --check, and added-lines credential/security scan passed. The full-tree lint-cli-paths.py result is a pre-existing false positive reproduced unchanged at base and is out of scope.
CI status for this exact SHA is N/A rather than running: the repository has only Build HiLink URLLC firmware, configured exclusively for workflow_dispatch; after the bounded wait Gitea reports zero commit statuses and zero Actions runs for the PR SHA. The aggregate pending with total_count=0 therefore does not represent an active check.
No physical-device validation is claimed. Hardware acceptance remains with Piotr; the next discriminating experiment is the documented Sstar-ehci-1 platform-driver unbind/bind from Ethernet or console, because it takes wlan0 down. The issue remains open until merge.
Investigation completed and published as PR #2: https://git.piksar.eu/piotr/openipc-builder/pulls/2
Commit: `e28472c5bd0268543ce49fa72ea4538832dde294` (remote branch and PR head verified). The audit found no device-specific discrepancy in the builder overlay, stock DT/config, Sstar EHCI/UTMI path, or speed-passive RTL driver. The PR adds the reviewed investigation record, safe diagnostics, full-HCD reinitialization procedure, true power-cycle limitations, and the D+/D- hardware/rework boundary.
Validation: claim-by-claim review against pinned `openipc/linux` revision `97b7fc4e`; `ci-matrix.py --self-test`, lint self-tests, workflow shell lint, `git diff --check`, and added-lines credential/security scan passed. The full-tree `lint-cli-paths.py` result is a pre-existing false positive reproduced unchanged at base and is out of scope.
CI status for this exact SHA is N/A rather than running: the repository has only `Build HiLink URLLC firmware`, configured exclusively for `workflow_dispatch`; after the bounded wait Gitea reports zero commit statuses and zero Actions runs for the PR SHA. The aggregate `pending` with `total_count=0` therefore does not represent an active check.
No physical-device validation is claimed. Hardware acceptance remains with Piotr; the next discriminating experiment is the documented `Sstar-ehci-1` platform-driver unbind/bind from Ethernet or console, because it takes `wlan0` down. The issue remains open until merge.
This is stronger than the prior USB-device rebind: it re-runs Sstar-ehci-1 / UTMI platform initialization and still negotiates Full-Speed. Input supply capacity was also changed without improvement.
Next: source audit of the exact vendor EHCI/UTMI driver for device-specific PHY controls. If that finds no concrete HiLink-specific discrepancy, classify this as an HS hardware-path/rework issue rather than a WFB/OpenIPC configuration defect.
## Full EHCI/UTMI reinitialization result
Piotr performed the complete platform driver cycle over Ethernet:
```sh
echo soc:Sstar-ehci-1 > /sys/bus/platform/drivers/Sstar-ehci-1/unbind
sleep 2
echo soc:Sstar-ehci-1 > /sys/bus/platform/drivers/Sstar-ehci-1/bind
sleep 5
cat /sys/bus/usb/devices/1-1/speed
```
Result:
```text
12
```
This is stronger than the prior USB-device rebind: it re-runs `Sstar-ehci-1` / UTMI platform initialization and still negotiates Full-Speed. Input supply capacity was also changed without improvement.
Next: source audit of the exact vendor EHCI/UTMI driver for device-specific PHY controls. If that finds no concrete HiLink-specific discrepancy, classify this as an HS hardware-path/rework issue rather than a WFB/OpenIPC configuration defect.
Follow-up hardware evidence has been incorporated into the existing PR: #2
New verified head: 17caa64ed7f75bfc91b9ede3c9b6983ad5ec4191. The document now records that Piotr’s full Sstar-ehci-1 platform-driver unbind/bind over Ethernet still negotiated at 12 Mbit/s, and that changing input-supply capacity did not improve the result.
Combined with the pinned vendor EHCI/UTMI source audit, the actionable remaining fault domain is classified as USB High-Speed physical path/signal-integrity/rework rather than WFB/OpenIPC configuration, RF/FEC, ordinary userspace timing, USB-device rebind, full HCD/UTMI initialization, or input-supply-capacity tuning. The document explicitly retains two limits: undocumented analog controls are not proven irrelevant, and USB HS operation has not been achieved or claimed.
The follow-up was independently reviewed. Final checks passed: single-document scope, git diff --check, and changed-lines credential/security scan; earlier repository checks remain applicable to the unchanged scanned paths. The known lint-cli-paths.py base false positive remains untouched.
PR metadata was updated and read back. This exact SHA has zero commit statuses and zero Actions runs because the repository’s sole workflow is workflow_dispatch only; Gitea’s aggregate pending with total_count=0 is not an active CI run. The issue remains open until merge.
Follow-up hardware evidence has been incorporated into the existing PR: https://git.piksar.eu/piotr/openipc-builder/pulls/2
New verified head: `17caa64ed7f75bfc91b9ede3c9b6983ad5ec4191`. The document now records that Piotr’s full `Sstar-ehci-1` platform-driver unbind/bind over Ethernet still negotiated at `12` Mbit/s, and that changing input-supply capacity did not improve the result.
Combined with the pinned vendor EHCI/UTMI source audit, the actionable remaining fault domain is classified as USB High-Speed physical path/signal-integrity/rework rather than WFB/OpenIPC configuration, RF/FEC, ordinary userspace timing, USB-device rebind, full HCD/UTMI initialization, or input-supply-capacity tuning. The document explicitly retains two limits: undocumented analog controls are not proven irrelevant, and USB HS operation has not been achieved or claimed.
The follow-up was independently reviewed. Final checks passed: single-document scope, `git diff --check`, and changed-lines credential/security scan; earlier repository checks remain applicable to the unchanged scanned paths. The known `lint-cli-paths.py` base false positive remains untouched.
PR metadata was updated and read back. This exact SHA has zero commit statuses and zero Actions runs because the repository’s sole workflow is `workflow_dispatch` only; Gitea’s aggregate `pending` with `total_count=0` is not an active CI run. The issue remains open until merge.
The internal RTL8812EU assembly is a custom carrier/module, not a drop-in USB dongle. It has a four-wire host harness/pad connection, two RF pigtails, and visible local regulation.
Piotr measured 5.13 V directly at the module input. That is within the common 5 V module input range (4.75–5.25 V), so the earlier 3.3 V-at-5V-input hypothesis is ruled out at the module ingress.
Next physical gate is not more upstream supply testing: photograph both sides at macro scale, identify the four host pads and trace D+/D− through any series/ESD/common-mode components. Perform continuity only with power fully removed.
## Hardware inspection evidence
The internal RTL8812EU assembly is a custom carrier/module, not a drop-in USB dongle. It has a four-wire host harness/pad connection, two RF pigtails, and visible local regulation.
Piotr measured **5.13 V directly at the module input**. That is within the common 5 V module input range (4.75–5.25 V), so the earlier 3.3 V-at-5V-input hypothesis is ruled out at the module ingress.
Next physical gate is not more upstream supply testing: photograph both sides at macro scale, identify the four host pads and trace D+/D− through any series/ESD/common-mode components. Perform continuity only with power fully removed.
The latest hardware-inspection evidence is now incorporated into PR #2: #2
New verified head: 2f30ea2a7bc003899a1a515e104c155a8e6d4d83. The investigation record now identifies the internal radio as a custom four-wire carrier/module with two RF pigtails and local regulation, and records Piotr’s 5.13 V measurement directly at module ingress. This rules out the earlier 3.3-V-at-5-V-input hypothesis at ingress and makes further upstream capacity tuning non-discriminating; it does not rule out downstream noise/ripple or a local-regulator fault.
The next physical gate is documented as macro photography of both sides, pinout-agnostic identification of all four host pads, and end-to-end D+/D− tracing through any series, ESD, common-mode, via, connector, or harness elements. Continuity/ohmmeter work is permitted only with all power removed and rails discharged. No pad mapping, component identity, or unsupplied measurement was invented.
The update was independently reviewed. Single-document scope, git diff --check, changed-lines credential/security scan, and unsafe-instruction sweep passed; earlier repository validations remain applicable. PR metadata was updated and read back. For this exact SHA Gitea again reports zero commit statuses and zero Actions runs because the sole workflow is workflow_dispatch only. The issue remains open until merge.
The latest hardware-inspection evidence is now incorporated into PR #2: https://git.piksar.eu/piotr/openipc-builder/pulls/2
New verified head: `2f30ea2a7bc003899a1a515e104c155a8e6d4d83`. The investigation record now identifies the internal radio as a custom four-wire carrier/module with two RF pigtails and local regulation, and records Piotr’s `5.13 V` measurement directly at module ingress. This rules out the earlier 3.3-V-at-5-V-input hypothesis at ingress and makes further upstream capacity tuning non-discriminating; it does not rule out downstream noise/ripple or a local-regulator fault.
The next physical gate is documented as macro photography of both sides, pinout-agnostic identification of all four host pads, and end-to-end D+/D− tracing through any series, ESD, common-mode, via, connector, or harness elements. Continuity/ohmmeter work is permitted only with all power removed and rails discharged. No pad mapping, component identity, or unsupplied measurement was invented.
The update was independently reviewed. Single-document scope, `git diff --check`, changed-lines credential/security scan, and unsafe-instruction sweep passed; earlier repository validations remain applicable. PR metadata was updated and read back. For this exact SHA Gitea again reports zero commit statuses and zero Actions runs because the sole workflow is `workflow_dispatch` only. The issue remains open until merge.
Both resistors measured approximately 100 Ω across their own endpoints with power removed. This is not a single 100 Ω differential termination; it is 100 Ω inserted in each data line.
That is far above the usual external USB 2.0 series damping range (often roughly 15–33 Ω, subject to the PHY datasheet) and is a strong candidate for why Full-Speed survives but High-Speed negotiation/chirp fails.
Do not replace blindly before confirming component size and workmanship plan. A reversible test is to place a matched resistor in parallel across each existing 100 Ω part; e.g. 33 Ω in parallel gives approximately 25 Ω effective per line. After modification, the only acceptance check is fresh enumeration at 480 Mbit/s; revert if behavior regresses.
## Concrete USB HS hardware candidate: confirmed 100 Ω series resistors
Piotr traced the two USB data nets physically. Each net goes:
```text
SSC338Q-side → 100 Ω series resistor → RTL8812EU-module D+ / D−
```
Both resistors measured approximately 100 Ω across their own endpoints with power removed. This is not a single 100 Ω differential termination; it is 100 Ω inserted in each data line.
That is far above the usual external USB 2.0 series damping range (often roughly 15–33 Ω, subject to the PHY datasheet) and is a strong candidate for why Full-Speed survives but High-Speed negotiation/chirp fails.
Do not replace blindly before confirming component size and workmanship plan. A reversible test is to place a matched resistor in parallel across each existing 100 Ω part; e.g. 33 Ω in parallel gives approximately 25 Ω effective per line. After modification, the only acceptance check is fresh enumeration at 480 Mbit/s; revert if behavior regresses.
The confirmed per-line series-resistor evidence and reversible experiment are now incorporated into PR #2: #2
New verified head: dff6783b3f751b8f08d5ed0c596e170992fb96ae. The document records two separate approximately 100 Ω resistors, one in series with each D+/D− net, and explicitly distinguishes them from a differential termination. They are treated as a strong physical candidate for the FS-survives/HS-fails signature, not as a proven root cause.
The gated experiment uses matched parallel parts on both lines only after package/location/workmanship/ESD confirmation and with the board fully de-energized. The example is independently verified: 33 Ω || 100 Ω = 3300/133 = 24.81 Ω per line. After magnified inspection and de-energized resistance verification, the sole acceptance criterion is fresh enumeration at 480 Mbit/s; otherwise the parallel parts are removed and the original state restored. No final line impedance, eye quality, or guaranteed outcome is claimed without SI evidence. The 4096 kbit/s WFB limit remains until HS is demonstrated.
Independent review corrected the reduction wording, clarified isolation of the rework setup, and guarded against SI overclaim. Arithmetic, single-document scope, git diff --check, changed-lines credential/security scan, and unsafe-instruction sweep passed. PR metadata was updated and read back. This exact SHA has zero commit statuses and zero Actions runs because the repository’s only workflow is workflow_dispatch. The issue remains open until merge.
The confirmed per-line series-resistor evidence and reversible experiment are now incorporated into PR #2: https://git.piksar.eu/piotr/openipc-builder/pulls/2
New verified head: `dff6783b3f751b8f08d5ed0c596e170992fb96ae`. The document records two separate approximately `100 Ω` resistors, one in series with each D+/D− net, and explicitly distinguishes them from a differential termination. They are treated as a strong physical candidate for the FS-survives/HS-fails signature, not as a proven root cause.
The gated experiment uses matched parallel parts on both lines only after package/location/workmanship/ESD confirmation and with the board fully de-energized. The example is independently verified: `33 Ω || 100 Ω = 3300/133 = 24.81 Ω` per line. After magnified inspection and de-energized resistance verification, the sole acceptance criterion is fresh enumeration at `480` Mbit/s; otherwise the parallel parts are removed and the original state restored. No final line impedance, eye quality, or guaranteed outcome is claimed without SI evidence. The 4096 kbit/s WFB limit remains until HS is demonstrated.
Independent review corrected the reduction wording, clarified isolation of the rework setup, and guarded against SI overclaim. Arithmetic, single-document scope, `git diff --check`, changed-lines credential/security scan, and unsafe-instruction sweep passed. PR metadata was updated and read back. This exact SHA has zero commit statuses and zero Actions runs because the repository’s only workflow is `workflow_dispatch`. The issue remains open until merge.
Piotr replaced the two verified 100 Ω USB D+/D− series resistors with 12 Ω parts. Immediate runtime result:
cat /sys/bus/usb/devices/1-1/speed
# 480
This is direct hardware proof that the original 100 Ω-per-line series network was the High-Speed negotiation blocker. Keep 12 Ω installed during the next validation gates; do not change resistance again until fresh full HCD/UTMI rebind and WFB stability are verified.
Remaining acceptance: new high-speed enumeration in dmesg, full Sstar-ehci-1 unbind/bind remains 480, and established WFB baseline works without USB disconnects.
## HS restored: series-resistor rework result
Piotr replaced the two verified 100 Ω USB D+/D− series resistors with **12 Ω** parts. Immediate runtime result:
```sh
cat /sys/bus/usb/devices/1-1/speed
# 480
```
This is direct hardware proof that the original 100 Ω-per-line series network was the High-Speed negotiation blocker. Keep 12 Ω installed during the next validation gates; do not change resistance again until fresh full HCD/UTMI rebind and WFB stability are verified.
Remaining acceptance: new high-speed enumeration in dmesg, full `Sstar-ehci-1` unbind/bind remains 480, and established WFB baseline works without USB disconnects.
The successful 12 Ω rework result is now incorporated into PR #2: #2
New verified head: 36e63aeff0758b6743488b46769b479bfa22a012. The investigation record now states that replacing both verified 100 Ω per-line D+/D− resistors with matched 12 Ω parts changed the immediate runtime speed from 12 to 480 Mbit/s. This direct A/B evidence confirms the original 100 Ω network as the High-Speed negotiation blocker on this unit. It does not claim 12 Ω as a universal SSC338Q requirement or establish long-term signal margin.
The historical parallel-resistor proposal is marked superseded and was never executed. Keep the installed 12 Ω parts unchanged and retain the 4096 kbit/s WFB limit until all remaining owner-run gates are recorded:
fresh dmesg shows a new high-speed enumeration without relevant USB errors;
full Sstar-ehci-1 unbind/bind over Ethernet or console still reports 480;
the established WFB baseline remains stable without USB disconnect/reset events.
Independent review corrected stale pre-rework wording and prevented the first 480 result from prematurely releasing the conservative WFB limit. Single-document scope, git diff --check, credential/security scan, stale-instruction sweep, and overclaim/unsafe-instruction review passed. PR metadata was updated and read back. For this SHA there are zero commit statuses and zero Actions runs because the repository’s only workflow is workflow_dispatch. Root cause is confirmed; full hardware acceptance remains pending these three gates. The issue remains open until merge.
The successful 12 Ω rework result is now incorporated into PR #2: https://git.piksar.eu/piotr/openipc-builder/pulls/2
New verified head: `36e63aeff0758b6743488b46769b479bfa22a012`. The investigation record now states that replacing both verified 100 Ω per-line D+/D− resistors with matched 12 Ω parts changed the immediate runtime speed from `12` to `480` Mbit/s. This direct A/B evidence confirms the original 100 Ω network as the High-Speed negotiation blocker on this unit. It does not claim 12 Ω as a universal SSC338Q requirement or establish long-term signal margin.
The historical parallel-resistor proposal is marked superseded and was never executed. Keep the installed 12 Ω parts unchanged and retain the 4096 kbit/s WFB limit until all remaining owner-run gates are recorded:
1. fresh `dmesg` shows a new high-speed enumeration without relevant USB errors;
2. full `Sstar-ehci-1` unbind/bind over Ethernet or console still reports `480`;
3. the established WFB baseline remains stable without USB disconnect/reset events.
Independent review corrected stale pre-rework wording and prevented the first `480` result from prematurely releasing the conservative WFB limit. Single-document scope, `git diff --check`, credential/security scan, stale-instruction sweep, and overclaim/unsafe-instruction review passed. PR metadata was updated and read back. For this SHA there are zero commit statuses and zero Actions runs because the repository’s only workflow is `workflow_dispatch`. Root cause is confirmed; full hardware acceptance remains pending these three gates. The issue remains open until merge.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Confirmed baseline
DarwinFPV HiLink / SSC338Q internal RTL8812EU radio (
0bda:a81a) negotiates USB Full-Speed instead of High-Speed.The kernel explicitly reports:
Controlled re-enumeration
With Ethernet management active, the device was unbound and rebound via
/sys/bus/usb/drivers/usb/{unbind,bind}. It freshly negotiated12Mbit/s again.This rules out a transient radio driver state and ordinary userspace/WFB timing. It does not yet prove that no kernel PHY tuning can help, because rebind does not reinitialize the entire SSC338Q PHY.
Active DT findings
Next work
Sstar-ehci-1node.No credentials or pairing material belongs in this issue.
Investigation completed and published as PR #2: #2
Commit:
e28472c5bd0268543ce49fa72ea4538832dde294(remote branch and PR head verified). The audit found no device-specific discrepancy in the builder overlay, stock DT/config, Sstar EHCI/UTMI path, or speed-passive RTL driver. The PR adds the reviewed investigation record, safe diagnostics, full-HCD reinitialization procedure, true power-cycle limitations, and the D+/D- hardware/rework boundary.Validation: claim-by-claim review against pinned
openipc/linuxrevision97b7fc4e;ci-matrix.py --self-test, lint self-tests, workflow shell lint,git diff --check, and added-lines credential/security scan passed. The full-treelint-cli-paths.pyresult is a pre-existing false positive reproduced unchanged at base and is out of scope.CI status for this exact SHA is N/A rather than running: the repository has only
Build HiLink URLLC firmware, configured exclusively forworkflow_dispatch; after the bounded wait Gitea reports zero commit statuses and zero Actions runs for the PR SHA. The aggregatependingwithtotal_count=0therefore does not represent an active check.No physical-device validation is claimed. Hardware acceptance remains with Piotr; the next discriminating experiment is the documented
Sstar-ehci-1platform-driver unbind/bind from Ethernet or console, because it takeswlan0down. The issue remains open until merge.Full EHCI/UTMI reinitialization result
Piotr performed the complete platform driver cycle over Ethernet:
Result:
This is stronger than the prior USB-device rebind: it re-runs
Sstar-ehci-1/ UTMI platform initialization and still negotiates Full-Speed. Input supply capacity was also changed without improvement.Next: source audit of the exact vendor EHCI/UTMI driver for device-specific PHY controls. If that finds no concrete HiLink-specific discrepancy, classify this as an HS hardware-path/rework issue rather than a WFB/OpenIPC configuration defect.
Follow-up hardware evidence has been incorporated into the existing PR: #2
New verified head:
17caa64ed7f75bfc91b9ede3c9b6983ad5ec4191. The document now records that Piotr’s fullSstar-ehci-1platform-driver unbind/bind over Ethernet still negotiated at12Mbit/s, and that changing input-supply capacity did not improve the result.Combined with the pinned vendor EHCI/UTMI source audit, the actionable remaining fault domain is classified as USB High-Speed physical path/signal-integrity/rework rather than WFB/OpenIPC configuration, RF/FEC, ordinary userspace timing, USB-device rebind, full HCD/UTMI initialization, or input-supply-capacity tuning. The document explicitly retains two limits: undocumented analog controls are not proven irrelevant, and USB HS operation has not been achieved or claimed.
The follow-up was independently reviewed. Final checks passed: single-document scope,
git diff --check, and changed-lines credential/security scan; earlier repository checks remain applicable to the unchanged scanned paths. The knownlint-cli-paths.pybase false positive remains untouched.PR metadata was updated and read back. This exact SHA has zero commit statuses and zero Actions runs because the repository’s sole workflow is
workflow_dispatchonly; Gitea’s aggregatependingwithtotal_count=0is not an active CI run. The issue remains open until merge.Hardware inspection evidence
The internal RTL8812EU assembly is a custom carrier/module, not a drop-in USB dongle. It has a four-wire host harness/pad connection, two RF pigtails, and visible local regulation.
Piotr measured 5.13 V directly at the module input. That is within the common 5 V module input range (4.75–5.25 V), so the earlier 3.3 V-at-5V-input hypothesis is ruled out at the module ingress.
Next physical gate is not more upstream supply testing: photograph both sides at macro scale, identify the four host pads and trace D+/D− through any series/ESD/common-mode components. Perform continuity only with power fully removed.
The latest hardware-inspection evidence is now incorporated into PR #2: #2
New verified head:
2f30ea2a7bc003899a1a515e104c155a8e6d4d83. The investigation record now identifies the internal radio as a custom four-wire carrier/module with two RF pigtails and local regulation, and records Piotr’s5.13 Vmeasurement directly at module ingress. This rules out the earlier 3.3-V-at-5-V-input hypothesis at ingress and makes further upstream capacity tuning non-discriminating; it does not rule out downstream noise/ripple or a local-regulator fault.The next physical gate is documented as macro photography of both sides, pinout-agnostic identification of all four host pads, and end-to-end D+/D− tracing through any series, ESD, common-mode, via, connector, or harness elements. Continuity/ohmmeter work is permitted only with all power removed and rails discharged. No pad mapping, component identity, or unsupplied measurement was invented.
The update was independently reviewed. Single-document scope,
git diff --check, changed-lines credential/security scan, and unsafe-instruction sweep passed; earlier repository validations remain applicable. PR metadata was updated and read back. For this exact SHA Gitea again reports zero commit statuses and zero Actions runs because the sole workflow isworkflow_dispatchonly. The issue remains open until merge.Concrete USB HS hardware candidate: confirmed 100 Ω series resistors
Piotr traced the two USB data nets physically. Each net goes:
Both resistors measured approximately 100 Ω across their own endpoints with power removed. This is not a single 100 Ω differential termination; it is 100 Ω inserted in each data line.
That is far above the usual external USB 2.0 series damping range (often roughly 15–33 Ω, subject to the PHY datasheet) and is a strong candidate for why Full-Speed survives but High-Speed negotiation/chirp fails.
Do not replace blindly before confirming component size and workmanship plan. A reversible test is to place a matched resistor in parallel across each existing 100 Ω part; e.g. 33 Ω in parallel gives approximately 25 Ω effective per line. After modification, the only acceptance check is fresh enumeration at 480 Mbit/s; revert if behavior regresses.
The confirmed per-line series-resistor evidence and reversible experiment are now incorporated into PR #2: #2
New verified head:
dff6783b3f751b8f08d5ed0c596e170992fb96ae. The document records two separate approximately100 Ωresistors, one in series with each D+/D− net, and explicitly distinguishes them from a differential termination. They are treated as a strong physical candidate for the FS-survives/HS-fails signature, not as a proven root cause.The gated experiment uses matched parallel parts on both lines only after package/location/workmanship/ESD confirmation and with the board fully de-energized. The example is independently verified:
33 Ω || 100 Ω = 3300/133 = 24.81 Ωper line. After magnified inspection and de-energized resistance verification, the sole acceptance criterion is fresh enumeration at480Mbit/s; otherwise the parallel parts are removed and the original state restored. No final line impedance, eye quality, or guaranteed outcome is claimed without SI evidence. The 4096 kbit/s WFB limit remains until HS is demonstrated.Independent review corrected the reduction wording, clarified isolation of the rework setup, and guarded against SI overclaim. Arithmetic, single-document scope,
git diff --check, changed-lines credential/security scan, and unsafe-instruction sweep passed. PR metadata was updated and read back. This exact SHA has zero commit statuses and zero Actions runs because the repository’s only workflow isworkflow_dispatch. The issue remains open until merge.HS restored: series-resistor rework result
Piotr replaced the two verified 100 Ω USB D+/D− series resistors with 12 Ω parts. Immediate runtime result:
This is direct hardware proof that the original 100 Ω-per-line series network was the High-Speed negotiation blocker. Keep 12 Ω installed during the next validation gates; do not change resistance again until fresh full HCD/UTMI rebind and WFB stability are verified.
Remaining acceptance: new high-speed enumeration in dmesg, full
Sstar-ehci-1unbind/bind remains 480, and established WFB baseline works without USB disconnects.The successful 12 Ω rework result is now incorporated into PR #2: #2
New verified head:
36e63aeff0758b6743488b46769b479bfa22a012. The investigation record now states that replacing both verified 100 Ω per-line D+/D− resistors with matched 12 Ω parts changed the immediate runtime speed from12to480Mbit/s. This direct A/B evidence confirms the original 100 Ω network as the High-Speed negotiation blocker on this unit. It does not claim 12 Ω as a universal SSC338Q requirement or establish long-term signal margin.The historical parallel-resistor proposal is marked superseded and was never executed. Keep the installed 12 Ω parts unchanged and retain the 4096 kbit/s WFB limit until all remaining owner-run gates are recorded:
dmesgshows a new high-speed enumeration without relevant USB errors;Sstar-ehci-1unbind/bind over Ethernet or console still reports480;Independent review corrected stale pre-rework wording and prevented the first
480result from prematurely releasing the conservative WFB limit. Single-document scope,git diff --check, credential/security scan, stale-instruction sweep, and overclaim/unsafe-instruction review passed. PR metadata was updated and read back. For this SHA there are zero commit statuses and zero Actions runs because the repository’s only workflow isworkflow_dispatch. Root cause is confirmed; full hardware acceptance remains pending these three gates. The issue remains open until merge.