A method and device for storing real-time sensing data based on off-line storage of internal flash ROM of a single-chip microcomputer

Abstract

This invention discloses a method and device for offline storage of real-time sensor data based on the internal Flash ROM of a microcontroller. Applied to the field of data processing technology, this invention focuses on the standardized processing, storage, indexing, time alignment, and transmission of multi-parameter sensor data. First, it receives carbon dioxide concentration, temperature, humidity, and air pressure data, generates standard data packets in 4-32 byte format, and combines them with real-time timestamps and data interval information. Based on the characteristics of Flash ROM, the data packets and auxiliary information are written sequentially in units of 64-512 bytes, erasing only new sectors before writing. 12-24 bytes of core index information are extracted, stored cyclically in dedicated sectors, and erased uniformly when full. Data addresses are located through the index, and time recovery after interruption is achieved by relying on the non-volatile storage of timestamps, accurately aligning data and time. Finally, the data is uploaded to a mobile APP via Bluetooth, receiving the APP's time synchronization RTC module, completing the entire process of data management and interaction.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method and device for offline storage of real-time sensor data based on the internal Flash ROM of a microcontroller. Background Technology

[0002] In existing technologies, the various types of data collected by sensors, such as carbon dioxide concentration, temperature, relative humidity, and air pressure, often lack standardized encapsulation rules, resulting in different storage formats, byte lengths, and encoding methods for different parameters. This necessitates adapting to multiple format conversion logics during subsequent data reading, parsing, and cross-device transmission, increasing data processing complexity, increasing the likelihood of parsing errors, reducing data utilization efficiency, and failing to meet the requirements for data uniformity and compatibility in offline storage scenarios.

[0003] Flash ROMs inherently possess the characteristics of "sector-level erasure, byte-level writing" and a limited erase lifespan (e.g., a typical single sector can be erased approximately 20,000 times). Existing storage methods do not optimize storage strategies for these characteristics, resulting in two major problems: First, the data integration method is unreasonable, failing to fully utilize sector space, leading to storage redundancy and low storage efficiency; second, erase operations are frequent, often employing "erase before write" or "random erase" modes, significantly shortening the Flash ROM's lifespan and making it unsuitable for long-term offline storage applications.

[0004] The temporal correlation of real-time sensor data directly impacts its application value, but current technologies lack efficient time synchronization and estimation mechanisms. On one hand, relying solely on a single timing module (such as RTC) in offline states can easily lead to inaccurate data timestamps due to accumulated timing errors. On the other hand, the lack of a precise indexing and association mechanism makes it impossible to quickly locate data addresses and estimate the real-time time of each data packet through indexes, resulting in inaccurate alignment between data and time. This makes it difficult to confirm the actual time of data generation during subsequent data tracing, affecting the validity of the data.

[0005] In existing technologies, the uploading of sensor data to the terminal (such as a mobile app) and the time synchronization of the RTC module are mostly independent processes, lacking collaborative design. During offline storage, the timing error of the RTC module accumulates continuously, and the RTC benchmark is not updated in a timely manner using the real-time time feedback from the terminal after data upload, resulting in continuous timestamp deviations in subsequent data acquisition. At the same time, the data upload protocol lacks standardized design, making it prone to transmission interruptions and data loss, affecting the smooth transition of offline stored data to online applications. Summary of the Invention

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0007] A method for offline storage of real-time sensor data based on the internal Flash ROM of a microcontroller includes: receiving carbon dioxide concentration, temperature, relative humidity, and air pressure data collected by sensors; standardizing the data according to a specification of 4 to 32 bytes per packet to generate sensor data packets in a unified format; acquiring real-time time information; and generating timestamps and data generation interval information; based on Flash... The ROM storage features integrate standardized sensor data packets with timestamps, read / write flags, and generation interval information in units of 64 to 512 bytes. Each unit stores sensor data and auxiliary information, written to a designated storage area in sector order, with erasure operations performed only when writing a new sector, generating sensor data storage result information. The core information of the auxiliary index is extracted and integrated in 12 to 24-byte units, divided into several dedicated sectors as storage areas. Each time a packet of sensor data is stored, the index value is updated and written cyclically. After being filled, it is erased and then stored cyclically again, generating auxiliary index data storage result information. Combining the sensor data storage result and auxiliary index data, the latest / oldest data address is located through the index. By storing the timestamp non-volatilely, data time information recovery is achieved when continuous detection is forced to be interrupted. The real-time time of each data packet is calculated based on the timestamp and generation interval, achieving precise data-time alignment and generating data-time alignment result information. Based on the Bluetooth module interface, the aligned sensor data is uploaded to the mobile APP according to the agreed protocol. The real-time time fed back by the APP is received to synchronously update the RTC module, generating data transmission and time synchronization result information.

[0008] A device based on offline storage of real-time sensor data in the internal Flash ROM of a single-chip microcomputer, the device includes: an acquisition module, used to receive carbon dioxide concentration, temperature, relative humidity and air pressure data collected by sensors, standardize the data according to the specification of 4 to 32 bytes per packet, generate sensor data packets in a unified format, acquire real-time time information, and generate timestamp and data generation interval information;

[0009] The processing module, based on the characteristics of Flash ROM storage, integrates standardized sensor data packets with timestamps, read / write flags, and generation interval information in units of 64 to 512 bytes. Each unit stores sensor data and auxiliary information, written to a designated storage area in sector order, with an erase operation performed only when writing a new sector, generating sensor data storage result information. It extracts the core information of the auxiliary index and integrates it in 12 to 24-byte units, dividing it into several dedicated sectors as storage areas. Each time a packet of sensor data is stored, the index value is updated and written cyclically. After the sector is full, it is erased and then stored cyclically again, generating auxiliary index data storage result information. Combining the sensor data storage result and auxiliary index data, it locates the latest / oldest data address through the index. By storing the timestamp non-volatilely, it restores the data time information when continuous detection is forced to be interrupted. Based on the timestamp and generation interval, it calculates the real-time time of each data packet, achieving precise data-time alignment and generating data-time alignment result information. Based on the Bluetooth module interface, it uploads the aligned sensor data to a mobile APP according to a pre-defined protocol, receives the real-time time feedback from the APP to synchronously update the RTC module, generating data transmission and time synchronization result information.

