A file transmission method, system, device and medium based on wireless module communication

Abstract

The application provides a file transmission method, system, device and medium based on wireless module communication, belongs to the technical field of file transmission, and specifically comprises the following steps: a handheld terminal broadcasts a device searching instruction after being started, and searches for a nearby host terminal; after receiving the device searching instruction of the handheld terminal, the host terminal returns relevant information; the handheld terminal lists all connectable devices for a user to select, the user selects a target host terminal, the handheld terminal requests a file list from the target host terminal; the host terminal returns a directory structure or a file name list of the host terminal to the handheld terminal, and enters a file transmission stage; after receiving a file transmission request, the host terminal sends selected files in fragments; and the handheld terminal saves the received files. The application effectively solves the defects of traditional wired transmission and wireless transmission in operation complexity, device pairing efficiency, transmission reliability and the like, and is suitable for the interactive requirements of industrial or commercial scenes such as queuing machines and handheld terminals.

Description

Technical Field

[0001] This invention belongs to the field of file transfer technology, specifically relating to a file transfer method, system, device, and medium based on wireless module communication. Background Technology

[0002] In the current field of wireless communication, especially in short-range, low-power application scenarios, 433MHz wireless transceiver modules are widely used due to their strong penetration ability and wide coverage.

[0003] File transfer in related technologies requires a network connection, which cannot be performed in environments with unstable or no network, thus limiting its application scenarios. Traditional wireless devices (such as Wi-Fi devices) require manual input of IP addresses and MAC addresses or completion of complex pairing processes to establish a connection. For queuing machines and multiple handheld terminals, each device needs to be configured individually, which is time-consuming and prone to errors.

[0004] In related technologies, after receiving a response from the host terminal, the handheld terminal lists the devices in the order they were received, which results in the omission of crucial information such as signal strength and device model. In log file transmission scenarios, if the user mistakenly selects a host terminal with a weak signal, such as a device that is too far away, it will lead to low log transmission rates, frequent retransmissions, especially for large log files, and may even result in transmission failures requiring a restart.

[0005] The file list returned by the host is often arranged in storage order, without distinguishing between folders and files, and is not sorted by type / time. In log file processing scenarios, the host typically stores multiple log files named by date, such as log_20240101, log_20240102, etc. Unordered lists require users to search for the target log line by line, which is time-consuming and error-prone, especially when there are many log files. Moreover, handheld terminals do not bind the target device ID when sending file requests. If multiple host terminals of the same model exist in the same area, signal superposition may cause the request to be received by the wrong host, resulting in the log file being transmitted to the wrong device, affecting the efficiency of troubleshooting. Summary of the Invention

[0006] This invention provides a file transfer method based on wireless module communication. Through the integrated design of wireless communication module, automated device discovery, reliable transmission mechanism and multi-format support, it effectively solves the shortcomings of traditional wired transmission and simple wireless transmission in terms of operation complexity, device pairing efficiency, transmission reliability and multi-scenario adaptability. It is suitable for the daily file interaction needs of industrial or commercial scenarios such as queuing machines and handheld terminals.

[0007] The methods include: S101: Deploy wireless transceiver modules on both the host and handheld terminals; S102: After the handheld terminal is started, it broadcasts a device search command and enters the device discovery phase to search for nearby host terminals; S103: After receiving the broadcast command to find the device, the host verifies the validity of the command; after successful verification, it reads its own device ID, model, and current system timestamp, assembles the response information according to the preset format, and sends it back to the handheld terminal; S104: Based on the information returned by the host, the handheld terminal lists all connectable devices for the user to select. After the user selects the target host, the handheld terminal requests a file list from the target host and enters the file browsing stage. S105: After receiving the file list request from the handheld terminal, the host terminal returns its own directory structure or file name list to the handheld terminal. The handheld terminal displays the file list, and the user selects the file to be transferred on the handheld terminal and triggers a send request, thus entering the file transfer stage. S106: After receiving the file transfer request, the host will send the selected file in segments; after receiving the file, the handheld terminal will perform a CRC check to confirm its integrity. If the check is successful, it will prompt the file save path and complete the file reception and saving.

[0008] It should be further explained that step S104 specifically includes: S1041: After receiving the device identification information returned by the host, the handheld terminal parses the device information, extracts the device type and signal strength parameters, and filters the list of connectable devices according to preset filtering conditions. S1042: The handheld terminal will visualize the filtered valid device information according to preset rules; S1043: The handheld terminal generates device selection status feedback information in real time, displays the selected mark in the device entry, and provides feedback on the current selection progress to the user interface until the user confirms the final target host. S1044: After confirming the target host, the handheld terminal generates a file list request message containing the current device's unique identifier and session sequence number, and sends it to the selected target host through the 433MHz wireless transceiver module to request the host's file directory structure and file metadata.

[0009] It should be further explained that step S1041 specifically includes: S10411: The handheld terminal receives the device identification information transmitted back from the host through the wireless transceiver module. The device identification information adopts a predefined string format and uses delimiters to separate each field, thus completing the reception and format recognition of the raw data. S10412: The handheld terminal calls the built-in parsing module to split the string by the delimiter, extract the device type field and signal strength field, and convert the string form of the signal strength into an unsigned integer value; S10413: The handheld terminal reads the user's pre-stored filtering condition configuration and forms a set of filtering rules; S10414: For each device entry, the handheld terminal sequentially performs a dual judgment on whether the device type is in the allowed list and whether the signal strength value is greater than the threshold. If both conditions are met, the entry is retained; otherwise, it is marked as invalid and removed from the list of connectable devices, and finally a filtered list of valid devices is generated.

