A communication control method based on dynamic AT instruction analysis and multi-protocol fusion

Abstract

A communication control method based on dynamic AT instruction analysis and multi-protocol fusion, through constructing an asynchronous non-blocking instruction queue, the application layer returns immediately after queuing the AT instruction, and the dedicated sending thread sends in sequence when the serial port is idle, eliminating the I / O blocking of the application layer; through a dynamic fuzzy matching algorithm, a two-dimensional traversal strategy of "cutting first and then matching" is adopted, after cutting the serial port byte stream according to "\r\n" line, the extensible message processor mapping table is used to dynamically bind the processor function, solving the data conflict problem of active reporting code stream and instruction response; through the in-band digestion and forwarding mechanism, the local state update and remote protocol forwarding are completed on a single data receiving path, realizing the fusion processing of multi-protocol format. The application is suitable for the remote control scene of the fixed station host to the channel machine in the professional mobile communication system such as TETRA, and significantly improves the real-time performance, reliability and scalability of the communication control.

Description

Technical Field

[0001] This invention relates to the field of wireless communication control technology, specifically to a communication control method based on dynamic AT command parsing and multi-protocol fusion, applicable to remote control scenarios of fixed host to channel unit in professional mobile communication (PMR) systems. Background Technology

[0002] In professional mobile communication systems, fixed-station hosts typically connect to channel units via serial ports, using AT command sets to perform operations such as parameter configuration, call control, and status queries on the channel units. Traditional AT command control schemes generally employ a synchronous blocking mode of "send-wait-parse," meaning that after the application layer sends an AT command, it blocks and waits for the channel unit to return a response, and only sends the next command after parsing is complete.

[0003] This synchronous blocking mode has the following technical drawbacks: 1. Serial port data stream conflicts lead to parsing misalignment. As an active communication device, the channel unit not only responds to the host's query commands but also actively reports unsolicited status code streams when the network status changes, such as incoming call notification + CTICN, call authorization + CTXG, call disconnection + CTCR, etc. When the actively reported code stream and the ongoing command response arrive interleaved in the serial port byte stream, the traditional blocking scheme cannot distinguish the data ownership, leading to parsing misalignment or system freeze.

[0004] 2. Burst streams can cause buffer overflows. In specialized communication networks such as TETRA (Terrestrial Trunking Radio), the channel unit may continuously report multiple status messages in a short period of time, such as simultaneously reporting +CTICN incoming calls, +CTCC call setup, and +CTXG call rights granting. The traditional single-buffer structure is prone to overflow, resulting in the loss of critical status information.

[0005] 3. Application layer I / O blocking causes control response delay. When the application layer needs to send call control commands such as initiating a group call (ATD), hanging up (ATH), or pressing AT+CTXD on PTT, if the serial port is in a blocked state waiting for the response of the previous command, the new control command cannot be sent in time, resulting in a poor user experience and high control response delay.

[0006] 4. Poor compatibility with multiple data formats. In actual deployments, fixed hosts need to handle multiple data formats simultaneously: AT command text format, internal binary protocol format (including CRC checksum), UDP network transmission format, etc. Traditional solutions typically design separate processing logic for each format, lacking a unified protocol fusion mechanism, resulting in high code redundancy and high maintenance costs.

[0007] A search revealed several existing technologies for improving AT command processing: Solution 1 employs multi-threaded separate transmission and reception, similar to independent read / write threads in Linux serial port programming. However, this solution only addresses the parallelism of transmission and reception, failing to resolve data conflicts between proactively reported code streams and command responses. Solution 2 uses a state machine to parse AT responses, such as binding each command to a specific expected echo. However, this solution has weak processing capabilities for non-requested code streams, and the state machine is prone to entering an illegal state when unexpected proactive reporting occurs. Solution 3 employs a timeout retransmission mechanism, such as waiting for a fixed timeout after transmission. However, this solution is inefficient in scenarios with frequent proactive reporting, with a significant amount of time consumed in timeout waiting.

[0008] In summary, existing technologies lack a comprehensive communication control scheme that can simultaneously resolve serial port data stream conflicts, bursty bit stream processing, application layer I / O blocking, and multi-protocol integration. Summary of the Invention

