Satellite telemetry data processing method and device based on self-analysis telemetry data packet

Abstract

The application provides a satellite telemetry data processing method and device based on self-analysis telemetry data packets, wherein the method comprises: receiving a satellite telemetry data frame, containing a frame synchronization code, valid data and a check code, the valid data including self-analysis telemetry data packets; verifying the frame synchronization code and the check code to confirm the completeness of the satellite telemetry data frame; extracting the self-analysis telemetry data packets from the valid data, the self-analysis telemetry data packets being composed of multiple dynamic telemetry quantities; for the self-analysis telemetry data packets, sequentially analyzing each dynamic telemetry quantity, reading a telemetry quantity type, determining a telemetry quantity value length according to the telemetry quantity type and reading the telemetry quantity value; and according to a telemetry quantity arrangement order, associating the analyzed telemetry quantity value to a corresponding telemetry parameter name.

Description

Technical Field

[0001] This invention relates to the field of information technology, and in particular to a satellite telemetry data processing method and apparatus based on self-parsed telemetry data packets. Background Technology

[0002] Satellite telemetry data processing, a crucial component of the aerospace field, bears the heavy responsibility of real-time monitoring and analysis of satellite operational status. Its accuracy and efficiency directly impact the success or failure of space missions. Whether for scientific exploration or communication services, telemetry data serves as a bridge between the ground and satellites; any processing errors can lead to mission risks. Therefore, the ability to quickly extract useful information from complex and ever-changing data has become an undeniable challenge in this field.

[0003] Traditional telemetry data packets consist of multiple telemetry data items with a fixed structure. Each telemetry data item requires a specified placeholder length, i.e., the number of bytes or bits it occupies. Typically, a frame of satellite telemetry data consists of three data fields: frame synchronization code, valid data, and checksum. The valid data field usually contains several different types of telemetry data packets, and the frame data structure is as follows: Figure 1 As shown. When parsing traditional satellite telemetry data, the receiving end needs to know the number of bytes or bits occupied by each telemetry measurement in the valid data in order to accurately parse the content represented by each telemetry measurement. Therefore, the bit length of each telemetry measurement must be predetermined in traditional telemetry data packets to achieve accurate content parsing. The data structure of traditional telemetry data packets is as follows: Figure 2 As shown.

[0004] Therefore, traditional telemetry data parsing methods require not only knowledge of each telemetry measurement's name but also its data placeholder information (i.e., the number of bytes or bits occupied) to parse its specific value, resulting in insufficient flexibility. Furthermore, because traditional telemetry data uses pre-defined settings, modifying the telemetry measurements necessitates code modification and retesting, leading to a massive workload.

[0005] Therefore, how to realize a telemetry data structure based on dynamic settings, accurately identify the types and ranges of various parameters, and complete dynamic and efficient analysis has become a key technical issue in the field of satellite telemetry data processing. Summary of the Invention

[0006] To address the problems in the prior art, this invention provides a satellite telemetry data processing method based on self-parsed telemetry data packets, comprising: Receive satellite telemetry data frames, wherein the satellite telemetry data frames contain a frame synchronization code, valid data and a check code, wherein the valid data includes self-parsing telemetry data packets; Verify the frame synchronization code and check code to confirm the integrity of the satellite telemetry data frame; The self-parsing telemetry data packet is extracted from the valid data. The self-parsing telemetry data packet includes multiple dynamic telemetry measurements. Each dynamic telemetry measurement includes: telemetry measurement type and telemetry measurement value. The telemetry measurement type is used to describe the data type and data length of the dynamic telemetry measurement. The telemetry measurement value is used to store the telemetry measurement value that conforms to the corresponding data length. For the self-parsing telemetry data packet, the telemetry type of each dynamic telemetry measurement is parsed sequentially, the data length of the telemetry value is determined according to the telemetry type of each dynamic telemetry measurement, and the telemetry value of each dynamic telemetry measurement is parsed sequentially based on the data length of each dynamic telemetry measurement. Based on the order of each dynamic telemetry measurement, the parsed telemetry values ​​are associated with the corresponding telemetry parameter names.

[0007] Furthermore, the telemetry type occupies a predetermined number of bytes or a predetermined number of bits. Furthermore, parsing the telemetry type of each dynamic telemetry measurement includes: reading a predetermined number of bytes or multiple predetermined bits as the telemetry type; Furthermore, based on the telemetry type, the data length and parsing rules of the dynamic telemetry are obtained from the predefined type table; the bytes corresponding to the data length of the dynamic telemetry are read as the telemetry value of the dynamic telemetry, and converted into data values ​​according to the parsing rules.

[0008] Alternatively, for the self-parse telemetry data packets, each dynamic telemetry measurement is parsed sequentially until all dynamic telemetry measurements are fully parsed; the arrangement order of the dynamic telemetry measurements in the self-parse telemetry data packets is predefined by the telemetry data composition system, and the parsing system obtains the arrangement order for associating the telemetry parameter names. Furthermore, the valid data contains multiple self-parse telemetry data packets of different types; parsing is performed for each different type of self-parse telemetry data packet.

[0009] Furthermore, the predefined type table includes: unsigned integer type U08 corresponding to 1 byte of unsigned integer, U16 corresponding to 2 bytes of unsigned integer, U24 corresponding to 3 bytes of unsigned integer, U32 corresponding to 4 bytes of unsigned integer, and U64 corresponding to 8 bytes of unsigned integer.

[0010] Furthermore, the predefined type table includes: signed integer type S08 corresponding to a 1-byte signed integer, S16 corresponding to a 2-byte signed integer, S24 corresponding to a 3-byte signed integer, S32 corresponding to a 4-byte signed integer, and S64 corresponding to an 8-byte signed integer.

[0011] Furthermore, the telemetry type further includes a bit type BITx, where x is an integer from 1 to 15; the method for parsing the bit type includes: determining the length of the numerical byte to be 1 byte or 2 bytes based on the value of x; reading the data of the corresponding byte length and converting it into a temporary integer value; performing a bitwise AND operation on the temporary integer value using the bit mask corresponding to x to filter out high-order padding bits and extract the target valid bit value.

[0012] Furthermore, it also includes robustness monitoring and recovery steps: during streaming parsing, the total number of bytes read (telemetry type bytes and telemetry value length) is accumulated in real time; after parsing all telemetry data in the preset order, the total number of bytes is compared with the theoretical total number of bytes statically calculated based on the order and predefined type table, or the current read pointer position is compared with the preset tail boundary position of the underlying data frame; if the two are inconsistent, a packet parsing offset is determined and an anomaly alarm is triggered; and after triggering the anomaly alarm, a misalignment recovery operation is performed: the current self-parsing telemetry data packet is discarded, and a sliding window is used to search for the next valid telemetry type identifier or frame synchronization code in the subsequent byte stream to realign the read pointer and resume streaming parsing.

[0013] Furthermore, the self-parsing telemetry data packet dynamically determines the reading boundary of each telemetry measurement based on the mapping relationship between the telemetry measurement type and the predefined type table.

[0014] According to another aspect of the present invention, a satellite telemetry data processing apparatus based on self-parsed telemetry data packets is also provided, comprising: The receiving module is used to receive and verify the integrity of satellite telemetry data frames. When it is determined that the satellite telemetry data frame has passed the integrity verification, the self-parsing telemetry data packet is extracted from the satellite telemetry data frame. The streaming parsing module is used to read the telemetry type of each dynamic telemetry measurement in the self-parsing telemetry data packet in sequence using pointers, and to obtain the corresponding data length and parsing rules from the predefined type table; The conversion module is used to truncate the byte stream according to the data length and convert it into telemetry values, while shifting the pointer to the next position to be processed; The association module is used to match and map the converted telemetry values ​​with the telemetry parameter names according to a preset arrangement order.

[0015] According to another aspect of the present invention, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements a satellite telemetry data processing method based on self-parsing telemetry data packets as described above.

[0016] The technical solutions provided by the embodiments of the present invention may include the following beneficial effects: This invention discloses a satellite telemetry data processing method and apparatus based on self-parsed telemetry data packets. Each dynamic telemetry measurement in the self-parsed telemetry data packets of satellite telemetry data frames does not require a fixed header, fixed position, or length field. The technical solution of this invention uses a parsing system based on a self-parsed telemetry data protocol, which only needs to know the name and order of each telemetry measurement to parse out its specific value. The telemetry data composition system can flexibly organize telemetry data. By designing a predefined type table and an adaptive parsing mechanism, efficient parsing and parameter association for various data types are achieved. Furthermore, if the telemetry measurements in the telemetry data need to be modified, the self-parsed telemetry data protocol does not require program changes; only the list of telemetry measurement names and their order need to be modified.

