Intelligent visual reminding method for audio state of wireless collar clip microphone receiving end

Abstract

The invention belongs to the technical field of audio signal processing and man-machine interaction, and particularly relates to an intelligent visual reminding method for the audio state of a wireless collar clip microphone receiving end, which comprises a state monitoring and LED driving logic system for strictly synchronizing USB audio affairs, and an intelligent visual reminding system for the audio state of a wireless collar clip microphone receiving end through a double-LED flicker mode with differentiated frequencies. Independent, real-time and unambiguous visual representation of two core audio transactions of recording and broadcasting is realized, a bivariate differential monitoring mechanism based on USB transaction triggering is constructed in the receiving end of the wireless collar clamp microphone, and a differential frequency flicker strategy of two independent controllable LEDs is combined, so that the wireless collar clamp microphone can be used for monitoring the audio frequency of the wireless collar clamp microphone. Accurate, real-time and localized visual reminding of recording and broadcasting states is realized.

Description

Technical Field

[0001] This invention belongs to the field of audio signal processing and human-computer interaction technology, specifically a method for intelligent visual reminder of audio status of a wireless lavalier microphone receiver. Background Technology

[0002] With the profound evolution of the mobile internet ecosystem and the widespread adoption of short video content creation, wireless lavalier microphones, as key peripherals for improving audio capture quality, have become deeply integrated into the daily creative workflows of smartphone users. These devices typically employ a split architecture, consisting of a transmitter worn on the user's collar and a receiver connected to the phone via a physical interface (such as Type-C), working together to form a complete wireless audio transceiver system. In typical application scenarios, the receiver not only stably transmits the voice signal captured by the transmitter to the phone to complete the recording task, but also receives audio data streams from the phone for local playback or transmission back to the transmitter, thus supporting complex audio operations such as background music overlay and real-time monitoring. This technology effectively solved the mobility constraints of wired microphones in its early stages and significantly improved the flexibility and professionalism of audio recording in mobile scenarios, thus quickly becoming a standard configuration for content creators.

[0003] However, as users' demands for creative efficiency and operational certainty continue to rise, the inherent shortcomings of existing wireless lavalier microphone systems in terms of human-computer interaction are becoming increasingly apparent. Specifically, current mainstream products generally rely solely on mobile phone screen displays or headphone monitoring as the only means of audio status feedback, while the receiver itself lacks an independent and intuitive status indication mechanism. Furthermore, when users are unable to view the screen or are not wearing monitoring equipment, such as while walking and filming outdoors, operating other devices with both hands, or coordinating multiple cameras, their perception of whether the system is in a valid recording or unexpected playback state is completely "black box." The reason for this is that the hardware design of existing receivers often only retains the most basic power indicator light, without building any localized perception feedback channels for the dynamic behavior of audio tasks. Moreover, even if some high-end models introduce simple always-on / off status lights, the lack of ability to distinguish between the two core tasks of recording and playback makes it difficult to provide semantically discernible operational guidance.

[0004] The aforementioned limitations do not stem from a single missing function, but rather from a structural disconnect between "state awareness" and "user interaction" within the existing technical architecture. On one hand, while the USB audio controller inside the receiver can accurately identify and process IN transactions (uploading recording data) and OUT transactions (downloading audio data) from the phone, this transaction information is typically encapsulated at the firmware level and not accessible to upper-layer interaction modules. On the other hand, to control cost and size, manufacturers generally do not integrate displays or complex audio-visual prompts into the receiver, preventing state information from being conveyed to the user in a low-cognitive-load manner. Consequently, this inherent contradiction is amplified dramatically in high-concurrency, high-uncertainty real-world usage environments: users may misjudge the recording status, resulting in the entire recording becoming silent and unusable, or unexpected background music output may disrupt the acoustic environment during silent recording. Crucially, in scenarios such as live streaming, interviews, and teaching, where audio continuity and controllability are critically demanding, operational errors caused by such state blind spots are often irreversible and have severe consequences.

[0005] Therefore, a method for intelligent visual alerts of audio status at a wireless lavalier microphone receiver is proposed to address the above issues. Summary of the Invention