[0010] It should be further noted that S10413 specifically includes the following steps: Step S104131: The handheld terminal reads multi-level filtering conditions from the preset user configuration file, specifically including the first level of device type whitelist, the second level of signal strength threshold range, and the third level of device status identifier. Step S104132: The handheld terminal maps the read filtering conditions with the real-time received device information, cross-compares the device type field with the whitelist, matches the signal strength field with the threshold range, and logically associates the device status field with the availability status to generate composite filtering rules. Step S104133: The handheld terminal introduces a priority weight mechanism, assigning different weight coefficients to device type matching degree, signal strength adaptability, and device status availability, and dynamically adjusting the weight allocation according to user-defined preference settings; Step S104134: The handheld terminal calculates a comprehensive score based on priority weights, generates a matching score for each device entry, and generates a priority list by sorting the scores from high to low. Only device entries with scores higher than a preset threshold are retained as the final list of connectable devices.

[0011] It should be further noted that step S104131 also includes the following steps: Step S104131: While reading the user's preset filtering condition configuration, the handheld terminal loads the scene strategy package obtained from the most recent network synchronization; Step S104132: The handheld terminal performs an intersection operation on the list of allowed service types in the scenario policy package and the user's local preset list to generate a composite allowed list that takes effect in real time. When the composite allowed list is updated, the user is prompted with the change in a graphical manner. Step S104133: The handheld terminal introduces an editable exception channel marker. The user can manually mark any device entry as an exception device by a single touch gesture. Exception devices skip type checks in subsequent filtering and only retain signal strength checks. Step S104134: The handheld terminal establishes a rolling log area in the storage medium to record the generation time of each composite allow list, the version number of the source policy package, and the number of intersection results. The log area is cyclically overwritten according to the first-in-first-out principle for subsequent traceability.

[0012] It should be further explained that step S106 specifically includes the following steps: Step S1061: Before sending each fragment, the host first broadcasts the physical layer timestamp of the fragment through the wireless transceiver module. The handheld terminal compares the timestamp with the local clock. If the time deviation exceeds the preset tolerance, the fragment is marked as a fragment abnormal and the fragment is retried first in the subsequent verification stage. Step S1062: While receiving the file segments, the handheld terminal automatically switches to speaker notification mode, replacing the screen notification with sound announcements to indicate the file saving progress. Step S1063: The host appends a variable-length tail identifier sequence generated by a hardware random source to the end of the file. The sequence length is related to the total number of bytes in the file. The handheld terminal only considers the file transmission to be finished after receiving the complete tail identifier sequence. If the tail identifier sequence is missing or the length is incorrect, it will force a rollback to the previous segment to receive it again. Step S1064: After the handheld terminal completes the file saving, it sends an acknowledgment frame to the host terminal through the wireless transceiver module. The acknowledgment frame does not contain any file content data, but only contains a unique identifier for this session and a success mark.

[0013] It should be further explained that step S1061 specifically includes: S10611: When the host encapsulates each data fragment, it calls the on-chip hardware clock module to obtain the current physical layer timestamp, writes the timestamp into the header field of the fragment, and adds the system timestamp corresponding to the fragment generation time to the tail of the fragment, forming a dual timestamp structure of physical layer timestamp and system timestamp. S10612: When the host terminal broadcasts fragments through the wireless transceiver module, it uses frequency hopping spread spectrum technology to select the channel and transmits the fragment header information containing dual timestamps at a fixed power to ensure that the handheld terminal can still stably receive timestamps in complex electromagnetic environments. S10613: After receiving the fragment, the handheld terminal parses the physical layer timestamp in the fragment header, calculates the difference between it and the current time of the local RTC real-time clock, and obtains the time deviation value Δt. S10614: Preset time deviation tolerance. If Δt exceeds the range, the handheld terminal will mark the fragment as a fragment abnormal and record the deviation value, fragment sequence number and reception time in the reception log. At the same time, it will adjust the reception window of subsequent fragments and prioritize requesting the retransmission of the first two fragments of the current fragment from the host.

[0014] This application also provides a file transfer system based on wireless module communication, the system including: a host terminal and a handheld terminal; Deploy wireless transceiver modules on both the host and handheld terminals; After the handheld terminal is started, it broadcasts a device search command and enters the device discovery phase, searching for nearby host terminals. After receiving the device search command from the handheld terminal, the host computer sends back its own device ID, model, and timestamp, responds to the handheld terminal, and displays its own device identification information. Based on the information returned by the host, the handheld terminal lists all connectable devices for the user to select. After the user selects the target host, the handheld terminal requests a file list from the target host and enters the file browsing stage. After receiving the file list request from the handheld terminal, the host returns its own directory structure or file name list to the handheld terminal. The handheld terminal displays the file list, and the user selects the file to be transferred on the handheld terminal and triggers a send request, thus entering the file transfer stage. After receiving a file transfer request, the host will send the selected file in segments. After receiving the file, the handheld terminal will perform a CRC check to confirm its integrity. If the check is successful, it will display the file save path and complete the file reception and saving.

[0015] According to another embodiment of this application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the file transfer method based on wireless module communication.

[0016] According to another embodiment of this application, a storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the file transfer method based on wireless module communication.