[0009] To address the problems in existing AT command control schemes, such as serial port data stream conflicts leading to parsing misalignment, sudden active reporting of code streams causing buffer overflows, application layer I / O blocking causing control response delays, and poor compatibility of multi-protocol data formats, this invention provides a communication control method based on dynamic AT command parsing and multi-protocol fusion. It achieves asynchronous transmission and automatic scheduling of AT commands, dynamic line segmentation and fuzzy matching parsing of serial port data, and parallel processing of local state digestion and remote protocol forwarding, significantly improving the real-time performance, reliability, and scalability of communication control.

[0010] The technical solution adopted in this invention is: a communication control method based on dynamic AT command parsing and multi-protocol fusion, implemented based on a control box, a fixed host, and a channel machine. The steps are as follows: Step 1, the control box sends AT commands to the fixed host via a UDP network. The application layer of the fixed host encapsulates the AT commands to be sent into a linked list node, appends it to the tail of the asynchronous non-blocking command queue, and then returns immediately. The serial port main loop thread of the fixed host calls the sending processing function in each polling cycle, and retrieves them in order when the serial port is idle and sends them to the channel machine through the serial port, thereby realizing non-blocking interaction between the application layer and the control box. After the control box sends the command, it can continue to execute subsequent tasks without waiting for the serial port to complete the transmission. Step 2: In the same polling cycle of the serial port main loop thread, the fixed host receives the raw byte stream reported by the channel machine through the serial port, performs line segmentation on the continuous data in the receiving buffer, and divides the continuous byte stream into independent lines according to the "\r\n" delimiter, thereby unifying the non-request code stream and instruction response code stream actively reported by the channel machine into the same parsing framework. Step 3: Based on the independent rows cut out in Step 2, construct an extensible message processor mapping table. The message processor mapping table stores the correspondence between message prefix strings and processor functions. On the serial port data receiving path, each batch of cut independent rows is received, triggering local parsing processing. Traverse the message processor mapping table, use the strncmp prefix matching algorithm to dynamically bind each row of data with the corresponding processor function and execute it. After obtaining the matching result, directly update the local status parameters of the fixed host. Thus, it can correctly parse the active reporting code stream that arrives at any time without having to pre-specify the expected echo. Step four: The fixed host takes over the serial port data receiving path from step two. While the local parsing process in step three is being executed, the local digestion process and the remote forwarding process are performed in parallel: the local digestion process calls the matching result from step three to update the local status parameters of the fixed host, and the remote forwarding process encapsulates the raw data according to the internal protocol format and sends it to the control box via the UDP network, thereby realizing "one-time reception, dual processing" of serial port data and completing the unified integration of the local status synchronization of the fixed host and the remote transparent proxy of the control box; it realizes non-blocking asynchronous transmission of the channel machine serial port data stream, dynamic fuzzy matching parsing, and pipelined processing of in-band digestion and forwarding.

[0011] The asynchronous non-blocking instruction queue described in step one adopts a doubly linked list structure. Each linked list node contains fields for instruction string, instruction length, enqueue timestamp, and instruction type. The serial port main loop thread checks whether there is an instruction waiting for a response in each poll. If not, it takes a node from the head of the queue and sends it through the serial port. After sending, it releases the node's memory. If there is an instruction, it further checks whether the current instruction has timed out: it records the sending timestamp of each instruction. If a preset timeout threshold of 800-1200 milliseconds has been exceeded since sending and no valid response has been received, the current instruction is automatically discarded, the receive buffer is cleared, and the serial port is released, allowing subsequent instructions to continue sending in subsequent polls. This automatically restores the communication link when the channel device is unresponsive, avoiding system freeze. If the timeout threshold has not been exceeded, the current sending operation is skipped, and the current instruction is waited for to be completed in subsequent polls. The polling period is 1 millisecond.

[0012] The line splitting described in step two is implemented using the thread-safe strtok_r function, which uses "\r\n" as the delimiter to divide the continuous byte stream in the receive buffer into a maximum of 20 independent lines.

