Data caching method and system for mineral exploration Internet of Things equipment

Abstract

The invention discloses a data caching method for mineral exploration Internet of Things equipment. The method is executed by a single thread. When a user needs to store data, the data is cached through a first cache queue module in a microcontroller memory, an element address is separated from the data cache, and the data is cached by dynamically utilizing the memory space of the microcontroller according to the size of the data to be stored; when the external flash memory is idle, popping up the data in the first cache queue module one by one, and pushing the data into a second cache queue module of the external flash memory one by one for persistent caching of the data; and when the user needs to take out and upload the data cached in the external flash memory, popping up the data in the second cache queue module in the external flash memory one by one, and releasing the space in the external flash memory at the same time. According to the method, single-thread double-layer caching can be realized on the basis of limited hardware, the situation of sudden large data volume can be dealt with without data loss, and electric energy is saved to the greatest extent.

Description

Technical Field

[0001] The present invention relates to the field of mineral exploration equipment, and in particular to a data caching method and system for mineral exploration Internet of Things equipment. Background Art

[0002] During the preliminary, general, and detailed survey stages of mineral exploration, prospecting areas are often located in harsh outdoor environments. Therefore, prospectors typically use small, portable equipment to collect field data. This equipment typically includes geophysical equipment (such as electrical and magnetic methods), infrared spectroscopy equipment (shortwave infrared, Fourier transform infrared, etc.), and, more recently, portable gas geochemical exploration equipment. These devices typically use digital electronic systems to collect and record data in the field, storing the data on the device's built-in hard drive or flash memory. Upon completion of the field work and upon returning to the facility, the data is transferred to a computer for processing.

[0003] Embedded devices used in the field typically use microcontrollers with low-performance, low-power chips (typically consuming only tens of milliwatts, roughly a hundred times less than the power consumption of solid-state drives). They typically have only a single core and lack a memory management unit (MMU). Therefore, complex random access memory (RAM) similar to that of solid-state drives (SSDs) cannot be implemented on this hardware. Limited by the computing power of these devices, they typically lack built-in common file systems (such as FAT), and therefore rely on proprietary, simple data storage and transfer protocols.

[0004] This built-in storage method has three problems: (1) Poor data security. The field environment is relatively harsh. If the device is damaged before the data is transferred to the computer, the data will be permanently lost. (2) Low data transmission and processing efficiency. Exploration is usually a team work, and the data collected in the field must be analyzed by experts working indoors before it is meaningful. However, the data of the current equipment must wait until the field personnel take it out from the device after the work is completed every day before it can be handed over to the experts for analysis, and the indoor experts cannot obtain the first-line data in time. (3) Poor compatibility. These devices usually use dedicated data cables to transmit data, and special application software usually needs to be installed on the computer. Although data transmission difficulties caused by physical damage to the data cable or incompatibility of application software due to operating system upgrades are not common, once they occur, they will greatly affect the progress of the work and may even jeopardize the progress of the entire project execution.

[0005] In fact, the above problems have existed in electronic devices across various industries, but the emergence of the Internet of Things (IoT) has largely resolved them. Relying on the infrastructure of the international Internet, various devices within the IoT use a unified data transmission protocol to exchange data. These devices are connected via either wired or wireless connections. It offers advantages such as intelligent interconnection, big data processing, real-time monitoring and feedback, and flexible scalability.

[0006] The prerequisite for applying the Internet of Things is that it must be able to access the international Internet. However, since mineral exploration work is usually carried out in field environments with relatively weak network infrastructure, it is impossible to guarantee that the equipment is always connected to the Internet. This means that mineral exploration equipment must be able to cache data when there is no network connection, and send the cached data when there is network access.

[0007] For devices such as desktop computers and mobile phones, it is not difficult to implement caching on the file system without affecting other services due to their high computing power, high hardware abstraction, and strong multi-tasking capabilities. However, for IoT devices, their processors are usually microcontrollers with extremely low computing power and do not run an operating system. The level of abstraction of the underlying hardware is low, and it is not easy to implement reliable data caching without major changes to the hardware architecture. There are two main difficulties: (1) Wear leveling needs to be completed on the microcontroller. The blocks of flash memory have a limit on the number of erase and write times (usually about 100,000 times). Therefore, if a hard offset is used for data address indexing, a small number of blocks will quickly run out of life and no longer be able to write data. For devices such as solid-state drives and USB flash drives, they usually have wear leveling technology implemented by special hardware and software. Mineral exploration equipment is usually not equipped with these special hardware, so wear leveling must be completely implemented by microcontroller software. (2) The waiting time for flash memory erase is usually long. For example, the sector erase time of W25Q128 EEPROM is usually 100 to 400 milliseconds. Devices like solid-state drives and USB flash drives typically use cache memory to reduce processor latency. However, the flash memory used in mineral exploration equipment typically lacks cache memory, so this latency must be handled at the software level. If the microcontroller software doesn't perform other tasks during this latency period, it can easily cause device lag and extend data collection intervals, impacting exploration effectiveness.

[0008] The root cause of these two issues lies in the limited computing power and memory of microcontrollers, making it difficult to implement a universal caching system. However, mineral exploration equipment typically features a large number of small, independent data entries, necessitating the design of a specialized caching system to effectively cache data.

[0009] To implement caching, a single Flash buffer is a relatively easy approach. Another approach is to use an operating system and multithreading on a microcontroller, but these approaches present many potential problems: (1) firmware size increases, increasing memory overhead; (2) communication between threads can easily lead to software defects due to thread conflicts; and (3) multithreaded debugging becomes difficult.

