A multi-type data co-line transmission method and system

Abstract

The application discloses a kind of multi-type data co-line transmission method and system, the multi-type data co-line transmission method includes: sending end is buffered and frame encapsulation to multiple different types of service data, respectively generates independent data frame;The independent data frame successively includes synchronization identification section, type identification section, service data section, check section;Multiple groups of independent data frame are sequentially and continuously transmitted on same communication link, frame interval meets communication link electrical and timing specification;Receiving end continuously monitors link signal, completes frame synchronization by synchronization identification section, reads type identification section and distinguishes data type, carries out check verification to service data section by check section, after verification, different types of data are separated and directed to corresponding equipment.Output to the application's advantages include:1, overall compatibility existing communication link, adaptation existing hardware, circuit, device, driver and underlying transceiver protocol;2, realize multi-type data stable co-line transmission on single communication link, ensure that various data do not interfere with each other, not dislocation, not aliasing;3, realize receiving end automatic frame synchronization, data type identification, transmission check, data separation and directional output, without manual configuration debugging;4, adaptation multiple communication link types and communication mode, improve scheme universality and applicable scope etc.

Description

Technical Field

[0001] This invention belongs to the field of data communication technology, specifically relating to a method and system for multi-type data co-line transmission. Background Technology

[0002] In existing communication systems, a single physical link can typically only transmit one type of data or control signal. When multiple service data, such as audio, video, control, and sensing data, need to be transmitted simultaneously, existing technologies have significant limitations: First, it increases the physical wiring, which leads to high cabling costs, complex construction, and large system size, making it unfavorable for equipment mobility and integrated design.

[0003] Second, replacing communication hardware or upgrading communication protocols cannot be compatible with existing equipment, resulting in high system upgrade costs and long cycles.

[0004] Third, traditional time-division multiplexing, frequency-division multiplexing, and code-division multiplexing technologies require modification of the underlying timing, electrical, or driving logic, making it difficult to directly reuse existing communication links.

[0005] Fourth, existing data transmission solutions for various types often rely on dedicated chips or custom circuits, resulting in poor versatility and cumbersome on-site deployment.

[0006] Fifth, there is a lack of universal co-line transmission solutions that are purely software-based, low-cost, highly compatible, and highly stable, which cannot meet the needs of rapid iteration and upgrading of old communication systems. Summary of the Invention

[0007] The purpose of this invention is to overcome the above-mentioned shortcomings of the prior art and provide a method and system for multi-type data co-line transmission that is fully compatible with existing communication links.

[0008] The technical solution adopted to achieve the purpose of this invention is as follows: The multi-type data collinear transmission method provided by this invention includes: The sending end buffers and encapsulates multiple service data of different types, generating independent data frames respectively; each independent data frame sequentially includes a synchronization identifier segment, a type identifier segment, a service data segment, and a check segment; Multiple sets of independent data frames are transmitted sequentially and continuously on the same communication link, with the frame interval conforming to the electrical and timing specifications of the communication link. The receiving end continuously monitors the signal of the communication link, completes frame synchronization through the synchronization identifier segment, reads the type identifier segment to distinguish data types, and verifies the service data segment through the check segment. If the verification is successful, the different types of data are separated and output to the corresponding devices. If the verification fails, the exception handling mechanism is triggered to directly discard the exception frame.

[0009] The communication link is an existing communication link, and the transmission process is compatible with the hardware structure, electrical specifications, timing rules, driving method and underlying transceiver protocol of the communication link, and is adapted to the native idle timing and signal characteristics of the communication link.

[0010] The synchronization identifier segment is used by the receiving end to quickly capture the frame header, accurately complete frame synchronization, and avoid data parsing misalignment. It has unique and identifiable signal characteristics that can be effectively identified by the receiving end from the signals of the communication link. Its characteristic amplitude, duration, and code pattern are adapted to the signal recognition capability of the corresponding communication link.

[0011] The type identifier segment is a fixed-length unique identifier used to distinguish two or more different types of business data. The identifier length is adaptively set according to the number of business types.

[0012] The service data segment is used to carry various types of valid service data, and its length can be adaptively adjusted according to transmission requirements.

[0013] The verification segment is used to detect and verify transmission errors in the service data segment, and the verification scope covers at least the type identifier segment and the service data segment.

[0014] The multiple sets of independent data frames are continuously transmitted according to service requirements using any one of the following transmission modes: cyclic transmission, alternating transmission, on-demand triggered transmission, or timed transmission, while maintaining the idle level state of the link specification between frames.

[0015] The anomaly handling mechanism includes one or more of the following: frame synchronization loss, data verification error, invalid type identifier, abnormal data frame length, link interference fluctuation, and bus conflict anomaly.

[0016] The multi-type data co-line transmission system provided by the present invention includes a transmitting end and a receiving end connected by a communication link; The transmitting end includes a data caching module, a frame encapsulation module, and a transmission driver module connected in sequence; the data caching module is used to cache different types of service data; the frame encapsulation module is used to encapsulate different types of service data into data frames containing a synchronization identifier segment, a type identifier segment, a service data segment, and a check segment; the transmission driver module is used to transmit the data frames via the communication link; The receiving end includes a signal acquisition module, a synchronization detection module, a type parsing module, a verification module, a data separation module, and a directional output module connected in sequence. The signal acquisition module is used to acquire data frames on the link; the synchronization detection module is used to identify frame headers; the type parsing module is used to distinguish data types; the verification module is used for data verification; the data separation module is used to separate data that passes verification; and the directional output module is used to output the separated data in a directional manner.

[0017] The communication link supports any one or more of the following communication modes: one-way, half-duplex, and full-duplex. The sending end and the receiving end can flexibly switch roles based on the link characteristics. Beneficial effects

