Run the whole chain before the out-lap

Generated from content/lms/telemetry-systems-engineering/07-system-integration-and-troubleshooting/01-integration-smoke-test.md; edit the source file, not this page.

Source path: content/lms/telemetry-systems-engineering/07-system-integration-and-troubleshooting/01-integration-smoke-test.md

Course: Design and validate the telemetry system that feeds every decision

Module: Integrate the full pipeline and keep it running

Estimated duration: 55 minutes

An integration smoke test is the short proof that the telemetry system can do its whole job before the car leaves to make data at speed. It is not the same as seeing the logger power light come on. It is not a full engineering analysis. It is not the next-session fault diagnosis lesson. The skill is narrower and more urgent: before the out-lap, you prove that the sensors, wiring, logger, lap source, dashboard functions, download path, analysis software, display template, and human decision loop are connected well enough to produce usable evidence.

That distinction matters because a data system can fail quietly. A car can leave the paddock with a working logger but no usable lap marker. It can record channels but fail to exchange engine data with the chassis logger. It can have a dashboard configured for a reference lap, but not for the current session. It can have the six basic driver channels present, yet no battery-voltage or pressure context to warn you that the car itself needs attention before anyone talks about driving technique. The smoke test is the discipline that catches those failures while the car is still close enough to fix.

The principle is simple: prove the next decision, not the whole season. You are not trying to answer every performance question before the first out-lap. You are trying to make sure that, when the car returns, you can open the file quickly, see the vital channels first, inspect the basic performance channels, segment the run, compare what needs comparing, and set a specific objective for the next session. The bonded sources put the same idea several ways. Begin with the vital channels before performance data. Look for the obvious first. Use other channels to check a hypothesis. Ask why. Compare laps when you can. Keep the system simple enough that you can actually use it under time pressure.

For an intermediate Tracky user, the important change is that you stop treating integration as an installation task and start treating it as an operational habit. Installation asks whether the system exists. Integration asks whether the system produces useful, interpretable data in the environment where the team will use it. Your smoke test is complete only when the file makes it all the way from the car into the analysis view, with the channels and lap structure needed for the next engineering decision.

The chain you are proving

Think of the telemetry chain as seven linked jobs. First, the car has to measure the intended channels. A basic logging kit should at least cover vehicle speed, engine RPM, throttle position, steering angle, lateral acceleration, and longitudinal acceleration. Those six channels already give you a large amount of analysis value. If the car is more instrumented, brake pressure, suspension movement, wheel speeds, gear position, tire temperatures, tire pressures, ride height, yaw rate, brake temperatures, and other channels may be in the system. The exact set is not a trophy list. The source material is clear that engineers should ask what they actually want to measure. Specific needs require specific channels.

Second, those measurements have to reach the logger. This is where cables, connectors, spare sensors, and backup equipment matter. The pit area is part of the telemetry system because failures do not wait for a convenient moment. Critical sensors should be within reach, and so should the equipment needed to recover from a failure. A smoke test that ignores the physical layer is incomplete. If the harness is vulnerable, the connector is questionable, or the spare you need is buried in the trailer, your analysis workflow is only theoretically ready.

Third, the logger has to record a file that can be retrieved. The sources emphasize downloading the logger every time the car enters, including engine warm-ups and rollout laps, because even those short runs can contain relevant information. That instruction is useful before the out-lap as well. A warm-up file is not wasted data. It is a low-risk chance to prove the logger, storage, transfer path, and analysis template before the car is committed to a session.

Fourth, the data needs lap and distance context. A beacon channel should identify the beginning and end of a lap, and modern systems may also use virtual beacons for sectors. Without lap structure, the file may still contain data, but the analysis becomes slower and less reliable. Time and distance plots are central because they let you compare laps directly. Speed traces are especially valuable because they show where time is gained or lost. A smoke test has not passed if you can only see a pile of samples but cannot orient them by lap, distance, or sector.

