Build a channel budget that answers the question
Generated from
content/lms/telemetry-systems-engineering/01-sensor-selection-and-placement/03-channel-budget-and-system-architecture.md; edit the source file, not this page.
Source path: content/lms/telemetry-systems-engineering/01-sensor-selection-and-placement/03-channel-budget-and-system-architecture.md
Course: Design and validate the telemetry system that feeds every decision
Module: Choose the right sensor for every signal
Estimated duration: 55 minutes
Principle: the channel budget starts with the question, not the sensor catalog.
A good telemetry system is not the car with the most channels. It is the car whose logged channels can answer the question you brought back from the track. If the question is where the driver is losing time, the budget must capture enough evidence to compare laps on a time or distance basis and see where the speed trace changes. If the question is whether the car is unstable on entry or exit, the budget must capture driver inputs and vehicle response together. If the question is whether a setup change worked, the budget must include the channels that should show the effect of that change. The budget is the bridge between a driving or engineering question and a system architecture that can actually produce evidence.
That is why the first discipline is subtraction. You do not begin by listing every sensor you can afford. You begin by writing the answer you need after the next run. The answer might be: the driver brakes too early in Turn 1, the throttle trace shows confidence returning after mid-corner, the car loses speed after an aero change, the brake system cannot repeat pressure, or the damper data explains a balance complaint. Each answer implies a different set of direct channels, derived channels, display needs, memory needs, wiring needs, and spare parts. The channel budget is your written promise that the system can support that answer without drowning the team in unused traces.
The bonded sources are clear on the practical order. Start with a small set of basic signals, then extend the system step by step as you gain experience in the data. The core signals already create a large amount of analyzable information. More channels should enter the system because a specific need requires them, not because a long list looked impressive in the paddock. Analysis often creates new questions, so the budget also has to leave room for future expansion in the wiring harness, memory, and other hardware. That combination is the skill: ask narrowly, log enough, analyze systematically, and leave the architecture able to grow.
Scope: what this lesson owns.
This lesson is about deciding which channels belong in the system and how those channels move through the architecture. It does not replace the related lessons on turning a measurand into a sensor specification or mounting sensors so the data is trustworthy. Those lessons handle the detailed sensor spec and physical installation. Here you are deciding what must be measured, what can be calculated, what must be stored instead of merely displayed, what source system owns each signal, what the analysis workflow will do with the data, and what future expansion the hardware must tolerate.
Think of the channel budget as a living table with one row per required answer. For each row you write the driver or engineering question, the direct channels needed, the supporting channels needed for context, any math channels you intend to create, the hardware source of each signal, whether the channel must be logged or only displayed, and the trackside action the result will support. If a row cannot end with an action, it is not yet a budget row. It is curiosity.
The basic architecture every budget must respect.
Every data acquisition system in the bonded corpus has the same basic flow. A physical parameter of interest is captured by a sensor. The sensor turns that physical parameter into an electronic signal that the logger can understand. The logger stores measured parameters in electronic memory. A computer or laptop communicates with the logger through an external link so the team can download data and configure the system. Some systems add a dashboard so the driver can see readings. Some dashboards and loggers are one integrated unit. Engine ECUs can transfer engine-related signals to an external logger so those channels can be overlaid with lap timing.
That architecture matters because every channel budget has to answer two different questions. First, can the car sense this parameter. Second, will the parameter be stored in the place where analysis can use it. A dashboard input that is visible to the driver but not stored is not enough for post-session analysis. An engine value that lives inside the ECU is not automatically useful to chassis analysis unless it can be transferred to the logger and aligned with the lap beacon. A future suspension channel is not just a sensor purchase; it may require an input module, harness provision, memory capacity, and software setup. The budget must make those dependencies visible before the car is wired.
A clean budget therefore separates source, transport, storage, and analysis. Source means where the value originates: standalone sensor, ECU, dashboard input, expansion module, or calculated channel. Transport means how it gets to the logger: direct analog input, CAN network, interface cable, or another supported system link. Storage means whether the value is logged in memory or merely presented to the driver. Analysis means what graph, comparison, statistic, or math channel will use it. When one of those four boxes is blank, the budget is not finished.
The minimum useful budget: six core channels plus a lap reference.
For a track-day, HPDE, or club-racing car, the core logging kit starts with six signals: vehicle speed, engine RPM, throttle position, steering angle, lateral acceleration, and longitudinal acceleration. Add a beacon or other lap reference so the data has a beginning and end for each lap. That set is not primitive. It is enough to compare laps, see where time is gained or lost, study driver inputs, and understand broad vehicle response.
Vehicle speed is the primary performance trace because it tells where the lap changes. The stopwatch says a lap was quicker or slower. The speed trace shows where that happened. That is the trace you return to again and again when you ask whether a driver carried more speed into a corner, lost time on exit, hesitated before throttle, or suffered from traffic. If your budget does not include a reliable speed channel and lap reference, it cannot answer the most basic performance question.
Engine RPM and throttle position give the driver and powertrain context. They help show whether the driver is committed to acceleration, whether throttle pickup is smooth or hesitant, and whether shifts occur at consistent points. Steering angle shows the driver input that creates lateral response. Lateral acceleration shows the cornering demand. Longitudinal acceleration shows braking and acceleration demand. Together, these channels let you compare what the driver asked for against how the car responded.
Do not underestimate this core set. The sources point out that measuring the basic signals already gives the engineer a massive amount of data to analyze. For an intermediate driver, that is a warning and an opportunity. The warning is that more channels can slow you down if you cannot read the first six. The opportunity is that many driver-development questions can be answered without a large sensor expansion. A careful comparison of speed, throttle, steering, lateral acceleration, longitudinal acceleration, RPM, and lap position can expose inconsistent braking points, slow brake application, throttle hesitation, shift timing variation, entry oversteer signatures, and exit oversteer signatures.
How to decide whether a new channel earns a place.
A channel earns a place when it changes the answer you can produce. Brake pressure earns a place when longitudinal acceleration alone cannot tell whether braking performance changed because of driver input, tire grip, brake system behavior, or release timing. Suspension movement earns a place when speed and acceleration show a balance or ride problem but cannot explain what the chassis is doing. Infrared tire temperature earns a place when you need thermal evidence from the tire rather than only driver feel or acceleration traces. Wheel speeds earn a place when you need to compare individual wheels or diagnose locking, slip, or speed-source problems. Yaw speed earns a place when rotational behavior matters. Ride height, suspension loads, brake disc temperatures, aerodynamic pressures, propshaft torque, gear lever force, and tire pressure all belong only when they answer a specific question.
The bonded corpus names brake line pressure, suspension movement, and infrared tire temperature as the usual next logical step after the six basic channels. That ordering is practical. Brake pressure connects the driver's foot to the braking trace. Suspension movement connects chassis motion to balance and damping analysis. Tire temperature connects the tire's thermal state to handling and grip. Those channels turn a driver-performance logger into a more capable chassis-analysis system. But they also increase wiring, memory, hardware, setup time, spares, and analysis complexity. The budget must show why they are worth that cost.
The rule is simple: if you cannot write the question the channel answers, do not add the channel yet. If you can write the question, add the channel only after checking whether an existing channel or math channel can answer it well enough. The best low-budget teams extract maximum information from the hardware at hand. A team with fewer channels but a better question can outlearn a team with more sensors and no analysis plan.
Direct channels versus math channels.
Not every useful trace starts as a separate physical sensor. Analysis software can create mathematical channels from logged data so the calculated result can be plotted and analyzed like its own channel. The bonded corpus lists operations such as adding, subtracting, multiplying, dividing, trigonometric functions, differentiation, integration, averaging, and constants in math expressions. The briefing material also points to combined G plots, histograms, roll gradient, understeer angle, and shock absorber velocity as examples of calculated or advanced analysis views.
This changes how you budget. A math channel is not free, but it may avoid buying the wrong sensor. It depends on having the right source channels logged first. Shock absorber velocity is only possible if suspension movement is logged and the software can differentiate it. A combined G plot depends on lateral and longitudinal acceleration. A throttle histogram depends on throttle position. A driver-input comparison depends on throttle, steering, braking or longitudinal acceleration, RPM, and lap alignment. A budget should therefore include two types of channels: raw channels you must physically log and derived channels you intend to calculate.
The discipline is to write the math channel next to the question. If the question is whether the driver is spending more time at full throttle after a setup change, the raw channel is throttle position and the analysis view is a throttle histogram. If the question is whether the car uses the traction envelope more effectively, the raw channels include lateral and longitudinal acceleration and the analysis view is a combined G plot. If the question is whether damping behavior changed, the raw channel is suspension movement and the analysis may include shock velocity. The math channel is the answer format; the raw channel is the evidence source.
Building the budget in layers.
Layer one is safety and health. When the car comes in, analysis starts with vital channels such as engine and driveline temperatures, pressures, and battery voltage. That is not optional overhead. A car with a performance problem may first have a health problem. The driver may be standing beside you saying the car is not drivable, but the first scan still checks whether anything strange is happening in the vital data. Your budget should include the channels you need to protect the car and trust the run before you chase performance.
Layer two is what the car and driver did. This is where speed, acceleration, throttle, steering, RPM, and lap position live. You observe speed, acceleration, and driver activity before trying to understand deeper causes. This layer answers: where did the lap change, what did the driver ask from the car, and how repeatable was the behavior across laps. It also gives you the context for any later vehicle-dynamics channel. Without this layer, shock traces or strain gauges can become disconnected from the actual lap problem.
Layer three is why the car did it. This is where brake pressure, suspension movement, tire temperature, strain gauges, wheel speeds, yaw speed, ride height, wheel loads, aerodynamic pressures, and related channels enter. These channels are powerful because they can explain the mechanism behind a speed or acceleration trace. They are also easy to misuse if you skip layer two. First find the corner, lap segment, or driver input where the performance changed. Then use the deeper channels to explain it.
Layer four is future expansion. The source material warns that the number of signals may grow, and that growth affects the wiring harness, available memory, and other hardware. That means a good channel budget includes not only today's channels but the likely next questions. If the team is starting with the six basic signals, the harness and logger choice should not block the next logical additions of brake pressure, suspension movement, and infrared tire temperature. If the engine ECU already carries engine RPM, throttle position, lambda, and air box pressure, the architecture should support transferring those values to the external logger when engine performance analysis becomes important.
Layer five is trackside operation. A channel budget that cannot be run at the event is incomplete. The sources recommend downloading the logger every time the car comes in because warm-ups and rollout laps can still contain useful information. They also recommend having critical sensors, cables, connectors, and spare equipment within reach. Therefore the budget must name the operational burden: what gets downloaded, what gets checked first, what spares are needed, and what channel failures would prevent the session from answering its question.
The question-to-channel method.
Use this sequence whenever you build or revise a budget.
First, state the decision. Do not write a vague topic such as braking or handling. Write the decision you will make after reviewing the data. Examples: move the brake marker later, ask the driver to release pressure more smoothly, test the previous rear bar setting again, add a suspension travel channel before judging the damper change, or ignore a lap because traffic compromised the comparison.
Second, identify the primary evidence. For lap-time location, the primary evidence is the speed trace compared across laps. For driver consistency, it is the time or distance plot of speed, throttle, steering, RPM, and acceleration across several laps. For braking, it may be speed, longitudinal acceleration, and brake pressure. For chassis response, it may be steering, lateral acceleration, yaw speed, suspension movement, and tire temperature. For an aero change, the source material points you toward speed and wheel load traces as likely places where the effect appears.
Third, identify the alignment requirement. If you are comparing laps, you need a lap beacon or equivalent lap reference. If you are overlaying engine ECU data with chassis data, you need the systems to communicate so the engine channels can be transferred and overlaid with the lap timing. If you cannot align the evidence, the budget cannot answer the question cleanly.
Fourth, decide what must be logged rather than displayed. The source architecture includes displays, dashboards, loggers, and integrated dashboard-logger units. The distinction matters. A channel that only appears on a dash can help the driver in the moment, but it cannot be plotted afterward unless it is stored. Put storage status in the budget.
Fifth, decide what can be calculated. If the answer is a combined G plot, histogram, understeer angle, roll gradient, or shock velocity, list the required raw channels and the math channel. Make sure the raw channels are actually present in the logged data. Do not discover after the event that the calculated result required a channel you did not record.
Sixth, plan the first readout. Before the session, write the order you will use after downloading data. Health channels first. Then speed, acceleration, and driver activity. Then explanatory channels such as shock data, strain gauges, tire temperatures, brake pressure, or wheel loads. Then multi-lap comparisons, run charts, or statistics if you need a wider view. That order prevents you from being pulled into a detailed trace before you know whether the run was healthy and whether the pattern is real.
Seventh, convert the finding into one next-session objective. The briefing material is explicit that the goal is to set specific, actionable objectives for the next on-track session. If the budget produces an interesting graph but no objective, the budget was too vague. The next objective might be a driver action, setup decision, sensor addition, or validation run.
What good looks like.
A good channel budget feels almost boring at the laptop. You open the download, check the vital channels, and nothing strange is happening. You look at the speed traces from all laps, not only the fastest one, and the place where time is gained or lost is visible. You check traffic and obvious lap irregularities before making a conclusion. You compare driver activity and vehicle response. You use more than one channel to verify the hypothesis. You can say what to do next without inventing a story that the traces do not support.
The budget is also good when the channel list is shorter than your wish list. That means you made choices. A basic driver-development system might have only the six core channels, a lap beacon, and enough ECU values to make sense of RPM and throttle. A chassis development system might add brake pressure, suspension movement, wheel speeds, tire temperatures, and yaw speed. An aerodynamic development system might require speed and wheel load traces, and perhaps other pressure or ride-height related channels if the question justifies them. The difference is not ambition. The difference is the question.
Good also looks like maintainability. Critical sensors are reachable. Spare cables and connectors are available. The architecture leaves room for future input modules or ECU communication. The memory and hardware can tolerate the planned channel growth. The budget does not treat the logger as a sealed box; it treats the system as sensors, network, logger, memory, download link, analysis software, and trackside workflow.
What bad looks like.
A bad budget usually fails in one of four ways. It records a lot of channels but cannot answer a decision question. It records the right kind of parameter but in the wrong place, such as a display-only input that never reaches logger memory. It omits the alignment channel, so laps cannot be compared cleanly. Or it adds explanatory channels before the team can read the basic traces.
Another bad pattern is fastest-lap obsession. The sources warn not to focus only on the fastest lap. Analyze all laps and look for consistencies and inconsistencies. Traffic can heavily influence lap time. A channel budget built only around the fastest lap can misdiagnose a one-off event as a driver or setup trend. If you need to know whether a behavior is real, budget for comparison across laps and use statistics or run charts when a wider view helps.
A third bad pattern is single-channel diagnosis. A dip in G after apex with a sudden steering input may indicate entry oversteer. Hasty steering corrections after throttle application may indicate exit oversteer. Those are useful diagnostic signatures, but the process still asks you to verify a hypothesis with multiple channels. A steering trace alone is not the car. A G trace alone is not the driver. The budget should put the relevant channels together so the story is testable.
A fourth bad pattern is ignoring expansion. Most teams start simple and grow. If the initial hardware has no practical path to more inputs, no memory headroom, or no harness plan, the first budget becomes a trap. The point is not to buy everything now. The point is to avoid building a system that must be ripped apart the first time analysis produces the next logical question.
Using driver feedback without letting it dominate.
The sources tell you to listen to the driver because it makes it easier to know what to look for. That is the right relationship. Driver feedback points the analysis toward a question. It does not replace the traces. If the driver says the car is not drivable, you still begin with vital channels and check whether anything strange is happening. Then you observe what the car did through speed, acceleration, and driver activity. Only after that do you move deeper into why, using shock data, strain gauges, tire temperatures, brake pressure, yaw, or wheel speeds as the question requires.
This is especially important for intermediate drivers because feel can be accurate about the symptom and imprecise about the cause. The driver may feel nervous on entry. The data might show inconsistent brake release, a steering correction with a lateral G dip, or a genuine chassis response. The channel budget should preserve that distinction. It should include enough driver-input and vehicle-response channels to translate feedback into a testable hypothesis.
Budgeting for setup changes.
Before a setup change, write which channels are expected to move if the change works. The source material gives a direct example: aerodynamic changes are most likely to show up in speed and wheel load traces. The broader principle applies to every change. If you change something and cannot name the channels that should show the effect, you are not ready to evaluate the change with data.
For a driver coaching change, expect the driver channels and speed trace to move first: braking point, brake application, throttle timing, steering rate, RPM and shift timing, and speed through the relevant segment. For a braking system question, add brake pressure or brake temperature if those are the variables under suspicion. For suspension and damping work, add suspension movement and math channels such as shock velocity when the source channels support them. For tire behavior, add infrared tire temperatures or pressures when the question is thermal or pressure related. The budget is the contract between the change and the proof.
Budgeting for engine and chassis systems together.
Engine performance analysis has its own important signals: engine RPM, throttle position, lambda, and air box pressure. Chassis analysis often lives in the external data acquisition unit. The source architecture says the engine ECU should be able to communicate with the external unit so engine signals can be transferred and overlaid with lap-timing beacons. That is a system architecture decision, not just a channel decision.
When you budget engine and chassis channels together, keep ownership clear. Some values originate in the ECU. Some values originate in chassis sensors. Some are displayed to the driver. Some are logged. Some are calculated later. The laptop and analysis software only see what reaches memory and can be downloaded. A good budget names the route for each value so the engine and chassis stories can be aligned on the same lap.
The architecture example in the source material is useful because it separates measurement from storage. A display system has inputs for RPM, water and oil temperature, oil and fuel pressure, lap beacon, lateral G, and speed, but the display itself does not store those values. Through a CAN connection, the measured signals are transferred to a recording module. Additional input modules can be added to the network. An interface cable links the computer for data download and configuration. That is exactly the level of clarity your own budget should show.
How to read the budget after the session.
The session readout begins before the car enters pit lane. You already wrote the question and the channels expected to answer it. When the car arrives, download the logger. Include warm-ups and rollout laps in your data habit because they can contain relevant information. Start with the vital channels. Then view the basic performance channels. Then move to explanatory channels. That sequence keeps the analysis from becoming guesswork with graphs.
Once the data is open, do not ask which trace is interesting. Ask whether the budget answered the question. If the question was where time was gained or lost, the speed trace across laps should show the location. If the question was driver consistency, the overlays should show whether braking, throttle, steering, shifts, or acceleration traces repeat. If the question was balance, the steering, lateral acceleration, yaw or related response channels should agree with the symptom. If the question was damping, the suspension movement and derived channels should point to a pattern. If the question was a setup change, the channels named before the run should be inspected first.
If the evidence is inconclusive, do not stretch it. Record why. Maybe traffic contaminated the comparison. Maybe the lap beacon or alignment was missing. Maybe the channel was displayed but not logged. Maybe the sensor did not survive the run. Maybe the budget did not include the explanatory channel needed. Those are not failures if you capture them and revise the budget. They are failures only if you tell a confident story the system could not support.
The final output of the budget is not the graph. It is the next action. A driver might get one objective for the next session. A team might reverse a setup change, repeat it, add one channel, or repair a data path. A systems engineer might change the logger, harness, or module plan to preserve future expansion. Every action should be traceable back to the original question and the channels that answered it.
A compact template you can use.
Write the budget in this order. Question. Decision after the run. Direct logged channels. ECU or external source channels. Math channels or plots. Lap alignment requirement. Health channels to inspect first. Architecture path from source to logger memory. Expansion needs. Spares and trackside operation. Next-session objective.
For example, a driver consistency question might require speed, throttle, steering, RPM, lateral acceleration, longitudinal acceleration, and lap beacon. The plots might be time or distance overlays plus a throttle histogram. The decision might be whether the driver should focus on brake point repeatability, throttle timing, or shift timing. The architecture may be a basic logger with ECU throttle and RPM transfer. The first readout checks battery voltage and engine temperatures, then speed, then driver inputs, then lap-to-lap consistency. The next objective is one driver change, not a pile of tips.
A chassis balance question might start with the same core channels but add brake pressure, suspension movement, infrared tire temperatures, wheel speeds, and yaw speed if the specific symptom demands them. The decision might be whether the problem is driver release timing, entry oversteer, exit oversteer, or a setup effect. The math channels might include shock velocity or a combined G plot. The architecture must support additional inputs and memory, not just the basic logger.
An aero evaluation question might begin with speed and wheel load traces because the source material identifies those as likely places for aerodynamic effects to appear. The decision might be whether a change improved performance in the segments where aero load matters. The budget must include comparison laps and control for traffic before concluding that the setup change worked or failed.
Final rule.
A channel budget is successful when it protects the car, captures what the driver and car did, supports the why channels needed for the specific question, and produces one action for the next run. It should not be a museum of every possible trace. It should be a working system for replacing guesswork with quantifiable evidence, using the smallest architecture that can answer today's question while leaving a sensible path for tomorrow's one.
Worked example: the six-channel HPDE driver budget
Question: where is the driver losing time, and is the loss coming from inconsistent inputs or vehicle response. This is the right first budget for a driver who is ready to stop relying on memory and start comparing laps objectively.
Budget the core channels first: vehicle speed, engine RPM, throttle position, steering angle, lateral acceleration, longitudinal acceleration, and a lap beacon or equivalent lap reference. Add the health channels your car already makes available, such as temperatures, pressures, and battery voltage, because those are checked before performance analysis. If the ECU can provide RPM and throttle to the logger, record that architecture path explicitly so the values are stored with the lap data rather than only shown somewhere else.
The analysis plan is simple. After each run, download the logger. Check vitals first. Then compare speed traces over all useful laps, not just the quickest lap. Use traffic awareness before calling a lap representative. Once the speed trace shows where time appears, use throttle, steering, RPM, lateral acceleration, and longitudinal acceleration to see what the driver did there. A slow exit with delayed throttle looks different from a slow entry with early braking. A steering correction with a dip in lateral G after apex points you toward an entry-balance question. Hasty corrections after throttle point you toward an exit-balance question.
The budget has answered the question when you can write one next-session objective. The driver may need to brake at a more repeatable point, get to throttle sooner, clean up steering release, or shift at a more consistent location. If you cannot choose one objective from the traces, the issue may not be channel count. It may be that the original question was too broad or the laps were not comparable.
Worked example: expanding after a not-drivable complaint
Question: the driver reports that the car is not drivable after a setup change. The wrong response is to jump straight into exotic channels. The right response is to preserve the analysis order: health first, what happened second, why third.
Start with vital channels such as temperatures, pressures, and battery voltage. If something strange is happening there, fix the car before debating balance. Then inspect what the car did: speed, acceleration, and driver activity. Compare multiple laps and look for consistency. If the symptom appears repeatedly in the same segment, move to the channels that can explain the mechanism.
The likely first expansion is brake pressure, suspension movement, and infrared tire temperature. Brake pressure helps separate driver input from braking response. Suspension movement helps explain chassis motion and damping behavior. Tire temperature helps show whether thermal behavior is part of the complaint. Depending on the exact question, wheel speeds, yaw speed, ride height, suspension loads, tire pressures, or brake disc temperatures may earn a place. They do not all enter automatically. Each one must connect to a specific hypothesis.
If the complaint followed an aerodynamic change, write before analysis that speed and wheel load traces are expected to show the effect. If those traces do not move in the expected region, the change may not have produced the intended result, the run may not be comparable, or the budget may be missing the channel required to prove it. The lesson is that the expansion is driven by the complaint and the expected evidence, not by the longest possible sensor list.
Worked example: engine ECU plus chassis logger architecture
Question: how do you budget a system where engine data and chassis data come from different places. The source architecture gives a useful pattern. The engine ECU may already know engine RPM, throttle position, lambda, and air box pressure. The chassis logger may own speed, acceleration, steering, lap beacon, suspension, brake pressure, and tire-related channels. For analysis, those values need to land in the same logged data set and align with the lap reference.
In the budget, do not simply list RPM and throttle. Write that they originate in the ECU, must be transferred to the external data acquisition unit, and must be overlaid with the lap beacon. Write which values are displayed and which are stored. If a dashboard measures values but does not store them, the route to the recording module matters. A CAN-based architecture with additional input modules can grow cleanly, but only if you reserve the physical and logical path for the future channels.
The success criterion is practical. After the session, the laptop should be able to show engine and chassis behavior together on the same lap. You should be able to compare speed, throttle, RPM, acceleration, and lap position without hand-matching separate files or guessing timing. If the engine data is visible during the run but absent from the download, the channel budget failed at the storage layer, not the sensor layer.
Common mistakes
Mistake 1: building a shopping list instead of a question list. A long channel list can still fail if no one knows what decision the data should support. Good looks like one written question, the minimum direct channels needed, the math channels expected, and one next-session action.
Mistake 2: forgetting the lap reference. Without a beacon or equivalent lap alignment, comparing laps becomes much less useful. Good looks like every performance budget including a clear way to identify lap beginnings and endings.
Mistake 3: logging display assumptions. A value shown to the driver is not automatically stored for analysis. Good looks like every channel having a named source, transport path, and storage location.
Mistake 4: analyzing why before what. Shock data, strain gauges, tire temperatures, and wheel loads are explanatory channels. They should be read after you know where the speed, acceleration, and driver traces changed. Good looks like health check, basic behavior, then mechanism.
Mistake 5: fastest-lap tunnel vision. The quickest lap may not represent the pattern, especially when traffic affects lap time. Good looks like reviewing all useful laps, looking for consistencies and inconsistencies, and using wider views such as statistics or run charts when needed.
Mistake 6: single-channel storytelling. A steering correction, G dip, throttle trace, or speed loss can suggest a hypothesis, but the process asks you to verify with multiple channels. Good looks like driver input, vehicle response, and lap context agreeing before you call the cause.
Mistake 7: no expansion path. Many teams start with the basic six and grow. If the initial architecture blocks brake pressure, suspension movement, tire temperature, ECU transfer, or additional modules, the budget has created future rework. Good looks like reserving harness, memory, and hardware capacity for the next likely questions.
Mistake 8: no trackside operating plan. If you cannot download consistently, check vitals first, and keep critical spares available, the best channel list can fail in the paddock. Good looks like a repeatable post-run routine and backup sensors, cables, and connectors for the channels that matter.
Drill: three-session question-to-channel budget
Purpose: practice building a budget that produces one actionable objective per session.
Count and duration: do this over three on-track sessions at your next event. Spend 15 minutes before Session 1 writing the budget. Spend 20 minutes after each session downloading and reviewing the data. The total drill takes about 75 minutes of paddock work across the day.
Session 1: write one question before the car goes out. Use the core channels: speed, RPM, throttle, steering, lateral acceleration, longitudinal acceleration, and lap reference. Add only the health channels already available. After the run, download the logger, check vitals, then compare speed traces across all useful laps. Success criterion: identify one track segment where the speed trace shows a repeatable gain or loss.
Session 2: use the same channel set and one driver objective from Session 1. After the run, compare speed, throttle, steering, RPM, and acceleration in the chosen segment. Success criterion: decide whether the change came from driver input consistency, throttle timing, braking behavior shown through longitudinal acceleration, or something the current budget cannot explain.
Session 3: revise the channel budget based on the gap. If braking is unresolved, propose brake pressure. If chassis motion is unresolved, propose suspension movement. If tire behavior is unresolved, propose infrared tire temperature or pressure data. If the current channels answered the question, do not add a sensor. Success criterion: finish the day with either one confirmed driver objective or one justified channel addition tied to a written question.
The pass condition is not a faster lap. The pass condition is a budget that turns the data into a specific next step without guessing.
Cross-references and boundaries
Use the related measurand-to-sensor lessons after this budget is written. The budget tells you that brake pressure, suspension movement, tire temperature, speed, steering, or acceleration must be known. The sensor-spec lesson should then decide the required range, accuracy, response behavior, and interface for that measurand. Use the mounting lesson after the sensor is chosen, because a correct channel can still produce untrustworthy data if the physical installation is poor.
This lesson also touches driver analysis, vehicle diagnostics, and math channels, but it does not try to replace those deeper skills. Here you only need enough of each to budget correctly. If the question depends on a combined G plot, throttle histogram, understeer angle, roll gradient, or shock velocity, list the raw channels and derived channel in the budget. The detailed interpretation belongs in the later analysis work.
The boundary is useful because it prevents scope creep. Channel budgeting is the moment where you choose the evidence. Sensor specification chooses the instrument. Mounting makes the instrument trustworthy. Analysis converts the recorded evidence into the next action.
Author Review
No quiz questions are attached to this lesson.
Sources
| # | Document | Chunk | Pages | Score | Collection |
|---|---|---|---|---|---|
| 1 | Analysis Techniques for Racecar Data Acquisition | f6dc9cae-392f-1151-15c6-df8acd9a8ec5 | 5 | 1 | uio_books_raw_v1 |
| 2 | Analysis Techniques for Racecar Data Acquisition | 99fdf750-f23e-0611-c169-ea0a4763a55c | 5 | 1 | uio_books_raw_v1 |
| 3 | Analysis Techniques for Racecar Data Acquisition | 48d56105-c3c5-81ff-d649-243a1cd43c35 | 6 | 1 | uio_books_raw_v1 |
| 4 | Briefing on High-Performance Driving and Event Operations | d91cd52a-c875-8a59-4539-4257a7b4d757 | 1 | 1 | uio_books_raw_v1 |
| 5 | Analysis Techniques for Racecar Data Acquisition | fe480844-bae5-7848-3b0e-8ffbd328ce32 | 6 | 1 | uio_books_raw_v1 |
| 6 | Analysis Techniques for Racecar Data Acquisition | 5eeea298-6191-0fb2-1054-b10fe574a804 | 2 | 1 | uio_books_raw_v1 |
| 7 | Analysis Techniques for Racecar Data Acquisition | d0db9128-dc9a-aec3-14a8-5f101654753f | 3 | 1 | uio_books_raw_v1 |
| 8 | Analysis Techniques for Racecar Data Acquisition | b7da1ef7-f9f8-c734-bdb6-c1aa09e017fe | 5 | 1 | uio_books_raw_v1 |