[0013] The prefix matching algorithm described in step three adopts a two-dimensional traversal strategy of "segmentation first, then matching". After dividing the serial port byte stream into rows, each row of data is dynamically bound to the corresponding processor function through strncmp prefix comparison. The message prefix string is compared with the beginning part of the row to be matched. The matching length is based on the length of the prefix string. Fuzzy matching of AT response messages with parameters is supported. The message processor mapping table is implemented using a structure array. Each structure contains the message prefix string and function pointer. When adding a new AT response type, only the message processor mapping table entry and the corresponding processor function implementation need to be added. There is no need to modify the core parsing logic.

[0014] The local processing described in step four further includes: updating one or more status parameters among the channel device's initialization status flag, recording push status flag, default group number, individual number, and call instance identifier according to the matching result; the remote forwarding processing further includes: encapsulating the raw data according to a custom internal protocol format, wherein the internal protocol format includes a type identifier byte, a length field, a data payload, and a CRC-16 check field; the internal protocol format identification uses the hexstring function to determine the format type of the serial port data, and if it is text format, the data is appended to the receiving buffer for local processing, and if it is binary format, the buffer is cleared.

[0015] The technical effects of this invention are as follows: By constructing an asynchronous non-blocking instruction queue, the application layer enqueues AT instructions and returns immediately, which are then sent sequentially by a dedicated sending thread when the serial port is idle, thus eliminating application layer I / O blocking; through a dynamic fuzzy matching algorithm, using a two-dimensional traversal strategy of "cutting first and then matching", the serial port byte stream is cut into rows of "\r\n", and the processor function is dynamically bound using an extensible message processor mapping table, thus solving the data conflict problem between the actively reported code stream and the instruction response; through an in-band digestion and forwarding mechanism, local status updates and remote protocol forwarding are completed simultaneously on a single data receiving path, realizing the fusion processing of multiple protocol formats.

[0016] This invention is applicable to remote control scenarios of fixed host to channel unit in professional mobile communication systems such as TETRA, significantly improving the real-time performance, reliability and scalability of communication control. Attached Figure Description

[0017] Figure 1 This is a diagram of the overall system architecture of the present invention; Figure 2 This is a timing diagram of the asynchronous non-blocking instruction queue of the present invention; Figure 3 This is a flowchart of the dynamic fuzzy matching algorithm of the present invention; Figure 4 This is a data flow diagram of the in-band digestion and forwarding mechanism of this invention; Figure 5 This is the timing diagram for the main loop scheduling of this invention. Detailed Implementation

[0018] This invention proposes a communication control method based on dynamic AT command parsing and multi-protocol fusion. It adopts a modular and scalable AT command processing architecture and achieves efficient, reliable, and real-time communication control through the collaborative work of three core mechanisms: Mechanism 1: Asynchronous non-blocking command queue; The doubly linked list structure atcmd_list is used to cache the AT commands to be sent. The serial port main loop thread thread_serial calls the send processing function at_tx_process in each polling cycle to send the commands in sequence when the serial port is idle. The application layer does not need to block and wait for I / O to complete.

[0019] Mechanism 2: Dynamic fuzzy matching algorithm; adopts a two-dimensional traversal strategy, firstly the serial port receive buffer cmdbuf is divided into rows according to the "\r\n" delimiter, then the expandable message processor mapping table msg_handlers[] is traversed, and each row of data is dynamically bound to the corresponding processor function through the strncmp prefix matching algorithm.

[0020] Mechanism 3: In-band digestion and forwarding mechanism; a protocol conversion layer is embedded in the serial port data receiving path, and the hexstring function is used to realize the automatic recognition and conversion of binary or text format. The at_proxy_process_serial_rx function simultaneously completes local digestion, that is, calls at_cmd_process for parsing and processing, and remote forwarding, that is, the raw data is encapsulated according to the internal protocol format and sent to the remote control end via UDP, realizing "one-time reception, dual processing".

[0021] 1. System overall architecture, such as Figure 1 As shown, the application implementing this invention is deployed within a fixed host unit, using an embedded Linux platform. The fixed host unit is located between the control box and the channel unit, enabling bidirectional communication. The system includes the following core modules: an AT command asynchronous queue module atcmd_list, responsible for caching and scheduling AT commands; an AT response dynamic parsing module at_cmd_process + msg_handlers[], responsible for line segmentation, prefix matching, and processor distribution of serial port received data; a protocol conversion and forwarding module at_proxy_process_serial_rx, responsible for data format conversion and remote transparent proxy; and an extensible message processor mapping table msg_handlers[], storing the mapping relationship between message prefixes and processor functions.