[0017] As can be seen from the above technical solutions, the present invention has the following advantages: This invention provides a file transfer method based on wireless module communication. Wireless communication is achieved through a 433MHz wireless transceiver module, eliminating the need for a physical connection between the host and handheld terminal; file transfer is entirely completed via wireless signals. Simultaneously, the unified communication software incorporates device discovery and file selection functions, allowing users to complete transfers simply through the interface. Upon receiving a device search broadcast command from the handheld terminal, the host automatically sends back device ID, model, and other information. The handheld terminal automatically generates a list of connectable devices based on this information, and the user can initiate a connection simply by selecting the target host. A CRC check mechanism is used to verify the integrity of the transmitted file; if the check fails, a retransmission is triggered to ensure complete consistency between the received and sent files. Furthermore, a file fragmentation strategy reduces the impact of single-packet loss on the overall file. Automatic recognition and transmission of formats such as text files, log files, and configuration files are supported; the handheld terminal selects the save path based on the file extension, eliminating the need for user-specified formats. This invention provides a handheld terminal that sorts device lists by signal strength from highest to lowest, displaying device ID, model, signal icon, and last response time. When a user needs to transmit fault logs from a host, they can intuitively select a device with full signal strength, reducing log transmission delays caused by poor signal and improving transmission efficiency. The host generates a list containing filenames, sizes, and creation times, sorted by folder priority and filename in ascending order. The host's log folder is at the top, and internal log files are arranged in ascending date, allowing users to quickly locate the most recent fault logs and reducing search time. The host returns a structured file list, facilitating quick file location for users. A confirmation mechanism after file selection reduces errors and ensures accurate transmission. Fragmented transmission adapts to the characteristics of wireless channels, CRC checksums and retransmission mechanisms ensure file integrity, and file save path prompts facilitate user retrieval, improving transmission success rate and user experience. This effectively improves the efficiency and reliability of file transmission. Attached Figure Description

[0018] To more clearly illustrate the technical solution of the present invention, the accompanying drawings used in the description will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 Here is a flowchart of a file transfer method based on wireless module communication; Figure 2 This is a flowchart illustrating an embodiment of a file transfer method based on wireless module communication. Figure 3 This is a schematic diagram of a file transfer system based on wireless module communication. Figure 4 This is a schematic diagram of an electronic device. Detailed Implementation

[0020] The file transfer method based on wireless module communication involved in this application will be described in detail below. Specific details such as particular system architectures and technologies are set forth for illustrative purposes and not for limitation, so as to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without these specific details.

[0021] The file transfer system based on wireless module communication provided in this application involves a host end and a receiver end. Both the host end and the receiver end can be electronic devices, which can be implemented in various forms. For example, the terminals described in the embodiments of this invention can include mobile terminals such as mobile phones, smartphones, laptops, digital broadcast receivers, personal digital assistants (PDAs), tablet computers (PADs), portable multimedia players (PMPs), navigation devices, etc., as well as fixed terminals such as digital TVs, desktop computers, etc.

[0022] The wireless internet access technologies involved between the host and receiver can include wireless local area networks (Wi-Fi, WLAN), wireless broadband (Wibro), global microwave interconnection access (WiMAX), high-speed downlink packet access (HSDPA), and so on.

[0023] Optionally, the host device can be a queuing machine, and the receiver device can be a handheld terminal.

[0024] It should be understood that, when used in this specification, terms include indicating the presence of a described feature, integral, step, operation, element, and / or component, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof. The terms include, encompass, have, and variations thereof mean including but not limited to, unless otherwise specifically emphasized.

[0025] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0026] Please see Figure 1The diagram shows a flowchart of a file transfer method based on wireless module communication in a specific embodiment. The method includes: Step S101: Deploy wireless transceiver modules on both the host and handheld terminals.

[0027] In some embodiments, both the host and handheld terminals use the same 433MHz wireless transceiver module. The wireless transceiver module integrates an RF switch, a power amplifier, and a crystal oscillator. The 433MHz wireless transceiver module needs to support an adjustable baud rate of 1.2kbps-9.6kbps. The host module is connected to the main control MCU via a UART interface, and the receiver module is connected to the embedded processor via an SPI interface. The channel bandwidth of both modules is uniformly set to 25kHz to reduce interference in the same frequency band.

[0028] Optionally, the host and handheld terminals each have communication software. During pre-installation, the device initialization configuration is completed, including writing the MAC address of the host / receiver and the default communication channel, and running a device heartbeat detection thread in the background of the software.

[0029] Encrypted transmission is enabled by default. The software's built-in encryption module can automatically generate a 16-byte initial key, which is stored in the device's non-volatile memory and is not lost when the device restarts. In addition to displaying the status in text, the status feedback function also supports prompting key milestones via vibration or a buzzer.

[0030] Step S102: After the handheld terminal starts up, it broadcasts a device search command and enters the device discovery phase to search for nearby host terminals.

[0031] In some embodiments, after the handheld terminal is started, the communication software automatically triggers the generation of a device search command. The command format is [terminal type][function code][timeout][checksum], where the terminal type field is fixed as HT, the function code is 01, and the timeout can be adjusted through the terminal settings interface.

[0032] The broadcast uses an interval-increasing method, with a 1-second interval for the first 5 broadcasts, and an additional 1-second interval for every 5 broadcasts thereafter, to avoid continuous high-frequency broadcasts occupying channel resources.

[0033] In this embodiment, the handheld terminal triggers the host terminal response within the coverage area by periodically broadcasting standardized commands. The incremental broadcast interval strategy balances search efficiency and channel occupancy, and the timeout mechanism avoids meaningless continuous searching.

[0034] Step S103: After receiving the broadcast device search command, the host verifies the legality of the command; after successful verification, it reads its own device ID, model, and current system timestamp, assembles the response information according to the preset format, and sends it back to the handheld terminal.

[0035] In some embodiments, after receiving a device search command, the wireless module on the host side first verifies the legality of the command through a verification code. After successful verification, the main control MCU reads the device ID, model, and current system timestamp from the memory within 50ms, and concatenates them into response information in the format of device ID|model|timestamp.

[0036] The response information is sent via the wireless module, and the transmission power is related to the signal strength when receiving the command. When the host displays the response status, if it is equipped with a screen, the device ID of the handheld terminal is highlighted in red font. If there is no screen, it is distinguished by the flashing frequency of the indicator light.

[0037] As can be seen, after verifying the validity of the command through the check code, the host extracts its own key information to generate response data, which is then transmitted back to the handheld terminal via the wireless module. The dynamic adjustment of the transmission power ensures the reachability of the response information in complex environments, while the display or indicator light prompts inform on-site personnel that the device has been discovered.