Fifth, the engine data and chassis data need to meet in the same analysis context when the system depends on both. The sources describe an engine ECU or engine logger that communicates with the external data acquisition unit, allowing engine signals to be transferred and overlaid with lap-timing beacons. That is a classic whole-chain test item. It is not enough to know that the ECU has RPM and throttle somewhere, or that the chassis logger has acceleration somewhere else. If the workflow requires those channels to be overlaid, the smoke test must prove the overlay.

Sixth, the dashboard and driver-facing outputs have to match the data strategy. Modern dashboards may show shift lights, brake balance indication, wheel lock or slip warnings, sector times from virtual beacons, a reference-lap comparison, or predictive lap time. Those functions depend on logged data and on correct configuration. If you use them, they are not decorations; they are part of the system. The smoke test should confirm that the driver sees the intended information and that the display is based on the right reference or condition.

Seventh, the human loop has to close. The sources repeatedly connect analysis with driver comments, driver education, and next-session objectives. You listen to the driver because it tells you what to inspect. You avoid jumping straight to criticism because driver activity and chassis balance are closely related. You finish by setting objectives for the next session. The smoke test therefore includes the people and the process. The file has to open where the engineer can read it. The display template has to show the important channels. The team has to know what will be checked first when the car returns.

The minimum channel set for a smoke test

The first decision is scope. A smoke test fails when it tries to become a full analysis of every channel on the car. The source material supports a step-by-step system: start with the six basic channels, then extend the system as experience and need grow. That is also the right mental model for integration. You define a minimum acceptable channel set for this event, this car, and this session, then you prove that set before the out-lap.

For a basic HPDE or club-racing data workflow, the minimum performance set is vehicle speed, engine RPM, throttle position, steering angle, lateral acceleration, and longitudinal acceleration. Those channels let you orient the lap, see acceleration and braking, see steering activity, and compare driver inputs. They also support later driver analysis: braking points, brake application speed when brake pressure exists, throttle smoothness, shift timing, steering corrections, and consistency from lap to lap.

The minimum health set is separate. Before performance analysis, you inspect vital channels such as engine and driveline temperatures, pressures, and battery voltage. This ordering is important. A driver may want to know why the car feels poor, and the engineer may be tempted to go straight to speed traces, throttle traces, brake traces, and sector deltas. The better sequence is to make sure no strange things are happening in the vital channels first. If the car has a health or reliability issue, performance interpretation can wait.

If the car has more instrumentation, your smoke test adds only the channels that are expected to support decisions at this event. Brake pressure is a strong next channel because it directly supports braking analysis. Suspension movement and infrared tire temperatures are also identified as logical extensions in the source material. Gear position, wheel speeds, axle-specific lateral acceleration, yaw rate, tire pressures, brake disc temperatures, ride height, and suspension loads may all be valuable, but they are not automatically part of every smoke test. The question is not how many channels the system could log. The question is which channels must be present and readable for the team to act intelligently today.

A useful smoke-test worksheet therefore has three groups. Group one is vital car health. Group two is core driver and vehicle performance. Group three is event-specific extensions. If a channel is in group three, write why it matters. For example, if the session follows an aerodynamic change, the sources say the likely effects should show up in speed and wheel load traces. That makes speed and wheel loads part of the expected-evidence plan. If the session is about driver braking, brake pressure belongs in the minimum set. If the session is about dashboard coaching, sector timing or reference-lap comparison belongs in the minimum set.

The pre-out-lap sequence

Start before the engine runs. Stand at the pit box and make the physical system visible. Confirm that the critical sensors, cables, connectors, and spare equipment are reachable. This is not housekeeping for its own sake. It is how you keep a small integration problem from consuming the session. If a sensor or connector fails during the smoke test, you need the recovery path nearby.

Next, confirm the intended channel list against the actual car. Do not rely on memory from the last event. Data systems grow step by step. A car that had six basic channels last month may now have brake pressure or suspension travel. A car that usually has ECU exchange may be running a different configuration. The smoke test begins with the exact signals this setup is supposed to deliver.

Power the car and create a short record. If the engine warm-up can be logged, log it. The sources specifically point out that engine warm-ups and rollout laps can provide relevant information. In this lesson, that becomes a method: use the warm-up to prove that the logger records, the vital channels appear, the transfer process works, and the analysis template opens. You are not pretending an engine warm-up replaces on-track validation. You are using it to catch preventable chain failures early.