[0022] 2. Asynchronous non-blocking instruction queues, such as... Figure 2As shown, the asynchronous non-blocking instruction queue process is as follows: After starting the thread_serial main loop, the application layer initiates an AT command request, such as a group call, hang-up, or PTT control, calling atcmd_add_last_str() to encapsulate the command as an _atcmd node, appending it to the tail of the atcmd_list linked list, and then returning immediately without blocking the calling thread. Simultaneously, the main loop calls at_tx_process() in each cycle, first checking if the serial port is idle. If the serial port is not idle, it skips sending and waits for the current command to complete; if the serial port is idle, it further checks if the queue is empty. If the queue is empty, it skips, with no command to send; if the queue is not empty, it calls list_get_first() to retrieve the first node, sends it to the channel machine via serial port using serial_write(), and then enters a state of waiting for a response from the channel machine. During the waiting process, it checks whether a response has been received from the channel machine. If a response is received, the current cmd node is released, and the command processing is complete; if no response is received, it enters the timeout detection branch, checking if the difference between the current timestamp and the enqueue timestamp exceeds 1000 milliseconds. If the timeout period is less than 1000 milliseconds, the system continues to wait for a response; if it exceeds 1000 milliseconds, the instruction is deemed to have timed out, the current instruction is automatically discarded, the cmd node is released and the cmd pointer is cleared, and the serial port is released. Regardless of the branch, `usleep(1000)` is ultimately executed to achieve 1-millisecond cycle control, and then the main loop returns to the beginning of the next polling cycle. This mechanism proposes an asynchronous AT instruction queue architecture based on a doubly linked list. The application layer enqueues the instruction and returns immediately, and the `thread_serial` main loop sends the instructions in sequence when the serial port is idle, completely eliminating application layer I / O blocking. Combined with the 1000ms timeout management mechanism, the serial port resources are automatically released when the channel device is unresponsive, preventing the system from appearing to freeze.

[0023] 3. Dynamic fuzzy matching algorithms, such as... Figure 3As shown, the dynamic fuzzy matching algorithm is one of the core innovations of this invention. It is implemented by the at_cmd_process function and adopts a two-dimensional traversal strategy of "slicing first and then matching". The specific processing flow is as follows: cmdbuf serves as a serial port receiving buffer, which stores the original response data received from the channel machine, such as multiple lines of data including "+CTICN:1,2,3\r\n", "+CTXG:1,1,0\r\n", and "OK\r\n". First, cstr_split() is called to slice the continuous byte stream in cmdbuf with "\r\n" as the delimiter, dividing the original data into independent lines, such as "+CTICN:...", "+CTXG:...", and "OK". Then, the two-dimensional traversal matching stage is entered. The message handler mapping table msg_handlers[] is traversed. For each line of data after the slice, the entire message handler mapping table is traversed by a for loop. For each entry, strncmp is called to perform prefix matching to determine whether the line starts with a certain message prefix in the message handler mapping table. If a match is successful, i.e., strncmp returns 0, the corresponding handler function handler[j].func_ptr(...) is called to execute the corresponding local state update logic. Specifically, when the "+CTICN" prefix is ​​matched, the handle_CTICN handler function is called to set the recording push stream flag is_recording to true; when the "+CTXG" prefix is ​​matched, the handle_CTXG handler function is called to parse and record the call instance identifier cc_instance = 1; when the "OK" prefix is ​​matched, the handle_OK handler function is called to set the initialization completion flag is_initialized to true and trigger the parameter configuration process. The extensible message handler mapping table msg_handlers[] uses a structure array to store the mapping relationship between message prefixes and handler functions, and supports dynamic expansion. The message processor mapping table contains 10 entries, covering key AT response types such as group number notification + CTGS, call mode notification + CTOM, individual number notification + CNUMF, call disconnection + CTCR, call rights grant + CTXG, call termination + CDTXC, incoming call notification + CTICN, call setup + CTCC, call in progress + CTOCP, and command execution success OK. This mechanism proposes a two-dimensional traversal parsing strategy of "segmentation first, matching later." It uses a "\r\n" line splitter to divide the serial port byte stream into independent message lines, and then uses an extensible message processor mapping table to dynamically bind each line of data to the corresponding processor function.Using prefix matching instead of exact match or substring match has the following advantages: it is compatible with parameterized AT responses, such as "+CTICN:1,2,3\r\n" which can directly match the prefix "+CTICN"; the matching time complexity is O(n), which is independent of the response content length; it naturally supports priority sorting, allowing high-priority processors to be placed at the top of the message processor mapping table. This algorithm naturally supports the processing of unsolicited proactively reported code streams, such as +CTICN, +CTXG, +CTCR, and +CTCC, without requiring pre-specified expected responses, thus solving the parsing misalignment problem of traditional state machine solutions when dealing with bursty code streams.

