Method, system and device for multi-protocol collaborative transmission of GPS speed data in vehicle NVH test and storage medium

Abstract

The application discloses a multi-protocol cooperative transmission method, system and device of GPS speed data in vehicle NVH testing and a storage medium, and belongs to the technical field of digital information transmission. The method bypasses the dependence on the original OBD protocol of the vehicle and a private database by constructing an independent vehicle speed data channel from the GPS satellite signal to the standard diagnostic response; the GPS module directly measures the speed based on the Doppler effect and outputs speed data with a UTC timestamp, which is encapsulated into a standard OBD-II message after protocol analysis and filtering verification by an MCU, and then transmitted to the test software through a diagnostic interface simulated by a PC end, thereby realizing non-intrusive collection and cross-device time synchronization of the speed data. The application does not need to depend on the vehicle-specific ECU or DBC file, solves the problems of poor compatibility and insufficient synchronization accuracy of the existing GPS speed data transmission protocol, and improves the generality and stability of digital information transmission in vehicle NVH testing.

Description

Technical Field

[0001] This application relates to the field of digital information transmission technology, and in particular to a multi-protocol collaborative transmission method, system, device and storage medium for GPS speed data in vehicle NVH testing. Background Technology

[0002] In scenarios such as vehicle NVH testing, performance testing, and road testing, testing software (such as PicoDiagnostics) needs to acquire GPS speed data through a stable digital communication link and perform correlation analysis between this data and multi-source test data such as vibration and noise. Its core relies on an efficient and universal data stream transmission mechanism, standardized communication protocol adaptation, and precise time synchronization technology, which belongs to the application scenario of digital information transmission.

[0003] In existing technologies, the transmission and interaction of GPS speed data mainly rely on standard signals output by the vehicle's ECU, and the data link is established through the OBD / diagnostic interface or CAN bus. This transmission scheme has the following key technical problems directly related to digital information transmission:

[0004] The CAN bus protocols and diagnostic databases (such as DBC files) of different vehicle models have private customization differences, which means that third-party testing equipment needs to develop exclusive communication adaptation modules for different vehicle models. The protocol adaptation cost of the transmission link is high and the universality is insufficient.

[0005] New energy vehicles generally implement access control or deep customization of the OBD / diagnostic interface, which makes it difficult for third-party testing equipment to connect with the vehicle's native communication network, and the transmission channel for GPS speed data cannot be stably established, affecting the effective interaction of digital data.

[0006] In traditional transmission schemes, the timestamp format of the raw GPS data is not consistent with the receiving format of the host computer test software, and there is a lack of standardized time synchronization mechanism. This leads to the accumulation of time deviations during data transmission, which cannot meet the requirements of timestamp synchronization accuracy for multi-source test data correlation analysis and reduces the effectiveness of digital information transmission.

[0007] The raw GPS data needs to undergo multiple rounds of format conversion to be compatible with the receiving protocol of the host computer testing software, which increases the probability of data transmission delay, packet loss and errors. Furthermore, the lack of link conflict detection and fault tolerance mechanisms affects the stability of digital data transmission.

[0008] Therefore, existing technologies suffer from technical problems such as poor protocol compatibility, high link adaptation costs, insufficient time synchronization accuracy, and low transmission reliability during GPS speed data transmission in vehicle NVH testing scenarios. There is an urgent need for a digital information transmission solution based on a universal communication protocol, supporting multi-scenario link adaptation, accurate time synchronization, and conflict tolerance. Summary of the Invention

[0009] The purpose of this application is to provide a multi-protocol collaborative transmission method, device, equipment and storage medium for GPS speed data in vehicle NVH testing. It solves the problems of excessive reliance on vehicle model-specific resources, poor adaptability and difficulty in signal acquisition in the prior art. It realizes non-intrusive vehicle speed acquisition without relying on the vehicle ECU, and improves the advantages of universality and testing efficiency.

[0010] This application provides a multi-protocol collaborative transmission method for GPS speed data in vehicle NVH testing, which is applied to a multi-protocol collaborative transmission system for GPS speed data in vehicle NVH testing, including a GPS module, a signal processing and packaging module MCU, a USB communication module, a PC-side software driver layer, a host computer test software, and the vehicle under test;

[0011] The ECU of the vehicle under test is electrically connected to the CAN bus harness to generate a first signal transmission channel, so that the ECU and the vehicle under test can communicate directly based on the first signal transmission channel;

[0012] The GPS module, the signal processing and packaging module MCU, the USB communication module, and the PC-side software driver layer are connected in series to form a second signal transmission channel, so that the speed data collected by the GPS module is processed by the second signal transmission channel and transmitted to the host computer test software, realizing non-intrusive data acquisition.

[0013] A multi-protocol collaborative transmission method for GPS speed data in vehicle NVH testing includes at least the following steps:

[0014] The GPS module collects satellite signals in real time, calculates vehicle speed data based on the Doppler effect, and outputs protocol data with GPS UTC timestamps simultaneously.

[0015] The signal processing and packaging module MCU receives protocol data, performs XOR verification, abnormal speed value removal and amplitude limiting filtering preprocessing on the protocol data, and parses it to obtain the effective vehicle speed data.

[0016] The USB communication module transmits the valid vehicle speed data and GPS UTC timestamp to the PC software driver layer through the binary frame structure preset by the USB communication module.

[0017] The PC-side software driver layer encapsulates the effective vehicle speed data into a standard OBD-II diagnostic response message and converts the GPS UTC timestamp into a message timestamp, which is then transmitted to the host computer test software to complete the NVH test correlation analysis.

[0018] Furthermore, the GPS module is electrically connected to the signal processing and packaging module MCU via a UART TTL interface. The signal processing and packaging module MCU is electrically connected to the USB communication module via a USB 2.0 Full Speed ​​interface. The USB communication module communicates with the PC-side software driver layer via a CDC-type virtual serial port. The PC-side software driver layer communicates with the host computer test software via a J2534 interface. The J2534 interface implemented by the PC-side software driver layer maps CAN identifiers. The request ID sent by the host computer test software is 0x7DF, the response ID of the simulated ECU response by the PC-side software driver layer is 0x7E8, and the backup response ID is 0x7E9.

[0019] Furthermore, the signal processing and packaging module (MCU) preprocesses the protocol data and parses the valid vehicle speed data, including:

[0020] The signal processing and packaging module MCU parses the ground speed data from the GPVTG statement of the NMEA-0183 protocol data, and uses the GPRMC statement of the NMEA-0183 protocol data as a backup data source.

[0021] The parsed vehicle speed data is processed for bad frame verification, amplitude limiting filtering, and satellite signal loss handling. When satellite signals are blocked, a preset IMU fusion algorithm is activated to ensure the continuity of speed output.

[0022] Based on the preprocessed vehicle speed data, valid vehicle speed data is generated.

