Interoperability methods, bridging devices, storage media, and computer software products between Bluetooth intercom devices and Mesh intercom devices

By using the Bluetooth and Mesh communication modules in the bridging device, seamless audio data bridging between Bluetooth intercom devices and Mesh intercom devices is achieved, solving the interoperability problem between different types of terminals and improving the flexibility and user experience of cross-network collaborative work.

CN122496781APending Publication Date: 2026-07-31SHENZHEN AIQISHI INTELLIGENT TECHNOLOGY CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
SHENZHEN AIQISHI INTELLIGENT TECHNOLOGY CO LTD
Filing Date
2026-07-03
Publication Date
2026-07-31

AI Technical Summary

Technical Problem

It is difficult to achieve seamless bidirectional bridging of audio data between different types of communication terminals, which limits the flexibility of cross-network collaborative work.

Method used

By using the Bluetooth communication module and Mesh communication module in the bridging device, audio links and group communication are established with the Bluetooth intercom device and the private Mesh intercom network, respectively. The control module is used to perform audio data format conversion and digital mixing, so as to achieve seamless bidirectional bridging of audio data across networks.

Benefits of technology

It enables seamless cross-network audio data bridging between Bluetooth intercom devices and Mesh intercom devices, improving the collaborative capabilities of cross-network devices and the user experience.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122496781A_ABST
    Figure CN122496781A_ABST
Patent Text Reader

Abstract

This application discloses a method, bridging device, storage medium, and computer program product for interoperability between a Bluetooth intercom device and a Mesh intercom device. The method includes: establishing a Bluetooth audio link with the Bluetooth intercom device via a Bluetooth communication module; performing group communication with the Mesh intercom device via a Mesh communication module; in response to receiving first audio data, converting the first audio data into a Mesh network-compatible format via a control module to obtain processed first audio data, and broadcasting the processed first audio data to the Mesh intercom device via the Mesh communication module; in response to receiving local audio data and second audio data, digitally mixing the local audio data and second audio data via a control module to obtain a mixed audio stream, and transmitting the mixed audio stream back to the Bluetooth intercom device. Thus, by establishing a Bluetooth audio link and group communication via the bridging device, cross-network audio data bridging is achieved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the technical field of wireless communication and audio processing, and more specifically, to a method for interconnecting a Bluetooth intercom device and a Mesh intercom device, a bridging device, a storage medium, and a computer program product. Background Technology

[0002] With the development of wireless communication technology, wireless voice intercom devices have been widely used in various team collaboration scenarios. Currently, the industry typically adopts short-range communication solutions based on the standard Bluetooth protocol and self-organizing network communication solutions based on Mesh architecture to meet different voice interaction needs.

[0003] However, in practical applications, there is significant heterogeneity among different underlying communication protocols and network architectures. When users need to conduct cross-network group voice interaction between different types of communication terminals, it is often difficult for different types of communication terminals to achieve seamless bidirectional bridging of audio data, thus limiting the flexibility of collaborative work between different types of communication terminals. Summary of the Invention

[0004] In view of the above problems, this application proposes a method for interconnection between a Bluetooth intercom device and a Mesh intercom device, a bridging device, a storage medium, and a computer program product, which can solve the above problems.

[0005] In a first aspect, embodiments of this application provide a method for interoperating between a Bluetooth intercom device and a Mesh intercom device, applied to a bridging device. The bridging device includes a Bluetooth communication module, a Mesh communication module, and a control module. The method includes: establishing a Bluetooth audio link with the Bluetooth intercom device through the Bluetooth communication module to receive first audio data transmitted from the Bluetooth intercom device through the Bluetooth audio link; performing group communication with Mesh intercom devices in a private Mesh intercom network through the Mesh communication module to receive second audio data transmitted from the Mesh intercom devices; in response to receiving the first audio data, converting the first audio data into a Mesh network-compatible format through the control module to obtain processed first audio data, and broadcasting the processed first audio data to the Mesh intercom device through the Mesh communication module; in response to receiving local audio data and second audio data, digitally mixing the local audio data and second audio data through the control module to obtain a mixed audio stream, and transmitting the mixed audio stream back to the Bluetooth intercom device through the Bluetooth communication module.

[0006] Secondly, embodiments of this application also provide a bridging device, including a processor, a memory, and one or more applications; the one or more applications are stored in the memory and configured to be executed by the processor to implement the above-described method for interoperating between the Bluetooth intercom device and the Mesh intercom device.

[0007] Thirdly, embodiments of this application also provide a computer-readable storage medium storing program code, wherein the above-described method for interconnecting the Bluetooth intercom device and the Mesh intercom device is executed when the program code is run by a processor.

[0008] Fourthly, embodiments of this application also provide a computer program product, which includes a computer program stored on a computer-readable storage medium. The computer program includes program instructions, which, when executed by a computer, cause the computer to perform the above-described method for interoperating between a Bluetooth intercom device and a Mesh intercom device.