[0024] 4. In-band digestion and forwarding mechanisms, such as Figure 4 As shown, the in-band digestion and forwarding mechanism is another core innovation of this invention, achieving "one-time reception, dual processing" on the serial port data receiving path. The specific processing flow is as follows: After starting the thread_serial main loop, the data receiving operation is executed first. The serial_read() function is called to read the raw byte stream from the serial port and store the read data in the tmpbuf temporary buffer. Then, the hexstring() function is called to identify the format and determine the data format type: if it is binary format, the cmdbuf buffer is cleared, wr is set to 0, and no further parsing and forwarding processing is performed; if it is text format, the data in tmpbuf is appended to the cmdbuf receiving buffer using memcpy, and subsequent processing continues. After completing the format identification and data appending, the process enters two processing paths in parallel: the local digestion processing path: the at_cmd_process() function is called to perform parsing processing. First, the data in cmdbuf is split into lines using cstr_split() with the newline character \n as the delimiter, dividing the continuous byte stream into independent lines. Then, the message handler mapping table `msg_handlers[]` is traversed, and strncmp prefix matching is performed on each line to find the corresponding handler. Upon successful matching, the corresponding handler function is called to update local status parameters, including the recording / pushing flag `is_recording`, the call instance identifier `cc_instance`, and the initialization completion flag `is_initialized`. Remote forwarding processing path: `pack_protocol_packet()` is called to encapsulate the raw data according to the internal protocol format, which includes a type identifier, length, data payload, and a CRC-16 checksum field. After encapsulation, the data packet is sent to the remote console via UDP `sendto()`.

[0025] After the two paths described above are executed in parallel, the same serial port data received achieves "one-time reception, dual processing": both the state digestion is completed locally, and the data is forwarded to the remote control terminal after protocol encapsulation. The entire process achieves zero data copying, eliminating the need for secondary serial port reading. Finally, `usleep(1000)` is executed to implement 1-millisecond cycle control, returning to the main loop to begin the next polling cycle.

[0026] 5. Main loop timing control, such as... Figure 5 As shown, the thread_serial main loop has a fixed period of 1ms, and each period is executed strictly in sequence: Period N: at_tx_process() detects cmd=NULL and the queue is empty, skips sending; at_proxy_process_serial_rx() has no data, skips; Period N+1: at_tx_process() retrieves the ATD instruction from the queue and sends it to the channel device via serial port; no data is received; usleep(1000). Period N+2: at_tx_process() detects that cmd is not empty and waits for a response; at_proxy_process_serial_rx() receives the OK response, internally calls at_cmd_process() to complete local parsing, and encapsulates the raw data into an internal protocol packet and forwards it to the control box via UDP; at_rx_process releases the current cmd node after detecting CMD_RETURN_OK; usleep(1000). Period N+3: at_tx_process() detects cmd=NULL and continues processing the next instruction or idle; no data is received; usleep(1000). This process repeats continuously, ensuring that the tasks of sending, receiving, processing, and forwarding operate in a tightly integrated, streamlined manner within a 1ms cycle.

[0027] This mechanism proposes a "one-time reception, dual processing" serial port data stream processing architecture, simultaneously completing local state digestion and remote protocol forwarding on a single data reception path, avoiding the overhead of repeated data reading and secondary parsing. The hexstring function enables automatic identification of binary / text formats, supporting the fusion processing of multiple protocol data formats. Precise control of the main loop's 1ms cycle and usleep(1000) ensures the system's real-time performance and stability in high-frequency AT command interaction scenarios.

