A PC-to-Android device large file high-speed transmission method and device based on a serial port protocol

Abstract

The application provides a PC-to-Android device large file high-speed transmission method and device based on a serial port protocol, and applies to the technical field of data processing. The application is a PC-to-Android device serial port large file high-speed transmission scheme, which receives transmission requirements and serial port basic configurations first, generates protocol starting and dynamic resource configuration settings; then starts LZ4 real-time compression and hybrid verification according to the settings, obtains file initial blocks and serial port rate original data; then processes the data by using pre-stored rules, generates standard compression blocks and rate comparison benchmarks; then generates rate adjustment signals and verification adaptation information according to baud rate negotiation rules, generates verification levels and control operation information in combination with hardware states; finally, transmission actions are converted by transmission requirements and error code feedback, classified information is extracted, adaptation parameters and calibration rules are generated, the problems of low efficiency, redundancy and the like of a traditional serial port are solved, and transmission efficiency and reliability are improved.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method and device for high-speed transmission of large files from a PC to an Android device based on a serial port protocol. Background Technology

[0002] Existing PC-to-Android device large file transfer solutions based on serial port protocols have significant technical flaws, failing to meet the demands for efficient and reliable transmission. Traditional solutions lack optimized block strategies for different file types, resulting in fixed block sizes and poor compatibility between text and binary file transmission. Compression mechanisms lack specificity, failing to select efficient algorithms tailored to the characteristics of serial port transmission, leading to high data redundancy and low transmission efficiency. Baud rates are mostly fixed values, unable to be dynamically adjusted according to transmission status, easily resulting in packet loss or stuttering due to rate mismatch. Verification mechanisms are simplistic, relying on only a single level of verification, making it difficult to balance verification accuracy and computational overhead, and insufficiently guaranteeing data integrity. Furthermore, the lack of a linkage mechanism between transmission parameters and serial port hardware resources and file specifications leads to unreasonable resource consumption, poor compatibility, and an inability to adapt to the needs of large file transfer in various scenarios.

[0003] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore includes information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0004] According to one aspect of this application, a method for high-speed large file transfer from a PC to an Android device based on a serial port protocol is provided, comprising: receiving a large file transfer request command from the PC to the Android device and basic serial port communication configuration information, generating basic setting information for the start of the transfer protocol and dynamic resource configuration; based on the transfer protocol start command and dynamic resource configuration settings, starting the LZ4 real-time compression function and triggering the hybrid verification mechanism to be enabled, generating initial file block information and raw data of the real-time serial port transmission rate; receiving a pre-stored block compression pipeline protocol and rate data processing rules, processing the initial file block information and the raw data of the real-time serial port transmission rate, and generating standard compressed data block information and transmission rate ratio. The system processes the baseline information, comparing the standard compressed data block information with the transmission rate based on dynamic baud rate negotiation rules, to generate rate adjustment signals and verification mechanism adaptation information. It then processes the verification mechanism adaptation information with the device serial port hardware resource status information to generate mixed verification levels and file transfer specification matching control operation information. Based on preset large file transfer mode operation requirements and real-time bit error rate feedback, the control operation information is transformed into actual file transfer actions. The system extracts and classifies the transmission mode requirements, bit error rate feedback, control operation information, and serial port hardware attributes to generate transmission mode adaptation parameters, rate calibration rules, resource occupancy thresholds, and file transfer and serial port protocol linkage mapping information.

[0005] Another aspect of this application discloses a high-speed large file transfer device from a PC to an Android device based on a serial port protocol, comprising: an acquisition module, configured to receive a large file transfer request command from the PC to the Android device and basic serial port communication configuration information, and generate basic setting information for the transmission protocol startup and dynamic resource configuration; a processing module, configured to, based on the transmission protocol startup command and dynamic resource configuration settings, start the LZ4 real-time compression function and trigger the hybrid verification mechanism, and generate initial file block information and raw data of the serial port real-time transmission rate; receive a pre-stored block compression pipeline protocol and rate data processing rules, process the initial file block information and raw data of the serial port real-time transmission rate, and generate standard compressed data block information and... The system compares transmission rate benchmark information; it processes standard compressed data block information with transmission rate benchmark information based on dynamic baud rate negotiation rules to generate rate adjustment signals and verification mechanism adaptation information; it processes verification mechanism adaptation information and device serial port hardware resource status information to generate mixed verification level and file transmission specification matching control operation information; based on preset large file transmission mode operation requirements and real-time bit error rate feedback, it transforms control operation information into actual file transmission actions, extracts and classifies transmission mode requirements, bit error rate feedback, control operation information and serial port hardware attributes, and generates transmission mode adaptation parameters, rate calibration rules, resource occupancy thresholds, and file transmission and serial port protocol linkage mapping information.

[0006] According to another aspect of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a second processor, implements the above-described method for high-speed large file transfer from a PC to an Android device based on a serial port protocol.

[0007] This application provides a method and device for high-speed large file transfer from a PC to an Android device based on a serial port protocol. Addressing the pain points of large file transfer between PCs and Android devices via serial ports, the server first receives the transmission request and serial port configuration, generating protocol startup and resource configuration settings; it then initiates LZ4 real-time compression and hybrid verification, generating adaptive blocks and raw rate data based on file type; after processing with pre-stored rules, it obtains standard compressed blocks and rate comparison benchmarks; through dynamic baud rate negotiation, it generates rate adjustment signals and verification adaptation information, determining the hybrid verification level and control operation information based on hardware status; finally, based on transmission mode requirements and error feedback, it transforms these into transmission actions and generates adaptation parameters, calibration rules, etc. This solution, through core designs such as block optimization, dynamic rate negotiation, and hybrid verification, solves the problems of inefficiency, redundancy, and poor compatibility of traditional solutions, improving transmission efficiency and reliability.

[0008] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0009] Figure 1 The flowchart illustrates a method for high-speed large file transfer from a PC to an Android device based on a serial port protocol, according to an embodiment of this application.

[0010] Figure 2 This illustration shows a schematic diagram of a high-speed large file transfer device from a PC to an Android device based on a serial port protocol, according to an embodiment of this application. Detailed Implementation

[0011] The preferred embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0012] The following is combined with Figure 1 This application describes a method for high-speed transfer of large files from a PC to an Android device based on a serial port protocol, according to exemplary embodiments thereof. In one embodiment, this application also proposes a method and apparatus for high-speed transfer of large files from a PC to an Android device based on a serial port protocol. Figure 1 As shown, this method is applied to a server and includes:

[0013] S101 receives large file transfer request commands and basic serial communication configuration information from PCs and Android devices, and generates basic settings for transmission protocol startup and dynamic resource configuration.

[0014] In one implementation, the large file transfer request command needs to specify the core transmission parameters to ensure consistency between the two ends. File-related information includes file type (e.g., text file, binary industrial control data file, vehicle dashcam video file, etc.), total file size (e.g., 100MB text data, 2GB vehicle video data), and transmission priority (e.g., high priority for industrial control command files, normal priority for ordinary log files). Regarding transmission performance requirements, the minimum transmission speed threshold (e.g., not less than 300KB / s), maximum acceptable latency (e.g., no more than 1s in industrial scenarios), and data integrity requirements (e.g., no data loss or tampering allowed) should be specified. Specific use cases (e.g., data upload for industrial control equipment, data export from vehicle dashcams) should be indicated to provide a basis for subsequent resource allocation. The PC sends a transmission request command to the Android vehicle dashcam, with the following content: "Transmission type: binary vehicle video file; File size: 1.8GB; Transmission priority: high; Minimum transmission speed: 350KB / s; Maximum latency: 0.8s; Data integrity: no loss, no tampering; Application scenario: vehicle data export."

[0015] The basic configuration information for serial communication covers core parameters at both the hardware and software levels, ensuring the basic connectivity of the communication link. For hardware connection parameters, the serial port interface type (e.g., UART interface), pin definitions (e.g., TX / RX pin correspondence), and physical connection method (e.g., direct wired connection) must be clearly defined. Initial communication parameters include the default baud rate (e.g., 115200bps, used as the initial rate before negotiation), data bits (e.g., 8 bits), stop bits (e.g., 1 bit), and parity bit (if no parity bit is specified, a hybrid parity mechanism will be used instead). Regarding device hardware capabilities, the PC must provide the maximum supported baud rate for the serial port (e.g., the serial port supports up to 1.5Mbps for the i7-11800H processor), and Android devices must provide serial port hardware processing capabilities (e.g., the serial port data buffer capacity and maximum concurrent processing capability of the Snapdragon 888 chip). The Android car dashcam provides feedback on basic serial communication configuration information, which includes: "Interface type: UART; Pin definition: TX->PC_RX, RX->PC_TX; Initial baud rate: 115200bps; Data bits: 8 bits; Stop bits: 1 bit; Parity bit: None; Maximum supported baud rate: 1.5Mbps; Serial port buffer capacity: 64KB; Maximum concurrent processing capability: Supports parallel reception of 32 data blocks."

