Remote firmware upgrade method and system for pile detector

Abstract

The application provides a remote firmware upgrade method and system of a pile detector, which comprises the following steps: S1: an Android host computer on a static load host detects a program version of a host control board on a server and a program version of a host control board of a base station; S2: if a new version of the program version of the host control board on the server is detected, the host control board is subjected to firmware program upgrade; and S3: if a new version of the program version of the host control board of the base station is detected, the host control board of the base station is subjected to firmware program upgrade. The host control board of the static load host and the host control board of the base station are subjected to firmware program upgrade in a segmented issuing and per-packet reply mode with a packet count, so that the firmware issuing progress is completely known and controllable. Through the packet count mechanism of the method, the progress of the current firmware issuing can be known, and the success of the firmware program downloading can be finally confirmed.

Description

Technical Field

[0001] This invention relates to the field of firmware upgrade technology, and in particular to a remote firmware upgrade method and system for a foundation pile detector. Background Technology

[0002] As a type of building foundation structure, pile foundations are buried underground and belong to concealed works. Accurately determining the quality of pile foundation engineering is crucial for ensuring the overall quality and safety of the building. According to the "Technical Specification for Testing Building Pile Foundations JGJ106-2014," the main methods for pile foundation testing include static load testing, core drilling, low-strain method, high-strain method, and sonic logging. Among these, static load testing typically uses a static load testing instrument, which includes the following components: static load tester, displacement sensor, hydraulic sensor, data acquisition base station, and oil pump controller. Firmware is a program stored on the microcontroller chip inside an embedded hardware device to drive the device's operation. Typically, the firmware is programmed into the device chip using specialized software and a professional programmer at the factory.

[0003] Currently, the internal hardware of the static load host and the data acquisition base station are embedded devices. Their application scenarios dictate that they cannot be equipped with additional network access hardware components for direct network connection, making direct network connection to the server impossible. Furthermore, the devices themselves are difficult to disassemble and assemble; program updates rely on specialized downloaders and specialized computer-based firmware flashing software. Typically, firmware updates can only be completed when the device is returned to the factory, resulting in long update cycles and the need for disassembly. Reassembling the device also leads to wear and tear between the outer casing components, affecting the device's waterproof and dustproof performance and impacting user experience. For example, Chinese patent CN109873722A discloses a method for remote firmware upgrades. During a remote firmware upgrade, the server transmits the firmware update package in packets to the gateway, which then further transmits it in packets to the nodes, or directly writes the packets to the gateway. This allows the server to remotely update the firmware of the gateway or the nodes. However, this method cannot handle unforeseen circumstances during the upgrade process (such as a power outage of the host computer causing firmware download interruption), and it cannot guarantee 100% controllable download success. Summary of the Invention

[0004] In view of this, the present invention proposes a remote firmware upgrade method and system for a foundation pile detector, in order to solve the problem that existing remote firmware upgrade methods cannot guarantee 100% controllable successful downloads.

[0005] The technical solution of the present invention is implemented as follows: On one hand, the present invention provides a remote firmware upgrade method for a foundation pile detector, which includes the following steps:

[0006] S1: The program version of the host control board on the Android host computer detection server of the static load host and the program version of the main control board of the acquisition base station.

[0007] S2: If a new version of the host control board program is detected on the server, the firmware program of the host control board will be upgraded by means of segmented distribution and replying with each packet and attaching a packet count.

[0008] S3: If a new version of the main control board program of the acquisition base station is detected on the server, the firmware program of the main control board of the acquisition base station will be upgraded by means of segmented distribution and replying with each packet and attaching a packet count.

[0009] Based on the above technical solutions, preferably, step S2 specifically includes:

[0010] S201: If a new version of the program on the host control board on the server is detected, the operator shall decide whether to upgrade the host control board at this time. If no upgrade is required or no new version is detected, the static load host will start and run normally.

