layered-soul/skills/systematic-debugging/references/wifi-projector-dashboard-diagnostics.md

Wi-Fi/projector/dashboard diagnostics notes

Use this reference for recurring home-network investigations where the user wants an understandable history dashboard plus occasional packet evidence. The class of task is: Wi-Fi/SSH/tmux lag with changing topology, phone hotspots, projectors/streaming devices, and non-technical viewers.

Storage and legibility defaults

• Do not write repeated diagnostics to the Desktop.
• Use a single run directory under ~/.local/state/hermes/net-tests/<scenario>-<timestamp>/.
• Put generated dashboards under ~/.local/share/hermes/net-dashboard/.
• For non-technical viewers, lead with spike charts and plain-language event cards. Keep tables and packet details behind <details>.

Event markers matter

When the user reports a real-world change, immediately write a marker file in the active run directory with:

• machine timestamp (date --iso-8601=seconds)
• user-observed timestamp if different (e.g. installer top-bar time)
• exact text/status the user saw
• current quick pings if useful

Examples of useful markers:

• projector turned on / streaming started
• Ubuntu installer visible / finished
• APT transaction summary visible
• Bluetooth turned off
• phone hotspot/network switch

If a capture window ended before the user's marker, say so clearly: that run is a pre-event baseline, not post-event evidence.

Avoid false single-cause stories

Projector tests can have multiple simultaneous variables. Label the dashboard accordingly rather than saying "Epson only" when other load is active.

Example topology note to capture:

• debby is on phone hotspot in basement
• projector/router are upstairs
• another Ubuntu laptop is also on the hotspot near the projector/router
• Ubuntu installer may or may not still be downloading
• Android hotspot client isolation may prevent seeing the other laptop in ip neigh

Interpret spikes by segment:

• clean gateway + spiky internet/Tailscale => upstream/mobile/hotspot saturation or bufferbloat
• spiky gateway too => local Wi-Fi/RF/hotspot contention
• improvement after Ubuntu install finishes => installer/download load was relevant
• continued spikes after installer finishes while projector streams => projector/streaming or broader RF/mobile path remains suspect

Short pcap sampling pattern

With low disk space, avoid continuous pcaps. Prefer periodic short packet samples:

• 20 seconds every 5 minutes
• strict per-sample filesize caps
• stop below a free-space threshold
• capture control/diagnostic traffic and interactive paths, not full large-download payloads

Suggested filters:

• Wi-Fi interface: arp or icmp or port 53 or udp port 5353 or udp port 5355 or udp port 1900 or udp port 3702 or udp port 41641 or host <gateway> or net <hotspot-subnet>
• Tailscale interface: tcp port 22 or icmp

Keep pcaps under the active run directory in pcap-samples/, and summarize them into the dashboard later. Do not dump raw packet logs into chat.

A reusable sampler script is available at scripts/periodic-pcap-sampler.sh.

Bluetooth on 2.4 GHz

If Wi-Fi is also 2.4 GHz, Bluetooth can sometimes contribute to local jitter because Wi-Fi/Bluetooth coexist on nearby spectrum and often shared hardware. Treat Bluetooth-off as a marker and compare before/after; do not overclaim. If local gateway ping stays good but internet/Tailscale remains hundreds of ms, Bluetooth is not the main cause.

Ubuntu installer / APT evidence

Installer screenshots can provide useful network-load timing. Record visible logs with both report time and screenshot/log timestamps. For example, an APT summary showing Need to get: 218 MB and visible Get: lines around 23:49 means a real download phase occurred then, even if the user reports it later.