[0016] Combining the above two types of information, a basic, directly executable setting is generated, laying the groundwork for the subsequent transmission process. For the transmission protocol startup parameters, the block compression pipeline protocol designed in this invention is explicitly enabled, specifying the protocol version (e.g., V1.0), frame structure standard (e.g., the frame header includes a file type identifier, block number, and CRC8 checksum), and data transmission mode (batch transmission).

[0017] The basic rules for dynamic resource configuration are as follows: For baud rate negotiation, a baud rate probe sequence is set (1500000bps→921600bps→460800bps→230400bps→115200bps), with a response time threshold of 0.1 seconds. If the response time at the current baud rate is less than 0.1 seconds during probe, it is determined as the initial working baud rate. For block size preset rules, a block base is preset based on file type (4KB / block for text files, 64KB / block for binary files), which can be fine-tuned according to actual transmission conditions. For resource allocation rules, hardware resources are allocated for compression and verification functions (e.g., 20% CPU resources are allocated for LZ4 real-time compression on Android devices, and 15% CPU resources are allocated for mixed verification calculations), and the data buffer allocation size is set (e.g., 32KB buffer for text file transmission, and 256KB buffer for binary file transmission).

[0018] For example, combining the above requirements and configuration information, basic setting information is generated, which includes: "Transmission protocol: Chunked compression pipeline protocol V1.0; Frame structure: Frame header (file type identifier 2 bytes + block number 4 bytes + CRC8 check 1 byte) + data block + frame tail (CRC32 check 4 bytes); Baud rate negotiation sequence: 1500000bps→921600bps→460800bps→230400bps→115200bps; Response time threshold: 0.1 seconds; Chunking preset: binary file 64KB / block; Resource allocation: LZ4 compression CPU share 20%, mixed check 15% CPU share, buffer size 256KB."

[0019] S102, based on the transmission protocol startup command and dynamic resource configuration settings, starts the LZ4 real-time compression function and triggers the hybrid verification mechanism to be enabled, generating the initial file block information and the original data of the serial port real-time transmission rate.

[0020] In one implementation, file type-specific block parameters are grouped and categorized according to preset block rules to generate block patterns for text and binary files, along with 4KB / 64KB associated processing parameters. The preset block rules, centered on file data characteristics and transmission efficiency, clearly define the block logic for different file types, ensuring that block size is compatible with data structure and transmission scenarios. For text files (such as industrial control log files and configuration text files), which have high data redundancy and short individual data entries, the preset block size is 4KB / block. Associated processing parameters include block number encoding format (using 4-byte binary encoding), block boundary markers (using "0x0A0D" as the block end marker), and data padding rules (when block data is less than 4KB, it is padded with 0x00 to fill the block, avoiding frame structure disorder). For binary files (such as vehicle recorder video files and industrial equipment firmware files), which have high data density and strong continuity, the preset block size is 64KB / block. The associated processing parameters include block number encoding format (4-byte binary encoding), block boundary identifier (with "0x1F2E" as the block end marker), and data fragmentation rules (fragmentation is based on file storage physical sector alignment to reduce I / O read and write operations).

[0021] For example, the file to be transferred on the PC is an industrial control log text file (20MB in size). It is classified as a text file according to the rules, with the block mode set to 4KB / block. The associated processing parameters are "block number: 4-byte binary encoding; block boundary identifier: 0x0A0D; data padding: padding with 0x00 if less than 4KB". It is finally divided into 5000 data blocks (20MB ÷ 4KB = 5000). Another file to be transferred is a vehicle 1080P video file (1.2GB in size). It is classified as a binary file, with the block mode set to 64KB / block. The associated processing parameters are "block number: 4-byte binary encoding; block boundary identifier: 0x1F2E; fragmentation rule: fragmentation by sector alignment". It is finally divided into 18750 data blocks (1.2GB ÷ 64KB = 18750).

[0022] Based on the needs of large file transfer, the design of the LZ4 real-time compression function is implemented, obtaining compression activation standards, compressed data types, and compression range information to generate compression function activation design information. The LZ4 real-time compression function activation design must align with transmission requirements, balancing compression efficiency and system overhead to ensure no impact on real-time transmission. For the compression activation standards, dual trigger conditions are set; compression is activated when either condition is met. These are: 1) a file single-block data redundancy threshold (text files ≥30% redundancy, binary files ≥20% redundancy, obtained through sampling and analysis of 1KB data in the file header); and 2) a transmission rate requirement condition (when the minimum transmission rate is ≥200KB / s, compression is forcibly activated to reduce data volume). The compressed data types are clearly defined, compressing only valid data within data blocks, excluding block boundary identifiers, block numbers, and other control fields to avoid distortion of control information during compression. The compression range adopts a "single-block independent compression" mode, meaning each data block is processed by LZ4 independently, retaining the original block's control field relationships after compression to ensure independent decompression and reassembly at the receiving end.

[0023] For the aforementioned 20MB industrial control log text file, the minimum transmission rate is 300KB / s, and the sampled analysis file redundancy is 45%, meeting the compression enable criteria. The generated compression function enable design information is: "Enablement criteria: Redundancy ≥ 30% or minimum transmission rate ≥ 200KB / s; Compressed data type: valid data block (excluding block number and boundary identifier); Compression range: independent compression of single blocks, retaining control field associations." For the 1.2GB vehicle video file, the minimum transmission rate is 350KB / s, the sampled analysis redundancy is 25%, and the enable design information is: "Enablement criteria: Redundancy ≥ 20% or minimum transmission rate ≥ 200KB / s; Compressed data type: valid data block; Compression range: independent compression of single blocks."

[0024] Based on the operational planning and verification monitoring requirements of large file transfer mode, corresponding CRC8 fast check nodes are set for the compression function of each block rule according to the design information. The setting of CRC8 fast check nodes needs to cover the key links of transmission to ensure that fast verification can be achieved before and after data compression and before transmission, so as to detect data anomalies in a timely manner. For the check nodes corresponding to text files (4KB / block), there are two types: first, a check node before compression, which calculates the CRC8 check value of the 4KB raw data after the data block is divided into blocks according to the rules and before LZ4 compression is performed. This value is used to compare with the check value of the decompressed data to verify whether the compression and decompression process has damaged the data; second, a check node before transmission, which calculates the CRC8 check value of the entire compressed data block (including valid data and padding fields) after the data block is compressed and before the encapsulated frame structure is sent to the receiving end with the frame. For the check nodes corresponding to binary files (64KB / block), the same as for text files, two check nodes are set: one before compression and one before transmission. Because binary files contain larger amounts of data, the calculation of the verification node is performed in parallel with the pipeline process of data segmentation and compression. That is, CRC8 calculation is started immediately after segmentation is completed, and compression is prepared simultaneously to avoid verification taking up extra transmission time.

[0025] For industrial control log files with 4KB / block, the CRC8 fast check node information is set as follows: "Check Node 1 (before compression): After block division, perform CRC8 calculation on the 4KB raw data, with a polynomial of 0x31 and an initial value of 0xFF; Check Node 2 (before transmission): After compression, perform CRC8 calculation on the compressed data block (including padding fields), with the polynomial and initial value consistent with Check Node 1". For vehicle video files with 64KB / block, the check node information is set as follows: "Check Node 1 (before compression): After block division, perform CRC8 calculation in parallel, with a polynomial of 0x31 and an initial value of 0xFF; Check Node 2 (before transmission): After compression, calculate CRC8 on the complete data block, with the same parameters as before, and check and encapsulation frame structure are performed in parallel".