[0010] In order to implement a queue in memory, the easiest way to think of it is to use a method similar to vector and list in C++ STL to implement the queue. These data containers must dynamically allocate memory, which involves the use of a heap. However, since microcontrollers usually do not have dedicated MMU hardware, the allocation and release of the heap usually rely on functions such as brk and sbrk, that is, they must be allocated and released directly on the physical memory through software. This has the following problems: (1) Low efficiency, because the brk and sbrk functions usually search linearly in the memory for the next available block. As the number of queue elements increases, the efficiency will inevitably decrease; (2) It is easy to cause memory fragmentation, resulting in sufficient free memory space, but it cannot be used because it is not continuous space; (3) Reduced program stability, because the allocation of the heap cannot be predicted at compile time and will change as the program runs, which can easily cause insufficient memory. Generally speaking, using a heap on a microcontroller without an MMU is a bad design. If the heap is not used, the easiest way to think of it is to allocate a fixed array in the form of a global variable, and the length of each element in the array is the maximum length of the possible data. This will inevitably cause memory waste. The scenario that the present invention faces is that long data rarely appears, and short data appears more frequently. For example, the longest data encountered by the program is 128 bytes. If 16 elements are to be cached, then at least 128*16=2KB of space is required. However, it is impossible to fill up all 2KB because data with a length of 128 bytes does not appear often. The ideal situation is to be able to dynamically balance the data length and the number of cache levels, such as allocating 256 bytes of space to achieve the storage of 2 128-byte elements and 16 16-byte elements, so that the allocated cache space can be effectively utilized as much as possible. The present invention is precisely dedicated to solving the problem of effective utilization of cache space. Summary of the Invention

[0011] The main purpose of the present invention is to design and implement the mineral exploration equipment based on the hardware characteristics of the microcontroller technology so that the mineral exploration equipment can cache data in the flash memory element of the microcontroller in an off-network environment, and can retrieve the data from the cache and send it to the network in a network environment.

[0012] The technical solution adopted in the present invention is: A data caching method for a mineral exploration IoT device is provided, wherein the method is executed in a single thread in a microcontroller of the mineral exploration IoT device; When a user needs to store data, the data is first cached by a first cache queue module in the microcontroller memory. The first cache queue module specifically separates the element address and data cache, and dynamically utilizes the microcontroller memory space to cache data according to the size of the data to be stored; When the external flash memory is idle, the data in the first cache queue module are popped out one by one according to the head offset position of the external flash memory stored in the auxiliary record module in the microcontroller memory, and are pushed one by one into the second cache queue module of the external flash memory for persistent caching of the data; When the user needs to retrieve and upload the data cached in the external flash memory, the data in the second cache queue module in the external flash memory is popped out one by one according to the head offset position of the external flash memory stored in the auxiliary record module, and the space in the external flash memory is released at the same time.

[0013] According to the above technical solution, the first cache queue module includes a data push interface and a data pop-up interface, through which data of unequal lengths are dynamically stored in the first cache queue module; and through which the stored data is deleted from the head of the first cache queue module, and the deleted data is stored in a designated buffer.

[0014] Following the above technical solution, the first cache queue module implements a FIFO data structure based on the microcontroller memory, which contains 4 sub-variables: the first sub-variable is an integer head, which is used to record the head level index; the second sub-variable is an integer back, which is used to record the tail level index; the third sub-variable is an integer array buffer, which is used to store a circular buffer for data at each level; the fourth sub-variable is an integer array levels, which is used to index the starting offset of each level of the FIFO data structure on the integer array buffer.

[0015] Following the above technical solution, the auxiliary recording module includes a write interface, a read interface, an erase interface, an activation interface, an activation status check interface and a recovery interface, wherein the write interface writes the head offset and tail offset position of the external flash memory.

[0016] Following the above technical solution, the auxiliary recording module includes two page modules. The page module is an abstraction of the page of the microcontroller flash memory. The page module contains 4 sub-variables: the first sub-variable is the integer addrSignature, which is used to store the page status information address of the microcontroller flash memory; the second sub-variable is the integer addrBegin, which is used to store the starting address of the space of the microcontroller flash memory; the third sub-variable is the integer addrEnd, which is used to store the ending address of the space of the microcontroller flash memory; the fourth sub-variable is the integer addrNext, which is used to store the next write address of the microcontroller flash memory.

[0017] Following the above technical solution, the method specifically implements reading, writing and erasing of the external flash memory through an external flash memory driver module provided in the microcontroller.

[0018] Following the above technical solution, any data with a length less than S is pushed into the first cache queue module, where S is the maximum data capacity of the FIFO. The pushed data is named element and has a length of size. The specific execution process of the push interface is as follows: Calculate the remaining space. If the remaining space is insufficient, return an error or force a header element to pop up to free up space. If there is enough remaining space, calculate the tail level index and tail offset after pushing; If the sum of the current tail offset and the length of the pushed data is less than or equal to S, the data element is directly written into the ring buffer; otherwise, it means that a loop has occurred in the ring buffer and the data element needs to be written in segments.

[0019] Following the above technical solution, the specific execution process of the pop-up interface is as follows: Check whether the data in the first cache queue module is empty. If not, calculate the next head position after the data is popped out and update it; Calculate the offset start and end positions of the current header data in the ring buffer. If the offset end position is greater than the offset start position, copy the header data directly to the specified position; otherwise, it means that a loop has occurred in the ring buffer, and copy the header data in segments to the specified position.

[0020] The present invention also provides a data caching system for mineral exploration Internet of Things devices, including a microcontroller and an external flash memory, which caches data using the method described in the above technical solution.

[0021] The present invention also provides a computer storage medium storing a computer program executable by a processor, wherein the computer program executes the data caching method for a mineral exploration Internet of Things device described in the above technical solution.

[0022] The present invention achieves the following beneficial effects: Addressing the low-power, low-performance microcontrollers in embedded devices used in the field, the present invention implements a dedicated dual-layer buffered data structure based on this limited hardware. This structure solves the data transmission problem between the memory cache and the external Flash cache using only a single thread, without causing program blocking. Specifically, by providing a cache queue module within the microcontroller memory (i.e., volatile memory) of a mineral exploration IoT device, separating element addresses (pointers) from the data cache, a queue data structure (i.e., a first cache queue module) with dynamically adjustable element sizes is implemented. Furthermore, a queue data structure (i.e., a second cache queue module) is implemented within the external Flash memory (i.e., non-volatile memory) in conjunction with an auxiliary recording module within the microcontroller's built-in Flash memory. Furthermore, data exchange between the two cache queues can be performed using a single thread, which is sufficient to handle bursty data writes. Thus, the present invention utilizes a memory queue and a Flash queue to implement a single-threaded dual-layer buffer, capable of handling bursty data volumes without data loss and maximizing energy savings.