[0011] S202: If an upgrade is selected, the host computer program will obtain the new firmware program for the host control board from the server and prompt the operator to perform a static load host power-off and restart operation.

[0012] S203: After the static load host is powered on again, the host computer program sends a firmware upgrade command to the host control baseboard, along with the number of firmware program segments to be downloaded to the host control baseboard. At this time, the host control baseboard enters the upgrade waiting mode. After the host computer program downloads the corresponding number of firmware program segments to the host control baseboard in sequence, and the host control baseboard replies to the host computer program line by line to confirm that the firmware download is correct, the host computer prompts that the firmware download is successful, the firmware upgrade of the host control baseboard is completed, and the new firmware program runs.

[0013] Based on the above technical solution, preferably, before step S201, the following is also included:

[0014] The program storage is partitioned on the host control panel, into two parts:

[0015] The first part serves as the boot area, used to store the upgrade boot control program required for firmware upgrades. The upgrade boot control program is used to control the firmware program to be sent, burned, and boot the device's firmware program.

[0016] The second part serves as the application firmware area, used to store firmware programs that maintain the normal operation of the host control board's business functions.

[0017] Based on the above technical solutions, preferably, step S3 specifically includes:

[0018] S301: If a new version of the program on the main control board of the acquisition base station is detected on the server, the operator shall decide whether to upgrade the main control board of the acquisition base station at this time. If no upgrade is required or no new version is detected, the main control board of the acquisition base station will start and run normally.

[0019] S302: If an upgrade is selected, the host computer program of the manually controlled static load host downloads the new firmware program of the main control board of the acquisition base station from the server, and sends it to the acquisition base station in segments via serial port through the host control board to LoRa communication. At the same time, a mechanism for verifying and retransmitting error packets is added. If the verification of a certain segment fails, or the acquisition base station replies with a timeout, the host computer program will retransmit the segment until every segment is successfully sent. After the main control board of the acquisition base station replies to the host computer program to confirm that the firmware download is correct, the host computer will indicate that the firmware download is successful, the firmware upgrade of the main control board of the acquisition base station is completed, and the new firmware program is running.

[0020] Based on the above technical solution, preferably, before step S301, the following is also included:

[0021] The program storage is partitioned on the main control board of the data acquisition base station, and divided into two parts:

[0022] The first part serves as the boot area, used to store the upgrade boot control program required for firmware upgrades. The upgrade boot control program is used to control the firmware program to be sent, burned, and boot the device's firmware program.

[0023] The second part serves as the application firmware area, which stores the firmware program used to maintain the normal operation of the main control board's service functions at the data acquisition base station.

[0024] Based on the above technical solutions, preferably, step S3 further includes:

[0025] When the host experiences an abnormal situation and is powered on again, the interruption point in the firmware transmission is detected by the return packet count value, and the interruption point is resumed for transmission.

[0026] On the other hand, the present invention provides a system that employs the remote firmware upgrade method for the foundation pile detector as described above, wherein the system includes:

[0027] Static load host and data acquisition base station;

[0028] The static load host is used to upgrade the firmware of itself and the data acquisition base station by using segmented distribution and replying to each packet with packet count;

[0029] The data acquisition base station is communicatively connected to the static load host and is used to receive firmware programs from the static load host to upgrade its own firmware.

[0030] Based on the above technical solutions, preferably, the static load host includes:

[0031] Android host computer, host control baseboard, and first LoRa module;

[0032] The Android host computer is communicatively connected to the host control baseboard and is used to detect the program version of the host control baseboard and the program version of the acquisition base station on the server. It also upgrades the firmware of the host control baseboard and the acquisition base station by using segmented distribution and replying to each packet with packet count.

[0033] The host control baseboard is communicatively connected to the first Lora module and is used to upgrade the firmware of the acquisition base station by forwarding the firmware program sent by the Android host computer through the first Lora module.