[0009] The technical solution provided in this application is applied to a bridging device, which includes a Bluetooth communication module, a Mesh communication module, and a control module. The method includes: establishing a Bluetooth audio link with a Bluetooth intercom device via the Bluetooth communication module to receive first audio data transmitted from the Bluetooth intercom device; conducting group communication with Mesh intercom devices in a private Mesh intercom network via the Mesh communication module to receive second audio data transmitted from the Mesh intercom devices; in response to receiving the first audio data, converting the first audio data into a Mesh network-compatible format via the control module to obtain processed first audio data, and broadcasting the processed first audio data to the Mesh intercom devices via the Mesh communication module; in response to receiving local audio data and the second audio data, digitally mixing the local audio data and the second audio data via the control module to obtain a mixed audio stream, and transmitting the mixed audio stream back to the Bluetooth intercom device via the Bluetooth communication module. Thus, by establishing a Bluetooth audio link with the Bluetooth intercom device and group communication with the private Mesh intercom network via the Bluetooth communication module and the Mesh communication module on the bridging device, respectively, seamless bidirectional bridging of audio data across networks is achieved. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments and drawings obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0011] Figure 1 This illustration shows a schematic diagram of the interoperability system between a Bluetooth intercom device and a Mesh intercom device provided in an embodiment of this application.

[0012] Figure 2The illustration shows a flowchart of a method for interoperating between a Bluetooth intercom device and a Mesh intercom device according to an embodiment of this application.

[0013] Figure 3 A schematic diagram of the structure of a bridging device provided in an embodiment of this application is shown.

[0014] Figure 4 This illustration shows a schematic diagram of the structure of a computer-readable storage medium provided in an embodiment of this application.

[0015] Figure 5 A schematic diagram of the structure of a computer program product provided in an embodiment of this application is shown. Detailed Implementation

[0016] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the invention as detailed in the appended claims.

[0017] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0018] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0019] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0020] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0021] References to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized.

[0022] Please see Figure 1 , Figure 1 This application provides a schematic diagram of the interoperability system between a Bluetooth intercom device and a Mesh intercom device, as illustrated in an embodiment of this application. Figure 1 As shown, the interconnection system 100 between the Bluetooth intercom device and the Mesh intercom device includes a bridging device 110, a Bluetooth intercom device 120, and a Mesh intercom device 130.

[0023] In some implementations, the bridging device 110 can be an intermediate hub device with cross-network protocol conversion and audio interoperability capabilities. The bridging device 110 integrates a Bluetooth communication module 111, a Mesh communication module 112, and a control module 113. In practical applications, the bridging device 110 can function as a standalone hardware gateway or be integrated into a walkie-talkie terminal. The core function of the bridging device 110 is to establish a data channel between the standard Bluetooth audio link and the private Mesh walkie-talkie network, enabling format conversion, bidirectional transmission, and mixing of audio data between heterogeneous networks.

[0024] In one specific implementation, the Bluetooth communication module 111 can be a wireless transceiver unit for interfacing with an external general-purpose terminal. The Bluetooth communication module 111 supports standard Bluetooth audio profiles, such as HFP, HSP, or A2DP, and is mainly used to establish and maintain a stable Bluetooth audio link with an external Bluetooth intercom device. It is responsible for receiving the raw voice data stream from the Bluetooth intercom device to the local device and packaging the mixed audio stream back to the Bluetooth intercom device through the Bluetooth protocol stack.

[0025] Mesh communication module 112 can be a radio frequency and baseband processing unit that accesses a private mesh network. It has a built-in or adapted private mesh communication protocol stack and can join an ad hoc network composed of multiple mesh intercom devices as a legitimate node. It not only supports low-latency multi-hop routing forwarding with other mesh nodes, but also has group broadcasting capabilities. It can inject converted audio data into the mesh network and simultaneously listen to and receive group voice data from other nodes in the mesh network.

[0026] The control module 113 can be a microcontroller (MCU), a digital signal processor (DSP), or an application-specific integrated circuit (ASIC). When the first audio data is received, the control module 113 performs encoding and decoding conversion operations, re-encapsulating it into a Mesh network-compatible format. The control module internally runs a digital mixing algorithm, which performs amplitude scaling and superposition calculations on the acquired local microphone audio data and the second audio data received from the Mesh network in real time to generate the final mixed audio stream for transmission back.

[0027] In one specific implementation, the Bluetooth communication module 111 is connected to the control module 113 via an I2S bus or other internal audio interface. The Mesh communication module 112 is connected to the control module 113 via an I2S bus.

[0028] The Bluetooth intercom device 120 can be a wireless voice communication terminal that supports standard Bluetooth communication protocols, such as HFP / HSP audio profiles. The Bluetooth intercom device 120 typically uses a traditional star topology or point-to-point connection method, enabling it to establish a standard Bluetooth audio link with conventional smartphones, Bluetooth headsets, or bridging devices 110. Due to limitations in its underlying protocol, the Bluetooth intercom device 120 itself cannot directly join and participate in group communication within a multi-hop mesh network.

[0029] Mesh intercom device 130 is a self-organizing wireless voice communication terminal built on a proprietary Mesh protocol. Mesh intercom device 130 acts as an independent node in the network, supporting a multi-hop relay mechanism. It can automatically network with other Mesh intercom devices without a central base station, enabling low-latency one-to-many or many-to-many group voice communication. Due to the use of a manufacturer-defined proprietary Mesh protocol, communication barriers typically exist between Mesh intercom devices of different brands or models, preventing direct native interoperability with Bluetooth intercom device 120.

[0030] Further, please refer to Figure 2 , Figure 2 This illustration shows a flowchart of a method for interoperating between a Bluetooth intercom device and a Mesh intercom device according to an embodiment of this application. This method can be applied to the aforementioned bridging device, which includes a Bluetooth communication module, a Mesh communication module, and a control module. Figure 2 As shown, the method may include steps 210 to 240.