[0028] Example 1: Group call initiation scenario. This example describes the complete process of how the various mechanisms of the present invention work together when a user initiates a TETRA group call through the control box.

[0029] Step 1: Application Layer Constructs and Queues Instructions. The control box sends a group call request to the fixed station host via the UDP network. Upon receiving the request, the fixed station host calls the group call setting function, which constructs two AT instructions: the first, AT+CTSDC=0,0,0,1,1,0,1,1,0,0\r\n, is the call parameter configuration instruction; the second, ATD{group}\r\n, is the group call dialing instruction. The two instructions sequentially call the enqueue function, encapsulating them into independent linked list nodes and appending them to the tail of the atcmd_list linked list. The function returns immediately after each instruction is enqueued, without blocking or waiting for serial port I / O operations. The application layer thread can continue executing subsequent tasks without waiting for the actual transmission of the instruction.

[0030] Step 2: The asynchronous sending thread sends data in sequence. In the next thread_serial main loop cycle, at_tx_process detects that atcmd_list is not empty and the serial port is idle, retrieves the first node AT+CTSDC=... and sends it through the serial port. After sending is complete, ATD1011105 continues to be sent in subsequent cycles.

[0031] Step 3: Channel device response parsing. After receiving the command, the channel device returns OK\r\n. The serial port receives data and enters at_rx_process: serial_read reads OK\r\n; hexstring is recognized as text format and appended to cmdbuf; at_cmd_process calls cstr_split to cut out "OK"; msg_handlers[] is traversed and {"OK", handle_OK} is matched; handle_OK detects is_initialized == false and calls l2t_channel_configure_parameter to complete the channel device initialization parameter configuration.

[0032] Step 4: Status Update and Forwarding. `handle_OK` sets `is_initialized` to true and illuminates the LAN indicator light. Simultaneously, `at_proxy_process_serial_rx` encapsulates `OK\r\n` into an internal protocol packet and forwards it to the control box via UDP, notifying the user that the group call has been successfully initiated.

[0033] Example 2: Incoming call notification and audio streaming linkage scenario. This example describes the complete process of the various mechanisms of the present invention working together when the channel device actively reports an incoming call notification.

[0034] Step 1: Channel device actively reports. Upon detecting an incoming call, the channel device actively reports via the serial port: +CTICN:1,0,0,0,1011110,1,1,0,1,1,0,1011105,0\r\n +CTCC:1,1,1,0,0,1,1\r\n.

[0035] Step 2: Serial port reception and format recognition. at_rx_process reads the above data through serial_read, recognizes hexstring as text format, and appends it to cmdbuf.

[0036] Step 3: Line splitting and 2D matching. `at_cmd_process` calls `cstr_split` to split the data into two lines: line 0 is "+CTICN:1,0,0,0,1011110,1,1,0,1,1,0,1011105,0", and line 1 is "+CTCC:1,1,1,0,0,1,1". Iterate through `msg_handlers[]`: line 0 matches {"+CTICN", handle_CTICN}, `is_recording = true`, and audio streaming is started; line 1 matches {"+CTCC", handle_CTCC}, `is_recording = true` (confirming it has started).

[0037] Step 4: Local processing and remote forwarding. After the local state update is complete, at_proxy_process_serial_rx encapsulates the raw data into an internal protocol packet and forwards it to the control box via UDP. The control box then starts audio reception and playback based on this packet.

[0038] Step 5: Call End Cleanup. The channel unit reports "+CTCR: 1,0\r\n" (call disconnected), handle_CTCR sets is_recording to false, and stops audio streaming.

[0039] Example 3: PTT control and talk rights granting scenario. This example describes the complete process of how the various mechanisms of the present invention work together when a user presses the PTT (Push-to-Talk) button.

[0040] Step 1: PTT Pressed. The control box sends a PTT press command to the fixed station host via the UDP network. Upon receiving the command, the fixed station host calls the PTT press processing function. This function dynamically constructs the AT command AT+CTXD={cc_instance},2,0\r\n, where {cc_instance} is the current call instance identifier, dynamically filled by the fixed station host based on the current call status, used to specify the call instance corresponding to the call right request. After the command is constructed, the enqueue function is called to encapsulate the command into a linked list node and append it to the tail of the atcmd_list linked list. The function returns immediately without blocking and waiting for serial port I / O operations. The serial port main loop thread retrieves the command when the serial port is idle and sends it to the channel unit to request call right from the system.