[0023] Of course, any product implementing the present invention does not necessarily need to achieve all of the advantages described above at the same time. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following is a brief introduction to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0025] Figure 1 This is a schematic diagram of the implementation of three important software modules of a microcontroller in a data cache system for a mineral exploration IoT device according to an embodiment of the present invention; Figure 2 This is a flow chart of a data caching method for a mineral exploration IoT device according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the execution flow of the push interface of the cache queue module according to one embodiment of the present invention; Figure 4 This is a schematic diagram of the execution flow of the pop-up interface of the cache queue module according to one embodiment of the present invention; Figure 5 1 is a schematic diagram of the execution flow of the auxiliary recording module writing interface according to one embodiment of the present invention; Figure 6 1 is a schematic diagram of the execution flow of the auxiliary recording module recovery interface according to one embodiment of the present invention; Figure 71 is a schematic diagram of the execution flow of the auxiliary recording module writing interface according to one embodiment of the present invention; Figure 8 This is a schematic diagram of the execution flow of the auxiliary recording module transfer interface according to one embodiment of the present invention; Figure 9 This is a schematic diagram of the execution flow of the system push interface according to one embodiment of the present invention; Figure 10 This is a schematic diagram of the execution flow of a system pop-up interface according to an embodiment of the present invention; Figure 11 It is a schematic diagram of the execution flow of the system refresh interface according to an embodiment of the present invention. DETAILED DESCRIPTION

[0026] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0027] It should be noted that the illustrations provided in the embodiments of the present invention are only schematic illustrations of the basic concept of the present invention. Therefore, the drawings only show components related to the present invention and are not drawn according to the number, shape and size of components in actual implementation. In actual implementation, the type, quantity and proportion of each component can be changed at will, and the component layout type may also be more complicated.

[0028] In the present invention, it should also be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer" and the like are used to indicate positions or locations based on those shown in the accompanying drawings. These terms are intended solely to facilitate the description of the present application and to simplify the description. They are not intended to indicate or imply that the devices or components referred to must have a specific orientation, be constructed, or operate in a specific orientation. Therefore, they should not be construed as limiting the present application. Furthermore, the terms "first" and "second" are used solely for descriptive and distinguishing purposes and should not be construed as indicating or implying relative importance.

[0029] In addition, it should be noted that the features of the various embodiments of the present invention may be combined or coupled in part or in whole, and, as will be appreciated by those skilled in the art, may interact and operate in different ways. Each embodiment may be implemented independently of one another or in an associated relationship.

[0030] The hardware level of the data caching system for mineral exploration IoT devices of the present invention mainly includes a microcontroller and external flash memory. The microcontroller includes at least one processor core, a certain amount of memory (RAM) and flash memory (Flash), wherein the flash memory must allow programming within the application (i.e., allowing the user program to read and write to the specified flash memory area by address). At the same time, the microcontroller should include the necessary peripheral interfaces that can communicate with the external flash memory. External flash memory refers to a flash memory element that can be programmed through an external circuit and should provide write, read, and erase functions. The data caching system for mineral exploration IoT devices is mainly used to implement the data caching method for mineral exploration IoT devices of the embodiments below.

[0031] like Figure 2 As shown, the data caching method for a mineral exploration IoT device according to an embodiment of the present invention is executed in a single thread in a microcontroller of the mineral exploration IoT device, and mainly includes the following steps: S1. When a user needs to store data, the data is first cached by a first cache queue module in the microcontroller memory. The first cache queue module specifically separates the element address and data cache, and dynamically uses the microcontroller memory space to cache the data according to the size of the data to be stored; S2. When the external flash memory is idle, the data in the first cache queue module are popped out one by one according to the head offset position of the external flash memory stored in the auxiliary record module in the microcontroller memory, and are pushed one by one into the second cache queue module of the external flash memory for persistent caching of the data; S3. When the user needs to retrieve and upload the data cached in the external flash memory, the data in the second cache queue module in the external flash memory is popped out one by one according to the head offset position of the external flash memory stored in the auxiliary record module, and the space in the external flash memory is released at the same time.

[0032] To implement the above method, at the software level, the system adopts the first-in-first-out queue mode (FIFO). There are three main software modules (such as Figure 1 The system consists of a cache queue module, an auxiliary recording module, and an external flash drive module. Three main user interfaces are provided: push, pop, and refresh. The push interface adds user data to the end of the queue; pop returns data at the head of the queue to the user and removes it from the system; and refresh is a function that users must periodically run to keep the system running.

[0033] (1) Cache queue module When users push data to the system, the system may be waiting for flash memory IO. At this time, the user data must be cached and written to the flash memory after the IO waiting period ends, without blocking the caller. This module is key to improving system responsiveness.

[0034] The cache queue module is a memory-based FIFO data structure that contains 4 sub-variables: an integer head for recording the head level index, an integer back for recording the tail level index, an integer array buffer which is a circular buffer for storing data of each level, and an integer array levels for indexing the starting offsets of each level of the FIFO on the buffer. The initial values of these variables are all 0. The length of the levels array is D, and the length of the buffer array is S. D and S are specified by the user. Here, D is the maximum depth of the FIFO (i.e., the maximum number of elements), and S is the maximum data capacity of the FIFO. This module provides two interfaces: push and pop. The execution methods of each interface are as follows: Push interface: Any data with a length less than S can be pushed into this module. Suppose the data pushed by the caller is named element with a length of size. The execution process is as follows (as Figure 3 shown): 1) Calculate the remaining space free. First, calculate the current head offset headAddress as levels[head], and the tail offset backAddress as levels[back]. When backAddress >= headAddress, free is S - (backAddress - headAddress); otherwise, free is headAddress - backAddress. If free < size, it means there is not enough space to push this element, and the user can return an error or forcefully pop a head element to release space according to the situation. If the space is sufficient, continue to the next step.

[0035] 2) Calculate the tail level index backNext after pushing as (back + 1) % D, and the tail offset after pushing backAddressNext as (backAddress + size) % S.

[0036] Again, if backAddress + size <= S, directly copy element to the position buffer + backAddress; otherwise, it means the buffer buffer has cycled. Calculate the length of the first part of the data size0 as S - backAddress, first copy the data of the first size0 length of element to the position buffer + backAddress, and then copy the remaining data of element to the position buffer + 0.

[0037] 3) Update back to backNext, and update levels[backNext] to backAddressNext.