[0023] Furthermore, the GPS module collects satellite signals and outputs data, including:

[0024] The GPS module supports multi-system joint positioning using GPS, BeiDou, and GLONASS. It measures speed based on the Doppler effect of satellite signals, and the speed measurement accuracy of the GPS module is ±0.1 km / h.

[0025] The GPS module outputs NMEA-0183 protocol data with GPS UTC timestamps. The time synchronization accuracy of the GPS UTC timestamps is ±1ms. At the same time, the GPS module outputs PPS pulse signals to provide a time reference.

[0026] Furthermore, the USB communication module transmits the valid vehicle speed data and GPS UTC timestamp to the PC software driver layer through a preset binary frame structure, including:

[0027] The USB communication module uses the CDC class to implement a virtual serial port, which supports driverless recognition on the PC.

[0028] The USB communication module transmits valid vehicle speed data and GPS UTC timestamps to the PC software driver layer according to a preset 32-byte binary frame structure.

[0029] Furthermore, the PC-side software driver layer encapsulates the effective vehicle speed data into a standard OBD-II diagnostic response message and converts the GPS UTC timestamp into a message timestamp, transmitting it to the host computer test software to complete NVH test correlation analysis, including:

[0030] The PC-side software driver layer fully implements the PassThru API, and after receiving valid vehicle speed data and GPS UTC timestamps, it encapsulates them into a standard OBD-II diagnostic response message in a preset 8-byte payload format.

[0031] When a PID list request is received from the host computer test software, a negative response is first returned with the response ID, and then a positive response that supports bitmasks is returned with the backup response ID.

[0032] When a vehicle speed PID request is received from the host computer testing software, it responds with a pre-packaged vehicle speed message.

[0033] The data update frequency of the PC software driver layer is configured to be 5-50Hz. The PC software driver layer has a native message detection function. When a valid message with the same ID is detected on the bus, it will automatically remain silent or switch to a backup response ID.

[0034] Furthermore, the PC-side software driver layer encapsulates the effective vehicle speed data into a standard OBD-II diagnostic response message, converts the GPS UTC timestamp into a message timestamp, and transmits it to the host computer test software to complete the NVH test correlation analysis, including:

[0035] The time step module of the PC software driver layer converts the GPS UTC timestamp into a J2534 message timestamp and calibrates the time of the host computer test software.

[0036] When a test completion command is detected, the non-intrusive nature of the second signal transmission channel is maintained, normal communication of the first signal transmission channel is maintained, and the original vehicle network of the vehicle under test is ensured to be free from interference.

[0037] This application also proposes a multi-protocol cooperative transmission system for GPS speed data in vehicle NVH testing, including:

[0038] The acquisition module is used to acquire satellite signals in real time, calculate vehicle speed data based on the Doppler effect, and synchronously output protocol data with GPS UTC timestamps.

[0039] The processing module is used to receive protocol data, perform XOR verification, remove abnormal speed values ​​and perform amplitude limiting filtering preprocessing on the protocol data, and parse to obtain valid vehicle speed data.

[0040] The transmission module is used to transmit the effective vehicle speed data and GPS UTC timestamp to the PC software driver layer through a preset binary frame structure.

[0041] The encapsulation module is used to encapsulate the effective vehicle speed data into a standard OBD-II diagnostic response message, convert the GPS UTC timestamp into a message timestamp, and transmit it to the host computer test software. It also realizes the collision detection and silent rollback functions.

[0042] This application also proposes a multi-protocol collaborative transmission device for GPS speed data in vehicle NVH testing, comprising: a memory, a processor, and a multi-protocol collaborative transmission program for GPS speed data in vehicle NVH testing stored in the memory and capable of running on the processor. The multi-protocol collaborative transmission program for GPS speed data in vehicle NVH testing is configured to implement the steps of the above-mentioned multi-protocol collaborative transmission method for GPS speed data in vehicle NVH testing.

[0043] This application also proposes a storage medium storing a multi-protocol collaborative transmission program for GPS speed data in vehicle NVH testing. When the multi-protocol collaborative transmission program for GPS speed data in vehicle NVH testing is executed by a processor, it implements the steps of the above-described multi-protocol collaborative transmission method for GPS speed data in vehicle NVH testing.

[0044] This application has the following beneficial effects:

[0045] This application provides a multi-protocol collaborative transmission method, apparatus, device, and storage medium for GPS speed data in vehicle NVH testing. Through non-intrusive GPS speed acquisition, the system processes and transmits vehicle speed data using a second signal transmission channel, avoiding reliance on vehicle ECUs and dedicated resources. This achieves universal vehicle speed signal acquisition and solves the problems of excessive reliance on vehicle model-specific resources, poor adaptability, and difficulty in signal acquisition in existing technologies. It realizes non-intrusive vehicle speed acquisition without relying on vehicle ECUs, improving versatility and testing efficiency. Attached Figure Description

[0046] Figure 1 A flowchart illustrating a multi-protocol collaborative transmission method for GPS speed data in vehicle NVH testing provided in this application;

[0047] Figure 2 A schematic diagram of a multi-protocol cooperative transmission system for GPS speed data in vehicle NVH testing provided in this application;

[0048] Figure 3 Another schematic diagram of the multi-protocol cooperative transmission system for GPS speed data in vehicle NVH testing provided in this application;

[0049] Figure 4 A schematic diagram illustrating the scenario of the multi-protocol cooperative transmission method for GPS speed data in vehicle NVH testing provided in this application;

[0050] Figure 5 The signal processing (MCU) schematic diagram for the multi-protocol cooperative transmission method of GPS speed data in vehicle NVH testing provided in this application;

[0051] Figure 6 This application provides a schematic diagram of the structure of a multi-protocol cooperative transmission system for GPS speed data in vehicle NVH testing;

[0052] Figure 7 This application provides a schematic diagram of the structure of a multi-protocol collaborative transmission device for GPS speed data in vehicle NVH testing. Detailed Implementation

[0053] To make the objectives, technical solutions, and advantages of this application clearer, specific embodiments of this application will be described in further detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely for explaining this application and not for limiting it. It should also be noted that, for ease of description, only the parts relevant to this application are shown in the drawings, not all of them. Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe operations (or steps) as being processed sequentially, many of these operations can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. A process can be terminated when its operation is completed, but it may also have additional steps not included in the drawings. A process can correspond to a method, function, procedure, subroutine, subroutine, etc.

[0054] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0055] In vehicle NVH testing, performance testing, and road testing scenarios, testing software needs to acquire stable and synchronized vehicle speed signals to perform correlation analysis between vibration and speed data. However, existing technologies mainly rely on vehicle speed signals output by the vehicle ECU, read through the OBD / diagnostic interface or CAN bus. This method is limited by OEMs' proprietary diagnostic databases, access control of OBD interfaces for new energy vehicles, and differences in CAN bus protocols among different vehicle models. This makes it difficult for third-party testing equipment to directly acquire vehicle speed signals, resulting in poor adaptability and insufficient universality, increasing vehicle model adaptation costs.