[0034] The first Lora module is communicatively connected to the acquisition base station.

[0035] Based on the above technical solutions, preferably, the data acquisition base station includes:

[0036] The main control board and the second LoRa module;

[0037] The main control board is communicatively connected to the second Lora module and is used to upgrade the firmware of the main control board by receiving the firmware program sent by the Android host computer through the second Lora module.

[0038] The second Lora module is communicatively connected to the first Lora module.

[0039] The remote firmware upgrade method and system for the foundation pile detector of the present invention have the following advantages over the prior art:

[0040] (1) The firmware program of the host control board of the static load host and the main control board of the acquisition base station is upgraded by adopting the method of segmented download and each packet reply with packet count. This makes the firmware download progress completely knowable and controllable. Through the packet count mechanism of this method, the current firmware download progress can be known, and finally the firmware program download success can be confirmed 100%.

[0041] (2) The firmware delivery logic adopts the form of segmented pure valid data, that is, the Android host computer delivers pure firmware segment data without adding any redundant data. The counting verification and return packet synchronization are all done by the host control board return packet. This method greatly improves the efficiency of the auxiliary upgrade firmware delivery between different modules in the same device.

[0042] (3) When necessary (such as when the host computer is out of power or in an abnormal environment), the Android host computer can detect the firmware transmission breakpoint by the return packet count value (the firmware transmission breakpoint detection under unknown and unrecorded conditions is supported by special return packet logic) and realize the breakpoint resume transmission. Attached Figure Description

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

[0044] Figure 1 This is a flowchart of the remote firmware upgrade method for the foundation pile detector of the present invention;

[0045] Figure 2 This is a partial schematic diagram of the remote firmware upgrade process of the present invention;

[0046] Figure 3 This is a partial flowchart illustrating the breakpoint detection process in the event of an abnormal remote firmware upgrade according to the present invention.

[0047] Figure 4 This is a block diagram of the remote firmware upgrade system for the foundation pile detector of the present invention. Detailed Implementation

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

[0049] Example 1

[0050] like Figure 1-3 As shown, a remote firmware upgrade method for a foundation pile detector according to the present invention includes the following steps:

[0051] S1: The program version of the host control board on the Android host computer detection server of the static load host and the program version of the main control board of the acquisition base station.

[0052] S2: If a new version of the host control board program is detected on the server, the firmware program of the host control board will be upgraded by means of segmented distribution and replying with each packet and attaching a packet count.

[0053] S3: If a new version of the main control board program of the acquisition base station is detected on the server, the firmware program of the main control board of the acquisition base station will be upgraded by means of segmented distribution and replying with each packet and attaching a packet count.

[0054] This method uses segmented download and packet count to upgrade the firmware of the host control board of the static load host and the main control board of the acquisition base station. This makes the firmware download progress completely knowable and controllable. Through the packet count mechanism of this method, we can know the current progress of firmware download and ultimately achieve 100% confirmation of successful firmware download.

[0055] Specifically, step S2 includes:

[0056] S201: If a new version of the program on the host control board on the server is detected, the operator shall decide whether to upgrade the host control board at this time. If no upgrade is required or no new version is detected, the static load host will start and run normally.

[0057] S202: If an upgrade is selected, the host computer program will obtain the new firmware program for the host control board from the server and prompt the operator to perform a static load host power-off and restart operation.

[0058] S203: After the static load host is powered on again, the host computer program sends a firmware upgrade command to the host control baseboard, along with the number of firmware program segments to be downloaded to the host control baseboard. At this time, the host control baseboard enters the upgrade waiting mode. After the host computer program downloads the corresponding number of firmware program segments to the host control baseboard in sequence, and the host control baseboard replies to the host computer program line by line to confirm that the firmware download is correct, the host computer prompts that the firmware download is successful, the firmware upgrade of the host control baseboard is completed, and the new firmware program runs.