[0006] This invention provides an intelligent visual alert method for audio status at a wireless lavalier microphone receiver, aiming to solve the technical problem in existing technologies where the lack of a localized, semantically clear status feedback mechanism prevents users from accurately judging the recording and playback status without relying on a mobile phone screen or monitoring device. To achieve the above-mentioned objective, this invention, based on existing hardware resources at the receiver, constructs a status monitoring and LED driving logic system that is strictly synchronized with USB audio transactions. Through a dual-LED flashing mode with differentiated frequencies, it achieves independent, real-time, and unambiguous visual representation of the two core audio transactions: recording and playback.

[0007] The physical structure of the wireless lavalier microphone receiver includes a printed circuit board assembly (PCBA) integrating the following core hardware modules: a first light-emitting diode (LED1), a second light-emitting diode (LED2), a central processing unit (CPU) with general purpose input / output (GPIO) control capabilities, and a physical interface compliant with the USB Type-C specification. LED1 and LED2 are both surface-mount red light-emitting diodes with a forward operating voltage of 2.1V and a maximum continuous forward current of 20mA. They are connected to two independent GPIO pins of the CPU via current-limiting resistors, allowing the CPU to independently control the on / off state of the two LEDs digitally. The Type-C interface is used to establish a physical connection with a smartphone, while also handling power transmission and high-speed data communication.

[0008] During system initialization, the receiving end is inserted into the corresponding port of the smartphone via the Type-C interface to establish a physical link. Subsequently, the smartphone initiates the standard USB device enumeration process. The receiving end responds to the host request, sequentially returning the device descriptor, configuration descriptor, interface descriptor, and endpoint descriptor. The interface descriptor explicitly declares that the device is a composite audio device conforming to the USB Audio Class 1.0 specification, containing one audio input interface and one audio output interface. The audio input interface is bound to an IN-direction bulk transfer endpoint for uploading voice data acquired by the transmitting end and processed by the receiving end; the audio output interface is bound to an OUT-direction bulk transfer endpoint for receiving background music or system audio data streams from the smartphone. After enumeration, the smartphone operating system registers two independent audio stream channels in the audio subsystem, corresponding to the recording path and playback path respectively, ensuring that subsequent audio transactions can be triggered through the standard USB transaction mechanism.

[0009] At the software logic level, the receiver firmware deploys two independent but structurally symmetrical status monitoring and LED driving modules in the CPU, corresponding to OUT transactions (audio output) and IN transactions (recording), respectively. Each module contains a 32-bit unsigned integer counter variable and its corresponding backup variable, and the transaction activity status is determined through a difference comparison mechanism in the main loop.

[0010] For OUT transactions, the firmware defines global variables OUT_FLAG and OUT_FLAG_BK in the data processing interrupt service routine of the audio output interface, both initially set to zero. Whenever the smartphone sends a valid OUT transaction data packet to the receiving end, a batch transmission completion interrupt is triggered at the OUT endpoint. The interrupt service routine executes the operation OUT_FLAG = OUT_FLAG + 1, incrementing the variable value. The CPU main loop executes the status detection logic at fixed intervals (no more than 10 milliseconds): first, it reads the current OUT_FLAG and OUT_FLAG_BK values; if they are not equal, it determines that there is an active audio output transaction, and then calls the LED driver function, setting the GPIO pin of LED1 high for 100 milliseconds and then low for 100 milliseconds, forming a square wave drive signal with a period of 200 milliseconds and a frequency of 5 Hz, causing LED1 to blink regularly; then, the current OUT_FLAG value is assigned to OUT_FLAG_BK, completing the status synchronization. If OUT_FLAG equals OUT_FLAG_BK, then driving LED1 is stopped, keeping it off. This mechanism ensures that LED1 blinks only when there is actual audio data stream output, and the blinking frequency is strictly locked at 5 Hz.

[0011] For IN transactions, the firmware defines global variables IN_FLAG and IN_FLAG_BK in the data preparation logic of the audio input interface, with initial values ​​of zero. Each time the receiving end uploads a valid IN transaction data packet to the smartphone, completing a batch transmission of recording data, the firmware executes the operation IN_FLAG = IN_FLAG + 1 in the corresponding transmission completion callback function. The CPU main loop synchronously performs IN transaction status detection: comparing IN_FLAG and IN_FLAG_BK; if they are not equal, it is determined that the recording transaction is active, and immediately drives the GPIO pin of LED2 to output a square wave signal with a period of 500 milliseconds, i.e., a high level for 250 milliseconds followed by a low level for 250 milliseconds, forming a 2 Hz blinking frequency; then, the IN_FLAG value is written to IN_FLAG_BK to complete synchronization. If the two are equal, the LED2 driver is turned off, extinguishing it. Thus, the 2 Hz blinking of LED2 uniquely indicates that recording is in progress.