[0038] Step S104: Based on the information returned by the host, the handheld terminal lists all connectable devices for the user to select. After the user selects the target host, the handheld terminal requests a file list from the target host and enters the file browsing stage.

[0039] In some embodiments, after receiving the response information from the host, the handheld terminal splits the fields according to the delimiter, extracts the device ID, model, and timestamp, and generates a list of connectable devices by combining the signal strength at the time of reception. The list is sorted from high to low signal strength.

[0040] In this embodiment, each device in the list displays the following items: device ID, model, signal strength icon, and last response time. When a user taps a device on the touchscreen, a confirmation box pops up on the terminal. After confirmation, a file list request command is generated, appending the host's device ID to ensure the uniqueness of the request. Once the file browsing stage begins, the screen displays the browsing devices. This multi-dimensional device information display and signal strength sorting help users select the optimal connection target, and weak signal marking reduces subsequent transmission failures caused by poor signal strength. Secondary confirmation and targeted request commands avoid the risk of misselecting devices, and clear stage prompts allow users to clearly understand the operation progress.

[0041] Step S105: After receiving the file list request from the handheld terminal, the host terminal returns its own directory structure or file name list to the handheld terminal. The handheld terminal displays the file list, and the user selects the file to be transferred on the handheld terminal and triggers a send request, thus entering the file transfer stage.

[0042] After receiving the file list request in this embodiment, the host first verifies whether the device ID in the request matches itself. If the match is successful, the file management module traverses the local storage directory and generates a list of data containing file name, size, creation time, and file type, sorted by folder priority and file name in ascending order.

[0043] The list data is transmitted in frames via the wireless module. The first frame contains the total number of files and the total number of frames, and subsequent frames are transmitted sequentially according to their sequence numbers. After receiving the data, the handheld terminal reassembles the list according to the frame sequence numbers and uses different icons to distinguish file types when displaying the data. The request includes a unique identifier for each file.

[0044] Step S106: After receiving the file transfer request, the host terminal sends the selected file in segments; after receiving the file, the handheld terminal performs a CRC check to confirm its integrity. If the check is successful, it displays the file save path and completes the file reception and saving.

[0045] In this embodiment, after receiving the sending request, the host locates the target file by the file's unique identifier, and segments it into 1KB packets. Each packet header contains the total number of packets, the current packet sequence number, and the packet checksum. The segments are sent continuously through the wireless module, with an interval of no more than 100ms between adjacent packets.

[0046] When the handheld terminal receives fragments, it first checks whether the packet sequence numbers are consecutive. If they are not consecutive, it records the missing sequence numbers. After each packet is received, it calculates the checksum and compares it with the header checksum. If they match, they are temporarily stored in the buffer. If they do not match, the packet is marked as invalid. After all packets are received, if there are missing or invalid packets, the handheld terminal sends a retransmission request, and the host only retransmits the specified packets.

[0047] After successful verification, the handheld terminal will stitch the cached data into a complete file, automatically classify and store it according to file type, and display it after saving.

[0048] This embodiment of fragmented transmission reduces the amount of data per frame, minimizing the risk of entire file loss due to interference during wireless transmission. Sequence number checking prevents data packets from being out of order. Targeted retransmission reduces the amount of data transmitted repeatedly, improving transmission efficiency.

[0049] In one embodiment of the present invention, based on step S104, the following will provide a possible embodiment and its specific implementation will be described in a non-limiting manner. For example... Figure 2 As shown, step S104 specifically includes: S1041: After receiving the device identification information returned by the host, the handheld terminal parses the device information, extracts the device type and signal strength parameters, filters the list of connectable devices according to preset filtering conditions, and removes device entries that do not meet the conditions. S1042: The handheld terminal will visualize the filtered valid device information according to preset rules. The displayed content includes device name, model, signal strength icon, and device online status indicator. At the same time, it supports users to browse the list of devices that are outside the display range by swiping the touch screen or turning pages by pressing the button. S1043: When the user selects the target host by pressing the button, the handheld terminal generates device selection status feedback information in real time, displays the selected mark at the device entry, and provides feedback on the current selection progress to the user interface until the user confirms the final target host. S1044: After confirming the target host, the handheld terminal generates a file list request message containing the current device's unique identifier and session sequence number, and sends it to the selected target host via the 433MHz wireless transceiver module, requesting to obtain the host's file directory structure and file metadata. The file metadata includes filename, file size, creation time, and file type identifier.

[0050] It should be noted that the preset filtering conditions can be a whitelist of device types and a signal strength threshold preset during the communication software initialization phase. The visual display arranges the list of valid devices in descending order of signal strength, with stronger signals appearing first. Devices of the same strength are arranged in ascending order of their device IDs, forming a priority queue.

[0051] This embodiment enables users to efficiently filter and accurately select connectable devices through intelligent device information filtering, enhanced visual interaction, and a two-way status feedback mechanism, and triggers the file list interaction process on the target host through standardized request messages.

[0052] In one embodiment of the present invention, based on step S1041, the following will provide a possible embodiment and its specific implementation will be described in a non-limiting manner. Step S1041 specifically includes: S10411: The handheld terminal receives the device identification information transmitted back from the host through the 433MHz wireless transceiver module. The device identification information adopts a predefined string format, and the fields are separated by delimiters to complete the reception and format recognition of the raw data.

[0053] Optionally, the string format can be device ID, model, signal strength, and device type.