[0038] Pop-up interface: The stored data can be popped out from the header of the module. The caller needs to provide a buffer element to store the returned data. The execution process is as follows (e.g. Figure 4 shown): 1) Check if the data in the module is empty. If back is equal to head, the data is empty and no further operations are performed. Otherwise, the data is not empty and execution continues.

[0039] 2) Calculate the next head position after the pop-up as (head + 1)% D. Calculate the starting offset of the head data in the buffer as levels[head] and ending offset as levels[headNext]. Update head to headNext.

[0040] 3) If end > begin, the data from buffer + begin to buffer + end is copied to element; otherwise, it means that the buffer is looped, so the data from buffer + begin to buffer + S is first copied to the element header, and then the data from buffer + 0 to buffer + end is copied to the remaining space of element.

[0041] (2) Auxiliary recording module This module stores the system's header and tail offsets. During runtime, this information is stored in memory, but for persistence, it must be saved to flash memory at the appropriate time and restored from flash memory after each hardware reboot. This module consists of two submodules called "page modules." The page module abstracts the "pages" of microcontroller flash memory, allowing users to write a certain length of data to flash memory and then read it back out, ensuring wear leveling across the flash memory area to extend the life of the flash memory.

[0042] The page module contains four sub-variables: integer addrSignature, used to store the page status information address; integer addrBegin, used to store the starting address of the space; integer addrEnd, used to store the ending address of the space; and integer addrNext, used to store the address of the next write. When initializing the module, the user must specify the page number on the flash memory corresponding to the page module and calculate the starting address of the page. addrSignature corresponds to the starting address of the page, addrBegin is addrSignature + 1, addrEnd is the starting address of the page plus the size of each page of the flash memory, and addrNext defaults to addrBegin. The page module provides the following interfaces: Write interface: allows users to write data to the page. In order to identify the data written by the user, the user needs to provide not only the data itself but also an integer data name. Assume that the data name provided by the user is name, the data name is object, and the data size is size (note that the maximum size cannot be larger than the flash page size). The interface returns the offset addr of the next write. The write process is performed as follows (such as Figure 5 shown): 1) Calculate the CRC value of the object and set the name to crc.

[0043] 2) Use the microcontroller's in-application programming interface to write crc, name, size, and object to the address addrNext in that order. Although this step is synchronous, the microcontroller's built-in flash memory typically has much faster write speeds and minimal I / O latency compared to external flash memory, so it typically doesn't significantly impact program performance.

[0044] 3) If the write succeeds, update addrNext to addrNext+size+sizeof(name)+sizeof(crc)+sizeof(size) and return addrNext. If the write fails, it means the current page is full, and return 0.

[0045] Read interface: This allows the user to read previously written data from a specified address. This interface typically does not require specialized design, as data in the microcontroller's flash memory can be read using the same method as accessing internal memory: by address. This operation is relatively simple, so it is not shown in the figure.

[0046] Erase interface: This interface calls the corresponding interface of the microcontroller to erase the page. After the erase is complete, 0xFFFFAAAA is written to the addrSignature location. This operation is relatively simple, so it is not shown in the figure.

[0047] Activation interface: This interface writes the data 0xAAAAAAAA to the addrSignature location to mark the page as active. This operation is relatively simple, so it is not shown in the figure.

[0048] Activation status check interface: This interface checks the data at the addrSignature location to determine whether the page is in the active state. This operation is relatively simple, so it is not shown in the figure.

[0049] Restore interface: This interface is used to restore the module's related status data after each hardware restart. This interface returns an integer array index. By calling this interface, you can obtain the names of all data written to the page and the address of the latest version of the named data. The execution process of this interface is as follows (e.g. Figure 6 shown): 1) Let address be addrBegin.

[0050] 2) Read the data at the address location, take out the previously written CRC, name, size, and object, and perform CRC verification on the object.

[0051] 3) If the verification fails, the execution is complete. If the verification passes, update address to address + size + sizeof(name) + sizeof(crc) + sizeof(size) and repeat step 2).

[0052] Wear-leveling offset data can be recorded using a single page. However, erasing a full page typically takes a long time. To reduce I / O latency, we need to merge the two page modules into a single auxiliary recording module and switch between them to achieve asynchronous erasure. Let's assume the auxiliary recording module contains two page modules named a and b, and contains the following subvariables: the page module pointer active records the currently active page, and the integer array index records the address corresponding to the data name.

[0053] The auxiliary recording module provides the following interfaces: Write interface (such as Figure 7 (as shown): This function is used to write data to the currently active page. The parameters of this interface are consistent with the page module's write interface, so the write interface of the page module corresponding to active is directly called to write data. If the write fails, indicating that the page is full, the transfer interface is executed. After the transfer interface is completed, the write interface of the page module corresponding to active is called again. If the write is successful, the function returns address and updates index[name] to address.

[0054] Read interface: This is the same as the page module's read interface. This interface directly calls the read interface of the page module corresponding to the active page. This operation is relatively simple, so it is not shown in the figure.

[0055] Transfer interface: This interface is used to transfer the data of a full active page module to another erased page module. Figure 8 As shown, the execution steps are as follows: 1) First, determine whether the target page module next is a or b by comparing it with active.

[0056] 2) Iterate over all elements in index, where the index is i and the data is address. If address is greater than 0, read the data at that address from active and write it to next. This completes the data transfer.

[0057] 3) Execute the next activation interface.

[0058] 4) Execute the active erase interface.

[0059] 5) Update active to next.

[0060] Recovery interface: This interface is used to restore the module's status data after each hardware restart. This operation is relatively simple, so it is not shown in the figure. The steps for executing this interface are as follows: 1) Check whether the currently activated page module is a or b through the page module activation status check interface, and assign the currently activated page module to active.

[0061] 2) Execute the active recovery interface to obtain the names and addresses of all data on the page and assign them to index.

[0062] The above design allows the auxiliary recording module to read and write data to the microcontroller's flash memory in a wear-leveled and non-blocking manner. However, this module is only suitable for random recording of small amounts of data with low update frequency, as the microcontroller's flash memory space is generally small. Furthermore, this module does not implement a FIFO-style data interface.

[0063] (3) External flash drive module This module is essentially an abstraction of external flash memory. Its specific implementation varies depending on the hardware register definitions, but its implementation is relatively simple and is therefore not shown in the figure. The external flash memory driver module primarily implements the following interface functions: writing, reading, and erasing external flash memory based on the tail offset position of the external flash memory stored in the auxiliary record module.