[0018] The present invention has the following advantages: 1. Fully compatible with existing communication links, and adaptable to existing hardware, circuits, devices, drivers and underlying transceiver protocols.

[0019] 2. To achieve stable co-line transmission of multiple types of data on a single communication link, ensuring that various types of data do not interfere with each other, are not misaligned, and are not mixed up.

[0020] 3. It enables automatic frame synchronization, data type identification, transmission verification, data separation, and directional output at the receiving end, without the need for manual configuration and debugging.

[0021] 4. Adapts to various communication link types and communication modes, improving the versatility and applicability of the solution.

[0022] 5. Frame encapsulation, caching, synchronization detection, type identification, verification, data separation, and targeted output are all implemented by software functional modules, which can reduce hardware modification costs, simplify deployment processes, and improve system scalability, stability, and real-time transmission performance.

[0023] 6. The type identifier segment can be flexibly configured by byte. The number of bytes can be adjusted adaptively according to the number of service types. By default, 1 byte can support the differentiation of 256 service types without the need to increase the link bandwidth. No configuration adjustment is required in normal scenarios, and it can be flexibly expanded in complex scenarios.

[0024] 7. This invention solves the problems of high wiring costs, poor compatibility, and cumbersome deployment in the prior art by using a “frame structure standardization + software parsing” design. It does not require adding hardware or modifying the underlying protocol and can be directly adapted to the upgrade needs of old systems.

[0025] The technical solution of the present invention will be further described below with reference to the accompanying drawings. Attached Figure Description

[0026] Figure 1 This is a block diagram of the multi-type data collinear transmission system of the present invention.

[0027] Figure 2 This is a schematic diagram of the complete structure of an independent data frame.

[0028] Figure 3It is a timing waveform diagram of multi-type data co-line transmission (t - frame interval time, T - data frame transmission duration), showing the unified timing framework for continuous transmission of multiple types of data frames. Each data frame contains a synchronization identifier segment S (Sync), a type identifier segment T (Type), a service data segment D (Data), and a check segment C (Chek). The synchronization identifier segment S can be flexibly configured into fixed level, pulse train, break signal, specific code pattern, etc., according to the communication link type. The frame interval is the idle state defined by the specifications of each communication link. When multiple frames are transmitted continuously, the frame interval duration meets the electrical and timing requirements of the corresponding link. Detailed Implementation

[0029] See Figure 1 , Figure 2 The present invention provides a multi-type data co-line transmission system, comprising a transmitting end and a receiving end connected via a communication link; the transmitting end includes a data buffer module, a frame encapsulation module, and a transmission driver module connected in sequence; the data buffer module is used to buffer different types of service data; the frame encapsulation module is used to encapsulate different types of service data into data frames containing a synchronization identifier segment, a type identifier segment, a service data segment, and a check segment; the transmission driver module is used to transmit the data frames via the communication link; the receiving end includes a signal acquisition module, a synchronization detection module, a type parsing module, a verification module, a data separation module, and a directional output module connected in sequence; the signal acquisition module is used to acquire the data frames on the communication link; the synchronization detection module is used to identify the frame header of the data frames; the type parsing module is used to distinguish data types; the verification module is used to perform data verification on the data frames; the data separation module is used to separate the data frames that pass the verification; and the directional output module is used to output the separated data in a directional manner.

[0030] The sending end and the receiving end are not fixed in hardware, and the roles can be flexibly interchanged based on the characteristics of the communication link, adapting to the bidirectional data transmission needs of various communication modes such as one-way, half-duplex, and full-duplex.

[0031] The sending driver module and the signal acquisition module are both adapted to the hardware structure, electrical specifications, timing rules and underlying protocols of the communication link to ensure stable transmission of the data frames.

[0032] The communication link supports any one or more communication modes, including unidirectional, half-duplex, and full-duplex communication modes. It is compatible with various link types such as wired bus, RS485, UART, DMX512, Ethernet, wireless radio frequency, Bluetooth, WiFi, and power line carrier, and is compatible with their native hardware specifications and protocols. It supports flexible switching between the transmitting and receiving roles of the sending end and the receiving end based on the characteristics of the communication link.

[0033] The functional modules of both the sending end and the receiving end are implemented in software, including the data buffer module, frame encapsulation module, and sending driver module of the sending end, and the signal acquisition module, synchronization detection module, type parsing module, verification module, data separation module, and directional output module of the receiving end.

[0034] The multi-type data collinear transmission method provided by this invention, based on the above-mentioned system, performs data transmission, including: The sending end buffers and encapsulates multiple data streams of different types into frames, generating independent data frames for each. Each independent data frame sequentially includes a synchronization identifier segment, a type identifier segment, a service data segment, and a checksum segment, as shown below. Figure 2 As shown; Multiple sets of independent data frames are transmitted sequentially and continuously on the same communication link, with the frame interval conforming to the electrical and timing specifications of the communication link, such as... Figure 3 As shown; The receiving end continuously monitors the signal of the communication link, completes frame synchronization through the synchronization identifier segment, reads the type identifier segment to distinguish data types, and verifies the service data segment through the check segment. If the verification is successful, different types of data are separated and output to the corresponding devices. If the verification fails, the exception handling mechanism is triggered to directly discard the exception frame.

[0035] The communication link is an existing communication link, and the transmission process is compatible with the hardware structure, electrical specifications, timing rules, driving method and underlying transceiver protocol of the communication link, and is adapted to the native idle timing and signal characteristics of the communication link.

[0036] The independent data frames can adopt a fixed length or variable length structure.

[0037] The synchronization identifier segment is used by the receiving end to quickly capture the frame header, accurately complete frame synchronization, and avoid data parsing misalignment. It has unique and identifiable signal characteristics that can be effectively identified by the receiving end from the signals of the communication link. Its characteristic amplitude, duration, and code pattern are adapted to the signal recognition capability of the corresponding communication link.

