Articles

Haltech workflows

Best Haltech Channels to Log for Startup, Dyno, and Track Use

A builder-grade Haltech channel checklist for first startup, street testing, dyno pulls, and track sessions, with priorities by use case.

15 min read

Start with the decision the log must support

A useful Haltech channel set starts with a question: is the engine safe to run, is the fuel model right, is boost control behaving, did the hardware change work, or did the car survive a full session? If you log every available channel without a purpose, review gets slower and the signal gets harder to see. If you log too little, the file cannot prove anything.

Build channel sets by use case, not by habit

First startup, dyno tuning, street validation, and track sessions are different tests. They share a core group of channels, but the priority changes. First startup needs sensor sanity and pressure confidence. A dyno pull needs actual-versus-target fueling, ignition, and boost behavior. A track session needs heat, pressure, gear, speed, and driver-demand context over time.

  • First startup asks: are sensors believable, does the engine have oil/fuel pressure, is voltage stable, and is lambda control sane enough to continue?
  • Street shakedown asks: does the car behave through transient throttle, cruise, light boost, heat, alternator load, fan cycles, and real airflow?
  • Dyno tuning asks: did the engine hit the intended load window, did measured lambda match target, did boost follow target, and did timing stay where expected?
  • Track use asks: what happens when heat, lateral load, fuel slosh, airflow, shift events, and driver variability stack together for multiple laps?

Respect logging limits and review limits

Haltech documents Elite datalog channel setup in its Datalog Elite support article, including selecting channels and sample rates. Nexus hardware can expose broader modern logging capability — for example Haltech lists the Nexus R5 VCU with onboard logging capability far beyond an older minimal channel set — but bigger logging capacity does not remove the need for a focused review profile.

  • Use high sample rates for fast events: RPM instability, boost oscillation, gear shifts, throttle transients, knock, and pressure drop under load.
  • Use slower rates for slow-moving context: coolant temperature, fuel level, ambient conditions, and sometimes long-session thermal trends.
  • Do not bury critical safety channels below dozens of rarely used status flags. If a review layout hides oil pressure, fuel pressure, voltage, or lambda target, it is the wrong layout.
  • When storage or channel count is limited, prioritize channels that explain cause and effect over channels that are merely interesting.

Use a core channel set for almost every log

Most Haltech logs should start from the same core: driver demand, engine speed, load, fueling, ignition, temperatures, pressures, voltage, and ECU intervention. This gives you a repeatable baseline so each article, dyno session, or race weekend does not start from scratch.

Driver demand and operating point

These channels tell you whether the test actually happened. Without them, you may mistake a partial-throttle lift, traction event, or shift for a tune problem.

  • RPM: the horizontal reference for most tuning and diagnostic decisions.
  • Throttle position and/or pedal position: confirms whether the driver requested torque and whether throttle closure influenced the result.
  • Vehicle speed and gear: separates comparable pulls from mixed-condition driving, shift events, wheelspin, or traction-limited acceleration.
  • MAP, load, or manifold pressure: shows the actual air-load state the engine saw, not just the intended boost or table area.
  • Run timer or time: useful for aligning events, heat rise, fan cycles, staged dyno pulls, and multi-lap sessions.

Fueling and mixture control

Fueling channels should let you compare target, measured result, and correction. Haltech support material for Target Lambda and O2 Control is worth linking because actual lambda alone is not enough. A measured value only matters relative to the target and the strategy trying to correct it.

  • Measured lambda or AFR, preferably lambda for fuel-independent review.
  • Target lambda or target AFR, so you know whether the measured value is actually rich or lean for that operating point.
  • Closed-loop fuel correction or short-term correction, to see whether the ECU is hiding a base fuel error.
  • Injector duty cycle and/or injector pulse width, especially near high load or high RPM.
  • Fuel pressure and differential fuel pressure if available. A wideband cannot tell you whether the system maintained pressure under boost.
  • Fuel composition, flex-fuel content, or ethanol percentage when relevant.

Ignition, knock, and ECU intervention

For ignition review, log what the tune commanded, what the ECU delivered, and what safety systems did. A pull can look conservative because timing was pulled, not because the base table is right.

  • Ignition timing or final delivered timing.
  • Knock level, knock count, knock threshold, or knock correction if configured. Haltech’s Knock Control documentation is useful context for understanding that knock systems depend on setup and calibration, not just a generic number.
  • Timing trims from intake air temperature, coolant temperature, boost, flex fuel, knock, torque management, or protection strategies.
  • Launch, traction, boost-by-gear, flat shift, rev limiter, or engine protection status channels if those strategies are active.
  • Crank/cam sync or trigger error channels during startup, high-RPM instability, or breakup diagnosis.