[0064] The external flash drive module provides the following interfaces: Write interface: The caller provides the page number, data, and data size, and writes the data into the external flash memory.

[0065] Read interface: The caller provides the page number and data size, and returns the data at the address in the external flash memory.

[0066] Erase interface: The caller provides the sector number to be erased, and after execution, the erasure of the sector will begin. After the interface is executed, it does not wait for the erasure to be completed but returns directly.

[0067] Erase status query interface: query whether the flash memory is currently being erased.

[0068] Generally speaking, the IO operation speed of external flash memory is very fast, but erasing takes a long time.

[0069] (4) System interface The above three modules constitute the main part of this system, but in addition, the system requires some auxiliary variables: the integer head is used to record the head page number, the integer back is used to record the tail page number, and the Boolean dirty is used to record whether the head or tail page number of the system has changed. Assume that the number of pages in the external flash memory is P, and the size of each page is N. The system provides the following interfaces: Push interface: any data with a length less than N can be pushed into the system. Let the data pushed by the caller be named element and its length be size. Figure 9 As shown, the execution process is as follows: 1) Calculate the CRC check value crc of element.

[0070] 2) Execute the push interface of the cache queue module to push a task data. The task data includes the following content: task type is write, write page is back, and write data is size, crc, and element.

[0071] 3) Update dirty to true. Calculate the sector S0 to which back belongs. Then update back to (back+1)%P and calculate the sector S1 to which back belongs again.

[0072] 4) If S0 is not equal to S1, it means that the next write will be in a new sector and needs to be erased. Then, a task data is pushed into the cache queue, including the following content: task type is erase, and the erased sector is S1.

[0073] Pop-up interface: The interface execution process is as follows (such as Figure 10 shown): 1) Checks whether head is equal to back. If so, it means there is no data left in the system to be popped out, so the function returns null without further execution.

[0074] 2) Call the erase status query interface of the external flash driver module. If erasing is in progress, it will return empty without continuing execution.

[0075] 3) Call the read interface of the external flash driver module, first read the first few bytes of the head page to determine the data size of the page, then read all the data, update the head to (head + 1)% P, and update the dirty flag to true. Perform a CRC check on the read data and return the data if the check passes; otherwise, return nothing.

[0076] Refresh interface: The interface execution process is as follows (such as Figure 11 shown): 1) If dirty is true, call the auxiliary record module's write interface to save head and back with different names (for example, 0 and 1) to the auxiliary record module. Then update dirty to false.

[0077] 2) Call the erase status query interface of the external flash driver module. If erasing is in progress, return directly without continuing execution.

[0078] 3) Call the pop-up interface of the cache queue module. If no new task data pops up, it returns directly without continuing execution; otherwise, it obtains the type of the new task data.

[0079] 4) If the task type is write, parse the write page, write data and size in the task, call the write interface of the external flash driver module, write these data to the corresponding page, and then return.

[0080] 5) If the task type is erase, parse the erase sector in the task, call the erase interface of the external flash driver module, erase the corresponding sector, and then return.

[0081] The present invention, through the close coordination of three modules, constructs a cache system capable of asynchronous push and pop operations on a microcontroller, using a first-in, first-out queue mode. The key to this system is that it eliminates the erase operation, a major source of I / O wait for external flash memory, while ensuring wear-leveling of the flash memory. While the external flash memory is being erased, the system can still push data normally without blocking other business logic. This significantly improves data processing efficiency compared to traditional blocking methods. Furthermore, the system provides three simple interfaces, allowing user programs to benefit from the efficiency improvements brought by asynchronous operations without requiring complex, specialized design. This system is designed to address the data generation and transmission characteristics of mineral exploration equipment, namely, the high frequency, small, and numerous periodic data production. Even when the equipment is offline, it ensures that data is pushed into the flash memory for caching as it is generated. When connected, the data can be popped and sent to a remote server. This design adapts to the network environment of field work, enabling mineral exploration equipment to benefit from Internet of Things technology, achieving secure and efficient data transmission and improving the efficiency of mineral exploration work.

[0082] It should be noted that the present invention is different from the SSD cache in the following aspects: (1) The purpose is different. The SSD is a universal storage device. The most direct manifestation of its universality is that it supports "random storage", that is, each write can specify an arbitrary write location. Since the problem to be solved in the present invention is how to cache data when there is no signal, it uses a relatively simple data structure, namely a queue; (2) The means are different. In order to achieve efficient random write, the main control system of the SSD is usually more complex. In terms of software, in order to achieve write balance of flash memory hardware, the main control chip must maintain a mapping table of virtual addresses and physical addresses. For example, when data is repeatedly written to the 0xAA address, the actual address of the corresponding flash memory chip changes each time it is written. In addition, for data that is frequently read and written, in order to reduce the loss caused by erasing the flash memory chip and improve the burst write performance, the SSD main control usually provides a large cache space on the volatile memory. However, in order to achieve random storage, the cache usually uses a mapping table to record data. The key of the mapping table is the data address and the value is the data at the address. At the hardware level, to handle the complex random read and write operations mentioned above, SSD controller chips typically require high performance. These main control chips must provide a memory management unit (MMU) to achieve efficient random access storage on volatile memory (i.e., RAM) to support mapping table data structures. These chips also typically have multiple cores to improve SSD read and write efficiency through multi-threaded operations. Due to the complex software and hardware structure mentioned above, SSDs typically consume a lot of power, typically reaching an operating power of around 3 watts.

[0083] Since this patent is targeted at embedded devices used in the field, to maximize power conservation, the microcontroller is typically a low-power chip with poor performance (typically consuming only tens of milliwatts, roughly a hundred times less than the power consumption of a solid-state drive). It typically has only a single core and lacks a memory management unit (MMU). Therefore, complex random access memory (RAM) similar to that of a solid-state drive (SSD) cannot be implemented on this hardware. However, since the present invention aims to solve a specific problem in a specific field, it does not require the high-energy, general-purpose solutions of SSDs. Based on this limited hardware, the present invention implements a dedicated dual-layer buffered data structure. A queue data structure (a first cache queue module) with dynamically adjustable element size is implemented in the volatile memory. A similar queue data structure (a second cache queue module) is also implemented in the non-volatile memory, in conjunction with the microcontroller's built-in flash memory (an auxiliary storage module). Furthermore, data exchange between the two cache queues can be performed using a single thread, effectively handling bursty data writes.