[0038] The type identifier segment is a fixed-length unique identifier used to distinguish two or more different types of business data. The identifier length is adaptively set according to the rule that 2^(8×n) ≥ the number of business types, where n is the number of identifier bytes and 1 byte = 8 binary bits. This invention uses a 1-byte identifier by default, which can support the distinction of 256 business types and supports the expansion of multiple data types.

[0039] The service data segment is used to carry various types of valid service data, and its length can be adaptively adjusted according to transmission requirements.

[0040] The verification segment uses conventional data transmission verification methods to detect and verify transmission errors in the service data segment. The verification scope covers at least the type identifier segment and the service data segment. Conventional verification methods can be adapted and verified according to the scenario, such as CRC16 and CRC32, to ensure the integrity and accuracy of data transmission.

[0041] Multiple sets of independent data frames can be continuously transmitted in any transmission mode according to business needs, and the frames maintain an idle state that conforms to the communication link specification. Common transmission modes include cyclic transmission, alternating transmission, on-demand triggered transmission, and timed transmission.

[0042] For wireless links such as radio frequency, Bluetooth, WiFi, and power line carrier, the frame structure, synchronization identifier segment, and frame interval of this invention are all compatible with the native standard specifications of the corresponding wireless links. The synchronization identifier segment can be directly combined and matched with the native frame header of the wireless link, reusing the frame header identification logic of the wireless link itself to complete the synchronization, without the need for additional synchronization signals or additional adaptation modifications. For link collision avoidance in multi-node / bidirectional transmission, this invention is compatible with the native collision avoidance rules of each communication link, and can also adapt to conventional bus collision avoidance strategies according to link requirements. The frame interval for continuous transmission of multiple frames is based on the idle timing requirements defined in the electrical and timing standards of the corresponding communication link, ensuring transmission compatibility.

[0043] Sending end workflow First, it receives different types of business data through multiple data input interfaces and completes data caching and formatting.

[0044] Second, a unique type identifier is assigned to each type of business data. This invention uses a 1-byte identifier by default, which can accurately mark up to 256 types.

[0045] Third, according to the preset frame structure, add the synchronization identifier segment, type identifier segment, business data segment, and verification segment in sequence, such as... Figure 2 As shown, the independent data frame encapsulation is completed.

[0046] Fourth, multiple sets of independent data frames are sequentially and continuously transmitted on the same communication link through the transmission driver module, such as... Figure 3 As shown.

[0047] Fifth, it supports multiple transmission modes such as cyclic sending, alternating sending, event-triggered sending, and timed sending, maintaining an idle state that conforms to the communication link specification between frames, such as... Figure 3 As shown, a link idle check must be performed before sending, and transmission can only be initiated after the link timing specifications are met.

[0048] Receiver Workflow First, the signal acquisition module continuously monitors the signal of the communication link and captures synchronization identification features in real time.

[0049] Second, after detecting a valid synchronization identifier, the frame header of the data frame is locked to complete the frame synchronization operation.

[0050] Third, read the content of the type identifier segment, determine the business data type corresponding to the current data frame, and discard the frame directly if an invalid type identifier is detected.

[0051] Fourth, extract the content of the business data segment and complete the transmission error verification through the check segment.

[0052] Fifth, valid data that passes verification is processed by the data separation module and then transmitted to the corresponding device through the directional output module; abnormal data frames that fail verification or have abnormal frame lengths are directly discarded, and transmission error information is recorded.

[0053] Sixth, the system can automatically adapt to data frames of different lengths and transmission rates, improving transmission compatibility. When frame synchronization is lost, the synchronization flag monitoring process is automatically restarted to quickly re-establish frame synchronization.

[0054] Example 1: Lighting and audio co-line transmission based on the standard DMX512 protocol This embodiment is applied to standard DMX512 control scenarios such as stage lighting, studios, performance bars, and mobile performances. Under the premise of fully complying with the DMX512-A protocol and without modifying existing hardware and cabling, a single transmitting device alternately transmits standard lighting control data and digital audio data in a time-division multiplexing manner on the same DMX512 bus. This enables a single link to carry multiple types of service data, simplifies on-site cabling, and improves system integration and mobility.

[0055] This embodiment only needs to distinguish between two service types, and the default 1-byte type identifier segment of this invention can fully meet the requirements.

[0056] Hardware components and interfaces Transmitter hardware: The main controller uses an STM32 or dedicated DMX512 main control chip; the built-in UART serial port is used to generate standard DMX512 timing; the RS485 differential driver chip uses compatible devices such as MAX485 and SN75176; the differential bus interface is a 2-core shielded twisted pair cable with A and B terminals; the audio input uses an I²S or PCM interface audio acquisition module; the power supply uses a DC 9V to 24V wide voltage stage equipment power supply.

[0057] Transmission link hardware: The standard DMX512 bus uses 2-core shielded twisted pair cable with a characteristic impedance of 120Ω; a 120Ω terminating resistor is connected in parallel at the end of the bus; the physical interface uses a standard three-core XLR male and female plug, which is compatible with existing stage cabling.

[0058] Receiver hardware: The standard DMX512 luminaire has a built-in RS485 receiver and driver decoding circuit; the audio receiver module consists of an RS485 receiver chip, an audio DAC, and a power amplifier circuit; the output is connected to the lighting actuator and the audio playback device respectively.

[0059] Protocol and Timing Specifications This embodiment strictly follows the DMX512-A standard protocol; the physical layer is RS-485 differential transmission; the baud rate is fixed at 250kbps; the data format is 1 start bit, 8 data bits, 2 stop bits, and no parity; the frame timing consists of a Break signal of not less than 92μs, a MAB signal of not less than 12μs, a start code, and 512 channels of data.