[0026] The file block grouping results, LZ4 compression function enabling design information, and CRC8 check nodes are processed to generate initial file block information and raw serial port real-time transmission rate data, including block grouping information, compression function enabling scheme, and CRC8 check standard. The core information from the first three steps is integrated to form initial data that can be directly used for transmission execution. Simultaneously, the raw acquisition data of the serial port real-time transmission rate is recorded to provide a basis for subsequent rate optimization. The block grouping information (file type, block size, associated processing parameters), compression function enabling scheme (enabling standard, compression type, range), and CRC8 check standard (check node, polynomial, initial value) are summarized, and a unique identifier (block number + file identifier) ​​is assigned to each data block. The frame structure encapsulation rules are defined (frame header = file identifier 2 bytes + block number 4 bytes + CRC8 check value 1 byte, frame tail = block boundary identifier 2 bytes). While initiating block transmission, the actual transmission rate data is collected at a frequency of 10ms / time through the rate monitoring module of the serial port hardware interface. The timestamp of each collection, the current block number, and the instantaneous rate value are recorded to form the raw rate dataset. It has not undergone any filtering or optimization processing to ensure the authenticity of the data.

[0027] For example, after integration, the initial block information of the 20MB industrial control log file is as follows: "Blocking rule: text type, 4KB / block, block number 4-byte binary encoding, boundary identifier 0x0A0D; Compression scheme: enabled, redundancy ≥30% or rate ≥200KB / s trigger, compress valid data, single block independent compression; CRC8 check standard: dual-node check, polynomial 0x31, initial value 0xFF, frame header contains check value; Frame structure: file identifier (0x0102) + block number + CRC8 + valid data + padding field + boundary identifier"; The original data of the serial port real-time transmission rate is as follows: "timestamp 1698765432100ms, block number 0001, instantaneous rate 280KB / s; timestamp 1698765432110ms, block number 0001, instantaneous rate 295KB / s;..." (continuously collected until the file transmission ends). The initial block information of the 1.2GB vehicle video file is as follows: "Blocking rule: binary, 64KB / block, block number 4-byte binary encoding, boundary identifier 0x1F2E; Compression scheme: enabled, triggered by redundancy ≥20% or rate ≥200KB / s, compressing valid data, single block independent compression; CRC8 check standard: dual-node check, polynomial 0x31, initial value 0xFF, frame header contains check value; Frame structure: file identifier (0x0304) + block number + CRC8 + valid data + boundary identifier"; The original data of the serial port real-time transmission rate is as follows: "timestamp 1698765500000ms, block number 0001, instantaneous rate 330KB / s; timestamp 1698765500010ms, block number 0001, instantaneous rate 342KB / s; ...".

[0028] S103 receives the pre-stored block compression pipeline protocol and rate data processing rules, processes the initial block information of the file and the original data of the real-time serial port transmission rate, and generates standard compressed data block information and transmission rate comparison benchmark information.

[0029] In one implementation, the chunked compression pipeline protocol and rate data processing rules are imported into the transmission data processing system for compatibility analysis. The windowed confirmation mechanism and rate level switching logic are extracted, and the transmission efficiency and data integrity of different file type chunking combined with LZ4 compression are simulated to generate chunked compression adaptation simulation data. The transmission data processing system has protocol parsing and scenario simulation functions. It first performs deep adaptation analysis on the imported rules, and then generates simulation data that closely resembles actual transmission through scenario simulation. The core of the chunked compression pipeline protocol includes data block transmission timing and frame interaction logic, while the rate data processing rules clearly define the rate adjustment threshold and adaptation conditions. After system analysis, two key logics were extracted: first, a windowed confirmation mechanism, where the receiving end performs batch confirmation every 32 data blocks, replacing the traditional single-frame acknowledgment and reducing acknowledgment frames by 80%; second, a rate level switching logic, dynamically switching based on the bit error rate in the levels of 1500000bps→921600bps→460800bps→230400bps→115200bps, triggering a rate reduction if three consecutive data block verification failures occur. Simulated transmission of text-based (4KB / block) and binary (64KB / block) files combined with LZ4 compression was performed at low bit error rates (…). ), and bit error rate ( High error rate Tested in an environment where transmission efficiency (data volume transmitted per unit time) and data integrity (percentage of blocks that pass verification) are recorded, and block compression adaptation simulation data is generated.

[0030] The extracted windowed confirmation mechanism is as follows: "After the receiving end buffers 32 consecutive data blocks, it generates a batch confirmation frame containing all block numbers and sends it back to the sending end all at once." The rate level switching logic is: "If CRC8 check fails for 3 consecutive data blocks at the current baud rate, it immediately switches to the next baud rate level and enables FEC encoding." In the simulation test, for text files (4KB / block), under a low bit error rate environment, the LZ4 compression rate is 60%, the transmission efficiency is 350KB / s, and the data integrity is 99.99%; for binary files (64KB / block), under a medium bit error rate environment, the compression rate is 55%, the transmission efficiency is 330KB / s, and the data integrity is 99.98%. All of the above data are included in the block compression adaptation simulation data.

[0031] A block identifier mapping algorithm is employed to subdivide the correspondence between compressed blocks and transmission rates in the block compression adaptation simulation data, generating a standardized data processing model. This algorithm decomposes the data processing logic from the dimensions of block type identification, compression efficiency matching, and rate adaptation, establishing mapping rules for different scenarios such as fast transmission of small text files and efficient compression of large binary files, while also aiming for stable rates. The block identifier mapping algorithm focuses on the precise matching of compressed blocks and transmission rates. Through multi-dimensional logic decomposition, it establishes mapping rules adapted to different scenarios, forming a standardized processing model. The mapping relationship is constructed from three core dimensions: Block type identification, distinguishing file types through a 2-byte identifier in the data block header (0x0102 for text, 0x0304 for binary); Compression efficiency matching, dividing into high, medium, and low levels based on LZ4 compression ratio (50%-70%), corresponding to different rate adaptation priorities; and Rate adaptation, determining the optimal transmission rate range by combining the current baud rate level and bit error rate.

[0032] For fast transmission of small text files, high baud rate levels (1.5Mbps / 921600bps) are prioritized, and the maximum transmission rate is used when the compression efficiency is ≥60% to ensure minimal transmission latency. For efficient compression of large binary files, a balance is struck between rate and stability. The peak rate of the corresponding baud rate level is used when the compression efficiency is ≥55%, and the rate is appropriately reduced when the compression efficiency is below 55% to avoid data loss. Based on these rules, a standardized data processing model is generated, including block identifiers, compression efficiency, rate ranges, and applicable scenarios.

[0033] The block identifier mapping algorithm processes a text-type compressed block (identifier 0x0102, compression rate 65%), identifying it as a high-priority, fast transmission scenario, and mapping it to a 1.5Mbps baud rate range, with a rate adaptation range of 1450KB / s-1500KB / s. For a binary-type compressed block (identifier 0x0304, compression rate 53%), it is identified as an efficient compression and stable transmission scenario, and mapped to a 921600bps baud rate range, with a rate adaptation range of 880KB / s-920KB / s. All mapping results are integrated to generate a standardized data processing model, clarifying the rate adaptation schemes corresponding to different block identifier combinations.

[0034] The system collects characteristic parameters such as compressed data block verification pass rate, real-time serial port speed fluctuation, and block batch transmission delay under different transmission scenarios. It then constructs a block compression transmission characteristic library and generates data processing constraint data. Specifically, the block compression transmission characteristic library customizes parameters for speed optimization requirements in low bit error rate scenarios, compression efficiency requirements in high redundancy data scenarios, and confirmation mechanism requirements in multi-block continuous transmission scenarios. Through multi-scenario parameter collection, a characteristic library covering different transmission needs is established, providing clear constraints for data processing and ensuring compliant and efficient transmission. This is particularly relevant for low bit error rate (≤...) scenarios. The study collected key characteristic parameters for three core scenarios: low error rate scenarios, high redundancy data (redundancy ≥ 40%), and multi-block continuous transmission (single transmission ≥ 100 blocks). For low error rate scenarios, the study collected compressed data block verification pass rate and baud rate stability maintenance time; for high redundancy data scenarios, the study collected LZ4 compression rate and compression time; and for multi-block continuous transmission scenarios, the study collected batch transmission delay and acknowledgment frame feedback time.

[0035] The feature library is categorized by scenario to customize parameter standards. Low bit error rate scenarios focus on rate optimization, with constraints of "verification pass rate ≥ 99.99%, baud rate stability maintenance time ≥ 10s"; high redundant data scenarios focus on compression efficiency, with constraints of "LZ4 compression rate ≥ 60%, single-block compression time ≤ 1ms"; multi-block continuous transmission scenarios focus on acknowledgment mechanisms, with constraints of "batch transmission delay ≤ 50ms, acknowledgment frame feedback time ≤ 10ms". Based on these constraints, data processing constraint data is generated, clarifying the parameter boundaries for each scenario. Low bit error rate scenario (industrial control environment, bit error rate...) The data collected showed a verification pass rate of 99.995% and a baud rate stability time of 15s. The constraint data was set as "verification pass rate ≥ 99.99%, baud rate stability ≥ 10s". In the high redundancy data scenario (log file transmission, redundancy 45%), the data collected showed a compression rate of 68% and a single block compression time of 0.8ms. The constraint data was set as "compression rate ≥ 60%, compression time ≤ 1ms". In the multi-block continuous transmission scenario (vehicle video batch transmission, 1000 blocks per transmission), the data collected showed a batch transmission delay of 42ms and an acknowledgment frame feedback time of 8ms. The constraint data was set as "transmission delay ≤ 50ms, feedback time ≤ 10ms". All data were entered into the block compression transmission feature library.

[0036] By integrating standardized data processing models with data processing constraint data, a block compression-rate adaptation coupled processing model is constructed. Through iterative optimization of the model, standard compressed data block information and transmission rate comparison benchmark information are generated. Through model fusion and iterative optimization, dynamic coordination between compressed block processing and rate adaptation is achieved, outputting standardized data and rate comparison benchmarks to provide a basis for subsequent transmission adjustments. The mapping rules in the standardized data processing model are used as core logic and embedded into the parameter boundaries of the data processing constraint data to construct the coupled processing model. The model includes a data input layer (compressed block information, current rate data), a logic processing layer (mapping rule matching, constraint condition verification), and an output layer (standard data blocks, rate benchmark), realizing fully automated processing of the "input-matching-verification-output" process.

[0037] Multiple iterations are performed based on block compression adaptation simulation data. After each iteration, the fit between the output results and the constraints is compared to optimize the mapping rules and parameter weights. The final result is generated when the compressed block information output by the model meets the requirements of "compliant block structure and compliant compression rate," and the rate benchmark meets the requirements of "adapting to the scenario and fluctuations within the constraints." Standard compressed data block information clearly defines standardized parameters such as block identifier, compression rate, checksum, and frame structure. Transmission rate comparison benchmark information sets standard rate ranges, fluctuation thresholds, and adjustment trigger conditions for different scenarios.

[0038] The coupled processing model, after fusion, takes into account information about a binary compressed block (identifier 0x0304, original size 64KB, compression ratio 58%) and current bit rate data (921600bps, bit error rate). After mapping rule matching and adaptation to a 921600bps rate range, constraint verification showed that the compression ratio and rate both met the requirements. The output standard compressed data block information was: "Block identifier 0x0304, compressed size 35.84KB, CRC8 checksum 0x7A, CRC32 checksum 0x12345678, frame header includes block number + checksum, frame tail includes boundary identifier"; the transmission rate comparison benchmark information was: "standard rate range 880KB / s-920KB / s, rate fluctuation threshold ±5%, rate adjustment triggered after 3 consecutive fluctuations exceeding the threshold". After 10 rounds of iterative optimization, the constraint fit of the model output results improved from 92% to 99.5%, and the standard compressed data block information and transmission rate comparison benchmark information were finally determined.

[0039] S104 processes the standard compressed data block information and the transmission rate comparison reference information based on the dynamic baud rate negotiation rule to generate rate adjustment signals and verification mechanism adaptation information.

[0040] In one implementation, standard compressed data block information and transmission rate comparison benchmark information are obtained based on dynamic baud rate negotiation rules. Features of compressed block integrity, current baud rate adaptability, and bit error rate stability are extracted. The dynamic baud rate negotiation rules clearly define the data extraction dimensions and feature judgment criteria, accurately capturing key features affecting transmission quality from two types of core information, providing a basis for subsequent processing. Standard compressed data block information includes standardized parameters such as block identifier, compression rate, checksum, and frame structure; transmission rate comparison benchmark information covers standard rate ranges, fluctuation thresholds, and adjustment trigger conditions under different scenarios. Three core features are extracted from these two types of information according to the rules: compressed block integrity (whether the data block is completely received and whether compression and decompression are normal), current baud rate adaptability (the degree to which the currently used 1.5Mbps / 921600bps level rate matches the transmission requirements), and bit error rate stability (the fluctuation range and abnormal risk of the bit error rate during continuous transmission).

[0041] Obtain standard compressed data block information (block identifier 0x0304, compression ratio 58%, CRC8 checksum 0x7A) of a binary file and compare it with transmission rate benchmark information (standard rate range 880KB / s-920KB / s, fluctuation threshold ±5%). Extract the following features: compressed block integrity (100 data blocks have been received, no obvious missing markers), current baud rate adaptability (currently using a rate of 921600bps, minimum transmission rate required is 350KB / s), and bit error rate stability (bit error rate fluctuation in transmitted data blocks is within a certain range). to between).

