Measurement and recording analysis
Work through MDF/MF4 measurements and bus recordings to establish what happened, when, and under which conditions — starting from the evidence in the file rather than from an assumed cause.
Vehicle Data & Measurement
Vehicle measurement and log analysis
Measurement campaigns produce far more data than anyone can inspect by hand. The problem is rarely a shortage of data — it is finding the few seconds that matter across hundreds of files, and being able to find them again the next time without repeating the work.
Discuss a Data Analysis ProjectProblems I can investigate
Find the behavior behind the symptom
- 01
An event is somewhere in the measurement, but hard to locate
A known symptom occurred during a drive, and finding it means scanning long recordings for a condition that has not yet been expressed precisely. Defining that condition is usually the first real step.
- 02
Measurement files are too large to work with
Files that exceed what a viewer or spreadsheet can handle need streaming or chunked processing, selective signal extraction, and resampling decisions made deliberately rather than by whatever a tool defaults to.
- 03
The relationship between signals is unclear
Two signals appear connected, but the relationship is obscured by sampling rates, time offsets, or the fact that they were recorded through different paths. Correlation is examined with those effects made explicit.
- 04
Event detection needs to be automated
A condition that was found manually once needs to be found reliably every time, across every future measurement, with the same definition applied consistently.
- 05
The same analysis has to run across many files
An analysis that works on one recording has to be applied to a whole campaign, with results aggregated in a form that supports comparison rather than one report per file.
- 06
Data is in the wrong format for the next step
Measurements and recordings need to move between formats and into other tools without silently losing timestamps, signal metadata, or numeric precision.
What I can help with
Focused engineering work in Vehicle Data & Measurement
Event detection and rule definition
Turn an informally described symptom into an explicit, testable condition over signals and time, then apply it consistently across recordings so results are comparable.
Signal correlation and timing analysis
Compare signals recorded at different rates or through different paths, making resampling, alignment, and time-offset handling explicit rather than incidental.
Bus recording decoding
Decode CAN traffic inside recordings against database definitions so network data can be analyzed alongside measured signals in the same timeline.
Batch analysis pipelines
Build repeatable processing that runs across an entire measurement campaign and aggregates results, so the analysis survives past the engineer who first ran it.
Format conversion and data extraction
Move measurement and recording data between formats and into downstream tooling while preserving timestamps, signal metadata, and precision.
Visualization and reporting
Produce the plots and summaries that make a finding reviewable by other engineers, generated by the same pipeline that produced the result.
Specific services
Services in Vehicle Data & Measurement
Automated Vehicle Measurement Analysis
Find recurring events across MF4/MDF recordings with automated signal checks, explicit time alignment, and traceable engineering reports.
BLF Analysis
Investigate intermittent vehicle faults in BLF logs with event timelines, message timing comparisons, decoded signals, and documented evidence.
BLF Conversion
Convert supported BLF records to ASC or CSV with checks for timestamps, channels, identifiers, and payloads. Document format limits and verify target-tool import.
BLF Decoding Service
Decode BLF recordings into usable CAN data, investigate vehicle behavior, and automate repeatable analysis from supplied logs and DBC files.
MF4 Automation
Automate recurring MF4 measurement batches with configurable event rules, per-file processing status, repeatable reports, and explicit handling of failed inputs.
MF4 Conversion
Convert MF4 measurement data into practical engineering workflows, with automated processing, signal analysis, and repeatable reporting.
MF4 Measurement Analysis
Analyze MF4 measurement data to locate events, correlate signals, investigate vehicle behavior, and automate repeatable engineering reports.
Python Automation
Automate automotive data preparation and recurring engineering workflows in Python with input validation, reusable configuration, and clear outputs.
What to send
Start with the evidence you already have
Problem description
Observed symptoms, context, reproduction steps, and expected behavior.
MF4/MDF measurement
A measurement file containing recorded signals and timestamps.
BLF recording
A Vector binary log containing timestamped bus communication.
ASC recording
A text-based Vector bus recording.
CAN dump
Raw or text-exported CAN frames.
DBC
A CAN database defining messages and signals, needed for signal-level decoding.
How the analysis works
From recorded data to engineering findings
- 01
Define what is being looked for
Convert the described symptom into a condition that can be evaluated over signals and time. Ambiguity here is the most common reason an analysis produces results nobody trusts.
- 02
Establish what the data contains
Check which signals are present, at what rates, over what period, and whether the recording actually covers the conditions in question.
- 03
Build the analysis
Implement the detection, correlation, or conversion as code, with the handling of resampling, alignment, and missing data made explicit.
- 04
Apply it across the data set
Run the analysis over the full set of recordings and aggregate the results so occurrences can be compared rather than read one file at a time.
- 05
Review the findings against the data
Check detected occurrences against the underlying signals to confirm the rule is finding what it was meant to find, and note the cases where it cannot decide.
- 06
Deliver a repeatable pipeline
Hand over the analysis in a form that can be re-run on future measurements, with the plots, reports, and documentation it produces.
What you receive
Deliverables matched to the investigation
Engineering analysis
A documented analysis of the measurement data, with the evidence and findings behind it.
Python analysis script
A maintainable Python workflow for engineering-data analysis.
Automated report
Generated plots and summaries produced by the analysis on each run.
Data converter
A conversion tool between measurement or recording formats that preserves timestamps and metadata.
Measurement viewer
A focused viewer for inspecting the signals and events that matter in your workflow.
CAN decoding results
Decoded frames, signals, and interpretation notes from bus recordings.
Technologies & formats
Automotive data and analysis environments
- MDF
Measurement Data Format
The ASAM family of binary measurement-data formats.
- MF4
MDF 4 Measurement
The fourth-generation ASAM MDF format for synchronized measurement data.
- BLF
Binary Logging Format
A Vector binary container for timestamped bus communication.
- ASC
ASCII Log Format
A human-readable Vector format for timestamped bus events.
- CSV
Comma-Separated Values
A tabular text format often used for exchanging decoded engineering data.
- DBC
CAN Database
A text format describing CAN messages, signals, nodes, scaling, and metadata.
- XCP
Universal Measurement and Calibration Protocol
A protocol for ECU measurement, calibration, stimulation, and programming.
- DLT
Diagnostic Log and Trace
An AUTOSAR logging protocol and format for embedded applications.
- CANalyzer
Vector CANalyzer
A Vector environment for recording and analyzing vehicle-network communication.
- MDA
ETAS MDA
A measurement-data analysis and visualization application.
- cantools
cantools
A Python package for parsing CAN databases and encoding or decoding messages.
- Python
Python
A general-purpose language widely used for automotive analysis, tooling, and automation.
FAQ
Practical questions before an investigation
- How large can the measurement files be?
- Size is a processing design question rather than a hard limit. Files too large for interactive viewers are handled by streaming or chunked reading and by extracting only the signals an analysis needs. Where a data set is too large to transfer, the work can be delivered as a pipeline you run on your own infrastructure.
- What if I cannot share the measurement data?
- That is common with vehicle data. The analysis can be built against a representative sample, an anonymized extract, or a described signal structure, and delivered as code you run in your own environment. The trade-off is that validation then depends on your feedback rather than direct observation.
- Do you need a DBC to analyze a bus recording?
- For signal-level analysis, yes — decoding payloads into physical values requires the definitions. Frame-level analysis, including timing, presence, and error activity, is possible without one. Measurement files in MDF/MF4 usually carry their own signal metadata and do not need a DBC.
- Can the analysis be handed over rather than run as a service?
- Yes, and that is usually the better outcome. The deliverable is normally a documented Python workflow your team can re-run and adapt, not a one-off result. A single analysis run is available where that genuinely is all that is needed.
- How do you handle signals recorded at different rates?
- Explicitly. Resampling and alignment choices change what a correlation appears to show, so the chosen approach — and its effect on the result — is documented rather than left to a library default. Where a timing relationship cannot be resolved from the available sampling, that is reported as a limit of the data.
Discuss the evidence
Discuss a Measurement Analysis Project
Describe what you need to find in your vehicle data. A sample measurement or recording and the condition you are looking for is enough to scope the work.