Telemetry Data Quality Checklist

Two laps can be aligned on screen and still be a poor comparison. A different circuit layout, an incorrect timing reference, traffic, a changing tyre state or a clipped channel can make a precise-looking trace answer the wrong question.

This checklist comes before interpretation. It does not decide which setup is faster, rank a logger or diagnose a car. It helps you decide whether the pair of laps is usable enough to support one careful next question.

What data quality means here

Data quality is not a single score. It is the context needed to know what a signal can and cannot support. A lap comparison may have reliable timing but no steering channel, or a useful speed trace with uncertain GPS alignment. Keep those limitations visible instead of treating missing information as a zero.

The aim is a defensible statement such as: “These laps are comparable enough to investigate the exit of one corner, but the logger does not establish steering angle.” That is more useful than a confident conclusion built on an unknown.

If the file itself is the first uncertainty, use the Telemetry CSV Data-Quality Inspector to check its local structure before interpreting the channels. It can expose missing cells, duplicated timestamps, contextual gaps and flat-lined fields, but it cannot establish sensor accuracy or vehicle condition.

1. Confirm the lap and circuit definition

Before opening the traces, record:

• circuit and layout
• direction of travel
• session or run identifier
• start and finish definition
• sector or split definition, if used
• timing source, beacon or GPS reference
• whether the analysis software has aligned the laps to the same distance or time basis

A lap from a different layout or timing definition is not a valid comparison just because its final time looks similar. If the start line, lap marker or alignment point moved, label the comparison unusable until it is corrected.

2. Record the session context

Start with what can change the answer to this specific question. The aim is not to complete an academic data-acquisition form.

Essential now

• confirm the circuit layout, direction, session or run identity, and start or finish definition
• state the question narrowly enough to test, such as one corner exit or one input phase
• identify the channels needed for that question and whether they are available, usable and understood
• record any material difference that could affect the answer, rather than silently assuming the conditions were equivalent

Useful when relevant

• traffic, overtakes, flags or a lift caused by another car
• weather, track temperature, damp patches and changing surface
• tyre model, condition, warm-up state and the measurement process
• fuel, passenger or load differences
• session order, cool-down laps and interruptions
• driver intent, notable corrections and anything felt in the car

Do not document every possible variable when it cannot affect the question. Record material differences when they matter, and keep the resulting limitation visible. A changing context does not automatically invalidate a pair. It changes the confidence and the question the pair can answer.

The existing cold-to-hot tyre-pressure method can support the tyre-state record when pressure context matters. It records observed change without creating a universal target.

3. Check channel provenance

For every channel you plan to use, identify what it represents and where it comes from:

• directly measured sensor signal
• vehicle or CAN-supplied signal
• GPS-derived position or speed
• calculated or filtered channel
• driver note or observation

Vendor documentation can provide narrow product context, but a URL that resolves to a general downloads area or a company home page is not specific technical evidence for a capability. Do not infer that every logger, vehicle integration, licence or configuration provides every signal. Check the actual installation and software configuration. Where documentation describes product-specific comparison views, overlays or channel types, keep that claim conditional.

A channel name is not a guarantee of accuracy. Record missing sensors, uncertain definitions, smoothing, filtering, clipping and any known timing or synchronization limitation.

4. Check alignment and completeness

Look for:

• a complete trace from the same start and finish
• sensible sector or split boundaries
• consistent lap distance or time alignment
• a checked timing and synchronization basis
• no obvious GPS jumps or dropouts
• no clipped or flat-lined channels where the question depends on them
• comparable sampling and filtering where the software exposes those settings

If the evidence needed for the question is absent, the correct state is not “zero” and not “no difference”. It is unknown. Choose a narrower question, collect better data or stop the interpretation there.

5. Decide whether the pair is usable

Usable for a defined question

The layout, timing, context and relevant channels are sufficiently comparable. You can locate one segment or phase to inspect, while retaining the stated limitations.

Usable with limitations

The pair can support a cautious observation, but one or more factors remain uncertain. State the uncertainty beside the observation and avoid a mechanical or setup conclusion.

Not usable for this question

The laps differ in layout, timing, context or required evidence, or the signal quality prevents a meaningful comparison. Do not use the pair to justify a vehicle change. Find a better pair or record what must be measured next.

This is a data-quality decision, not a score for the driver or the equipment.

6. Move from quality to interpretation

Once the pair is usable, use the two-lap telemetry method to locate where time changed. Start with a cumulative delta or segment time, choose one corner or linked section, and compare the available inputs and vehicle-response signals together.

That existing guide answers a different question. This page asks whether the evidence is fit enough to interpret. The two-lap method asks where the time changed, what might explain it and what to test next. Do not use this gate as a substitute for the deeper trace-analysis method.

Keep the sequence separate:

1. observation: what changed in the trace or driver report?
2. possible explanation: what might account for it?
3. test or measurement: what would distinguish those explanations?
4. controlled change: what one safe input could be compared?
5. validation: what result would support or weaken the hypothesis?

A delta locates a time difference. It does not prove its cause. A faster lap is not evidence that every action on it was better, and one channel is not enough to diagnose a mechanical fault.

Practical pre-interpretation checklist

Before writing a conclusion, answer:

• Are both laps definitely the same circuit layout and direction?
• Is the start, finish and sector definition the same?
• Was alignment or synchronization checked?
• Were material differences such as traffic, weather, tyre state, fuel or load recorded where relevant?
• Which channels are actually available and what is their provenance?
• Are any channels missing, clipped, filtered or uncertain?
• Is the question narrower than the evidence can support?
• Can one segment be compared without pretending the whole lap is explained?
• What would make the result inconclusive?
• What is the next measurement or controlled test?

If several answers are unknown, keep the result in the unknown or not-usable state. That is a valid outcome and protects the next test from false precision.

Related method and boundaries

The structured track-test method connects data review to a baseline, one controlled change and validation. The methodology page explains why source-backed facts, conditional interpretation and visible limitations matter.

Do not increase driving risk because a trace appears clean. Telemetry does not clear a suspected brake, tyre, wheel, suspension, steering or structural fault. Follow manufacturer, component and event guidance and seek competent inspection where appropriate.

Limitations

This checklist is an editorial method, not a measurement standard or software review. Channel availability and signal quality vary by logger, vehicle integration, configuration and software version. Sampling, filtering and synchronization depend on the actual logger and software; treat them conditionally and verify what the software exposes. A consistent process improves comparison but does not turn a small dataset into a diagnosis.

No measured session, real driver experience, representative telemetry or product hands-on testing is claimed here. The next useful step is to record the missing context or choose a better-comparable pair before making a technical conclusion.