WIFI module offline fault log uploading system and method
By constructing a fault number mapping and circular buffer storage mechanism, the problem of the inability to upload offline fault logs of WIFI modules in a timely manner is solved, realizing reliable storage and efficient traceability of fault information, which is suitable for smart homes and industrial IoT.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SICHUAN HONGMEI INTELLIGENT TECH CO LTD
- Filing Date
- 2026-01-21
- Publication Date
- 2026-04-21
AI Technical Summary
In offline scenarios, fault logs of WIFI modules cannot be uploaded in a timely manner, making it difficult for after-sales maintenance to locate the root cause of the problem. Existing technical solutions rely on network stability or occupy a large amount of storage space and lack data classification and management.
A fault number mapping system is constructed, and a circular buffer is used to store fault logs. When the WIFI module is offline, the fault number and timestamp are recorded. After power-on, the fault information is automatically uploaded to the cloud, so as to achieve reliable traceability of fault information.
It enables reliable storage and efficient uploading of fault logs in offline scenarios, reduces storage overhead, improves fault information tracing efficiency, and is suitable for scenarios such as smart homes and industrial IoT.
Smart Images
Figure CN121908314A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of communication equipment technology, and in particular to a WIFI module offline fault log uploading system and method. Background Technology
[0002] With the rapid proliferation of IoT devices, the stability of Wi-Fi modules, as a core component enabling communication between devices and the cloud, directly determines the overall reliability of IoT devices. Because IoT devices are often deployed in complex and ever-changing network environments (such as home and industrial settings) and require long-term operation, Wi-Fi modules are susceptible to factors such as network fluctuations, hardware aging, or software logic defects, leading to occasional communication interruptions and data loss. These faults are random and transient, and fault diagnosis relies on real-time log uploads from the device to the cloud for analysis. However, when the device is offline (e.g., due to Wi-Fi disconnection, abnormal power outages and restarts) or the network signal is weak, critical fault logs cannot be uploaded in a timely manner, making it difficult to pinpoint the root cause of the problem during after-sales maintenance due to a lack of effective data support.
[0003] To address the issue of offline fault log management for Wi-Fi modules, three main solutions are adopted: First, based on a real-time log upload mechanism, a continuous communication link is established between the device and the cloud to transmit log data to the server for storage in real time; second, a text-format log storage solution is adopted, recording fault information in chronological order in the device's local FLASH memory; and third, an unstructured storage management strategy is used to dynamically update log data in a cyclic overwrite manner to avoid exhausting storage space.
[0004] However, real-time upload solutions are highly dependent on network stability, and log data will inevitably be lost in offline scenarios, failing to cover fault information throughout the device's lifecycle. Secondly, text log storage occupies a large amount of FLASH space, which poses a serious burden on resource-constrained embedded devices. Furthermore, unstructured storage lacks data classification and priority management mechanisms, making it prone to storage overflow due to sudden increases in log volume, or loss of critical fault information due to disordered cyclic overwriting order. Summary of the Invention
[0005] This application provides a WIFI module offline fault log uploading system and method to solve the technical problems that current log uploads are highly dependent on network stability, log data will be lost in offline scenarios, and the system cannot cover fault information throughout the entire life cycle of the device.
[0006] The first aspect of this application provides a WIFI module offline fault log upload system, including: The communication connection fault detection module, number mapping module, FLASH storage module, communication control module, and cloud server; The fault detection module is configured as follows: Obtain the operating status of the WIFI module; Based on the operating status, determine whether the WIFI module has experienced an offline failure; If so, then determine the offline fault type of the WIFI module; The number mapping module is configured as follows: The fault number is determined based on the mapping relationship between the fault number and the offline fault type; The fault number is encapsulated into a log entry and sent to the FLASH storage module for storage; the log entry includes: the timestamp when the WIFI module experienced an offline fault, the fault number, and the upload status bit. The communication control module is configured as follows: When the WIFI module is powered on and starts up, it connects to the cloud server, sends the log entries to the cloud server, and deletes the log entries stored in the FLASH storage module.
[0007] In some embodiments, the number mapping module is configured with a fault type encoding table, which is used to store the mapping relationship between fault numbers and offline fault types; The number mapping module is also configured as follows: The fault type coding table may be modified or expanded.
[0008] In some embodiments, the FLASH storage module adopts a circular buffer structure. The circular buffer is provided with a head pointer position and a tail pointer position. The head pointer position is used to store the log entry corresponding to the largest timestamp, and the tail pointer position is used to store the log entry corresponding to the smallest timestamp. The timestamps corresponding to the log entries stored from the head pointer position to the tail pointer position decrease sequentially.
[0009] In some embodiments, the ring buffer has a capacity of 2KB; the ring buffer is capable of storing 256 log entries.
[0010] In some embodiments, the FLASH storage module is configured as follows: Receive the log entry and determine whether the circular buffer has remaining capacity; If not, the log entry corresponding to the maximum timestamp will be stored from the head pointer position, and the log entry stored at the tail pointer position will be deleted. Specifically, when the log entry corresponding to the maximum timestamp is stored at the head pointer position and the log entry stored at the tail pointer position is deleted, the log entries in the circular buffer move towards the tail pointer position.
[0011] In some embodiments, the upload status bit includes 0 and 1. When the upload status bit is 0, the log entry is in an unuploaded state; when the upload status bit is 1, the log entry is in an uploaded state. The communication control module is also configured to: Once the log entry has been sent to the cloud server, the upload status bit of the log entry is changed to 1.
[0012] In some embodiments, the communication control module is further configured to: If the WIFI module experiences an offline failure while the log entry is being sent to the cloud server, the log entry being sent will be marked as pending retry. When the WIFI module is powered on, the log entries corresponding to the pending retry state are uploaded to the cloud server. After the log entries are uploaded, the log entries with the upload status bit of 0 are uploaded to the cloud server in ascending order of timestamp.
[0013] In some embodiments, the communication control module is further configured to: If the WIFI module experiences an offline failure while the log entry is being sent to the cloud server, the remaining content of the log entry being sent will be retained. Once the WIFI module is powered on and started, the remaining contents of the log entries are uploaded to the cloud server.
[0014] The second aspect of this application provides a method for uploading offline fault logs of a WIFI module, applied to the WIFI module offline fault log uploading system described in any one of the first aspects above, comprising: Obtain the operating status of the WIFI module; Based on the operating status, determine whether the WIFI module has experienced an offline failure; If so, then determine the offline fault type of the WIFI module; The fault number is determined based on the mapping relationship between the fault number and the offline fault type; The fault number is encapsulated into a log entry and sent to the FLASH storage module for storage; the log entry includes: the timestamp when the WIFI module experienced an offline fault, the fault number, and the upload status bit. When the WIFI module is powered on and starts up, it connects to the cloud server, sends the log entries to the cloud server, and deletes the log entries stored in the FLASH storage module.
[0015] In some embodiments, the FLASH storage module adopts a circular buffer structure. The circular buffer is provided with a head pointer position and a tail pointer position. The head pointer position is used to store the log entry corresponding to the largest timestamp, and the tail pointer position is used to store the log entry corresponding to the smallest timestamp. The timestamps corresponding to the log entries stored from the head pointer position to the tail pointer position decrease sequentially. The method further includes: Receive the log entries and determine if there is remaining capacity in the circular buffer; If not, the log entry corresponding to the maximum timestamp will be stored from the head pointer position, and the log entry stored at the tail pointer position will be deleted. Specifically, when the log entry corresponding to the maximum timestamp is stored at the head pointer position and the log entry stored at the tail pointer position is deleted, the log entries in the circular buffer move towards the tail pointer position.
[0016] This application provides a system and method for uploading offline fault logs of a WIFI module. The system includes: a fault detection module for communication connection, a number mapping module, a FLASH storage module, a communication control module, and a cloud server. The fault detection module is configured to: acquire the operating status of the WIFI module; determine whether the WIFI module has experienced an offline fault based on the operating status; if so, determine the offline fault type of the WIFI module. The number mapping module is configured to: determine a fault number based on the offline fault type and the mapping relationship between the fault number and the offline fault type; encapsulate the fault number into a log entry and send it to the FLASH storage module for storage. The log entry includes: a timestamp when the WIFI module experienced an offline fault, a fault number, and an upload status bit. The communication control module is configured to: connect to the cloud server after the WIFI module powers on, send the log entry to the cloud server, and delete the log entry stored in the FLASH storage module, so as to automatically detect and upload unsent log entries to the cloud server after the WIFI module is powered on again, thereby achieving reliable traceability of offline fault information. Attached Figure Description
[0017] To more clearly illustrate the technical solution of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0018] Figure 1 This is a flowchart illustrating the operation of the WIFI module offline fault log upload system in this application.
[0019] Explanation of reference numerals in the attached figures: 1- Fault detection module; 2- Number mapping module; 3- FLASH storage module; 4- Communication control module; 5- Cloud server. Detailed Implementation
[0020] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.
[0021] Because some technologies rely heavily on network stability for log uploads, log data can be lost in offline scenarios, failing to cover fault information throughout the device's lifecycle. To address this issue, this application provides a Wi-Fi module offline fault log upload system and method. The Wi-Fi module offline fault log upload system and method are described below: like Figure 1 The diagram shown is a flowchart of the WIFI module offline fault log upload system in operation according to this application.
[0022] The first aspect of this application provides a WIFI module offline fault log upload system, including: The communication connection fault detection module 1, number mapping module 2, FLASH storage module 3, communication control module 4, cloud server 5.
[0023] The fault detection module 1 is configured as follows: Obtain the operating status of the WIFI module; based on the operating status, determine whether the WIFI module has experienced an offline fault; if so, determine the type of offline fault of the WIFI module.
[0024] For example, if the WIFI module has a configuration or authentication error, the offline fault type may be: incorrect WIFI password, mismatched encryption method (e.g., the device only supports WPA2, but the router is set to WPA3), or the SSID is hidden and not configured correctly.
[0025] The number mapping module 2 is configured as follows: The fault number is determined based on the mapping relationship between the fault number and the offline fault type. The fault number uses a 16-bit unsigned integer (1~65536) and supports 65536 unique fault types. A correspondence between the fault number and the fault type is established through a preset fault type encoding table (as shown in Table 1), supporting dynamic expansion of new fault types via OTA upgrades. Specifically, the number mapping module 2 is configured with a fault type encoding table, which stores the mapping relationship between the fault number and the offline fault type.
[0026] Table 1: Mapping of Regulation Numbers and Types
[0027] The number mapping module 2 is also configured as follows: The fault type coding table may be modified or expanded.
[0028] The fault number is encapsulated into a log entry and sent to the FLASH storage module 3 for storage. The log entry includes: the timestamp when the WIFI module experiences an offline fault, the fault number, and the upload status bit. The FLASH storage module 3 uses the module's built-in non-volatile FLASH and divides it into an independent log storage area (recommended capacity ≥ 2KB). The log entry format is defined as: 4-byte timestamp, 2-byte fault number, and 1-byte status bit. A single log entry occupies only 7 bytes, and 2KB of space can store approximately 297 log entries.
[0029] In this embodiment, the FLASH storage module 3 adopts a circular buffer structure. The circular buffer has a head pointer position and a tail pointer position. The head pointer position stores the log entry corresponding to the largest timestamp, and the tail pointer position stores the log entry corresponding to the smallest timestamp. The timestamps of the log entries stored from the head pointer position to the tail pointer position decrease sequentially. The FLASH storage module 3 uses a circular buffer structure to achieve cyclic writing through the "head pointer position" (the position of the latest entry) and the "tail pointer position" (the position of the earliest unuploaded entry). When the storage area is full, the new log entry automatically overwrites the oldest stored log entry pointed to by the tail pointer position to avoid overflow. Fault numbers include, but are not limited to, 1 to 65535. The capacity of the FLASH storage module 3 storing log entries includes, but is not limited to, 2KB, and the supported number of log entries includes, but is not limited to, 256.
[0030] The communication control module 4 is configured as follows: When the WIFI module is powered on and starts up, it connects to the cloud server 5, sends the log entries to the cloud server 5, and deletes the log entries stored in the FLASH storage module 3.
[0031] The upload status bit includes 0 and 1. When the upload status bit is 0, the log entry is in an unuploaded state; when the upload status bit is 1, the log entry is in an uploaded state.
[0032] The communication control module 4 is further configured to: Once the log entry has been sent to the cloud server 5, the upload status bit of the log entry is changed to 1.
[0033] Specifically, after the WIFI module is powered on, it first checks the FLASH storage module 3 before executing normal business logic. If there are unuploaded entries (upload status bit is 0), it starts the WIFI connection and establishes a TCP connection with the cloud server 5. Log entries are sent in ascending order of timestamp. Each log entry waits for the cloud server 5 to return an acknowledgment frame (ACK). After receiving the ACK, the upload status bit of the corresponding log entry is updated to 1 (uploaded), and the tail pointer is moved until the upload status bit of all log entries is updated to 1, completing the upload of log entries. Then, the log entries stored in the FLASH storage module 3 are deleted.
[0034] This application provides an offline fault log upload system for WIFI modules. By constructing a fault numbering system ranging from 1 to 65535, fault types are mapped to unique numbers. When an offline fault occurs in the WIFI module, the fault number and timestamp are stored in a circular queue of the FLASH storage module 3. When the WIFI module is powered on again, any unsent fault log entries are automatically detected and uploaded to the cloud server 5, enabling reliable traceability of offline fault information. This system solves the information loss problem in offline scenarios caused by real-time log upload mechanisms and features low storage overhead, high traceability efficiency, and strong adaptability, making it suitable for scenarios with high equipment reliability requirements, such as smart homes and industrial IoT.
[0035] In this embodiment, the FLASH storage module 3 is configured as follows: Receive the log entry and determine if the circular buffer has remaining capacity.
[0036] If not, the log entry corresponding to the maximum timestamp will be stored from the head pointer position, and the log entry stored at the tail pointer position will be deleted; the timestamp is in UTC seconds.
[0037] Specifically, when the log entry corresponding to the maximum timestamp is stored at the head pointer position and the log entry stored at the tail pointer position is deleted, the log entries in the circular buffer move towards the tail pointer position. That is, when the circular buffer is full, new log entries automatically overwrite the oldest unuploaded log entries. This overwriting mechanism prevents log entries from being missed during the upload process.
[0038] In this embodiment, the communication control module 4 is further configured as follows: If the WIFI module experiences an offline failure while the log entry is being sent to the cloud server 5, the log entry being sent will be marked as pending retry. During the log entry upload process, the WIFI module may experience another offline failure. If this happens, the log entry being sent will be marked as pending retry.
[0039] After the WIFI module powers on, it uploads the log entries corresponding to the "waiting to retry" state to the cloud server 5. Once all log entries have been uploaded, the log entries with an upload status bit of 0 are uploaded to the cloud server 5 sequentially, in ascending order of timestamp. If the WIFI module experiences another offline failure during the log entry upload process, the incompletely uploaded log entries are marked. When the WIFI module recovers, the upload continues based on these incomplete log entries, improving the upload rate and preventing duplicate uploads.
[0040] In this embodiment, the communication control module 4 is further configured as follows: If the WIFI module experiences an offline failure while the log entries are being sent to the cloud server 5, the remaining content of the log entries being sent is retained. When the WIFI module powers on and restarts, the remaining content of the log entries is uploaded to the cloud server 5. That is, the cloud server 5 supports resuming interrupted uploads to avoid duplicate log entries. If the WIFI module experiences another offline failure during the log entry upload process, the incompletely uploaded log entries are marked. When the WIFI module recovers, the upload continues according to the progress of the incompletely uploaded log entries, improving the upload rate and preventing duplicate uploads.
[0041] This application provides a WIFI module offline fault log upload system, the specific process of which is as follows: Establish a fault numbering system: Preset an integer range from 1 to 65536 as fault numbers, with each number uniquely corresponding to a fault type or fault event. In cases of WIFI offline or other faults, such as memory leaks, logs cannot be uploaded to the cloud via TCP. However, the fault number can be stored in the local WIFI module FLASH (number mapping module 2). Once the WIFI module is powered on, the log entry will be uploaded to the cloud server 5.
[0042] Offline fault storage: When the WIFI module experiences an offline fault, a corresponding fault number is generated, and it is encapsulated into a log entry in the format of "timestamp, fault number, upload status bit" and written to the system's FLASH storage module 3.
[0043] After the WIFI module powers on, it uploads log entries: Upon powering on, the WIFI module checks if there are any unuploaded log entries in the FLASH storage module 3. If so, it connects to the cloud server 5 via the WIFI network and uploads the log entries in chronological order (time stamp size). After uploading, the log entries are deleted or marked as invalid. If there are unuploaded entries (upload status bit is 0), the WIFI module connects and establishes a TCP connection with the cloud server 5. Log entries are sent in ascending order of timestamp, and each entry waits for an acknowledgment frame (ACK) from the cloud server 5. Upon receiving an ACK, the upload status bit of the corresponding log entry is updated to 1 (uploaded), and the tail pointer is moved. If the upload fails (e.g., due to network interruption), the corresponding log entry is retained and marked as "pending retry." Once the WIFI module powers on, entries marked as "pending retry" are uploaded first.
[0044] A second aspect of this application provides a method for uploading offline fault logs of a WIFI module, applied to an offline fault log uploading system for a WIFI module as described in any of the above embodiments, comprising: Obtain the operating status of the WIFI module; Based on the operating status, determine whether the WIFI module has experienced an offline failure; If so, then determine the offline fault type of the WIFI module; The fault number is determined based on the mapping relationship between the fault number and the offline fault type; The fault number is encapsulated into a log entry and sent to the FLASH storage module for storage; the log entry includes: the timestamp when the WIFI module experienced an offline fault, the fault number, and the upload status bit. When the WIFI module is powered on and starts up, it connects to the cloud server, sends the log entries to the cloud server, and deletes the log entries stored in the FLASH storage module.
[0045] The FLASH storage module adopts a circular buffer structure. The circular buffer is set with a head pointer position and a tail pointer position. The head pointer position is used to store the log entry corresponding to the largest timestamp, and the tail pointer position is used to store the log entry corresponding to the smallest timestamp. The timestamps corresponding to the log entries stored from the head pointer position to the tail pointer position decrease sequentially. The method further includes: Receive the log entries and determine if there is remaining capacity in the circular buffer; If not, the log entry corresponding to the maximum timestamp will be stored from the head pointer position, and the log entry stored at the tail pointer position will be deleted. Specifically, when the log entry corresponding to the maximum timestamp is stored at the head pointer position and the log entry stored at the tail pointer position is deleted, the log entries in the circular buffer move towards the tail pointer position.
[0046] It is worth noting that the effects of the above method embodiments can be found in the effects of the above system embodiments, and will not be repeated here.
[0047] The above detailed embodiments further illustrate the purpose, technical solution, and beneficial effects of the embodiments of this application. It should be understood that the above are merely specific embodiments of the embodiments of this application and are not intended to limit the protection scope of the embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solutions of the embodiments of this application should be included within the protection scope of the embodiments of this application.
Claims
1. A WIFI module offline fault log upload system, characterized in that, include: The communication connection fault detection module (1), number mapping module (2), FLASH storage module (3), communication control module (4), and cloud server (5) are all included. The fault detection module (1) is configured as follows: Obtain the operating status of the WIFI module; Based on the operating status, determine whether the WIFI module has experienced an offline failure; If so, then determine the offline fault type of the WIFI module; The number mapping module (2) is configured as follows: The fault number is determined based on the mapping relationship between the fault number and the offline fault type; The fault number is encapsulated into a log entry and sent to the FLASH storage module (3) for storage; the log entry includes: the timestamp when the WIFI module experiences an offline fault, the fault number, and the upload status bit; The communication control module (4) is configured as follows: When the WIFI module is powered on and starts up, it connects to the cloud server (5), sends the log entries to the cloud server (5), and deletes the log entries stored in the FLASH storage module (3).
2. The WIFI module offline fault log upload system according to claim 1, characterized in that, The number mapping module (2) is configured with a fault type encoding table, which is used to store the mapping relationship between fault numbers and offline fault types; The number mapping module (2) is also configured as follows: The fault type coding table may be modified or expanded.
3. The WIFI module offline fault log upload system according to claim 1, characterized in that, The FLASH storage module (3) adopts a circular buffer structure. The circular buffer is provided with a head pointer position and a tail pointer position. The head pointer position is used to store the log entry corresponding to the maximum timestamp, and the tail pointer position is used to store the log entry corresponding to the minimum timestamp. The timestamps corresponding to the log entries stored from the head pointer position to the tail pointer position decrease sequentially.
4. The WIFI module offline fault log upload system according to claim 3, characterized in that, The circular buffer has a capacity of 2KB; the circular buffer can store 256 log entries.
5. The WIFI module offline fault log upload system according to claim 3, characterized in that, The FLASH storage module (3) is configured as follows: Receive the log entry and determine whether the circular buffer has remaining capacity; If not, the log entry corresponding to the maximum timestamp will be stored from the head pointer position, and the log entry stored at the tail pointer position will be deleted. Specifically, when the log entry corresponding to the maximum timestamp is stored at the head pointer position and the log entry stored at the tail pointer position is deleted, the log entries in the circular buffer move towards the tail pointer position.
6. The WIFI module offline fault log upload system according to claim 5, characterized in that, The upload status bit includes 0 and 1. When the upload status bit is 0, the log entry is in an unuploaded state; when the upload status bit is 1, the log entry is in an uploaded state. The communication control module (4) is also configured to: Once the log entry has been sent to the cloud server (5), the upload status bit of the log entry is modified to 1.
7. The WIFI module offline fault log upload system according to claim 6, characterized in that, The communication control module (4) is also configured to: If the WIFI module fails to go offline during the process of sending the log entry to the cloud server (5), the log entry being sent will be marked as pending retry. When the WIFI module is powered on, the log entries corresponding to the pending retry state are uploaded to the cloud server (5). After the log entries are uploaded, the log entries with the upload status bit of 0 are uploaded to the cloud server (5) in ascending order of timestamp.
8. The WIFI module offline fault log upload system according to claim 1, characterized in that, The communication control module (4) is further configured as follows: If the WIFI module fails to go offline during the process of sending the log entry to the cloud server (5), the remaining content of the log entry being sent will be retained. When the WIFI module is powered on and started, the remaining contents of the log entries are uploaded to the cloud server (5).
9. A method for uploading offline fault logs of a WIFI module, applied to the WIFI module offline fault log uploading system described in any one of claims 1 to 8, characterized in that, include: Obtain the operating status of the WIFI module; Based on the operating status, determine whether the WIFI module has experienced an offline failure; If so, then determine the offline fault type of the WIFI module; The fault number is determined based on the mapping relationship between the fault number and the offline fault type; The fault number is encapsulated into a log entry and sent to the FLASH storage module for storage; the log entry includes: the timestamp when the WIFI module experienced an offline fault, the fault number, and the upload status bit. When the WIFI module is powered on and starts up, it connects to the cloud server, sends the log entries to the cloud server, and deletes the log entries stored in the FLASH storage module.
10. A method for uploading offline fault logs of a WIFI module according to claim 9, characterized in that, The FLASH storage module adopts a circular buffer structure. The circular buffer is set with a head pointer position and a tail pointer position. The head pointer position is used to store the log entry corresponding to the largest timestamp, and the tail pointer position is used to store the log entry corresponding to the smallest timestamp. The timestamps corresponding to the log entries stored from the head pointer position to the tail pointer position decrease sequentially; The method further includes: Receive the log entries and determine if there is remaining capacity in the circular buffer; If not, the log entry corresponding to the maximum timestamp will be stored from the head pointer position, and the log entry stored at the tail pointer position will be deleted. Specifically, when the log entry corresponding to the maximum timestamp is stored at the head pointer position and the log entry stored at the tail pointer position is deleted, the log entries in the circular buffer move towards the tail pointer position.