Build an action-first telemetry dashboard
Generated from
content/lms/telemetry-systems-engineering/06-telemetry-transmission-real-time-and-storage/02-real-time-dashboards-and-alerting.md; edit the source file, not this page.
Source path: content/lms/telemetry-systems-engineering/06-telemetry-transmission-real-time-and-storage/02-real-time-dashboards-and-alerting.md
Course: Design and validate the telemetry system that feeds every decision
Module: Get data off the car and into the engineer's hands
Estimated duration: 55 minutes
A real-time dashboard is not a smaller analysis workbook. It is a decision surface. Its job is to take the mass of car and driver data that is arriving during a session and reduce it to the next useful action: keep running, change the driver task, protect the car, check the sensor, or save the evidence for the post-session debrief.
That sounds simple until you put it on a live pit screen or a cockpit display. Data acquisition has become accessible to almost everyone, and modern systems can record what the car and driver are doing with many sensors. The trap is that accessibility tempts you to show everything. The more channels you can log, the easier it is to build a dashboard that looks technical and fails the moment someone has to act on it. Van Valkenburgh describes one of data acquisition's core problems as the mass of data that resists fast analysis. That is the exact problem a real-time dashboard must solve.
The rule for this lesson is: show only the evidence that changes a decision now, and attach that evidence to the action it should produce. If the display cannot change a decision while the car is still on track, it belongs in the post-session analysis view or the storage system, not on the real-time dashboard.
The mechanism is attention. The driver is already part of the performance equation, not a passenger for the data system. The crew is already managing timing, traffic, weather, mechanical risk, and the driver's report. A dashboard that adds twenty unprioritized traces does not create understanding. It creates a new workload. Jenkinson's comparison of instrument layouts makes the old point in dashboard language: most drivers cannot read a complicated instrument pack accurately while racing, and an over-complicated layout can provide false information. A realistic cockpit layout used only oil pressure, tachometer, and water temperature. The lesson is not that your live telemetry screen should have only those three channels. The lesson is that the person using the display determines the display. The driver gets a few survival and task cues. The pit or engineering view can carry more context, but even that view must still answer a decision.
For an intermediate driver or club-racing team, the action-first dashboard has four layers. The first layer is the question: what decision are we trying to make while the session is live? The second layer is the evidence: which small channel group can answer that question without dragging in noise? The third layer is confidence: do we have enough baseline, repeatability, and sensor trust to act? The fourth layer is the action: what should the driver, crew, or analyst do next?
Do not start by asking which widgets look useful. Start by writing the action list. A driver-performance dashboard might need to say that the driver is using more steering while the car is not producing more cornering response, so the next action is a driver debrief on entry speed, release timing, or throttle timing. A mechanical dashboard might need to say that a vital sign is outside the known safe band, so the next action is to call the car in or reduce risk. A test dashboard might need to say that the current lap is not comparable to the baseline because traffic or driver inconsistency spoiled it, so the next action is to continue collecting rather than change the car. A data-quality dashboard might need to say that a sensor or transmission path has lost credibility, so the next action is to stop trusting that channel for live decisions.
That action list protects you from the common dashboard mistake: making the screen a museum of channels. The Rouelle seminar example described by Van Valkenburgh used one simple MoTeC screen with four channels in a 100 mph turn: lateral g, steering, speed, and throttle. The instructor notes pointed to an understeer diagnosis, front-tire overuse, and the driver's throttle timing. Four channels were enough to begin a real performance conversation because they spanned driver input, vehicle response, speed, and power demand. That is the model. The point is not that every dashboard must use only those four traces. The point is that the channel group was chosen because it could answer a specific question about what the driver and car were doing in the corner.
Build your dashboard the same way. For each live question, choose the smallest witness set. If you are watching whether the driver is creating an entry-understeer pattern, a useful witness set can be speed, steering, throttle, and lateral acceleration. If you are watching whether the car is safe to continue, the witness set changes to the few health signals your equipment and vehicle system can support reliably. If you are watching whether a setup test is valid, the witness set includes comparable lap conditions and the driver's repeatability more than it includes exotic channels. If you cannot name the witness set, you have not defined the decision.
The second sub-skill is baselining. A live alert without a baseline is just a loud opinion. Van Valkenburgh's testing rule applies directly here: consistency is primary, and one exceptional lap out of a scattered set does not prove anything. A dashboard that tells you to change the car because one trace moved once is doing the same bad testing that the book warns against. Before you trust a live condition, you need a well-known reference. That can be the same car and driver on a known good run, the same session before the issue appeared, a controlled test state, or an agreed safe operating standard from the equipment maker. The important part is that the dashboard compares against something known, not against a vague memory.
Baselining also keeps the dashboard from confusing driver improvement with car improvement. If a setup change appears to make the car faster, Van Valkenburgh warns that you need the ability to return to the original setting to know whether the change worked or whether the driver simply improved. The same principle applies to dashboard alerting. If the screen reports a better corner trace after the driver has warmed up, the alert should not immediately claim that the last mechanical adjustment worked. It should say that the lap improved against baseline and preserve the evidence for a controlled comparison.
The third sub-skill is diagnostic logic. Denton's diagnostic framing is useful even though it comes from vehicle service rather than race data: diagnosis depends on knowledge of the system and a logical process. Your dashboard should follow that same discipline. It should not jump from symptom to cure. It should move from observed condition, to likely area, to next check or action. If you do not understand the vehicle system well enough to diagnose the condition, the dashboard should not pretend that it does. It can still be useful by flagging that the evidence is unusual and needs inspection.
That humility matters because a data system can be wrong in several ways. A sensor can be miscalibrated. A connection can be poor. A transmission path can be noisy. A channel can be true but irrelevant to the decision in front of you. The bonded corpus points to sensor reading accuracy as a serious topic, not a decorative one, and it reminds you to follow the manufacturer instructions for the equipment you are using. In dashboard design, that means the alert should carry confidence. If a channel has not been checked against a known reference, it should not be allowed to trigger a high-consequence instruction by itself.
The fourth sub-skill is separating dashboard audiences. The driver display and the pit display are not the same product. The driver display should be closer to Jenkinson's realistic instrument layout: a few cues that can be read under load. In an HPDE car, that may mean no live coaching dashboard at all, only a shift light, warning light, or simple lap reference if permitted. In a race car, it may mean a small set of safety and task cues. The pit display can carry richer information, but it still needs priority. If the pit display forces the crew to study a page while the car is already past pit entry, it has failed as a real-time tool.
A useful pit dashboard has a short top row for state, not channels. The state row says whether the car is safe to continue, whether the current data is trustworthy, whether the current run is comparable to baseline, and whether there is a driver task worth communicating. Below that, each state can have the witness traces that support it. This reverses the usual bad layout. Instead of starting with traces and asking people to find meaning, it starts with the decision and lets the traces explain why.
The fifth sub-skill is keeping driver data and vehicle data together. Segers' data acquisition framing is explicit that the car does not drive itself and that logging driver activities helps improve performance. A dashboard that monitors only the car can miss the driver's role in the event. A dashboard that monitors only the driver can blame technique for a car or sensor problem. The best action-first view keeps at least one driver input and one vehicle response near each other whenever the decision is about performance. Steering without lateral response, throttle without speed gain, speed without driver input context, or lateral g without steering context can all mislead if shown alone.
For an intermediate team, you can think in four alert families. The first family is continue or stop. These are car-protection and safety alerts. They require the strongest confidence because the action is high consequence. The second family is change the task. These are driver-performance alerts that tell the crew or coach what to ask the driver to try next, or what to review after the session. The third family is preserve the test. These alerts tell you whether the current run is valid against the baseline or whether traffic, inconsistency, or an untrusted channel has made the data poor. The fourth family is investigate later. These alerts do not interrupt the session; they tag a moment for post-session analysis.
That fourth family is underrated. Not every real-time insight should become a real-time instruction. Van Valkenburgh's testing chapter is strict about careful procedures because development conclusions can be contaminated by inconsistency. Sometimes the correct live action is to mark the lap and keep running. This is especially true for an HPDE driver who is still building repeatability. A dashboard that interrupts every possible flaw can make the driver worse. A dashboard that tags the best evidence and turns it into one debrief question can make the driver better.
The sixth sub-skill is using simple automation without pretending it is intelligence. Van Valkenburgh mentions data functions such as recording auto-start when speed passes a condition, and then discusses data mining as a future answer to the mass of data. That gives you a conservative pattern for real-time alerting. A condition can trigger a state. A state can expose evidence. A person or a carefully limited rule can choose the next action. Do not let a simple threshold masquerade as an expert crew chief. If you write an alert that says the front tires are overused, the dashboard should show the channel relationship that supports that call and give a modest action, such as review entry speed and steering demand, not a sweeping setup prescription.
The seventh sub-skill is deciding what not to show. Heave, roll, suspension movement, damper position, and other advanced channels can be valuable in the right engineering context, and the corpus includes examples of sophisticated data logging, kinematics, compliance tests, and objective validation. But those channels earn their place only when the user can act on them. A club driver watching a live dashboard does not need rear roll in degrees unless the team has already connected that value to a decision. A crew chief may need it during a suspension test. A coach may not. A storage system may need to keep it for later. The real-time dashboard should not promote an advanced channel just because it looks like engineering.
Calibration is how you know the dashboard is getting better. The first cue is speed of decision. After a session, ask the person who used the dashboard what it told them to do. If the answer is a list of channels, the dashboard is not done. If the answer is one clear action and the evidence behind it, the screen is improving. The second cue is fewer false arguments. When the driver returns, the live tag, the driver report, and the trace should point to the same area often enough that the debrief begins quickly. They do not need to agree perfectly, but they should not feel like three separate stories.
The third cue is repeatability. If the dashboard flags a pattern on one lap and that pattern disappears when the driver repeats the corner cleanly, the dashboard should help you see that. If it flags the same issue across comparable laps, the issue becomes more credible. This is where consistency and baselining matter. A good dashboard makes repeatability visible. A poor dashboard makes every lap feel like a new emergency.
The fourth cue is restraint. As the dashboard improves, it should not necessarily become louder. It should become more selective. The practical data advice in the corpus is to keep learning, keep it simple, focus on the basics, and ask why. That is a strong dashboard calibration test. If you add a widget and it does not help answer why or choose the next action, remove it from the real-time view.
This lesson sits between the sibling lessons on transmission and storage. A radio link that survives at 200 mph is a prerequisite for live telemetry, but link design is not the skill here. Your dashboard should be honest when the link or sensor is not trustworthy, and then hand the transport problem to the radio-link lesson. A season-long storage system makes data findable later, but storage taxonomy is not the skill here. Your real-time dashboard should tag the moment and action clearly enough that the storage system has something meaningful to keep, then leave the archive design to the storage lesson.
The final habit is to treat the dashboard as a crew member with a narrow job. It is allowed to notice, compare, and suggest. It is not allowed to invent context, overwhelm the driver, or declare victory without a baseline. When it is built well, it shortens the gap between data and action. It does not replace the driver, the engineer, or the instructor. It gives each of them the next clean question.
Worked example: the four-channel 100 mph turn
In the Rouelle seminar example described by Van Valkenburgh, the analysis screen used lateral g, steering, speed, and throttle in a 100 mph turn. Instructor notes on that simple screen identified an understeer pattern, front-tire overuse, and the driver's throttle timing. That is a strong model for an action-first dashboard because the display did not need a giant channel stack to find a useful question.
For a live dashboard, turn that example into a state rather than a trace gallery. The state might be entry response suspect or front tire demand high. The witness channels sit underneath: speed, steering, lateral g, and throttle. The action is not automatically change the setup. The action is first to check whether the pattern repeats on comparable laps and whether the driver report matches it. If it repeats, the next debrief can focus on whether the driver is asking for too much front tire before adding throttle or whether the car's balance is limiting the driver's ability to get back to power.
The important design move is that the dashboard does not merely show steering and lateral g. It explains why those two channels are beside each other. Steering is the driver's request. Lateral g is part of the car's response. Speed sets the corner context. Throttle shows whether the driver is adding power into the condition or waiting for the car to finish turning. That small witness set is enough to choose the next question.
Worked example: Connaught versus BRM as a dashboard warning
Jenkinson's instrument-layout comparison is useful far beyond vintage cockpit design. The Connaught layout is described as over-complicated for most drivers to read accurately, while the B.R.M. layout is presented as a more realistic use of the driver with oil pressure, tachometer, and water temperature. Treat that as a warning label for every modern live dashboard.
If the driver is the audience, the screen must be sparse. A novice or intermediate HPDE driver should not be expected to parse a multi-channel coaching dashboard at speed. If the club-racing driver needs a live cue, it should be a small number of simple states: shift, warning, pit, or one approved task cue. Anything that requires interpretation belongs to the pit wall or to the debrief.
If the crew is the audience, the dashboard may be richer, but the same warning still applies. A pit screen with too many unlabeled traces can give false confidence. The crew may think they have seen the cause when they have only seen a symptom. The action-first version names the decision first, shows the supporting channels second, and keeps the raw detail one click lower unless it is needed now.
Worked example: Road Atlanta WSC and the danger of advanced channels without action
The data-mining chunk includes a Track Master Road Atlanta WSC file reference and advanced state values such as heave and rear roll. Those can be legitimate engineering signals in the right test. They are not automatically good real-time dashboard signals. If the person watching the dashboard cannot connect heave or rear roll to an action during this session, those values should not dominate the live view.
A better dashboard asks what decision the Road Atlanta run is supposed to support. If the test is a suspension-development run with a known baseline, heave and rear roll may belong in an engineering panel, alongside the car state and lap context that make them meaningful. If the session is an HPDE coaching run, those same channels probably belong in the stored data for later review while the live dashboard focuses on driver inputs, vehicle response, and car health. The channel is not good or bad by itself. It earns its real-time space only by changing a decision.
Common mistakes
The first mistake is the trace museum. The dashboard shows every channel because the logger can record every channel. It looks serious, but nobody can say what action it recommends. Good looks like a short state list with witness traces underneath each state.
The second mistake is the single-lap verdict. One lap looks faster or cleaner, so the dashboard claims a setup, driver, or condition change worked. Van Valkenburgh's testing discipline warns against exactly this kind of conclusion. Good looks like comparing against a known baseline and waiting for repeatable evidence before treating the alert as a conclusion.
The third mistake is blaming the driver without driver data. If the display shows only speed or lap time, it can miss the difference between a driver choice and a car response. Good looks like pairing at least one driver input with at least one vehicle response when the question is performance.
The fourth mistake is giving the driver an engineer's screen. The cockpit display asks the driver to interpret traces while driving. Good looks like a few readable cues for the driver and a richer, still prioritized view for the crew or post-session analyst.
The fifth mistake is trusting an unproven channel. A sensor, installation, connection, or transmission path can be the problem. Good looks like a dashboard that has a data-quality state and refuses to make high-consequence calls from unvalidated evidence.
The sixth mistake is action inflation. Every alert becomes urgent. The driver gets interrupted, the crew chases noise, and the debrief loses focus. Good looks like sorting alerts into continue or stop, change the task, preserve the test, and investigate later.
Drill: three-session action dashboard build
Run this drill at your next event with one car and one driver. The count is three sessions. The duration is one full event day or the first three clean sessions available. The success criterion is that by the end of the third session, every live alert on your dashboard can be explained in one sentence as condition, evidence, and next action.
Session 1 is baseline only. Do not coach from the dashboard unless there is a safety or car-protection concern. Record the small witness set you plan to use, such as speed, steering, throttle, and lateral g for a driver-performance question. After the session, choose one corner or one repeated situation and write the normal pattern for this driver today. Do not use the fastest isolated lap as the whole baseline if the rest of the run is scattered.
Session 2 is tag and compare. Let the dashboard tag moments that differ from the baseline, but limit yourself to three tags for the whole session. Each tag must have a reason. For example, the driver asked for more steering without a matching response, or the throttle came in while the car was still not accepting the request. After the session, compare the tags with the driver's report. If the driver did not feel the thing the dashboard tagged, that is not a failure. It is a calibration question.
Session 3 is one-action use. Before the session, choose one alert that is allowed to change the driver's task or the crew's instruction. Everything else is investigate later. During the session, use only that one action alert unless safety requires otherwise. After the session, check whether the action produced clearer evidence, a better driver report, or a more repeatable pattern. If it did, keep the alert and refine it. If it did not, rewrite the question or remove the alert from the real-time view.
When this principle breaks down
The action-first principle breaks down when the corpus-backed prerequisites are missing. If you do not know the vehicle system, a logical diagnostic process cannot carry you to a reliable conclusion. If the driver is inconsistent enough that every lap is a different experiment, the dashboard should mostly collect and tag rather than prescribe. If the sensor or equipment setup has not been checked against the manufacturer's instructions or a known reference, high-consequence alerting is premature.
It also breaks down when the action belongs to another system. If the issue is loss of live data, that is a transmission and link-confidence problem before it is a dashboard problem. If the issue is finding the same event months later, that is a storage and retrieval problem before it is a live-dashboard problem. The dashboard should expose those states honestly, then hand the work to the right layer instead of pretending a prettier screen will solve it.
Author Review
No quiz questions are attached to this lesson.
Sources
| # | Document | Chunk | Pages | Score | Collection |
|---|---|---|---|---|---|
| 1 | Race Car Engineering Mechanics Paul Van Valkenburgh | 8260513e-cde0-cc8a-046b-ba10e5cf93e9 | 155 | 1 | uio_books_raw_v1 |
| 2 | Race Car Engineering Mechanics Paul Van Valkenburgh | f721fe85-812c-0bdc-d9b3-212cd51c14f7 | 149 | 1 | uio_books_raw_v1 |
| 3 | Analysis Techniques for Racecar Data Acquisition | c6840a75-c015-d97b-7b98-bd7b84b4cbab | 18 | 1 | uio_books_raw_v1 |
| 4 | Analysis Techniques for Racecar Data Acquisition | d0db9128-dc9a-aec3-14a8-5f101654753f | 3 | 1 | uio_books_raw_v1 |
| 5 | Race Car Engineering Mechanics Paul Van Valkenburgh | 4a0085b1-a5b6-20ef-c288-ff092fa3e4d9 | 116 | 1 | uio_books_raw_v1 |
| 6 | The racing driver The theory and practice of fast driving Denis Jenkinson | 65cd76b7-11b8-e4a2-6535-390fc7f9ae14 | 62 | 1 | uio_books_raw_v1 |
| 7 | Advanced Automotive Fault Diagnosis. Automotive Technology. Vehicle Maintenance and Repair Tom Denton | 0672c860-bee6-a4dc-9b02-791715040ba6 | 21 | 1 | uio_books_raw_v1 |
| 8 | Advanced Automotive Fault Diagnosis. Automotive Technology. Vehicle Maintenance and Repair Tom Denton | a0387995-9c33-0128-e79b-01034218ed7c | 11 | 1 | uio_books_raw_v1 |
| 9 | Data-for-Drivers-PRINT | b80dc634-a0a7-d6de-d470-353aed47e2a6 | 17 | 1 | uio_books_raw_v1 |
| 10 | Racing Chassis and Suspension Design Carroll Smith | 641284b1-db2d-2ec6-42ff-218f9b509d67 | 128 | 1 | uio_books_raw_v1 |
| 11 | Racing Chassis and Suspension Design Carroll Smith | 52047a73-bbbf-e4e8-51ff-bb6cdbc0101b | 134 | 1 | uio_books_raw_v1 |
| 12 | Advanced Automotive Fault Diagnosis. Automotive Technology. Vehicle Maintenance and Repair Tom Denton | bdef2e8d-2f3e-d253-ab8f-2d0002361b54 | 328 | 1 | uio_books_raw_v1 |
| 13 | Analysis Techniques for Racecar Data Acquisition | 74ff9a5e-1293-62fd-0a20-d45fbbd732b7 | 4 | 1 | uio_books_raw_v1 |
| 14 | Race Car Engineering Mechanics Paul Van Valkenburgh | ea519039-ee4f-d64c-b79a-88981a8aa7c7 | 7 | 1 | uio_books_raw_v1 |