A flight simulator signal acquisition and transmission system based on UDP communication

Abstract

The application provides a flight simulator signal acquisition and transmission system based on UDP communication, comprising a sending end and a receiving end, wherein the sending end identifies the acquired data obtained from the control system, the instrument system and the environment simulation system of the flight simulator to determine the target category of the current acquired data. The sending end stores the current acquired data in a cache queue corresponding to the target category and sends it to the receiving end through a UDP port corresponding to the target category.

Description

Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a signal acquisition and transmission system for a flight simulator based on UDP communication. Background Technology

[0002] With the widespread application of flight simulation technology in the field of aviation training, the signal acquisition and transmission system of flight simulators based on UDP (User Datagram Protocol) communication has become a key technological support. In existing technologies, flight simulators generate various types of simulated signals in real time, including flight attitude, engine parameters, avionics system status, and environmental data. This data is transmitted to various terminal nodes of the training system via the UDP protocol to achieve real-time data synchronization and interaction between multiple devices.

[0003] Current mainstream implementations typically employ a single transmission channel architecture, where all types of flight data share the same network transmission resources. While this approach simplifies system design complexity, it has significant limitations: critical flight control data competes for the same network bandwidth resources with non-critical auxiliary information, potentially causing transmission delays for important data when bandwidth is limited.

[0004] Especially in situations of network congestion or insufficient processing capacity at the receiving end, the system lacks an adaptive adjustment mechanism based on real-time network status feedback, making it impossible to prioritize the transmission quality of flight safety-related data. Summary of the Invention

[0005] The purpose of this application is to provide a flight simulator signal acquisition and transmission system based on UDP communication to solve the technical problems of poor response accuracy and instability in the existing flight simulator signal transmission process.

[0006] In a first aspect, the present invention provides a signal acquisition and transmission system for a flight simulator based on UDP communication, comprising a transmitter and a receiver, wherein... The transmitting end identifies the collected data from the flight simulator's control system, instrument system, and environmental simulation system to determine the target category of the currently collected data; The sending end stores the currently collected data in a cache queue corresponding to the target category, and sends it to the receiving end through the UDP port corresponding to the target category.

[0007] In an optional implementation, the sending end identifies the collected data in the following ways: When the data source for the collected data is the control system, the currently collected data is identified as a key category; When the data source for the collected data is an instrument system, the currently collected data is identified as an important category; When the data source for the collected data is an environmental simulation system, the currently collected data is classified as ordinary.

[0008] In an optional implementation, it further includes: Based on the data source of the collected data, the corresponding priority score value is determined; The target category of the collected data is updated based on the score range into which the priority score value of the collected data falls.

[0009] In an optional implementation, the step of determining the corresponding priority score value based on the data source of the collected data specifically includes: Based on the data frame identifier of the collected data, the corresponding safety impact assessment value, real-time requirement assessment value, and accuracy requirement assessment value are matched based on the preset assessment table. The weighted sum of the total impact assessment value, real-time demand assessment value, and accuracy demand assessment value is used to determine the corresponding priority score value.

[0010] In an optional implementation, the sender communicates with the receiver through the following steps: The sending end generates multiple UDP packets based on the collected data to be sent, and each UDP packet also includes a sending timestamp; The sending end sends multiple UDP data packets to the receiving end through the corresponding UDP port according to the target sending frequency.

[0011] In an optional implementation, the receiving end records the timestamp of each UDP packet received and sends it back to the sending end; The sending end determines the network latency and network jitter values ​​based on the receiving timestamp fed back by the receiving end, thereby determining the communication network status; The sending end adjusts the size and sending frequency of UDP packets based on the determined communication network status.

[0012] In an optional implementation, the sender adjusts the UDP packet transmission frequency in the following way: Calculate the product of the current transmission frequency and the correction factor, and use it as the new transmission frequency; And, the correction factor is calculated in the following way. : ; ; in, , These are the network state impact coefficient and the NACK feedback impact coefficient, respectively. This is the congestion index value. The NACK attenuation coefficient, This represents the cumulative number of NACKs within the most recent 100ms time window. , These are the delay weighting coefficient and the jitter weighting coefficient, respectively. This is a network latency smoothing value. This is the network jitter smoothing value. This is the network latency threshold. This is the network jitter threshold.