Temperature, pressure, and electrical health

These channels explain whether the test environment was healthy. Many calibration ghosts are actually heat, pressure, or voltage problems.

  • Coolant temperature and intake air temperature for thermal context and compensation review.
  • Oil pressure and oil temperature where available, especially for track use or high-RPM dyno work.
  • Fuel pressure, differential pressure, and pump duty if available.
  • Battery voltage, alternator behavior, fan state, pump state, and any power management channels that affect injector dead time or ignition energy.
  • Boost control state, wastegate duty, boost target, and manifold pressure when any forced-induction control is being reviewed.

First startup channel set

The first startup is not a power test. It is a sensor, oiling, fueling, trigger, and electrical sanity test. Keep the channel set narrow enough that problems are obvious immediately.

Required first-start channels

The goal is to catch “stop now” conditions quickly. The log should make it obvious whether the engine has oil pressure, sane RPM signal, reasonable temperatures, stable battery voltage, believable MAP/TPS readings, and mixture feedback that is not wildly wrong once the sensor is active.

  • RPM, cranking RPM, and trigger/sync status if available.
  • Throttle position, pedal position if drive-by-wire, MAP, coolant temperature, intake air temperature, and battery voltage.
  • Oil pressure, fuel pressure, and differential fuel pressure if wired.
  • Lambda or AFR once the wideband is warmed and active, plus target lambda and O2 correction if closed-loop is enabled.
  • Injector pulse width, ignition timing, idle control position, fan state, and any engine protection flags.

First-start review pattern

Read the first-start log in order: cranking sync, oil pressure rise, idle catch, voltage stability, temperature rise, fan cycle, mixture behavior, and sensor plausibility. Do not tune idle aggressively until you know the sensors and base mechanical state are trustworthy.

  • If RPM drops out or spikes during cranking, solve trigger/sync before chasing fuel or idle control.
  • If oil pressure is slow or unstable, stop. No amount of lambda correctness makes a pressure problem safe.
  • If battery voltage sags badly during cranking or fan operation, fix power/grounds/charging before trusting injector and ignition behavior.
  • If coolant or air temperature is impossible before startup, fix the sensor calibration before using compensation tables.

Dyno channel set

A dyno pull should be repeatable evidence. The log must show the operating window, target-versus-actual behavior, and anything that invalidated the pull. The goal is not just a horsepower number; it is a clean explanation of why the pull made that number safely or did not.

Required dyno channels

For a ramp pull, log the channels that explain torque request, load, mixture, timing, boost, temperature, pressure, and intervention. If the dyno operator or tuner cannot tell whether the ECU followed the intended strategy, the channel set is incomplete.

  • RPM, throttle position, MAP/load, vehicle speed or gear, and run timer.
  • Measured lambda, target lambda, O2 correction, injector duty cycle, injector pulse width, fuel pressure, and fuel composition if relevant.
  • Ignition timing, knock/correction, timing trims, limiter/protection state, and any torque management state.
  • Boost target, manifold pressure, wastegate duty, boost control mode, and gear if boost strategy changes by gear.
  • Coolant temperature, intake air temperature, oil pressure, fuel pressure, battery voltage, fan state, and pump state.

Make pulls comparable

A channel set only helps if the pull is comparable. Align the same gear, similar start RPM, similar ramp rate, similar coolant and intake temperature, and similar throttle behavior. Label baseline, change, and repeat pulls explicitly so the log history can be trusted later.

  • If throttle is not steady or wide open during the intended window, label the pull dirty.
  • If IAT or coolant temperature changes materially between pulls, note that before judging power or knock sensitivity.
  • If boost target changed, table cells changed, or fuel changed, do not compare the pull as if only one variable moved.
  • If correction is doing the work, do not call the base fuel map finished just because measured lambda hit target.

Track session channel set

Track logging exposes problems that a short dyno pull may never show: heat soak, oil pressure under lateral load, fuel pressure during long sweepers, driver throttle behavior, shift problems, and recovery between laps. The channel set should preserve enough context to connect engine data with session reality.

Required track channels