[0031] In step 210, a Bluetooth audio link is established with the Bluetooth intercom device via the Bluetooth communication module to receive the first audio data transmitted from the Bluetooth intercom device via the Bluetooth audio link.

[0032] The first audio data can be the raw uplink audio stream from the Bluetooth intercom device. In one specific implementation, the first audio data is a digital audio data packet generated by the Bluetooth intercom device after collecting the user's voice signal through its built-in acoustic sensor (e.g., microphone), undergoing analog-to-digital conversion and basic encoding of the Bluetooth protocol stack. The first audio data is transmitted to the Bluetooth communication module of the bridging device in the form of a data packet through the established Bluetooth audio link between the Bluetooth communication module and the Bluetooth intercom device.

[0033] It is worth noting that the initial audio data typically uses the audio format specified by the Bluetooth standard, which is not yet compatible with the transmission protocol of Mesh networks. Therefore, the control module needs to parse and convert the data in order to broadcast it on the Mesh network.

[0034] The Bluetooth audio link is a synchronous connection-oriented link. The Bluetooth communication module and the Bluetooth intercom device reserve a dedicated physical channel in a preset fixed time slot to transmit real-time voice streams without retransmission in a point-to-point symmetrical connection manner, thereby minimizing transmission latency.

[0035] Bluetooth audio links can also be enhanced synchronous connection-oriented links. In addition to reserving fixed time slots, the Bluetooth communication module also configures a retransmission window after the fixed time slots. When an abnormality is detected in the first audio data transmission, the retransmission window is used to retransmit the data a limited number of times, which improves the integrity and anti-interference capability of audio data while maintaining low latency characteristics.

[0036] Once the Bluetooth audio link is established, a dedicated audio transmission channel is formed between the physical and logical link layers. The Bluetooth communication module uses frequency hopping spread spectrum technology to quickly switch between multiple channels in the 2.4GHz band, carrying real-time pulse code modulation voice data streams. This ensures that subsequent first audio data can be transmitted between the bridging device and the Bluetooth intercom device in a low-latency and highly reliable manner, effectively avoiding voice interruptions or popping sounds caused by signal interference.

[0037] Therefore, a seamless connection between bridging devices and Bluetooth intercom devices can be achieved through the Bluetooth communication module. There is no need to modify the hardware of existing Bluetooth intercom devices or crack their proprietary protocols. High-quality first audio data can be obtained simply through the standard Bluetooth audio link, which greatly reduces system costs and improves compatibility and scalability.

[0038] In step 220, group communication is conducted with the Mesh intercom devices in the private Mesh intercom network through the Mesh communication module to receive the second audio data transmitted from the Mesh intercom devices.

[0039] The second audio data can be a downlink group voice stream originating from the private Mesh intercom network. When a Mesh intercom device in the private Mesh intercom network initiates a group call or performs multi-hop relay forwarding, it generates digital audio data packets that conform to the private Mesh protocol specification. The second audio data is these group audio streams generated by other nodes in the network and transmitted to this bridging device via wireless broadcast or routing.

[0040] Unlike the first audio data mentioned above, the second audio data usually carries remote group voice information in a multi-party collaborative scenario. After receiving the second audio data, the control module will decapsulate it and send it to the digital mixer for fusion processing with the locally acquired audio data.

[0041] In some implementations, the Mesh communication module loads and runs a private Mesh communication protocol stack compatible with the private Mesh intercom network. The bridging device uses the Mesh communication module to send network access requests to surrounding devices or scan beacons within the network to discover and identify active Mesh intercom devices. Upon receiving a response from a legitimate Mesh node, the Mesh communication module executes the handshake and authentication process of the private protocol. After successful authentication, the bridging device is dynamically assigned a network address and a corresponding security key, thus officially joining the private Mesh intercom network as a legitimate node.

[0042] After completing the network registration, the Mesh communication module starts the group communication mode. The Mesh communication module continuously listens to specific group channels or logical channels, and captures and receives the second audio data transmitted from the Mesh intercom devices in the network in real time. The Mesh communication module also has the ability to package the processed first audio data according to the same private protocol format and inject it into the private Mesh intercom network through multi-hop routing or network-wide broadcasting, thereby realizing bidirectional group communication.

[0043] This demonstrates that the communication barrier between the standard Bluetooth protocol and the proprietary Mesh protocol has been successfully broken down through the Bluetooth and Mesh communication modules. By integrating the bridging device as a legitimate node into the proprietary Mesh intercom network, it can capture and receive secondary audio data from multiple Mesh terminals in real time. This allows Bluetooth users, who were previously limited to point-to-point communication, to seamlessly participate in many-to-many Mesh team collaboration, greatly enhancing the collaborative capabilities of cross-network devices. More specifically: In step 230, in response to receiving the first audio data, the control module converts the first audio data into a Mesh network-compatible format to obtain processed first audio data, and broadcasts the processed first audio data to the Mesh intercom device through the Mesh communication module.

[0044] The processed first audio data can be a target audio stream that has undergone protocol conversion and format encapsulation, enabling it to be recognized and forwarded by a private Mesh intercom network. In one specific implementation, after acquiring the first audio data from the Bluetooth intercom device, the control module first decapsulates and decodes it to restore it to the original pulse code modulation data. Then, according to the communication protocol specifications of the private Mesh intercom network, the pulse code modulation data is re-encoded, for example, using a low bit rate encoding and decoding algorithm specific to the Mesh network, and the protocol header information required for Mesh network transmission is added, such as network address, group identifier, sequence number, and checksum. Finally, it is encapsulated to generate a digital audio data packet that conforms to the Mesh air interface transmission standard, i.e., the processed first audio data.