[0054] S10412: The handheld terminal calls the built-in parsing module to split the string by the delimiter, extract the device type field and signal strength field, and convert the string form of the signal strength into an unsigned integer value; S10413: The handheld terminal reads the user's pre-stored filtering condition configuration, including the list of allowed service types and the minimum signal strength threshold, to form a filtering rule set; S10414: For each device entry, the handheld terminal sequentially performs a dual judgment on whether the device type is in the allowed list and whether the signal strength value is greater than the threshold. If both conditions are met, the entry is retained; otherwise, it is marked as invalid and removed from the list of connectable devices, and finally a filtered list of valid devices is generated.

[0055] As can be seen, this embodiment extracts key parameters by parsing the original device information returned by the host and logically comparing them with user-defined service type restrictions and signal strength lower limits. Only device entries that meet all the rules are retained, thereby reducing invalid user selections and improving the accuracy and efficiency of device discovery.

[0056] It should be noted that this embodiment can convert signal strength in string format into comparable integer values. A string truncation function is used to extract substrings, and an integer conversion function is used to convert them into numerical values; if the string format is abnormal, it is marked as an invalid signal strength.

[0057] To determine whether a device type meets the user's preset service type restrictions, a prefix matching method is used. Prefix matching considers that if the user's allowed service type is queuing machine, then a device type of queuing machine is considered a match.

[0058] To determine whether a device should remain in the valid list, the valid criteria are: (Device type matches) AND (Signal strength value ≥ threshold).

[0059] If the device type matches (true), the device is valid if it fits the allowed list and the signal strength value is greater than or equal to the threshold; otherwise, the device is invalid and removed.

[0060] In one embodiment of the present invention, based on step S10413, the following is a possible embodiment and its specific implementation will be described in a non-limiting manner. S10413 specifically includes the following steps: Step S104131: The handheld terminal reads multi-level filtering conditions from the preset user configuration file, specifically including the first level of device type whitelist, such as queuing machines, self-service terminals, and barcode scanners; the second level of signal strength threshold range; and the third level of device status indicators, such as online, offline, and under maintenance. Different configuration files are dynamically loaded according to the user's permission level.

[0061] Step S104132: The handheld terminal maps the read filtering conditions with the real-time received device information, cross-compares the device type field with the whitelist, matches the signal strength field with the threshold range, and logically associates the device status field with the availability status to generate composite filtering rules.

[0062] Step S104133: The handheld terminal introduces a priority weight mechanism, assigning different weight coefficients to device type matching degree, signal strength adaptability, and device status availability, and dynamically adjusting the weight allocation according to user-defined preference settings.

[0063] Step S104134: The handheld terminal calculates a comprehensive score based on priority weights, generates a matching score for each device entry, and generates a priority list by sorting the scores from high to low. Only device entries with scores higher than a preset threshold are retained as the final list of connectable devices.

[0064] It should be noted that the comprehensive score and priority ranking method can be based on the score calculation method: for each device item, calculate the type matching degree separately. The type matching degree can be set to 0-100 points, the signal strength adaptability can be set to 0-100 points, and the status availability can be set to 0-100 points. Then, the comprehensive score is obtained by weighted summation according to the weights.

[0065] For example: Overall score = (Type matching degree × 0.5) + (Signal strength adaptability × 0.3) + (State availability × 0.2). Set an overall score threshold and only retain devices with scores higher than the threshold to ensure that the final list only contains devices with high matching degree.

[0066] The device status availability scoring method in this embodiment can be configured with the following device status scoring rules:

[0067] This embodiment also implements hierarchical management of user permissions, loading different filtering configuration files according to user roles. Administrators can configure stricter filtering conditions, while ordinary users can only access basic filtering rules.

[0068] This embodiment ensures data processing consistency and accuracy by parsing standardized device information and converting signal strength formats; multi-level filtering conditions combined with user permission management make the filtering rules more aligned with actual usage scenarios and user needs; priority weighting mechanisms and comprehensive scoring ranking help users quickly locate highly matching devices and reduce invalid selections; prefix matching and dual valid condition judgment improve the accuracy of device filtering; at the same time, the recording of relevant operations and results facilitates subsequent traceability. The entire process, from data reception, parsing, filtering to result generation, comprehensively improves the efficiency and reliability of device discovery and enhances the system's practicality and flexibility.

[0069] In one embodiment of the present invention, based on step S104131, the following is a possible embodiment and its specific implementation will be described in a non-limiting manner. Step S104131 further includes the following steps: Step S104131: While reading the user's preset filtering condition configuration, the handheld terminal loads the scene policy package obtained from the most recent network synchronization. The scene policy package contains a list of allowed service types that are dynamically updated according to geographical location, time window, and service priority.

[0070] Step S104132: The handheld terminal performs an intersection operation on the list of allowed service types in the scenario policy package and the user's local preset list to generate a composite allowed list that takes effect in real time. When the composite allowed list is updated, the user is prompted with the changes in a graphical manner.

[0071] Step S104133: The handheld terminal introduces an editable exception channel marker. The user can manually mark any device entry as an exception device by a single touch gesture. Exception devices skip type checks in subsequent filtering and only retain signal strength checks.

[0072] Step S104134: The handheld terminal establishes a rolling log area in the storage medium to record the generation time of each composite allow list, the version number of the source policy package, and the number of intersection results. The log area is cyclically overwritten according to the first-in-first-out principle for subsequent traceability.

[0073] It should be noted that after the handheld terminal is powered on, the embedded processor receives scene policy packets periodically sent by the remote server via a 433MHz wireless transceiver module and writes them to the policy cache area of ​​non-volatile memory. When the processor starts the filtering process, it first reads the scene policy packet version number from the policy cache area and compares it with the version number of the local preset list. If the version numbers are different, the intersection operation unit is activated to perform a bitwise AND operation on the two lists to obtain a composite allowed list and immediately refresh the prompt icon on the touch screen. If the user performs a long press gesture on a device item through the capacitive touch screen, the processor writes the device ID to the exception channel register. The exception channel register directly masks the type comparison result in the subsequent double judgment stage. Whenever the composite allowed list is updated or the exception channel register is changed, the processor appends a record to the rolling log area. The record includes the current system clock value, policy packet version number, and list length. When the log area is full, the oldest entry is automatically overwritten to ensure that the storage space remains constant.