[0017] The technical solution of this invention solves the problems of flexible and varied telemetry data formats and high parsing difficulty, significantly improving the processing efficiency and accuracy of satellite telemetry data, and providing reliable support for the real-time parsing and application of complex telemetry data. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the structure of a satellite telemetry data frame in the existing technology; Figure 2 This is a schematic diagram of the structure of a traditional telemetry data packet; Figure 3 This is a flowchart of a satellite telemetry data processing method based on self-parsed telemetry data packets according to the present invention; Figure 4 This invention relates to a satellite telemetry data frame streaming parsing system; Figure 5 This is a schematic diagram of the structure of a satellite telemetry data processing device based on self-analyzing telemetry data packets according to the present invention; Figure 6 This is a schematic diagram of the structure of the self-parsing telemetry data packet according to an embodiment of the present invention; Figure 7 This is a schematic diagram of a specific embodiment of a traditional telemetry data packet; Figure 8 for Figure 7 A schematic diagram of the byte stream format of the corresponding traditional telemetry data packet; Figure 9 This is a schematic diagram of a specific embodiment of the self-parsing telemetry data packet of the present invention; Figure 10 for Figure 9 A schematic diagram of the byte stream format of the corresponding self-parsing telemetry data packet. Detailed Implementation

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

[0020] To enable those skilled in the art to more clearly understand this technical solution, the abbreviations and symbols used herein are uniformly defined as follows: SXX (such as S08, S16, S32, etc.) represents a signed integer of XX bits; UXX represents an unsigned integer of XX bits; FLT and DBL represent single-precision and double-precision floating-point types, respectively; STRXX and BINXX represent strings and binary data of XX bytes, respectively. In this embodiment, all references to "S16" refer to a signed integer occupying 2 bytes (i.e., 16 bits), and its logic in the predefined type table is consistent with that of S16.

[0021] According to an embodiment of the present invention, raw satellite telemetry data frames are acquired from a satellite transmission channel. These frames contain a frame synchronization code, valid data, and a checksum. The valid data portion may consist of one or more self-parsed telemetry data packets. The start position of the data frame is located by identifying the frame synchronization code, and the integrity of the data frame is verified using the checksum. For a verified complete data frame, the valid data portion is extracted, decomposed into one or more self-parsed telemetry data packets, and each self-parsed telemetry data packet is processed. Each self-parsed telemetry data packet includes multiple dynamic telemetry measurements. The type identifier byte of each dynamic telemetry measurement, i.e., the telemetry measurement type, is read. The byte length or bit length of the telemetry measurement value is determined based on the type identifier, and then the specific numerical content of each dynamic telemetry measurement is parsed. The parsed telemetry measurement values ​​are matched with a pre-established list of telemetry measurement names to generate a structured telemetry data record for subsequent satellite status monitoring, ensuring that the received satellite telemetry data frames are accurately parsed into usable information. Figure 3 This is a flowchart of a satellite telemetry data processing method based on self-parsed telemetry data packets according to the present invention. Figure 3 As shown, the method may specifically include: Step 301: Receive satellite telemetry data frames. The satellite telemetry data frames include frame synchronization codes, valid data, and check codes. The valid data contains several self-parsing telemetry data packets.

[0022] The raw satellite telemetry data frames are acquired from the satellite transmission channel. Each satellite telemetry data frame contains a frame synchronization code, valid data, and a checksum. The valid data portion may consist of one or more self-parsed telemetry data packets. The start position of the data frame is located by identifying the frame synchronization code, and the integrity of the data frame is verified using the checksum.

[0023] Specifically, the satellite transmission channel continuously sends a binary data stream, and the receiving end needs to accurately determine the complete satellite telemetry data frame from this data stream. For example, the frame synchronization code is a pre-agreed fixed byte sequence, such as 0xAA55. The receiving end searches for this sequence in the data stream; once a match is found, the starting boundary of the data frame is determined. Subsequently, based on the predefined total length of the data frame or the length obtained by parsing the frame header information, a data block of the corresponding length is extracted from the starting boundary as the data frame to be verified. Next, a preset verification algorithm, such as cyclic redundancy check, is applied to the data block to calculate a check value, which is compared with the checksum appended to the end of the data frame. If the two match, it is determined that the data frame has not experienced any errors during transmission, its integrity is guaranteed, and a reliable data foundation is provided for subsequent parsing. This step ensures that the objects processed subsequently are complete and structurally correct data, avoiding parsing failures due to data misalignment or corruption.

[0024] S3011. For a data frame that has been verified to be complete, extract the valid data portion, decompose the valid data into one or more self-parse telemetry data packets, and process each self-parse telemetry data packet. Each self-parse telemetry data packet includes multiple dynamic telemetry measurements.

[0025] S3012. Read the type identifier byte of each dynamic telemetry measurement, that is, the telemetry measurement type, determine the byte length or bit length of the telemetry measurement value based on the type identifier, and then parse out the specific value content of each dynamic telemetry measurement.

[0026] In one possible implementation, the valid data is located after the frame synchronization code and before the checksum. After extracting the valid data, it needs to be split into independent self-parsing telemetry data packets. Each self-parsing telemetry data packet does not have a fixed total length; its boundaries are dynamically determined by the multiple dynamic telemetry data packets it contains. Therefore, the parsing process is a sequential reading process. The parsing program starts from the first byte of valid data. According to the definition of the self-parsing protocol, it first reads the type identifier byte of the first dynamic telemetry data packet, i.e., the telemetry type. Then, based on the rules corresponding to the type identifier, it determines the number of bytes occupied by the subsequent numerical part, thus completely reading the first dynamic telemetry data packet. After reading, the program pointer moves to the beginning position of the next dynamic telemetry data packet, and the above process is repeated until all bytes of valid data have been read.

[0027] This sequential parsing method allows a continuous, valid byte stream to be reconstructed into several well-structured dynamic telemetry units, each containing both type and numerical information. The advantage of this approach is that it eliminates the need to fix the total length or internal structural details of the data packets, enabling dynamic composition of data frames.

[0028] Figure 4 This describes the satellite telemetry data frame streaming parsing process according to an embodiment of the present invention. For example... Figure 4 As shown, the receiving module receives telemetry data frames and verifies the synchronization code and checksum. After the extraction module parses the telemetry data packets from the valid data, it enters the core streaming parsing stage: First, it reads, for example, 1 byte, the telemetry type identifier, and obtains the corresponding numerical length and parsing rules through a predefined type table mapping. Then, the conversion module extracts the byte stream and converts it into numerical values ​​and offsets the pointer according to the parsing rule library (including integer rules for unsigned / signed integers, floating-point rules, bit-by-bit extraction rules BITx, string rules, or binary rules, etc.). At the same time, the parsing robustness monitoring module determines the offset by accumulating the total number of bytes and comparing the length to ensure parsing stability. The association module maps the parsing results to the telemetry parameter names in a preset order. Finally, the loop parsing mechanism returns to the step of reading the telemetry type, realizing continuous streaming parsing of telemetry data.

