top of page

Live data analysis – recording readings correctly in operation

A fault code names a system in which a deviation was noticed. What the control unit actually sees while the engine is running is not in it. That is exactly what live data is for: continuously updated readings that show how sensors, controls and actuators work together in a particular operating state. They only become meaningful, however, when the moment of the recording matches the symptom.

This page describes the operating state in which a recording is made, how to recognise a usable recording, and how live data differs from the fault memory and freeze frame data. You then send your recording to MotorScope: usually within one hour of complete data arriving you receive an analysis report with a traceable assessment – around the clock, at night and at weekends too, independent of repair work and parts sales.

Have your diagnostic data checked →

When live data analysis makes sense

Not every fault needs a recording. It becomes worthwhile as soon as the behaviour depends on the operating state, the temperature or the load – that is, whenever a still frame from the fault memory yields too little:

  • The symptom occurs without any entry being filed in the fault memory.

  • The fault memory contains an entry, but how the car drives does not fit it.

  • The behaviour visibly depends on temperature and disappears once the engine is warm.

  • The irregularity only shows under load, uphill, with a trailer or on longer stretches.

  • After a repair a residual doubt remains as to whether the control is behaving normally again.

  • Two garages reach different conclusions and there is no common set of data.

  • Before approving a parts replacement, the data should be verifiable.

  • A set of measurements already exists, but nobody relates it to the symptom.

Safety first. If the engine warning light is flashing, if there is a severe loss of power, smoke, a smell of fuel, unusual noises, or anything unusual about the brakes or steering, do not keep driving the vehicle. Have it checked on site first – a data analysis is no substitute for an inspection of the vehicle.

What live data is – and what sets it apart from a snapshot

Live data means readings that a control unit provides continuously during operation: input values from sensors, quantities calculated from them, and feedback from the control. Unlike a stored entry, they describe not a completed state but a course over time. Only that course shows whether a value follows a change, lags behind it, or does not follow it at all.

This is why the moment decides what you learn. A value that looks unremarkable at idle can run outside its intended range under load – and the other way round. A recording that does not contain the moment of the symptom describes a state nobody asked about. How the individual engine quantities behave is the subject of online engine diagnostics; here it is about the recording itself.

When to record the data

The same engine gives different pictures in different operating states. Six situations cover most questions. Which of them fits your case follows from the symptom: what you record is the state in which the behaviour occurs.

At idle at operating temperature

Warm idle is the calmest reference an engine offers: steady speed, low load, warm-up completed. Controls work in a narrow window here, and deviations stand out accordingly. This recording serves as the starting point against which every other operating state can be compared. If the engine is unremarkable here, the search moves to states with load or with a cold engine.

On a cold start

For a cold-start recording the engine should have stood long enough for the temperatures to even out. The recording therefore begins before the start and continues through the warm-up phase. What becomes visible here is whether the reported temperatures fit one another and the standing time, how the mixture control behaves during enrichment, and at which point the control passes into normal operation. Faults that occur only with a cold engine can no longer be demonstrated later on a warm one – this recording cannot be made up without letting the vehicle cool down again.

Under load at a constant speed

At a steady speed with a constant engine speed the engine works under load without the operating points shifting all the time. This makes visible deviations that are masked at idle by the low load: control deviations that grow with load, or values that slowly drift away instead of settling. The advantage of this situation is its stability – the recorded values can be assigned to a clearly identifiable operating point.

Under acceleration

Under acceleration, load and engine speed change quickly and the control has to follow. That following is exactly the point: what becomes visible is whether demanded and actual values match, whether a value reacts with a delay, and whether the control compensates for a deviation or runs into a limit. Loss of power, juddering under acceleration or a transition into limp-home mode show up in this situation and hardly before it.

On the overrun

On the overrun – throttle closed, the vehicle rolling in gear – the engine is driven along instead of driving. Injection is reduced, and the pressure and filling conditions reverse compared with the traction phase. This situation is informative because leaks and actuators behave differently here than under traction: a value that does not return to the expected range on the overrun points to something other than the same value under load. The transition back into traction belongs in the recording as well.

Exactly while the symptom occurs

All the states above are approximations. What brings clarity most readily is the recording that contains the moment of the symptom itself – the judder, the drop in power, the warning light coming on. So start the recording before the situation in which the behaviour is known to occur, and end it only afterwards. Also note at which point in the recording the symptom occurred. Without that note, a long series of measurements stays hard to interpret, because the interesting section is not marked in it.