[0074] In step S104131 of this embodiment, the scenario strategy package format can be a fixed-length record sequence, and each record consists of a geolocation encoding field, a time window start field, a time window end field, and a business type bitmap field; the processor determines whether the record is effective by comparing the current GPS coordinates with the geolocation encoding field.

[0075] This embodiment combines scenario strategy packages with local preset lists to generate a composite allowed list, enabling filtering rules to adapt to dynamically changing scenarios and improving the flexibility and applicability of filtering. Graphical prompts for list changes allow users to be promptly informed of changes in filtering conditions. The exception channel marking function meets device connection needs in special circumstances, enhancing operational convenience. The rolling log area facilitates subsequent traceability of the filtering process, improving system maintainability and reliability. The overall process, from filtering rule generation and user prompts to special handling and record traceability, comprehensively optimizes the device filtering stage.

[0076] In one embodiment of the present invention, based on step S106, the following is a possible embodiment and its specific implementation will be described in a non-limiting manner. Step S106 specifically includes the following steps: Step S1061: Before sending each fragment, the host first broadcasts the physical layer timestamp of the fragment through the 433MHz wireless transceiver module. The handheld terminal compares the timestamp with the local clock. If the time deviation exceeds the preset tolerance, the fragment is marked as a fragment abnormal and the fragment is retried first in the subsequent verification stage.

[0077] Step S1062: While receiving the file segments, the handheld terminal automatically switches to speaker notification mode, replacing the screen notification with sound announcements to indicate the file saving progress.

[0078] Step S1063: The host appends a variable-length tail identifier sequence generated by a hardware random source to the end of the file. The sequence length is related to the total number of bytes in the file. The handheld terminal only considers the file transmission to be over after receiving the complete tail identifier sequence. If the tail identifier sequence is missing or the length is incorrect, it will force a rollback to the previous segment to receive it again.

[0079] Step S1064: After the handheld terminal completes the file saving, it sends an acknowledgment frame to the host terminal through the 433MHz wireless transceiver module. The acknowledgment frame does not contain any file content data, but only contains a unique identifier for this session and a success mark. After receiving the acknowledgment frame, the host terminal immediately lights up the local LED indicator and keeps it lit for a fixed duration to visually inform the on-site operators that the transmission loop has been completed.

[0080] It should be noted that the fragment transmission process on the host side is completed by the main control MCU driving the 433MHz wireless transceiver module. Each fragment is encapsulated into a fixed-length frame, with the frame header carrying the fragment sequence number, physical layer timestamp, and tail identifier length indicator. Before transmission, the MCU reads the hardware random source, appends the random tail identifier sequence to the end of the file, and writes it into the FIFO of the 433MHz module via the SPI bus.

[0081] After an interrupt is triggered by the 433MHz module, the embedded processor in the handheld terminal reads the FIFO, first parsing the timestamp field and comparing it with the local 32kHz real-time clock, recording the deviation value; then, it writes the segmented data into the buffer, reserving space for a tail identifier sequence at the end of the buffer. The processor reads the ambient light sensor ADC value in parallel and determines whether to enable the speaker driver circuit based on the threshold register.

[0082] Once the buffer detects the complete tail identifier sequence, the processor closes the 433MHz receive window, writes the buffer contents to the SD card, and then sends an acknowledgment frame via unicast. Upon receiving this frame, the host pulls the LED driver pin high on the GPIO port, and automatically pulls it low after the timer expires, completing the closed-loop indication.

[0083] This embodiment uses physical layer timestamp comparison to promptly detect abnormal fragments and prioritize retries, improving data reception accuracy. A speaker notification mode supplements screen prompts, allowing users to clearly understand the transmission progress in complex environments. A variable-length tail identifier sequence ensures the integrity of file transmission, preventing files from becoming invalid due to missing data. Confirmation frames and LED indicators form a transmission loop, allowing on-site personnel to intuitively understand the transmission completion status. The entire process, from data transmission and reception verification to status feedback, comprehensively guarantees the reliability, ease of use, and closed-loop traceability of wireless file transmission.

[0084] In one embodiment of the present invention, based on step S1061, the following will provide a possible embodiment and its specific implementation will be described in a non-limiting manner. Step S1061 specifically includes: S10611: When encapsulating each data fragment, the host calls the on-chip hardware clock module to obtain the current physical layer timestamp, writes the timestamp into the header field of the fragment, and adds the system timestamp corresponding to the fragment generation time to the tail of the fragment, forming a dual timestamp structure of physical layer timestamp and system timestamp. S10612: When the host unit broadcasts fragments through the 433MHz wireless transceiver module, it uses frequency hopping spread spectrum technology to select the channel and transmits the fragment header information containing dual timestamps at a fixed power to ensure that the handheld terminal can still receive timestamps stably in complex electromagnetic environments. S10613: After receiving the fragment, the handheld terminal parses the physical layer timestamp in the fragment header, calculates the difference between it and the current time of the local RTC real-time clock, and obtains the time deviation value Δt.

[0085] Optionally, Δt = fragmented physical layer timestamp - local RTC time.

[0086] S10614: Preset time deviation tolerance. If Δt exceeds this range, the handheld terminal marks the fragment as a fragment abnormal and records the deviation value, fragment sequence number and reception time in the reception log. At the same time, it adjusts the reception window of subsequent fragments and prioritizes requesting the retransmission of the first two fragments of the current fragment from the host. If the current fragment sequence number is n, it prioritizes retransmitting fragments n-2 and n-1 to avoid subsequent fragment order disorder due to loss of synchronization.