[0041] Step 2: Asynchronous transmission. at_tx_process retrieves and sends the command when the serial port is idle.

[0042] Step 3: Talk rights grant notification. After granting talk rights, the channel unit actively reports "+CTXG: 1,1,0,0\r\n". at_cmd_process matches {"+CTXG", handle_CTXG} and updates cc_instance = 1.

[0043] Step 4: PTT Release. The control box sends a PTT release command to the fixed station host via the UDP network. Upon receiving the command, the fixed station host calls the PTT release processing function. This function dynamically constructs the AT command AT+CUTXC={cc_instance}\r\n, where {cc_instance} is the current call instance identifier, dynamically filled by the fixed station host according to the current call status, used to specify the call instance corresponding to the release of talk rights. After the command is constructed, the enqueue function is called to encapsulate the command into a linked list node and append it to the tail of the atcmd_list linked list. The function returns immediately without blocking and waiting for serial port I / O operations. The serial port main loop thread retrieves the command when the serial port is idle and sends it to the channel device, releasing the currently occupied talk rights to the system.

[0044] Step 5: Forward to the control box. at_proxy_process_serial_rx encapsulates the response AT+CUTXC=1\r\n into an internal protocol packet and forwards it to the control box via UDP, notifying the PTT that it has been released.

[0045] Example 4: Timeout and Error Recovery Scenario. This example describes the timeout management and error recovery mechanism of the present invention when the channel device does not respond or responds abnormally.

[0046] Step 1: Command transmission. at_tx_process retrieves AT+CTSDC=0,0,0,1,1,0,1,1,0,0\r\n from atcmd_list and transmits it via serial port, recording the transmission timestamp tick_ms.

[0047] Step 2: Wait for a response. In the subsequent main loop cycle of thread_serial, at_tx_process detects that this->cmd != NULL (waiting for a response) and skips the send operation. at_proxy_process_serial_rx continues to read serial port data.

[0048] Step 3: Timeout Detection. Timeout detection logic is executed in each call to the serial port data receiving and processing function. First, it checks if there is an instruction currently being executed. If so, it calculates the difference between the current timestamp and the instruction's enqueue timestamp and checks if it exceeds 1000 milliseconds. If it exceeds 1000 milliseconds, the instruction is considered timed out, and a timeout cleanup operation is immediately performed: the serial port receive buffer is cleared, the instruction string memory and node memory occupied by the current instruction are released, the instruction pointer is set to null, and the serial port is released, allowing the next instruction waiting to be sent to obtain the right to send data. If it does not exceed 1000 milliseconds, the system continues to wait for a response without any further action.

[0049] Step 4: Automatic Recovery. After the timeout, this->cmd is reset to NULL, and at_tx_process automatically retrieves the next instruction from atcmd_list in the next cycle to continue sending. The system automatically returns to normal operation without manual intervention.

[0050] Step 5: Handling incomplete responses. When at_cmd_process returns CMD_RETURN_NOT_COMPLETE (if the response data is truncated by TCP / IP packets), at_rx_process retains the existing data in cmdbuf and continues to wait for subsequent data to arrive before appending and parsing, until a complete response is received or a timeout occurs.

Claims