[0013] In an optional implementation, the sender calculates the current network latency smoothing value in the following manner. : The current network latency smoothing value is calculated by weighted summing of the historical network latency smoothing value and the current network latency value.

[0014] In an optional implementation, each UDP packet also includes a category identifier, and the receiving end processes the execution content of the UDP packet according to the priority corresponding to the category identifier determined from the UDP packet.

[0015] In an optional implementation, the sender adjusts the size of the UDP packets in the following way: When the frequency of UDP packet transmission decreases, the data size of the UDP packet decreases; When the frequency of UDP packet transmission increases, the amount of data in the UDP packets increases.

[0016] This application provides a UDP-based signal acquisition and transmission system for flight simulators, comprising a transmitter and a receiver. The transmitter identifies the acquired data from the flight simulator's control system, instrument system, and environmental simulation system to determine the target category of the currently acquired data. The transmitter stores the currently acquired data in a buffer queue corresponding to the target category and transmits it to the receiver through the UDP port corresponding to the target category. By classifying and grading data and allocating resources differently, limited network resources are rationally configured according to data importance, ensuring that critical flight control data obtains the optimal transmission channel and the highest transmission frequency. This fundamentally solves the resource contention problem and improves the response accuracy and stability of the flight simulator's signal transmission process. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram of a signal acquisition and transmission system for a flight simulator based on UDP communication, provided as an embodiment of this application. Detailed Implementation

[0019] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0020] Example 1 Figure 1 This is a schematic diagram of a signal acquisition and transmission system for a flight simulator based on UDP communication, provided as an embodiment of this application. Figure 1 As shown in the figure, this application provides a signal acquisition and transmission system for a flight simulator based on UDP communication, including a transmitter and a receiver, wherein... The transmitting end identifies the collected data from the flight simulator's control system, instrument system, and environmental simulation system to determine the target category of the currently collected data.

[0021] The sending end stores the currently collected data in a cache queue corresponding to the target category, and sends it to the receiving end through the UDP port corresponding to the target category.

[0022] The transmitter here can be used for signal acquisition of the flight simulator, and establish communication connections with the flight simulator's control system, instrument system, and environmental simulation system respectively. It can collect various sensor signals and control signals during the flight simulator's operation in real time, and the acquisition frequency can be set from 100Hz to 500Hz.

[0023] The sending end can classify and grade all collected data according to the degree of impact of the data on the operation of the flight simulator, and then transmit the data according to different priorities.

[0024] In this way, by classifying and grading the transmitted data and allocating resources differently, the sending end can rationally allocate limited network resources according to the importance of the data, ensuring that critical flight control data obtains the optimal transmission channel and the highest transmission frequency, fundamentally solving the problem of resource contention and guaranteeing signal response accuracy and communication stability.

[0025] In one feasible implementation, the sending end may include a signal acquisition module, a classification and grading engine, a priority queue manager, a UDP sending scheduler, a network status detection module, and a feedback receiving module.

[0026] The signal acquisition module here is used to interface with the hardware interfaces of various subsystems, acquire various raw signals, and complete steps such as signal conditioning, analog-to-digital conversion, dimensional conversion, and data frame encapsulation.

[0027] Here, the flight control data sent by the control system may include control stick pitch angle signal, control stick roll angle signal, control stick yaw angle signal, elevator yaw angle / yaw rate signal, aileron yaw angle / yaw rate signal, rudder yaw angle / yaw rate signal, pitch angle signal, roll angle signal, heading angle signal, throttle position signal, flap position signal, landing gear status signal, trim position signal, etc.

[0028] The instrument display data sent by the instrument system is used for real-time display of instruments in the flight simulator. This may include barometric altitude signals (0-15000m, accuracy ±1m), radio altitude signals, indicated airspeed signals, vacuum speed signals, ground speed signals (0-1200km / h, accuracy ±1km / h), magnetic heading signals, true heading signals (0-360°, accuracy ±0.5°), vertical speed signals, engine speed signals, engine temperature signals, fuel level signals, and VOR / ILS / DME navigation deviation signals, etc.