[0012] When a smartphone simultaneously initiates recording and audio playback operations, such as in a live streaming scenario where both user voice is captured and background music is overlaid, IN and OUT transactions will occur concurrently. In this case, the CPU main loop sequentially completes independent comparisons of two sets of variables and LED driving decisions within a single execution cycle: first, it processes the OUT transaction state, determining whether to drive LED1 at 5 Hz based on the difference between OUT_FLAG and OUT_FLAG_BK; then, it processes the IN transaction state, determining whether to drive LED2 at 2 Hz based on the difference between IN_FLAG and IN_FLAG_BK. Because the two sets of logic use completely separate variables and GPIO resources, and the main loop execution cycle is much shorter than the minimum time unit of any blinking cycle (100 milliseconds), the blinking behavior of LED1 and LED2 does not interfere with each other, each maintaining its preset frequency. Users can clearly distinguish the two blinking modes with the naked eye: fast blinking (5Hz) indicates audio playback, slow blinking (2Hz) indicates recording, and the simultaneous presence of both indicates that the system is in a composite operating mode.

[0013] The LED driving function employs a non-blocking timing control mechanism, specifically implemented as follows: In each main loop, if it is necessary to start the blinking of an LED, the firmware records the current system tick count as the start timestamp and sets the target blinking period; in subsequent main loops, the difference between the current tick count and the start timestamp is continuously compared; when the high-level duration threshold is reached, the GPIO level is switched and the start timestamp is updated; when the complete cycle is reached, the status flag is reset. This mechanism avoids main loop blocking caused by using delay functions, ensuring the real-time performance and concurrency of transaction monitoring and LED control.

[0014] Furthermore, to prevent overflow and wrapback of the 32-bit counter variable under extremely long continuous operation, the firmware performs a boundary check before each increment: if the current value of OUT_FLAG or IN_FLAG is equal to 0xFFFFFFFF, it is reset to 0 after the increment operation, and OUT_FLAG_BK or IN_FLAG_BK is also reset synchronously. Since the detection period of the main loop is much shorter than the transaction trigger interval, even if wrapback occurs, the variable difference can still correctly reflect the transaction activity status and will not lead to misjudgment.

[0015] In a preferred embodiment of the present invention, LED1 and LED2 are arranged horizontally side-by-side on the PCBA with a spacing of not less than 3 mm, and are located directly below the transparent window of the receiver housing, ensuring that the user can clearly distinguish the independent flickering behavior of the two LEDs from any viewing angle. The transparent window of the housing is made of polycarbonate material with a light transmittance of not less than 85% and a color temperature correction coefficient of 1.0 to ensure that the original color and flickering characteristics of the LEDs are not optically distorted.

[0016] In another preferred embodiment of the present invention, the CPU adopts an ARM Cortex-M0+ core microcontroller with a main frequency of 48MHz, and has 64KB of built-in flash memory and 8KB of static random access memory. Its GPIO pins support push-pull output mode, with a high level output of no less than 3.0V and a low level output of no more than 0.4V, which is sufficient to reliably drive the LED to work under rated current. The USB controller module supports full-speed (12Mbps) communication, conforms to the USB 2.0 specification, and can accurately parse the token packets, data packets, and handshake packets of IN and OUT transactions, ensuring accurate capture of transaction triggering events.

[0017] The method described herein runs entirely locally on the receiving end, requiring no dedicated application installation or modification of the operating system kernel on the smartphone. It only relies on the standard USB audio class driver to function properly. Therefore, this invention is compatible with all mobile terminal devices that support the USBAudioClass 1.0 specification, including but not limited to smartphones running Android 6.0 and above or iOS 11.0 and above.