[0029] For example, the type identifier byte 0x21 might correspond to a "2-byte signed integer," while 0x15 might correspond to a "1-byte unsigned integer." After reading the type identifier, the parser queries a pre-established type mapping table. The type mapping table defines the numerical data format, length, and encoding rules corresponding to each type identifier. Based on the type mapping table, the program reads the corresponding length of bytes or bits from the data stream. For byte-type data, the specified number of bytes is read directly; for bit-type data, it may be necessary to extract the bits from the bytes. After reading the raw numerical data, it is then converted into a numerical value with actual physical meaning according to the encoding rules defined in the type mapping table (such as sign-magnitude, two's complement, floating-point format, etc.).

[0030] For example, for type 0x21, the program reads the next two bytes and interprets them as a specific voltage or temperature value using the two's complement format of a signed integer. This step is the core of the self-parsing protocol; it converts a general byte stream into telemetry parameter values ​​with clear physical meaning and units, enabling subsequent applications to directly understand and use this data.

[0031] S3013. Match the parsed telemetry values ​​with a pre-established list of telemetry names to generate structured telemetry data records for subsequent satellite status monitoring, ensuring that the received satellite telemetry data frames are accurately parsed into usable information.

[0032] It should be noted that the telemetry name list defines the logical order of each telemetry measurement in the data packet and its corresponding parameter name, such as "single unit voltage," "single unit temperature," and "operating mode." Since the self-parsing protocol dynamically parses the values ​​through type identifiers, the name list does not need to contain data length information; it only needs to maintain consistency with the order of telemetry measurements in the data packet. The parsing program assigns the first parsed telemetry value to the first parameter name in the name list, the second value to the second name, and so on. Ultimately, a structured data record is generated, organized in key-value pairs or a similar format, such as {"single unit voltage": 3.45, "single unit temperature": 25, "operating mode": 3}. This structured record is very convenient for storage, retrieval, and display, and can be directly used by the satellite ground control system's database, monitoring interface, or data analysis module, thereby reflecting the real-time status of each satellite subsystem and providing immediate and accurate data support for satellite on-orbit management and fault diagnosis.

[0033] Step 302: Verify the validity of the frame synchronization code and check code to confirm the integrity of the satellite telemetry data frame.

[0034] The frame synchronization code and checksum are obtained from the satellite telemetry data frame. The frame synchronization code is compared to determine if it matches the pre-established synchronization code template. If they match, the start position of the satellite telemetry data frame is preliminarily confirmed as valid. For the preliminarily confirmed valid start position, the checksum at the end of the satellite telemetry data frame is read. The checksum is used to verify the integrity of the valid data portion, confirming that the data content has not been tampered with or lost. When the checksum verification passes, the byte sequence of the valid data portion is extracted, and its length and structure are recorded to ensure that the integrity of the satellite telemetry data frame is not affected during subsequent parsing. For the extracted valid data portion, the type and arrangement order of its internal data packets are further checked to confirm that the data frame integrity meets the preset structural requirements, providing a reliable basis for subsequent parsing.

[0035] In one possible implementation, when obtaining the frame synchronization code from the satellite telemetry data frame, a specific byte sequence in the data stream can be located first, for example, by scanning consecutive bytes to match a preset template. This ensures that the satellite telemetry data frame is not misaligned due to transmission noise, thereby improving the accuracy of subsequent processing. Specifically, if the template is a fixed pattern, such as a specific hexadecimal sequence, the comparison process involves bit-by-bit comparison. After confirming a match, the starting position is marked, which helps avoid invalid data interfering with the overall parsing.

[0036] In one possible implementation, for a valid satellite telemetry data frame with a determined starting position, when reading the checksum and verifying the valid data, a cyclic redundancy check (CRC) method is used to calculate the hash value of the data portion and compare it with the read checksum. For example, when the data portion is a byte sequence, its checksum is calculated; if they match, it confirms that there has been no tampering. This has the beneficial effect of enhancing data integrity, preventing telemetry value deviations caused by transmission errors, and further supporting reliable decision-making by the satellite system.

[0037] In one possible implementation, after successful verification, during the extraction of the byte sequence of satellite telemetry data frames and the recording of their length and structure, the sequence can be stored in a separate buffer, with the total number of bytes and internal segments labeled. This approach facilitates direct access to the complete data by subsequent modules, avoiding the overhead of repeated verification. For example, in multi-frame processing scenarios, this extraction method ensures the independence of each frame and reduces cross-validation errors.

[0038] In one possible implementation, when checking the type and order of internal data packets, the type bytes in the sequence are traversed to verify if they conform to a preset order. For example, the first byte of each packet indicates the type; if the order matches, the structure is confirmed to be complete. The advantage of this approach is that it allows for early detection of protocol violations, thereby improving parsing efficiency and maintaining the overall reliability of data frames in complex telemetry environments.

[0039] For example, in satellite telemetry applications, if the satellite telemetry data frame contains voltage and mode packets, the entire verification process, from synchronization code matching to structure checking, ensures the accurate extraction of values ​​such as single-unit voltage. In this case, multiple aspects support the stability of data parsing. For instance, in noisy environments, synchronization code comparison prevents frame offsetting, checksum verification blocks the risk of data loss, and type checking ensures the correct packet order. These aspects support each other, forming a complete data integrity assurance mechanism, thereby reducing fault diagnosis time and improving the reliability of telemetry data in actual deployments.

[0040] For example, in scenarios with unstable transmission links, comparing the synchronization code can filter out interfered initial data in the data frame. Then, the checksum verification confirms that the content is unchanged. After extracting the sequence record structure, checking the packet type order further verifies whether the data frame conforms to the protocol. Multiple verification methods support each other, ensuring the integrity of the data frame is maintained even under high-noise conditions, which is beneficial to the continuity of real-time satellite monitoring.

[0041] For example, from another perspective, in data frames where multiple data packet types coexist, confirming the starting position helps isolate valid data, extracting data after verification ensures accurate length, and sequential checks verify type consistency. These exemplified implementations support the effectiveness of verification through logical progression. For instance, initial positioning followed by in-depth verification and structural review improves overall integrity and is applicable to extensions of various satellite telemetry protocols.

[0042] Step 303: Extract the self-parsing telemetry data packet from the valid data. The self-parsing telemetry data packet includes multiple dynamic telemetry measurements. Each dynamic telemetry measurement includes: telemetry measurement type and telemetry measurement value. The telemetry measurement type describes the data type and data length of the dynamic telemetry measurement. The telemetry measurement value stores the telemetry measurement value that conforms to the corresponding data length.

[0043] Figure 6 This is a schematic diagram of the structure of the self-parsing telemetry data packet according to an embodiment of the present invention. The satellite telemetry data frame consists of a frame synchronization code, valid data, and a checksum in sequence. The valid data field can contain one or more telemetry data packets of different types, providing the basic frame structure for telemetry data parsing. The self-parsing telemetry data packet includes multiple dynamic telemetry measurements, for example, telemetry 1, telemetry 2, telemetry 3, telemetry 4, ..., telemetry n. Each dynamic telemetry measurement includes: a telemetry measurement type and a telemetry measurement value. The telemetry measurement type describes the data type and data length of the dynamic telemetry measurement. The telemetry measurement type can occupy one or more bytes or multiple bits; the technical solution of this application uses one byte as an example for illustration. The telemetry measurement value is used to store the telemetry measurement value that conforms to the corresponding data length; that is, the number of bytes or bits occupied is determined by its corresponding telemetry measurement type.

[0044] Existing data processing methods generally suffer from insufficient adaptability to different data formats. Many methods rely on fixed data structures or pre-defined rules, and their processing efficiency and accuracy drop significantly when encountering irregular formats or variable content. Especially when dealing with special data packets, existing methods often cannot handle them flexibly, leading to omissions or errors during data parsing and affecting the reliability of subsequent analysis.

[0045] According to one embodiment, the technical solution of the present invention sets up a predefined type table. Preferably, the predefined type table includes: unsigned integer type U08 corresponding to 1 byte of unsigned integer, U16 corresponding to 2 bytes of unsigned integer, U24 corresponding to 3 bytes of unsigned integer, U32 corresponding to 4 bytes of unsigned integer, and U64 corresponding to 8 bytes of unsigned integer. Preferably, the predefined type table includes: signed integer type S08 corresponding to 1 byte of signed integer, S16 corresponding to 2 bytes of signed integer, S24 corresponding to 3 bytes of signed integer, S32 corresponding to 4 bytes of signed integer, and S64 corresponding to 8 bytes of signed integer.

[0046] Furthermore, the predefined type table may include: floating-point type FLT corresponding to 4 bytes of floating-point data, and DBL corresponding to 8 bytes of floating-point data; bit type BIT1 corresponding to 1 bit occupying 1 byte, BIT2 corresponding to 2 bits occupying 1 byte, BIT3 corresponding to 3 bits occupying 1 byte, BIT4 corresponding to 4 bits occupying 1 byte, BIT5 corresponding to 5 bits occupying 1 byte, BIT6 corresponding to 6 bits occupying 1 byte, and BIT7 corresponding to 7 bits occupying 1 byte; BIT9 corresponding to 9 bits occupying 2 bytes, BIT10 corresponding to 10 bits occupying 2 bytes, BIT11 corresponding to 11 bits occupying 2 bytes, BIT12 corresponding to 12 bits occupying 2 bytes, BIT13 corresponding to 13 bits occupying 2 bytes, BIT14 corresponding to 14 bits occupying 2 bytes, and BIT15 corresponding to 15 bits occupying 2 bytes, wherein the bit type values ​​are stored with low-order bits aligned.

[0047] Furthermore, the predefined type table may include: string type STR1 corresponding to a 1-byte string, STR2 corresponding to a 2-byte string, STR3 corresponding to a 3-byte string, STR4 corresponding to a 4-byte string, STR5 corresponding to a 5-byte string, STR6 corresponding to a 6-byte string, STR7 corresponding to a 7-byte string, STR8 corresponding to a 8-byte string, STR9 corresponding to a 9-byte string, STR10 corresponding to a 10-byte string; STR20 corresponding to a 20-byte string, STR30 corresponding to a 30-byte string, STR40 corresponding to a 40-byte string, STR50 corresponding to a 50-byte string, STR60 corresponding to a 60-byte string, STR70 corresponding to a 70-byte string, STR80 corresponding to an 80-byte string, STR90 corresponding to a 90-byte string, and STR100 corresponding to a 100-byte string.

[0048] Furthermore, the predefined type table can include: Binary data type BIN1 corresponds to 1 byte of binary data, BIN2 corresponds to 2 bytes of binary data, BIN3 corresponds to 3 bytes of binary data, BIN4 corresponds to 4 bytes of binary data, BIN5 corresponds to 5 bytes of binary data, BIN6 corresponds to 6 bytes of binary data, BIN7 corresponds to 7 bytes of binary data, BIN8 corresponds to 8 bytes of binary data, BIN9 corresponds to 9 bytes of binary data, BIN10 corresponds to 10 bytes of binary data; BIN20 corresponds to 20 bytes of binary data, BIN30 corresponds to 30 bytes of binary data. The binary data is as follows: BIN40 corresponds to 40 bytes of binary data, BIN50 corresponds to 50 bytes of binary data, BIN60 corresponds to 60 bytes of binary data, BIN70 corresponds to 70 bytes of binary data, BIN80 corresponds to 80 bytes of binary data, BIN90 corresponds to 90 bytes of binary data, BIN100 corresponds to 100 bytes of binary data, BIN150 corresponds to 150 bytes of binary data, BIN200 corresponds to 200 bytes of binary data, BIN250 corresponds to 250 bytes of binary data, and BIN300 corresponds to 300 bytes of binary data.

[0049] Table 1 is a mapping table of telemetry type IDs and numerical lengths for self-analyzing satellite telemetry data in this invention. The hexadecimal encoding of the type IDs in the table represents the actual number of bytes / bits stored for each type, and is the core basis for the parsing system to dynamically determine the numerical length using the type ID.

[0050] Table 1

[0051] Step 304: For each self-parsing telemetry data packet, parse multiple telemetry values ​​sequentially until the data parsing of the self-parsing telemetry data packet is completed. Specifically, for each self-parsing telemetry data packet, parse the telemetry type of each dynamic telemetry value sequentially, determine the data length of the telemetry value based on the telemetry type of each dynamic telemetry value, and parse the telemetry value of each dynamic telemetry value sequentially based on the data length of each dynamic telemetry value.

[0052] The beneficial effects of the technical solution of the present invention will be explained below through specific examples: A traditional telemetry data packet contains five telemetry measurements, occupying a total of six bytes: Single-machine voltage (2 bytes), value: 0x5633; Single-machine current (2 bytes), value: 0x1527; Single-machine temperature (1 byte), value: 0x17; Single-machine operating status (2 bits), value: 0x01; Single-machine operating mode (6 bits), value: 0x03. The specific telemetry packet data structure is as follows... Figure 7 As shown. Figure 7 This is a schematic diagram of a specific implementation of a traditional telemetry data packet, illustrating the fixed bit length and numerical distribution of each parameter in a traditional telemetry packet containing five typical telemetry measurements, including single-machine voltage and current. After conversion to byte stream format, it occupies a total of 6 bytes, with each byte containing the following content: Figure 8 As shown. Figure 8 for Figure 7 The diagram shows the byte stream format of the corresponding traditional telemetry data packet, illustrating the actual byte storage content and distribution of the traditional telemetry packet.

[0053] Traditional telemetry data parsing systems require not only the name of each telemetry measurement but also its data placeholder information (i.e., the number of bytes or bits occupied) to parse the specific value of the telemetry measurement, which lacks flexibility. If the telemetry measurement in the telemetry data needs to be modified, the traditional telemetry data parsing system requires code modification and retesting, resulting in a huge amount of engineering work.

[0054] A self-parsed telemetry data packet stores the same data content as the traditional telemetry data packet above. It contains 5 telemetry measurements, occupying a total of 12 bytes: Single-unit voltage (3 bytes), type: 2-byte signed integer 0x21, value: 0x5633; Single-unit current (3 bytes), type: 2-byte signed integer 0x21, value: 0x1527; Single-unit temperature (2 bytes), type: 1-byte unsigned integer 0x10, value: 0x17; Single-unit operating status (2 bytes), type: 2-bit type 0x41, value: 0x01; Single-unit operating mode (2 bytes), type: 6-bit type 0x45, value: 0x03. The specific telemetry packet data structure is as follows... Figure 9 As shown. Figure 9 This is a schematic diagram illustrating a specific embodiment of the self-parse telemetry data packet of the present invention. It shows the type ID, numerical distribution, and overall bit-space characteristics of five telemetry data items with the same content as a traditional telemetry packet under the self-parse protocol. After conversion to byte stream format, it occupies a total of 12 bytes, and the content of each byte is as follows: Figure 10 As shown. Figure 10 for Figure 9The corresponding byte stream format diagram of the self-parsing telemetry data packet shows the actual byte storage content and distribution of the self-parsing telemetry packet, intuitively demonstrating the format difference from the traditional telemetry packet.

[0055] A parsing system using a self-parse telemetry data protocol only needs to know the name and order of each telemetry measurement to parse its specific value. The telemetry data composition system can flexibly organize the telemetry data. If the telemetry measurements in the data need to be modified, the self-parse telemetry data protocol does not require program changes; only the list of telemetry measurement names and their order need to be modified.

[0056] According to the technical solution of the present invention, the effective data portion is extracted from the received satellite telemetry data frame. The effective data portion contains multiple self-parsed telemetry data packets. Boundary division is performed based on the frame synchronization code and checksum, separating the effective data content located between the two. From the separated effective data content, different types of data packets are identified, and each data packet is classified according to its header identifier. The portion belonging to the self-parsed telemetry data packet is extracted to form an independent telemetry data unit. From the extracted telemetry data unit, the dynamic telemetry measurements are parsed one by one. The type byte of each dynamic telemetry measurement is read to determine its corresponding numerical value byte length, obtaining the specific value of each dynamic telemetry measurement. The parsed telemetry measurement values ​​are reassembled according to their arrangement order, and each dynamic telemetry measurement is matched with its name and type to form a complete self-parsed telemetry data packet content for subsequent processing.

[0057] According to an embodiment of the present invention, the self-parsing telemetry data packet parsing steps are as follows: 1. When extracting valid data from received satellite telemetry frames, the start position of the data frame can be determined by locating the frame synchronization code. For example, the frame synchronization code is a specific byte sequence, such as 0x21, 0x56. This ensures accurate separation of valid data, avoids parsing errors caused by data confusion, and improves the reliability of data processing. After verifying the checksum, the content between the two is separated to form an independent valid data block. This method maintains data integrity, reduces the impact of transmission noise interference, and thus provides clean basic data for subsequent extraction.

[0058] 2. When identifying different types of data packets from the separated valid data content, each data packet is classified based on its header identifier, such as the type byte 0x41. For example, the portion of the header identifying a self-parse type is extracted to form an independent telemetry data unit. This provides flexibility in classification processing, facilitates optimized parsing for specific data types, and avoids inefficiencies caused by overall data clutter.

[0059] For example, if a data packet contains both type 1 and type 2, the self-parsing part is determined and separated by the header bytes. This correlation ensures the continuity from boundary division to classification and improves the overall protocol's adaptability.

[0060] 3. When parsing telemetry data units one by one, the type byte of each telemetry data unit (e.g., 0x21) is read to determine its numerical value (e.g., 3 bytes), thus obtaining the specific value. For example, the single-unit voltage value is 0x5633. This allows for dynamic length parsing, which is beneficial for adapting to changes in the data scale of different telemetry data units and reducing redundancy caused by a fixed structure. This reading process forms a logical chain with the unit in the previous step, directly inputting the extracted unit for parsing. Its purpose is to accurately restore the meaning of each dynamic telemetry data unit, improving the readability and utilization value of the data.

[0061] 4. When reorganizing the parsed telemetry values ​​according to their order, each telemetry value is mapped to its name, such as its stand-alone operating mode and type, to form a complete self-parsing telemetry data packet. For example, the value 0x03 is mapped to the mode description. This ensures the integrity of the data organization and facilitates subsequent processing, such as direct use for satellite status monitoring.

[0062] For example, this reorganization is closely linked to the previous step of parsing the values, ensuring a continuous process from reading to the corresponding data. Its purpose is to build a scalable protocol framework that supports flexible modification of telemetry data without changing the underlying program, thereby enhancing the system's adaptability and maintenance efficiency.

[0063] In summary, the technical solution of this invention obtains an initial byte stream from a self-parsing telemetry data packet. For this byte stream, the first byte is read as a telemetry type identifier to determine the specific data type of the telemetry and the byte length occupied by subsequent values. Based on the determined telemetry type identifier, subsequent byte streams of the corresponding length are read as the telemetry value content, and this value content is stored as the parsing result of the current telemetry. After the parsing of the current telemetry value content is completed, it is determined whether there are still unread byte streams in the self-parsing telemetry data packet. If there are unread portions, the process returns to reading the first byte and continues parsing the type identifier of the next telemetry. This process is repeated until all byte streams in the self-parsing telemetry data packet have been read and parsed into the corresponding telemetry values, completing the parsing task of the entire data packet.

[0064] Preferably, the steps for enumerating dynamic telemetry data packets one by one are as follows: S3011. Obtain the initial byte stream from the self-parsing telemetry data packet. Read the first byte from the initial byte stream as the type identifier of the dynamic telemetry measurement, and determine the specific data type of the dynamic telemetry measurement and the byte length occupied by subsequent values. The telemetry measurement type identifier is a predefined code. For example, the identifier 0x21 represents a signed integer occupying 2 bytes.

[0065] In one possible implementation, the parsing system maintains a type mapping table that records the data format and length information corresponding to each type identifier. Upon reading the type identifier byte, the parsing system queries the mapping table to determine how many bytes need to be read to construct the complete telemetry value. The advantage of this approach is that the parsing logic is decoupled from the specific data type definition; the structure of subsequent data can be dynamically determined using only a single byte identifier, eliminating the need to hard-code the length of each telemetry value in the program.

[0066] S3012. Based on the determined type identifier of the dynamic telemetry measurement, read the subsequent byte stream of the corresponding length as the telemetry measurement value content, and store the value content as the parsing result of the current telemetry measurement. For example, if the type identifier indicates that the subsequent value occupies 3 bytes, the parsing system will read 3 bytes consecutively.

[0067] In one embodiment, the raw byte stream read needs to be converted according to the format specified by the type identifier. For example, for signed integer types, it may be necessary to combine multiple bytes in big-endian or little-endian order and convert them into decimal values. This conversion process is done automatically, and the converted values ​​are stored and associated with a predefined telemetry name (such as "single-unit voltage") to form a complete telemetry parameter record.

[0068] S3013. After the current telemetry data content is parsed, determine whether there are still unread byte streams in the self-parsing telemetry data packet. If there are unread parts, return to the first byte reading process and continue to parse the type identifier of the next dynamic telemetry data.

[0069] Understandably, self-parsing telemetry data packets are composed of multiple "type identifier + value" units concatenated sequentially. Therefore, after parsing one unit, the system needs to check the position of the byte stream pointer. If the pointer has not yet reached the end of the byte stream, it means there is still telemetry data to be parsed. The system will automatically use the next byte pointed to by the pointer as the new type identifier and repeat the parsing process of steps S41 and S42. This cyclical judgment mechanism ensures that no matter how many telemetry data packets are contained in the data packet, they can be parsed sequentially and completely.

[0070] S3014. Repeat the above process S41-S43 until all byte streams in the self-parsing telemetry data packet are read and parsed into the corresponding telemetry values, thus completing the parsing task of the entire data packet.

[0071] For example, the parsing process for a data packet containing 5 telemetry values ​​is the same as the above "read type - read value - check loop" process executed 5 times. When the byte stream pointer reaches the end, the loop terminates, and at this point, the values ​​of all telemetry values ​​have been successfully extracted and stored. This design makes the parser universal; it uses the same parsing logic to process self-parsing telemetry data packets of different content and lengths, without requiring modifications to the program code for the structure of each data packet, greatly improving the system's flexibility and maintainability.

[0072] Step 305: According to the order of each dynamic telemetry measurement, associate the parsed telemetry measurement values ​​with the corresponding telemetry parameter names.

[0073] Preferably, starting from the beginning of the self-parsing telemetry data packet, one byte is read sequentially for each dynamic telemetry measurement as a telemetry type identifier. Based on the telemetry type identifier, a pre-established type mapping table is consulted to determine the byte length occupied by the telemetry value corresponding to the type identifier and the value conversion rule. According to the byte length, a corresponding number of bytes are continuously read from the self-parsing telemetry data packet to form the original byte sequence of the telemetry value. The original byte sequence is parsed according to the value conversion rule to convert the byte data into the final telemetry value of the corresponding data type.

[0074] In a specific example, the steps from type identification to numerical conversion in telemetry are as follows: S3051. Read one byte from the beginning of the self-parsing telemetry data packet as a telemetry type identifier. This ensures that the type of each telemetry measurement is accurately identified, thus providing a basis for subsequent parsing.

[0075] For example, when a data packet begins with a hexadecimal sequence, the first byte, such as 0x45, is extracted. This represents a specific type, such as a standalone operating mode, avoiding the limitations of traditional fixed structures that require prior knowledge of the location and length of each telemetry measurement, thus improving the flexibility of data processing. This reading method allows the parsing system to dynamically adapt to different telemetry measurements without relying on static configuration.

[0076] S3052. Query the pre-established type mapping table based on the read telemetry type identifier. The type mapping table contains the correspondence between the identifier, byte length, and conversion rules.

[0077] For example, for the identifier 0x45, the type mapping table defines its value as occupying 1 byte and uses integer conversion, which is beneficial for quickly locating and parsing parameters.

[0078] Furthermore, the query process achieves efficient matching through hash lookup, which not only reduces the probability of errors but also enhances the system's scalability. When a new type is added, only the type mapping table needs to be updated.

[0079] S3053. Based on the byte length obtained from the query, read the corresponding bytes continuously from the data packet to form the original byte sequence.

[0080] For example, if the length is 2 bytes, the last two bytes, such as 0x56 and 0x33, are extracted to form a sequence, which is beneficial for accurately capturing numerical data without missing or overreading.

[0081] This reading method ensures data integrity, especially in satellite telemetry scenarios, preventing data loss due to transmission noise interference. Furthermore, combined with transformation rules, it can convert sequences into meaningful values, improving the overall accuracy and reliability of the parsing.

[0082] S3054. Parse the original byte sequence according to the numerical conversion rules and convert it into the final value of the corresponding data type.

[0083] For example, applying big-endian conversion to the sequence 0x5633 yields a voltage value, which helps convert the raw data into a readable form, supporting downstream applications such as monitoring systems.

[0084] Specifically, the transformation rules may include shift and masking operations to ensure that the values ​​conform to the expected type. This not only improves data utilization efficiency but also facilitates integration into a larger framework, ultimately achieving complete self-resolution for each dynamic telemetry measurement.

[0085] In specific implementation, the "parsing rules" in the predefined type table specifically include computer operation instruction sequences: for multi-byte integer data (such as U16, S32), the parsing rules include big-endian or little-endian byte order rearrangement instructions based on the operating platform architecture; for signed integer data (S08 to S64), the parsing rules include mathematical operation instructions that invert and add one to convert the read two's complement byte stream into its original code value; and for floating-point data (FLT, DBL), the parsing rules include floating-point conversion algorithms that strictly follow the IEEE 754 standard.

[0086] According to one implementation method, taking the signed integer telemetry subcategory S16 of the general category of telemetry as an example, the correspondence between telemetry type identifiers and data lengths is extracted. The telemetry type identifiers include identifiers representing signed integers, where identifier 0x21 corresponds to two bytes of signed integer data. Based on the extracted correspondence, a mapping from type identifiers to specific data types is established in the predefined type table, mapping identifier 0x21 to a two-byte signed integer, and defining it as type S16 according to naming rules. Based on data storage examples of single-machine current and single-machine operating mode, the data parsing process of type S16 is verified, confirming that the two-byte original data can be parsed according to the signed integer format and obtain the correct value. The predefined type table is expanded, and referring to the definition method of type S16, the type identifiers and data length definitions of other signed integers, unsigned integers, and floating-point types are systematically supplemented to form a complete set of telemetry types.

[0087] Specifically, the steps for generating a complete set of telemetry types are as follows: 1. When extracting the correspondence between telemetry type identifiers and data lengths, all mentioned type identifiers can be identified first. For example, the identifier 0x21 is described as corresponding to signed integer data. This extraction process involves scanning the text content line by line to capture keywords and numerical pairs, thereby ensuring the accuracy of subsequent mappings and avoiding parsing errors.

[0088] 2. When establishing the mapping from type identifiers to data types based on the extracted correspondence, the identifier 0x21 is specifically mapped to a two-byte signed integer and defined as type S16. This step can be achieved by creating a key-value pair structure. For example, the association between identifiers and byte lengths is recorded in a table, making data parsing more efficient and helping the system quickly locate type information when processing various telemetry data.

[0089] 3. When verifying the data parsing process of type S16 using data storage examples of single-machine current and single-machine operating mode, the parsing of two bytes of raw data can be simulated. For example, the high byte and low byte can be combined and signed integer conversion rules can be applied to confirm the correctness of the value. This verification helps to enhance the reliability of the type and is beneficial to reducing data interpretation errors in actual telemetry packets.

[0090] 4. When expanding the predefined type table, and systematically supplementing other types by referring to the definition method of type S16, unsigned integers such as U08 occupying 1 byte and floating-point types such as FLT occupying 4 bytes can be added one by one to form a complete set of telemetry types. Such expansion can support more data formats, which is beneficial for adapting to diverse telemetry needs and improving the compatibility of the parsing system.

[0091] According to one implementation, storage rules for telemetry types are obtained from a predefined type table. For bit-type data, such as 1-byte and 2-byte types, their storage space sizes are determined, and data is arranged according to low-order alignment to ensure accurate storage at byte boundaries. After data arrangement, a corresponding byte stream format is constructed for each type of bit-type data. The arranged data is written into the byte stream according to the low-order alignment rule, forming a complete telemetry data packet structure. The content of the telemetry data packet is extracted from the byte stream. For bit-type data of different byte lengths, its numerical content is parsed, ensuring that the parsing process is consistent with the low-order alignment storage rules, generating a set of telemetry values ​​for subsequent processing. The parsed set of telemetry values ​​is compared with the predefined type table to verify whether the storage and parsing of each type of bit-type data conforms to the byte occupation rules and low-order alignment requirements, ultimately achieving an accurate representation of the telemetry type.

[0092] Specifically, the steps for obtaining and verifying bit-type telemetry storage rules are as follows: 1. Retrieve the storage rules for telemetry types from the predefined type table.

[0093] For example, for bit-type data that occupies 1 byte, such as BIT1 to BIT7, the storage space size is fixed at 1 byte, which helps to save space and improve transmission efficiency in data-intensive environments.

[0094] In one embodiment, when dynamic telemetry occupies K bits, if K is 3, its least significant bit is aligned to the lower 3 bits of the byte, and the most significant bit is filled with zeros, ensuring that the data is accurately stored at the byte boundaries. Because least significant bit alignment avoids the complexity of bit shifting operations, this approach offers the advantages of data consistency and ease of parsing. From multiple perspectives, this arrangement supports the real-time data processing requirements of satellite telemetry systems and complements 2-byte types, such as BIT9 to BIT15, which are extended to 16 bits to accommodate a larger numerical range, thus supporting the diverse storage requirements of dynamic telemetry measurements with varying precision.

[0095] 2. Construct a byte stream format after the data is arranged.

[0096] For example, for each type of bit data, it is written into a byte stream according to the low-order alignment rule to form a complete telemetry data packet structure, which can bring the beneficial effects of compact data packet structure and simplified error detection.

[0097] In one embodiment, assuming dynamic telemetry data occupies J bits, where J is 10, it is first arranged into the lower 10 bits of a 2-byte array, with the higher bits padded with zeros before being written into the byte stream. This progressive logic from arrangement to writing ensures the integrity of the data packet. From multiple perspectives, this approach supports compatibility between traditional telemetry data packets and self-parsing telemetry data packets. For example, when the single-machine operating mode value 0x03 occupies 6 bits, writing 1 byte with the lower bits aligned can combine with a single-machine voltage such as 0x5633, which occupies 3 bytes, to form a unified telemetry data packet structure, supporting the self-organization efficiency of multiple data types.

[0098] 3. Extract the telemetry data packet content from the byte stream and parse the values.

[0099] For example, for bit-type data of different byte lengths, ensuring that the parsing is consistent with the low-order bit alignment and generating a set of telemetry values ​​brings the beneficial effects of improved parsing accuracy and subsequent processing reliability.

[0100] In one embodiment, for a 1-byte BIT5 type, the value is read from the lower 5 bits of the byte during parsing, ignoring high-order padding. This supports data parsing from multiple directions during the data extraction and generation process. For example, when processing a standalone mode with type ID 0x45, parsing the 0x03 value and combining it with other telemetry data such as voltage of type 0x21 forms a complete representation of the value set, mutually supporting the continuity of data from storage to application.

[0101] 4. Compare and verify the obtained telemetry data set with the predefined type table.

[0102] For example, checking whether the storage and parsing of each type of bit data conforms to byte occupancy rules and low-bit alignment requirements is used to complete the accurate representation of telemetry types, thus achieving the beneficial effects of verifying reliability and improving the robustness of the parsing system.

[0103] According to one implementation, the telemetry type in the predefined type table also includes string types, such as STR1 (1 byte) to STR10 (10 bytes), STR20 (20 bytes) to STR100 (100 bytes), and binary data types BIN1 (1 byte) to BIN10 (10 bytes), BIN20 (20 bytes) to BIN300 (300 bytes).

[0104] The data length definitions for telemetry types are retrieved from a predefined type table. For string data, the range is determined from 1 byte to 100 bytes. Similarly, for binary data, the range is determined from 1 byte to 300 bytes, forming an initial data length mapping table. Based on this initial mapping table, a corresponding data storage structure is constructed, associating the data length of string or binary data with specific storage byte locations to form a byte allocation scheme for data parsing. Based on this byte allocation scheme, the input satellite telemetry data packets are parsed, and the corresponding byte content is extracted from the data packets according to the length definitions for string or binary data, generating structured telemetry data records. For these structured telemetry data records, the byte length of each dynamic telemetry measurement is verified to meet the length requirements for string and binary data in the predefined type table, ensuring consistency between the data parsing results and the predefined type table, thus completing the accurate identification and storage of telemetry types.

[0105] In one possible implementation, the data length definition for telemetry types is obtained from a predefined type table to ensure standardized processing of different data types. For example, for string data, determining a range from 1 byte to 100 bytes helps to accurately allocate storage space in satellite telemetry data packets, avoiding data overflow or waste, thereby improving the efficiency and reliability of data transmission.

[0106] Specifically, the parsing process involves scanning entries in the type table, associating the byte length of each string with its corresponding data range to form a mapping table. This helps to quickly locate data boundaries during subsequent parsing. In satellite telemetry systems, this method prevents parsing errors caused by length mismatches, resulting in more stable data consistency.

[0107] In one possible implementation, a corresponding data storage structure is constructed based on the initial data length mapping table. The length of string or binary data is associated with specific storage byte positions, forming a byte allocation scheme for data parsing. This optimizes the organization of satellite telemetry data. For example, when processing binary data, a dynamic buffer can be created by associating positions between binary data ranging from 1 byte to 300 bytes, ensuring the ordered arrangement of content within the data packet and thus improving parsing speed and accuracy.

[0108] Specifically, the construction process involves assigning a starting offset to each type. In practical applications, this reduces memory fragmentation because it allows for flexible adjustment of storage based on length, avoiding the inefficiency of fixed-size structures.

[0109] In one possible implementation, the input satellite telemetry data packets are parsed based on a byte allocation scheme. The corresponding byte content is extracted from the data packets according to the length definitions of string and binary data types, generating structured telemetry data records. This facilitates the transformation of the raw byte stream into a readable format. For example, when extracting a 20-byte string, the specified byte is directly located and read according to the scheme, supporting parallel processing of multiple telemetry measurements and thus improving the overall system's responsiveness.

[0110] Specifically, the parsing process involves matching the type length byte by byte. Because abnormal lengths are detected in real time, the extracted content is ensured to conform to predefined specifications, which can enhance data integrity.

[0111] In one possible implementation, the byte length of each telemetry measurement is verified against the length requirements for string and binary data in a predefined type table for structured telemetry data records. This ensures that the data parsing results are consistent with the predefined type table, accurately identifying and storing the telemetry measurement type, which is beneficial for ultimately verifying the reliability of the telemetry system. For example, when verifying a 100-byte string data, the actual length is compared with the definition in the table. If they match, the type is confirmed to be accurate. This supports the robustness of data processing in multiple ways, such as preventing tampering or transmission errors.

[0112] Specifically, the verification process is achieved through length comparison and type ID checking, which improves the security of the parsing system. Because inconsistent data is filtered out during the identification phase, the accurate storage and application of telemetry types are ensured.

[0113] Self-parsing telemetry data packets do not contain a header or length field. They parse all dynamic telemetry data one by one by continuously reading the telemetry data type and its corresponding value. The order of the dynamic telemetry data is predefined by the telemetry data composition system and sent to the parsing system.

[0114] According to one implementation, valid data is obtained from satellite telemetry data frames. The valid data field may contain one or more self-parsed telemetry data packets. For each self-parsed telemetry data packet, a pre-established list of dynamic telemetry names and their order are used to guide the parsing process, ensuring that the content of each dynamic telemetry measurement is read in a predefined order. The telemetry type field is read one by one according to the predefined telemetry arrangement order. The type field occupies a fixed number of bytes or bits, used to determine the byte length or bit length of subsequent telemetry values, and the corresponding numerical data is parsed based on the content of the type field. When parsing each telemetry value, the corresponding numerical content is extracted from the data stream based on the byte length or bit length determined by the type field. The numerical content corresponds one-to-one with the pre-established list of telemetry names, forming complete telemetry information. For each parsed telemetry information, subsequent telemetry measurements are continuously processed in the order of arrangement until all telemetry measurements within the data packet have been parsed. This process does not rely on the packet header or length field; it achieves complete decoding of the self-parsed telemetry data packets by continuously reading the type and numerical values.

[0115] Specifically, the steps from data frame extraction to complete decoding of self-parsing telemetry data packets are as follows: 1. The process of obtaining valid data fields from satellite telemetry data frames involves identifying the frame synchronization code to locate the data start point.

[0116] For example, when a satellite telemetry data frame begins with a specific synchronization code, the parsing system skips the synchronization code and directly extracts the subsequent valid data fields. This extraction ensures that portions containing multiple self-parsing telemetry data packets are fully captured, which is beneficial to the accuracy of subsequent parsing. Because a pre-established list of telemetry data names and their order instructs the parsing system to process each data packet sequentially, data confusion is avoided and parsing efficiency is improved.

[0117] 2. Read the telemetry type field one by one according to the predefined arrangement order of dynamic telemetry measurements. The type field occupies a fixed 1 byte.

[0118] For example, if the type field value is 0x21, indicating a 2-byte signed integer, the parsing system determines the length of the numeric field to be 2 bytes. This reading method is beneficial for dynamically adapting to different lengths in dynamic telemetry, achieving flexible data organization by directly parsing the numeric data through the type field, and avoiding the inflexibility caused by fixed space allocation in traditional data packet formats.

[0119] 3. When parsing each telemetry value, extract the value from the data stream based on the byte length or bit length determined by the type field.

[0120] For example, for a telemetry measurement representing a single unit voltage, if the type is 0x21 and the value is 0x5633, the extracted data will be matched with a pre-established list of names to form complete information such as "Single Unit Voltage: 0x5633". This extraction and matching facilitates the construction of a readable set of telemetry information, ensuring that the parsing system can understand the meaning of the data without additional metadata, thereby improving the system's adaptability and ease of maintenance.

[0121] 4. For each dynamic telemetry data obtained from parsing, continue processing subsequent telemetry data in the order they are arranged until the data packet parsing is complete.

[0122] For example, in a data packet containing five dynamic telemetry measurements, the parsing system reads the type and value pairs sequentially, such as processing voltage first, then operating mode, until the last one. This method, which eliminates the need to set packet headers or length fields and reads data sequentially, simplifies protocol design and reduces overhead. This is because parsing, driven by a predefined order and type, can fully decode the data packet and supports flexible adjustments to the parsing system based on telemetry data composition without modifying the parsing logic.

[0123] Furthermore, since self-parsing telemetry data packets have no header or length field, the parsing system determines the end of the current data packet and the beginning of the next data packet based on the following conditions: after the parsing system completes the continuous reading and parsing of a predetermined number of dynamic telemetry measurements within the current data packet, the position of the current read pointer is automatically identified as the end boundary of the current data packet. The adjacent next byte is then identified as the first telemetry measurement type identifier of the next data packet. To ensure the adaptability of the satellite telemetry data processing method in the space communication environment, the parsing system dynamically loads and updates the list and order of telemetry parameter names during the initialization phase or upon receiving a specific telemetry frame containing configuration update instructions. This mechanism ensures that when the working modes of the ground system and the satellite end switch or when telemetry measurements are added or removed, the parsing system can maintain strong consistency between the parsing logic and the data structure in real time.

[0124] The parsing system associates each parsed telemetry value with its corresponding telemetry parameter name based on the list and order of telemetry names, thus achieving adaptive parsing of complete telemetry data.

[0125] According to one implementation, valid data portions are extracted from received telemetry data frames. After verifying the frame synchronization code and checksum, data content containing multiple dynamic telemetry measurements is obtained and stored as a data stream to be parsed. For the data stream to be parsed, the type bytes of each telemetry measurement are read one by one according to a pre-established list and order of telemetry measurement names to determine its data type and the number of bytes occupied by the corresponding value, generating an original value set for each telemetry measurement. The original value set is matched with the list of telemetry measurement names, and for each telemetry measurement name and its order, the parsed value is associated with the corresponding name, forming a structured telemetry parameter mapping table. Based on the structured telemetry parameter mapping table, for each telemetry parameter name, its corresponding value content is output, realizing adaptive parsing of telemetry data.

[0126] Specifically, the steps for generating a self-analyzing telemetry data stream are as follows: 1. Extract the valid data portion from the received telemetry data frame. After verifying the frame synchronization code and checksum, obtain the data content containing multiple telemetry measurements and store it as a data stream to be parsed. In one possible implementation, the parsing system first identifies a specific byte sequence at the start of the data frame, i.e., the frame synchronization code. For example, a preset hexadecimal value combination is used to confirm the boundaries of the data frame. Subsequently, the parsing system calculates and compares the checksum portion of the data frame according to a preset verification algorithm, such as cyclic redundancy check, to verify whether errors have occurred during data transmission. Only when the frame synchronization is correct and the verification passes, the parsing system considers the portion between the frame synchronization code and the checksum as valid data and treats it as a continuous byte sequence, i.e., the data stream to be parsed, for subsequent processing steps. This ensures that the data on which subsequent parsing is based is complete and correct, avoiding parsing errors caused by frame positioning errors or data corruption.

[0127] 2. For the data stream to be parsed, according to the pre-established list of telemetry names and their order, read the type byte of each telemetry one by one, determine its data type and the number of bytes occupied by the corresponding value, and generate the original value set of each telemetry.

[0128] For example, the parsing system begins reading from the beginning of the data stream to be parsed. It first reads one byte, which is the type identifier for the first dynamic telemetry measurement. Internally, the parsing system maintains a type mapping table that defines the data format and length corresponding to each type identifier.

[0129] For example, the type identifier 0x21 might correspond to "2-byte signed integer," meaning that the two bytes immediately following the type byte together constitute the telemetry value. Based on this mapping, the parsing system extracts the corresponding length of bytes from the data stream and converts it into a raw integer value. After parsing the first dynamic telemetry, the pointer moves to the type byte position of the next dynamic telemetry, repeating the process until all telemetry values ​​in the data stream have been processed. Ultimately, the system obtains a sequentially arranged list of raw values, i.e., the raw value set. The core of this process lies in the self-descriptive nature of the type byte, which allows the system to dynamically determine how many bytes to read based on the type information, adapting to telemetry packets with different data structures, without needing to know the fixed length of each telemetry value in advance.

[0130] 3. Match the original set of values ​​with the list of telemetry names. For each dynamic telemetry name and its order, associate the parsed values ​​with the corresponding names to form a structured telemetry parameter mapping table.

[0131] It should be noted that the pre-established list of telemetry names defines the parameter names that users are concerned with and their order of appearance in the data packets.

[0132] For example, the list might be ["Single-unit voltage", "On-board temperature", "Single-unit operating mode"]. The previously generated set of raw numerical values ​​is also arranged in the same order. Therefore, the parsing system can pair the first name in the list with the first value in the raw numerical set, the second name with the second value, and so on. This association operation transforms a series of raw, meaningless numbers into key-value pairs with clear semantics.

[0133] For example, the value 0x5633 is associated with the name "single-unit voltage". The resulting telemetry parameter mapping table is a structured data object that clearly records the name of each telemetry parameter and its corresponding specific value, providing directly usable information for the final data presentation and application.

[0134] Preferably, the specific internal operation of associating the parsed telemetry values ​​with the corresponding telemetry parameter names is as follows: an ordered dictionary or key-value pair structure is instantiated in the system memory, and the telemetry values ​​obtained by streaming parsing are written one by one into the Value (value) field of the telemetry parameter structure array loaded from a pre-configured JSON or XML file in the order of pointer traversal, thereby constructing a structured telemetry parameter object in memory that can be directly called by the upper-level monitoring software.

[0135] 4. Based on the structured telemetry parameter mapping table, output the corresponding numerical content for each telemetry parameter name to realize the adaptive parsing process of satellite telemetry data.

[0136] Understandably, the telemetry parameter mapping table has already completed the conversion of data from binary streams to semantic parameters. At this point, the system can output the parsed results in various formats according to application requirements.

[0137] For example, the mapping table can be converted into an easy-to-read text report, directly displaying "Single-machine voltage: 0x5633"; the data can also be packaged into a standard data exchange format for use by other systems; or the values ​​can be stored in a database. Because the entire parsing process relies on the data's inherent type information and a pre-configured list of names, rather than a hard-coded fixed format, when the content of the telemetry data packet changes—for example, by adding new telemetry measurements or changing existing types—only the name list and type mapping table need to be updated, without modifying the core logic of the parsing program. This achieves the parsing system's adaptability to changes in telemetry data content, i.e., adaptive parsing.

[0138] When parsing bit-type telemetry data (such as BIT1 to BIT15), the system employs bitmask extraction logic. Taking BIT10, which occupies 2 bytes of storage space, as an example, the parsing system first reads the complete 2 bytes of data and combines them into a 16-bit integer. Since this type uses low-order alignment storage, the system performs a bitwise AND operation between this 16-bit integer and the hexadecimal mask 0x03FF to filter out the 6 zero-value bits padded in the high-order bits, accurately extracting the telemetry value of the lower 10 bits. For bit-type data occupying 1 byte (such as BIT5), a bitwise AND operation is performed between the read byte and the mask 0x1F to achieve accurate reconstruction of the value of a specific bit segment.

[0139] Figure 5 This is a schematic diagram of a satellite telemetry data processing device based on self-parsed telemetry data packets according to the present invention. The device includes a receiving module, a streaming parsing and conversion core, and an association module.

[0140] The receiving module is used to receive and verify the integrity of satellite telemetry data frames. When it is determined that the satellite telemetry data frame has passed the integrity verification, the self-parsing telemetry data packet is extracted from the satellite telemetry data frame.

[0141] The core of the streaming parsing and conversion system includes a streaming parsing module and a conversion module. The streaming parsing module uses pointers to sequentially read the telemetry type of each dynamic telemetry measurement in the self-parsing telemetry data packet and obtains the corresponding data length and parsing rules from a predefined type table. It sequentially reads the type identifiers in the self-parsing telemetry data packets, obtains the corresponding numerical length and parsing rules, and passes them to the conversion module.

[0142] The conversion module is used to extract the byte stream and convert it into telemetry values ​​based on the above information. At the same time, it performs pointer offset and passes the converted telemetry values ​​to the associated module. That is, it extracts the byte stream according to the data length and converts it into telemetry values, while offsetting the pointer to the next position to be processed. The association module is used to match and map the converted telemetry values ​​with the telemetry parameter names according to a preset arrangement order to form complete telemetry data information. The whole process realizes self-parsed satellite telemetry data streaming without relying on packet headers or length fields.

[0143] It should be noted that the above examples are merely some specific embodiments of the present invention. Obviously, the present invention is not limited to the above embodiments and many variations are possible. All variations that can be directly derived or conceived by those skilled in the art from the content disclosed in this invention should be considered within the scope of protection of this invention.

Claims

1. A satellite telemetry data processing method based on self-parsed telemetry data packets, characterized in that, include: Receive satellite telemetry data frames, wherein the satellite telemetry data frames contain a frame synchronization code, valid data and a check code, wherein the valid data includes self-parsing telemetry data packets; Verify the frame synchronization code and check code to confirm the integrity of the satellite telemetry data frame; The self-parsing telemetry data packet is extracted from the valid data. The self-parsing telemetry data packet includes multiple dynamic telemetry measurements. Each dynamic telemetry measurement includes: telemetry measurement type and telemetry measurement value. The telemetry measurement type is used to describe the data type and data length of the dynamic telemetry measurement. The telemetry measurement value is used to store the telemetry measurement value that conforms to the corresponding data length. For the self-parsing telemetry data packet, the telemetry type of each dynamic telemetry measurement is parsed sequentially, the data length of the telemetry value is determined according to the telemetry type of each dynamic telemetry measurement, and the telemetry value of each dynamic telemetry measurement is parsed sequentially based on the data length of each dynamic telemetry measurement. Based on the order of each dynamic telemetry measurement, the parsed telemetry values ​​are associated with the corresponding telemetry parameter names.

2. The method according to claim 1, characterized in that, The telemetry type occupies a predetermined number of bytes or a predetermined number of bits; Parsing the telemetry type of each dynamic telemetry measurement includes: reading a predetermined byte or multiple predetermined bits as the telemetry type.

3. The method according to claim 2, characterized in that, It also includes obtaining the data length and parsing rules of the dynamic telemetry from a predefined type table according to the telemetry type; The bytes corresponding to the data length of the dynamic telemetry measurement are read as the telemetry value of the dynamic telemetry measurement, and converted into a data value according to the parsing rules.

4. The method according to claim 1, characterized in that, For the self-parsing telemetry data packet, each dynamic telemetry measurement is parsed sequentially until all dynamic telemetry measurements are fully parsed; the arrangement order of the dynamic telemetry measurements in the self-parsing telemetry data packet is predefined by the telemetry data composition system, and the parsing system obtains the arrangement order to associate the telemetry parameter names.

5. The method according to claim 1, characterized in that, The valid data contains multiple different types of self-parse telemetry data packets; parsing is performed for each different type of self-parse telemetry data packet.

6. The method according to claim 1, characterized in that, It also includes analyzing robustness monitoring and recovery steps: During the streaming parsing process, the total number of bytes of telemetry type and telemetry value length read is accumulated in real time; After parsing all telemetry data in the preset order, compare the total number of bytes with the theoretical total number of bytes statically calculated based on the order and the predefined type table, or compare the current read pointer position with the preset tail boundary position of the underlying data frame. If the two are inconsistent, the packet parsing offset is determined and an exception alarm is triggered.

7. The method according to claim 1, characterized in that, It also includes analyzing robustness monitoring and recovery steps: During the streaming parsing process, the total number of bytes of telemetry type and telemetry value length read is accumulated in real time; After parsing all telemetry data in the preset order, compare the total number of bytes with the theoretical total number of bytes statically calculated based on the order and the predefined type table, or compare the current read pointer position with the preset tail boundary position of the underlying data frame. If the two are inconsistent, the packet parsing offset is determined and an abnormal alarm is triggered; and after the abnormal alarm is triggered, the misalignment recovery operation is performed: the current self-parsing telemetry packet is discarded, and the next valid telemetry type identifier or frame synchronization code is searched in the subsequent byte stream in a sliding window to realign the read pointer and resume streaming parsing.

8. The method according to claim 1, characterized in that, The self-parsing telemetry data packet dynamically determines the reading boundary of each telemetry measurement based on the mapping relationship between the telemetry measurement type and the predefined type table.

9. A satellite telemetry data processing device based on self-parsed telemetry data packets, characterized in that, include: The receiving module is used to receive and verify the integrity of satellite telemetry data frames. When it is determined that the satellite telemetry data frame has passed the integrity verification, the self-parsing telemetry data packet is extracted from the satellite telemetry data frame. The streaming parsing module is used to read the telemetry type of each dynamic telemetry measurement in the self-parsing telemetry data packet in sequence using pointers, and to obtain the corresponding data length and parsing rules from the predefined type table; The conversion module is used to truncate the byte stream according to the data length and convert it into telemetry values, while shifting the pointer to the next position to be processed; The association module is used to match and map the converted telemetry values ​​with the telemetry parameter names according to a preset arrangement order.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements a satellite telemetry data processing method based on self-analyzing telemetry data packets as described in any one of claims 1 to 8.

Images