[0029] The environmental simulation system sends environmental simulation data to simulate the external environment during flight. This includes wind speed signals, wind direction signals, atmospheric temperature signals, atmospheric pressure signals, visibility signals, cloud height / density signals, precipitation type / intensity signals, terrain height / type data, and scene rendering parameters (lighting / texture / obstacle coordinates), etc.

[0030] The acquired data includes at least the signal ID (globally unique identifier), signal name (e.g., "elevator deflection angle"), source subsystem (control / instrument / environment, etc.), acquired value (physical engineering value after dimensional conversion), physical unit (° / m / km / h, etc.), acquisition timestamp (microsecond level), and signal status (valid / invalid / out of limit).

[0031] The classification and grading engine here can identify the categories of collected data through physical channels, data frame identifiers, feature verification, and other methods.

[0032] For example, in one embodiment, the classification and grading engine at the sending end can identify the collected data through a physical channel: When the data source is the control system, the currently acquired data is classified as critical. When the data source is the instrumentation system, the currently acquired data is classified as important. When the data source is the environmental simulation system, the currently acquired data is classified as ordinary.

[0033] The classification and grading engine can determine the source and priority of the collected data by looking up a table using the intra-frame classification code, unique signal ID, or device source address.

[0034] The classification and grading engine can further combine the established range and accuracy indicators of various types of data to perform feature matching, ensuring accurate classification.

[0035] In one feasible implementation, after the initial signal classification and identification, the classification and grading engine can also perform priority scoring to update and correct the target category of the collected data.

[0036] Specifically, priority scores can be determined based on the data source of the collected data. The target category of the collected data is then updated based on the score range into which the priority score falls.

[0037] The step of determining the corresponding priority score based on the data source of the collected data specifically includes: Based on the data frame identifiers of the collected data, the corresponding safety impact assessment value, real-time requirement assessment value, and accuracy requirement assessment value are matched according to a preset evaluation table. The total impact assessment value, real-time requirement assessment value, and accuracy requirement assessment value are weighted and summed to determine the corresponding priority score value.

[0038] The safety impact assessment value here is used to evaluate the degree of impact of data on flight control safety, and the value range is [0,1]. For example, signals that directly affect flight safety, such as joystick control signals, control surface feedback signals, and flight attitude signals, are classified as critical and can be assigned a value of 0.9-1.0. Important data, such as instrument display data, can be assigned a value of 0.3-0.6. Ordinary data, such as environmental simulation data, can be assigned a value of 0.0-0.3.

[0039] Real-time demand assessment values ​​are used to evaluate the sensitivity of data to transmission latency, with a range of [0,1]. Specifically, flight control data typically requires sub-millisecond response times and can be assigned a value of 0.9-1.0. Instrument data displays allow for delays of tens of milliseconds and can be assigned a value of 0.4-0.7. Environmental rendering data allows for delays of hundreds of milliseconds and can be assigned a value of 0.1-0.4.

[0040] The accuracy requirement assessment value is used to evaluate the degree of accuracy required for data transmission, and the value range is [0,1]. Flight control data requires an angle accuracy of ±0.1°, and can be assigned a value of 0.9-1.0. Instrument display data requires an altitude accuracy of ±1 meter, and can be assigned a value of 0.5-0.8. Environmental simulation data has relatively relaxed accuracy requirements and can be assigned a value of 0.1-0.4.

[0041] Based on flight simulator industry standards and a large amount of experimental data, the corresponding weighting coefficients can be set to W1=0.5, W2=0.3, and W3=0.2, respectively, adhering to the design principle of prioritizing safety, followed by real-time performance, and then accuracy.

[0042] Here, the weighting coefficients can also be adjusted according to the specific flight simulator model and application scenario.

[0043] Furthermore, based on the calculated priority score, the target category of the collected data can be redefined.

[0044] Specifically, data with a priority score of 0.7 or higher can be classified as critical. Data with a priority score between 0.3 and 0.7 can be classified as important. Data with a priority score of 0.3 or lower can be classified as ordinary.