[0060] Frame structure and parameter definition Synchronization Identifier Segment: The DMX512 standard Break signal is reused as the frame synchronization feature, corresponding to the attached... Figure 3 In this embodiment, the synchronization identifier segment area of ​​the data frame is configured as a DMX512 specification Break low-level signal. Its characteristics are compatible with the DMX512 link signal recognition capability and can be stably recognized. The receiving end completes frame header locking by recognizing the Break, without adding a new synchronization signal, and is fully compatible with the protocol timing.

[0061] Type Identifier Segment: The type is distinguished by the DMX512 start code, which is 1 byte long. The start code 0x00 indicates a standard light control data frame, and the start code 0x01 indicates a digital audio data frame, so as to realize automatic type recognition.

[0062] Business data segment: Lighting data is standard 512-channel DMX control data; audio data uses 8-bit or 16-bit PCM format data packets, adapted to DMX512 250kbps baud rate, and the length of a single audio data packet is ≤64 bytes.

[0063] Checksum section: A checksum is added to the end of the audio data packet to detect transmission errors, ensure the integrity of the audio data, and cover the start code 0x01 and the audio data packet.

[0064] Sending end workflow The transmitting end generates Break and MAB as frame headers according to the DMX512-A standard timing; the lighting control data and digital audio data are buffered and encapsulated separately, such as... Figure 2 As shown; light frames and audio frames are sent in an alternating transmission mode, such as... Figure 3 As shown; light frames begin with start code 0x00, followed by 512 channel standard data; audio frames begin with start code 0x01, followed by audio data packets and checksums; transmission timing, level, and frame interval all conform to the DMX512-A specification, as shown. Figure 3 As shown, ensure smooth synchronization between lighting and audio.

[0065] Receiver Workflow The receiving end continuously monitors the bus signals, captures the DMX512 Break signal, and completes frame synchronization, such as Figure 3 As shown; the start code is read to determine the data type: if it is 0x00, it is determined to be light data and directly output to the standard DMX512 driver module; if it is 0x01, it is determined to be audio data, the data packet is extracted and verified, and after the verification is successful, it is sent to the audio decoding module; the standard DMX512 device only responds to frames with start code 0x00 and is not affected by audio data, realizing multi-type data isolation and diversion. When a link signal conflict is detected, data parsing is immediately terminated and the bus monitoring state is restored.

[0066] Applicable equipment description In this embodiment, the lighting control data is output to the standard DMX512 stage lighting fixtures, including PAR lights, moving head lights, beam lights, and light strip controllers, which are the corresponding equipment; the digital audio data is output to the stage audio playback equipment, including power amplifiers, full-range speakers, monitor speakers, and audio decoders, which are the corresponding equipment. All the related equipment are existing equipment commonly used in stage scenes and do not require addition or modification. Implementation effect

[0067] This embodiment fully complies with the DMX512-A protocol specification. Standard DMX512 lighting fixtures can operate normally and stably without delay, abnormalities, or interference. Digital audio and lighting control data are transmitted synchronously on the same bus. Figure 3 As shown, the audio is smooth and distortion-free, without any stuttering; the solution is purely software-based, requiring no changes to hardware, wiring, or existing protocols. Its compatibility, stability, and real-time performance meet the engineering requirements of professional stage performance equipment. The 1-byte type identifier segment accurately distinguishes between two data types, eliminating resource waste and ensuring high transmission efficiency.

[0068] Example 2: Control data and sensor data are transmitted on the same line based on a standard RS485 bus. Application scenarios This embodiment is applied to industrial site monitoring, intelligent equipment control, and distributed data acquisition scenarios. Based on the characteristics of RS485 half-duplex bus, it enables flexible interchange of the transmitting and receiving roles of all nodes on the bus. It allows for bidirectional, time-division, and orderly transmission of equipment control data, multi-channel sensor acquisition data, and equipment status feedback data on a single link. The receiving end / transmitting end can automatically identify data types, complete verification and separation, and output in a targeted manner. It is fully compatible with existing RS485 electrical specifications, timing rules, and hardware structures, without the need for adding or modifying hardware, and adapts to the actual needs of bidirectional interaction in industrial sites.

[0069] This embodiment needs to distinguish between four service types, and the default 1-byte type identifier segment of this invention can fully meet the requirements.

[0070] Hardware components and interfaces Sending / receiving node hardware (all nodes are configured uniformly, and role interchangeability is supported). The main controller uses industrial-grade microcontrollers such as STM32 and AVR; it is equipped with a hardware UART serial port for communication drive; the RS485 driver chip uses compatible devices such as MAX485 and SP3485, and the chip's DE / RE pins are shorted to connect to the MCU's general-purpose I / O port, serving as the core for half-duplex role switching; it is equipped with differential bus A and B signal interfaces; it integrates GPIO control output interface and ADC sampling interface, supporting I²C, SPI and analog sensor access; it is equipped with current limiting and ESD electrostatic protection circuits; the power supply adopts DC 5V, 12V or 24V industrial wide voltage power supply.

[0071] Core design: All nodes have identical hardware, with no fixed master / slave hardware distinction. The node ID and default working mode are configured only through software, enabling flexible switching between sending and receiving roles.

[0072] Transmission link hardware The transmission medium is shielded 2-core twisted pair cable with a characteristic impedance of 120Ω; a 120Ω terminating resistor is connected in parallel at each end of the bus; a bus topology cabling is adopted, and the transmission distance can reach 0 to 1200 meters, which complies with the industrial RS485 standard; all nodes are connected in parallel to the A and B ends of the bus, using the existing industrial field cabling method.