Open the first file in the analysis software. Do not stop at confirming that a file exists. A file that cannot be interpreted is not an operational pass. Load the same display template you will use when the car returns from the session. Check that vehicle speed, RPM, throttle, steering, lateral acceleration, and longitudinal acceleration appear where expected. If front brake pressure, gear, or other driver-evaluation channels are part of the template, confirm those too. The source examples of driver-activity displays place brake pressure, gear, RPM, speed, and throttle together because those channels help begin driver evaluation.

Now check vital channels before performance. Look at engine and driveline temperatures, pressures, and battery voltage. You are looking for obvious trouble and strange behavior, not doing a complete reliability study. The point is to avoid building a performance story on top of a car-health problem. If the vital channels are not present, not readable, or clearly not behaving as expected for the situation, the smoke test does not pass.

After vital channels, check the time and distance structure. Confirm that the system can identify lap start and end when a beacon or virtual beacon is used. If the car has not completed a lap yet, confirm that the lap source is configured and that the analysis software can use the distance or timing basis available from the file. For systems that support sector times from virtual beacons, confirm that the sectors exist in the dashboard or analysis configuration before they become part of a driver instruction.

Then check the speed trace. The source material gives speed special weight: the stopwatch says whether the lap is slow or quick, but the speed graph shows where time is gained or lost. In a smoke test, you are not yet mining time gain. You are proving that the main reference trace exists and can be read. If speed is absent, misrouted, or not usable in the display template, much of the later workflow becomes guesswork.

Check the channels against each other. The Data for Drivers process emphasizes looking for incongruencies, using other channels when available, comparing where possible, and asking why. That logic is valuable before the session. Do not accept each channel in isolation. If the throttle channel, RPM channel, and speed channel tell a coherent story during warm-up or movement, confidence rises. If one channel tells a story that conflicts with the others, you have a smoke-test finding, even if the logger says the channel is alive.

Confirm the dashboard only after the logged data path is sane. If the dashboard uses programmable shift lights, brake balance indication, wheel lock or slip warnings, sector times, reference-lap comparison, or predictive lap time, those features depend on configuration and previous data. Confirm the driver-facing display is using the intended setup. A dashboard function that looks impressive but is tied to stale assumptions can mislead the driver during the first timed laps.

Finally, decide whether the chain has passed. A pass means the car can leave with the team knowing that the minimum channels are present, the file can be retrieved, the analysis view is usable, lap or distance structure is ready, any dashboard outputs in use are configured, and the crew knows the first questions to ask when the car comes back. A fail means you either fix the broken link or deliberately reduce the data plan and tell the driver what will not be available. Silent partial credit is the dangerous option.

What good looks like in the first usable file

A good smoke-test file is boring in the right way. It opens quickly. The expected display template loads. The vital channels are visible before the performance discussion starts. The basic performance channels are present. The speed trace is readable. The lap, distance, or sector structure is not a mystery. If the ECU and external data acquisition unit are both involved, their signals appear in one usable context. If the dashboard uses reference-lap or sector functions, those functions are tied to the intended reference.

Good also means the data invites the next question instead of stopping the conversation. If you see an unexpected behavior, you can compare it with another channel. If the driver reports a handling issue after the run, you know where speed, acceleration, driver input, and health channels live. If the team made a setup change, you already know which traces should be examined first. If the driver wants an objective, the system can support one instead of forcing vague advice.

The strongest smoke-test evidence is not perfection. It is traceability. You can say what was tested, what passed, what was reduced, and what will be checked after the car returns. This matters because data analysis at an event is time-limited. The source material notes that during race weekends or test sessions, engineers must quickly find what is needed in the logged data. A clean smoke test buys that speed before the session begins.

The first review after the car returns

This lesson is about running the chain before the out-lap, but the skill is incomplete if you do not know what the chain is preparing you to do. When the car enters, download the logger every time. Do not wait for the perfect lap or the perfect complaint. Engine warm-ups and rollout laps can matter, and so can imperfect sessions with traffic. The sources warn against focusing only on the fastest lap and recommend looking across all laps for consistencies and inconsistencies. That starts with retrieving every file.