[0045] In this way, classification is driven by a mathematical model based on multi-dimensional feature quantification, resulting in more reasonable classification. Furthermore, the fine-grained evaluation values ​​and weighting coefficients can be dynamically adjusted according to the flight phase (takeoff, cruise, landing, emergency).

[0046] For example, during takeoff / landing, the system can automatically increase the weight of safety impact assessment values ​​for altitude, speed, and attitude data while lowering classification thresholds, ensuring the transmission of critical data categories. During cruise, the standard weighting is restored. In emergency situations, the system automatically expands the verification threshold range for relevant parameters to avoid false alarms, ensuring that classification results reflect the actual importance of the data under the current flight conditions in real time.

[0047] The sending end communicates with the receiving end through the following steps: The sending end generates multiple UDP packets based on the collected data to be sent, each UDP packet also including a sending timestamp. The sending end sends these multiple UDP packets to the receiving end through the corresponding UDP port according to the target sending frequency.

[0048] The receiving end records the timestamp of each UDP packet received and sends it back to the sending end. Based on the timestamps from the receiving end, the sending end determines the network latency and jitter values ​​to ascertain the communication network status. Based on this determined network status, the sending end adjusts the size and transmission frequency of UDP packets.

[0049] In a specific embodiment, the priority queue manager here can maintain three 1024KB physically isolated cache queues. These three physically isolated cache queues can be used to cache different categories of data.

[0050] The UDP send scheduler can retrieve packets from the queue in priority order, encapsulate them, and send them out from the corresponding port / multicast.

[0051] In a specific embodiment, for critical data categories, a dedicated UDP port (port number set to 50001), a maximum transmission frequency of 100Hz, and an independent multicast address (set to 224.0.0.1) can be configured to form a dedicated transmission group. This ensures that such data has the highest priority in network transmission, achieving exclusive transmission and guaranteeing real-time performance and stability. After the dedicated signal acquisition module identifies the critical flight control data, it encapsulates the data into UDP packets and sends them to the preset port 50001 and multicast address 224.0.0.1, completing exclusive high-priority transmission at the highest frequency of 100Hz. Backend service units subscribed to this multicast address and port in the network will receive and parse this data.

[0052] For important data categories, a regular UDP port (port number set to 50002) can be assigned, a medium transmission frequency set to 50Hz, and a general multicast address (set to 224.0.0.2) can be used. This multicast address can be shared with data of the same priority for transmission, balancing transmission efficiency and network resource consumption.

[0053] For ordinary data, allocate a spare UDP port (port number set to 50003), set the minimum transmission frequency to 10Hz, do not configure a separate multicast address, share the basic network transmission channel, make full use of the remaining network bandwidth, and avoid occupying the transmission resources of high-priority data.

[0054] In this way, by allocating UDP communication resources differently, network resources can be tilted towards high-priority data, ensuring that critical flight control data can be transmitted first and avoiding problems such as transmission delays and packet loss.

[0055] The network status monitoring module here is used to calculate latency jitter and congestion index, and output adjustment parameters. The feedback receiving module is used to listen for and parse ACK / NACK signals, and distribute them to the monitoring module and the scheduler.

[0056] The receiving end may include a UDP receiving module, a data verification module, a data distribution module, and a feedback sending module.

[0057] Each UDP packet also includes a category identifier. The receiving end processes the UDP packet according to the priority corresponding to the category identifier determined from the UDP packet.

[0058] Specifically, the UDP receiving module listens on three ports and sorts data according to priority, maintaining a sliding window for sequence number deduplication. This module can pre-store the UDP port, multicast address, and packet identifier corresponding to the three priority levels, where the packet identifier corresponds one-to-one with the data priority (for example, critical data is identified as "01", important data as "02", and ordinary data as "03"). By identifying the packet identifier, UDP packets of different priorities can be quickly distinguished.

[0059] The data verification module allocates resources according to priority scheduling weights, performing three layers of verification in sequence: integrity, accuracy, and temporal continuity. Data verification includes packet integrity verification and data accuracy verification. Integrity verification is achieved by checking the packet length and checksum to ensure that packets are not lost or damaged. Accuracy verification is achieved by comparing the data in the packet with a preset threshold range to ensure that the data is not distorted.

