What's an orb, anyway.
If you arrived here from outside the hardware-overlay scene — you saw the word "orb" in a YouTube comment, you got linked from a friend, you're not sure what a sensor bridge is — this entry is for you. The product's seven orbs each look like a small thin ring with a number in the middle, sitting on your desktop. The rest of this note unpacks what that ring is doing.
The anatomy of one orb.
This is the GPU orb at sixty-seven percent utilisation. Five things are happening in the rendering. First, the thin coloured arc around the outside is the workload arc — it fills as the metric increases, all the way around if you're at one hundred percent. Second, the number in the middle is the headline, rendered as an outline-only numeral so the desktop background is visible through it. Third, the small "GPU" label above the headline is the orb's identity tag — it tells you which metric you're looking at. Fourth, the colour itself (each orb has its own from a seven-colour palette) is the secondary identity signal. Fifth, not visible in this still: a thin sparkline underneath the headline showing the metric's last sixty seconds.
What each of the seven measures.
CPU is overall processor utilisation, with an optional ring of tick marks around the perimeter — one per logical core. GPU is graphics utilisation; on cards that expose per-engine telemetry (3D, video encode, video decode) the orb optionally splits its arc into four sectors. RAM is memory pressure with DIMM tick marks. DISK is per-physical-disk activity, with hot-plug detection so a USB stick added mid-session shows up automatically. NET is network throughput against a configurable ISP cap, with ping latency in the chip row. FPS is frame rate sourced from RTSS or PresentMon when a game is running. BATT is battery state on laptops — charge percent, signed wattage (positive when charging, negative when discharging), time-to-empty.
BATT is the only one that conditionally deploys. On desktops, on VMs, on RDP sessions, on machines without a real lithium battery, the orb does not appear at all. The auto-detection runs at tray startup and uses a layered check: any installed battery instance with a lithium chemistry (LiOn or LiPo) is allowed immediately, otherwise the system type from Win32_ComputerSystem.PCSystemTypeEx has to read as Mobile or Slate. Desktops with a UPS attached do not light up a BATT orb, which is the common false-positive guard.
Where the data comes from.
Sensor data is read by a separate elevated process — the bridge — that talks to LibreHardwareMonitor's kernel driver. The bridge writes a snapshot file roughly once a second; the orbs themselves read the snapshot file at their own pace and never need admin privileges. This split exists because the kernel driver requires elevation to read CPU temperature, and elevating the orbs would require a UAC prompt every time you launched the tray, which is unacceptable for an everyday utility. Putting the elevated component behind a registered scheduled task means there's one UAC prompt at install time and zero per launch.
FPS comes from a separate bridge — Crystal Frame Capture — that wraps either RTSS or PresentMon depending on which one is available. NET runs entirely from Windows performance counters (no bridge required). BATT uses the Win32 power APIs directly — sub-millisecond P/Invoke calls that don't need admin and don't depend on LibreHardwareMonitor at all.
What the colour palette is for.
The seven theme colours are not decorative. They are how you read the orbs without legends. Once you've used Crystal Clear for a day, you know that blue is CPU and purple is GPU and amber is BATT, and you can identify any orb in your peripheral vision by colour alone. The palette is a deliberate tradeoff: it asks you to learn seven colour assignments in exchange for never reading a label again. The headline numeral and metric label inside each orb support the learning phase; once the palette is internalised, the orbs are functionally legendless.