[0084] In summary, the main control chip of a solid-state drive is equivalent to the microcontroller of the present invention. The cache chip of a solid-state drive is equivalent to the memory in the microcontroller of the present invention. The flash memory chip of a solid-state drive is equivalent to the flash memory chip of the present invention. However, the main control chip of a solid-state drive is expensive, has high performance, high power consumption, and is multi-core. This makes it easy to implement multi-threaded programs. In contrast, the microcontroller of the present invention is low-priced, has poor performance, low power consumption, and is single-core. This typically only allows for single-threaded programs, making multi-threaded programs more difficult. The cache chip of a solid-state drive contains memory management unit (MMU) hardware, which can use advanced data structures such as "heaps." This is primarily used to implement mapping table data structures. The memory of the present invention does not include an MMU, and using a heap can easily lead to memory fragmentation and reduce performance. Therefore, the software of the present invention utilizes a special queue data structure. The flash memory chip of a solid-state drive and the flash memory chip of the present invention are generally similar. However, due to the high performance of the main control chip of a solid-state drive, wear leveling is typically achieved using a mapping table. Due to the performance and power consumption limitations of the main control chip, the present invention cannot use a mapping table approach to achieve wear leveling. However, the essence of the present invention is a queue data structure, and a circular queue data structure can naturally achieve loss balancing, so no special design is required.

[0085] In a specific embodiment of the present invention, the microcontroller is STM32F103ZGT6 from Semiconductor, and the flash memory is W25Q128FW.

[0086] The W25Q128 flash memory has a capacity of 128Mbits (or 16Mbytes). Each page is 256 bytes, for a total of 65,536 pages. Each 16 pages is a sector. The minimum erase unit for this flash memory is the sector, and the erase time for a single sector is 100 to 400 milliseconds. This flash memory connects to the microcontroller via an SPI interface.

[0087] The system software part can be implemented using C++ code.

[0088] The implementation of the cache queue module is as follows: Define a template class named FIFO, where the template parameter SIZE is of uint32 type, representing the size of the cache space, and the template parameter DEPTH is of uint32 type, representing the maximum depth of the queue. This template class provides two public methods, namely Push - used to push data into the queue; Pop - used to pop data from the queue. Two private methods, namely Allocate - used to allocate space from the cache; Deallocate - used to release space from the cache. At the same time, this class has four member variables, namely _head, of uint8 type, used to store the queue head level number; _back, of uint8 type, used to store the queue tail level number; _levels, of uint32 type array, with a length of DEPTH, used to store the starting offset position of each level in the cache; _buffer, of uint8 type array, with a length of SIZE, used to store the data in the queue.

[0089] The specific implementation method of each function is as follows: The Push function returns a bool value, indicating whether the push was successful. It takes three parameters: element, a void constant pointer to the buffer containing the data to be pushed; size, an int representing the length in bytes of the data to be pushed; and forced, a bool value that specifies whether to pop existing elements to free up space when the queue runs out of space. The function first checks whether size is less than or equal to 0. If so, it returns true, indicating a successful push. It then passes size and forced to the Allocate function to allocate space at the end of the queue's circular buffer, obtaining the starting address of the allocated space. If the allocation fails, it returns false. It then calculates anddress + size. If it is less than or equal to SIZE, the buffer does not need to be circular, and element is copied directly to address. If it is greater than SIZE, element is copied piecemeal to address and the beginning of the buffer. Finally, it returns true, indicating that the push has been completed.

[0090] The Pop function returns an int value, indicating the length of the popped data. It contains two parameters: element, which is a void pointer type and is a pointer to the popped data buffer; size, which is an int type and is the byte length of the popped buffer. The function first determines whether the queue buffer is empty by comparing _head and _back to see if they are equal. If so, it returns 0 directly. It then defines two uint32 variables, begin and end, and calls the Deallocate function to release the space for the first element data in the queue. The start and end addresses of the element data are copied to begin and end. If end is greater than begin, it means that the queue buffer has not looped, and the data between begin and end can be directly copied to element. If end is less than begin, it means that the buffer has looped, and the data between begin and end are copied to element in segments. The length of the retrieved element data is then returned.

[0091] The return type of the Allocate function is uint32, which indicates the starting address of the allocated queue cache space. It contains two parameters: size, which is of int type, indicating the size of the space to be allocated; forced, which is of bool type, indicating whether to pop out existing elements to free up space when the queue space is insufficient. The function first checks whether there are any free levels in the level index _levels. The specific checking method is to determine whether (_back+1)%DEPTH is equal to _head. If it is equal, it means that the queue level index is full. If the forced variable is false at this time, it directly returns the maximum value of uint32, indicating that space cannot be allocated. Then check whether size is greater than SIZE. If it is greater, it means that the element data length exceeds the data buffer _buffer length, and it also returns the maximum value of uint32, indicating that space cannot be allocated. Then, the tail address of the queue buffer is retrieved through _levels[_back] and set as backAddress; the head address of the queue buffer is retrieved through _levels[_head] and set as headAddress; the level index in _levels is calculated by calculating (_back+1)%DEPTH and set as backNext; the address in _buffer when space allocation is requested next time is calculated by calculating (backAddress+size)%SIZE and set as backNextAddress. Then, the remaining space in _buffer is calculated. If backAddress is greater than or equal to headAddress, SIZE-(backAddress-headAddress) is calculated; otherwise, headAddress-backAddress is calculated and the result is set as free. If free is less than or equal to size, it means that there is insufficient space in _buffer. At this time, if forced is false, the maximum value of uint32 is directly returned, indicating that space cannot be allocated. If forced is true, the existing elements in the queue are released one by one until the available space in _buffer is greater than or equal to size. After ensuring that there is enough space in _buffer, store backNextAddress in _levels[backNext], which is the starting position for the next request for space. Finally, return backAddress.

[0092] The Deallocate function performs the opposite of Allocate and has no return value. It takes two parameters: begin, a uint32 reference representing the starting address of the freed space, and end, a uint32 reference representing the ending address of the freed space. This function sets begin to _levels[_head], sets _head to (_head+1)%DEPTH, and finally sets end to _levels[_head].