[0059] The communication path between the host control board and the Android host computer is limited by performance, resulting in a limited amount of data sent in a single transmission. Furthermore, the RAM capacity of the host control board chip is significantly smaller than the firmware size. Therefore, the firmware upgrade distribution scheme adopts a segmented distribution approach. The host control board bootloader uses a packet-by-packet reply method with packet counting, further simplifying the transmission packet structure to ensure both efficient firmware distribution and burning while maintaining the integrity and controllability of the entire distribution process. This method facilitates collaborative firmware upgrades between different components within the same device (Android host computer and host control board). The firmware distribution logic uses segmented, purely valid data; the Android host computer distributes pure firmware segments without adding any redundant data. Counting, verification, and packet synchronization are all handled by the host control board's packet returns. This approach significantly improves the efficiency of firmware upgrade distribution between different modules within the same device.

[0060] Prior to step S201, the method further includes:

[0061] The program storage is partitioned on the host control panel, into two parts:

[0062] The first part serves as the boot area, used to store the upgrade boot control program required for firmware upgrades. The upgrade boot control program is used to control the firmware program to be sent, burned, and boot the device's firmware program.

[0063] The second part serves as the application firmware area, used to store firmware programs that maintain the normal operation of the host control board's business functions.

[0064] After the static load host is powered on again, the host computer program detects that there is firmware that needs to be updated locally. It sends a firmware upgrade command to the upgrade boot control program of the host control baseboard, along with the number of firmware segments to be downloaded to the host control baseboard. At this time, the upgrade boot control program enters upgrade waiting mode. After the host computer program downloads the corresponding number of firmware segments to the host control baseboard in sequence, and the upgrade boot control program of the host control baseboard replies to the host computer program line by line to confirm that the firmware download is correct, the host computer prompts that the firmware download is successful. The upgrade boot control program of the host control baseboard then starts burning the newly installed firmware. At this point, the firmware upgrade of the host control baseboard is complete, and the new firmware is running.

[0065] Specifically, step S3 includes:

[0066] S301: If a new version of the program on the main control board of the acquisition base station is detected on the server, the operator shall decide whether to upgrade the main control board of the acquisition base station at this time. If no upgrade is required or no new version is detected, the main control board of the acquisition base station will start and run normally.

[0067] S302: If an upgrade is selected, the host computer program of the manually controlled static load host downloads the new firmware program of the main control board of the acquisition base station from the server, and sends it to the acquisition base station in segments via serial port through the host control board to LoRa communication. At the same time, a mechanism for verifying and retransmitting error packets is added. If the verification of a certain segment fails, or the acquisition base station replies with a timeout, the host computer program will retransmit the segment until every segment is successfully sent. After the main control board of the acquisition base station replies to the host computer program to confirm that the firmware download is correct, the host computer will indicate that the firmware download is successful, the firmware upgrade of the main control board of the acquisition base station is completed, and the new firmware program is running.

[0068] The firmware upgrade communication path involves the Android host computer transmitting data via serial port to the host control board, which then forwards it to the data acquisition base station via a 433LoRa interface. However, the communication path between the host control board and the Android host computer is limited by performance constraints, resulting in a limited amount of data transmitted per transmission. Furthermore, the 433LoRa interface on the host control board is subject to wireless communication interference, making it impossible to guarantee the accuracy of every packet transmission. Additionally, the RAM capacity of the data acquisition base station chip is still smaller than the firmware size on the main control board. Therefore, the firmware upgrade distribution scheme adopts a segmented distribution approach. The host control board's upgrade boot control program responds to each packet with a packet count, and CRC checks are added to both the sending and receiving packets to verify their correctness. Furthermore, a retransmission mechanism for erroneous packets is added. The packet format also accommodates the original business logic packet format (Modbus-RTU) of the host control board, ensuring that the host control board does not conflict with its original business logic during the forwarding of firmware upgrade packets, minimizing modifications to the original firmware of the host control board. The entire firmware download and flashing communication scheme fully reuses the communication path used by the device's business logic, without adding any additional communication hardware with low usage for firmware upgrades. This reduces costs while still using reasonable download and flashing communication logic with a retransmission mechanism to ensure complete and error-free download and flashing of the program.