1. A communication control method based on dynamic AT command parsing and multi-protocol fusion, characterized in that, Based on a control box, a fixed host unit, and a channel unit, the steps are as follows: Step 1: The control box sends AT commands to the fixed host via UDP network. The application layer of the fixed host encapsulates the AT commands to be sent as linked list nodes, appends them to the tail of the asynchronous non-blocking command queue, and then returns immediately. The serial port main loop thread of the fixed host calls the sending processing function in each polling cycle, and retrieves them in order when the serial port is idle and sends them to the channel machine through the serial port, thereby realizing non-blocking interaction between the application layer and the control box. After the control box sends the command, it can continue to execute subsequent tasks without waiting for the serial port to complete the transmission. Step 2: In the same polling cycle of the serial port main loop thread, the fixed host receives the raw byte stream reported by the channel machine through the serial port, performs line segmentation on the continuous data in the receiving buffer, and divides the continuous byte stream into independent lines according to the "\r\n" delimiter, thereby unifying the non-request code stream and instruction response code stream actively reported by the channel machine into the same parsing framework. Step 3: Based on the independent rows cut out in Step 2, construct an extensible message processor mapping table. The message processor mapping table stores the correspondence between message prefix strings and processor functions. On the serial port data receiving path, each batch of cut independent rows is received, triggering local parsing processing. Traverse the message processor mapping table, use the strncmp prefix matching algorithm to dynamically bind each row of data with the corresponding processor function and execute it. After obtaining the matching result, directly update the local status parameters of the fixed host. Thus, it can correctly parse the active reporting code stream that arrives at any time without having to pre-specify the expected echo. Step four: The fixed host takes over the serial port data receiving path from step two. While the local parsing process in step three is being executed, the local digestion process and the remote forwarding process are performed in parallel: the local digestion process calls the matching result from step three to update the local status parameters of the fixed host, and the remote forwarding process encapsulates the raw data according to the internal protocol format and sends it to the control box via the UDP network, thereby realizing "one-time reception, dual processing" of serial port data and completing the unified integration of the local status synchronization of the fixed host and the remote transparent proxy of the control box; it realizes non-blocking asynchronous transmission of the channel machine serial port data stream, dynamic fuzzy matching parsing, and pipelined processing of in-band digestion and forwarding.

2. The communication control method based on dynamic AT command parsing and multi-protocol fusion according to claim 1, characterized in that, The asynchronous non-blocking instruction queue described in step one adopts a doubly linked list structure. Each linked list node contains fields for instruction string, instruction length, enqueue timestamp, and instruction type. The serial port main loop thread checks whether there is an instruction waiting for a response in each poll. If not, it takes a node from the head of the queue and sends it through the serial port. After sending, it releases the node's memory. If there is an instruction, it further checks whether the current instruction has timed out: it records the sending timestamp of each instruction. If a preset timeout threshold of 800-1200 milliseconds has been exceeded since sending and no valid response has been received, the current instruction is automatically discarded, the receive buffer is cleared, and the serial port is released, allowing subsequent instructions to continue sending in subsequent polls. This automatically restores the communication link when the channel device is unresponsive, avoiding system freeze. If the timeout threshold has not been exceeded, the current sending operation is skipped, and the current instruction is waited for to be completed in subsequent polls. The polling period is 1 millisecond.

3. The communication control method based on dynamic AT command parsing and multi-protocol fusion according to claim 1, characterized in that, The line splitting described in step two is implemented using the thread-safe strtok_r function, which uses "\r\n" as the delimiter to divide the continuous byte stream in the receive buffer into a maximum of 20 independent lines.

4. The communication control method based on dynamic AT command parsing and multi-protocol fusion according to claim 1, characterized in that, The prefix matching algorithm described in step three adopts a two-dimensional traversal strategy of "segmentation first, then matching". After dividing the serial port byte stream into rows, each row of data is dynamically bound to the corresponding processor function through strncmp prefix comparison. The message prefix string is compared with the beginning part of the line to be matched. The matching length is based on the length of the prefix string. Fuzzy matching of AT response messages with parameters is supported. The message processor mapping table is implemented using a structure array. Each structure contains the message prefix string and function pointer. When adding a new AT response type, only the message processor mapping table entry and the corresponding processor function implementation need to be added. There is no need to modify the core parsing logic.

5. The communication control method based on dynamic AT command parsing and multi-protocol fusion according to claim 1, characterized in that, The local processing described in step four further includes: updating one or more status parameters among the channel device's initialization status flag, recording push status flag, default group number, individual number, and call instance identifier according to the matching result; the remote forwarding processing further includes: encapsulating the raw data according to a custom internal protocol format, wherein the internal protocol format includes a type identifier byte, a length field, a data payload, and a CRC-16 check field; the internal protocol format identification uses the hexstring function to determine the format type of the serial port data, and if it is text format, the data is appended to the receiving buffer for local processing, and if it is binary format, the buffer is cleared.

Images