[0018] The beneficial effects of this invention are: This invention achieves accurate, real-time, and localized visual alerts for recording and playback status by constructing a USB transaction-triggered bivariate differential monitoring mechanism within the wireless lavalier microphone receiver and combining it with a differentiated frequency flashing strategy using two independently controllable LEDs. This method fully utilizes existing hardware resources at the receiver, adding only two low-cost LED components without introducing a display screen, buzzer, or complex sensors, significantly controlling material costs and structural size. Simultaneously, its status recognition logic is directly coupled to the underlying USB transaction layer, avoiding uncertainties in higher-level application status judgments and ensuring strict synchronization between the alert signal and the actual audio data stream. This fundamentally solves the operational risks and user experience bottlenecks caused by the lack of status feedback in existing technologies. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of the present invention, 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 the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] In the attached diagram: Figure 1 This is a schematic diagram of the structure of the wireless lavalier microphone receiver of the present invention.

[0021] Figure 2 This is a schematic diagram of the wireless lavalier microphone receiver process of the present invention.

[0022] Figure 3 This is a system block diagram showing the synchronization relationship between the LED driving logic and USB audio transactions in this invention.

[0023] Figure 4 This is a timing diagram of the dual-LED flashing mode in the concurrent recording and broadcasting state of the present invention.

[0024] Figure 5 This is a schematic diagram of the overall process of the method of the present invention. Detailed Implementation

[0025] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0026] The wireless lavalier microphone receiver is a compact electronic device. Its external structure consists of an upper shell, a lower shell, and a transparent window in the middle, housing a printed circuit board assembly (PCBA). The PCBA, serving as the core carrier of all electronic functions, is made of FR-4 material, with a thickness of 1.0 mm and dimensions of 38 mm × 22 mm. The front of the PCBA is soldered with a central processing unit (CPU), a first light-emitting diode (LED1), a second light-emitting diode (LED2), a USB Type-C connector, current-limiting resistors R1 and R2, decoupling capacitors C1 to C4, and several passive components for signal conditioning and power management. LED1 and LED2 are both red surface-mount LEDs in 0603 packages, with a nominal forward operating voltage of 2.1V, a maximum continuous forward current of 20mA, a typical luminous intensity of 150mcd (@20mA), and a viewing angle of 120 degrees. The anode of LED1 is connected to the CPU's GPIO_PA0 pin via a current-limiting resistor R1 (150Ω, ±1% accuracy), while the cathode is grounded. The anode of LED2 is connected to the CPU's GPIO_PA1 pin via a current-limiting resistor R2 (also 150Ω, ±1%), while the cathode is also grounded. This connection method allows the CPU to directly control the on / off state of the two LEDs in push-pull output mode without the need for additional driver circuitry.

[0027] The USB Type-C connector uses a 16-pin full-function package, soldered to one end of the PCBA, for establishing a physical connection with a smartphone. This connector conforms to the USB Type-C 1.4 specification, supports reversible insertion, and has built-in CC1 / CC2 pins for power negotiation. In this embodiment, the receiving end acts as a USB peripheral device, obtaining 5V power from the host via the VBUS pin. This 5V power is then converted to 3.3V system power by an LDO regulator (such as an AMS1117-3.3) to power the CPU and other digital circuits. The D+ and D- differential signal lines are directly connected to the CPU's built-in USB full-speed (12Mbps) controller module for transmitting audio data and control information.

[0028] The CPU uses an STM32G031K8U6 microcontroller based on the ARM Cortex-M0+ core, with a maximum clock frequency of 64MHz (actually running at 48MHz). It has 64KB of built-in flash program memory and 8KB of BSRAM data memory. This chip integrates a device controller compliant with the USB 2.0 full-speed specification, supporting four configurable endpoints and possessing complete token packet parsing, data packet reception / transmission, and handshake packet generation capabilities. Its GPIO modules support multiple output modes, with PA0 and PA1 configured as push-pull outputs. The typical high-level output voltage is 3.2V (@VDD=3.3V, Iout=5mA), and the low-level output voltage is below 0.3V, fully meeting the electrical characteristics required to drive LEDs.