[0010] The beneficial effects are as follows: This invention provides a method for offline storage of real-time sensor data based on the internal Flash ROM of a microcontroller. Through standardized packaging, optimized storage strategies, precise indexing and time alignment, and collaborative transmission synchronization, it solves the pain points of traditional storage. First, it receives four types of sensor data, including carbon dioxide concentration and temperature, and packages them into 8-byte packets. Timestamps and interval information are generated using dual time sources. Then, based on the characteristics of Flash ROM, the data and auxiliary information are integrated into 128-byte packets, sequentially written to sectors, and erased only before writing new sectors, improving storage efficiency and lifespan. Simultaneously, core information is extracted to generate 12-byte index packets, which are stored cyclically in six dedicated sectors. Data addresses are located using the index, and real-time time is calculated by combining timestamps and intervals, achieving precise data-time alignment. Finally, the data is uploaded to the APP via Bluetooth, and the RTC module time is updated synchronously. Through standardized and optimized storage strategies, efficient data storage, accurate traceability, and stable transmission are achieved, adapting to long-term offline storage scenarios, extending hardware lifespan, and enhancing the value of data applications. Attached Figure Description

[0011] Figure 1 A flowchart illustrating a method for offline storage of real-time sensor data based on the internal Flash ROM of a microcontroller, provided in an embodiment of the present invention;

[0012] Figure 2 This is a schematic diagram of a device for offline storage of real-time sensor data based on the internal Flash ROM of a microcontroller, provided as an embodiment of the present invention. Detailed Implementation

[0013] The preferred embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit the present invention. Figure 1 This application describes a method for offline storage of real-time sensor data based on the internal Flash ROM of a microcontroller, according to an exemplary embodiment of the present application.

[0014] In this application embodiment, a method for offline storage of real-time sensor data based on the internal Flash ROM of a microcontroller is described, such as... Figure 1 As shown:

[0015] S101 receives carbon dioxide concentration, temperature, relative humidity, and air pressure data collected by the sensor, standardizes them according to the specification of 4 to 32 bytes per packet, generates sensor data packets in a unified format, obtains real-time time information, and generates timestamps and data generation interval information.

[0016] In one implementation, sensor output data is processed based on sensor data acquisition requirements and offline storage objectives. A data standardization mechanism is used to extract core parameters such as carbon dioxide concentration, temperature, relative humidity, and air pressure. These parameters are then packaged into packets of 4 to 32 bytes each using a format regularization module. Parameter type, data precision, and storage format are extracted and processed according to classification rules to generate a unified format sensor data packet, data specification verification information, parameter encoding mapping information, and data integrity assessment information. Four types of core parameters are extracted according to acquisition requirements and packaged in 8-byte format. Accompanying auxiliary information is generated simultaneously, ensuring that only four core indicators—carbon dioxide concentration, temperature, relative humidity, and air pressure—are retained in the sensor output data, while redundant and interfering data is removed.

[0017] Bytes are allocated using a "parameter segmentation encoding" method to ensure compact data storage. Carbon dioxide concentration: 2 bytes (range 0-5000ppm, precision 1ppm, encoded as a 16-bit unsigned integer); Temperature: 2 bytes (range -30℃ to 80℃, precision 0.1℃, encoded as a 16-bit unsigned integer offset by 30℃, i.e., actual temperature = encoded value / 10 - 30); Relative humidity: 2 bytes (range 0% to 80%, precision 0.1%, encoded as a 16-bit unsigned integer, actual humidity = encoded value / 10); Air pressure: 2 bytes (range 400hPa to 1100hPa, precision 0.1hPa, encoded as a 16-bit unsigned integer, actual air pressure = encoded value / 10).

[0018] The data specification verification information records the parameter order (e.g., "carbon dioxide-temperature-humidity-air pressure"), the byte length of each parameter, and the precision threshold, etc.; the parameter encoding mapping information clarifies the encoding rules (e.g., the temperature offset calculation method) and decoding formula for each parameter, which are used for subsequent data parsing; the data integrity assessment information is as follows, marking whether the current data packet contains 4 types of parameters, whether each parameter is within the valid value range, and generating an assessment label of "complete / missing / out of range".

[0019] Based on data integrity assessment information, various types of generated information are verified from multiple dimensions. A data supplementation mechanism is initiated for missing parameters. For devices with abnormal formats, the data correction service is invoked for secondary standardization. For data with substandard accuracy, the sensor calibration process is triggered, generating an optimized data processing solution that includes anomaly handling strategies and a supplementation time window. The data supplementation mechanism is initiated with a 10-second supplementation time window. If the acquired data packet lacks the "barometric pressure" parameter, the sensor is immediately triggered to re-acquire data. Three consecutive attempts to acquire barometric pressure data are made within 10 seconds. If all three attempts fail, a "barometric pressure parameter missing" log is recorded, and subsequent data is supplemented using interpolation (taking the average of the previous and subsequent valid barometric pressure values). The data correction service is invoked for secondary standardization. If the sensor output temperature data is 3 bytes (not conforming to the 2-byte convention), the lower 2 bytes of valid data are automatically truncated and re-converted according to preset encoding rules. If the data is in a non-integer format (e.g., with redundant decimal points), invalid characters are removed, and the data is rounded down to the nearest integer according to accuracy requirements.

[0020] If humidity data repeatedly shows "measured value deviates from standard ambient humidity by more than 5%" (accuracy threshold), the sensor self-calibration program is initiated. The measurement deviation is corrected using an internal reference value. Data storage is paused during calibration, and data is re-acquired and packaged after calibration. Integrating the above anomaly handling strategies, a standardized processing procedure is formed by defining the re-acquisition time window (10 seconds), calibration trigger conditions (deviation exceeding 5%), and correction priorities (format anomaly > inaccuracy > missing parameters).

[0021] The optimized processing scheme is integrated and executed, responding to data acquisition commands. Simultaneously, real-time time is obtained via Bluetooth or with the assistance of the RTC module, generating timestamps and data generation interval information. It responds to periodic sensor acquisition commands (e.g., every 5 minutes), processing data according to the optimized scheme—if no anomalies are found, the encapsulated 8-byte data packet is directly retained; if anomalies exist, they are corrected and supplemented according to the corresponding strategy to ensure the output data conforms to a unified format. During storage, only the time is obtained from the RTC, which is automatically synchronized via Bluetooth connection or periodically to ensure accuracy. If Bluetooth is disconnected, the microcontroller's built-in RTC module is activated for timing. The RTC module operates based on a 32.768kHz crystal oscillator, with an error of ±10ppm, approximately 0.864 seconds / day, continuing to accumulate time using the reference time from the last Bluetooth synchronization.

[0022] The time-related information is generated as follows: the acquired real-time time is converted into a Unix timestamp (e.g., 2024-05-20, 21:10:00 corresponds to 1716210600) and stored as a 4-byte integer; it is also generated at a fixed preset collection frequency (e.g., if it is collected once every 5 minutes, the interval is 5 minutes) and stored as a 1-byte integer, which will be used later to estimate the specific time of 15 packets of data in the same storage unit.