[0087] This embodiment uses dual timestamp synchronization detection of physical layer timestamp and local clock to determine in real time whether there is clock drift or abnormal channel delay in fragment transmission; after marking the fragment with abnormality, the strategy of prioritizing the retransmission of previous fragments is adopted to correct the transmission out-of-order problem caused by clock asynchrony in advance, thereby improving the integrity and reliability of file transmission.

[0088] Optionally, an m-sequence is used to generate a pseudo-random channel selection sequence, such as an m-sequence of length 16 with a period of 2¹. 5 -1, select the next communication channel every 100ms based on the sequence value. Ensure that the transmission channels of adjacent fragments are not duplicated. Reduce the impact of multipath interference on timestamp reception by switching channels.

[0089] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0090] The following are embodiments of a file transfer system based on wireless module communication provided in this disclosure. This system and the file transfer methods based on wireless module communication in the above embodiments belong to the same inventive concept. For details not described in detail in the embodiments of the file transfer system based on wireless module communication, please refer to the embodiments of the file transfer methods based on wireless module communication described above.

[0091] like Figure 3 As shown, the system includes: a host terminal 201 and a handheld terminal 202; Wireless transceiver modules are deployed on the host terminal 201 and the handheld terminal 202, respectively; After the handheld terminal 202 starts up, it broadcasts a device search command and enters the device discovery phase, searching for nearby host terminal 201 devices; After receiving the device search command from the handheld terminal 202, the host device 201 sends back its own device ID, model, and timestamp, responds to the handheld terminal 202, and displays its own device identification information; Based on the information returned by the host terminal 201, the handheld terminal 202 lists all connectable devices for the user to select. After the user selects the target host terminal 201 device, the handheld terminal 202 requests a file list from the target host terminal and enters the file browsing stage. After receiving the file list request from the handheld terminal 202, the host device 201 returns its own directory structure or file name list to the handheld terminal 202. The handheld terminal 202 displays the file list. The user selects the file to be transferred on the handheld terminal 202 and triggers a send request, thus entering the file transfer stage. After receiving the file transfer request, the host device 201 will send the selected file in segments; after receiving the file, the handheld terminal 202 will perform a CRC check to confirm its integrity. If the check is successful, it will prompt the file save path and complete the file reception and saving.

[0092] like Figure 4 As shown, this application also provides an electronic device, including a display module 103, a memory 102, a processor 101, and a computer program stored in the memory and executable on the processor 101. When the processor 101 executes the program, it implements the steps of a file transfer method based on wireless module communication.

[0093] In embodiments of the present invention, electronic devices include, but are not limited to, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic devices may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the embodiments described and / or claimed herein.

[0094] In this embodiment, processor 101 may be implemented using at least one of an application-specific integrated circuit, a programmable logic device, a field-programmable gate array, a processor, a controller, a microcontroller, a microprocessor, or an electronic unit designed to perform the functions described herein. In some cases, such an implementation may be implemented within a controller. For software implementation, implementations such as processes or functions may be implemented with separate software modules that allow the performance of at least one function or operation. Software code may be implemented by a software application (or program) written in any suitable programming language, and the software code may be stored in memory and executed by the controller.

[0095] The display module 103 is used to display information input by the user or information provided to the user. The display module 103 may include a display panel, which may be configured in the form of a liquid crystal display, an organic light-emitting diode, or the like.

[0096] The memory 102 can be used to store software programs and various data. The memory 102 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0097] This application also provides a storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the file transfer method based on wireless module communication.

[0098] The storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example,, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0099] In a storage medium, a readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying readable program code. This propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0100] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A file transfer method based on wireless module communication, characterized in that, The methods include: S101: Deploy 433MHz wireless transceiver modules on both the host and handheld terminals; S102: After the handheld terminal starts up, it broadcasts a device search command and enters the device discovery phase to search for nearby host terminals; S103: After receiving the broadcast device search command, the host verifies the validity of the command; After successful verification, the device reads its own device ID, model, and current system timestamp, assembles the response information according to the preset format, and sends it back to the handheld terminal. S104: Based on the information returned by the host, the handheld terminal lists all connectable devices for the user to select. After the user selects the target host, the handheld terminal requests a file list from the target host and enters the file browsing stage. S1041: After receiving the device identification information returned by the host, the handheld terminal parses the device information, extracts the device type and signal strength parameters, and filters the list of connectable devices according to preset filtering conditions. Step S1041 specifically includes: S10411: The handheld terminal receives the device identification information transmitted back from the host through the 433MHz wireless transceiver module. The device identification information adopts a predefined string format and uses delimiters to separate each field, thus completing the reception and format recognition of the raw data. S10412: The handheld terminal calls the built-in parsing module to split the string by the delimiter, extract the device type field and signal strength field, and convert the string form of the signal strength into an unsigned integer value; S10413: The handheld terminal reads the user's pre-stored filtering condition configuration and forms a set of filtering rules; S10413 specifically includes the following steps: Step S104131: The handheld terminal reads multi-level filtering conditions from the preset user configuration file, specifically including the first level of device type whitelist, the second level of signal strength threshold range, and the third level of device status identifier. Step S104132: The handheld terminal maps the read filtering conditions with the real-time received device information, cross-compares the device type field with the whitelist, matches the signal strength field with the threshold range, and logically associates the device status field with the availability status to generate composite filtering rules. Step S104133: The handheld terminal introduces a priority weight mechanism, assigning different weight coefficients to device type matching degree, signal strength adaptability, and device status availability, and dynamically adjusting the weight allocation according to user-defined preference settings; Step S104134: The handheld terminal calculates a comprehensive score based on priority weight, generates a matching score for each device item, and generates a priority list by sorting the scores from high to low. Only device items with scores higher than a preset threshold are retained as the final list of connectable devices. S10414: For each device entry, the handheld terminal sequentially performs a dual check on whether the device type is in the allowed list and whether the signal strength value is greater than the threshold. If both conditions are met, the entry is retained; otherwise, it is marked as invalid and removed from the list of connectable devices, and finally a filtered list of valid devices is generated. S105: After receiving the file list request from the handheld terminal, the target host returns its own directory structure or file name list to the handheld terminal. The handheld terminal displays the file list, and the user selects the file to be transferred on the handheld terminal and triggers a send request, thus entering the file transfer stage. S106: After receiving the file transfer request, the host will send the selected file in segments; after receiving the file, the handheld terminal will perform a CRC check to confirm its integrity. If the check is successful, it will prompt the file save path and complete the file reception and saving.

