ira started as a telemetry display. Connect to iRacing's shared memory, show speed and RPM, log to CSV. Useful but narrow. On Saturday it gained race guides, session registrations, owned content detection, and a test suite. Seven commits. One day. A different kind of application.
What ira was
A C program that did three things well:
- Read telemetry from iRacing’s shared memory at 60Hz
- Log that telemetry to CSV for post-session analysis
- Launch helper applications automatically when a session starts
All local. No network calls. No authentication. The iRacing SDK gives you shared memory for free, and everything ira did was built on that foundation.
What changed
iRacing has an HTTP API behind OAuth2. It knows what content you own, what races are scheduled, who is registered for upcoming sessions, and what the next race time is for every series. All of that information is useful before you click “Join” — and none of it was accessible from ira.
Saturday’s sprint added four capabilities:
Race guide — fetch the week’s schedule for any series: track name, session times, registration counts. Instead of opening the iRacing website to check what’s running, the information is available from the terminal.
Session registrations — see which upcoming sessions have registrations open, how many drivers are signed up, and when they start. Useful for picking sessions with healthy grids rather than guessing.
Owned content filtering — query the member info API for owned cars and tracks, then filter the race schedule to only show series where you actually own the required content. No more scrolling past races you can’t enter.
Next race time — calculate when the next session starts for a series using the schedule’s repeat interval. A simple question (“when does the next MX-5 race go off?”) that previously required mental arithmetic or a browser tab.
The test suite
The same day also added the project’s first unit test suite. Filter logic, model parsing, time calculations — the kind of code that is easy to get subtly wrong and hard to debug through manual testing.
One immediate payoff: the vibe review that ran after implementation caught three bugs — UTC timestamp handling, a session registration cache issue, and an integer overflow edge case. All three were found because the tests made the expected behaviour explicit enough to reason about.
The first test suite a project gets is always the most valuable one.
Why C
ira is written in C11. Not because C is the right choice for HTTP API clients — it is not — but because the project started as a telemetry tool, and shared memory access in C is natural. The iRacing SDK is a C API. The data structures map directly. There is no marshalling, no bindings layer, no impedance mismatch.
Adding HTTP and JSON on top of that means pulling in libraries (libcurl, cJSON) and writing more boilerplate than a higher-level language would require. But the alternative — rewriting the telemetry layer in another language — would lose the direct SDK integration that makes the core of the application clean.
So the project stays in C and accepts the trade-off: more explicit code for API work, but a single language and build system for the entire application.
What is next
The race planning features are read-only for now. The logical next step is making them actionable: filtering the race guide against your owned content automatically, presenting a “what can I race right now” view, and eventually integrating with the telemetry side so that pre-race information flows into the session context.
ira is still a terminal application. But it is no longer just a telemetry viewer.