[0056] Based on this, such as Figures 1-5 As shown, this application provides a multi-protocol collaborative transmission method for GPS speed data in vehicle NVH testing, which is applied to a multi-protocol collaborative transmission system for GPS speed data in vehicle NVH testing, including a GPS module, a signal processing and packaging module MCU, a USB communication module, a PC-side software driver layer, a host computer test software, and the vehicle under test;

[0057] The ECU of the vehicle under test is electrically connected to the CAN bus harness to generate a first signal transmission channel, so that the ECU and the vehicle under test can communicate directly based on the first signal transmission channel;

[0058] The GPS module, the signal processing and packaging module MCU, the USB communication module, and the PC-side software driver layer are connected in series to form a second signal transmission channel, so that the speed data collected by the GPS module is processed by the second signal transmission channel and transmitted to the host computer test software, realizing non-intrusive data acquisition.

[0059] A multi-protocol collaborative transmission method for GPS speed data in vehicle NVH testing includes at least the following steps:

[0060] The S100 and GPS modules collect satellite signals in real time, calculate vehicle speed data based on the Doppler effect, and simultaneously output protocol data with GPS UTC timestamps.

[0061] S200, the signal processing and packaging module MCU receives protocol data, performs XOR verification, abnormal speed value removal and amplitude limiting filtering preprocessing on the protocol data, and parses to obtain the effective vehicle speed data;

[0062] The S300 and USB communication module transmit the effective vehicle speed data and GPS UTC timestamp to the PC software driver layer through the binary frame structure preset by the USB communication module.

[0063] The S400 and PC-side software driver layer encapsulate the effective vehicle speed data into a standard OBD-II diagnostic response message and converts the GPSUTC timestamp into a message timestamp, which is then transmitted to the host computer test software to complete the NVH test correlation analysis.

[0064] In this embodiment, the GPS module acquires satellite signals in real time. This module utilizes the physical characteristics of satellite signals, such as the Doppler effect, to calculate the vehicle's real-time speed data. Simultaneously, the GPS module outputs raw data with timestamps, which can be in any standard timestamp format, for subsequent data synchronization. For example, the GPS module can periodically output text or binary data streams containing speed and time information.

[0065] The signal processing and packaging module (MCU) receives raw data from the GPS module. This module performs a series of preprocessing operations on the received data to improve its quality and reliability. These preprocessing operations may include checking data integrity, identifying and correcting outliers, and smoothing data fluctuations. Through these processes, the raw data is converted into usable vehicle speed data. For example, the MCU can perform cyclic redundancy checks on the received data frames and truncate or replace speed values ​​that exceed reasonable limits.

[0066] The USB communication module is responsible for transmitting the valid vehicle speed data, along with its corresponding timestamp, processed by the MCU (Microcontroller Unit) signal processing and packaging module, to the PC-side software driver layer. This module organizes and packages this data according to a preset data structure and transmits it via the USB interface. For example, the USB communication module can encapsulate vehicle speed data and timestamps into fixed-length data packets and send them via USB bulk transfer mode.

[0067] The PC-side software driver layer receives data from the USB communication module. Its primary task is to convert the received valid vehicle speed data into a standard format that the host computer testing software can recognize and process. Simultaneously, the original timestamp is converted into a message timestamp compatible with the host computer testing software. This converted data is then transmitted to the host computer testing software for correlation analysis of speed and vibration data during NVH testing. For example, the PC-side software driver layer can map the received vehicle speed data to specific diagnostic parameter identifiers (PIDs) and generate response messages conforming to common diagnostic protocols.

[0068] This implementation method achieves non-intrusive, high-precision acquisition of vehicle speed signals during NVH testing by constructing an independent GPS speed acquisition system. This solution effectively avoids reliance on the vehicle ECU's proprietary diagnostic database, solves the problem of OBD / diagnostic interface access control in new energy vehicles, and eliminates compatibility issues caused by differences in CAN bus protocols across different vehicle models. Therefore, this method significantly improves the universality and convenience of vehicle speed data acquisition, reduces vehicle model adaptation costs, and ensures the accuracy and reliability of the correlation analysis between vibration and speed data in NVH testing.

[0069] In some implementations, this application provides specific communication interfaces and CAN identifier mapping schemes to optimize data transmission links and ensure system compatibility. The GPS module is electrically connected to the signal processing and packaging module MCU via a UART TTL interface. As an asynchronous serial communication protocol, the UART TTL interface, with its simple structure and low cost, ensures that the raw protocol data output by the GPS module can be efficiently and reliably transmitted serially to the signal processing and packaging module MCU, avoiding complex signal conversion processes.

[0070] The signal processing and packaging module (MCU) is electrically connected to the USB communication module via a USB 2.0 Full Speed ​​interface. The USB 2.0 Full Speed ​​interface provides a data transfer rate of 12 Mbps, which meets the real-time performance and bandwidth requirements for vehicle speed data in NVH testing. The plug-and-play and hot-swappable features of this interface also simplify hardware connections and system integration.

[0071] The USB communication module communicates with the PC-side software driver layer via a CDC-type virtual serial port. This CDC-type virtual serial port allows the USB communication module to be recognized as a standard serial device by the PC operating system when connected to the PC, eliminating the need for specific drivers and achieving driverless recognition. The PC-side software driver layer can receive data from the USB communication module by operating this virtual serial port, greatly simplifying PC-side software development and deployment, and improving system compatibility and ease of use.

[0072] The PC-side software driver layer communicates with the host computer test software via the J2534 interface. The J2534 interface is a standard defined by SAE, specifying the programming interface for communication between the PC application and the vehicle ECU. By implementing the J2534 interface, the PC-side software driver layer provides a standard and unified interface to the host computer test software. This allows the host computer test software to obtain vehicle speed data simply by calling the J2534 API, without needing to concern itself with the details of the underlying hardware and communication protocols, thus enhancing the system's openness and compatibility.

[0073] Based on this, the J2534 interface implemented by the PC-side software driver layer maps CAN identifiers. Specifically, the request ID issued by the host computer test software is 0x7DF, which is the request ID used for function addressing in the OBD-II standard. The response ID simulated by the PC-side software driver layer for the ECU response is 0x7E8, which is a commonly used ID for ECU responses in the OBD-II standard. Meanwhile, to address potential CAN bus conflicts, a backup response ID of 0x7E9 is also provided. When the host computer test software issues a 0x7DF request, the PC-side software driver layer intercepts and processes the request, and sends the encapsulated vehicle speed data to the host computer test software using 0x7E8 as its primary response ID. When other ECUs on the bus are detected responding with 0x7E8, the system can automatically switch to the backup response ID 0x7E9 to avoid conflicts and ensure reliable data transmission.