[0029] After the system powers on or is plugged into a smartphone via the Type-C interface, the receiver first enters the hardware initialization phase. The CPU executes the reset vector and starts the firmware program. The firmware sequentially completes clock tree configuration (8MHz external crystal oscillator, multiplied by PLL to 48MHz system clock), GPIO initialization (PA0 and PA1 set to push-pull output, initially low level), USB controller initialization (enabling D+ / D- pins, configuring endpoint buffers), and global variable declarations. Among them, global variables related to OUT transactions include OUT_FLAG and OUT_FLAG_BK, both of which are 32-bit unsigned integers (uint32_t), and their initial values ​​are both set to 0; global variables related to IN transactions include IN_FLAG and IN_FLAG_BK, also of type uint32_t, and their initial values ​​are also 0. In addition, the system tick timer (SysTick) is configured with a 1-millisecond interrupt cycle to provide a precise time base.

[0030] Subsequently, the receiving end enters the USB device enumeration process. Once the Type-C connection is established, the smartphone, acting as the USB host, detects the inserted device and begins the standard enumeration process. The receiving firmware responds to the host's request by returning the following descriptors in sequence: The Device Descriptor's bDeviceClass field is set to 0x00, indicating that the device class is defined by an interface; the Configuration Descriptor declares a configuration containing two interfaces; the first interface is an audio input interface, whose Interface Descriptor has bInterfaceClass=0x01 (AUDIO), bInterfaceSubClass=0x02 (AUDIO_STREAMING), and bInterfaceProtocol=0x00, binding an IN-direction bulk transfer endpoint (EndpointAddress=0x81, maximum packet size 64 bytes); the second interface is an audio output interface, whose Interface Descriptor has bInterfaceClass=0x01, bInterfaceSubClass=0x02, and bInterfaceProtocol=0x00, binding an OUT-direction bulk transfer endpoint (EndpointAddress=0x02, maximum packet size 64 bytes). All descriptors strictly conform to the USBAudioClass 1.0 specification. After the enumeration is complete, the smartphone operating system registers two independent audio streams in the audio subsystem: one for acquiring voice from the receiver (corresponding to IN endpoint 0x81), and the other for sending background music or system prompts to the receiver (corresponding to OUT endpoint 0x02).

[0031] After successful enumeration, the firmware enters the main loop, which runs continuously in a non-blocking mode, with each iteration taking no more than 1 millisecond. The core tasks of the main loop include: USB event polling, transaction status detection, and LED driver logic execution. The USB controller continuously monitors bus activity in the background. When a valid OUT transaction (i.e., the host sending a data packet to endpoint 0x02) is detected and the handshake is successfully completed, an OUT endpoint transmission completion interrupt is triggered. In this interrupt service routine (ISR), the firmware performs the atomic operation: OUT_FLAG = OUT_FLAG + 1. If the current value of OUT_FLAG is equal to 0xFFFFFFFF, it is incremented and then reset to 0 to prevent 32-bit integer overflow from causing logical errors. Similarly, when the receiving end is ready and sends an IN transaction data packet to the host (uploading voice sampling data via endpoint 0x81) and receives an ACK confirmation, the firmware executes IN_FLAG = IN_FLAG + 1 in the IN transaction completion callback function, also performing overflow checks and wraparound processing.

[0032] The main loop performs a complete state check and LED driver decision every 10 milliseconds (i.e., every 10 SysTick interrupts). First, it processes the OUT transaction state: reading the current OUT_FLAG and OUT_FLAG_BK values. If OUT_FLAG ≠ OUT_FLAG_BK, it determines that an active audio output transaction exists. At this point, the firmware calls the LED1 driver logic. This logic uses a non-blocking timing mechanism: if LED1 is not currently blinking, it records the current system tick count (e.g., t0 = SysTick -> VAL) as the start timestamp, and sets the target high-level duration to 100 milliseconds and the low-level duration to 100 milliseconds, for a total period of 200 milliseconds (corresponding to 5Hz). In subsequent main loops, the difference Δt between the current time and t0 is continuously calculated. When Δt ≥ 100 milliseconds and GPIO_PA0 is currently high, PA0 is set low, and t0 is updated to the current time. When Δt ≥ 200 milliseconds, the LED1 blinking status flag is reset, and OUT_FLAG_BK is updated to the current OUT_FLAG value, completing this state synchronization. If OUT_FLAG and OUT_FLAG_BK are equal again at any time (i.e., no new OUT transaction occurs), the LED1 driver is immediately stopped, its GPIO is set low, and the relevant status flags are cleared.