[0093] The above completes the implementation of the cache queue module.

[0094] The auxiliary record module includes two classes: BucketPage and Bucket.

[0095] BucketPage is an encapsulation of a single page in a Bucket, serving the Bucket class. It contains six public functions: Resume, used to restore the page status from the internal flash memory; Write, used to write data to the internal flash memory; Read, used to read data from a specified address; IsActive, used to check whether the page is an active page; Activate, used to activate the page; and Erase, used to erase the page. It contains one private function: Verify, used to check whether the specified address contains valid data. It contains five private constants and variables: the constant _addrSignature is of type uint32 and is the address of the page status information; the constant _addrBegin is of type uint32 and is the starting address of the page storage area; the constant _addrEnd is of type uint32 and is the ending address of the page storage area; the variable _signature is of type uint32 pointer and is used to read the current page status information; and the variable _addrNext is the address to be written to the page next.

[0096] The specific implementation method of each function of BucketPage is as follows: The Write function returns a uint32 value, representing the address of the written data. It contains three parameters: name, an int8 type, which specifies the name of the data to be written; object, a constant void pointer type, which points to the buffer containing the data to be written; and size, an int type, which represents the byte size of the data to be written. The function first calculates the CRC checksum of the data pointed to by object combined with name. It then takes the first byte of the checksum and combines it with name and size into a uint32 variable, forming the data header to be written, set to header. The microcontroller's internal Flash programming interface is then called to write the header and the data pointed to by object to the Flash memory. The address for the next write is calculated and updated in _addrNext.

[0097] The Resume function has no return value. It contains one parameter, index, which is a uint32 pointer type and is used to output the address index of all data found in the flash memory. This function searches all data starting from the _addrBegin address and ending at _addrEnd. The Verify function performs the search. If the Verify function returns a valid data name, it also returns the address of the next valid data. If an invalid data name is returned, it means that there is no more valid data. For each valid data, the name is used as the sequence number and the address is used as the value, and it is indexed into the index variable. After the search is complete, the next address written is the address last substituted into the Verify function, and this address is assigned to _addrNext.

[0098] The Verify function returns a valid data name, of type uint8. It takes one parameter, address, of type uint32 reference, as input for the data address to be verified and, upon successful verification, outputs the next data address. This operation can be considered the inverse of the Write function. Although it must retrieve the data at the target address during execution, its purpose is not to retrieve data but to verify that the data stored in the flash memory is valid. If the data is valid, the name stored in the data header is returned.

[0099] Because the BucketPage class is typically used in pairs, and only one of the two pages must be active, we store specific identification data in _addrSignature to determine whether the page is active or erased. The Activate and IsActive methods are used to encapsulate setting and reading the activation state.

[0100] The Read and Erase functions are essentially encapsulations of the read and erase methods provided by the STM32F103 HAL, so they will not be described here.

[0101] The Bucket class essentially merges two BucketPages, encapsulating the two pages into a single, named write and read storage. When a page is full, the Bucket must also handle the task of migrating data from the old page to the new one. The Bucket class completes the implementation of the auxiliary record module, enabling upper-level programs to permanently store short data using uint8-formatted names without worrying about underlying erase and write operations.

[0102] The above completes the implementation of the auxiliary recording module.

[0103] The external flash driver module is essentially a wrapper around the W25Q128FW's SPI register interface. The W25Q128FW's manual provides direct access to registers via the SPI interface for data read, write, and erase operations, so I won't go into detail here.

[0104] Based on the above underlying modules, a top-level cache class can be implemented. This class primarily implements the second cache queue. To ensure simple and efficient data reading and writing within the second cache queue, the maximum length of each element in the queue is rigidly set to 256 bytes, the page size of the W25Q128FW. The main disadvantages of this design are that it limits the maximum element length and wastes space for short data. However, in real-world applications, individual data entries are typically short, and flash memory typically has a large memory footprint (e.g., 16MB for the W25Q128FW), so these two issues are less noticeable. However, the advantage of this design is obvious: the element data is aligned with the flash memory page. For example, when freeing up the space occupied by an element, a full sector can be erased without worrying about erasing "half" elements, significantly simplifying data management.

[0105] In this class, the first cache queue is used as a direct data cache. Each element is encoded as follows: the first byte of the element data indicates the operation type, which can be write (indicated by 0x00) or erase (indicated by 0x01). If the operation type is write, the remaining element data contains the write address and the data to be written; if the operation type is erase, the remaining element data contains the sector number to be erased.

[0106] This class contains three functions, Push, Pop and Frame.

[0107] The Push function typically performs some necessary checks, such as the size of the data to be written and whether the last page in the external flash memory has been erased. After these checks are completed, the address at the end of the second cache queue is read from the auxiliary record module, recorded as backAddress. The data to be written is then encoded using a header similar to the header file encoding used in the auxiliary record module, constructing a data header containing a CRC checksum and the data size. A data block is then constructed, encoded as follows: the first byte is 0x00, followed by the backAddress, then the data header, and finally the data to be written. This data is then pushed into the first cache queue using the Push interface of the first cache queue—a FIFO class instance. The last address of the queue recorded in the auxiliary record module is then updated to the address of the next page in the external flash memory. Note that if the address of the next page is not in the same sector as the previous page, an additional erase operation must be pushed into the first cache queue to ensure that the corresponding sector in the external flash memory is writable the next time the data is pushed. Specifically, the following coded data block is constructed: the first byte is 0x01, followed by the sector number corresponding to the address of the next page, and the Push interface of the first cache queue is called to push the data into the first cache queue. This completes the Push operation.

[0108] Since the speed of reading data from W25Q128FW is relatively fast, the Pop function does not need to rely on the first cache queue. In the Pop function, the head address and tail address of the second cache queue in the auxiliary record module are first read. If the two are equal, it indicates that there is no data in the second cache queue and it returns directly. Otherwise, it indicates that there is data, and the read instruction of the external flash drive module is directly called, that is, the 0x03 instruction of W25Q128FW reads the data at the head address. In the actual reading process, it is necessary to first read the element data header to determine the size of the data to be read, and then read the element data out and return it to the caller. After the reading is completed, the head address of the second cache queue in the auxiliary record module needs to be updated to the address of the next page.