A track profile should keep the engine safety core but add session context. Vehicle speed, gear, lap/session markers, temperature trends, and pressure channels are especially valuable because track issues are often time- and load-dependent rather than single-pull events.

  • RPM, throttle position, MAP/boost, vehicle speed, gear, and time/lap marker if available.
  • Measured lambda, target lambda, correction, fuel pressure, injector duty cycle, and fuel level or fuel pressure behavior during long corners if available.
  • Coolant temperature, intake air temperature, oil temperature, oil pressure, battery voltage, fan/pump states, and protection flags.
  • Knock/correction, timing, limiter events, traction or torque management state, and boost control state.
  • Optional but valuable: brake pressure, steering angle, lateral/longitudinal G, tire pressure/temperature, GPS speed, and lap time from an external logger.

Read track logs as sequences, not pulls

On track, one lap may not tell the truth. Compare out-lap, first push lap, best lap, late-session lap, and cooldown behavior. A car that is safe for one short burst may lose fuel pressure, oil pressure, timing, or boost control after heat and lateral load build.

  • Watch pressure behavior in corners, not only on straights. A stable dyno fuel pressure trace does not prove pickup under lateral load.
  • Watch IAT and coolant trends over the whole session. Heat soak can explain timing pull, power loss, knock sensitivity, or richer/leaner correction drift.
  • Mark traffic, driver lifts, missed shifts, yellow flags, or cooldown laps so they do not become false performance conclusions.
  • Pair the ECU log with driver notes and tire pressure data when the question is chassis balance or consistency rather than engine safety alone.

Create reusable profiles and naming rules

The best channel set is the one you can repeat. A dedicated builder should not rebuild the logging setup every time the car goes to the dyno or track. Create profiles, name files clearly, and keep the minimum viable context with every log.

Use profile tiers

Keep three or four saved profiles instead of one giant profile. A practical set is: first startup, street shakedown, dyno pull, track session, and fault diagnosis. Each profile should include the core safety channels plus use-case-specific context.

  • Required channels are the ones needed to decide whether to continue safely.
  • Useful channels explain likely causes when required channels show a symptom.
  • Advanced channels support specific strategies: boost control, traction, torque management, flex fuel, staged injection, power management, or aero/chassis integration.
  • If a channel is never used to make a decision, move it out of the default profile and into a diagnostic profile.

Name logs like evidence

File names and notes should make a log understandable months later. A good name includes date, vehicle, session type, change, run number, and outcome. “dyno_pull_04_boost_base_duty_minus5_clean” is ugly but useful. “finalfinal.log” is not evidence.

  • Good: 2026-05-23_miata_e85_dyno_pull03_18psi_base-duty-minus5_clean.log
  • Good: 2026-05-23_summit_session2_hot-pressure-change_push-midcorner.log
  • Bad: test, goodpull, log12, final.
  • Keep dirty or inconclusive logs, but label why they are not valid baselines.

Review the profile after every failure

Every time a log cannot answer the next question, update the profile. Missing fuel pressure after a lean pull, missing target lambda after a fueling review, or missing gear after a boost-by-gear test are not one-off annoyances. They are profile defects to fix before the next session.

Frequently asked questions

How many Haltech channels should I log?

Log the smallest set that can prove the decision you need to make. For most meaningful reviews, that means RPM, throttle, MAP/load, lambda, target lambda, fuel correction, timing, knock/correction, temperatures, pressures, voltage, and the relevant strategy states. Haltech’s Datalog Elite documentation is a useful reference for channel selection and sample-rate setup.

Should I log every Haltech channel if my ECU supports it?

Not by default. Bigger logs can be useful for fault diagnosis, but default review profiles should keep critical channels visible. Use broader profiles when chasing a specific issue, then return to a cleaner startup, dyno, street, or track profile for normal work.

What channels matter most for dyno tuning?

For dyno tuning, prioritize RPM, throttle, MAP/load, measured lambda, target lambda, O2 correction, injector duty, fuel pressure, ignition timing, knock/correction, boost target, manifold pressure, wastegate duty, coolant temperature, intake air temperature, oil pressure if available, and battery voltage.

What channels matter most for track use?

Track logs need the engine safety core plus session context: RPM, throttle, MAP/boost, speed, gear, lambda, target lambda, correction, fuel pressure, oil pressure, coolant temperature, intake air temperature, battery voltage, timing/knock, protection states, and any available lap, GPS, brake, steering, or tire data.

How TuneWorks helps

For this Haltech workflow, TuneWorks keeps the vehicle, log file, channels, charts, and AI-assisted review in one place so the process described here becomes repeatable instead of a one-off inspection. The best Haltech channel set is not the biggest one. Log the channels that prove driver demand, engine load, fueling, ignition, temperature, pressure, and ECU intervention for the decision you need to make.