Begin with vital channels again. Engine and driveline temperatures, pressures, and battery voltage come before performance interpretation. If those channels show nothing strange, move to the car and driver activity: speed, acceleration, throttle, steering, brake pressure when available, gear, and RPM. Listen to the driver because the comment directs your search, but do not let the comment override the data. A driver complaint may point to a real chassis issue, a driver input pattern, or a combination of both.

Use the speed trace as the orientation trace. It tells where time is gained or lost. Then use the other channels to understand why. Throttle trace can reveal coasting, hesitant application, early application followed by a lift, or lifts in fast corners. Brake pressure can reveal the shape of the initial application, the trail, a long tail, inconsistent pressure, or light-long versus hard-short braking. Steering, RPM, gear, G-sum, GPS line, total steer angle, throttle histogram, segment times, fastest rolling, and theoretical fastest can all become useful once the basic chain is verified.

The smoke test is what makes that review possible. Without it, the team may discover after the session that the one channel needed to explain the driver comment was absent, the lap source was wrong, the display template hid the vital channel, or the dashboard comparison was never configured. You cannot recover the lost first session by wishing the integration had been checked.

Sub-skills inside the smoke test

Sub-skill one is channel intent. Before you test anything, you know why each required channel exists. Speed is the orientation trace. RPM and throttle help connect engine output and driver demand. Steering angle helps reveal driver activity and corrections. Lateral and longitudinal acceleration show cornering and braking or acceleration forces. Brake pressure supports braking technique and brake-system analysis when installed. Temperatures, pressures, and battery voltage protect the car-health decision. The more advanced channels only belong in the minimum test when they support a specific question.

Sub-skill two is plausibility checking. You are not calibrating the whole car from first principles during a smoke test, but you are checking whether channels behave in a way that makes sense for the known situation. The source process calls this looking for incongruencies and using other channels to check. A channel that exists but does not make sense beside related channels is not a clean pass.

Sub-skill three is lap and distance orientation. Data becomes much more useful when you can compare laps and sectors. The sources discuss beacons, virtual beacons, sector times, reference laps, and predictive lap time. Your smoke test therefore includes the timing structure, not just the raw channels. If the first post-run analysis requires direct comparison between laps, the pre-run test must prove that the system can support direct comparison.

Sub-skill four is retrieval discipline. Logging is not done until the file is in the analysis environment. A logger that records but cannot be downloaded quickly is not integrated into the event workflow. The source material stresses quick access while the driver's memory is fresh. The smoke test should therefore include the actual transfer path, not an imaginary one.

Sub-skill five is template discipline. You need the channels presented in a form that supports the first decision. A user-friendly display for driver activity puts the important channels together. Time and distance plots support lap comparison. Histograms, G-sum, GPS line, and reports may be useful after the basics are confirmed. A smoke test should open the template that will actually be used under pressure, not a generic view that hides the missing piece.

Sub-skill six is driver-loop control. Driver data is not just a way to find fault. The sources warn that driver activity and chassis balance are closely interrelated, and that criticism can damage confidence if handled poorly. A good smoke test prepares the engineer to have a better conversation: listen first, check vital channels, observe what the car is doing, then investigate why. The objective is a development tool, not a courtroom exhibit.

Calibration cues

You know the smoke-test habit is improving when fewer surprises appear after the car's first session. The laptop view after the run looks familiar because it is the same template you opened before the out-lap. The engineer is not hunting for the speed trace or wondering whether brake pressure was logged. The driver-facing dashboard shows the functions that were expected. The first review starts with vital channels and then moves cleanly to speed, acceleration, and driver inputs.

You also know it is improving when the team asks narrower questions. Instead of asking whether the data worked, you ask whether the speed trace, throttle trace, brake pressure shape, steering activity, or segment report supports the driver's comment. Instead of debating the existence of a problem, you compare laps and look for consistencies or inconsistencies. Instead of giving the driver vague feedback, you set a specific objective for the next session.