[0073] Output hardware All nodes are configured with corresponding execution / monitoring modules according to business functions, such as execution modules like relays and motors, and monitoring modules like displays and data upload modules. All hardware is reused from existing industrial equipment, with no additions or modifications.

[0074] Electrical and communication parameters Communication method: Half-duplex differential transmission; Baud rate: 9600bps; Data format: 1 start bit, 8 data bits, 1 stop bit, no parity; Level specification: Complies with RS485 differential ±2V to ±6V standard; Frame interval: Not less than 10ms. This parameter is based on a 9600bps baud rate and can be adjusted proportionally according to the actual baud rate to ensure bus idle timing and avoid data conflicts. Node configuration: All nodes are assigned a unique 1-byte node ID, where node ID=0x00 is the master control node, and node ID=0x01~0xFF is the slave node. The master control node has the highest priority to send bus messages, and the slave nodes are sensing / execution nodes.

[0075] Frame structure and parameter definition All data transmitted by all nodes adopts a unified frame structure, in byte order as follows: Synchronization Identifier Segment → Type Identifier Segment → Target Node ID Segment → Service Data Segment → Check Segment. The definitions of each segment are as follows: Synchronization identifier segment: configured as a 2-byte fixed code pattern 0xAA + 0x55, corresponding to the appendix. Figure 3 The synchronization identifier segment area of ​​the data frame has characteristics that are compatible with the RS485 link signal identification capability and can be stably identified. It is used for fast and stable synchronization of all nodes to avoid confusion with regular business data. The receiving end only starts the subsequent parsing process after capturing this code pattern. Type Identifier Field: A 1-byte fixed identifier used to distinguish all bidirectional transmission data types, adapted to core business operations in industrial settings, defined as follows: 0x01: Master node → slave node control data frames, such as device start / stop and parameter adjustment commands.

[0076] 0x02: Data frames acquired from the sensor between the slave node and the master node, such as sampled data of temperature, humidity, pressure, and current.

[0077] 0x03: Device status feedback frame from slave node to master node, such as device operation / fault, sensor online / offline status.

[0078] 0x04: Master node → Specifies a slave node to query a frame individually, such as when the master node sends a data query command to a sensor node.

[0079] Target Node ID segment: 1 byte, indicating the target node ID of the data frame, enabling precise broadcast / unicast transmission.

[0080] Target ID=0x00: Broadcast frame, which is parsed and executed by all nodes.

[0081] Target ID = 0x01~0xFF: Unicast frames, only the nodes corresponding to the ID are parsed and executed, and the rest are discarded after verification.

[0082] The target node ID=0x00 also serves as the unique identifier of the master control node. When transmitting data from the slave node to the master node, the target ID is uniformly configured as 0x00 to achieve unicast transmission.

[0083] Business data segment: The length adapts to the business type, and the business data format corresponding to each type of frame is as follows: 0x01 Control Data Frame: Channel number 1 byte + control parameters 2 bytes.

[0084] 0x02 Sensor acquisition data frame: Sensor ID 1 byte + Data type 1 byte + Sample value 2 bytes.

[0085] 0x03 Status Feedback Frame: Device Module ID 1 byte + Running Status 1 byte, 0x00 = Normal, 0x01 = Fault, 0x02 = Offline.

[0086] 0x04 Single query frame: Query instruction 1 byte, 0x00 = collected data query, 0x01 = status query.

[0087] Verification segment: Configured as a 2-byte CRC16 check, covering the type identifier segment + target node ID segment + business data segment, improving transmission reliability in complex industrial environments. The verification algorithm adopts the industrial general RS485 CRC16 standard algorithm.

[0088] Half-duplex sender / receiver role switching core control logic All nodes switch between transmit and receive roles via software control using the DE / RE pins of the RS485 chip. The core rules are unified, and the entire process is implemented in software without any hardware modifications. The specific logic is as follows: Default mode: After all nodes are powered on, the MCU controls the DE / RE pins to be low, the RS485 chip enters receive mode, and all nodes continuously monitor the signals at bus A and B ends to capture the synchronization flag segment; Transmit mode switching: When any node needs to transmit data, it first performs a bus idle detection, continuously monitors the bus for ≥10ms, and confirms that there is no signal transmission. If it is a master node, ID=0x00, it directly sets the DE / RE pin to a high level and enters the transmit mode. If it is a slave node, it needs to additionally detect the master node's occupancy status, monitor the bus for ≥20ms, confirm that there is no master node data transmission, and then set DE / RE to a high level to enter the transmit mode. Data transmission: After entering the transmission mode, the data frame is encapsulated according to the unified frame structure and sent to the RS485 bus through the UART serial port. The transmission process strictly follows the 9600bps baud rate and timing specifications. Resume receive mode: After a single frame of data is sent, the MCU immediately sets the DE / RE pin back to low level, the RS485 chip resumes receive mode, and the node re-enters the bus monitoring state to ensure that the bus is released in a timely manner and to avoid being occupied.

[0089] Complete bidirectional transmission workflow This embodiment has no fixed sender / receiver; all nodes implement bidirectional data transmission according to business requirements and node ID rules. The following describes four core business scenarios: Scenario 1: Master node (0x00) → All slave nodes (broadcast): Send control data frame (0x01) After the master node detects that the bus has been idle for ≥10ms, it switches to transmit mode and encapsulates a broadcast control data frame: 0xAA+0x55 → 0x01 → 0x00 → channel number + control parameters → CRC16 checksum; The master node sends the data frame according to the specification, and immediately resumes the receiving mode after sending is completed; All slave nodes continuously monitor the bus, and after capturing the synchronization flag, they complete frame synchronization, and sequentially parse the type flag segment (0x01) and the target ID (0x00, broadcast), and perform CRC16 verification. For nodes that pass the verification, the control instructions of the service data segment are parsed and output to the corresponding execution module, such as a relay or motor; for nodes that fail the verification, the frame is discarded without any processing. After all slave nodes have completed their operations, they remain in receive mode and wait for subsequent data.