[0045] The processed first audio data is fully compatible with the physical and link layer requirements of the Mesh network in terms of format, thus enabling efficient multi-hop relay and broadcast transmission between Mesh network nodes.

[0046] By reconstructing the format and encapsulating the protocol of the first audio data through the control module, the audio stream that could only be transmitted in the Bluetooth audio link is transformed into processed first audio data that can be recognized and routed by the Mesh network. This eliminates the underlying communication barrier between the Bluetooth protocol and the proprietary Mesh protocol, and also enables the voice information of the Bluetooth intercom device to be injected into the Mesh network with extremely low latency and received and played by all Mesh intercom devices in the network, truly realizing cross-standard two-way voice interoperability.

[0047] More specifically, in some implementations, the step of converting the first audio data into a Mesh network-compatible format via a control module to obtain processed first audio data may include the following steps: (1) Parse and obtain the source audio encoding format currently used in the first audio data; (2) Convert the first audio data from the source audio encoding format to the target audio encoding format adapted to the private Mesh intercom network to obtain the transcoded audio data; (3) According to the audio transmission protocol requirements currently used in the private Mesh intercom network, the transcoded audio data is frame-encapsulated to generate the processed first audio data.

[0048] When the control module receives the first audio data via the Bluetooth communication module, it recognizes that the first audio data is transmitted based on a standard Bluetooth audio profile, which typically carries a specific audio encoding identifier at its underlying layer. The control module can accurately extract the source audio encoding format currently used by the first audio data by reading the header information or configuration parameters from the negotiation phase. Examples of suitable formats include Continuously Variable Slope Decrement Modulation (CVSD) and Enhanced Wideband Voice Coding (mSBC).

[0049] After identifying the source audio encoding format, the control module uses a decoder that matches the source audio encoding format to decode and restore the first audio data, converting it into an uncompressed raw pulse code modulation digital baseband signal. Then, based on the bandwidth limitations and audio quality requirements of the private Mesh intercom network, the module uses the network's preset target audio encoding algorithm, such as low-bit-rate AAC encoding optimized for Mesh self-organizing networks or other proprietary narrowband voice encoding, to re-compress and encode the raw pulse code modulation digital baseband signal, thereby generating transcoded audio data that conforms to the air interface transmission characteristics of the Mesh network.

[0050] After obtaining the transcoded audio data, a necessary protocol control header is added to the front of the transcoded audio data. The control header must contain at least the target group address, node sequence number, timestamp, and cyclic redundancy check field. At the same time, according to the maximum transmission unit limit of the Mesh network, the audio data with the protocol header is fragmented or padded and aligned. Finally, the processed first audio data that can be correctly received, parsed, and routed by other nodes in the Mesh network is generated.

[0051] Furthermore, in some embodiments, the interoperability method between the Bluetooth intercom device and the Mesh intercom device may further include the following steps: (1) During the process of receiving the first audio data, the control module continuously performs voice activity detection on the received first audio data to obtain the detection result; (2) If the detection result indicates that speech activity has been detected, then continue to execute the step "parse the first audio data and obtain the source audio encoding format currently used by the first audio data"; (3) If the detection result indicates that no voice activity was detected, then stop executing the step "parse the first audio data and obtain the source audio encoding format currently used by the first audio data", and stop broadcasting the processed first audio data to the Mesh intercom device.

[0052] While receiving the first audio data in real time via the Bluetooth communication link, the control module initiates voice activity detection in parallel. The control module analyzes the first audio data received in the buffer frame by frame, extracts the energy, zero-crossing rate or spectral features of the audio signal, and compares them with the preset noise floor threshold. Through continuous monitoring, the control module can determine in real time whether the current audio stream contains a valid human voice signal, thereby generating a binarized detection result representing whether there is voice input or only background noise.

[0053] When the detection result indicates the presence of voice activity, it is determined that a valid human voice exists. The control module determines that the user is speaking and triggers the subsequent cross-network forwarding process. At this time, the control module continues to run at full speed, parsing the first audio data, obtaining the source audio encoding format currently used by the first audio data, and performing subsequent transcoding and encapsulation operations in sequence. This ensures that the user's voice commands can be instantly converted into a format adapted to the Mesh network and seamlessly broadcast to the private Mesh intercom network, guaranteeing the continuity and real-time nature of group communication.

[0054] Conversely, if the detection result indicates that no voice activity was detected, it is determined that the current situation is only ambient background noise or a silent segment. The control module immediately suspends or skips subsequent high-power processing steps, stops parsing the first audio data, obtains the source audio encoding format currently used by the first audio data, and performs subsequent transcoding operations. At the same time, the control module controls the Mesh communication module to stop broadcasting the processed first audio data to the Mesh intercom device or only send very short control frames to maintain the link. This effectively avoids forwarding meaningless background noise to the Mesh network, thereby significantly reducing the air interface occupancy rate of the Mesh network, reducing co-channel interference, and reducing the overall power consumption of the bridging device.

[0055] In step 240, in response to receiving local audio data and second audio data, the local audio data and second audio data are digitally mixed by the control module to obtain a mixed audio stream, and the mixed audio stream is transmitted back to the Bluetooth intercom device through the Bluetooth communication module.

[0056] Local audio data can be audio signals locally collected by the bridging device or a Bluetooth intercom device directly connected to it. When a user picks up sound through the microphone built into the Bluetooth intercom device or bridging device, the resulting digital audio stream generated after analog-to-digital conversion is the local audio data.

