ATLAS HWiNFO Bridge
Streams live hardware sensor data from HWiNFO into Motion Applied ATLAS, so the machine driving the rig gets the same telemetry-style analysis as the car does.
The problem it solves
HWiNFO exposes several hundred readings on a typical PC - per-core clocks and temperatures, VRM and package power, fan headers, drive S.M.A.R.T. values, GPU hotspot deltas, explicit throttling flags - all sitting in Windows shared memory where nothing outside HWiNFO itself can see them. ATLAS is built to plot and overlay exactly this kind of time-series data, but has no native way to read HWiNFO's shared memory. This bridge is the missing link: it opens that shared memory directly, turns any subset of those readings into ATLAS parameters, and streams them through the same Kafka pipeline ATLAS already uses for car telemetry - so a GPU thermal throttle shows up on the same timeline as a lap time drop-off.
The bridge's own web UI, mid-session: connection status, sample count, and live values grouped by CPU/GPU/Memory/Network/Fans.
What's involved
Presets are computed against the machine's actual sensor tree, not a fixed list - the UI lists every reading HWiNFO currently publishes, live values included, with a search filter and select-all/select-filtered controls for building a custom set.
The same web UI that starts and stops the bridge also renders the values it's currently streaming, grouped by sensor, so there's no need to open ATLAS just to confirm data is actually flowing.
ATLAS registers each parameter with its own gRPC round-trip, so the picker warns past 250 channels selected - "full" on a well-instrumented board can mean a real wait before data starts.
HWiNFO's free build turns Shared Memory Support off again after 12 hours of runtime. The UI shows how long ago HWiNFO last refreshed its block and surfaces a clear notice - with a one-click retry - rather than silently flat-lining.
Computed channels - without writing FDL in ATLAS
The normal way to get a calculated value into ATLAS - a Fahrenheit conversion, a thermal
headroom margin, a VRM power figure - is to write it as an FDL function inside ATLAS's own
Function Editor. That means re-creating it in every workbook, and it can only ever see channels
already present in that session. This bridge does the same kind of maths on the way in instead:
a small JSON config lists formulas like $CPU0_CPUTctlTdie * 1.8 + 32, and the
result streams to ATLAS as its own ordinary channel - no FDL, no per-workbook setup, available
the moment the session starts.
Each formula is parsed into a Python AST and checked against a strict whitelist - arithmetic,
comparison, boolean logic and a if c else b conditionals are allowed; function
calls, attribute access, subscripting, comprehensions and lambdas are not. That's what makes
it safe to compile a formula once at session start and evaluate it every sample tick with no
further sandboxing needed.
Not just unit conversions: thermal headroom below a GPU's throttle point, VRM rail power computed as V×A and cross-checked against HWiNFO's own reported package power, efficiency ratios like MHz per watt, sensor-vs-sensor deltas (CCD imbalance, internal vs. motherboard temperature sensor), and plain 0/1 "hot" flags for a quick at-a-glance alert.
Specs resolve in file order, so a later formula can reference an earlier derived channel's result - the shipped config computes three VRM rail powers first, then sums them into a total, then diffs that total against the package power HWiNFO reports, all as separate chained channels.
A malformed entry is logged and skipped at load rather than failing startup; a channel
referencing a sensor this machine doesn't have (no CPU temp probe, say) drops silently
rather than blocking the rest; and evaluation itself never raises - a runtime problem like
divide-by-zero yields 0.0 instead of breaking the sampling loop.
Backed by 10 dedicated tests: formula compilation, missing-reference handling, divide-by-zero safety, rejected constructs, and chaining one derived channel off another.
Why it's worth trusting
The shared-memory parsing is tested against a synthetic block, so nothing about the test suite depends on HWiNFO actually running - it covers both of HWiNFO's struct layouts, unit and naming derivation, preset selection, duplicate sensor labels, a missing section, and sensors being added mid-session. Everything downstream of parsing - the gRPC session, Kafka, the Docker stack - is the same infrastructure my other ATLAS bridges already run in production.