[0090] Scenario 2: From node (e.g., 0x05) to master node (unicast): Send sensor acquisition data frame (0x02) After the sensor data sampling is completed at node 0x05, if the bus is idle for ≥20ms and there is no master node transmitting, switch to transmit mode and encapsulate the unicast sensor data frame: 0xAA+0x55 → 0x02 → 0x00 → Sensor ID + Data Type + Sample Value → CRC16 Check. The receiving mode is immediately resumed after the data frame is sent from node 0x05; After the master node captures the synchronization flag, it completes frame synchronization, parses the type flag segment (0x02) and the target ID (0x00), and performs CRC16 verification. After successful verification, the master node will output the sensor data to the monitoring module, such as the display screen or the data upload module; the remaining slave nodes will parse the target ID as 0x00, and only the master node will process it, while the other nodes will discard the frame.

[0091] Scenario 3: From a slave node (e.g., 0x08) to a master node (unicast): Send a device status feedback frame (0x03). After a device failure is detected at node 0x08, a status report is triggered. After the bus has been idle for ≥20ms, the report switches to transmit mode and encapsulates a unicast feedback frame: 0xAA+0x55 → 0x03 → 0x00 → Device Module ID + Fault Status (0x01) → CRC16 checksum. Resume receive mode after sending from node 0x08; After the master node completes frame synchronization, parsing, and verification, it outputs the fault status to the alarm / monitoring module to achieve real-time feedback of anomalies in the industrial field; the remaining nodes discard the frame according to the rules.

[0092] Scenario 4: Master node (0x00) → Specify slave node (e.g., 0x03, unicast): Send a separate query frame (0x04). The master node needs to query the sensor data of slave node 0x03. After detecting that the bus is idle for ≥10ms, it switches to transmit mode and encapsulates a unicast query frame: 0xAA+0x55 → 0x04 → 0x03 → Query command (0x00, data acquisition query) → CRC16 check. The master node immediately resumes receive mode after sending the data; After all nodes capture the synchronization flag, they complete the parsing. Only the ID of node 0x03 matches the target ID, and a CRC16 check is performed and the query command is parsed. The other nodes discard the frame directly after the check passes because the target ID does not match, without any processing. After parsing the data acquisition query command from node 0x03, the sensor acquisition data frame is immediately encapsulated and sent to the master node according to the process of scenario 2, so that the master node can accurately query the data of the specified slave node. If the master node does not receive a response from the slave node within 100ms after sending the query frame, it can retransmit once according to the rules.

[0093] Bus collision avoidance rules (pure software implementation, adapted for half-duplex bidirectional transmission) To avoid bus data conflicts and aliasing caused by multiple nodes simultaneously switching to transmit mode, three simple industrial-grade avoidance rules are formulated based on node ID and software detection. These rules require no additional hardware and are highly practical for implementation. 1. Master node priority rule: The master control node with node ID=0x00 has the highest priority to send data on the bus. Before any slave node sends data, it must continuously monitor the bus for ≥20ms and confirm that there is no master node data transmission before it can initiate a transmission request.

[0094] 2. Time-sharing transmission rules for slave nodes: When multiple slave nodes have transmission needs at the same time, transmission time slots are allocated according to the node ID from smallest to largest. Each time slot is 50ms. The slave node sends data after detecting that the bus is idle within its own time slot. The time slots are uniformly configured by the master node and written into the MCU by software, without the need for manual intervention.

[0095] 3. Retransmission restriction rules: If no response is received from the target node after any node sends data, such as if the master node does not receive data from the slave node within 100ms after sending a query frame, it can retransmit once. Retransmission still needs to follow the bus idle detection rules. If two consecutive retransmissions fail, the sending will stop and the transmission error information will be recorded to avoid continuous bus occupation.

[0096] Applicable equipment description In this embodiment, control data is output to industrial field execution devices as corresponding equipment, including industrial control execution devices such as relay modules, frequency converters, stepper motor controllers, solenoid valves, electric valves, and industrial indicator lights; sensor data is output to industrial monitoring devices as corresponding equipment, including data monitoring and storage devices such as industrial touch screens, data acquisition instruments, PLC hosts, cloud platform gateways, and industrial displays; status feedback data is collected and transmitted back by the execution devices / sensing devices themselves. All related application devices are common existing devices in industrial monitoring scenarios, which can be directly reused without modification. Implementation effect

[0097] A single RS485 half-duplex bus enables bidirectional, multi-type data co-line transmission, supports flexible interchange of all node transceiver roles, and fully adapts to the actual needs of bidirectional interaction in industrial field control, data acquisition, feedback, and query. All nodes have identical hardware, with no fixed transmitter or receiver distinction. Role switching is achieved only through software configuration. It is fully compatible with existing RS485 hardware, electrical specifications, and timing requirements. No new or modified hardware or rewiring is required, making it convenient to deploy in industrial fields with extremely low upgrade costs. It adopts a combined broadcast and unicast transmission method, which ensures accurate data transmission, no interference from irrelevant nodes, stable transmission in complex industrial environments such as strong electromagnetic interference, strong anti-interference ability, and no packet loss, misalignment, or aliasing. The pure software implementation of frame encapsulation, role switching, conflict avoidance, data parsing and targeted output reuses the original design in the core logic, has strong scalability, and can adapt to more industrial business data transmission needs by adding the type identifier segment and the business data segment format. All nodes are in receive mode by default, resulting in low bus occupancy and high real-time data transmission, which fully meets the real-time requirements of industrial field monitoring and distributed data acquisition. The 1-byte type identifier segment accurately distinguishes four types of industrial business data, leaving room for 252 types of expansion, which can flexibly adapt to the type expansion needs of subsequent industrial scenarios.