[0074] In some implementations, the signal processing and encapsulation module (MCU) preprocesses the protocol data and parses the valid vehicle speed data. Specifically, the MCU parses the ground-to-ground vehicle speed data from the GPVTG statement of the NMEA-0183 protocol data, using the GPRMC statement of the NMEA-0183 protocol data as a backup data source; performs bad frame verification, amplitude limiting filtering, and satellite loss processing on the parsed vehicle speed data; when satellite signals are blocked, a preset IMU fusion algorithm is activated to ensure the continuity of speed output; and generates the valid vehicle speed data based on the preprocessed vehicle speed data.

[0075] The signal processing and packaging module (MCU), as the core processing unit, is responsible for receiving raw protocol data from the GPS module and performing a series of processing, verification, and conversions to ultimately extract reliable vehicle speed information. Its role is to transform raw, potentially noisy, or incomplete data into "valid" data usable by subsequent systems. Typically, this MCU runs specific firmware programs containing data parsing algorithms, verification logic, filtering algorithms, and data fusion logic. These algorithms are executed through its built-in processor core, and it communicates with the GPS module via its peripheral interfaces.

[0076] Specifically, the signal processing and packaging module (MCU) parses ground speed data from the GPVTG statements in the NMEA-0183 protocol data. The NMEA-0183 protocol is a standard GPS receiver output data format, consisting of a series of statements beginning with a '$' character, each containing specific navigation or positioning information. The GPVTG statements are specifically used to provide ground speed and heading information, and the speed values ​​they contain are typically highly accurate. To improve the reliability of data acquisition, this application uses the GPRMC statements in the NMEA-0183 protocol data as a backup data source. The GPRMC statement is a recommended minimal GPS data statement containing key information such as time, date, location, speed, and heading. When the GPVTG statement becomes unavailable or corrupted for some reason, the signal processing and packaging module (MCU) switches to the GPRMC statement, extracting the speed data as a backup, thus ensuring continuous acquisition of speed information. The signal processing and packaging module (MCU) parses the NMEA-0183 protocol data stream, identifies the start and end markers of the GPVTG and GPRMC statements, and extracts the corresponding speed fields according to the protocol specifications.

[0077] After parsing the vehicle speed data, the signal processing and packaging module (MCU) further performs bad frame verification, amplitude limiting filtering, and satellite loss handling on this data. Bad frame verification aims to check the integrity and correctness of the received NMEA-0183 statement, for example, by checking and verifying whether the data was corrupted or erroneous during transmission. If the verification fails, the frame is considered bad and discarded or marked as invalid. Amplitude limiting filtering sets reasonable upper and lower limits for the parsed vehicle speed data. For example, a vehicle speed cannot accelerate from 0 to 200 km / h instantaneously, nor can it have a negative value. When the vehicle speed data exceeds a preset physical or logical range, it is limited to a reasonable range or marked as an outlier for processing to eliminate obvious measurement errors or instantaneous spikes. Satellite loss handling refers to the system's ability to recognize a "satellite loss" state when the GPS module reports insufficient satellites, decreased positioning accuracy, or complete loss of satellite signals. In a satellite loss state, the speed data output by the GPS module may be unreliable or completely missing; the satellite loss handling mechanism triggers subsequent compensation measures.

[0078] When satellite signals are blocked, such as when a vehicle is driving in a tunnel, a canyon surrounded by tall buildings, or an underground parking lot, GPS signals are obstructed, causing the GPS module to be unable to receive satellite signals normally or to receive signals of extremely poor quality. In this case, the signal processing and packaging module (MCU) will activate a preset IMU fusion algorithm to ensure the continuity of speed output. An IMU (Inertial Measurement Unit) typically includes an accelerometer and a gyroscope, which can measure the vehicle's linear acceleration and angular velocity. When GPS signals are unavailable, the IMU fusion algorithm uses the inertial data provided by the IMU sensors, combined with the vehicle's motion model, and estimates the vehicle's speed and position using algorithms such as Kalman filtering. This fusion algorithm can compensate for the loss of speed data during GPS signal interruptions, thereby ensuring the continuity and smoothness of speed output. The preset algorithm means that the algorithm is embedded in the MCU and automatically activated under specific conditions. After the above series of steps including parsing, verification, filtering, satellite loss handling, and IMU fusion, the final data output by the signal processing and packaging module (MCU) is the "valid vehicle speed data".

[0079] Through the above implementation, after receiving the protocol data output by the GPS module, the signal processing and packaging module MCU can prioritize parsing ground speed data from the GPVTG statement of the NMEA-0183 protocol. When GPVTG data is unavailable, the GPRMC statement serves as a backup data source, thereby improving the reliability of the speed data source. Simultaneously, by performing bad frame verification, amplitude limiting filtering, and satellite loss processing on the parsed speed data, interference from data transmission errors, abnormal measurements, and poor satellite signals is effectively eliminated, significantly improving the accuracy and stability of the speed data. Especially in harsh environments such as satellite signal obstruction, by enabling the preset IMU fusion algorithm, speed can be estimated using data from the inertial measurement unit, effectively compensating for data loss caused by GPS signal interruptions and ensuring the continuity of speed output. These refined preprocessing and data fusion mechanisms make the final generated effective speed data more accurate, stable, and continuous, providing high-quality, high-reliability speed input for NVH test correlation analysis by the host computer testing software. This avoids test interruptions or result deviations caused by speed data quality issues, thereby improving the overall efficiency and accuracy of NVH testing.

[0080] In some implementations, the GPS module acquires satellite signals and outputs data in ways that include: the GPS module is designed to simultaneously receive and process signals from multiple Global Navigation Satellite Systems (GNSS), such as the US Global Positioning System (GPS), China's BeiDou Navigation Satellite System (BDS), and Russia's GLONASS system. By integrating multi-band receivers and advanced signal processing algorithms, the module can utilize more visible satellites for positioning and velocity calculations. This multi-satellite joint positioning technology significantly improves the availability and coverage of satellite signals, especially in environments with limited or obstructed signals, thereby enhancing the continuity and reliability of velocity measurement data.

[0081] This GPS module uses the Doppler effect to accurately measure the instantaneous speed of a vehicle. Specifically, the module analyzes the change in the frequency of the received satellite signal relative to its transmission frequency (i.e., the Doppler shift), and combines this with precise satellite orbit information to calculate the receiver's velocity component relative to the satellite in real time. By comprehensively calculating the velocity components of multiple satellites, the vehicle's three-dimensional speed can be determined with high precision. Compared to methods that calculate speed based on position difference, Doppler velocimetry offers higher instantaneous accuracy and faster response speed.

[0082] This GPS module achieves a speed measurement accuracy of ±0.1 km / h. This high precision is achieved through a combination of technologies, including but not limited to using a high-sensitivity GNSS receiver chip, optimizing multi-galaxy joint positioning algorithms, and implementing sophisticated signal filtering and error correction techniques. High-precision speed measurement is crucial for accurately depicting the vehicle's operating status in NVH testing.