2. The file transfer method based on wireless module communication according to claim 1, characterized in that, Step S104 specifically includes: S1042: The handheld terminal will visualize the filtered valid device information according to preset rules; S1043: The handheld terminal generates device selection status feedback information in real time, displays the selected mark in the device entry, and provides feedback on the current selection progress to the user interface until the user confirms the final target host. S1044: After confirming the target host, the handheld terminal generates a file list request message containing the current device's unique identifier and session sequence number, and sends it to the selected target host through the 433MHz wireless transceiver module to request the host's file directory structure and file metadata.

3. The file transfer method based on wireless module communication according to claim 1, characterized in that, Step S104131 further includes the following steps: Step S104131: While reading the user's preset filtering condition configuration, the handheld terminal loads the scene strategy package obtained from the most recent network synchronization; Step S104132: The handheld terminal performs an intersection operation on the list of allowed service types in the scenario policy package and the user's local preset list to generate a composite allowed list that takes effect in real time. When the composite allowed list is updated, the user is prompted with the change in a graphical manner. Step S104133: The handheld terminal introduces an editable exception channel marker. The user can manually mark any device entry as an exception device by a single touch gesture. Exception devices skip type checks in subsequent filtering and only retain signal strength checks. Step S104134: The handheld terminal establishes a rolling log area in the storage medium to record the generation time of each composite allow list, the version number of the source policy package, and the number of intersection results. The log area is cyclically overwritten according to the first-in-first-out principle for subsequent traceability.

4. The file transfer method based on wireless module communication according to claim 1, characterized in that, Step S106 specifically includes the following steps: Step S1061: Before sending each fragment, the host first broadcasts the physical layer timestamp of the fragment through the 433MHz wireless transceiver module. The handheld terminal compares the timestamp with the local clock. If the time deviation exceeds the preset tolerance, the fragment is marked as a fragment abnormal and the fragment is retried first in the subsequent verification stage. Step S1062: While receiving the file segments, the handheld terminal automatically switches to speaker notification mode, replacing the screen notification with sound announcements to indicate the file saving progress. Step S1063: The host appends a variable-length tail identifier sequence generated by a hardware random source to the end of the file. The sequence length is related to the total number of bytes in the file. The handheld terminal only considers the file transmission to be finished after receiving the complete tail identifier sequence. If the tail identifier sequence is missing or the length is incorrect, it will force a rollback to the previous segment to receive it again. Step S1064: After the handheld terminal completes the file saving, it sends an acknowledgment frame to the host terminal through the 433MHz wireless transceiver module. The acknowledgment frame does not contain any file content data, but only contains the unique identifier of this session and a success mark.

5. The file transfer method based on wireless module communication according to claim 4, characterized in that, Step S1061 specifically includes: S10611: When the host encapsulates each data fragment, it calls the on-chip hardware clock module to obtain the current physical layer timestamp, writes the timestamp into the header field of the fragment, and adds the system timestamp corresponding to the fragment generation time to the tail of the fragment, forming a dual timestamp structure of physical layer timestamp and system timestamp. S10612: When the host unit broadcasts fragments through the 433MHz wireless transceiver module, it uses frequency hopping spread spectrum technology to select the channel and transmits the fragment header information containing dual timestamps at a fixed power to ensure that the handheld terminal can still receive timestamps stably in complex electromagnetic environments. S10613: After receiving the fragment, the handheld terminal parses the physical layer timestamp in the fragment header, calculates the difference between it and the current time of the local RTC real-time clock, and obtains the time deviation value Δt. S10614: Preset time deviation tolerance. If Δt exceeds the range, the handheld terminal will mark the fragment as a fragment abnormal and record the deviation value, fragment sequence number and reception time in the reception log. At the same time, it will adjust the reception window of subsequent fragments and prioritize requesting the retransmission of the first two fragments of the current fragment from the host.

6. A file transfer system based on wireless module communication, characterized in that, The system is used to implement the file transfer method based on wireless module communication as described in any one of claims 1 to 5; The system includes: a host computer and a handheld terminal; Deploy 433MHz wireless transceiver modules on both the host and handheld terminals; After the handheld terminal is started, it broadcasts a device search command and enters the device discovery phase, searching for nearby host terminals. After receiving the device search command from the handheld terminal, the host computer sends back its own device ID, model, and timestamp, responds to the handheld terminal, and displays its own device identification information. Based on the information returned by the host, the handheld terminal lists all connectable devices for the user to select. After the user selects the target host, the handheld terminal requests a file list from the target host and enters the file browsing stage. After receiving the file list request from the handheld terminal, the host returns its own directory structure or file name list to the handheld terminal. The handheld terminal displays the file list, and the user selects the file to be transferred on the handheld terminal and triggers a send request, thus entering the file transfer stage. After receiving a file transfer request, the host will send the selected file in segments. After receiving the file, the handheld terminal will perform a CRC check to confirm its integrity. If the check is successful, it will display the file save path and complete the file reception and saving.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the file transfer method based on wireless module communication as described in any one of claims 1 to 5.

8. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the file transfer method based on wireless module communication as described in any one of claims 1 to 5.

Images