[0023] S102, based on the characteristics of Flash ROM storage, integrates standardized sensor data packets with timestamps, read / write flags, and generation interval information in units of 64 to 512 bytes. Each unit stores sensor data and auxiliary information, and writes them to the designated storage area in sector order. An erase operation is only performed when writing a new sector to generate sensor data storage result information.

[0024] In one implementation, based on the Flash ROM's 512-byte sector size and 20,000 erasable cycles, standardized sensor data packets and auxiliary information such as timestamps, read / write flags, and generation intervals are categorized and integrated to generate 128-byte storage unit information. According to the Flash ROM's sector size and erasable cycles, sensor data and auxiliary information are categorized and integrated into 128-byte storage units. The basic characteristics of the Flash ROM are clearly defined: it uses the internal Flash ROM of the HC32L136 series microcontroller, with a single sector capacity of 512 bytes, a single sector erasable cycle life of 20,000 times, and storage operations following the characteristics of "sector-level erasure, byte-level writing". The standardized sensor data consists of 8 bytes per packet (containing four types of parameters: carbon dioxide concentration, temperature, relative humidity, and air pressure); a timestamp (4-byte Unix timestamp, recording the generation time of the latest packet out of 15 packets); read / write flags ("0xa1" indicates written data, "0xa2" indicates read data, each 1 byte); and a data generation interval (1 byte, recording the acquisition frequency, such as "0x05" if acquisition occurs every 5 minutes).

[0025] The following is an example of the integration of a 128-byte storage unit. It is integrated according to the structure of "core data + auxiliary information". 15 packets of sensor data (15 × 8 bytes = 120 bytes) and 8 bytes of auxiliary information (time stamp 4 bytes + read / write flag 2 bytes + generation interval 2 bytes) together constitute a 128-byte storage unit, ensuring that the data structure within the unit is fixed and easy to read and parse later.

[0026] The writing process for the sensor data area is as follows: each data packet in the sensor data area occupies 8 bytes, and each group has 15 data packets, totaling 120 bytes. Therefore, each group of data is stored in units of 128 bytes. The remaining 8 bytes are used to store the "data written flag" (1 byte), the "data discarded (read) flag" (1 byte), the acquisition interval of each data packet in this group (2 bytes) (users can choose to set it to 1 minute / 2 minutes / 5 minutes / 10 minutes), and the timestamp of the latest data packet in this group (4 bytes). This information is stored in the first 8 bytes of each group of data, and the content of the 15 data packets is stored in the last 120 bytes.