[0083] The GPS module outputs its collected data according to the NMEA-0183 standard protocol format, embedding a precise GPS Coordinated Universal Time (UTC) timestamp within the data. The NMEA-0183 protocol is a standard data format widely used in marine electronic equipment and GPS receivers. It defines various statement types to transmit information such as position, speed, and time. The GPS UTC timestamp provides a globally unified and highly accurate time reference, ensuring that all collected speed data has traceable and synchronized time information.

[0084] The GPS UTC timestamp output by this GPS module has a time synchronization accuracy of ±1ms. This means that the deviation between the module's internal clock and the globally unified UTC time is strictly controlled within 1 millisecond. This high-precision time synchronization is crucial for accurately correlating vehicle speed data with data from other sensors (such as vibration and noise sensors) in NVH testing. It can effectively eliminate analysis errors introduced by time asynchrony and ensure the alignment of multi-source data on the time axis.

[0085] In addition to embedding timestamps in the protocol data, this GPS module also outputs a pulse-per-second (PPS) signal via a dedicated hardware pin. The PPS signal is a square wave pulse with a period of 1 second, whose rising or falling edge is precisely aligned to the start of each second (typically the start of a UTC second). This high-precision physical pulse signal can serve as a reference for hardware-level time synchronization of external devices (such as signal processing and packaging modules like MCUs), further improving the overall system's time synchronization accuracy and reliability, making it particularly suitable for applications requiring extremely high time synchronization precision.

[0086] In some implementations, the USB communication module transmits the effective vehicle speed data and GPS UTC timestamp to the PC software driver layer through a preset binary frame structure. Specifically, the USB communication module uses a CDC class to implement a virtual serial port, supporting driverless recognition by the PC. The USB communication module transmits the effective vehicle speed data and GPS UTC timestamp to the PC software driver layer according to a preset 32-byte binary frame structure.

[0087] Specifically, the USB communication module uses the CDC (Communication Device Class) to implement a virtual serial port. The CDC class is a device class defined in the USB standard, whose main function is to allow USB devices to emulate traditional serial ports (such as RS-232), enabling applications on the PC to communicate with the USB device through a standard serial port interface (such as a COM port). When the USB communication module is connected to the PC, the PC operating system automatically recognizes it as a CDC device and loads the built-in CDC driver, eliminating the need for the user to manually install additional drivers, thus achieving driverless recognition on the PC side. This design greatly simplifies the device installation and deployment process, lowers the user's barrier to entry, and improves the system's compatibility across different PC operating system environments.

[0088] Based on this, the USB communication module transmits the valid vehicle speed data and GPS UTC timestamp to the PC-side software driver layer according to a preset 32-byte binary frame structure. This preset 32-byte binary frame structure aims to ensure the efficiency, reliability, and ease of parsing of data transmission. In actual operation, after receiving the valid vehicle speed data and GPS UTC timestamp processed by the signal processing and encapsulation module MCU, the USB communication module packages this data according to a predefined 32-byte frame format. For example, this frame structure may include a specific frame header for synchronization and identifying the start of the frame, a frame sequence number for detecting the order and integrity of the data packets, a field for carrying the valid vehicle speed data and GPS UTC timestamp, and a checksum field for data integrity checking. After encapsulation, these 32-byte binary frames are sent to the PC-side software driver layer through a virtual serial port interface. After receiving the data stream, the PC-side software driver layer can efficiently and accurately parse the valid vehicle speed data and GPS UTC timestamp according to the preset frame header and frame structure, and verify the integrity of the data through the checksum.

[0089] In some implementations, the PC-side software driver layer encapsulates the effective vehicle speed data into a standard OBD-II diagnostic response message and converts the GPS UTC timestamp into a message timestamp, transmitting it to the host computer test software to complete the NVH test correlation analysis. This PC-side software driver layer fully implements the PassThru API, receiving the effective vehicle speed data and GPS UTC timestamp, and encapsulating it into a standard OBD-II diagnostic response message in a preset 8-byte payload format. When a PID list request is received from the host computer test software, a negative response is first returned with a response ID, followed by a positive response supporting bitmasks with a backup response ID. When a vehicle speed PID request is received from the host computer test software, a packaged vehicle speed message is responded to. The data update frequency of the PC-side software driver layer is configured to 5-50Hz. The PC-side software driver layer has a native message detection function; when a valid message with the same ID is detected on the bus, it automatically silences or switches to the backup response ID.

[0090] Specifically, the PC-side software driver layer fully implements the PassThru API, meaning it can simulate a diagnostic device compliant with the J2534 standard. As a standardized interface specification, the PassThru API allows the host computer testing software to communicate with the vehicle's ECU through a unified interface, thus abstracting the details of the underlying hardware and communication protocols. By fully implementing this API, the system enables the host computer testing software to send diagnostic requests and receive responses without requiring special adaptation for this system, thereby improving system compatibility and ease of use.

[0091] Upon receiving valid vehicle speed data and a GPS UTC timestamp, the PC-side software driver layer encapsulates them into a standard OBD-II diagnostic response message with a preset 8-byte payload format. The standard OBD-II diagnostic message has a specific frame structure, including a message ID, data length, service ID, PID, and data payload. The preset 8-byte payload format ensures that the encapsulated vehicle speed data and timestamp meet the OBD-II protocol's data length requirements and can be correctly parsed by the host computer testing software. For example, the vehicle speed data can be encoded as 2 bytes, the timestamp as 4 bytes, and the remaining bytes can be used for other identifiers or padding to meet the 8-byte payload requirement.

[0092] To enable effective diagnostic communication with the host computer testing software, when the PC-side software driver layer receives a PID list request from the host computer testing software, it first returns a negative response with a response ID, and then returns a positive response with a backup response ID that supports the bitmask. The host computer testing software typically sends a PID list request at startup to query which data items the ECU supports. Returning a negative response first avoids conflicts with the response IDs of the actual ECUs in the vehicle, or indicates that the currently simulated ECU does not directly support all standard PIDs. Subsequently, a positive response supporting the bitmask is returned with the backup response ID, explicitly informing the host computer testing software which specific PIDs, such as the vehicle speed PID, the system supports. This mechanism allows the host computer testing software to recognize that the system exists as an independent "ECU" and knows which data it can request.

[0093] When the PC-side software driver layer receives a vehicle speed PID request from the host computer testing software, it immediately responds with a pre-packaged vehicle speed message. Once the host computer testing software learns through the PID list request that the system supports vehicle speed PID, it sends a specific vehicle speed PID request. Upon receiving this request, the PC-side software driver layer sends a pre-packaged OBD-II diagnostic response message containing valid vehicle speed data and a GPS UTC timestamp to the host computer testing software, ensuring that the host computer testing software can obtain real-time GPS vehicle speed data in the expected manner.