[0057] Local audio data represents the real-time voice input of the current nearby user and is a key component of two-way full-duplex intercom.

[0058] The mixed audio stream can be the target audio data after digital signal processing and fusion. The control module performs sampling rate alignment and amplitude normalization processing on the second audio data from the Mesh network and the local audio data in the digital domain, and then combines the two signals into a single audio stream through a digital mixing algorithm.

[0059] The mixed audio stream fully preserves the group call content within the Mesh network as well as the local users' speech content, ensuring the integrity and consistency of the listening experience.

[0060] By digitally mixing local audio data with secondary audio data, users of Bluetooth walkie-talkies can clearly hear their teammates' replies in the Mesh network while also hearing their own voice in real time. This processing method simulates the sidetone effect of traditional walkie-talkies, preventing users from unconsciously raising their volume due to not being able to hear themselves, and greatly enhancing the naturalness and comfort of cross-network communication.

[0061] Specifically, in some implementations, the step of digitally mixing local audio data and second audio data through a control module to obtain a mixed audio stream may further include the following steps: (1) Obtain preset mixing weight parameters, which include at least a first weight value for representing local speech priority and a second weight value for representing group communication priority; (2) Based on the first weight value and the second weight value, the sampling points of the local audio data and the sampling points of the second audio data are weighted and superimposed in the time domain to obtain the superimposed audio data; (3) Perform amplitude limiting and smoothing on the superimposed audio data and output the mixed audio stream.

[0062] Before performing the mixing operation, the control module first reads the current preset mixing weight parameters from the non-volatile memory. To prevent the total volume after mixing from being too high, the sum of the first weight value and the second weight value can be set to less than or equal to 1. Alternatively, in scenarios where it is necessary to maintain the original volume, the sum of the first weight value and the second weight value can be greater than 1, and this can be used in conjunction with the subsequent limiting algorithm.

[0063] The first weight value corresponds to the locally acquired voice signal and is used to control the loudness of the user's own voice to ensure vocal feedback in noisy environments. The second weight value corresponds to the received group communication signal and is used to control the proportion of remote teammates' voices in the mixed stream. In a specific implementation, the first and second weight values ​​can be fixed constants, for example, both 0.5, or they can be variables that are dynamically adjusted according to the ambient noise level, thereby achieving fine-grained control over the priority of different audio sources.

[0064] After obtaining the first and second weight values, the control module synchronizes and aligns the two digital audio streams, and performs a weighted summation operation on a sample-by-sample basis in the time domain. It extracts the local audio data sample value and the second audio data sample value at the same moment, multiplies them by the corresponding first and second weight values ​​respectively, and adds them together to obtain the superimposed audio data. This achieves lossless fusion of local speech and group speech in the digital domain, ensuring that users can clearly hear group commands while retaining necessary local sidetone feedback, and avoiding the problem of one channel's sound being completely masked by another channel.

[0065] Because the instantaneous amplitude of the superimposed audio signals may exceed the maximum quantization range of the digital audio system, clipping distortion may occur. Therefore, the control module performs amplitude limiting and smoothing processing on the superimposed audio data, monitors the amplitude of the superimposed data in real time, and when the amplitude exceeds a preset threshold, it uses hard limiting to clamp it to the maximum allowable value, or uses a soft limiting algorithm to smooth the waveform peaks to eliminate high-frequency harmonic distortion. This ensures that the dynamic range of the output mixed audio stream is strictly controlled within the range allowed by the Bluetooth transmission protocol, effectively preventing popping or distortion caused by excessive volume, and significantly improving the audio clarity and listening comfort of cross-network intercom.

[0066] Furthermore, in some embodiments, the interoperability method between the Bluetooth intercom device and the Mesh intercom device may further include the following steps: (1) Maintain independent first-in-first-out audio buffer queues for local audio data and second audio data respectively, and attach a collection timestamp to each frame of audio data when writing to the first-in-first-out audio buffer queue; (2) Read the timestamp of the first-in-first-out audio buffer queue and calculate the clock deviation between the local audio data and the second audio data; (3) When the clock deviation value exceeds the preset alignment threshold, perform frame dropping operation on the audio data with an earlier timestamp, or perform zero padding operation on the audio data with a later timestamp, until the clock deviation value is less than the preset alignment threshold. (4) Read audio frames of equal length synchronously from the first-in-first-out audio buffer queue and send them to the control module to execute the steps to obtain the preset mixing weight parameters.

[0067] To eliminate the differences in transmission latency and processing time between the two heterogeneous audio streams, the control module allocates and maintains independent circular first-in-first-out audio buffer queues in memory for the local audio data and the second audio data, respectively.

[0068] When a new audio frame is written to the corresponding circular first-in-first-out audio buffer queue, the control module uses a high-precision hardware timer to stamp the frame with a precise acquisition timestamp. This timestamp represents the actual generation time of the audio data in the frame, providing a unified absolute time reference for subsequent multi-channel audio timing alignment.

[0069] Before performing the mixing operation, the control module reads the timestamps of the current local audio data frame to be processed and the second audio data frame in real time, and calculates the clock deviation value between them. Using the clock deviation value, the control module can accurately determine which audio data is in a leading state and which is in a lagging state at the current moment, thus providing data support for subsequent dynamic compensation strategies.