[0060] The data distribution module pushes data to the control module, instrumentation module, and environment module according to data type after successful verification. Once the data verification is successful, critical flight control data is immediately synchronized to the flight simulator's control module for adjusting the simulator's control status. Important instrument display data is synchronized to the flight simulator's instrument display module for real-time updates. General environmental simulation data is synchronized to the flight simulator's environment simulation module for rendering the external flight environment.

[0061] The feedback sending module is used to generate ACK / NACK (including failure reason encoding) signals to send back to the sending end. If the verification finds that the data packet is damaged, lost, or distorted, it is determined as a verification failure. The receiving end immediately sends a NACK negative signal to notify the transmitting end to retransmit the data packet. After receiving the NACK signal, the transmitting end immediately retransmits the corresponding data packet to ensure the integrity of data transmission.

[0062] This application provides a UDP-based signal acquisition and transmission system for flight simulators. By classifying and grading data and allocating resources differently, the system rationally allocates limited network resources according to data importance, ensuring that critical flight control data obtains the optimal transmission channel and the highest transmission frequency. This fundamentally solves the problem of resource contention and improves the response accuracy and stability of the flight simulator signal transmission process.

[0063] It should be noted that the data acquisition and transmission scheme provided in this application is applicable to data transmission scenarios of various flight simulators (including full-mission flight simulators FFS, flight trainers FTD, aviation simulation training equipment, etc.).

[0064] Example 2 In one embodiment of this application, in order to further ensure the stability of flight simulator communication, an adaptive transmission adjustment scheme based on network status and receiver feedback is also provided.

[0065] In one specific embodiment, for critical data categories, the transmission latency is controlled within 50ms and the packet loss rate is less than 0.1%. For important data categories, the transmission latency is controlled within 80ms and the packet loss rate is less than 0.5%. For ordinary data categories, the transmission latency is controlled within 150ms and the packet loss rate is less than 1%.

[0066] During data transmission, the sending end can monitor the network transmission status in real time. Specifically, the monitoring method is to add a timestamp to each UDP data packet sent. After the receiving end receives the data packet, it feeds back the timestamp to the transmitting end. The transmitting end calculates the network transmission delay and jitter values ​​by comparing the timestamps and presets a network delay and jitter threshold (for example, the delay threshold can be set to 50ms and the jitter threshold can be set to 10ms) to determine whether there is a risk of network congestion.

[0067] Meanwhile, the transmitting end continuously monitors the ACK confirmation signal and NACK negation signal fed back by the receiving end, and dynamically adjusts the data packet sending frequency and data packet size.

[0068] When the transmitting end receives a NACK negative signal, or detects that the network latency jitter value exceeds a preset threshold, it determines that there is a risk of network congestion and immediately reduces the frequency of data packet transmission.

[0069] Specifically, the transmission frequency of critical data was reduced to 80Hz, important data to 40Hz, and ordinary data to 8Hz. At the same time, the data packet size was reduced by splitting the original single data packet (1024 bytes) into multiple small payload packets (256 bytes each), reducing the data load of a single transmission, reducing network transmission pressure, and avoiding further congestion.

[0070] When the network latency jitter value is detected to return to within the preset threshold and ACK confirmation signals are received three times consecutively, the network status is determined to have returned to stability. The data packet sending frequency is gradually increased by 10Hz each time until it returns to the initial sending frequency.

[0071] At the same time, the data packet size is increased, and multiple small data packets of the same priority (256 bytes / packet) are aggregated into a large data packet (1024 bytes / packet), thereby improving data transmission efficiency while ensuring stable transmission.

[0072] In one feasible implementation, a scheme for dynamically allocating UDP ports is provided.

[0073] Specifically, the sending end can maintain a pool of available UDP ports (the default range is 50000-50999, a total of 1000 ports).

[0074] Initial ports are assigned to three priority categories: critical category 50001 (dedicated port), important category 50002 (regular port), and ordinary category 50003 (spare port).

[0075] When the data characteristics change significantly due to the flight phase switching, they can be automatically recalculated through the port matching degree function. The system can dynamically adjust the port allocation scheme from the port pool without manual intervention.

