QtTune v0.3.1

QtTune 0.3.1 is the first release with a Windows download: unzip it, run qttune.exe, and pick mock://demo in Settings to watch the built-in simulated car drive. It needs no Qt, no Visual Studio and no separate Visual C++ redistributable. Read DISCLAIMER.md before connecting it to a vehicle.

Try it

1. Download qttune-0.3.1-windows-x64.zip below and unzip the whole folder.
2. Run qttune.exe. The program isn't code-signed, so SmartScreen may stop it the first time: choose More info, then Run anyway.
3. In Settings, press the mock://demo preset, then Connect.

The zip's README.txt covers adapters and what each file is.

What's new since 0.3.0

Talking to the car

• A request engine paces requests by the replies: one request in flight per ECU, the next sent as soon as the answer arrives, with a 100 ms wait, 78 (response pending) honoured, and a 20 ms floor between requests (ADR-0015).
• A PID-support probe reads each ECU's supported-PID bitmaps before polling and drops the PIDs it refuses, so a car that doesn't support a signal stops being asked for it.
• Vehicle identification at connect: VIN, calibration IDs, CVNs and the ECU's name (Service 09), and the standard UDS identification DIDs (ADR-0021).
• A uds-generic profile polls the UDS DIDs you list, or scans a range for the ones that answer, with text and hex values as well as numbers (ADR-0020).
• Whole ISO 15765 messages: a frame carries up to 4096 bytes, so long multi-frame replies arrive in one piece.
• Connect failures say why: a bad URI, an unknown profile, a vendor refusal (with the driver's own error text), a surrogate that failed, or a DLL that won't load each have their own code and message (ADR-0018).

The app

• Metric or imperial, chosen in Settings and remembered. Imperial is the default. Recordings keep the values exactly as decoded (ADR-0022).
• Settings composes the URI from profile buttons and a DID field, and reads a typed URI back into them.
• A simulated car worth watching: a modelled 4.5 L rear-drive coupe drives a scripted loop (a cold start, full-throttle pulls onto a fuel-cut limiter, a highway cruise, a stop, and a quarter mile off launch control with wheelspin) in real time. Its readings stay consistent with one another the way a real ECU's log does, and like a real log they never sit dead still.
• Frames carry session time, from the adapter's own clock where it has one.

Engineering

• Line coverage published to Codecov from a Windows CI job, libFuzzer harnesses for the decoder, the validators and the uds-generic query parser, and a Code of Conduct and governance notes.

What's verified, and where

QtTune's claims are tiered (docs/testing.md):

• Every build runs the full test suite on Windows, macOS and Linux, plus sanitizers and fuzzing, in CI. Everything above passes it.
• The J2534 stack is verified end to end against an in-tree fake vendor driver, in-process and through the 32-bit surrogate, including the request engine, the probe, identification and the DID scan.
• One real adapter (an OBDX Pro VX) has connected on a quiet bench bus, and one car has been read, read-only, through the surrogate, on 2026-10-22 (session sheet). That session ran 0.3.0's scheduler: the request engine, the probe, identification and uds-generic have not yet run on a car. The next vehicle session is planned to cover them.
• Other vehicles and adapters are untested.

Verifying the download

SHA256SUMS.txt holds the zip's SHA-256. The zip also carries a signed build provenance from this repository's release workflow, which you can check with the GitHub CLI:

gh attestation verify qttune-0.3.1-windows-x64.zip -R erickramer42/qttune