[0070] If the calculated clock deviation exceeds the preset alignment threshold, for example, exceeding the tolerance range of a few milliseconds, it indicates that the two audio channels have become significantly out of sync. At this time, the control module performs a frame dropping operation on the audio data with the earlier timestamp, that is, it directly discards one or more frames of historical data from the corresponding first-in-first-out audio buffer queue, so that it can quickly catch up to the current time point; The control module performs zero-padding for audio data with a later timestamp, which means inserting a silent frame into the current audio stream to artificially extend the playback duration of that audio stream, waiting for another audio stream to catch up.

[0071] The above frame dropping or zero-padding operations will continue to be executed in a loop until the recalculated clock deviation value is less than the preset alignment threshold, thereby achieving precise time alignment between the two audio streams.

[0072] After completing the timing alignment described above, the control module synchronously reads audio frames of equal length from the local FIFO audio buffer queue and the second audio FIFO audio buffer queue, respectively, according to a fixed reading rhythm. Since the two audio data streams are now strictly aligned on the time axis, the audio frames sent to the subsequent mixing module maintain a high degree of consistency in phase and timing. This not only effectively avoids comb filtering effects or echo interference caused by asynchronous mixing but also ensures that the final mixed audio stream has extremely high clarity and naturalness.

[0073] Therefore, time-stamp-based timing alignment effectively ensures the sound quality and continuity of multiple audio streams during digital mixing within the control module. However, in actual outdoor or complex electromagnetic environments, the wireless physical link between the Bluetooth communication module and the Bluetooth intercom device is still inevitably affected by factors such as signal obstruction and co-channel interference, resulting in stuttering or intermittent audio transmission. To further ensure high reliability and user experience in cross-network interoperability, in some embodiments, the interoperability method between the Bluetooth intercom device and the Mesh intercom device may further include the following steps: (1) The link quality parameters of the Bluetooth audio link are collected in real time through the Bluetooth communication module. The link quality parameters include at least one of the received signal strength indication and bit error rate. (2) In response to the link quality parameters being lower than the preset quality threshold, the control module reduces the current Bluetooth audio encoding bitrate of the Bluetooth communication module to the corresponding downgraded bitrate level, and / or reduces the sampling rate to the corresponding downgraded sampling rate level. (3) In response to the link quality parameters recovering to above the preset quality threshold, the bit rate or sampling rate of the Bluetooth audio encoding is restored to the default encoding parameters through the control module.

[0074] During the audio data transmission and reception process, the Bluetooth communication module continuously monitors the status of the underlying physical layer and baseband layer. The received signal strength indicator characterizes the electromagnetic energy level of the current Bluetooth link, reflecting the distance between devices and the presence of obstacles. The bit error rate (BER) measures the degree of data packet corruption during transmission, reflecting channel degradation conditions such as co-channel interference or multipath fading.

[0075] The control module reads the hardware registers inside the Bluetooth chip to obtain at least one of the link quality parameters in real time, thereby accurately assessing the health of the current wireless channel.

[0076] When the control module determines that the current link quality parameters are lower than the preset quality threshold, for example, if the received signal strength is weaker than -85dBm or the bit error rate exceeds the fault tolerance limit, it indicates that the current wireless environment can no longer stably support the existing high-bandwidth audio stream. According to the preset degradation strategy table, the control module will adjust the current Bluetooth audio encoding parameters of the Bluetooth communication module. For example, the encoding bitrate can be lowered to the corresponding degradation bitrate level, such as from 320kbps to 128kbps, to reduce the data throughput per unit time; or the sampling rate can be lowered to the corresponding degradation sampling rate level, such as from 48kHz to 16kHz, to reduce the baseband data generation rate.

[0077] After reducing the encoding bitrate or sampling rate, the Bluetooth communication module continues to track the link quality parameters in real time. When the link quality parameters are detected to have recovered to above the preset quality threshold and maintained for a stable observation period, it indicates that the wireless channel has restored normal transmission capability. The control module will automatically de-degrade the status and smoothly restore the Bluetooth audio encoding bitrate or sampling rate to the default initial encoding parameters.

[0078] In more complex private mesh intercom networks, audio data often needs to undergo multi-hop forwarding through multiple relay nodes to reach the target receiver. Due to the highly dynamic self-organizing nature of mesh networks, changes in the physical location of nodes, channel congestion, and co-channel interference can all lead to communication bottlenecks or spikes in latency on specific forwarding paths. To further ensure the efficiency and resilience of cross-network interoperability, and to ensure that the voice stream always selects the optimal channel for transmission in the complex and ever-changing mesh network, in some implementations, the interoperability method between the Bluetooth intercom device and the mesh intercom device may further include the following steps: (1) Periodically send probe frames to the Mesh intercom device through the Mesh communication module, and generate a network topology table based on the hop count information and channel occupancy status of each node recorded in the response frame returned by the Mesh intercom device. (2) The control module calculates the hop count and channel occupancy status of each forwarding path in the private Mesh intercom network by weighting the network topology table, and selects the forwarding path with the lowest weighted score as the current forwarding path. (3) The control module adaptively adjusts the coding rate and frame length used when transcoding the first audio data according to the hop count of the current forwarding path and the channel occupancy status to obtain the processed first audio data; (4) Control the Mesh communication module to broadcast the processed first audio data to the Mesh intercom device along the current forwarding path through the control module; (5) When the channel occupancy status of the current forwarding path exceeds the preset congestion threshold, the control module caches the processed first audio data, selects a new forwarding path from the network topology table, and sends the cached processed first audio data through the new forwarding path.