[0069] Prior to step S301, the method further includes:

[0070] The program storage is partitioned on the main control board of the data acquisition base station, and divided into two parts:

[0071] The first part serves as the boot area, used to store the upgrade boot control program required for firmware upgrades. The upgrade boot control program is used to control the firmware program to be sent, burned, and boot the device's firmware program.

[0072] The second part serves as the application firmware area, which stores the firmware program used to maintain the normal operation of the main control board's service functions at the data acquisition base station.

[0073] The mode selection of the upgrade boot control program for the data acquisition base station is controlled by the buttons on the data acquisition base station. When the data acquisition base station is powered on directly, the upgrade boot control program will normally pull up the previous data acquisition base station application firmware, and the original firmware program will run. When the load and unload buttons on the data acquisition base station are pressed and held simultaneously, and the power button on the data acquisition base station is turned on at the same time, the upgrade boot control program enters the upgrade waiting mode, and the load and unload lights on the data acquisition base station will be constantly lit. At this time, the host computer program of the static load host can be manually controlled to download the latest data acquisition base station firmware program from the server, and transmit it to the host control board via serial port to 433lora. The firmware update is distributed in segments by the data acquisition base station. Due to the wireless communication involved in the firmware update distribution process, each segment of the program needs to be verified. Therefore, a verification error packet retransmission mechanism has been added. When the verification of a certain segment of the program fails, or the response from the monitoring and control base station times out, the host computer program will retransmit the segment of the program until every segment of the program is successfully distributed to the data acquisition base station. After the main control board of the data acquisition base station confirms that the firmware download is correct by replying to the host computer program line by line, the host computer will indicate that the data acquisition base station upgrade is successful. The data acquisition base station upgrade boot control program will then start the newly burned firmware program. At this point, the firmware upgrade of the data acquisition base station is complete, and the new firmware program is running.

[0074] Step S3 also includes:

[0075] When the host experiences an abnormal situation and is powered on again, the interruption point in the firmware transmission is detected by the return packet count value, and the interruption point is resumed for transmission.

[0076] This method upgrades the communication channel via 433lora wireless transmission, enabling ultra-long-distance (1.7 km) communication between the upgraded device's data acquisition base station and the control upgrade device's static load host without relays. Given the low power consumption and ultra-long-distance characteristics of lora, and its relatively slow communication rate, a targeted communication return packet mechanism ensures stability during the slow and ultra-long physical distance firmware transmission process. When necessary (such as in abnormal on-site environments like the static load host losing power), the Android host computer can detect firmware transmission breakpoints through return packet counts (firmware transmission breakpoint detection in unknown or unrecorded situations is supported by special return packet logic), enabling breakpoint resumption of transmission.

[0077] For the current LoRa wireless long-range, low-power firmware transmission mode, uncertainties exist during the transmission process. This method specifically designs an extremely simplified and stable data packet transmission scheme: During firmware transmission, the host computer uses only two data packet formats: 1. A start packet, which includes the base station number, packet function information, firmware segmentation information (i.e., how many segments the firmware will be divided into for transmission), and CRC checksum information; 2. A data packet, which includes the base station number, packet function information, segment number information, and segment content information. The base station's response packet contains only one format: 1. A data segment sequence number packet, which includes the base station number, the segment number corresponding to the next data packet, and CRC checksum information. With this extremely simplified data packet design, the program transmission logic can be made extremely simple and less prone to errors. Even if the host computer experiences unforeseen circumstances such as battery depletion during firmware delivery, and the firmware delivery progress is unknown after power is restored and the device is restarted, simply sending any data packet for breakpoint detection will provide the firmware delivery breakpoint location via the segment number of the next data packet attached to the lower-level device's response packet. The host computer can then resume the transmission based on this breakpoint. In long-distance, slow wireless firmware delivery scenarios like LoRa, this passive breakpoint resumption eliminates complex program implementation logic, increases program stability, and improves user experience (the entire firmware delivery takes approximately 16 minutes; if unforeseen external anomalies such as power outages or strong wireless interference during on-site construction occur after 7 minutes of transmission, and only 9 minutes of transmission is needed afterward, the user experience will be improved by avoiding restarting the 16-minute transmission).