[0098] Example 3: UART-based co-line transmission of service data and debug logs Application scenarios This embodiment is applied to scenarios such as embedded development, smart terminals, and industrial control boards. A single transmitting device continuously transmits user service data and system debugging log data in a time-division multiplexing manner over a standard UART serial port link. Both types of data frames are transmitted in an orderly, co-linear manner on the same link. Figure 3 As shown, the receiving end automatically identifies the type, verifies, separates, and outputs the data in a targeted manner, ensuring full compatibility with existing UART hardware, electrical and timing specifications, without affecting the original business functions.

[0099] This embodiment only needs to distinguish between two service types, and the default 1-byte type identifier segment of this invention can fully meet the requirements.

[0100] Hardware components and interfaces Transmitter hardware: The main controller uses an embedded MCU, STM32, or ARM processor with a built-in standard UART interface; the UART interface includes a TX transmit pin and an RX receive pin, supporting half-duplex and full-duplex modes; the voltage level standard is 3.3V CMOS, compatible with 5V level systems; service data comes from external units such as sensors, buttons, and communication modules; debugging data comes from the MCU's internal operation logs, status information, and error codes.

[0101] Transmission link hardware: The transmission medium is a common single-ended signal line, DuPont wire, or ribbon cable; the system common GND is used as the reference ground; the transmission distance is 0 to 10 meters, suitable for communication between boards and short-distance devices; standard pin headers and sockets are used for connection, and no terminating resistor is required.

[0102] Receiver hardware: Uses common UART to USB modules such as CH340, CP2102, and PL2300; the receiving device is a PC host computer or debugging assistant; the output is divided into a service data parsing interface and a debugging log display window; the entire process uses existing hardware without modification or the addition of new circuits.

[0103] Communication parameter specifications The communication interface is a standard UART asynchronous serial communication; the commonly used baud rate is 9600bps or 115200bps, which can be configured; the data format is 1 start bit, 8 data bits, 1 stop bit, and no parity; the idle state is high level, and the frame interval is not less than 5ms. This parameter is based on the 9600bps / 115200bps baud rate adaptation and can be adjusted proportionally according to the actual baud rate. This frame interval conforms to the UART general timing specification.

[0104] Frame structure and parameter definition Synchronization identifier segment: configured as a 2-byte fixed frame header 0xAA + 0x55, corresponding to the appendix. Figure 3The synchronization identifier segment area of ​​the data frame has characteristics that are compatible with the UART link signal recognition capability and can be stably identified. It is used by the receiving end to quickly complete frame synchronization and is compatible with the code-type synchronization form of the UART serial port.

[0105] Type Identifier: 1-byte identifier code, 0x01 for user service data frames, 0x02 for system debugging log data frames.

[0106] Business data segment: length adaptive, business data is custom protocol content, and log data is ASCII string or hexadecimal status code.

[0107] Checksum: Configured as an 8-bit checksum, the calculation range is the type identifier segment + the service data segment, the calculation method is to sum the values ​​of each byte and take the lower 8 bits. If the checksum value is consistent with the calculation result of the receiving end, it is determined that the check is passed, so as to ensure the reliability of transmission.

[0108] Sending end workflow The transmitting device simultaneously collects service data and debug logs, and caches them separately; it encapsulates them into service data frames and debug data frames according to a unified frame structure, such as... Figure 2 As shown; alternating transmission mode is used for continuous time-division transmission on the same UART interface, such as... Figure 3 As shown; the frame interval is not less than 5ms, such as Figure 3 As shown, it conforms to the UART idle timing; it transmits data cyclically to ensure real-time data transmission, and performs link idle detection before transmission to avoid data transmission conflicts.

[0109] Receiver Workflow The receiving end continuously monitors the UART signal, and completes frame synchronization after capturing the synchronization flag, such as... Figure 3 As shown; read the type identifier segment to distinguish between business data and debugging logs; perform verification, and output the data separately if the verification passes; send business data to the business parsing module and debugging logs to the log display module. The two types of data do not interfere with each other. Frames that fail verification or lose synchronization identifiers are directly discarded without affecting normal data parsing.

[0110] Applicable equipment description In this embodiment, user service data is directed to embedded device function execution devices that serve as corresponding devices, including embedded terminal function devices such as sensor modules, LCD screens, button modules, motor drive boards, and wireless communication modules (Bluetooth / WiFi); system debugging log data is directed to development and debugging devices that serve as corresponding devices, including general embedded development and debugging devices such as PC hosts, portable debuggers, serial port screens, and data loggers. All related application devices are conventional devices in embedded development scenarios, and existing hardware can be directly reused. Implementation effect

[0111] A single UART interface can simultaneously carry business data and debug logs, such as Figure 3 As shown, no additional serial port resources are required; it is fully compatible with standard UART hardware and communication timing; it is implemented purely in software, without modifying the hardware or affecting the original functions; the transmission is stable and the parsing is accurate, greatly simplifying the hardware design and wiring of embedded systems. In the mass production and later maintenance of embedded devices, it can significantly reduce debugging and maintenance costs; the 1-byte type identifier segment accurately distinguishes two types of embedded data, ensuring efficient transmission and no resource waste.

[0112] Exception handling mechanism The anomaly handling mechanism of this invention is deeply integrated with the workflow of the sending end and the receiving end, realizing anomaly monitoring and handling at each stage of data transmission and parsing to ensure stable system operation, including: First, frame synchronization loss: The synchronization flag monitoring process is automatically restarted to quickly re-establish frame synchronization.