[0079] When a device is connected to the network or maintaining a connection, the Mesh communication module sends probe frames to neighboring nodes in the private Mesh intercom network via broadcast or multicast. Upon receiving a probe frame, the Mesh intercom device reads the routing information stored in its own routing table and sends a response frame containing the hop count to the target node in the network and the current channel occupancy status of the radio frequency channel, such as the channel idle assessment result or the channel busy ratio.

[0080] The control module parses the received response frames, extracts the identifiers, hop counts, and channel status information of each node, and uses this information to construct or update the local network topology table. The network topology table maps the connection relationships and link health of each node in the current private Mesh intercom network in real time, providing data support for subsequent routing decisions.

[0081] Based on the network topology table, the control module traverses all potential forwarding paths from the current Bluetooth intercom device to the target Mesh intercom device. For each potential forwarding path, the control module calculates a score according to a preset weighted calculation formula.

[0082] In one specific implementation, the preset weighted calculation formula can use the number of hops and the channel occupancy rate as two core variables and assign them corresponding weight coefficients. For example, the channel occupancy status can be given a higher weight to prioritize avoiding interference.

[0083] The lower the calculated weighted score, the lower the transmission delay and the lower the probability of interference for that path. The control module will compare the weighted scores of all paths and finally select the forwarding path with the lowest weighted score, marking it as the current forwarding path to carry the subsequent audio data transmission tasks.

[0084] After determining the current forwarding path, the control module will also perform adaptive transcoding on the first audio data based on the specific link characteristics of that path. Since different hop counts mean different transmission delays, and different channel occupancy states mean different available bandwidths, fixed encoding parameters may not be able to adapt to dynamically changing network environments.

[0085] The control module queries the preset bitrate adaptation strategy table and determines the optimal coding bitrate and frame length based on the total number of hops and average channel occupancy of the current forwarding path. For example, when the channel occupancy of the current forwarding path is detected to be high, the control module will select a lower coding bitrate and a shorter frame length to reduce the size of the data packets transmitted in a single transmission and reduce the risk of packet loss; conversely, it will select a higher coding bitrate to ensure audio quality.

[0086] The control module packages the processed first audio data into a Mesh network data frame and controls the Mesh communication module to transmit it via the radio frequency front end. During transmission, the Mesh communication module strictly follows the routing table entries of the current forwarding path, broadcasting and forwarding the data frame hop-by-hop. After receiving the data frame, the intermediate node in the network continues to forward it to the next hop according to the routing information in the frame header, until the processed first audio data is successfully delivered to the target Mesh intercom device.

[0087] To ensure robust communication, the control module continuously monitors the channel status of the current forwarding path during data transmission. When the channel occupancy of the current forwarding path suddenly increases and exceeds a preset congestion threshold, for example, due to sudden external Wi-Fi interference or a surge in network traffic, it indicates that the current path is no longer suitable for transmitting real-time audio.

[0088] At this point, the control module immediately stores the processed first audio data to be sent temporarily in the data buffer to prevent the data from being directly discarded and causing the voice to be interrupted; and immediately re-queries the network topology table to avoid the currently congested nodes or links, recalculates and selects a new forwarding path, and controls the Mesh communication module to quickly send out the audio data accumulated in the buffer through the new forwarding path.

[0089] Please see Figure 3 , Figure 3 The diagram shows a structural schematic of a bridging device provided in an embodiment of this application. The bridging device 110 in this application may include one or more of the following components: a processor 310, a memory 320, and one or more application programs. The one or more application programs may be stored in the memory 320 and configured to be executed by one or more processors 310. The one or more application programs are configured to execute the interoperability method between the Bluetooth intercom device and the Mesh intercom device as described in the foregoing method embodiments.

[0090] Processor 310 may include one or more processing cores. Processor 310 connects various parts within the bridging device 110 using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 320, and by calling data stored in memory 320. Optionally, processor 310 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). Processor 310 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the displayed content; and the modem handles wireless communication. It is understood that the modem may also not be integrated into processor 310 and may be implemented separately using a communication chip.

[0091] The memory 320 may include random access memory (RAM) or read-only memory (ROM). The memory 320 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 320 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for implementing at least one function, instructions for implementing the various method embodiments described below, etc. The data storage area may also store data created by the bridging device 110 during use.

[0092] Please see Figure 4 , Figure 4 The diagram illustrates the structure of a computer-readable storage medium 400 provided in an embodiment of this application. The computer-readable storage medium 400 stores program code, which can be called by a processor to execute the Bluetooth intercom device and Mesh intercom device interoperability method described in the above method embodiment.

[0093] The computer-readable storage medium 400 may be an electronic memory such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM. Optionally, the computer-readable storage medium 400 includes a non-transitory computer-readable storage medium. The computer-readable storage medium 400 has storage space for program code 410 that performs any of the method steps described above. This program code can be read from or written to one or more computer program devices. The program code 410 may be compressed, for example, in a suitable form.

[0094] Please see Figure 5 , Figure 5 The diagram illustrates the structure of a computer program product according to an embodiment of this application. The computer program product 500 includes a computer program 510 stored on a computer-readable storage medium. The computer program 510 includes program instructions. When the program instructions are executed by the computer, the computer performs the above-described method for interoperating between the Bluetooth intercom device and the Mesh intercom device.