[0042] The integrity characteristics of compressed blocks are verified to identify data block loss and compression / decompression anomalies, generating a block integrity coefficient. A combination of block-by-block verification and anomaly identification is used to quantify compressed block integrity. The coefficient ranges from 0 to 1, with values ​​closer to 1 indicating better integrity. First, the continuity of block numbers in the received data blocks is checked to determine if any are missing (e.g., if block numbers range from 0001 to 0100, missing block 0056 indicates a data block loss). Then, each data block is decompressed, and the CRC8 checksum of the decompressed data is compared with that of the original data. Inconsistencies indicate compression / decompression anomalies. The block integrity coefficient is calculated as: (Number of normally received and decompressed blocks ÷ Total number of blocks to be received) × 100%.

[0043] For example, a text file should receive 500 data blocks. After verification, 3 blocks (numbered 0210, 0356, and 0489) were found to be missing, and 2 blocks (numbered 0123 and 0301) had inconsistent checksums after decompression. The number of normal blocks was 495. The block integrity coefficient = (495 ÷ 500) × 100% = 0.99, indicating that the compressed block integrity is good.

[0044] Verify the current baud rate adaptability by checking the matching deviation between the 1.5Mbps / 921600bps tier rate and the file transfer requirements, generating a rate adaptation accuracy factor. Using the lowest rate in the file transfer requirements as the core benchmark, calculate the adaptation deviation of the current tier rate. The accuracy factor ranges from 0 to 1, with values ​​closer to 1 indicating better adaptability. Determine the actual transmission rate corresponding to the currently used baud rate tier (1.5Mbps or 921600bps) (calculated as the average based on the raw data of the serial port real-time transmission rate), compare it with the lowest rate in the transmission requirements, and calculate the deviation rate. The factor is calculated as follows: Rate adaptation accuracy factor = 1 - |(Current actual average rate - Minimum required rate) ÷ Minimum required rate|. If the current actual average rate ≥ the minimum required rate, the deviation rate is 0, and the factor is 1.

[0045] For example, a vehicle video file transfer requires a minimum rate of 350KB / s. Currently using a baud rate of 921600bps, the actual average transfer rate is 342KB / s. The deviation rate = |(342-350)÷350|≈0.023, and the rate matching accuracy factor = 1-0.023=0.977, indicating good baud rate compatibility. If a 1.5Mbps baud rate is currently used, the actual average transfer rate is 400KB / s. Since 400KB / s ≥ 350KB / s, the rate matching accuracy factor = 1, resulting in optimal compatibility.

[0046] The bit error rate stability characteristics are verified to confirm whether the bit error rate is controlled within the target range during continuous transmission and whether there is a risk of three consecutive data block verification failures. A bit error rate stability coefficient is then generated. The bit error rate (BER) stability is evaluated using a dual standard: a BER threshold of 3 blocks and a consecutive check failure threshold. The coefficient ranges from 0 to 1, with values ​​closer to 1 indicating better stability. The BER of each block in 100 consecutively transmitted data blocks is statistically analyzed to determine if it is consistently controlled within the acceptable range. Within; simultaneously track the continuity of failed verification blocks, checking for two consecutive failed blocks (if present, it is considered a risk of triggering three consecutive failures). Error rate stability coefficient = (length of continuous transmission segments with acceptable error rate and no two consecutive failed blocks ÷ total continuous transmission length) × 100%.