[0033] For IN transactions, after processing the OUT logic, the main loop immediately performs a comparison between IN_FLAG and IN_FLAG_BK. If they are not equal, the LED2 driving logic is initiated. This logic is also based on non-blocking timing: a high level lasts for 250 milliseconds, a low level lasts for 250 milliseconds, and a total period of 500 milliseconds (corresponding to 2Hz). The driving process is similar to LED1, using independent timestamps and status flags. When IN_FLAG and IN_FLAG_BK are synchronized, LED2 turns off.

[0034] Since the main loop period (10ms) is much smaller than the minimum blinking half-cycle of the LED (100ms), and the two sets of driving logic use completely independent GPIO pins, timing variables and status flags, even in scenarios where IN and OUT transactions occur concurrently (such as recording and playing background music simultaneously during a live broadcast), the blinking behavior of LED1 and LED2 can maintain the stability and independence of their respective frequencies. Figure 4 The timing diagram clearly shows this concurrent state: LED1 blinks regularly with a period of 200ms, and LED2 blinks independently with a period of 500ms, with no interference between their waveforms.

[0035] In terms of PCB layout, LED1 and LED2 are precisely placed on the front side of the PCBA near the Type-C connector, with a center-to-center distance of 4.2 mm. This ensures that two clearly distinguishable light spots are formed within the transparent window of the receiver housing. The transparent window is injection molded from optical-grade polycarbonate (PC) material, with a thickness of 1.2 mm and a measured light transmittance of 87.3% (according to ASTM D1003 standard). The color coordinates (CIE 1931) are x=0.685, y=0.312, which match well with the original emission spectrum of the LEDs, with no obvious color shift or scattering distortion. Users can accurately identify the difference in flicker frequency between the two LEDs within a distance of 30 cm from the receiver and a viewing angle of ±60 degrees.

[0036] To verify the effectiveness of the present invention, the following embodiments were designed and compared with comparative examples for testing.

[0037] In one specific embodiment, a receiver prototype was constructed using the complete technical solution described above. The test platform included: an Android 12 smartphone (Samsung Galaxy S22), an iOS 15 iPhone 13, a USB Audio Analyzer (Total Phase Beagle USB12), a high-speed camera (Phantom v2512, 1000fps), and acoustic analysis software (Adobe Audition). The test procedure was as follows: First, the receiver was plugged into the Android phone, and a recording application (such as Voice Recorder) was launched while simultaneously playing a local MP3 file. USB bus transactions were captured using the USB analyzer, confirming continuous data packet transmission at both the IN endpoint (0x81) and the OUT endpoint (0x02). The high-speed camera recorded the LED status; frame analysis confirmed that the blinking period of LED1 was 199.8 ± 1.2 ms (frequency 5.00 ± 0.03 Hz), and the blinking period of LED2 was 498.5 ± 2.1 ms (frequency 2.01 ± 0.01 Hz). Switching to an iOS device and performing the same operation using the GarageBand application yielded consistent results. In pure recording mode (recording only, no playback), only LED2 blinks at 2Hz; in pure playback mode (e.g., playing a YouTube video but with microphone access disabled), only LED1 blinks at 5Hz. All state transitions have a latency of less than 50 milliseconds, highly synchronized with the start / end of the audio data stream.

[0038] As a comparison, a simplified receiver was built, retaining only a single LED, and attempting to distinguish states through different colors (such as red / green) or a single flashing frequency. Testing revealed that under complex ambient lighting conditions (such as stage lighting or direct sunlight), users struggled to accurately distinguish color changes; and a single frequency could not simultaneously represent two concurrent states, leading to information loss in composite operating modes. Another comparison used application-layer API-based state detection (such as AndroidAudioManager.isRecordingActive()), and testing showed significant delays in state updates (averaging 200-500ms), and unreliability on some custom ROMs, failing to achieve strict synchronization with the underlying audio data stream.

[0039] The following table summarizes the key performance indicators of the embodiments and comparative examples: ; Experimental data show that the present invention is significantly superior to the comparative example in terms of state recognition accuracy, concurrent characterization capability, real-time response, and environmental robustness, while maintaining a very low increase in hardware cost.