The data itself should show fewer integration artifacts. Laps should segment as expected. Channels used together should appear together. ECU-derived signals and chassis logger signals should overlay where the system requires it. Dashboard reference functions should align with the intended reference. When you make a setup change, the channels expected to show the effect should be present before the car leaves. When a channel is absent, everyone should know that absence before the session rather than discovering it afterward.

The most important calibration cue is time. Race weekends and test sessions compress analysis. A clean smoke test makes the first review faster because the path has already been exercised. If the car comes in and the driver still remembers the lap, the engineer can use that memory immediately. That is the difference between a data system as a developmental tool and a data system as an archive of missed opportunities.

How to keep the smoke test from becoming analysis theater

The trap is to make the smoke test big enough that nobody runs it. The source material gives you a way out: keep learning, keep it simple, focus on the basics. The smoke test should be short, repeatable, and tied to the actual next decision. It should not become a tour of every math channel, every histogram, every suspension plot, and every theoretical fastest calculation.

Use a tiered rule. Tier one must pass for the car to leave with the data plan intact: vital channels, six basic performance channels or the event's minimum equivalent, logger retrieval, analysis template, lap or distance structure, and required dashboard outputs. Tier two can be repaired or deferred if the session can still meet its goal: useful but nonessential extensions. Tier three is full analysis work after the car returns: detailed driver coaching, handling diagnosis, setup interpretation, and documentation for the next engineer.

This tiering also keeps you from duplicating adjacent lessons. Diagnose telemetry faults before the next session is the deeper troubleshooting lesson. Document the system so the next engineer can take over is the handoff lesson. Here, the job is to run the chain early enough that those later skills have evidence to work with. You are building the runway, not flying the whole mission in the paddock.

The decision standard

At the end of the smoke test, make one of three calls. Green means the minimum chain is proven and the planned analysis workflow can proceed. Yellow means the car can go, but the data plan is reduced; name the missing channel or feature and adjust the post-run question. Red means the missing link defeats the session objective or hides a vital car-health concern, so the issue must be fixed before release.

The call should be based on evidence, not optimism. A green call requires a real file or confirmed live path, visible required channels, readable vital data, usable timing or distance context, and confirmed dashboard functions if they are part of the driver's plan. A yellow call requires an explicit reduced scope. For example, if brake pressure is unavailable but the session objective can shift to speed, throttle, steering, and acceleration consistency, say that before the car leaves. A red call is appropriate when vital channels are strange, the system cannot retrieve data, lap structure is unavailable for a session that depends on lap comparison, or the driver-facing display is wrong for the intended coaching.

The reason for making the call explicit is that partial data creates false confidence. A team can easily talk as if it has telemetry because the logger is powered, while the actual workflow is broken. The smoke test turns that vague confidence into an operational decision. It either proves the chain, reduces the plan, or stops the departure long enough to fix the link that matters.

Worked example: engine warm-up as a live chain test

The car is in the pit area before the first session. The logger powers on, but you do not treat that as a pass. You start the engine warm-up and record a short file because the source material explicitly says engine warm-ups can provide relevant information. In this case, the warm-up is valuable because it exercises the chain without spending a lap.

You retrieve the file through the same path you will use after the session. You open the normal analysis template, not a special diagnostic screen. The first check is car health: engine and driveline temperatures, pressures, and battery voltage. If those channels are missing or strange, you stop the performance conversation. If they are present and understandable, you move to the basic performance channels. RPM and throttle should make sense for a warm-up. Speed may be absent or minimal if the car is stationary, but the channel should exist in the template. Steering, lateral acceleration, and longitudinal acceleration may show little action in a stationary warm-up, so the goal is presence and plausibility, not on-track shape.

Next, you confirm that any engine ECU signals expected to overlay with chassis data are visible in the same analysis context. If engine RPM comes from the ECU and lateral acceleration comes from the logger, the smoke test should prove that those worlds meet. If they do not, you have found an integration failure early.

Finally, you confirm the dashboard functions that matter before release. If the driver relies on shift lights, verify that the configured behavior is present. If the event plan uses sector or reference-lap display, confirm that the display is configured before the driver is asked to trust it. At the end of this example, the car has not yet made a meaningful lap, but the team has proven the transfer path, display template, health channels, basic channel list, ECU overlay, and driver-facing functions. That is a valid smoke test.