[0076] The port matching function can be the optimal port mapping function with priority score, data rate, and packet size as input.

[0077] In one feasible implementation, for critical categories of data, an independent multicast address (default 224.0.0.1) can be assigned to form a dedicated transmission group, and exclusive transmission can be used to ensure absolute priority in network transmission.

[0078] For important categories of data, a general multicast address (default 224.0.0.2) can be assigned, and a shared transmission group can be used to balance transmission efficiency and network resource consumption.

[0079] Data in the ordinary category does not have a separate multicast address configured; it shares the basic network transmission channel to make full use of the remaining network bandwidth.

[0080] The initial value of the transmission frequency can be determined by the comprehensive priority score P. The highest transmission frequency is 100Hz.

[0081] The sending end can also adjust the sending frequency of UDP packets in the following ways: Calculate the product of the current transmission frequency and the correction factor, and use it as the new transmission frequency; And, the correction factor is calculated in the following way. : ; ; in, , These are the network state impact coefficient and the NACK feedback impact coefficient, respectively. This is the congestion index value. The NACK attenuation coefficient, This represents the cumulative number of NACKs within the most recent 100ms time window. , These are the delay weighting coefficient and the jitter weighting coefficient, respectively. This is a network latency smoothing value. This is the network jitter smoothing value. This is the network latency threshold. This is the network jitter threshold.

[0082] For example, based on specific experimental data, the network latency threshold can be determined to be 50ms, and the network jitter threshold can be 10ms. , They can be 0.6 and 0.4 respectively. , The values ​​are 0.5 and 0.3 respectively. It is 0.5. Let be the hyperbolic tangent function, which smoothly maps the unbounded C to the interval (0,1).

[0083] The congestion index here can indicate the network status, where, if If the value is 0, the network is good. If... A value between 0 and 0.5 indicates a slight fluctuation in the communication network. If... A value between 0.5 and 1.5 indicates moderate congestion in the communication network, requiring frequency and / or data packet adjustments. If... If the value is greater than 1.5, the transmission load needs to be significantly reduced.

[0084] Here, the sending end can calculate the current network latency smoothing value in the following way. : The current network latency smoothing value is calculated by weighted summing of the historical network latency smoothing value and the current network latency value.

[0085] The network jitter smoothing value can also be calculated using a similar exponentially weighted moving average method.

[0086] The current network latency value here is the difference between the receive timestamp and the send timestamp for the currently collected data.

[0087] The current network jitter value here is the absolute value of the difference between the current network latency value and the previous network latency value.

[0088] The sender can adjust the size of UDP packets in the following ways: When the frequency of UDP packet transmission decreases, the data size of the UDP packet decreases. When the frequency of UDP packet transmission increases, the data size of the UDP packet increases.

[0089] In a specific embodiment, the splitting granularity is continuously determined by the C value. When C=0.5, the packet is approximately 543 bytes, and when C=2.0, the packet is approximately 270 bytes. The splitting method is based on signal boundaries, ensuring that each signal record is complete and does not span multiple packets.

[0090] The split sub-packets are labeled in the packet header with: original packet ID + current sub-packet sequence number + total number of sub-packets, and the receiving end reassembles them according to this.

[0091] When C recovers to near 0 and ACKs are received continuously, σ rises back to near 1, and the packet size gradually recovers. Small packets of the same priority accumulated in the buffer queue are automatically aggregated into larger data packets. The aggregation process is continuous, and the aggregation degree gradually increases as congestion is alleviated, which can avoid secondary congestion caused by a sudden increase in transmission load.

[0092] During congestion, the frequency is reduced while the packet size is decreased; during recovery, the frequency is increased while the packet size is increased, thus coordinating the adjustment of network transmission load from both the rate and load dimensions.

[0093] In this way, both network layer congestion (represented by C) and application layer packet loss (represented by NACK_count) are considered simultaneously, and the two factors are weighted and integrated. The deterioration of either factor will trigger a frequency reduction, and the combined effect of the deterioration of both factors will comprehensively cover various network anomaly scenarios.