[0040] Furthermore, to optimize power consumption, a dynamic sleep mechanism is introduced in the LED driver logic. If no transaction activity is detected for 10 consecutive main loop cycles (i.e., 100ms) (i.e., OUT_FLAG=OUT_FLAG_BK and IN_FLAG=IN_FLAG_BK), the CPU enters sleep mode, retaining only the USB wake-up interrupt and SysTick interrupt enabled. Once a transaction occurs at any endpoint, the USB controller immediately wakes the CPU and resumes main loop execution. Real-world testing shows that in typical intermittent usage scenarios (such as conference recording, averaging 5 short recordings per minute), the average power consumption of the entire device is reduced by 37%, extending the continuous operating time under VBUS power supply.

[0041] In extreme long-term operation tests, the prototype operated continuously for 72 hours, during which IN and OUT transactions were continuously alternated. The 32-bit counter variable overflowed and wrapped around twice (each time after approximately 4.29 billion transactions), but because the firmware performed boundary checks and synchronously reset backup variables before incrementing, no false triggers or state loss occurred. The USB analyzer recorded the entire process, showing that the LED flashing status always maintained a one-to-one correspondence with the time of the transaction.

[0042] In summary, the intelligent visual alert method for audio status at the wireless lavalier microphone receiver proposed in this invention achieves accurate, real-time, and unambiguous visual feedback on recording and playback status by constructing a dual-variable differential monitoring mechanism based on USB transaction triggering locally at the receiver, combined with a differentiated frequency flashing strategy for two independently controllable LEDs. This solution relies entirely on existing hardware resources at the receiver, adding only two low-cost LED components without introducing a display screen, buzzer, or complex sensors, effectively controlling material costs and structural volume. Its status recognition logic is directly coupled to the underlying USB transaction layer, avoiding uncertainties in higher-level application status judgments and ensuring strict synchronization between the alert signal and the actual audio data stream. This method does not require installing a dedicated application or modifying the operating system kernel on the smartphone; it is cross-platform compatible and applicable to all mobile terminal devices supporting this specification, relying solely on the standard USBAudioClass 1.0 driver. Those skilled in the art can make adaptive adjustments to parameters such as LED color, flashing frequency, GPIO allocation, counter variable bit width, or main loop period based on this embodiment without departing from the core idea of ​​this invention; all such adjustments should be considered within the protection scope of this invention.

[0043] In the description of this invention, it should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired results of the technical solutions provided in this disclosure can be achieved, and no limitation is imposed herein.

[0044] The above description is merely a preferred embodiment of the present invention and does not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A wireless lavalier microphone receiving end audio state intelligent visual reminding method, the receiving end comprising a printed circuit board assembly, a first light emitting diode (LED1), a second light emitting diode (LED2), a central processing unit (CPU) with general input / output (GPIO) control capability, and a physical interface conforming to the USB Type-C specification; characterized in that, The method comprises the following steps: In the system initialization stage, a physical connection is established with the smart phone through the USBType-C interface, and a USB device enumeration process is completed, so that the receiving end is recognized as a composite audio device conforming to the USBAudioClass1.0 specification, which contains an IN direction batch transmission endpoint for uploading voice data and an OUT direction batch transmission endpoint for receiving background audio data; Global variables IN_FLAG and IN_FLAG_BK corresponding to the IN direction endpoint and global variables OUT_FLAG and OUT_FLAG_BK corresponding to the OUT direction endpoint are defined in the firmware, and the initial values of all variables are zero; Each time an IN transaction of uploading voice data to the smart phone is completed, an increment operation is performed on IN_FLAG in the corresponding transmission completion callback function; and each time an OUT transaction data packet from the smart phone is received, an increment operation is performed on OUT_FLAG in the OUT endpoint transmission completion interrupt service routine; In the CPU main loop, the following operations are sequentially performed at a period not greater than 10 milliseconds: Compare IN_FLAG with IN_FLAG_BK, if they are not equal, drive LED2 to flash at a frequency of 2 Hz, and assign the current IN_FLAG value to IN_FLAG_BK; if they are equal, turn off LED2; Compare OUT_FLAG with OUT_FLAG_BK, if they are not equal, drive LED1 to flash at a frequency of 5 Hz, and assign the current OUT_FLAG value to OUT_FLAG_BK; if they are equal, turn off LED1; Wherein, LED1 and LED2 are connected to two independent GPIO pins of the CPU, and their on-off states are independently controlled by the CPU, and the flashing behaviors of the two do not interfere with each other.