Worked example: setup change with expected evidence

The team has made a setup change before the session. The common mistake is to send the car out with a vague hope that the data will explain the change later. The better smoke-test move is to identify the channels expected to show the effect before the car leaves. The source material gives a direct example: aerodynamic changes most likely show up in speed and wheel load traces. That means the pre-out-lap smoke test for this situation must prove that speed is readable and that wheel load data, if instrumented for the car, is present in the analysis workflow.

You do not need to analyze the aerodynamic result before the car runs. You do need to make sure the evidence path exists. Confirm the channel list, open a fresh or warm-up file, and make sure the relevant traces appear in the template you will use after the session. If wheel load traces are not available, the data plan must change before the out-lap. You may still run the car, but you should not pretend the session will directly answer the original setup question.

When the car returns, the review sequence stays disciplined. Vital channels first. Then observe speed, acceleration, and driver activity before trying to explain why the car behaved as it did. If the driver reports that the car feels different, listen, but combine that report with the data. The smoke test has done its job because the traces needed for the setup question are available while the session is still fresh.

Worked example: reference-lap dashboard before the first timed run

A driver is using a dashboard with sector times, a reference-lap comparison, or predictive lap time. This is not just a display preference. The source material describes systems where virtual beacons compare the current lap to a reference lap and where predictive lap time is calculated from the difference between current time-distance data and a previously logged reference lap. If that function is wrong, the driver may receive misleading feedback while driving.

The smoke test for this case includes the dashboard as part of the chain. Before the out-lap, confirm that the reference lap loaded into the dashboard is the intended one for the session. Confirm that virtual beacons or sector definitions exist if the driver will use sector feedback. Confirm that the current data path can support the comparison. If the dashboard also carries shift lights, brake balance indication, or wheel lock or slip warnings, confirm the functions that are actually part of the session plan.

After the car returns, the analysis software should be able to show the same basic story: current lap structure, speed trace, and comparison context. If the dashboard said the driver was slower or faster than reference, the engineer should be able to inspect the underlying time-distance comparison rather than treating the dashboard as a mystery. The out-lap should never be the first time the team discovers that the display is aimed at the wrong reference.

Common mistakes

Mistake one: treating logger power as a system pass. A powered logger proves only that one component is alive. Good looks like a retrieved file opened in the actual analysis template, with required channels visible and usable.

Mistake two: chasing performance before checking vital channels. The source process begins with engine and driveline temperatures, pressures, and battery voltage. Good looks like a first review that clears car health before anyone debates braking, throttle, or steering technique.

Mistake three: testing every channel because the car has every channel. More sensors can create more questions as well as answers. Good looks like a minimum channel set tied to the session objective, with extensions added only when they support a real decision.

Mistake four: forgetting the lap source. Data without lap or distance context is slower to compare and easier to misread. Good looks like a confirmed beacon, virtual beacon, sector setup, or other timing basis before lap comparison becomes part of the plan.

Mistake five: using the fastest lap as the only validation target. The sources warn not to focus only on the fastest lap and recommend examining all laps for consistency and inconsistency. Good looks like a workflow that can inspect the whole run, including warm-ups, rollout laps, traffic-affected laps, and ordinary laps.

Mistake six: ignoring the driver because the data seems objective. Driver comments make it easier to know what to look for. Good looks like listening first, then using speed, acceleration, driver inputs, and health channels to separate what the car did from why it did it.

Mistake seven: blaming the driver from one trace. Driver activity and chassis balance are closely related. Good looks like combining driver comments with detailed data analysis and treating the data as a development tool, not as a way to damage confidence.

Mistake eight: leaving spares and connectors out of the smoke test. The pit area needs critical sensors, cables, connectors, and backup equipment within reach. Good looks like a physical recovery path ready before the failure appears.

Mistake nine: trusting a dashboard function that was not verified. Shift lights, sector displays, reference-lap comparison, and predictive lap time all depend on configuration. Good looks like confirming the specific driver-facing functions that will influence the run.