[0095] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for interoperability between a Bluetooth intercom device and a Mesh intercom device, characterized in that, Applied to a bridging device, the bridging device including a Bluetooth communication module, a Mesh communication module, and a control module, the method includes: The Bluetooth communication module establishes a Bluetooth audio link with the Bluetooth intercom device to receive first audio data transmitted from the Bluetooth intercom device through the Bluetooth audio link. The Mesh communication module communicates with the Mesh intercom devices in the private Mesh intercom network to receive second audio data transmitted from the Mesh intercom devices. In response to receiving the first audio data, the control module converts the first audio data into a Mesh network-compatible format to obtain processed first audio data, and broadcasts the processed first audio data to the Mesh intercom device through the Mesh communication module. In response to receiving local audio data and the second audio data, the control module performs digital mixing on the local audio data and the second audio data to obtain a mixed audio stream, and transmits the mixed audio stream back to the Bluetooth intercom device through the Bluetooth communication module. The method further includes: The Mesh communication module periodically sends probe frames to the Mesh intercom device, and generates a network topology table based on the hop count information and channel occupancy status of each node recorded in the response frames returned by the Mesh intercom device. The control module performs a weighted calculation of the hop count information and channel occupancy status of each forwarding path in the private Mesh intercom network based on the network topology table, and selects the forwarding path with the lowest weighted score as the current forwarding path. The control module adaptively adjusts the coding rate and frame length used when transcoding the first audio data based on the hop count information and channel occupancy status of the current forwarding path, thereby obtaining the processed first audio data. The control module controls the Mesh communication module to broadcast the processed first audio data to the Mesh intercom device along the current forwarding path. When the channel occupancy status of the current forwarding path exceeds a preset congestion threshold, the control module caches the processed first audio data, selects a new forwarding path from the network topology table, and sends the cached processed first audio data through the new forwarding path.

2. The method for interoperability between a Bluetooth intercom device and a Mesh intercom device according to claim 1, characterized in that, The step involves converting the first audio data into a Mesh network-compatible format via the control module to obtain processed first audio data, including: Parse and obtain the source audio encoding format currently used in the first audio data; The first audio data is converted from the source audio encoding format to the target audio encoding format adapted to the private Mesh intercom network to obtain the transcoded audio data. According to the audio transmission protocol currently used by the private Mesh intercom network, the transcoded audio data is frame-encapsulated to generate the processed first audio data.

3. The method for interoperating between a Bluetooth intercom device and a Mesh intercom device according to claim 2, characterized in that, The method further includes: During the process of receiving the first audio data, the control module continuously performs voice activity detection on the received first audio data to obtain detection results; If the detection result indicates that voice activity has been detected, then the step of parsing and obtaining the source audio encoding format currently used by the first audio data continues; If the detection result indicates that no voice activity was detected, the steps of parsing and obtaining the source audio encoding format currently used by the first audio data are stopped, and the broadcast of the processed first audio data to the Mesh intercom device is stopped.

4. The method for interoperating between a Bluetooth intercom device and a Mesh intercom device according to claim 1, characterized in that, The step involves digitally mixing the local audio data and the second audio data using the control module to obtain a mixed audio stream, including: Obtain preset mixing weight parameters, wherein the mixing weight parameters include at least a first weight value for characterizing local speech priority and a second weight value for characterizing group communication priority; Based on the first weight value and the second weight value, the sampling points of the local audio data and the sampling points of the second audio data are weighted and superimposed in the time domain to obtain the superimposed audio data; The superimposed audio data is subjected to amplitude limiting and smoothing processing to output the mixed audio stream.

5. The method for interoperating between a Bluetooth intercom device and a Mesh intercom device according to claim 4, characterized in that, The method further includes: Independent first-in-first-out (FIFO) audio buffer queues are maintained for the local audio data and the second audio data respectively, and a collection timestamp is appended to each frame of audio data when writing to the FIFO audio buffer queue; Read the timestamp of the first-in-first-out audio buffer queue and calculate the clock offset value between the local audio data and the second audio data; When the clock deviation value exceeds the preset alignment threshold, a frame dropping operation is performed on the audio data with an earlier timestamp, or a zero-padding operation is performed on the audio data with a later timestamp, until the clock deviation value is less than the preset alignment threshold. Audio frames of equal length are synchronously read from the first-in-first-out audio buffer queue and sent to the control module to execute steps to obtain preset mixing weight parameters.

6. The method for interoperating between a Bluetooth intercom device and a Mesh intercom device according to claim 1, characterized in that, The method further includes: The Bluetooth communication module collects the link quality parameters of the Bluetooth audio link in real time, and the link quality parameters include at least one of received signal strength indication and bit error rate; In response to the link quality parameter being lower than a preset quality threshold, the control module reduces the current Bluetooth audio encoding bitrate of the Bluetooth communication module to the corresponding downgraded bitrate level, and / or reduces the sampling rate to the corresponding downgraded sampling rate level. In response to the link quality parameters recovering to or above the preset quality threshold, the control module restores the bitrate or sampling rate of the Bluetooth audio encoding to the default encoding parameters.

7. A bridging device, characterized in that, include: One or more processors; Memory; One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the one or more processors, the one or more applications being configured to perform the Bluetooth intercom device and Mesh intercom device interoperability method as described in any one of claims 1-6.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores program code, which can be called by a processor to execute the interoperability method between the Bluetooth intercom device and the Mesh intercom device as described in any one of claims 1-6.

9. A computer program product, characterized in that, The computer program product includes a computer program stored on a computer-readable storage medium, the computer program including program instructions that, when executed by a computer, cause the computer to perform the interoperability method between the Bluetooth intercom device and the Mesh intercom device as described in any one of claims 1-6.