Archive sessions so future you can find the answer
Generated from
content/lms/telemetry-systems-engineering/06-telemetry-transmission-real-time-and-storage/03-archival-storage-and-data-management.md; edit the source file, not this page.
Source path: content/lms/telemetry-systems-engineering/06-telemetry-transmission-real-time-and-storage/03-archival-storage-and-data-management.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 telemetry archive is not a junk drawer for old files. It is a system for answering questions after your memory has gone soft. Six months from now, you will not remember which session had the hesitant throttle trace, which run used the different rear bar, which lap was clean enough to compare, or whether the car was genuinely better or you simply drove the corner differently. If the archive does not preserve that context, the data may still exist, but it will not be useful.
The principle is simple: store every session so it can be compared later. That means the raw log is only one part of the record. The useful record also includes what you were trying to do before the session, what track and conditions you had, what changed on the car, what the session produced, what channels were trustworthy enough to analyze, what the first comparison showed, and what objective should carry into the next outing. Ross Bentley frames the driver side of this plainly: keep a log book for every race, practice, test, or qualifying session, write objectives before going out, and after the session record track conditions, changes made or needed, and the results. In telemetry terms, that log book becomes the index for the data file.
This lesson sits after the real-time lessons in the module. A radio link that survives at speed gets data out of the car. A dashboard that tells you what to do next turns selected information into live action. Archival storage has a different job. It turns the season into memory you can search, compare, and learn from. The archive is successful when November-you can answer a May question without guessing.
The mechanism: data only becomes findable when it is attached to meaning
Race data systems can record what the vehicle and driver are doing, and modern systems have made that kind of logging accessible to ordinary drivers, not just professional teams. Segers points out that the same analysis techniques apply whether the vehicle is a development car, a stock car, or a road-legal car at a local strip, because the underlying driver and vehicle dynamics remain the same. That is the good news. The hard part is not merely having data. The hard part is extracting the right conclusions quickly from large data sets.
The bonded data-analysis chunks keep returning to the same discipline: start with an overview, look for incongruencies, dig for details, use other channels to check, ask why, compare if you can, calibrate the data to your driving, imagine what ideal would look like, and set objectives for the next session. That sequence is not just an analysis process. It is also an archive design rule. If you want to retrieve a useful session later, you must preserve enough information to re-run that process.
A raw data file by itself answers a weak question: what did the logger capture. A findable session record answers stronger questions: what was I trying to improve, what did the car feel like, what changed mechanically, which channel supports or contradicts the driver comment, what lap or segment is the useful comparison, and what should I test next. That is why a driver log and a telemetry archive should not live as separate worlds. The log gives the data meaning. The data checks the log.
Do not confuse storage volume with learning value. Van Valkenburgh describes one of the great data acquisition problems as the mass of data that defies fast analysis. Segers makes the same point from the analysis side: techniques are needed to draw the right conclusions quickly from very large data sets, and run charts or metrics can make important portions detectable. Your archive should reduce the future search problem, not increase it. You are building a map through the data, not a bigger pile of data.
The minimum useful session record
For an intermediate driver or engineer, a good session archive has seven parts. You can implement them in a notebook, a spreadsheet, a Tracky session record, or a race-team data workflow. The software is secondary. The structure is the skill.
First, preserve the session identity. Record the event, track, configuration if applicable, car, driver, session type, and date. The corpus supports using logged data to learn about the racetrack and to compare tracks by extracted parameters, so the track identity matters beyond filing convenience. If you later want to know how one circuit rewarded a setup or driving technique compared with another, you need the track context attached to the session.
Second, preserve the pre-session objective. Bentley describes writing down objectives before each session and the driving techniques or plans needed to achieve them. This is one of the most important archival fields because it tells future you what the data is supposed to be evidence for. A session aimed at improving brake release should not be filed only as a lap-time attempt. A session aimed at testing whether you can carry throttle through a fast corner should not be judged only by fastest lap. Without the objective, you will overvalue whatever looks obvious later.
Third, preserve track and condition comments. Bentley specifically includes comments on track and conditions after each session. This does not mean you need a weather station report for every HPDE run if the corpus did not give one. It means you need the conditions that changed the interpretation. Was the track green, hot, damp, crowded, or unusually clear. Was traffic heavy enough that the best lap is not the best teaching lap. Did the car behave differently after tires came in. Those notes explain why two logs that look similar may not be comparable.
Fourth, preserve setup changes made and changes still needed. Bentley puts setup changes in the same post-session record as track conditions and results. Segers explains that comparing data from different laps or runs with previously collected data can reveal the effect of setup changes or driver performance. If the car changes and the archive does not say so, a future comparison can lie by omission. You may think you found a driving breakthrough when you actually changed the car. You may think a setup worked when the driver simply got cleaner.
Fifth, preserve the channel inventory and limitation note. The Data for Drivers assumptions are modest and practical: a useful system starts beyond a lap timer with speed and longitudinal or lateral g at minimum, ideally throttle and brake pressure, then steering angle and engine RPM. The same source warns you to know the limitations of your data tool and to remember that data is objective but incomplete. In your archive, record which channels were present and which were trustworthy enough to use. A session with speed, throttle, brake, steering, and RPM is not the same evidence package as a session with only GPS speed and lap time.
Sixth, preserve a compact metric summary. Do not try to turn every channel into a season-long chart. The bonded chunks list many useful reports: segment or section times, fastest rolling, theoretical fastest, g-sum, GPS line, total steer angle, throttle histogram, brake pressure trace, throttle trace, RPM, gear, and consistency lap-to-lap. The right archive saves the few metrics that explain the question. If the issue was throttle hesitation, store the throttle trace observation and the relevant segment. If the issue was brake shape, record whether the application was inconsistent, light and long, hard and short, or had a long trail. If the issue was lap-to-lap consistency, store the consistency signature rather than every possible trace.
Seventh, preserve the first conclusion and next objective. The Data for Drivers process ends by imagining ideal and setting objectives for the next session. Bentley also connects records to learning when returning to the same track or facing a recurring driving problem. A session archive is incomplete if it only says what happened. It should also say what the next run is supposed to prove.
The closeout technique: twelve minutes before the memory fades
Your archive improves fastest when you close out the session while the sensations are still fresh. The technique is not a deep analysis session. It is a disciplined first pass that makes later analysis possible.
Step one: write the driver-side record before you stare at squiggly lines. Record the objective, the driver feel, the track and condition notes, setup changes, and the result. This protects the subjective side before the traces start changing your memory. Segers supports pairing objective logged data with subjective driver comments because the combination helps evaluate what is going on with the car and locate handling problems on the racetrack.
Step two: open the overview. Use the channels available to you, but start simple. Speed, longitudinal g, lateral g, throttle, brake, steering, RPM, gear, GPS line, section times, and lap-to-lap consistency are enough to start. The Data for Drivers process begins with overview before details. This matters because archival labels created from first impressions often become permanent. If you label a session as brake problem before noticing that the throttle trace explains the lap loss, future you will retrieve the wrong lesson.
Step three: look for one incongruency. The bonded process says to look for incongruencies, dig for details, and use other channels if available to check. An incongruency is where two pieces of evidence do not fit. The driver says the car would not rotate, but the throttle came in early enough to force a lift. The lap felt fast, but the first half of the corner shows the car slowing too much. The brake trace looks tidy, but the speed trace says the car was coasting. That conflict is often the most valuable archive tag because it tells you what to review later.
Step four: compare only after you know what you are comparing. Comparative analysis is powerful because different laps or runs can reveal setup changes or driver performance. But comparison without context creates false certainty. Compare the session to a cleaner lap, a previous event, another driver if you have permission and compatible data, or a theoretical fastest report only after the record says what changed and what stayed constant. Your archive should make that comparison easy by pointing to the usable reference, not merely by storing every session in date order.
Step five: convert one trace observation into one useful tag. For example, do not tag a session only as bad throttle. A useful tag says hesitant throttle after apex, early throttle then lift, lift in fast corner, long brake tail, inconsistent brake pressure, or coasting before application. Those phrases come from the available analysis categories in the bonded data chunks. They are findable because they describe a behavior, not a mood.
Step six: write the next objective. If the review shows a hesitation in throttle application, the next objective might be to commit to one progressive throttle build in the same corner. If the review shows that the first half of the corner is where the speed difference appears, the next objective might be to keep entry speed honest while improving the release and rotation. The objective is not a motivational note. It is the retrieval key for the next session.
Sub-skill 1: Build around questions, not file names
A file name can tell you date, track, and session. It cannot tell you why the session matters. The archive has to answer questions a driver or engineer will actually ask later. What did I try that day. Which session had the clean comparison. Which run followed the setup change. Which lap showed the throttle problem. Which event at this track had similar conditions. Which corner produced the same handling complaint. Which next objective did I set and never test.
The bonded corpus supports this because the analysis process is question-driven. It asks why. It compares. It calibrates the data to the driving. It sets objectives. If your archive cannot answer those questions, it is not an analysis archive. It is a storage container.
Sub-skill 2: Keep subjective and objective evidence together
Logged data is objective measurement. Driver comments are subjective evidence. Neither is enough alone. Segers says logged data can be used with subjective driver comments to evaluate what is going on with the car, identify handling problems, and locate where they occur. Bentley says to record the track, conditions, changes, and results. Data for Drivers warns that data has limitations and does not tell everything.
In practice, that means a useful archived session should pair felt language with trace language. Felt language might say the car washed wide in a fast turn, throttle commitment felt late, or the brake release felt too long. Trace language might say steering demand stayed high, throttle came in hesitantly, the speed trace flattened before turn-in, the brake pressure had a long tail, or lateral g and steering disagree with the driver feel. The archive should keep both, because the learning is often in the agreement or disagreement between them.
Sub-skill 3: Record channel trust, not just channel existence
A channel list is not enough. You need to know whether a channel was present, clean enough, and relevant enough for the conclusion. The corpus does not give you sensor-calibration procedures for this lesson, so do not invent them here. The supported skill is more basic: know the limitations of your data tool and use other channels if available to check. If brake pressure is missing, do not archive a braking conclusion as if you had pressure data. If steering angle is unavailable, be careful about diagnosing total steer angle. If GPS line is noisy, do not make a precise line-choice claim from it.
A simple archive note can carry this discipline: speed and lateral g usable, throttle present, brake pressure missing, steering absent. That one note prevents future-you from overclaiming. It also helps you choose what sessions are comparable. A throttle-histogram comparison needs throttle. A brake-shape comparison needs brake pressure. A steering-angle lesson needs steering angle.
Sub-skill 4: Promote traces into metrics only when the metric has a job
Segers emphasizes metrics and run charts because they make important portions of large data sets detectable and support reliable statistics. That does not mean every archived session needs every metric. The archive should promote a trace into a metric when repeated comparison will help.
If your question is lap-time trend, segment times and fastest rolling may be useful. If your question is whether you are leaving time in one section, a section report may be useful. If your question is throttle commitment, a throttle histogram or targeted throttle trace note may be useful. If your question is whether the car is asking for too much steering, total steer angle can be useful when the channel is available. If your question is line or track reference, GPS line may be useful when it is trustworthy. The discipline is to save the metric because it answers a known question, not because the software can display it.
Sub-skill 5: Preserve comparison targets
Comparative analysis is the core of season-later retrieval. The question is rarely what happened in isolation. It is what changed compared with another lap, another run, another driver, another setup, or another event at the same track. Segers explicitly describes comparing laps or runs with previously collected data to reveal setup effects or driver performance. Going Faster describes a same-section comparison where the speed difference comes from one driver slowing too much in the first half of the corner. That is the kind of comparison your archive should make findable.
When you close a session, mark the best comparison target while you still remember why it matters. The target might be the fastest clean lap, the best lap before traffic, the previous session before the setup change, the lap with the same mistake but less time loss, or the earlier event at the same circuit. The archive does not need to solve the whole analysis in the paddock. It needs to point to the right pair of records.
Sub-skill 6: Archive the racetrack as part of the lesson
Track data matters because logged data can be used to learn about the racetrack and to extract parameters that compare different tracks. In a driver archive, this means the track is more than a label. It is part of the pattern. Some tracks expose braking discipline. Some expose throttle patience. Some expose high-speed steering confidence. Some expose setup sensitivity. The bonded corpus does not support a detailed taxonomy of named circuits for this lesson, so keep this practical: when a session teaches you something about a track section, record the track section and the driving or vehicle behavior together.
That way, when you return to the same place, the record does what Bentley wants a driver record to do: help you learn by looking back when you return to the same track or have a recurring problem. A November archive is useful in April if it can tell you not just that you were slow, but where the track made you slow and what you planned to do about it.
Calibration cues: how you know the archive is working
The first cue is retrieval speed. At the end of the season, you can find the session that matters by problem, not just by date. You can search for a throttle hesitation, a long brake tail, a first-half corner speed loss, an understeer complaint, a setup change, or a next-session objective and land on the right record.
The second cue is comparison quality. When you open two sessions side by side, the archive already tells you whether they are comparable. It states the objective, conditions, setup state, channel availability, and reference lap. You are not discovering basic context after loading the traces.
The third cue is fewer false conclusions. You stop blaming setup when the archive shows the driver changed approach. You stop celebrating a lap-time gain when the record shows traffic cleared. You stop diagnosing a missing channel. You stop treating a single fast lap as the whole truth when segment reports and consistency show a different story.
The fourth cue is cleaner next-session planning. The archive naturally produces objectives because every record ends with a next question. Data for Drivers closes the loop by setting objectives for the next session, and Bentley starts the next run by writing objectives before going out. When those two habits connect, your archive becomes a learning loop.
The fifth cue is better restraint. You can leave many traces alone because the archive tells you what question matters. This is how you respect the warning that large data sets can defy fast analysis. You are not trying to analyze everything. You are trying to preserve the path back to the useful thing.
Cross-references inside this module
Use the radio-link lesson for the problem of getting data transmitted reliably at speed. Use the action-first dashboard lessons for deciding what belongs in front of the driver or crew during the session. This lesson begins when the run is over. Its job is to make the session teach again after the season, after the memory fades, and after the raw files have become too numerous to browse manually.
Worked example: the 100-mph four-channel corner
Van Valkenburgh includes a typical MoTeC analysis screen from Claude Rouelle using only four channels in a 100-mph turn: lateral g, steering, speed, and throttle. The screen is useful because it shows the archival lesson in miniature. You do not need every channel in the car to make a useful record. You need the right channels, a clear corner situation, and annotations that connect the trace to the handling question.
Suppose this was your session. If you archive only the raw file, future you has to remember that this was the high-speed understeer run. If you archive only the lap time, the lesson is nearly invisible. A better record says the objective was to confirm whether the car was using the front tires too hard in the 100-mph turn. The channel inventory says speed, throttle, steering, and lateral g were usable. The driver comment says the car needed more steering than expected and would not hold the intended arc. The trace note says steering demand remained high while throttle was being applied, and speed/lateral g show the corner load. The comparison target is the previous session before the change or the next session after the driver tries a different approach. The next objective is to test whether an earlier release, different throttle timing, or setup change changes the same four-channel signature.
That record is findable months later because it is indexed by situation and question. You can search for high-speed turn, understeer, front tire use, steering demand, throttle application, or four-channel comparison. You can also avoid overclaiming because the record admits what it has: four channels, not a full vehicle-dynamics lab. That is exactly the balance this lesson is teaching. Keep it simple, but keep the meaning attached.
Worked example: the same-section speed loss
The Going Faster chunk describes a data-acquisition example comparing two drivers on the same section of a race track, where the difference comes from one driver slowing too much in the first half of the corner. This is a perfect archival-storage example because the useful thing is not just the fastest lap. The useful thing is the location and shape of the loss.
If you file the session as personal best, you may never retrieve the comparison. If you file it as corner entry problem, you still may miss the point. The stronger record says the comparison was same section, two drivers or two laps, with the time difference caused by speed lost in the first half of the corner. The objective for the next session is not merely go faster. It is to understand why the car or driver gave away speed early in the section without compromising the rest of the corner.
The archive should attach the section report or speed trace to that note. If available, it should also preserve throttle and brake evidence: was there coasting, hesitant throttle, early throttle followed by a lift, a long brake tail, or inconsistent pressure. If those channels are not available, the record should say so. Later, when you return to that track or teach that section to yourself, the archive retrieves the exact comparison that mattered: the first half of the corner is where the time went missing.
This example also shows why theoretical fastest and fastest rolling reports need context. They can point to opportunity, but the session record has to explain whether the opportunity came from driving line, brake shape, throttle timing, setup, traffic, or data quality. The archive does not replace analysis. It makes the right analysis easy to resume.
Worked example: throttle hesitation versus brake-shape diagnosis
The Data for Drivers chunks give a practical checklist for throttle and brake traces. Throttle review can look for coasting, hesitant application, early application leading to a lift, and lifts in fast corners. Brake review can look at the shape of the pressure trace, including initial application, trail, long tail, inconsistent pressure, and light-long versus hard-short patterns. Those phrases are not just analysis prompts. They are excellent archive tags.
Imagine you come in from a session and the lap felt slow in a medium-speed corner. Without structure, you might archive the run as bad corner or slow lap. That label will not help later. A useful closeout asks which trace behavior actually describes the loss. If speed shows the car waiting before throttle, throttle shows hesitation after the driver should have begun building power, and brake pressure is already gone, the archive tag should be throttle hesitation or coasting. If brake pressure has a long tail into the same area and throttle delay follows from that, the tag should point to brake release shape. If throttle comes in early and then the driver lifts, the tag should preserve that exact pattern because it means the problem is not simply late throttle.
The retrieval value is obvious at the end of the season. You can look for all sessions tagged with hesitant application, early throttle then lift, long brake tail, or coasting and see whether the pattern is driver habit, track-specific, car-specific, or setup-related. You can also avoid mixing unlike problems. A hesitant throttle session and an early-throttle-then-lift session may both feel like poor exit, but they ask for different next objectives.
Drill: the three-session future-comparison archive
Run this drill at your next event. The count is three consecutive sessions in the same day. The duration is 10 to 12 minutes of closeout after each session, plus 20 minutes at home after the event. The success criterion is that one week later you can retrieve the right session, comparison lap, supporting channel, and next objective without opening every file.
Before session one, write one objective. Keep it narrow. Examples that match the bonded analysis process are brake-shape consistency, throttle commitment, lap-to-lap consistency, or a specific section time. After the session, make the seven-part record: session identity, objective, conditions, setup state, channel inventory, one metric or trace summary, and next objective. Do not analyze everything. Choose one question and one comparison target.
Before session two, carry forward the next objective from session one. After the run, compare session two with session one only on the chosen question. If the objective was throttle commitment, review the throttle trace and any relevant speed or segment evidence. If the objective was braking, review brake pressure shape and speed. If the objective was consistency, review lap-to-lap or section consistency. Write what changed and whether another channel supports it.
Before session three, repeat the loop. This time, make the archive decision explicit: which of the three sessions is the teaching reference for the future. It may not be the fastest. It may be the cleanest comparison, the clearest mistake, or the best evidence of improvement.
At home, wait at least a day, then test the archive. Ask five retrieval questions: which session had the cleanest comparison, which one had the clearest incongruency, what setup or condition changed, which channel was trustworthy enough for the conclusion, and what objective should you use next time at the same track. If you cannot answer without browsing raw files, the archive needs better tags and closeout notes. If you can answer quickly, you are building a season memory that will still work after the event glow is gone.
Common mistakes
Mistake one is the raw-file cemetery. You save every logger file but attach no objective, driver comment, setup state, condition note, or first conclusion. It feels safe because nothing is lost, but the useful context is gone. Good looks like a raw file linked to a human-readable session record.
Mistake two is fastest-lap filing. You index everything by best lap and ignore the clean comparison lap, the consistent lap, or the lap with the clearest trace signature. Good looks like choosing the reference that answers the question, not automatically choosing the fastest number.
Mistake three is separating the log book from the data. The driver writes notes somewhere, the telemetry lives somewhere else, and months later neither explains the other. Good looks like one session record where driver feel, conditions, setup changes, results, channel inventory, and trace observations sit together.
Mistake four is one-channel certainty. You see one trace and declare the answer. The bonded process says to use other channels if available to check. Good looks like asking whether speed, throttle, brake, steering, lateral g, section time, GPS line, or driver comment agrees with the conclusion.
Mistake five is metric hoarding. You save every possible chart because the software can generate it. That creates the large-data problem in a new form. Good looks like preserving the metric that serves the objective: section time for section loss, throttle histogram or trace note for throttle behavior, brake pressure shape for braking, total steer angle for steering demand, and consistency metrics for lap-to-lap repeatability.
Mistake six is hiding data limitations. You make conclusions later without knowing whether brake pressure, steering angle, throttle position, RPM, or GPS line were present and trustworthy. Good looks like a short channel-limitation note in every record.
Mistake seven is no next objective. The record ends with a diagnosis but no experiment. Good looks like closing the loop: what should the next session try, and what evidence would show that it worked.
When this principle breaks down
This lesson does not teach vendor storage architecture, cloud backup policy, database schema, compression, checksum design, or file-format migration. The bonded corpus does not support those implementation details. The supported lesson is the engineering habit underneath them: preserve the information needed to compare, interpret, and learn from the session later.
The principle also breaks down when you use the archive to pretend the data says more than it does. Data can be objective and still incomplete. If your system lacks brake pressure, do not archive precise brake-pressure conclusions. If your steering channel is absent, do not build a season trend around total steer angle. If your GPS line is unreliable, do not diagnose line choice from it alone. Good archival discipline includes humility about the measurement.
Finally, the principle breaks down if you postpone the human record until the end of the weekend. Bentley's driver-record method depends on before-session objectives and after-session comments. The longer you wait, the more the objective, sensation, traffic, condition, and setup context blur together. The raw data may survive, but the meaning leaks out. Close the record while the session is still fresh.
Author Review
No quiz questions are attached to this lesson.
Sources
| # | Document | Chunk | Pages | Score | Collection |
|---|---|---|---|---|---|
| 1 | Speed Secrets Professional Race Driving Techniques Ross Bentley | a009c9a4-cb8d-b3b5-063d-33e44ea0b5cb | 76 | 1 | uio_books_raw_v1 |
| 2 | Data-for-Drivers-PRINT | bbb02386-778f-20ec-ad16-b9c016921743 | 16 | 1 | uio_books_raw_v1 |
| 3 | Data for Drivers | cabda699642b26311b0a7ef998da2c71 | 15 | 1 | uio_books_raw_v1 |
| 4 | Analysis Techniques for Racecar Data Acquisition | 5eeea298-6191-0fb2-1054-b10fe574a804 | 2 | 1 | uio_books_raw_v1 |
| 5 | Analysis Techniques for Racecar Data Acquisition | 41138569-fa56-a0a4-38c5-301475e4131a | 21 | 1 | uio_books_raw_v1 |
| 6 | Analysis Techniques for Racecar Data Acquisition | d0db9128-dc9a-aec3-14a8-5f101654753f | 3 | 1 | uio_books_raw_v1 |
| 7 | Analysis Techniques for Racecar Data Acquisition | ad559d04-3651-61c2-d02b-5455aba0d7cc | 7 | 1 | uio_books_raw_v1 |
| 8 | Data for Drivers | d631abbb-2f0e-2c19-352a-be07deb00c4d | 1 | 1 | uio_books_raw_v1 |
| 9 | Analysis Techniques for Racecar Data Acquisition | 7ae7b884-5466-cf01-8e1a-333086305e85 | 5 | 1 | uio_books_raw_v1 |
| 10 | Analysis Techniques for Racecar Data Acquisition | 1d32f116-9b81-52c6-919d-dba1c542c011 | 5 | 1 | uio_books_raw_v1 |
| 11 | Analysis Techniques for Racecar Data Acquisition | 9ee3c928-9190-4c5d-2314-158932244c31 | 22 | 1 | uio_books_raw_v1 |
| 12 | Race Car Engineering Mechanics Paul Van Valkenburgh | f721fe85-812c-0bdc-d9b3-212cd51c14f7 | 149 | 1 | uio_books_raw_v1 |
| 13 | Race Car Engineering Mechanics Paul Van Valkenburgh | 8260513e-cde0-cc8a-046b-ba10e5cf93e9 | 155 | 1 | uio_books_raw_v1 |
| 14 | Going Faster Mastering the Art of Race Driving - Carl Lopez | 4285b990-c3e7-880e-5596-99af145b469c | 300 | 1 | uio_books_raw_v1 |
| 15 | Data-for-Drivers-PRINT | cb13d8c3-cc6b-28e9-246f-c3c64ae01efc | 1 | 1 | uio_books_raw_v1 |
| 16 | Data-for-Drivers-PRINT | b80dc634-a0a7-d6de-d470-353aed47e2a6 | 17 | 1 | uio_books_raw_v1 |