[0109] Finally, in the Frame function, the following logic is constructed: First, the W25Q128FW driver interface is called to check whether the flash memory is busy. If so, the function returns immediately. If not, the Pop interface of the first cache queue is called to pop the data. If no data is popped, the function returns immediately. If data is popped, the first byte of the data is checked. If it is 0x00, it indicates a write operation; if it is 0x01, it indicates an erase operation.

[0110] If it is a write operation, the write address, data content, etc. are parsed, and then the write interface of the W25Q128FW driver, that is, the 0x02 instruction, is called to write the data to the specified address and then return.

[0111] If it is an erase operation, the sector to be erased is parsed, and then the erase interface of the W25Q128FW driver, that is, the 0x20 instruction, is called to erase the specified sector. Then the program returns.

[0112] The above completes the construction of the cache system of the present invention.

[0113] In actual use, the following operations can be performed at 10ms intervals: When the upper layer has data to push (such as data received from the UART), the Push interface is called to push the data in. When the upper layer needs to pop data (such as detecting a network connection), the Pop interface is called to pop the data and send it to the network. After that, the Frame interface is executed once.

[0114] This application also provides a computer-readable storage medium, such as a flash memory, a hard disk, a multimedia card, a card-type memory (e.g., SD or DX memory), a random access memory (RAM), a static random access memory (SRAM), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a programmable read-only memory (PROM), a magnetic memory, a disk, an optical disk, a server, an App store, etc., storing a computer program that implements corresponding functions when executed by a processor. When executed by a processor, the computer-readable storage medium of this embodiment implements the data caching method for a mineral exploration IoT device according to the method embodiment.

[0115] It should be pointed out that, according to the needs of implementation, the various steps / components described in this application can be split into more steps / components, or two or more steps / components or partial operations of steps / components can be combined into new steps / components to achieve the purpose of the present invention.

[0116] The size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0117] It should be understood that those skilled in the art can make improvements or changes based on the above description, and all such improvements and changes should fall within the scope of protection of the appended claims of the present invention.

Claims

1. A data caching method for a mineral exploration IoT device, characterized in that: The method is executed in a single thread in the microcontroller of the mineral exploration IoT device; When a user needs to store data, the data is first cached by a first cache queue module in the microcontroller memory. The first cache queue module specifically separates the element address and data cache, and dynamically utilizes the microcontroller memory space to cache data according to the size of the data to be stored; When the external flash memory is idle, the data in the first cache queue module are popped out one by one according to the head offset position of the external flash memory stored in the auxiliary record module in the microcontroller memory, and are pushed one by one into the second cache queue module of the external flash memory for persistent caching of the data; When the user needs to retrieve and upload the data cached in the external flash memory, the data in the second cache queue module in the external flash memory is popped out one by one according to the head offset position of the external flash memory stored in the auxiliary record module, and the space in the external flash memory is released at the same time.

2. The data caching method for mineral exploration Internet of Things devices according to claim 1, characterized in that: The first cache queue module includes a data push interface and a data pop-up interface. The data push interface is used to dynamically store data of unequal lengths into the first cache queue module. The stored data is deleted from the head of the first cache queue module through the data pop-up interface, and the deleted data is stored in a designated buffer.

3. The data caching method for mineral exploration Internet of Things devices according to claim 2, characterized in that: The first cache queue module implements a FIFO data structure based on the microcontroller memory and contains four sub-variables: the first sub-variable is the integer head, which is used to record the head level index; the second sub-variable is the integer back, which is used to record the tail level index; the third sub-variable is the integer array buffer, which is used to store the circular buffer of data at each level; the fourth sub-variable is the integer array levels, which is used to index the starting offset of each level of the FIFO data structure on the integer array buffer.

4. The data caching method for mineral exploration Internet of Things devices according to claim 1, characterized in that: The auxiliary recording module includes a write interface, a read interface, an erase interface, an activation interface, an activation status check interface and a recovery interface, wherein the write interface writes the head offset and the tail offset position of the external flash memory.

5. The data caching method for mineral exploration Internet of Things devices according to claim 1, characterized in that: The auxiliary record module includes two page modules. The page module is an abstraction of the page of the microcontroller flash memory. The page module contains four sub-variables: the first sub-variable is an integer addrSignature, which is used to store the page status information address of the microcontroller flash memory; the second sub-variable is an integer addrBegin, which is used to store the starting address of the microcontroller flash memory space; The third sub-variable is an integer addrEnd, which is used to store the end address of the microcontroller flash memory space; the fourth sub-variable is an integer addrNext, which is used to store the next write address of the microcontroller flash memory.

6. The data caching method for mineral exploration Internet of Things devices according to claim 1, characterized in that: The method specifically realizes reading, writing and erasing of the external flash memory through an external flash memory driver module arranged in the microcontroller.

7. The data caching method for a mineral exploration Internet of Things device according to claim 3, characterized in that: Push any data with a length less than S into the first cache queue module, where S is the maximum data capacity of the FIFO. The pushed data is named element and has a length of size. The specific execution process of the push interface is as follows: Calculate the remaining space. If the remaining space is insufficient, return an error or force a header element to pop up to free up space. If there is enough remaining space, calculate the tail level index and tail offset after pushing; If the sum of the current tail offset and the length of the pushed data is less than or equal to S, the data element is directly written into the ring buffer; otherwise, it means that a loop has occurred in the ring buffer and the data element needs to be written in segments.

8. The data caching method for mineral exploration Internet of Things devices according to claim 3, characterized in that: The specific execution process of the pop-up interface is as follows: Check whether the data in the first cache queue module is empty. If not, calculate the next head position after the data is popped out and update it; Calculate the offset start and end positions of the current header data in the ring buffer. If the offset end position is greater than the offset start position, copy the header data directly to the specified position; otherwise, it means that a loop has occurred in the ring buffer, and copy the header data in segments to the specified position.

9. A data caching system for mineral exploration IoT devices, characterized in that: The device comprises a microcontroller and an external flash memory, which caches data by the method according to any one of claims 1 to 8.

10. A computer storage medium, characterized in that A computer program executable by a processor is stored therein, and the computer program executes the data caching method for a mineral exploration Internet of Things device according to any one of claims 1 to 8.

Images