theallelectricsmartgrid

Hub power and heat hypothesis — September 10, 2026

Status: hardware identified and read-only diagnostics collected. No PD-removal or hub-cooling trial has run under agent control. The user is free to perform ad hoc trials; no recording or log collection is active. After the user’s request to experiment, avoid device probes unless a new capture is coordinated.

Identity and specifications

The user reports a 90 W PD charger and identifies the hub through Amazon ASIN B0DHBFDFWC, “Satechi 4-in-1 USB-C Hub, 100W PD Pass-Through Charging.” The corresponding Satechi model is ST-H4CPDM, UPC 810086361328. The Amazon page could not be fetched; model mapping uses the user’s product description and Satechi’s matching product/manual, rather than claiming a retail SKU was read from the USB descriptor.

The official product page lists four USB-C 3.2 Gen 2 data ports at up to 10 Gbps, one sharing the PD-input role, up to 100 W PD input and 75 W maximum host output. The manual lists three peripheral ports at up to 5 V/1.5 A each and separately says a single peripheral should not exceed 5 V/2 A. It does not establish the simultaneous bus-powered budget for our iPad/MAYA/WB setup.

The quick guide differs in wording: it mentions 15 W for operation and says the data ports do not support charging, whereas the manual gives 5 V/1.5 A. Preserve this inconsistency. Do not infer a measured 15 W heat dissipation or promise 85 W host delivery. Charger rating, PD contract, host draw, peripheral-port limit and hub heat are different quantities.

Direct iPad reading at 12:54:31 PDT

Authenticated read-only Wi-Fi queries of the battery domain, IOPMPowerSource and IOUSBHostDevice completed without changing any setting. General paired Wi-Fi connection preference remained false. Raw base: /private/tmp/smartgrid-ipad-power-hub-20260910; compact query output is preserved in summaries/ and the reusable collector in analysis/.

A scoped search of the already-collected UI-off archive (12:26:20–12:43:50) for powerd/kernel charger, VBUS, PD-contract, overcurrent and hub-temperature messages found one powerd “Charging Completed” event at 12:38:12 with VBUS 1 and battery 100%. No explicit overcurrent/PD-contract/hub-temperature event was returned by that query. This limited logging result does not rule out power transients or establish continuous charging state throughout the test. The archive decoder warned of a wall-clock adjustment; retain its bounded interpretation. Exact output: summaries/smartgrid-juce815-ui-off-power-events-20260910.txt.

Can charging or hub temperature be controlled/read?

Apple documents an 80% charge limit on iPad Air M2 and later, including this M3. The battery already reports charging off at the sampled 100%. Apple’s charge limit controls battery filling; it is not documented as disconnecting the USB-C external power path. No supported app/API switch to isolate that power path was identified or invoked.

No accessible hub thermometer was found in the device record or the inspected model documentation. The app’s thermal state describes the iPad, and nominal iPad thermal state does not establish hub temperature. Hub enclosure temperature can be measured externally, preferably with a contact sensor; enclosure temperature still differs from internal chip temperature. Satechi’s troubleshooting guidance says its aluminum enclosure dissipates heat and can warm under peripheral/charging load. This establishes expected heat generation, not that our hub is overheating.

Working hypothesis and experiment order

Heavier UI work could increase iPad power demand through the hub even while the battery is not charging. A hub/PD supply or temperature interaction could therefore connect application workload to USB errors. This is plausible, not demonstrated. The observed snapshot does not show an obvious steady-state iPad input-power shortfall; it cannot exclude brief voltage disturbances, hub temperature or device-specific power behavior. Current Mac pmset reports AC power; that does not reconstruct its earlier hub power role.

  1. PD present versus absent: leave iPad/MAYA/WB cables, app, patch, UI, 48 kHz/512 and radios fixed; remove only the charger cable from the hub. Verify the peripherals remain powered and MAYA route/rate/frames/music before capture. This changes supply and power direction, potentially grounding and USB session state; do not treat the transition/reset as a spontaneous fault. Repeat both conditions. If bus power is insufficient, this comparison is unavailable, not a clean result.
  2. Hub cooling: keep all power/data connections unchanged and apply external airflow to the hub, ideally measuring case temperature. Compare repeated cooled/uncooled intervals within a continuous session. This targets heat more directly than unplugging PD.
  3. UI within one audio session: toggle rendering while preserving the same open audio session, then separate FFT/scope arithmetic from drawing if needed. Existing sequential UI pairs support an association but are confounded by new session setup and bursty errors.
  4. Native boundary tracing: measure whole callback entry/exit and output samples returned to RemoteIO, beyond the existing DSP subsection. Then choose session/backend or individual worker experiments from the evidence.

Score sporadic transaction-error/restart dropouts and periodic holes separately in every condition. JUCE 8.0.15 has already reproduced both. Keep the permanent 48 kHz request/guard and 512-frame request throughout. No app source or device power setting was changed for this power investigation.