CAN Bus Reverse Engineering and Vehicle Sensor Validation
Cosmo A. Hausmann and Francesca Koch
Dresden University of Applied Sciences
September 11, 2026
Modern vehicles generate vast amounts of CAN bus and sensor data, but accessing this information can be difficult without manufacturer documentation or a DBC file.
In this study, we use DewesoftX to reverse-engineer and decode an unknown CAN-FD vehicle speed signal from a production vehicle. We then compare the vehicle’s integrated acceleration sensors with a Bosch mm3 reference sensor during different driving maneuvers.
The results demonstrate how raw vehicle data can be decoded, validated, and used for vehicle dynamics analysis and sensor evaluation.

Reverse engineering vehicle CAN bus data
Modern vehicles exchange large amounts of data over their internal communication networks, but interpreting these signals can be difficult without manufacturer documentation or a DBC file.
In this study, we developed a practical workflow to identify and reconstruct an unknown signal from the CAN-FD network of a Škoda Enyaq Coupé RS iV. CAN-FD data was acquired through a direct bus connection using a Vector Informatik VN1630A interface and analyzed in real time with DewesoftX.
Using the Byte Change Detection feature in DewesoftX, we identified a motion-dependent signal without prior knowledge of its structure. Further analysis revealed that the signal represented vehicle speed, which could then be decoded and consistently reconstructed across the test drives.
The study demonstrates a practical method for CAN bus reverse engineering and signal decoding without manufacturer documentation, while showing how DewesoftX can be used to identify, analyze, and validate unknown CAN-FD signals.
Vehicle inertial sensor validation
The second part of the study compares the vehicle-integrated acceleration sensors of the Škoda Enyaq Coupé RS iV with a Bosch mm3 reference sensor. Longitudinal and lateral acceleration were recorded during acceleration, braking, circular driving, and zigzag maneuvers.
The measurements were analyzed for signal behavior, noise, offsets, and resolution. The vehicle-integrated sensors generally followed the Bosch reference measurements but produced smoother signals with less visible noise. The comparison also examines how signal filtering, sensor preprocessing, and numerical resolution affect the interpretation of vehicle acceleration data.
CAN bus reverse engineering without a DBC file
CAN-FD data acquisition setup
The study was conducted on a production electric vehicle, a Škoda Enyaq Coupé RS iV, whose vehicle network uses both CAN and CAN-FD communication. CAN-FD extends the capabilities of Classical CAN by supporting higher data rates and larger payloads per message [1].
The Controller Area Network (CAN) is a serial communication system widely used in vehicles to exchange data between electronic control units (ECUs), sensors, and actuators over a shared bus. Messages are identified by unique identifiers, which also determine their priority during bus arbitration [2].
For this study, three elements of the CAN frame are particularly important:
Start of Frame (SOF): Marks the beginning of a CAN message and synchronizes nodes on the network.
Identifier (ID): Identifies the message and determines its priority during bus arbitration.
Data field (payload): Contains the transmitted data that can be decoded into individual vehicle signals [1].
To acquire the vehicle data, we connected a Vector Informatik VN1630A interface directly to the vehicle’s CAN bus. Unlike OBD2-based diagnostics, the direct connection provided access to raw vehicle-network data without filtering through diagnostic protocols [1].
The integrated CAN module in DewesoftX was used to acquire, synchronize, record, and visualize the CAN and CAN-FD data in real time. The recorded raw data included arbitration IDs, high-resolution timestamps, and hexadecimal payload data for subsequent signal identification and decoding.
Identifying unknown CAN-FD signals in DewesoftX
We identified unknown CAN-FD signals directly during measurement using the Raw Data Analyzer in DewesoftX. This tool enables the analysis of raw, unstructured CAN data without an existing DBC file and visualizes signal activity at the bit and byte levels [3].
For the initial analysis, we used the Byte Change Detection function. First, we recorded a reference measurement while the vehicle was stationary at 0 km/h, establishing a static reference for all byte values in the CAN data stream. DewesoftX could then highlight changes in individual message contents as soon as the vehicle started moving [3].
The Change column in the Raw Data Analyzer indicates how much a byte deviates from the defined reference state on a scale from 0 to 100. A higher value represents a greater deviation. Sorting CAN messages by this parameter made it easier to identify bytes that changed in response to vehicle motion, particularly those that were constant or zero in the stationary reference measurement [3].
When the vehicle began moving, several byte positions showed clear deviations from the stationary reference. DewesoftX highlights these changes directly in the raw data stream, with the color intensity indicating the magnitude of the change. This real-time visualization helped identify motion-dependent CAN signals without prior knowledge of their structure [3].
Identifying CAN message 0x260
During the analysis, Arbitration ID 0x260 stood out. The message showed consistent and reproducible byte changes while the vehicle was moving but remained stable when stationary. This correlation made it a strong candidate for a vehicle dynamics signal. Additional stationary tests were performed to rule out throttle pedal position as the source of the signal.
To investigate the message further, we recorded several driving maneuvers on the test track at Dresden University of Applied Sciences using DewesoftX. CAN message 0x260 was selected for detailed analysis, with individual recordings limited to 30 seconds to create compact and comparable datasets.
Analysis in DewesoftX revealed that only bytes 7 and 8 contained dynamic signal components. When the vehicle was stationary, these bytes consistently contained the hexadecimal values 20 00. Because the message uses Intel byte order, or Least Significant Byte First, this corresponds to 0x0020, giving a stationary offset of 32.
Decoding the vehicle speed signal
For further analysis, we exported the raw data from DewesoftX and processed it in Python. The last two bytes of message 0x260 were extracted and plotted over time. The resulting signal showed a clear correlation with the vehicle’s actual speed profile.
At a maximum vehicle speed of approximately 40 km/h, an initial scaling factor of 0.005 was derived from the relationship between the raw CAN value and actual vehicle speed. The signal could therefore be decoded using the following relationship:
During reverse driving, CAN message 0x260 continued to produce positive values. This behavior suggests that the signal represents the magnitude of vehicle speed rather than direction-dependent longitudinal velocity, as commonly used for functions such as the Anti-lock Braking System (ABS) or Electronic Stability Program (ESP) [4].
Validating the decoded CAN signal
To further test whether message 0x260 represented vehicle speed, we used the decoded signal to calculate longitudinal acceleration. First, the speed signal was converted to m/s and slightly smoothed to reduce quantization effects. Numerical differentiation over time was then used to derive acceleration.
The evaluated test drive included both longitudinal and lateral vehicle motion, with the analysis focused on the first longitudinal driving maneuver. The calculated acceleration reached a peak of approximately 5.75 m/s², which falls within a plausible range for production electric vehicles reported in the literature [5].
Decoding and validating the vehicle speed signal
To validate the identified CAN message 0x260, we compared the decoded signal with known vehicle data. The four wheel-speed signals recorded during the same test runs served as reference values.
We exported the relevant signals from DewesoftX and processed them in Python. The decoded signal from message 0x260 showed a strong correlation with the wheel-speed signals over time. Because the datasets were not recorded simultaneously, they first had to be synchronized. Using their timestamps, each measurement point from message 0x260 was matched with the closest wheel-speed reference value.
Determining the vehicle speed scaling factor
We determined the final scaling factor using least-squares estimation, with the mean of the four wheel-speed signals as the reference. The calculation was based on the previously established relationship:
The optimal scaling factor k was determined by minimizing the squared error between the decoded CAN signal and the wheel-speed reference. This resulted in a final scaling factor of 0.00451.
A slight difference remained between the reconstructed vehicle speed and the wheel-speed-based reference, as shown in Figure 6. This difference is expected because vehicle speed in ABS and ESP systems is generally not calculated as a simple average of individual wheel speeds. Instead, vehicle dynamics estimation and filtering methods can be used to determine vehicle speed [4].
Creating a decoded vehicle speed channel in DewesoftX
Using the identified signal parameters, we created a new receive channel named Velocity in the DewesoftX Port Channel Decoder.
The decoded channel enables the reconstructed vehicle speed to be visualized in real time and recorded directly in DewesoftX for further analysis and signal processing.
Validating the CAN bus decoding method
The analysis indicates that CAN message 0x260 most likely represents vehicle speed. This interpretation was supported by several independent checks, including reconstruction using the identified offset and scaling factor, comparison with wheel-speed reference signals, and the physically consistent acceleration derived from the decoded speed signal.
The results demonstrate that certain vehicle dynamics signals can be reverse-engineered without a DBC file when sufficient measurement data and suitable reference signals are available. Combining raw CAN data analysis, data-driven scaling, comparison with known signals, and physical plausibility checks provides a practical approach for identifying and validating unknown signals in vehicle networks.
Vehicle inertial sensor validation
Vehicle and reference sensor test setup
The second part of the study compares the vehicle-integrated acceleration sensors of the Škoda Enyaq Coupé RS iV with a Bosch mm3 reference sensor.
The Bosch mm3 had already been installed in the vehicle by laboratory engineers for previous testing. It was positioned in a storage compartment in the front section of the center console and transmitted its measurement data over the CAN bus.
The Bosch mm3 is a three-axis inertial measurement sensor capable of measuring longitudinal acceleration, lateral acceleration, and vehicle yaw rate. For this study, we focused on comparing the longitudinal and lateral acceleration signals from the Bosch reference sensor with those transmitted by the vehicle-integrated sensors.
Accessing the vehicle acceleration signals
The exact position of the vehicle-integrated sensor was unknown. For the analysis, we assumed it was located near the vehicle’s center of gravity, approximately in the center console area at seat level.
Before comparing the measurements, we first had to identify and decode the CAN messages containing the vehicle’s acceleration data. We used the Raw Data Analyzer in DewesoftX to identify the relevant signals.
The Bosch mm3 also communicates via CAN. However, unlike the unknown vehicle signals, a corresponding DBC file for the Bosch sensor was provided by the Faculty of Vehicle Mechatronics at HTW Dresden and used to decode its CAN messages.
CAN and CAN-FD data acquisition
Both sensor systems were connected to DewesoftX on the measurement PC using a Vector Informatik VN1630A interface. The Bosch mm3 communicates via Classical CAN, while the vehicle sensor network uses CAN-FD.
Classical CAN supports message payloads of up to 8 bytes and bit rates of up to 1 Mbps. CAN-FD (Flexible Data Rate) extends the protocol with payloads of up to 64 bytes and higher data rates during the data phase. This increased bandwidth makes CAN-FD suitable for modern automotive systems that need to exchange larger amounts of data, including Advanced Driver Assistance Systems (ADAS) [6].
Comparing vehicle acceleration sensor data
Before starting the measurements, we imported the available DBC files for the vehicle CAN network and the Bosch mm3 sensor into the CAN plugin in DewesoftX.
The vehicle’s longitudinal acceleration signal was transmitted in m/s². To enable direct comparison with the Bosch mm3 measurements, we converted the signal to gravitational acceleration (g). A math channel was created in DewesoftX to divide the acceleration values by the gravitational constant of 9.81 m/s².
The required CAN signals were then enabled for recording in the DewesoftX CAN plugin. Once storage was activated, the recorded channels became available for post-processing in Analyze mode.
We configured four recorder instruments to compare the longitudinal and lateral acceleration signals from the vehicle-integrated sensors with those from the Bosch mm3 reference sensor.
Vehicle test maneuvers
We performed three driving maneuvers on the test field at Dresden University of Applied Sciences:
Acceleration and braking: The vehicle accelerated to approximately 45 km/h, followed by strong braking to a complete stop.
Circular driving: The vehicle followed a circular path at approximately 20 km/h.
Zigzag driving: The vehicle performed a zigzag maneuver at approximately 23 km/h.
Figure 9 shows the acceleration signals recorded during these maneuvers. The upper graphs show longitudinal acceleration, while the lower graphs show lateral acceleration from the vehicle-integrated sensors and the Bosch mm3 reference sensor.
During the measurements, we identified a significant offset in the vehicle sensor signals. When the vehicle was stationary, the lateral acceleration signal indicated approximately 1.24 g, while the Bosch mm3 remained close to zero. We therefore applied an offset correction of 1.24 g to normalize the vehicle signal to zero. A similar correction was required for the longitudinal acceleration signal.
Longitudinal acceleration results
During the acceleration and braking maneuver, the Bosch mm3 measured a maximum longitudinal acceleration of 0.669 g, compared with 0.659 g from the vehicle sensor. The minimum values were -0.605 g for the Bosch mm3 and -0.618 g for the vehicle sensor.
When the vehicle was stationary, both sensors exhibited baseline noise. However, the Bosch mm3 showed noticeably more noise than the vehicle-integrated sensor. Similar behavior was observed in the lateral acceleration measurements. The Bosch signal fluctuated around approximately 0.080 g, while the vehicle sensor remained between approximately 0.010 g and 0.000 g.
Lateral acceleration results
During the circular driving maneuver, the Bosch mm3 measured a maximum lateral acceleration of -0.583 g, while the vehicle sensor measured -0.520 g, resulting in a difference of 0.063 g.
During the zigzag maneuver, the Bosch mm3 recorded maximum and minimum lateral accelerations of 0.350 g and -0.408 g, respectively. The vehicle sensor measured 0.370 g and -0.270 g.
The largest difference between the two sensor systems occurred at the minimum lateral acceleration during the zigzag maneuver, with a deviation of 0.138 g.
Sensor noise, filtering, and resolution
Overall, the Bosch mm3 exhibited a higher baseline noise level and appeared to provide minimally filtered sensor data. In contrast, the vehicle-integrated sensor produced smoother signals with less visible noise. This behavior suggests that the vehicle data may undergo filtering or preprocessing before being transmitted over the CAN-FD network.
A closer examination of the lateral acceleration signal also revealed visible quantization effects in the vehicle data. As shown in Figure 10, the vehicle signal had a resolution of approximately 0.01 g, resulting in distinct flat sections in the signal curve. This behavior may indicate limited signal resolution or digital filtering.
The Bosch mm3 provided substantially higher numerical resolution, displaying values with up to 10 decimal places. However, higher numerical resolution does not necessarily mean higher measurement accuracy. Greater resolution can also make measurement noise and systematic errors more visible relative to the displayed precision.
Vehicle inertial sensor test results
The objective of this experiment was to compare the vehicle-integrated acceleration signals of the Škoda Enyaq Coupé RS iV with measurements from a Bosch mm3 reference sensor. Using DewesoftX and CAN-based data acquisition, we recorded, decoded, and analyzed longitudinal and lateral acceleration signals from both sensor systems.
Overall, the two systems showed good agreement across the tested driving maneuvers. During acceleration and braking, the maximum and minimum longitudinal acceleration values differed only slightly between the Bosch mm3 and the vehicle sensor. Similar behavior was observed during circular driving. The largest difference occurred during the zigzag maneuver, where the negative lateral acceleration values differed by 0.138 g. Despite this deviation, the overall signal behavior remained comparable throughout the tests.
Sensor offset, noise, and filtering
An important observation was the presence of offsets in the vehicle acceleration signals. Both longitudinal and lateral acceleration channels required offset correction before they could be meaningfully compared with the Bosch reference sensor.
The Bosch mm3 also exhibited noticeably higher background noise and appeared to provide minimally filtered sensor data. In contrast, the vehicle-integrated signals were smoother and showed less noise. This difference suggests that the vehicle data may undergo filtering or signal conditioning before being transmitted over the CAN-FD network.
Automotive inertial sensors used in safety-critical systems such as Electronic Stability Control (ESC) and Advanced Driver Assistance Systems (ADAS) are designed primarily for reliable operation under demanding environmental conditions. Literature on automotive micro-electromechanical systems (MEMS) sensors emphasizes requirements such as vibration resistance, temperature stability, reliability, functional safety, and fault tolerance [7], [8].
The smoother and less noisy behavior observed in the vehicle-integrated signals may therefore result from additional filtering and signal conditioning designed to improve robustness and control stability in automotive applications.
Signal resolution vs. measurement accuracy
The measurements also highlight the important distinction between signal resolution and measurement accuracy. The vehicle acceleration signals appeared to be quantized to approximately 0.01 g, producing visible flat sections in the recorded curves. The Bosch mm3, in comparison, provided substantially higher numerical resolution.
However, higher numerical resolution does not necessarily mean higher measurement accuracy. At finer resolutions, sensor noise and systematic measurement errors can simply become more visible in the recorded data.
Key findings
The experiment shows that CAN-based vehicle sensor data can provide useful inertial measurements for many automotive applications. At the same time, the comparison demonstrates how filtering, signal processing, sensor placement, offsets, and signal resolution can influence the interpretation of vehicle dynamics measurements.
Future investigations could include more precise timestamp synchronization, frequency-domain analysis, and additional reference sensors to further evaluate the dynamic behavior and accuracy of the vehicle-integrated inertial measurement system.
References
CSS Electronics, ‘CAN bus: The ultimate guide,’ Whitepaper, 2023.
K. Reif: ‘Automobilelektronik: Eine Einführung für Ingenieure’, 5. Edition, Wiesbaden: Springer Fachmedien, 2014, ISBN: 978-3-658-05048-1.
Dewesoft. ‘Raw data analyzer.’ [Online] [last checked: 20.05.2026].
F. Jiang and Z. Gao: ‘An adaptive nonlinear filter approach to the vehicle velocity estimation for ABS’, Feb. 2000. DOI:10.1109/CCA.2000.897472.
D. Bial, S. Nagurnas, and V. Mitunevicius: ‘Experimental research of car acceleration characteristics,’ Paper, 2012.
Dewesoft: ‘Pro training: CAN and CAN FD data acquisition.’ [Online] [last checked: 22.05.2026]
M. Ortloff et al.: ‘Reliability of automotive and consumer MEMS sensors – an overview,’ Microelectronics Reliability, vol.126, p.114-252, 2021. DOI:10.1016/j.microrel. 2021.114252.
R. B. GmbH: ‘Inertial measurement unit.’ [Online] [last checked: 22.05.2026].