[0113] Second, data verification errors: directly discard the current abnormal data frame and do not output interference data to ensure system stability.

[0114] Third, invalid type identifier: Ignore illegal data frames to prevent erroneous data from being routed to functional modules.

[0115] Fourth, abnormal data frame length: Filter excessively long or short frames according to preset specifications to prevent parsing program errors.

[0116] Fifth, link interference fluctuations: Relying on a stable synchronization identifier identification mechanism, it resists link signal jitter and ensures normal parsing.

[0117] Sixth, bus conflict anomaly: When a signal conflict caused by multiple nodes sending data simultaneously is detected, the current data transmission is immediately terminated, all nodes resume receiving mode and re-monitor the bus, and re-initiate transmission according to preset rules after the bus is idle.

[0118] Key Parameter Description The synchronization identifier must possess unique signal characteristics, be uniquely identifiable, and be effectively identified by the receiving end from the signals of the communication link, such as... Figure 3 Synchronization identifier segment example, to avoid being simulated by normal business data, can be flexibly configured into various forms such as fixed level, pulse train, specific code pattern; The type identifier is a fixed-length unique code, such as Figure 2 The length of the type identifier segment shown is set according to the rule that 2^(8×n) ≥ the number of business types, where n is the number of identifier bytes and 1 byte = 8 binary bits; this invention uses 1 byte by default, supporting 256 types, and can be expanded to 2 bytes in complex scenarios, supporting 65536 types; The frame interval follows the electrical and timing specifications of mainstream communication links, and is based on the idle timing requirements defined in the electrical and timing standards of the corresponding communication links to ensure continuous transmission stability. The frame interval of different links is adapted according to their native specifications and can be adjusted proportionally according to the actual baud rate of the link. The verification mechanism can be flexibly configured according to the transmission scenario, such as Figure 2 The verification segment shown balances data transmission reliability and software computation efficiency. Simple scenarios can use CRC16 and CRC32 verification methods, while complex industrial / wireless scenarios can use CRC16 / CRC32 and other verification methods.

Claims

1. A method for multi-type data co-line transmission, characterized in that, include: The sending end buffers and encapsulates multiple different types of service data, generating independent data frames for each; The independent data frame sequentially includes a synchronization identifier segment, a type identifier segment, a business data segment, and a verification segment; Multiple sets of independent data frames are transmitted sequentially and continuously on the same communication link, with the frame interval conforming to the electrical and timing specifications of the communication link. The receiving end continuously monitors the signal of the communication link, completes frame synchronization through the synchronization identifier segment, reads the type identifier segment to distinguish data types, and verifies the service data segment through the check segment. If the verification is successful, the different types of data are separated and output to the corresponding devices. If the verification fails, the exception handling mechanism is triggered to directly discard the exception frame.

2. The multi-type data collinear transmission method according to claim 1, characterized in that, The communication link is an existing communication link, and the transmission process is compatible with the hardware structure, electrical specifications, timing rules, driving method and underlying transceiver protocol of the communication link, and is adapted to the native idle timing and signal characteristics of the communication link.

3. The multi-type data collinear transmission method according to claim 1, characterized in that, The synchronization identifier segment is used by the receiving end to quickly capture the frame header, accurately complete frame synchronization, and avoid data parsing misalignment. It has a unique and identifiable signal characteristic that can be effectively identified by the receiving end from the signals of the communication link. Its characteristic amplitude, duration, and code pattern are adapted to the signal recognition capability of the corresponding communication link.

4. The multi-type data collinear transmission method according to claim 1, characterized in that, The type identifier segment is a fixed-length unique identifier used to distinguish two or more different types of business data. The identifier length is adaptively set according to the number of business types.

5. The multi-type data collinear transmission method according to claim 1, characterized in that, The service data segment is used to carry various types of valid service data, and its length can be adaptively adjusted according to transmission requirements.

6. The multi-type data collinear transmission method according to claim 1, characterized in that, The verification segment is used to detect and verify transmission errors in the service data segment, and the verification scope covers at least the type identifier segment and the service data segment.

7. The multi-type data collinear transmission method according to claim 1, characterized in that, The multiple sets of independent data frames are continuously transmitted according to service requirements using any one of the following transmission modes: cyclic transmission, alternating transmission, on-demand triggered transmission, or timed transmission, while maintaining the idle level state of the link specification between frames.

8. The multi-type data collinear transmission method according to claim 1, characterized in that, The anomaly handling mechanism includes one or more of the following: frame synchronization loss, data verification error, invalid type identifier, abnormal data frame length, link interference fluctuation, and bus conflict anomaly.

9. A multi-type data co-line transmission system, characterized in that, This includes the sending and receiving ends connected via a communication link; The transmitting end includes a data caching module, a frame encapsulation module, and a transmission driver module connected in sequence; the data caching module is used to cache different types of service data; the frame encapsulation module is used to encapsulate different types of service data into data frames containing a synchronization identifier segment, a type identifier segment, a service data segment, and a check segment; the transmission driver module is used to transmit the data frames via the communication link; The receiving end includes a signal acquisition module, a synchronization detection module, a type parsing module, a verification module, a data separation module, and a directional output module connected in sequence. The signal acquisition module is used to acquire data frames on the link; the synchronization detection module is used to identify frame headers; the type parsing module is used to distinguish data types; the verification module is used for data verification; the data separation module is used to separate data that passes verification; and the directional output module is used to output the separated data in a directional manner.

10. The multi-type data collinear transmission system according to claim 9, characterized in that, The communication link supports any one or more of the following communication modes: one-way, half-duplex, and full-duplex. The sending end and the receiving end can flexibly switch roles based on the link characteristics.

Images