[0047] For example, an industrial control log file continuously transmits 1000 data blocks, of which 998 blocks have a bit error rate of ≤ Only two blocks had excessive bit error rates (blocks 300 and 650, respectively, not consecutively), and there were no instances of two consecutive block check failures. The bit error rate stability coefficient = (1000 ÷ 1000) × 100% = 1.0, indicating excellent bit error rate stability. If consecutive check failures occur in blocks 401 and 402 during transmission, the bit error rate stability coefficient = (998 ÷ 1000) × 100% = 0.998, indicating a risk of triggering three consecutive failures.

[0048] Based on preset baud rate negotiation rules, the block integrity coefficient, rate adaptation accuracy factor, and error stability coefficient are processed. A dynamic rate switching mechanism is used to adjust the baud rate level, forward error correction coding compensates for bit errors, and the check node is optimized to improve check efficiency, generating a rate negotiation preprocessing result. The preset baud rate negotiation rules set coefficient thresholds and processing logic, and targeted optimization measures are taken for different coefficient combinations to form the preprocessing result. Qualified coefficient thresholds are set (block integrity coefficient ≥ 0.95, rate adaptation accuracy factor ≥ 0.9, error stability coefficient ≥ 0.95). If all coefficients meet the standards, the current baud rate level is maintained, and the execution timing of the check node is optimized (e.g., parallel execution with data compression). If the rate adaptation accuracy factor < 0.9, the dynamic rate switching mechanism is activated, upgrading to a higher baud rate level (e.g., switching from 921600bps to 1.5Mbps). If the error stability coefficient < 0.95, forward error correction (FEC) coding is enabled to compensate for bit errors. If the block integrity coefficient < 0.95, the detection accuracy of the check node is optimized (e.g., adding secondary verification of the compressed data).

[0049] A file transfer has a block integrity coefficient of 0.99, a rate adaptation accuracy factor of 0.88, and an error rate stability factor of 0.98. Because the rate adaptation accuracy factor is below standard, a dynamic rate switching mechanism is activated, upgrading the speed from 921600bps to 1.5Mbps. Simultaneously, the check node timing is optimized and executed in parallel with LZ4 compression. The generated rate negotiation preprocessing result is: "Rate level switching: 921600bps→1.5Mbps; Check node optimization: executed in parallel with compression; FEC encoding: temporarily disabled."

[0050] The preprocessing results of rate negotiation are integrated to generate a rate adjustment signal reflecting block integrity deviation, rate adaptation error, and bit error risk, as well as corresponding verification mechanism adaptation information for switching baud rate levels and enabling FEC coding. Core optimization measures and problem feedback from the preprocessing results are summarized to generate signals and adaptation information that can be directly triggered for execution, ensuring dynamic adaptation of transmission parameters. The risk levels of the quantitative deviations of the three core issues are clearly defined: block integrity deviation = 1 - block integrity coefficient; rate adaptation error = 1 - rate adaptation accuracy factor; and bit error risk levels are classified according to the bit error stability coefficient (≥0.95 is low risk, 0.9-0.95 is medium risk, <0.9 is high risk). The verification mechanism adaptation information corresponds to the optimization measures in the preprocessing results, clarifying the baud rate level switching direction, FEC coding activation status, and verification node optimization scheme, ensuring linkage with the rate adjustment signal.

[0051] Integrating the above preprocessing results, the generated rate adjustment signal is: "Block integrity deviation: 0.01 (low deviation); Rate adaptation error: 0.12 (medium error); Error risk level: low risk"; The verification mechanism adaptation information is: "Baud rate level switching: from 921600bps to 1.5Mbps; FEC encoding: temporarily disabled; Verification node optimization: executed in parallel with LZ4 compression to improve verification efficiency." If a file has an error stability coefficient of 0.89 (medium risk), and the preprocessing result is that FEC encoding is enabled, then the verification mechanism adaptation information is: "Baud rate level: maintained at 1.5Mbps; FEC encoding: enabled; Verification node optimization: added secondary verification after compression," and the error risk level in the rate adjustment signal is marked as medium risk.

[0052] S105 processes the verification mechanism adaptation information and the device serial port hardware resource status information to generate mixed verification level and file transfer specification matching control operation information.

[0053] In one implementation, verification mechanism adaptation information, device serial port hardware resource status information, and file transfer specification data are integrated. The priority of hybrid verification execution is determined based on the serial port hardware processing capability, while simultaneously overlaying data block transmission urgency and verification calculation overhead thresholds. This generates an intermediate processing dataset containing verification level selection logic, verification timing control standards, and initial verification schemes for different file types. First, the verification mechanism adaptation information, serial port hardware resource status information, and file transfer specification data are summarized. Using hardware capabilities as the core, combined with transmission urgency and verification overhead, the core verification rules and initial schemes are clarified, forming the intermediate processing dataset. The verification mechanism adaptation information includes baud rate level, FEC encoding enable status, and verification node optimization scheme; the device serial port hardware resource status information covers CPU processing capability, cache capacity, and maximum concurrent processing (e.g., Snapdragon 888 chip serial port CPU usage limit of 30%, cache 64KB, maximum concurrent 32 blocks); the file transfer specification data includes file type, block size, transmission priority, and minimum rate requirement.

[0054] Prioritization is based on serial port hardware processing capabilities. When hardware resources are sufficient (CPU usage ≤20%, cache remaining ≥50%), the mixed verification priority is set to "high" to prioritize verification integrity. When hardware resources are scarce (CPU usage 20%-30%, cache remaining 30%-50%), the priority is set to "medium" to balance verification and transmission efficiency. When hardware resources are limited (CPU usage >30%, cache remaining <30%), the priority is set to "low" to prioritize transmission continuity. Data block transmission urgency is categorized by transmission priority (industrial control commands are "urgent," vehicle video is "normal," and log files are "low-priority"). Urgent data block verification priority is automatically increased by one level. The verification calculation overhead threshold is set to ≤1ms for single block verification time (CRC8 ≤0.2ms, CRC32 ≤0.8ms). If this is exceeded, the verification process is simplified.

[0055] Clearly define the logic for selecting the verification level (prioritize CRC8 fast verification, trigger CRC32 deep verification upon failure), the standard for controlling the verification timing (execute in parallel with data compression / transmission without adding extra delay), and the initial verification scheme for different file types (text files: 4KB block; dual-node verification + fast retransmission; binary files: 64KB block; dual-node verification + parallel retransmission).

[0056] This project integrates relevant data from an industrial control instruction file (text-based, 4KB / block, transmission priority "urgent"). The hardware status is: CPU usage 15%, cache remaining 40% (sufficient resources). The verification mechanism adaptation information is: "baud rate 1.5Mbps, FEC not enabled". The mixed verification execution priority is determined to be "high", and the "high" priority is maintained after adding urgency. The verification calculation overhead threshold is set to ≤1ms per block. The generated intermediate processing dataset has the following characteristics: "Verification level selection logic: CRC8 preferred, CRC32 triggered upon failure; Verification timing: parallel execution with LZ4 compression; Initial text-based verification scheme: dual-node verification (before compression + before transmission), retransmission triggered within 10ms after verification failure; Verification overhead threshold: ≤1ms per block verification."

[0057] Based on the verification efficiency requirements, hardware resource consumption standards, and verification rules for different file types in the intermediate processing dataset, verification level conflicts in the intermediate processing dataset are marked and filtered to generate verification adaptation anomaly records. By comparing the core standards of the intermediate processing dataset, conflicts between the verification level and the actual scenario are investigated, the anomaly types and causes are identified, and traceable anomaly records are formed. The conflict judgment dimensions are as follows: verification efficiency requirements (single block verification time ≤ 1ms, batch verification does not affect transmission rate), hardware resource consumption standards (CPU usage ≤ 30%, cache usage ≤ 50%), and verification rules for different file types (text type dual-node verification, binary type dual-node verification + parallel retransmission). If a 64KB binary block uses dual-node verification and the single block verification time reaches 1.2ms (exceeding the overhead threshold), it is judged as "verification efficiency conflict"; if the hardware CPU usage is 35% (exceeding the upper limit) but high-priority verification is still performed, it is judged as "hardware resource conflict"; if text files need to skip CRC8 and directly execute CRC32 due to increased transmission urgency, which conflicts with the "CRC8 priority" logic, it is judged as "verification level selection conflict". Each exception record includes the file type, block size, conflict type, conflict cause, current parameters, and constraint criteria, ensuring accurate correction in the future.