[0094] Furthermore, the data update frequency of the PC-side software driver layer is configured to 5-50Hz. The data update frequency directly affects the real-time performance and accuracy of NVH testing, which typically requires high-frequency data sampling to capture the dynamic characteristics of vehicle vibration and noise. Configuring the update frequency within the 5-50Hz range allows users to flexibly adjust it according to specific testing needs and the processing capabilities of the host computer testing software, providing denser vehicle speed data points or meeting general monitoring requirements.

[0095] To ensure the system's non-intrusiveness, the PC-side software driver layer possesses native message detection capabilities. This function enables the PC-side software driver layer to monitor all messages on the CAN bus in real time and identify the message ID and content. When a valid message with the same ID is detected on the bus, the PC-side software driver layer can automatically silence or switch to the backup response ID. If the PC-side software driver layer discovers that another ECU on the bus is sending a valid message with the same response ID as the simulated ECU in this system, this indicates an ID conflict. In this case, the PC-side software driver layer will stop using the conflicting response ID to send messages to avoid interfering with the vehicle's original communication (silence), or switch to using a preset backup response ID to send data, allowing the host computer test software to continue acquiring data through the backup ID without interrupting the test.

[0096] In some implementations, the effective vehicle speed data is encapsulated into a standard OBD-II diagnostic response message at the PC-side software driver layer, and the GPS UTC timestamp is converted into a message timestamp. After being transmitted to the host computer test software to complete the NVH test correlation analysis, the time step module of the PC-side software driver layer converts the GPS UTC timestamp into a J2534 message timestamp and calibrates the time of the host computer test software. When a test completion command is detected, the non-intrusive characteristics of the second signal transmission channel are maintained, the normal communication of the first signal transmission channel is maintained, and the original vehicle network of the vehicle under test is ensured to be free from interference.

[0097] Specifically, the time step module in the PC-side software driver layer is a dedicated functional unit responsible for timestamp processing and synchronization. This module receives GPS UTC timestamps from the USB communication module and converts them into message timestamp formats conforming to the J2534 standard interface specification. This conversion typically involves adjusting the time format, such as mapping GPS UTC time (usually in seconds or milliseconds) to relative time counts defined in the J2534 standard, to ensure that the host computer test software can correctly parse and utilize this time information. This conversion enables precise time alignment between GPS speed data and other NVH test data (such as vibration and noise data) in the host computer test software. Simultaneously, the time step module is also responsible for calibrating the time in the host computer test software. This can be achieved by periodically sending calibration timestamps to the host computer test software or by providing an API interface for the host computer test software to actively query the current precise time, thereby ensuring the consistency of the time base throughout the entire test chain and avoiding data association errors caused by time drift or inconsistency between different devices.

[0098] Furthermore, this application also considers the system behavior after the test is completed. When the PC-side software driver layer or the host computer test software detects the "test complete" command issued by the user, the system will execute a series of safe exit operations. First, the system will maintain the non-intrusive nature of the second signal transmission channel. This means that the GPS speed acquisition system will not send any write commands or messages that may affect the normal function of the vehicle to the ECU or CAN bus of the vehicle under test throughout the entire test process and after the test; it always exists as a data listener and outputter. Second, the system will maintain normal communication of the first signal transmission channel. The first signal transmission channel is the electrical connection between the ECU of the vehicle under test and the CAN bus harness, used for direct communication between the vehicle's own ECU and the vehicle. After the test is completed, the PC-side software driver layer will stop simulating ECU response messages and release the J2534 interface resources to ensure that it no longer occupies or interferes with any communication on the CAN bus, thereby ensuring that the vehicle ECU can continue to communicate normally with other components of the vehicle and execute its control functions. Finally, through the above measures, it is ensured that the original vehicle network of the vehicle under test is free from interference. This means that after the test, the data stream, communication protocol, timing, etc. of the entire vehicle's CAN network (or other vehicle network) should remain in their original state, without any abnormal messages, delays, or functional impairments.

[0099] The methods of the embodiments of this application have been described in detail above, and the apparatus of the embodiments of this application is provided below.

[0100] like Figure 6 As shown, this embodiment provides a multi-protocol cooperative transmission system for GPS speed data in vehicle NVH testing, including:

[0101] The acquisition module 100 is used to acquire satellite signals in real time, calculate vehicle speed data based on the Doppler effect, and synchronously output protocol data with GPS UTC timestamps.

[0102] Processing module 200 is used to receive the protocol data, perform XOR verification, abnormal speed value removal and amplitude limiting filtering preprocessing on the protocol data, and parse to obtain effective vehicle speed data;

[0103] The transmission module 300 is used to transmit the effective vehicle speed data and GPS UTC timestamp to the PC software driver layer through a preset binary frame structure.

[0104] The encapsulation module 400 is used to encapsulate the effective vehicle speed data into a standard OBD-II diagnostic response message, convert the GPS UTC timestamp into a message timestamp, and transmit it to the host computer test software. It also realizes the collision detection and silent rollback functions.

[0105] It should be noted that in some embodiments, the functions or modules of the apparatus provided in this application can be used to execute the methods described in the above method embodiments. The specific implementation can be referred to the description of the above method embodiments, and for the sake of brevity, it will not be repeated here.

[0106] like Figure 7 As shown, this application proposes a multi-protocol cooperative transmission device for GPS speed data in vehicle NVH testing. The device includes a memory 10, a processor 20, and a multi-protocol cooperative transmission program 30 for GPS speed data in vehicle NVH testing, stored in the memory and executable on the processor. The multi-protocol cooperative transmission program for GPS speed data in vehicle NVH testing is configured to implement the steps of the aforementioned multi-protocol cooperative transmission method for GPS speed data in vehicle NVH testing.

[0107] The memory is a hardware component used to store data and instructions, and may include, but is not limited to, random access memory (RAM), read-only memory (ROM), flash memory, or hard disk drive. In the multi-protocol collaborative transmission device for GPS speed data in the vehicle NVH test, the memory is mainly used to store the multi-protocol collaborative transmission program for GPS speed data in the vehicle NVH test, as well as temporary data, configuration parameters, and processing results generated during program execution. Through the memory, the processor can quickly access the required program instructions and data, thereby ensuring the smooth execution of the GPS speed acquisition method.

[0108] The processor is the core computing unit of the multi-protocol collaborative transmission device for GPS speed data in the vehicle NVH test, responsible for executing the multi-protocol collaborative transmission program for GPS speed data in the vehicle NVH test stored in the memory. The processor can be a microcontroller (MCU), a central processing unit (CPU), or a digital signal processor (DSP), possessing the ability to execute instructions, perform arithmetic and logic operations, control data flow, and manage device resources. By executing the program, the processor can coordinate the work of components such as the GPS module, the signal processing and packaging module (MCU), and the USB communication module, and complete the various data processing and transmission tasks defined in the GPS speed acquisition method.