What makes a good recording

Whether a recording can be assessed is decided while it is taken, not while it is read. Five points make the difference.

  • Several values at the same time rather than one after another. What you learn lies in the relationship: whether one value rises while another falls, and whether both react to the same change. If the quantities are recorded one after another in separate runs, exactly that relationship is missing, because the driving situations are never exactly the same. So select the values that belong to your question together, before you start.

  • An update rate that suits the process. The more values are polled at the same time, the less often each individual one is updated. With slow processes such as warm-up that is uncritical. With fast processes – a brief judder, a load change – too low a rate can swallow the decisive deflection. In such cases, limit the selection to the values that belong to the question.

  • Record the duration and the moment. Note how long the recording ran and at which point the symptom occurred. A recording without that note forces guesswork about which section is meant.

  • Safety comes before data quality. Do not operate any device or phone while driving. For recordings under load a second person is sensible, operating the device and noting the observations while you drive; otherwise start the recording while stationary and let it run unattended. Measurement drives belong on a road where the driving situation can be produced safely – not in dense traffic. Traffic rules and speed limits apply unchanged; no recording justifies a manoeuvre that endangers others.

  • Assign every recording to its operating state. When you send them, say which recording belongs to which state – warm idle, cold start, constant speed, acceleration, overrun. Several unlabelled series cannot sensibly be compared with one another; three labelled ones can.

Fault memory, freeze frame data, live data: what is what

Fault memoryFreeze frame dataLive data

What it isList of the entries a control unit has filed, with code and statusSnapshot of the operating quantities at the moment of an entryContinuously updated readings during operation

When it arisesAs soon as a deviation meets the stored conditionsTogether with the entry, automaticallyOnly while you are recording

What it showsWhich system reported a deviation and whether it is current or storedThe conditions under which the entry arose – engine speed, temperature, load, vehicle speedHow values behave over time and how they react to one another

What it does not showThe cause and the course leading up to itWhat happened before and after that momentAnything about states that were not recorded

AvailabilityRemains until it is clearedOnly for entries that carry a snapshot with themIs lost if it is not saved

The three kinds of data do not replace one another, they complement one another: the fault memory names the suspicion, the freeze frame data supplies the conditions under which it arose, and the live data shows the course. How a fault code is built up and what the status says about it is described on the page about OBD diagnostics. If several entries sit in the memory at once, the fault code analysis shows how to separate the trigger from the follow-on entries. How an ordered diagnostic path emerges from these building blocks is set out under fault diagnosis.

Why live data alone still does not name a cause

Even a clean recording remains a description, not an explanation. Five patterns regularly lead to readings being read in the wrong direction.

The value is within the permitted range and still does not fit

A reading can lie within the intended limits and still not match the operating situation. It only stands out in comparison with the state in which it arose and with the other values from the same recording.

Calculated quantities look like measured ones

Some of the displayed values are not measured directly but calculated from other quantities. If an input value is distorted, the error travels on into everything derived from it. The conspicuous value then sits somewhere other than the cause.

The control masks the deviation

Controls compensate for deviations for as long as their adjustment range allows. The controlled quantity looks unremarkable while the manipulated variable is already far out. That only becomes visible when both values are recorded together.

The update rate simulates a course

If a value is updated rarely, jumps arise between updates that look like a drop-out. Whether a deflection is real or comes from the polling rate can only be judged if it is known how many values were polled at the same time.

The link to the symptom is missing

A recording without a note of when the symptom occurred can hardly be assessed. The most conspicuous point in the series need not be the point at which the vehicle actually behaved oddly.

Preparatory work is not documented

If the fault memory was cleared before the recording, a connector disconnected or a component replaced, the control behaves differently from everyday operation – adaptation values start again from the beginning. Without that note, a normal adaptation process is read as a fault.

What data live data analysis needs

Required

  • Vehicle data: VIN (17 characters; the letters I, O and Q do not appear in it), model, engine, year of manufacture and mileage.

  • Description of the symptom: when the behaviour occurs – right after starting, under load, on the motorway, with a cold engine or only after a longer drive. Since when, how often, under which conditions.

  • Diagnostic data: diagnostic tester export, fault memory print-out or app export with control unit, fault code and fault status.

  • A note on the operating state: which situation the recording belongs to and at which point the symptom occurred.