[0058] For example, the intermediate processing dataset for a certain vehicle video file (binary, 64KB / block, transmission priority "normal") requires "dual-node verification + parallel retransmission". The actual hardware CPU usage is 32% (exceeding the 30% limit). After verification, CPU usage rises to 45%, causing a 10% decrease in transmission rate, which is determined to be a "hardware resource conflict". The generated verification adaptation anomaly record is as follows: "File type: binary; Block size: 64KB; Conflict type: hardware resource conflict; Conflict reason: CPU usage exceeds the threshold (45% > 30%) after dual-node verification; Current parameters: dual-node verification + parallel retransmission, CPU usage 45%; Constraint standard: CPU usage ≤ 30%".

[0059] The intermediate processing dataset and verification adaptation anomaly records are verified and fused. Constraints are imposed on the computational overhead and hardware resource adaptation of hybrid verification, as well as reasonable range constraints on verification accuracy for different file types. Verification level conflicts are corrected and the hybrid verification execution logic is improved, generating hybrid verification levels and control operation information adapted to different file transfer specifications. By applying multiple constraints, the verification logic is optimized, conflict issues are corrected, and standardized control operation information adapted to different file transfer specifications is formed, ensuring efficient collaboration between verification and transmission. Core constraints are imposed: hybrid verification computational overhead constraints (single-block verification time ≤ 1ms, CRC8 and CRC32 collaboratively allocate time), hardware resource adaptation constraints (CPU usage ≤ 30%, cache usage ≤ 50%, verification parallelism dynamically adjusted according to hardware status), and verification accuracy constraints (text type ≥ 99.99%, binary type ≥ 99.98%).

[0060] The conflict correction logic addresses conflicts related to verification efficiency by simplifying the CRC32 calculation process (using a fast polynomial algorithm) or reducing the deep verification ratio (only performing CRC32 verification on 30% of blocks that failed CRC8 verification); for conflicts related to hardware resources, it lowers the verification priority (high → medium) or adopts "round-robin verification" (verifying one block every two blocks); and for conflicts related to verification level selection, it retains the core verification logic and temporarily adjusts the triggering conditions (triggering CRC32 within 5ms after an emergency data block fails CRC8 verification).

[0061] The verification process is clearly defined for different scenarios (sufficient hardware: dual-node verification + full retransmission; limited hardware: dual-node verification + sampling retransmission; scarce hardware: single-node CRC8 verification + on-demand retransmission), retransmission mechanism (maximum concurrent retransmission of 32, linked with windowed confirmation mechanism), and collaborative logic between verification and transmission (verification results are fed back to the transmission module in real time, dynamically adjusting the transmission rate). The final information includes mixed verification levels (high / medium / low), adapted file transmission specifications (file type, block size, transmission priority), and specific control operations (verification node enable / disable, verification algorithm selection, retransmission trigger conditions, and hardware resource allocation ratio).

[0062] To address the hardware resource conflict in the aforementioned vehicle-mounted video files, constraints were imposed to correct the conflict: the priority of the hybrid verification was reduced from "medium" to "low," and a "dual-node verification + sampling retransmission" approach was adopted (CRC32 verification was performed only on 20% of the failed CRC8 blocks). The hardware resource allocation ratio was adjusted (verification CPU usage ≤25%, cache usage ≤40%). The improved hybrid verification execution logic is: "CRC8 fast verification and transmission are performed in parallel; after failure, the BlockID is recorded; verification results are fed back in batches every 32 blocks received; CRC32 deep verification is performed only on 20% of the failed blocks; the maximum concurrent parallel retransmission is 16." The final generated hybrid verification level and control operation information are: "Hybrid verification level: low; Adapted specification: binary class 64KB / block, normal priority; Control operation: enable the CRC8 pre-transmission verification node, disable the pre-compression verification node, record the BlockID after CRC8 failure, perform CRC32 verification on 20% of the failed blocks during batch confirmation, the concurrent parallel retransmission is 16, verification CPU usage ≤25%, cache usage ≤40%, verification accuracy ≥99.98%."

[0063] S106, based on the preset large file transfer mode operation requirements and real-time bit error rate feedback, transforms control operation information into actual file transfer actions, extracts and classifies the transfer mode requirements, bit error rate feedback, control operation information and serial port hardware attributes, and generates transfer mode adaptation parameters, rate calibration rules, resource usage thresholds, and file transfer and serial port protocol linkage mapping information.

[0064] In one implementation, a transmission parameter correlation algorithm is used to screen key influencing factors based on preset large file transfer mode operating requirements, real-time bit error rate feedback, hybrid parity check control operation information, and serial port hardware attribute data. This generates a set of key influencing factors including baud rate adaptability, compression efficiency, parity check overhead, and hardware capacity. The transmission parameter correlation algorithm precisely identifies the core factors determining transmission quality by quantitatively analyzing the correlation between various data points, providing core input for subsequent modeling. This is based on preset large file transfer mode operating requirements (e.g., transfer rate ≥ 350KB / s, latency ≤ 0.8s), real-time bit error rate feedback (e.g., current bit error rate...). The system takes mixed verification control operation information (such as verification level and retransmission strategy) and serial port hardware attribute data (such as CPU processing power, cache capacity and maximum baud rate) as input, calculates the correlation coefficient between each parameter and transmission efficiency and reliability, and selects parameters with a correlation coefficient ≥ 0.7 as key influencing factors.

[0065] The factors are specifically defined as follows: Baud rate fit: The degree to which the current baud rate matches the file transfer requirements, quantified as a value between 0 and 1 (1 for complete fit). Compression efficiency: The actual compression ratio of the LZ4 compression algorithm (50%-70%), directly affecting the amount of data transmitted. Verification overhead: The calculation time of the hybrid verification mechanism (single block verification ≤ 1ms), related to hardware resource usage. Hardware capacity: The upper limit of CPU usage, cache capacity, and maximum concurrent processing of the serial port hardware (e.g., Snapdragon 888 chip serial port CPU usage ≤ 30%, cache 64KB, maximum concurrent 32 blocks).

[0066] Data related to a certain in-vehicle video file (binary, 64KB / block, transmission requirement ≥350KB / s, latency ≤0.8s) was filtered, and the real-time bit error rate feedback was as follows: The hybrid checksum control operation information is "low-level checksum + parallel retransmission", and the hardware attribute data is "CPU usage 25%, cache remaining 40%, maximum baud rate 1.5Mbps". Calculated using a transmission parameter correlation algorithm, baud rate compatibility (correlation coefficient 0.85), compression efficiency (correlation coefficient 0.82), checksum overhead (correlation coefficient 0.78), and hardware capacity (correlation coefficient 0.73) all meet the threshold requirements. The generated set of key influencing factors is: "Baud rate compatibility: 0.92 (1.5Mbps matches the 350KB / s requirement); Compression efficiency: 62%; Checksum overhead: 0.8ms / block; Hardware capacity: CPU usage 25%, cache remaining 40%, maximum concurrency 32 blocks".

[0067] Data fusion processing is performed on the set of key influencing factors, serial port transmission speed thresholds, bit error rate control standards, and equipment compatibility requirements to establish the correlation mapping relationship between various elements and generate a fused feature dataset. The key influencing factors are fused with the core constraint standards to clarify the linkage relationship between various elements, forming a structured feature dataset that provides complete input for model construction. The set of key influencing factors is the core, superimposed with serial port transmission speed thresholds (e.g., text ≥300KB / s, binary ≥350KB / s) and bit error rate control standards (≤...). Device compatibility requirements (supports Android 5.0 and above, no root access required). When establishing mapping relationships, baud rate adaptation must be linked to the transmission speed threshold (adaptation ≥ 0.9 corresponds to speed compliance), compression efficiency must meet the data volume reduction requirement (≥ 50%), verification overhead must be controlled within the hardware's carrying capacity (≤ 1ms / block), and hardware carrying capacity must meet compatibility requirements (CPU usage ≤ 30%). The fused feature dataset includes factor quantification values, constraint standards, mapping relationship identifiers, and scene labels (e.g., "vehicle video - regular priority"), ensuring that each feature is traceable and computable.