[0109] The multi-protocol collaborative transmission program for GPS speed data in vehicle NVH testing is a set of computer-executable instructions designed to implement all or part of the steps of the aforementioned multi-protocol collaborative transmission method for GPS speed data in vehicle NVH testing. This program, in the form of software code, enables the GPS module to acquire satellite signals in real time, calculate vehicle speed data based on the Doppler effect, and synchronously output protocol data with a GPS UTC timestamp. The signal processing and encapsulation module (MCU) receives the protocol data, performs XOR verification, abnormal speed value removal, and amplitude limiting filtering preprocessing on the protocol data, and parses it to obtain valid vehicle speed data. The USB communication module transmits the valid vehicle speed data and the GPS UTC timestamp to the PC-side software driver layer through a preset binary frame structure. The PC-side software driver layer encapsulates the valid vehicle speed data into a standard OBD-II diagnostic response message and converts the GPS UTC timestamp into a message timestamp, transmitting it to the host computer testing software to complete a series of operations, including NVH test correlation analysis. When the processor executes this program, it can automatically complete all the functions specified by the GPS speed acquisition method.

[0110] The multi-protocol collaborative transmission program for GPS speed data in vehicle NVH testing is configured to implement the steps of the aforementioned multi-protocol collaborative transmission method for GPS speed data in vehicle NVH testing. This means that the design and implementation of the program strictly follow the logical flow and technical requirements of the method. Specifically, the program includes instructions for controlling the GPS module to acquire data, algorithms for performing data preprocessing and parsing in the signal processing and encapsulation module MCU, a protocol stack for controlling the USB communication module to transmit data, and logic for data encapsulation and timestamp conversion in the PC-side software driver layer. This configuration ensures that the device can accurately and efficiently transform the method from a concept into a practically operable function, thereby providing stable and reliable GPS speed data for vehicle NVH testing.

[0111] This application proposes a storage medium storing a multi-protocol collaborative transmission program for GPS speed data in vehicle NVH testing. When the multi-protocol collaborative transmission program for GPS speed data in vehicle NVH testing is executed by a processor, it implements the steps of the above-described multi-protocol collaborative transmission method for GPS speed data in vehicle NVH testing.

[0112] Specifically, the storage medium refers to a physical carrier capable of storing digital data or programs. It can be a volatile storage medium, such as random access memory (RAM), used for temporary storage of program instructions and data; or a non-volatile storage medium, such as read-only memory (ROM), flash memory, hard disk drive (HDD), solid-state drive (SSD), optical disc (CD / DVD / Blu-ray Disc), or USB flash drive, used for long-term storage of program code and configuration data. In practical applications, this storage medium is typically integrated into a multi-protocol collaborative transmission system for GPS speed data in vehicle NVH testing, for example, as the internal flash memory of the signal processing and packaging module (MCU). The multi-protocol collaborative transmission program for GPS speed data in vehicle NVH testing is a set of computer-executable instructions designed to implement all or part of the steps of the aforementioned multi-protocol collaborative transmission method for GPS speed data in vehicle NVH testing. This program typically exists in software form and may include various functional modules for controlling GPS module data acquisition, MCU data preprocessing, USB communication module data transmission, PC-side software driver layer data encapsulation and interface communication, and interaction with the host computer testing software. This program ensures the automated and standardized execution of the above methods, thereby reducing the complexity and potential errors of manual operation. Processor execution refers to the process by which one or more central processing units (CPUs) or microcontrollers (MCUs) read and operate according to the instructions in the multi-protocol collaborative transmission program for GPS speed data in the vehicle NVH test. By executing these instructions, the processor can control the hardware components in the system (such as GPS modules and USB communication modules) to perform data acquisition and transmission, and execute logical operations such as data processing (such as XOR verification, filtering, and encapsulation). The processor's execution capability is key to achieving the automation and real-time performance of the above methods, ensuring smooth data flow and correct processing logic.

[0113] The above description is merely a preferred embodiment and the technical principles employed in this application. This application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions that can be made by those skilled in the art will not depart from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of this application. The scope of this application is determined by the scope of the claims.

Claims

1. A multi-protocol cooperative transmission method for GPS speed data in vehicle NVH testing, characterized in that, A multi-protocol collaborative transmission system for GPS speed data used in vehicle NVH testing, comprising a GPS module, a signal processing and packaging module (MCU), a USB communication module, a PC-side software driver layer, host computer testing software, and the vehicle under test; The ECU of the vehicle under test is electrically connected to the CAN bus harness to generate a first signal transmission channel, so that the ECU and the vehicle under test can communicate directly based on the first signal transmission channel. The GPS module, the signal processing and packaging module MCU, the USB communication module, and the PC-side software driver layer are connected in series to form a second signal transmission channel, so that the speed data collected by the GPS module is processed by the second signal transmission channel and transmitted to the host computer test software, thereby realizing non-intrusive data acquisition. The multi-protocol cooperative transmission method for GPS speed data in vehicle NVH testing includes at least the following steps: The GPS module collects satellite signals in real time, calculates vehicle speed data based on the Doppler effect, and synchronously outputs protocol data with GPS UTC timestamps. The signal processing and encapsulation module (MCU) receives the protocol data and performs XOR verification, abnormal speed value removal, and amplitude limiting filtering preprocessing on the protocol data. During the preprocessing process, when satellite signal obstruction triggers satellite loss processing, the signal processing and encapsulation module (MCU) activates a preset Kalman filter IMU fusion algorithm. It estimates the vehicle speed by combining the linear acceleration and angular velocity data from the IMU sensor with the vehicle motion model, ensuring continuous speed output and parsing to obtain valid vehicle speed data, including: The signal processing and packaging module MCU parses the ground speed data from the GPVTG statement of the NMEA-0183 protocol data, and uses the GPRMC statement of the NMEA-0183 protocol data as a backup data source. The parsed vehicle speed data is processed for bad frame verification, amplitude limiting filtering, and satellite signal loss handling. When satellite signals are blocked, a preset IMU fusion algorithm is activated to ensure the continuity of speed output. Based on the preprocessed vehicle speed data, the effective vehicle speed data is generated; the USB communication module transmits the effective vehicle speed data and GPS UTC timestamp to the PC-side software driver layer through a preset binary frame structure, including: the USB communication module uses a CDC class to implement a virtual serial port, supporting driverless recognition on the PC side; the USB communication module transmits the effective vehicle speed data and GPS UTC timestamp to the PC-side software driver layer according to a preset 32-byte binary frame structure; the PC-side software driver layer encapsulates the effective vehicle speed data into a standard OBD-II diagnostic response message, converts the GPS UTC timestamp into a message timestamp, and transmits it to the host computer test software to complete NVH test correlation analysis, including: The PC-side software driver layer fully implements the PassThru API. After receiving the valid vehicle speed data and GPS UTC timestamp, it encapsulates them into a standard OBD-II diagnostic response message in a preset 8-byte payload format. The vehicle speed data is encoded as 2 bytes, the GPS UTC timestamp is encoded as 4 bytes, and the remaining bytes are used for identification and padding. Then, the GPS UTC timestamp is converted into a message timestamp. The time step module of the PC-side software driver layer periodically sends calibration timestamps to the host computer test software and provides an API interface for the host computer test software to actively query the current accurate time, thereby accurately calibrating the time of the host computer test software. When a PID list request is received from the host computer test software, a negative response is first returned with the response ID, and then a positive response that supports bitmasks is returned with the backup response ID. When a vehicle speed PID request is received from the host computer testing software, it responds with an encapsulated vehicle speed message. The data update frequency of the PC-side software driver layer is configured to be 5-50Hz. The PC-side software driver layer has a native message detection function. When a valid message with the same ID is detected on the bus, it automatically silences or switches to the backup response ID.