Mistake ten: ending the test without an objective. The Data for Drivers process ends by setting objectives for the next session. Good looks like a green, yellow, or red data-plan call and a specific first question for the post-run review.

Drill: three-departure whole-chain smoke test

At your next event, run this drill for three consecutive car departures. The count is three departures. The time box is ten minutes per departure before the car leaves, plus five minutes immediately after the car returns. The success criterion is that, for all three departures, you can produce a usable file or confirmed live path, open the actual analysis template, verify the required health and performance channels, confirm lap or distance context, and write one specific post-run objective.

Departure one is the baseline. Before the engine starts, write the minimum channel set for the session. Include vital channels, the six basic performance channels, and any event-specific extensions such as brake pressure, wheel speeds, suspension movement, tire temperatures, or dashboard reference functions. During warm-up, record a short file. Retrieve it and open the normal template. Mark each required channel as present, absent, or reduced. Make a green, yellow, or red call before release.

Departure two adds comparison discipline. Repeat the same steps, but this time add one comparison question before the car leaves. The comparison might be current data against a previous outing, a reference lap in the dashboard, or lap-to-lap consistency after the car returns. The point is not to solve the comparison before the run. The point is to prove that the data structure will support the comparison.

Departure three adds driver-loop discipline. Before release, ask the driver what they expect to feel or what they want checked after the run. Do not coach from the smoke-test file. Just capture the question. When the car returns, download the data, clear vital channels first, then use speed, acceleration, throttle, steering, brake pressure if installed, RPM, and gear if installed to orient the driver's comment. Finish by writing one objective for the next session.

The drill is passed only if the workflow gets faster and cleaner by the third departure. If you still discover missing channels after the car returns, the drill has found a real integration weakness. If the team can make a green, yellow, or red data-plan call before each departure, the habit is forming.

When this principle breaks down

The principle does not mean every possible failure can be caught before the out-lap. Some failures appear only under load, vibration, heat, braking, cornering, or speed. The sources do not support pretending that a pit-lane smoke test replaces on-track validation. The correct standard is more practical: catch the failures that can be caught before the car spends a session, and make the remaining uncertainty explicit.

The principle also does not mean the car always stays parked until every optional channel works. Data systems are extended step by step. If an optional channel is missing but the session objective can still be met with the vital channels, six basic signals, lap context, and required dashboard functions, the right call may be yellow rather than red. The key is that the reduced plan is named before the car leaves.

Finally, the principle does not replace deeper diagnosis or documentation. If the smoke test fails, the next lesson on diagnosing telemetry faults before the next session becomes relevant. If the system passes and the team changes configuration, the documentation lesson becomes relevant. This lesson's job is to prevent silent chain failures before the out-lap and to make the first post-run analysis possible.

Author Review

No quiz questions are attached to this lesson.

Sources

#	Document	Chunk	Pages	Score	Collection
1	Analysis Techniques for Racecar Data Acquisition	48d56105-c3c5-81ff-d649-243a1cd43c35	6	1	uio_books_raw_v1
2	Analysis Techniques for Racecar Data Acquisition	f6dc9cae-392f-1151-15c6-df8acd9a8ec5	5	1	uio_books_raw_v1
3	Briefing on High-Performance Driving and Event Operations	d91cd52a-c875-8a59-4539-4257a7b4d757	1	1	uio_books_raw_v1
4	Data for Drivers	cabda699642b26311b0a7ef998da2c71	15	1	uio_books_raw_v1
5	Analysis Techniques for Racecar Data Acquisition	3516d932-714f-e990-2877-853744eef9e5	18	1	uio_books_raw_v1
6	Analysis Techniques for Racecar Data Acquisition	cf21fbf2-060f-6c81-341f-fd8da871ffbf	18	1	uio_books_raw_v1
7	Analysis Techniques for Racecar Data Acquisition	b7da1ef7-f9f8-c734-bdb6-c1aa09e017fe	5	1	uio_books_raw_v1
8	Analysis Techniques for Racecar Data Acquisition (Jorge Sergers)	df95e4dec6eedb526da65ed0ceddb9b7	4	1	uio_books_raw_v1