[0068] Integrating the key influencing factors and constraint standards of the above-mentioned vehicle-mounted video files, the transmission speed threshold is 350KB / s, and the bit error rate control standard... Compatibility requirements: Android 10.0 (no root required). The established mapping relationship is: "Baud rate adaptation 0.92 → Transmission speed 360KB / s (meets standards); Compression efficiency 62% → Data volume reduction 62% (meets standards); Verification overhead 0.8ms / block → CPU usage 25% (meets standards); Hardware capacity → Supports Android 10.0 (meets standards)". The generated fusion feature dataset is: "Scene label: In-vehicle video - Regular priority; Baud rate adaptation: 0.92 (corresponding speed 360KB / s, threshold 350KB / s); Compression efficiency: 62% (threshold ≥ 50%); Verification overhead: 0.8ms / block (threshold ≤ 1ms); Hardware capacity: CPU 25% / Cache 40% / Android 10.0 (all meet standards); Current error rate." (Target is) )".

[0069] A dynamic integration model for large file serial port transmission parameters is constructed based on a fused feature dataset. The model uses file transmission specifications as the input dimension, key influencing factors as core parameters, and multiple constraints as boundary conditions to generate an initial transmission parameter dataset adapted to the current scenario. Based on the fused feature dataset, a dynamic model that considers multiple constraints is built, outputting initial transmission parameters adapted to the current scenario, achieving preliminary matching between parameters and the scenario. The model uses file transmission specifications (file type, chunk size, transmission priority) as the input dimension, key influencing factors as core parameters, and multiple constraints (speed, bit error rate, compatibility) as boundary conditions. Through iterative algorithm calculation, the model outputs transmission parameters adapted to the current scenario, including baud rate levels, compression ratio targets, verification strategies, and hardware resource allocation ratios. The initial transmission parameter dataset content: clearly defines the core parameters of each transmission stage, ensuring that there are no conflicts between parameters and that they meet the constraints.

[0070] The model is built based on the aforementioned fused feature dataset. The input dimension is "binary class 64KB / block, regular priority". The core parameters are baud rate adaptation 0.92, compression efficiency 62%, etc. The boundary conditions are speed ≥ 350KB / s, bit error rate ≤ After iterative calculation of the model, the generated initial transmission parameter dataset is as follows: "Baud rate level: 1.5Mbps; Compression rate target: 65%; Verification strategy: dual-node verification (CRC8+CRC32) + parallel retransmission (concurrency 16); Hardware resource allocation: LZ4 compression CPU usage 20%, verification CPU usage 15%, cache allocation 32KB; Compatibility adaptation: Android 5.0+ without root".

[0071] To address the large file transfer requirements across different scenarios, the initial transmission parameter dataset is decomposed into data dimensions. This clarifies the application priority, adjustment frequency, and anomaly handling measures for transmission mode adaptation parameters, rate calibration rules, resource consumption thresholds, and protocol linkage mapping information. This generates transmission mode adaptation parameters, rate calibration rules, resource consumption thresholds, and file transfer and serial port protocol linkage mapping information suitable for multiple scenarios. Parameter dimensions are refined according to different scenario requirements, clarifying parameter application rules and anomaly handling solutions, resulting in standardized and implementable transmission configuration information. Classified by scenario (industrial control / vehicle video / log files), baud rate levels, block sizes, and compression rate targets are defined (e.g., industrial control: 1.5Mbps / 4KB / 65%; log files: 921600bps / 4KB / 55%). Calibration trigger conditions (rate fluctuation ±5%, 3 consecutive bit errors) and calibration step sizes (baud rate ±10%, compression rate ±5%) are set. Based on hardware status (sufficient / strained / scarce), set upper limits for CPU and cache usage (e.g., sufficient: CPU ≤ 30% / cache ≤ 50%; scarce: CPU ≤ 20% / cache ≤ 30%). Clearly define the linkage logic for chunking, compression, verification, and retransmission (e.g., 64KB chunks → 60% compression rate → dual-node verification → parallel retransmission). Prioritize operations in the order of "rate compliance > bit error rate control > resource usage > compatibility"; anomaly handling measures include increasing the baud rate when the rate is insufficient, strengthening verification when the bit error rate exceeds the limit, and reducing the compression rate when resources are scarce.

[0072] The initial transmission parameter dataset is disassembled and adapted to multiple scenarios to generate final information. The transmission mode adaptation parameters are: industrial control (text 4KB / 1.5Mbps / 65% compression), vehicle video (binary 64KB / 1.5Mbps / 62% compression), and log file (text 4KB / 921600bps / 55% compression). The rate calibration rule is to trigger calibration when the fluctuation is ±5%, with the baud rate adjusted by 10% and the compression rate adjusted by 5% each time. The resource usage thresholds are as follows: sufficient hardware (CPU≤30% / cache≤50%), strained (CPU≤25% / cache≤40%), and scarce (CPU≤20% / cache≤30%). The protocol linkage mapping information is: text 4KB → compression rate 55%-65% → dual-node verification → fast retransmission; binary 64KB → compression rate 50%-62% → dual-node verification → parallel retransmission (concurrency 16). When the rate is <350KB / s, the baud rate is increased to 1.5Mbps; when the bit error rate is > Enable FEC encoding when CPU usage is >30%; reduce compression rate to 50%.

[0073] In one implementation, such as Figure 2 As shown, this application also provides a high-speed large file transfer device from a PC to an Android device based on a serial port protocol, comprising:

[0074] The acquisition module 201 is used to receive the large file transfer request command between the PC and the Android device and the basic configuration information of serial communication, and to generate the basic setting information for the start of the transfer protocol and dynamic resource configuration.

[0075] The processing module 202 is used to start the LZ4 real-time compression function and trigger the hybrid verification mechanism based on the transmission protocol start command and dynamic resource configuration settings, generating initial file block information and raw data of real-time serial port transmission rate; receiving pre-stored block compression pipeline protocol and rate data processing rules, processing the initial file block information and raw data of real-time serial port transmission rate, generating standard compressed data block information and transmission rate comparison benchmark information; processing the standard compressed data block information and transmission rate comparison benchmark information based on dynamic baud rate negotiation rules, generating rate adjustment signals and verification mechanism adaptation information; processing the verification mechanism adaptation information and device serial port hardware resource status information, generating hybrid verification level and file transmission specification matching control operation information; based on the preset large file transmission mode operation requirements and real-time bit error rate feedback, converting the control operation information into actual file transmission actions, extracting and classifying transmission mode requirements, bit error rate feedback, control operation information and serial port hardware attributes, generating transmission mode adaptation parameters, rate calibration rules, resource occupancy thresholds, and file transmission and serial port protocol linkage mapping information.

[0076] The various embodiments in this application are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments for evaluating the high-speed large file transfer method from PC to Android device based on a serial port protocol, the electronic device, the electronic device, and the readable storage medium are relatively simple to describe because they are substantially similar to the above-described embodiments of the high-speed large file transfer method from PC to Android device based on a serial port protocol. Relevant parts can be referred to the descriptions of the above-described embodiments of the high-speed large file transfer method from PC to Android device based on a serial port protocol.

Claims