[0094] Furthermore, during network recovery, C decreases, NACK_count decreases, γ gradually rises back to 1, and the frequency automatically recovers. The frequency increase during recovery is also smooth and continuous, avoiding the "overshoot" phenomenon that can occur with fixed-step recovery. This ensures communication stability.

[0095] In one feasible implementation, if the sending end does not receive any ACK / NACK for more than 500ms, it is determined that the link is interrupted. All priority data transmissions are immediately suspended, and a heartbeat probe packet (64 bytes) is sent every 200ms. Upon receiving the first ACK, transmission is gradually resumed from the lowest frequency.

[0096] For example, the frequency is set at 50Hz for critical data, 20Hz for important data, and 5Hz for general data, with the frequency gradually increased according to the recovery algorithm. During the interruption, the acquisition end continues to acquire data and enqueue it. If the queue overflows, it is handled according to the established strategy. After recovery, expired data exceeding 500ms is automatically discarded.

[0097] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0098] Furthermore, the units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0099] Furthermore, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0100] It should be noted that if the function is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0101] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.

[0102] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A signal acquisition and transmission system for a flight simulator based on UDP communication, comprising a transmitter and a receiver, characterized in that, in, The transmitting end identifies the collected data obtained from the flight simulator's control system, instrument system, and environmental simulation system to determine the target category of the currently collected data; The sending end stores the currently collected data in a cache queue corresponding to the target category, and sends it to the receiving end through the UDP port corresponding to the target category; The sending end generates multiple UDP data packets based on the collected data to be sent. Each UDP data packet includes at least a sending timestamp and a category identifier. The sending end sends the multiple UDP data packets to the receiving end through the corresponding UDP port according to the target sending frequency. The receiving end records the timestamp of each UDP packet received and sends it back to the sending end; The sending end determines the network delay value and network jitter value based on the receiving timestamp fed back by the receiving end, so as to determine the communication network status, and adjusts the size and sending frequency of UDP packets based on the communication network status. The category identifier shown also serves as the priority for the receiving end to process received UDP packets.

2. The system according to claim 1, characterized in that, The sending end identifies the collected data in the following ways: When the data source of the collected data is the control system, the currently collected data is determined to be a key category; When the data source of the collected data is an instrument system, the currently collected data is determined to be of an important category; When the data source of the collected data is an environmental simulation system, the currently collected data is determined to be of the ordinary category.

3. The system according to claim 2, characterized in that, Also includes: Based on the data source of the collected data, the corresponding priority score value is determined; The target category of the collected data is updated based on the score range into which the priority score value of the collected data falls.

4. The system according to claim 3, characterized in that, The step of determining the corresponding priority score value based on the data source of the collected data specifically includes: Based on the data frame identifier of the collected data, the corresponding safety impact assessment value, real-time requirement assessment value, and accuracy requirement assessment value are matched according to the preset assessment table. The safety impact assessment value, real-time demand assessment value, and accuracy demand assessment value are weighted and summed to determine the corresponding priority score value.

5. The system according to claim 1, characterized in that, The sending end adjusts the frequency of UDP packet transmission in the following ways: Calculate the product of the current transmission frequency and the correction factor, and use it as the new transmission frequency; And, the correction factor is calculated in the following way. : ； ； in, , These are the network state impact coefficient and the NACK feedback impact coefficient, respectively. This is the congestion index value. The NACK attenuation coefficient, This represents the cumulative number of NACKs within the most recent 100ms time window. , These are the delay weighting coefficient and the jitter weighting coefficient, respectively. This is a network latency smoothing value. This is the network jitter smoothing value. This is the network latency threshold. This is the network jitter threshold.

6. The system according to claim 1, characterized in that, The sending end calculates the current network latency smoothing value in the following way. : The current network latency smoothing value is calculated by weighted summing of the historical network latency smoothing value and the current network latency value.

7. The system according to claim 1, characterized in that, The receiving end processes the execution content of the UDP packet according to the priority corresponding to the category identifier given in the UDP packet.

8. The system according to claim 5, characterized in that, The sender adjusts the size of UDP packets in the following ways: When the frequency of UDP packet transmission decreases, the data size of the UDP packet decreases; When the frequency of UDP packet transmission increases, the amount of data in the UDP packets increases.

Images