[0078] Thus, the method in this embodiment uses segmented delivery and packet replies with packet counts to upgrade the firmware of the host control board of the static load host and the main control board of the acquisition base station. This makes the firmware delivery progress completely knowable and controllable. Through the packet counting mechanism of this method, the current firmware delivery progress can be known, and ultimately, the successful download of the firmware program can be confirmed to be 100%.

[0079] Example 2

[0080] A system is provided that employs the remote firmware upgrade method for the pile testing instrument as described in Embodiment 1, such as... Figure 4 As shown, the system includes:

[0081] Static load host and data acquisition base station;

[0082] The static load host is used to upgrade the firmware of itself and the data acquisition base station by using segmented distribution and replying to each packet with packet count;

[0083] The data acquisition base station is communicatively connected to the static load host and is used to receive firmware programs from the static load host to upgrade its own firmware.

[0084] The static load host includes:

[0085] Android host computer, host control baseboard, and first LoRa module;

[0086] The Android host computer is communicatively connected to the host control baseboard and is used to detect the program version of the host control baseboard and the program version of the acquisition base station on the server. It also upgrades the firmware of the host control baseboard and the acquisition base station by using segmented distribution and replying to each packet with packet count.

[0087] The host control baseboard is communicatively connected to the first Lora module and is used to upgrade the firmware of the acquisition base station by forwarding the firmware program sent by the Android host computer through the first Lora module.

[0088] The first Lora module is communicatively connected to the acquisition base station.

[0089] The data acquisition base station includes:

[0090] The main control board and the second LoRa module;

[0091] The main control board is communicatively connected to the second Lora module and is used to upgrade the firmware of the main control board by receiving the firmware program sent by the Android host computer through the second Lora module.

[0092] The second Lora module is communicatively connected to the first Lora module.

[0093] Thus, the system in this embodiment uses a segmented delivery and packet-by-packet reply with packet count to upgrade the firmware program of the host control board of the static load host and the main control board of the acquisition base station. This makes the firmware delivery progress completely knowable and controllable. Through the packet count mechanism of this method, the current firmware delivery progress can be known, and finally, the successful download of the firmware program can be confirmed to be 100%.

[0094] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A remote firmware upgrade method for a foundation pile detector, characterized in that: Includes the following steps: S1: The program version of the host control board on the Android host computer detection server of the static load host and the program version of the main control board of the acquisition base station. S2: If a new version of the host control board program is detected on the server, the firmware program of the host control board will be upgraded by means of segmented distribution and replying with each packet and attaching a packet count. S3: If a new version of the program on the main control board of the acquisition base station is detected on the server, the firmware program of the main control board of the acquisition base station will be upgraded by segmented distribution and replying with each packet and attaching a packet count through LoRa communication. Step S2 specifically includes: S201: If a new version of the program on the host control board on the server is detected, the operator shall decide whether to upgrade the host control board at this time. If no upgrade is required or no new version is detected, the static load host will start and run normally. S202: If an upgrade is selected, the host computer program will obtain the new firmware program for the host control board from the server and prompt the operator to perform a static load host power-off and restart operation. S203: After the static load host is powered on again, the host computer program sends a firmware upgrade command to the host control baseboard, along with the number of firmware program segments to be downloaded to the host control baseboard. At this time, the host control baseboard enters the upgrade waiting mode. After the host computer program downloads the corresponding number of firmware program segments to the host control baseboard in sequence, and the host control baseboard replies to the host computer program line by line to confirm that the firmware download is correct, the host computer prompts that the firmware download is successful, the firmware upgrade of the host control baseboard is completed, and the new firmware program runs.