1. A method for high-speed transfer of large files from a PC to an Android device based on a serial port protocol, characterized in that, include: Receive large file transfer request commands and basic serial communication configuration information from PC and Android devices, and generate transfer protocol startup commands and basic dynamic resource configuration settings. Based on the transmission protocol startup command and dynamic resource configuration settings, the LZ4 real-time compression function is started and the hybrid verification mechanism is triggered to generate the initial file block information and the original data of the serial port real-time transmission rate. The system receives pre-stored block compression pipeline protocol and rate data processing rules, processes the initial file block information and raw serial port real-time transmission rate data, and generates standard compressed data block information and transmission rate comparison benchmark information. This includes importing the block compression pipeline protocol and rate data processing rules into the transmission data processing system for adaptability analysis, extracting the windowed confirmation mechanism and rate level switching logic, simulating the transmission efficiency and data integrity when different file type blocks are combined with LZ4 compression, and generating block compression adaptation simulation data. A block identifier mapping algorithm is used to further subdivide the correspondence between compressed blocks and transmission rates in the block compression adaptation simulation data, generating a standardized data processing model. The block identifier mapping algorithm addresses block type identification, compression efficiency matching, and rate adaptation dimensions. The data processing logic is broken down, and mapping rules are established for different scenarios, including fast transmission of small text files and efficient compression of large binary files, to meet the transmission needs and rate stability targets. Characteristic parameters such as the pass rate of compressed data blocks, real-time fluctuations in serial port rates, and latency of block-based batch transmission are collected under different transmission scenarios to construct a block-based compression transmission characteristic library and generate data processing constraint data. Specifically, the block-based compression transmission characteristic library customizes parameters for rate optimization requirements in low error rate scenarios, compression efficiency requirements in high-redundancy data scenarios, and confirmation mechanism requirements in multi-block continuous transmission scenarios. The standardized data processing model and data processing constraint data are integrated to construct a block compression-rate adaptation coupled processing model. Through iterative optimization of the model, standard compressed data block information and transmission rate comparison benchmark information are generated. Based on the dynamic baud rate negotiation rule, the standard compressed data block information and the transmission rate ratio are processed to generate the rate adjustment signal and the verification mechanism adaptation information. The verification mechanism adaptation information and device serial port hardware resource status information are processed to generate mixed verification level and file transfer specification matching control operation information; Based on the preset large file transfer mode operation requirements and real-time bit error rate feedback, the control operation information is transformed into actual file transfer actions. The transfer mode requirements, bit error rate feedback, control operation information and serial port hardware attributes are extracted and classified to generate transfer mode adaptation parameters, rate calibration rules, resource usage thresholds, and file transfer and serial port protocol linkage mapping information.

2. The method as described in claim 1, characterized in that, Based on the transmission protocol startup command and dynamic resource configuration settings, the LZ4 real-time compression function is started and the hybrid verification mechanism is triggered, generating initial file block information and raw data of the serial port real-time transmission rate, including: The file types are grouped and classified according to the preset block division rules, generating block division patterns and 4KB / 64KB associated processing parameter information for text and binary classes. Based on the needs of large file transfer, the layout design of the LZ4 real-time compression function is carried out, and the compression activation standard, compression data type and compression range information are obtained to generate compression function activation design information. Based on the operational planning and verification monitoring requirements of the large file transfer mode, the corresponding CRC8 fast verification node is set for the compression function of each block rule using the design information. The file block grouping results, LZ4 compression function enablement design information, and CRC8 check nodes are processed to generate the initial file block information and raw data of serial port real-time transmission rate, which include block grouping information, compression function enablement scheme, and CRC8 check standard.

3. The method as described in claim 1, characterized in that, Based on the dynamic baud rate negotiation rule, the standard compressed data block information and the transmission rate comparison reference information are processed to generate rate adjustment signals and verification mechanism adaptation information, including: Based on the dynamic baud rate negotiation rules, standard compressed data block information and transmission rate comparison benchmark information are obtained, and features of compressed block integrity, current baud rate adaptability and bit error rate stability are extracted. The integrity characteristics of compressed blocks are verified to identify data block loss and compression / decompression anomalies, and a block integrity coefficient is generated. Verify the current baud rate adaptability characteristics, check the mismatch between the 1.5Mbps / 921600bps hierarchical rate and file transfer requirements, and generate a rate adaptability accuracy factor. Verify the bit error rate stability characteristics to confirm whether the bit error rate is controlled within the target range during continuous transmission and whether there is a risk of three consecutive data block verification failures, and generate a bit error rate stability coefficient. Based on the preset baud rate negotiation rules, the block integrity coefficient, rate adaptation accuracy factor and error stability coefficient are processed. The baud rate level is adjusted by a dynamic rate switching mechanism, the forward error correction coding is used to compensate for errors, and the check node is optimized to improve the check efficiency, thereby generating the rate negotiation preprocessing result. The integrated rate negotiation preprocessing results generate a rate adjustment signal that reflects block integrity deviation, rate adaptation error and bit error risk, as well as corresponding verification mechanism adaptation information for switching baud rate levels and enabling FEC encoding.

4. The method as described in claim 1, characterized in that, The verification mechanism adaptation information and device serial port hardware resource status information are processed to generate mixed verification level and file transfer specification matching control operation information, including: The verification mechanism adaptation information, device serial port hardware resource status information and file transfer specification data are integrated. Based on the serial port hardware processing capability, the execution priority of hybrid verification is determined. At the same time, the urgency of data block transmission and the verification calculation overhead threshold are superimposed to generate an intermediate processing dataset containing verification level selection logic, verification timing control standard and initial verification scheme for different file types. Based on the verification efficiency requirements, hardware resource consumption standards, and verification rules for different file types of the intermediate processing dataset, verification level conflicts in the intermediate processing dataset are marked and filtered to generate verification adaptation anomaly records. The intermediate processing dataset and verification adaptation anomaly records are verified and merged. Constraints are imposed on the computational overhead and hardware resource adaptation of hybrid verification, as well as reasonable range constraints on the verification accuracy of different file types. Conflicts in the verification level are corrected and the hybrid verification execution logic is improved. Hybrid verification level and control operation information adapted to different file transfer specifications are generated.

5. The method as described in claim 4, characterized in that, Based on the preset large file transfer mode operation requirements and real-time bit error rate feedback, control operation information is transformed into actual file transfer actions. The system extracts and categorizes transfer mode requirements, bit error rate feedback, control operation information, and serial port hardware attributes to generate transfer mode adaptation parameters, rate calibration rules, resource usage thresholds, and file transfer and serial port protocol linkage mapping information, including: A transmission parameter correlation algorithm is used to screen key influencing factors such as the operating requirements of the preset large file transmission mode, real-time bit error rate feedback, hybrid check control operation information, and serial port hardware attribute data, generating a set of key influencing factors including baud rate adaptability, compression efficiency, check overhead, and hardware carrying capacity. Data fusion processing is performed on the set of key influencing factors, serial port transmission speed threshold, bit error rate control standard and equipment compatibility requirements, to establish the correlation mapping relationship between the elements and generate a fused feature dataset. A dynamic integration model for large file serial port transmission parameters is constructed based on a fusion feature dataset. The model uses file transmission specifications as the input dimension, key influencing factors as core parameters, and multiple constraint information as boundary conditions to generate an initial transmission parameter dataset adapted to the current scenario. Based on the large file transfer requirements of different scenarios, the initial transfer parameter dataset is decomposed into data dimensions to clarify the application priority, adjustment frequency, and anomaly response measures of transfer mode adaptation parameters, rate calibration rules, resource consumption thresholds, and protocol linkage mapping information. This generates transfer mode adaptation parameters, rate calibration rules, resource consumption thresholds, and file transfer and serial port protocol linkage mapping information that are suitable for multiple scenarios.

6. A high-speed large file transfer device from a PC to an Android device based on a serial port protocol, characterized in that, The apparatus for implementing the method of claim 1 includes: The acquisition module is used to receive large file transfer request instructions and basic serial communication configuration information between PC and Android device, and generate transfer protocol start instructions and dynamic resource configuration basic setting information. The processing module is used to initiate the LZ4 real-time compression function and trigger the hybrid verification mechanism based on the transmission protocol start command and dynamic resource configuration settings, generating initial file block information and raw data of the real-time serial port transmission rate; receiving pre-stored block compression pipeline protocol and rate data processing rules, processing the initial file block information and raw data of the real-time serial port transmission rate, generating standard compressed data block information and transmission rate comparison benchmark information; processing the standard compressed data block information and transmission rate comparison benchmark information based on dynamic baud rate negotiation rules, generating rate adjustment signals and verification mechanism adaptation information; processing the verification mechanism adaptation information and device serial port hardware resource status information, generating hybrid verification level and file transmission specification matching control operation information; based on the preset large file transmission mode operation requirements and real-time bit error rate feedback, converting the control operation information into actual file transmission actions, extracting and classifying transmission mode requirements, bit error rate feedback, control operation information and serial port hardware attributes, generating transmission mode adaptation parameters, rate calibration rules, resource occupancy thresholds, and file transmission and serial port protocol linkage mapping information.

7. An electronic device, characterized in that, include: First processor; and memory for storing executable instructions of the first processor; The first processor is configured to execute the high-speed large file transfer method from PC to Android device based on serial port protocol as described in any one of claims 1 to 5 by executing the executable instructions.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the second processor, it implements the high-speed large file transfer method from PC to Android device based on serial port protocol as described in any one of claims 1 to 5.

Images