2. The multi-protocol cooperative transmission method for GPS speed data in vehicle NVH testing as described in claim 1, characterized in that, The GPS module is electrically connected to the signal processing and packaging module MCU via a UART TTL interface. The signal processing and packaging module MCU is electrically connected to the USB communication module via a USB 2.0 Full Speed ​​interface. The USB communication module communicates with the PC-side software driver layer via a CDC-type virtual serial port. The PC-side software driver layer communicates with the host computer test software via a J2534 interface. The J2534 interface implemented by the PC-side software driver layer maps CAN identifiers. The request ID issued by the host computer test software is 0x7DF, the response ID of the simulated ECU response by the PC-side software driver layer is 0x7E8, and the backup response ID is 0x7E9.

3. The multi-protocol cooperative transmission method for GPS speed data in vehicle NVH testing as described in claim 1, characterized in that, The GPS module acquires satellite signals and outputs data, including: The GPS module supports multi-star joint positioning of GPS, BeiDou and GLONASS, and performs speed measurement based on the Doppler effect of satellite signals. The speed measurement accuracy of the GPS module is ±0.1km / h. The GPS module outputs NMEA-0183 protocol data with GPS UTC timestamps. The time synchronization accuracy of the GPS UTC timestamps is ±1ms. At the same time, the GPS module outputs PPS pulse signals to provide a time reference.

4. The multi-protocol cooperative transmission method for GPS speed data in vehicle NVH testing as described in claim 1, characterized in that, The PC-side software driver layer encapsulates the effective vehicle speed data into a standard OBD-II diagnostic response message, converts the GPS UTC timestamp into a message timestamp, and transmits it to the host computer test software to complete the NVH test correlation analysis, including: The time step module of the PC-side software driver layer converts the GPS UTC timestamp into a J2534 message timestamp and calibrates the time of the host computer test software. When a test completion command is detected, the non-intrusive nature of the second signal transmission channel is maintained, normal communication of the first signal transmission channel is maintained, and the original vehicle network of the vehicle under test is ensured to be free from interference.

5. A multi-protocol cooperative transmission system for GPS speed data in vehicle NVH testing, characterized in that, include: The GPS module is used to acquire satellite signals in real time, calculate vehicle speed data based on the Doppler effect, and synchronously output protocol data with GPS UTC timestamps. The signal processing and packaging module (MCU) receives the protocol data and performs XOR verification, abnormal speed value removal, and amplitude limiting filtering preprocessing on the protocol data. During the preprocessing, when satellite signal obstruction triggers satellite loss processing, a preset Kalman filter IMU fusion algorithm is activated. The vehicle speed is estimated by combining the linear acceleration and angular velocity data from the IMU sensor with the vehicle motion model to ensure the continuity of speed output. The effective vehicle speed data is then parsed and obtained, including: The signal processing and packaging module MCU parses the ground speed data from the GPVTG statement of the NMEA-0183 protocol data, and uses the GPRMC statement of the NMEA-0183 protocol data as a backup data source. The parsed vehicle speed data is processed for bad frame verification, amplitude limiting filtering, and satellite signal loss handling. When satellite signals are blocked, a preset IMU fusion algorithm is activated to ensure the continuity of speed output. The effective vehicle speed data is generated based on the preprocessed vehicle speed data; The USB communication module is used to transmit the effective vehicle speed data and GPS UTC timestamp to the PC software driver layer through a preset binary frame structure. The USB communication module uses the CDC class to implement a virtual serial port, which supports driverless recognition on the PC. The USB communication module transmits the effective vehicle speed data and GPS UTC timestamp to the PC software driver layer according to a preset 32-byte binary frame structure. The PC-side software driver layer is used to encapsulate the effective vehicle speed data into a standard OBD-II diagnostic response message, convert the GPS UTC timestamp into a message timestamp, and transmit it to the host computer test software. It also implements collision detection and silent rollback functions, including: The PC-side software driver layer fully implements the PassThru API. After receiving the valid vehicle speed data and GPS UTC timestamp, it encapsulates them into a standard OBD-II diagnostic response message in a preset 8-byte payload format. The vehicle speed data is encoded as 2 bytes, the GPS UTC timestamp is encoded as 4 bytes, and the remaining bytes are used for identification and padding. Then, the GPS UTC timestamp is converted into a message timestamp. The time step module of the PC-side software driver layer periodically sends calibration timestamps to the host computer test software and provides an API interface for the host computer test software to actively query the current accurate time, thereby accurately calibrating the time of the host computer test software. When a PID list request is received from the host computer test software, a negative response is first returned with the response ID, and then a positive response that supports bitmasks is returned with the backup response ID. When a vehicle speed PID request is received from the host computer testing software, it responds with an encapsulated vehicle speed message. The data update frequency of the PC-side software driver layer is configured to be 5-50Hz. The PC-side software driver layer has a native message detection function. When a valid message with the same ID is detected on the bus, it automatically silences or switches to the backup response ID.

6. A multi-protocol collaborative transmission device for GPS speed data in vehicle NVH testing, characterized in that, include: The system includes a memory, a processor, and a multi-protocol collaborative transmission program for GPS speed data in vehicle NVH testing, stored on the memory and executable on the processor. The multi-protocol collaborative transmission program for GPS speed data in vehicle NVH testing is configured to implement the steps of the multi-protocol collaborative transmission method for GPS speed data in vehicle NVH testing as described in any one of claims 1 to 4.

7. A storage medium, characterized in that, The storage medium stores a multi-protocol collaborative transmission program for GPS speed data in vehicle NVH testing. When the processor executes the multi-protocol collaborative transmission program for GPS speed data in vehicle NVH testing, it implements the steps of the multi-protocol collaborative transmission method for GPS speed data in vehicle NVH testing as described in any one of claims 1 to 4.

Images