2. The remote firmware upgrade method for the pile foundation detector as described in claim 1, characterized in that: Before step S201, the method further includes: The program storage is partitioned on the host control panel, into two parts: The first part serves as the boot area, used to store the upgrade boot control program required for firmware upgrades. The upgrade boot control program is used to control the firmware program to be sent, burned, and boot the device's firmware program. The second part serves as the application firmware area, used to store firmware programs that maintain the normal operation of the host control board's business functions.

3. The remote firmware upgrade method for the pile foundation detector as described in claim 1, characterized in that: Step S3 specifically includes: S301: If a new version of the program on the main control board of the acquisition base station is detected on the server, the operator shall decide whether to upgrade the main control board of the acquisition base station at this time. If no upgrade is required or no new version is detected, the main control board of the acquisition base station will start and run normally. S302: If an upgrade is selected, the host computer program of the manually controlled static load host downloads the new firmware program of the main control board of the acquisition base station from the server, and sends it to the acquisition base station in segments via serial port through the host control board to LoRa communication. At the same time, a mechanism for verifying and retransmitting error packets is added. If the verification of a certain segment fails, or the acquisition base station replies with a timeout, the host computer program will retransmit the segment until every segment is successfully sent. After the main control board of the acquisition base station replies to the host computer program to confirm that the firmware download is correct, the host computer will indicate that the firmware download is successful, the firmware upgrade of the main control board of the acquisition base station is completed, and the new firmware program is running.

4. The remote firmware upgrade method for the pile foundation detector as described in claim 3, characterized in that: Before step S301, the method further includes: The program storage is partitioned on the main control board of the data acquisition base station, into two parts: The first part serves as the boot area, used to store the upgrade boot control program required for firmware upgrades. The upgrade boot control program is used to control the firmware program to be sent, burned, and boot the device's firmware program. The second part serves as the application firmware area, which stores the firmware program used to maintain the normal operation of the main control board's service functions at the data acquisition base station.

5. The remote firmware upgrade method for the pile foundation detector as described in claim 3, characterized in that: Step S3 also includes: When the host experiences an abnormal situation and is powered on again, the interruption point in the firmware transmission is detected by the return packet count value, and the interruption point is resumed.

6. A system employing a remote firmware upgrade method for a pile foundation testing instrument as described in any one of claims 1-5, characterized in that: The system includes: Static load host and data acquisition base station; The static load host is used to upgrade the firmware of itself and the data acquisition base station by using segmented distribution and replying to each packet with packet count; The data acquisition base station is communicatively connected to the static load host and is used to receive firmware programs from the static load host to upgrade its own firmware.

7. The system as described in claim 6, characterized in that: The static load host includes: Android host computer, host control baseboard, and first LoRa module; The Android host computer is communicatively connected to the host control baseboard and is used to detect the program version of the host control baseboard and the program version of the acquisition base station on the server. It also upgrades the firmware of the host control baseboard and the acquisition base station by using segmented distribution and replying to each packet with packet count. The host control baseboard is communicatively connected to the first Lora module and is used to upgrade the firmware of the acquisition base station by forwarding the firmware program sent by the Android host computer through the first Lora module. The first Lora module is communicatively connected to the acquisition base station.

8. The system as described in claim 7, characterized in that: The data acquisition base station includes: The main control board and the second LoRa module; The main control board is communicatively connected to the second Lora module and is used to upgrade the firmware of the main control board by receiving the firmware program sent by the Android host computer through the second Lora module. The second Lora module is communicatively connected to the first Lora module.

Images