2. The method of claim 1, wherein the method further comprises: The driving LED1 to flash at a frequency of 5 Hz specifically includes: controlling the GPIO pin of LED1 to output high level for 100 milliseconds and then switching to low level for 100 milliseconds to form a square wave signal with a period of 200 milliseconds; and the driving LED2 to flash at a frequency of 2 Hz specifically includes: controlling the GPIO pin of LED2 to output high level for 250 milliseconds and then switching to low level for 250 milliseconds to form a square wave signal with a period of 500 milliseconds.

3. The method of claim 1, wherein the wireless lavalier microphone receiving end audio status intelligent visual reminder method is characterized by, The IN_FLAG, IN_FLAG_BK, OUT_FLAG and OUT_FLAG_BK are all 32-bit unsigned integer variables; before performing the increment operation on IN_FLAG or OUT_FLAG each time, it is judged whether the current value is equal to 0xFFFFFFFF, if yes, then after incrementing, it is reset to 0, and the corresponding IN_FLAG_BK or OUT_FLAG_BK is also reset to 0.

4. The method of claim 1, wherein the wireless lavalier microphone receiving end audio status intelligent visual reminder method is characterized by, The LED1 and LED2 are both red surface mount light emitting diodes, connected to the GPIO pin of the CPU through a current limiting resistor, and the cathode is grounded; the resistance value of the current limiting resistor is 150Ω, and the precision is ±1%.

5. The method of claim 1, wherein the wireless lavalier microphone receiving end audio status intelligent visual reminder method is characterized by, The CPU is a microcontroller with ARM Cortex-M0+ core, 48MHz frequency, built-in USB full-speed controller module, supporting parsing token packets, data packets and handshake packets of USB IN and OUT transactions, and triggering corresponding interrupts or callback functions when transactions are completed.

6. The method of claim 1, wherein the wireless lavalier microphone receiving end audio status intelligent visual reminder method is characterized by, The LED1 and LED2 are horizontally arranged side by side on the printed circuit board assembly, with a center distance of not less than 3 mm and located directly below the transparent window of the receiving end shell; the transparent window is made of polycarbonate material, and the light transmittance is not less than 85%.

7. The method of claim 1, wherein the method further comprises: The logic for driving the LED1 or LED2 adopts a non-blocking timing control mechanism: when starting the flashing, the system tick count value is recorded as the starting timestamp, and in the subsequent main loop, the GPIO level is dynamically switched according to the difference between the current time and the starting timestamp, until a complete flashing period is completed and the state flag is reset.

8. The method of claim 1, wherein the wireless lavalier microphone receiving end audio status intelligent visual reminder method is characterized by, When no IN transaction or OUT transaction activity is detected within 10 consecutive main loop cycles, the CPU enters sleep mode, only retaining the USB wake-up interrupt and system tick interrupt enabled; when any endpoint has a transaction, the USB controller immediately wakes up the CPU to resume main loop execution.

9. The method of claim 1, wherein the wireless lavalier microphone receiving end audio status intelligent visual reminder method is characterized by, The interface descriptor returned during the enumeration process of the USB device declares that the device contains two independent audio interfaces: the first interface is an audio input interface, bound to the IN direction bulk transfer endpoint; the second interface is an audio output interface, bound to the OUT direction bulk transfer endpoint; both interfaces conform to the USB Audio Class 1.0 specification and are registered as two independent audio stream channels by the smartphone operating system.

10. The method of claim 1, wherein the wireless lavalier microphone receiving end audio status intelligent visual reminder method is characterized by, The method runs completely on the receiving end locally, without the need for installing a dedicated application program or modifying the operating system kernel on the smartphone side, and only relies on the standard USB Audio Class 1.0 driver to achieve cross-platform compatibility, suitable for all mobile terminal devices supporting Android 6.0 and above versions or iOS 11.0 and above versions of the specification.

Images