[0027] The sensor data area is located from 0x9e00 (the starting address of sector 79 in the microcontroller's internal Flash ROM) to 0xfdff (the ending address of sector 126), totaling 48 sectors. Each sector is 512 bytes and can store 4 groups, or 60 packets, of data.

[0028] To accurately locate the latest data packet during storage, a "starting address of the latest sensor data packet" (one of the auxiliary index data) is introduced. After each sensor detects a data packet, before storing the data, this address is incremented by 8 to update the address, and then the latest data is stored in a consecutive 8-byte space at the new address. The address value will then increase with each detection, and the data in the storage space will be stored in 8-byte units, in order from oldest to newest detection time.

[0029] Whenever the address value is updated to a multiple of 512, it indicates that a new sector is about to be written, and an erase operation needs to be performed on the new sector before writing.

[0030] Whenever the address value is updated to a multiple of 128, it means that a new set of data is ready to be written. The address needs to be increased by 8 (to reserve space for the flag and timestamp, pointing to the first address of the 15 data packets). In addition to writing the first data packet of this set, this storage also needs to write the "data written flag" - 0xa1 in the first byte and write the collection interval (minutes) of each data packet in this set in the second byte.

[0031] Whenever the address value is updated to the 120th byte of the current 128 bytes, it indicates that the last packet of data in this group is about to be written. This storage also needs to add a timestamp to this group of data, that is, the timestamp of the latest packet of data is written in bytes 5 to 8.

[0032] Whenever the address value is increased to a value greater than 0xfdff, the address is reassigned back to 0x9e00, so that the data is stored cyclically within the set space.

[0033] To accurately locate the oldest data packet during the reading process, the "starting address of the oldest sensor data packet" (one of the auxiliary index data) is introduced. Each time a data set is sent via Bluetooth, the first 120 consecutive bytes of data stored in this set are read from this address and stored in the Bluetooth transmission data buffer. Then, the 4th byte of the 128 bytes of this data set is written with the "data discarded (read) flag" – 0xa2. If the first three data sets in the same sector have already been read, there is no need to write the read flag for the 4th data set; the sector can be directly erased. After completion, the starting address of the oldest sensor data packet is incremented by 128 to update the address so that Bluetooth can continue to index correctly when sending the next data set.

[0034] During the operation of the sensor, a timestamp is only added to the data set when the last packet of data in the set is detected. In other words, if the data set is not yet filled, the time cannot be determined. If the user turns off the device or the battery is too low and the device shuts down automatically, the real-time time will be lost after the device is turned on again, and the detection time of this data set will be completely undetermined.

[0035] At this point, three auxiliary index data points need to be introduced: "timestamp of the latest data packet," "flag indicating whether real-time time was synchronized via Bluetooth during this power-on," and "flag indicating whether sensor data is stored." The content of the auxiliary data area is updated each time the content changes. Upon powering on again after a power-off, the auxiliary index data in the Flash ROM is read. If any data flag is "true," the previously interrupted data set needs to be processed: if the synchronization time flag is "true," the time of the last data packet detected during the last power-on can be determined. Then, the timestamp from the auxiliary index data is written to the timestamp storage address of the latest data set (bytes 5 to 8 of the 128 bytes), thus resolving the issue of the latest data set not being fully filled, power-off detection interruption, and the inability to determine the time of this data set. After completion, the synchronization time flag is updated to "false" (because the time has not been synchronized during this power-on).

[0036] However, a new problem arises in this situation—a data set might not be fully filled, containing fewer than 15 packets. This necessitates the introduction of a "data set early termination flag"—0xfefa. After a power-off detection interruption, upon restarting and writing the correct timestamp, the 0xfefa flag needs to be written to the address of the next data set (the next 128 bytes) immediately following the latest data packet. The "start address of the latest sensor data packet" should then be directly assigned to the storage address of the next new data set. This ensures that the system knows the data set contains fewer than 15 packets during reading and informs the app, preventing errors during parsing and packet segmentation.

[0037] Since all packets in a set of data are detected at the same interval, when the user changes the detection cycle, the detection of this set of data must be ended in advance, the 0xfefa flag must be written, a new 128-byte start must be made, and a new set of data detection must be restarted.

[0038] The preceding text has already mentioned the specific content of the auxiliary data, including the "starting address of the latest packet of sensor data" (2 bytes), the timestamp of the latest packet of data (4 bytes), the "starting address of the oldest packet of sensor data" (2 bytes), a flag indicating whether real-time time was synchronized via Bluetooth during this power-on (1 byte), and a flag indicating whether sensor data is stored (1 byte), as well as their respective functions. Therefore, it can be understood that this data is frequently updated, and each update must be reliably saved, as it plays a crucial role in the normal reading and writing of the sensor data area. Given the limited number of sector erase cycles, special processing is needed to slow down sector wear and ensure the product's lifespan.

[0039] In this scheme, the address of the auxiliary data area is from 0x9200 (the starting address of sector 73 in the microcontroller's internal Flash ROM) to 0x9dff (the ending address of sector 78), a total of 6 sectors and 3072 bytes.

[0040] To facilitate data retrieval during reading, a "starting address of auxiliary index data" (2 bytes) is introduced; to save storage space, the two flags are merged into 1 byte, with the synchronization time flag in bit0 and the data presence flag in bit1; for data reliability, a CRC-8 checksum is introduced. This results in a 12-byte set of auxiliary data. By storing these 12-byte units continuously and cyclically in the auxiliary data area, erasing them only when the area is full, a sector can be erased only once every 256 write cycles.

[0041] For example, when the product is powered on for the first time and the first packet of data is detected, the address of the latest data needs to be updated. When writing to the auxiliary data area, the address value 0x9200 (little-endian storage) is written to addresses 0x9200 and 0x9201. Subsequent addresses are written with the contents of the auxiliary data in sequence, and the last byte 0x920b is written with a CRC-8 checksum, thus completing one instance of auxiliary data storage. After the sensor has been running for a period of time, the device connects to the mobile phone via Bluetooth and the time synchronization is successful. Then, the time synchronization flag needs to be updated and written to the auxiliary data area. At this time, the storage address of the auxiliary data is incremented by 12, and storage is performed again with 0x920c as the starting address. At the same time, 0 is written to 0x9200 and 0x9201.

[0042] The operation of writing 0 here utilizes the characteristic that Flash ROM writing essentially injects electrons into the floating gate of the corresponding bit, changing the bit corresponding to 0xff to 0. For example, writing 0x7e changes bit 7 and bit 0 to 0. That is to say, when an address has already been written with a value, the remaining bits at that address can be changed to 0 without erasing; that is, the value stored at a specific address can be cleared to 0 without erasing. Since no erasure is performed, and no electrons are removed from the floating gate of the Flash ROM, almost no wear and tear is caused.

[0043] After the auxiliary data has been updated 256 times, all 6 sectors will be full. When updating the storage next time, the address needs to be reassigned to 0x9200. Before writing, all 6 sectors should be erased once to continue the cyclic storage of this area.

[0044] Combining the sector-only erase feature of Flash ROM with the need for extended lifespan, operation rules are set to write in sector order and erase only before writing a new sector, ensuring that each sector is erased once per day at the fastest acquisition frequency. Taking advantage of the sector-only erase feature of Flash ROM, sequential write and on-demand erase rules are set to extend storage lifespan. A "sector-sequential write" method is used, writing 128-byte storage units sequentially to Flash ROM sectors. A single 512-byte sector can hold four 128-byte storage units (4 × 128 = 512 bytes), written sequentially in the order of unit 1, unit 2, unit 3, and unit 4 until the sector is full. After a sector is full, the process switches to the next unused sector to continue sequential writing, without overwriting already stored data. Each time data from a sector is read and sent, an erase is also performed on the sector to restore it to its initial 0xff state.

[0045] Once the first sector is filled with four storage units (60 packets of sensor data), when preparing to write to the second sector, only one erase operation is performed on the second sector. Data is collected as quickly as once per minute, but a total of 48 sectors are used, meaning 2880 packets of data can be stored. The data cycle through the same sector only every two days, meaning an erase operation is performed on each sector only once every two days before writing. Assuming the user transmits data every two days, and each sector containing data is erased once during transmission, each sector only needs to be erased once per day, significantly reducing the erase frequency. Based on a single sector's ability to be erased 20,000 times, a sector erased only once per day has a theoretical lifespan of 20,000 days (approximately 54.8 years), far exceeding product usage requirements.

[0046] The storage unit integration results, content design information, and erase / write rules are processed to generate sensor data storage result information that includes unit composition, storage layout, and operation specifications. The storage unit integration results, layout design, and operation rules are integrated to form standardized storage result information, clarifying storage execution specifications. The storage result information contains three core contents, as follows: Unit composition description, clarifying that a 128-byte storage unit consists of 15 packets of 8-byte sensor data + 8 bytes of auxiliary information (timestamp, read / write flag, generation interval), and annotating the byte length and encoding rules of each data type; Storage layout specifications, with a 128-byte address allocation table, clarifying the specific address range and layout order of core data and auxiliary information, as well as the combination method of accommodating 4 storage units in a single sector (512 bytes); Operation execution rules, detailing the operation process of "sequential writing, new sector pre-erasure," including sector switching conditions (current sector is full), erase triggering timing (before writing a new sector), and read / write flag update timing (after data writing / uploading), etc. Presented in a standardized document format, it includes a unit composition table, address layout diagram, and operation procedure instructions, facilitating adherence to unified standards during subsequent hardware execution and software parsing.

[0047] S103 extracts the core information of the auxiliary index and integrates it according to the 12 to 24 byte specification. It divides several dedicated sectors as storage areas. Each time a packet of sensor data is stored, the index value is updated and written in a loop. After it is full, it is erased and then stored in a loop to generate auxiliary index data storage result information.

[0048] In one implementation, based on the Flash ROM's storage characteristics of 512 bytes per sector and 20,000 erasure cycles, standardized sensor data packets, along with auxiliary information such as timestamps, read / write flags, and generation intervals, are categorized and integrated to generate storage unit information in 128-byte units. According to the characteristics of the HC32L136 series microcontroller's internal Flash ROM (512 bytes per sector, 20,000 erasure cycles, supporting sector-level erasure and byte-level writing), standardized sensor data packets and auxiliary information are categorized and integrated to form storage units in 128-byte units. Each standardized sensor data packet is 8 bytes long and contains four core parameters: carbon dioxide concentration, temperature, relative humidity, and air pressure; the 15 packets total 120 bytes.

[0049] The auxiliary information consists of 8 bytes, including a 4-byte Unix timestamp (recording the generation time of the latest packet among the 15 data packets), a 1-byte "data written flag" (fixed value 0xa1), a 1-byte "data discarded (read) flag" (default value if not read, 0xa2 is written after reading), a 1-byte data generation interval (user can set 1 / 2 / 5 / 10 minutes), and a 1-byte reserved field.

[0050] Based on storage efficiency requirements, the content layout of the 128-byte storage unit is designed, the storage ratio of 15 packets of sensor data and 8 bytes of auxiliary information is determined, and the storage unit content design information is generated. Based on the need to maximize storage efficiency, a fixed arrangement order of core data and auxiliary information is defined to ensure efficient reading and writing. Byte 0 (byte 1): Data written flag (0xa1); Byte 1 (byte 2): Data generation interval (1 / 2 / 5 / 10 minutes, 1-byte integer); Byte 2 (byte 3): Reserved field; Byte 3 (byte 4): Data discarded (read) flag (default value, updated to 0xa2 after reading); Bytes 4-7 (bytes 5-8): Timestamp of the latest data packet in this group (4-byte Unix timestamp); Bytes 8-127 (bytes 9-128): 15 packets of sensor data, each packet is 8 bytes arranged in the order of acquisition time, with addresses 8-15 being packet 1, addresses 16-23 being packet 2, and so on, and addresses 120-127 being packet 15. Core sensor data accounts for 93.75% (120 / 128), while auxiliary information accounts for 6.25% (8 / 128), achieving efficient utilization of storage space.

[0051] Considering the sector-only erasure feature of Flash ROM and the need for extended lifespan, operation rules were set to write in sector order and erase only before writing a new sector, ensuring that each sector is erased once per day at the fastest acquisition frequency. Using the "sector-sequential writing" method, 128-byte storage units are written sequentially to Flash ROM sectors. A single 512-byte sector can hold 4 storage units (4 × 128 = 512 bytes). After the sector is filled in the order of unit 1 to unit 4, the system switches to the next unused sector to continue writing, without overwriting already stored data.

[0052] An erase operation is performed only before writing a new sector; sectors that have already been written to are not erased again. If the first three sets of data for the same sector have been read, the sector is erased directly after the fourth set of data is read, restoring the initial 0xff state.

[0053] At the fastest acquisition frequency (1 minute / time), 48 sensor data sectors can store 2880 data packets. The sector is written once every two days, and each sector is erased no more than once per day. Based on the calculation that a single sector can be erased 20,000 times, the theoretical lifespan can reach about 54.8 years, which meets the long-term use requirements of the product.

[0054] The storage unit integration results, content design information, and erase / write rules are processed to generate sensor data storage result information that includes unit composition, storage layout, and operation specifications. A 128-byte storage unit is labeled as consisting of 15 packets of 8-byte sensor data + 8 bytes of auxiliary information, specifying the byte length, encoding rules, and flag definitions (such as the meaning of 0xa1 and 0xa2) for each data type.

[0055] The attached 128-byte address allocation table clarifies the specific address range and arrangement order of core data and auxiliary information, as well as the combination method of accommodating 4 storage units in a single sector (512 bytes).

[0056] This document details the complete process of "sequential writing, new sector pre-erase, and post-read sector erasure," including sector switching conditions (current sector is full), erasure trigger timing (before writing a new sector, after all 4 sets of data in the same sector have been read), and flag update timing (after data is written, after data is read).

[0057] S104 combines sensor data storage results with auxiliary index data, locates the latest / oldest data address through indexing, restores data time information when continuous detection is forced to be interrupted by non-volatile storage of timestamps, calculates the real-time time of each data packet based on timestamps and generation intervals, achieves accurate data-time alignment, and generates data-time alignment result information.

[0058] In one implementation, multi-dimensional feature extraction is performed on the sensor data storage results and auxiliary index data. The storage address, data packet format, and quantity information of the sensor data are parsed, and the header address, timestamp, and data generation interval in the auxiliary index are identified, generating a set of features to be processed that includes data storage features and index positioning features. Key feature information is extracted from the sensor data storage results and auxiliary index data, providing a data foundation for subsequent address positioning and time estimation.

[0059] Based on preset time alignment rules, the feature set is collaboratively processed. An index matching algorithm is used to accurately locate the addresses of the latest / oldest sensor data. A time estimation model is employed, combining timestamps and generation intervals to calculate the real-time time of each data packet. Data correlation verification tools are used to confirm the consistency of the estimation logic, generating time alignment processing results and evaluation information covering address matching degree and time estimation accuracy. The corresponding storage unit addresses are directly matched using the "latest packet sensor data header address" and "oldest packet sensor data header address" fields in the auxiliary index.

[0060] Starting from the base timestamp (latest data packet time) in the index, the times of other data packets within the same storage unit are deduced backwards according to the collection interval. For example, a 128-byte unit stores 15 data packets with a base timestamp of 1716210600 (21:10:00, time of the 15th data packet). With a collection interval of 5 minutes, the time of the 14th data packet is 21:05:00 (1716210300), the 13th packet is 21:00:00 (1716210000), and so on, until the time of the 1st data packet is 20:00:00 (1716207600). By comparing whether the time intervals of data within the same storage unit are consistent with the collection interval and whether the times of different storage units are continuous, the deduction logic is confirmed to be consistent. The time difference between the 15th packet and the 1st packet of data in a certain unit is 70 minutes (15 × 5 - 5 minutes), which is consistent with the calculated result; the time of the 15th packet of data in the next storage unit (i.e., older data) is 19:55:00, which is continuous with the time of the 1st packet of data in the current unit, 20:00:00, and the judgment logic is consistent.

[0061] The time alignment result is not a simple "address-time" correspondence, but a multi-layered association system of "storage unit-data packet-real-time" constructed by combining the Flash ROM storage structure, the characteristics of the 128-byte storage unit, and auxiliary index reference information, to ensure complete matching with the actual storage logic.

[0062] The evaluation information needs to be based on the hardware parameters of the HC32L136 microcontroller (such as the Flash ROM sector structure and RTC module precision) and data management rules, and generate quantifiable and technically based results from multiple dimensions to avoid abstract descriptions: The core of address matching degree is to verify the consistency between the address located by the auxiliary index and the actual storage address of the Flash ROM. It is evaluated in two levels: The storage unit address matching degree needs to confirm whether the starting address of the 128-byte unit located by the auxiliary index corresponds completely to the unit address marked with "data written flag" in the Flash ROM.

[0063] For scenarios after Bluetooth synchronization: When the sensor first connects to the phone, time synchronization is automatically triggered, and the RTC module receives standard time updates from the APP. If the Bluetooth connection is maintained, the sensor actively initiates a time request to the APP every 24 hours to complete periodic synchronization. After synchronization, the RTC module uses the calibrated standard time as the reference for timing. At this time, the calculated historical data time is completely consistent with the actual time, with an error of 0 seconds. Furthermore, the timestamps of subsequent data collection are all generated based on the calibrated RTC time, ensuring time continuity.

[0064] For scenarios where only RTC-assisted timing is used: When Bluetooth is disconnected, the timing relies on the microcontroller's built-in RTC module (32.768kHz crystal oscillator, error ±10ppm, approximately 0.864 seconds / day), continuing to accumulate the base time from the last Bluetooth synchronization. In this scenario, the calculated time will accumulate inherent RTC errors. For example, after 24 hours of continuous offline storage, the calculated time deviates from the actual time by 0.860 seconds, which does not exceed the design accuracy threshold. After reconnecting to the phone and completing time synchronization, the RTC module will update to the standard time, and the subsequent data time calculation error will be cleared to zero, meeting the usage requirements.

[0065] Data correlation consistency is used to confirm the fit between the time estimation logic and the storage rules. It is verified in two layers: Intra-unit interval consistency requires verification of the time interval between adjacent data packets within a 128-byte unit to see if it completely matches the collection interval of the auxiliary index record. In the example, the time interval between the 15 packets of data in all units is 5 minutes, with no anomalies of "interval lengthening / shortening", and the compliance rate is 100%. Inter-unit time continuity requires verification of whether the time connection between adjacent 128-byte units is continuous, without jumps or overlaps. The time of the first packet of the newer unit is adjacent to the time of the 15th packet of the older unit, with an interval of 5 minutes, which is consistent with the collection cycle, and the continuity compliance rate is 100%.

[0066] Logical contradictions must be clearly marked with details of address conflicts, time anomalies, and other issues discovered during the calculation process, along with their handling methods. In the example, invalid addresses are excluded by verifying the "data written flag" of the storage unit, and the validity of the time base is confirmed by the "synchronization flag" of the auxiliary index. No logical contradictions such as address duplication, time jumps, or interval anomalies are found, and there are no abnormal records, ensuring the reliability and traceability of the time alignment results.

[0067] Based on the evaluation information, targeted optimizations are performed. An index correction mechanism is used to adjust address positioning deviations, and an interval calibration algorithm is applied to correct time estimation errors. For data correlation anomalies, the correspondence between the index and sensor data is re-verified, generating optimized alignment content. For deviations or anomalies found in the evaluation information, a dedicated mechanism is used for correction to ensure the accuracy of address positioning and time estimation. Address positioning deviation correction is as follows: Deviation scenario: The latest data header address of the index record deviates from the actual storage address by 16 bytes (possibly due to incorrect storage unit arrangement). The index correction mechanism is applied as follows: By comparing the "data written flag" field of the storage unit, adjacent address segments are traversed to relocate the starting address of the valid data; the corrected address matches the actual storage address.

[0068] The data correlation anomaly was corrected as follows: The time interval between the 5th and 6th data packets of a certain storage unit was 10 minutes (exceeding the 5-minute collection interval), which was determined to be a correlation anomaly. The 8-byte auxiliary information of the storage unit was re-verified, and it was found that the "generation interval" field was mistakenly written as 10 minutes. The field was corrected by using the collection interval information in the index, and the time was recalculated to ensure that the interval was consistent.

[0069] The aligned content is integrated and optimized, and a final verification is performed based on the accuracy requirements of sensor data time tracing. This generates data and time alignment results information including address location steps, time calculation methods, and anomaly handling schemes. The corrected address-time correspondence table, correction records, calibration coefficients, etc., are then integrated to form a complete aligned dataset. Example: In the integrated dataset, each data packet includes "storage address, original calculated time, calibrated time, and correction instructions," ensuring traceability.

[0070] The verification process includes checking the uniqueness of the covered addresses (no duplicate addresses), the continuity of time (no jumps or overlaps), and the matching of the total data volume (the aligned data volume matches the actual storage volume). If a duplicate address record is found in a data packet, the redundant entry is deleted. If two data segments overlap in time, the collection interval and calculation logic are rechecked, and corrections are made to ensure time continuity. If the aligned data volume of 45 packets matches the actual storage volume, the verification is considered successful.

[0071] Data and time alignment result generation: This includes three core components, as follows: Address location steps: A clear explanation of the complete process of "index matching - deviation correction - final confirmation," with examples of key addresses. Time calculation method: A detailed explanation of the steps of "baseline timestamp acquisition - backward calculation by interval - error calibration," with calculation formulas and calibration coefficients. Anomaly handling plan: Records the types of deviations encountered during this optimization process, the correction mechanisms, and the handling results, providing a reference for similar issues in the future.

[0072] The S105, based on the Bluetooth module interface, uploads the aligned sensor data to the mobile APP according to the agreed protocol, receives the real-time time feedback from the APP to update the RTC module synchronously, and generates data transmission and time synchronization result information.

[0073] In one implementation, data transmission and time synchronization based on the Bluetooth module interface are primarily achieved by transmitting data according to agreed-upon rules and synchronizing the RTC time. The specific process is as follows:

[0074] When the sensor is first connected to the phone, time synchronization is automatically triggered. The sensor receives a standard time update (RTC) from the app, and all subsequent data storage is based on the RTC time. If the Bluetooth connection is maintained, the sensor will proactively send a time request to the app every 24 hours to complete periodic synchronization and ensure the accuracy of the RTC time.

[0075] When the app enters the historical data interface, it automatically sends a data transmission request to the sensor. Users can also manually initiate a data transmission request by clicking on the historical data interface; the sensor will only start data transmission upon receiving the request.

[0076] Data is transmitted in 128-byte units. The first 120 bytes store sensor data (8 bytes per packet), bytes 121-122 are the "0xFEFA" (big-endian) data end marker, byte 123 is the sampling interval, bytes 124-127 are the timestamp of the latest data packet in this group, and byte 128 is reserved. If the data group has fewer than 15 packets, "0xFEFA" is filled in for the last two bytes after the latest data packet, and "0x00" is filled in for all subsequent bytes up to byte 123. Data verification follows the Tuya BT3L Bluetooth module general protocol. If verification fails, the data group cannot be transmitted to the APP. After each transmission, the address of the oldest data is updated for easy subsequent data management and transmission.

[0077] After the device is powered on, the Bluetooth module enters broadcast mode. The mobile app discovers the device by scanning and parsing the broadcast packets and displays the device name. Users can easily complete the device's network activation and pairing, establishing a stable BLE connection. After successful pairing, the sensor e-ink display visually shows the Bluetooth pairing status through icons and continuously stores sensor data.

[0078] like Figure 2 As shown, a device for offline storage of real-time sensor data based on the internal Flash ROM of a microcontroller includes:

[0079] The acquisition module 201 is used to receive carbon dioxide concentration, temperature, relative humidity and air pressure data collected by the sensor, standardize the data according to the specification of 4 to 32 bytes per packet, generate sensor data packets in a unified format, acquire real-time time information, and generate timestamp and data generation interval information.

[0080] Processing module 202 is used to integrate standardized sensor data packets with timestamps, read / write flags, and generation interval information in units of 64 to 512 bytes, based on the storage characteristics of Flash ROM. Each unit stores sensor data and auxiliary information, and writes them to a designated storage area in sector order. An erase operation is performed only when writing a new sector, generating sensor data storage result information. It extracts the core information of the auxiliary index and integrates it in a specification of 12 to 24 bytes, dividing it into several dedicated sectors as storage areas. Each time a packet of sensor data is stored, the index value is updated and written cyclically. After it is full, it is erased and then stored cyclically again, generating auxiliary index data storage result information. Combining the sensor data storage result and auxiliary index data, it locates the latest / oldest data address through the index. By storing the timestamp non-volatilely, it realizes the recovery of data time information when continuous detection is forced to be interrupted. It calculates the real-time time of each packet of data based on the timestamp and generation interval, realizing accurate data and time alignment, and generating data and time alignment result information. Based on the Bluetooth module interface, it uploads the aligned sensor data to the mobile APP according to the agreed protocol, receives the real-time time feedback from the APP to synchronously update the RTC module, and generates data transmission and time synchronization result information.

[0081] A computing device includes a memory for storing computer program instructions and a processor for executing the computer program instructions, wherein when the computer program instructions are executed by the processor, the device is triggered to execute any method based on offline storage of real-time sensor data in the internal Flash ROM of a microcontroller.

[0082] The methods and / or embodiments in this application can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. When the computer program is executed by a processing unit, it performs the functions defined in the methods of this application.

[0083] It should be noted that the computer-readable medium described in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, 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 device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0084] It will be apparent to those skilled in the art that this application is not limited to the details of the exemplary embodiments described above, and that this application can be implemented in other specific forms without departing from the spirit or essential characteristics of this application. Therefore, the embodiments should be regarded as exemplary and non-limiting in all respects, and the scope of this application is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be embraced within this application.

Claims

1. A method for offline storage of real-time sensor data based on the internal Flash ROM of a microcontroller, characterized in that, include: The system receives carbon dioxide concentration, temperature, relative humidity, and air pressure data collected by sensors, standardizes them to 4 to 32 bytes per packet, generates sensor data packets in a unified format, obtains real-time time information, and generates timestamps and data generation interval information. Based on the characteristics of Flash ROM storage, standardized sensor data packets are integrated with timestamps, read / write flags, and data generation interval information in units of 64 to 512 bytes. Each unit stores sensor data and auxiliary information, and is written to a designated storage area in sector order. An erase operation is performed only when a new sector is written, generating sensor data storage result information. The auxiliary information includes a 4-byte timestamp, a 1-byte data written flag, a 1-byte data read flag, a 1-byte data generation interval information, and a 1-byte reserved field. The timestamp is the timestamp of the latest data packet. The read / write flag includes a 1-byte data written flag and a 1-byte data read flag. The designated storage area is the sensor data area. The core information of the auxiliary index is extracted and integrated according to the 12 to 24 byte specification, and divided into several dedicated sectors as storage areas. Each time a packet of sensor data is stored, the index value is updated and written cyclically. After the index is full, it is erased and then stored cyclically again to generate auxiliary index data storage result information. The core information of the auxiliary index includes the starting address of the auxiliary index data, the starting address of the latest packet of sensor data, the timestamp of the latest packet of data, the starting address of the oldest packet of sensor data, a flag indicating whether the real-time time was synchronized via Bluetooth during this power-on, and a flag indicating whether sensor data is stored. The storage area of ​​the dedicated sectors is the auxiliary data area. By combining sensor data storage results with auxiliary index data, the latest / oldest data address is located through the index. By storing the timestamp non-volatilely, the data time information is recovered when continuous detection is forced to be interrupted. The real-time time of each data packet is calculated based on the timestamp and the data generation interval information, so as to achieve accurate alignment between data and time and generate data and time alignment result information. Based on the Bluetooth module interface, the aligned sensor data is uploaded to the mobile APP according to the agreed protocol. The real-time time feedback from the APP is received to update the RTC module synchronously and generate data transmission and time synchronization result information.

2. The method for offline storage of real-time sensor data based on the internal Flash ROM of a microcontroller according to claim 1, characterized in that, The system receives carbon dioxide concentration, temperature, relative humidity, and air pressure data collected by sensors, standardizes these data packets to a 4-32 byte per packet format, generates a unified format sensor data packet, acquires real-time time information, and generates timestamps and data generation interval information, including: Based on the sensor data acquisition requirements and offline storage objectives, the sensor output data is processed. A data standardization mechanism is used to extract core parameters such as carbon dioxide concentration, temperature, relative humidity, and air pressure. The data is then packaged into packets of 4 to 32 bytes each using a format regularization module. Parameter type, data accuracy, and storage format are extracted and processed according to classification rules to generate sensor data packets in a unified format, data specification verification information, parameter encoding mapping information, and data integrity assessment information. Based on the data integrity assessment information, the generated information is verified in multiple dimensions. A data supplementation mechanism is initiated for missing parameters. For devices with abnormal formats, the data correction service is called for secondary standardization. For data with substandard accuracy, the sensor calibration process is triggered. An optimized data processing scheme including anomaly handling strategies and supplementation time windows is generated. The optimized processing scheme is integrated and executed, responding to data acquisition commands. At the same time, real-time time is obtained through the Bluetooth module or timed with the assistance of the RTC module, and timestamps and data generation interval information are generated.

3. The method for offline storage of real-time sensor data based on the internal Flash ROM of a microcontroller according to claim 1, characterized in that, Based on the characteristics of Flash ROM storage, standardized sensor data packets are integrated with timestamps, read / write flags, and data generation interval information in units of 64 to 512 bytes. Each unit stores sensor data and auxiliary information, and is written to a designated storage area in sector order. An erase operation is performed only when writing a new sector, generating sensor data storage result information, including: Based on the storage characteristics of Flash ROM sectors (512 bytes, erasable 20,000 times), standardized sensor data packets and auxiliary information such as timestamps, read / write flags, and data generation intervals are classified and integrated to generate storage unit information in units of 128 bytes. Based on storage efficiency requirements, the content layout of the 128-byte storage unit is designed, the storage ratio of 15 packets of sensor data and 8 bytes of auxiliary information is determined, and the storage unit content design information is generated. In the storage space of the sensor data area, each packet of data occupies 8 bytes, and each group has 15 packets of data, totaling 120 bytes. Combining the sector-only erasure feature of Flash ROM and the need for extended lifespan, we set up operation rules that write in sector order and erase only when writing a new sector, ensuring that each sector is erased once a day at the fastest acquisition frequency; The storage unit integration results, content design information, and erase / write rules are processed to generate sensor data storage result information that includes unit composition, storage layout, and operation specifications.

4. The method for offline storage of real-time sensor data based on the internal Flash ROM of a microcontroller according to claim 1, characterized in that, The core information of the auxiliary index is extracted and integrated according to a 12- to 24-byte specification. Several dedicated sectors are allocated as storage areas. Each time a packet of sensor data is stored, the index value is updated and written cyclically. Once full, the index is erased and then stored again in a cyclic manner, generating auxiliary index data storage result information, including: Based on the auxiliary index function requirements, the core information of the auxiliary index is obtained, including the header address, timestamp, synchronization flag, and data presence flag. The header address includes the starting address of the auxiliary index data, the starting address of the latest packet of sensor data, and the starting address of the oldest packet of sensor data. The timestamp is the timestamp of the latest packet of data. The synchronization flag includes a flag indicating whether the real-time time has been synchronized via Bluetooth during this power-on. The data presence flag includes a flag indicating whether sensor data is stored. The extracted auxiliary index core information is validated to ensure the completeness of each information item and the standardization of the data format, and information validation parameters are generated. Based on the 12-byte standard, the core information of the auxiliary index that has passed the verification is integrated and encapsulated to generate a standardized index data packet. The 12-byte standard includes the starting address of the auxiliary index data (2 bytes); the starting address of the latest packet of sensor data (2 bytes); the timestamp of the latest packet of data (4 bytes); the starting address of the oldest packet of sensor data (2 bytes); and a CRC-8 checksum (1 byte, which is a combination of a flag indicating whether the real-time time was synchronized via Bluetooth during this power-on and a flag indicating whether sensor data is stored). Based on product lifecycle requirements, the storage area is planned, divided into 6 dedicated sectors, the area boundaries and usage rules are defined, and storage area configuration information is generated; Write rules are set based on the erase characteristics of Flash ROM. The index value is updated every time a packet of sensor data is stored. The data is written to the storage area in sequence and continuously in a loop to generate a loop write operation scheme. Set up a sector erase triggering mechanism. When the six dedicated sectors are full, perform a unified erase and then start storing from the beginning in a loop to generate an erase scheduling rule. By integrating standardized index data packages, storage area configuration information, cyclic write operation schemes, and erase scheduling rules, auxiliary index data storage result information containing data composition, storage location, and operation specifications is generated.

5. The method for offline storage of real-time sensor data based on the internal Flash ROM of a microcontroller according to claim 4, characterized in that, By combining sensor data storage results with auxiliary index data, the latest / oldest data address is located through the index. By storing timestamps non-volatilely, data time information can be recovered when continuous detection is forcibly interrupted. Based on the timestamps and data generation interval information, the real-time time of each data packet is calculated, achieving precise data-time alignment and generating data-time alignment result information, including: Multidimensional feature extraction is performed on sensor data storage results and auxiliary index data. The storage address, data packet format, and quantity information of sensor data are parsed, and the header address, timestamp, and data generation interval information in the auxiliary index are identified. A set of features to be processed, including data storage features and index positioning features, is generated. The header address includes the first address of the auxiliary index data, the first address of the latest packet of sensor data, and the first address of the oldest packet of sensor data; the timestamp is the timestamp of the latest packet of data; the synchronization flag includes a flag indicating whether the real-time time has been synchronized via Bluetooth during this power-on; and the data existence flag includes a flag indicating whether sensor data is stored. Based on the preset time alignment rules, the feature set is processed collaboratively. The index matching algorithm is used to accurately locate the address of the latest / oldest sensor data. The time estimation model is used to calculate the real time of each data packet by combining the timestamp and the data generation interval information. The consistency of the estimation logic is confirmed by the data correlation verification tool. The time alignment processing result and evaluation information covering address matching degree and time estimation accuracy are generated. Based on the evaluation information, targeted optimizations are performed. Address positioning deviations are adjusted using an index correction mechanism, time estimation errors are corrected using an interval calibration algorithm, and the correspondence between the index and sensor data is re-verified for data correlation anomalies, generating optimized alignment content. The alignment content is integrated and optimized, and a final verification is performed based on the accuracy requirements of time tracing of sensor data. This generates data and time alignment results information that includes address location steps, time calculation methods, and anomaly handling solutions.

6. A device for offline storage of real-time sensor data based on the internal Flash ROM of a microcontroller, used to implement the method of claim 1, characterized in that, The device includes: The acquisition module is used to receive carbon dioxide concentration, temperature, relative humidity and air pressure data collected by the sensor, standardize the data according to the specification of 4 to 32 bytes per packet, generate sensor data packets in a unified format, acquire real-time time information, and generate timestamps and data generation interval information. The processing module, based on the characteristics of Flash ROM storage, integrates standardized sensor data packets with timestamps, read / write flags, and data generation interval information in units of 64 to 512 bytes. Each unit stores sensor data and auxiliary information, written to a designated storage area in sector order, with an erase operation performed only when writing a new sector, generating sensor data storage result information. It extracts the core information of the auxiliary index and integrates it in 12 to 24-byte units, dividing it into several dedicated sectors as storage areas. Each time a packet of sensor data is stored, the index value is updated and written cyclically. After the sector is full, it is erased and then stored cyclically again, generating auxiliary index data storage result information. Combining the sensor data storage result and auxiliary index data, it locates the latest / oldest data address through the index. By storing the timestamp non-volatilely, it restores the data time information when continuous detection is forced to be interrupted. Based on the timestamp and data generation interval information, it calculates the real-time time of each data packet, achieving precise data-time alignment and generating data-time alignment result information. Based on the Bluetooth module interface, it uploads the aligned sensor data to a mobile APP according to a pre-defined protocol, receives the real-time time feedback from the APP to synchronously update the RTC module, generating data transmission and time synchronization result information.

7. An electronic device, characterized in that, include: First processor; and memory for storing executable instructions of the first processor; The first processor is configured to execute the method of offline storage of real-time sensor data based on the internal Flash ROM of a microcontroller, as described in any one of claims 1 to 5, by executing the executable instructions.

8. A computing device, the device comprising a memory for storing computer program instructions and a processor for executing the computer program instructions, wherein, When the computer program instructions are executed by the processor, the device is triggered to execute the method of offline storage of real-time sensor data based on the internal Flash ROM of a single-chip microcomputer, as described in any one of claims 1 to 5.

Images