Helpful, if available

  • Freeze frame data with engine speed, coolant temperature, engine load or vehicle speed.

  • Further live data from a second operating state for comparison, and target/actual comparisons.

  • A note on how many values were polled at the same time and how long the recording ran.

  • Screenshots from an OBD app and photos of the warning lights.

  • Invoices for work already carried out and a list of replaced parts.

  • Any indication that the fault memory was cleared, that the battery was weak or that a connector was recently disconnected.

How to make your data usable Send the complete log wherever possible rather than a code typed out by hand. Screenshots only help if every value is legible and not just the top line of the screen is shown. Photos should be sharp and show the entry in full. A special diagnostic tester is not a requirement – existing print-outs, photos or app exports are often enough, provided the fault description is meaningful.

Where diagnostic data can be obtained at all, and what the assessment costs, is set out under online vehicle diagnostics. If there is no recording from the vehicle yet, the data set can also be built from existing documents as part of remote car diagnostics.

How the analysis works

  1. Describe the problem — Give the vehicle model, engine, year of manufacture and mileage – and describe when the symptom occurs.

  2. Send the data — Upload fault codes, diagnostic logs, freeze frame data or screenshots through the form.

  3. Assess the connections — MotorScope compares the data with the symptoms you described and the work carried out so far.

  4. Receive the analysis report — Usually within one hour of complete data arriving, you receive your analysis report with a traceable assessment and a prioritised list of possible checks. Assessment runs around the clock – at night and at weekends too.

What the analysis report contains

  • Systematic assessment of the fault memory and – where available – the live data and sensor values

  • Plausibility check of the values and assessment of the technical connections

  • Comparison with publicly available manufacturer specifications and reference values

  • VIN-based check for publicly available recalls and service campaigns

  • Analysis report assessing the irregularities, with recommendations on how to proceed

What the online assessment does – and what it does not

What the online assessment does

  • Puts fault memory, live data and symptoms into context

  • Shows which measurement is most likely to bring clarity next

  • Makes a repair recommendation verifiable before you approve it

  • Prepares the garage visit with a clear question

  • Is independent of repair orders and parts sales

What it does not do

  • Repairs and parts sales

  • Approving repairs or certifying roadworthiness

  • Replacing a personal inspection of the vehicle

  • Swapping parts on suspicion, or a guarantee of success

  • Replacing the German MOT (HU), the emissions test (AU) or any other legally required inspection

If the data does not show a clear picture, the report says so explicitly. Rather than settling on a cause prematurely, it shows which check will bring the most clarity next.

Frequently asked questions about live data analysis

In which operating state should I record?

In the state in which the symptom occurs. If it only occurs with a cold engine, the recording begins before the start; if it shows under load, a measurement drive belongs to it. An additional recording at warm idle is helpful as a comparison, because the other states can be measured against it.

How long does a recording have to be?

It should contain the moment of the symptom in full, so begin before it and end after it. A short recording with the symptom in it says more than a long one without.

How many values should I record at once?

As many as belong to the question, and no more. Every additional value reduces the update rate of the others. With fast processes a narrow selection is an advantage; with slow processes a larger selection hardly matters.

Can I record while driving myself?

Do not operate a device at the wheel. Start the recording while stationary and let it run, or take a second person who operates the device and notes the moment of the symptom. Measurement drives belong on a road where the driving situation can be produced safely.

Are screenshots enough instead of a recording?

Screenshots show a moment, not a course. For questions that turn on behaviour over time, a recording is considerably more productive. If only screenshots are available, every value should be legible and the operating state should be stated with them.

What if no fault is stored during the recording?

That is often the case and is no reason to stop. Symptoms without an entry in the fault memory are precisely a typical reason for a recording, because the behaviour only shows over time.

Does the recording have to come from a particular device?

No. What counts for the assessment is the content: the individual values must be legible, several quantities should come from the same run, and the operating state belongs with them. Whether the values come from a workshop log, an app or a photographed screen is secondary.

What if the recording shows no clear cause?

With complex fault patterns that is normal. The report then names which measurement or which additional operating state will bring the most clarity next, instead of committing prematurely.

All questions and answers

Understand the data first. Then act with purpose.

Upload your diagnostic data and receive an independent assessment usually within one hour – before you order the next part. Around the clock, at night and at weekends too.

Have your diagnostic data checked →

bottom of page