Cross-platform mobile power supply data interaction and state monitoring system and method

Abstract

The invention relates to the technical field of mobile power supply monitoring and data communication, in particular to a cross-platform mobile power supply data interaction and state monitoring system and method, and aims to solve the problems of unreliability, high delay and poor compatibility of cross-platform communication caused by limitation of a safety mechanism of an operating system in the prior art. According to the system, a triple redundancy communication architecture which is based on a standard MIDI protocol and fuses an MTP protocol and gamepad equipment simulation is constructed, sensor data is embedded into an MIDI SysEx message through a displacement coding algorithm, and millisecond-level safety warning is achieved through a kernel-level audio path; and meanwhile, dynamic switching of communication protocols is supported, and drive-free, low-delay and high-reliability data interaction and active safety intervention of the whole platform are ensured.

Description

Technical Field

[0001] This invention relates to the field of energy storage systems and power supply circuit control technology, and in particular to a cross-platform mobile power supply data interaction and status monitoring system and method. Background Technology

[0002] With the deep penetration of portable electronic devices in consumer, industrial, and emergency communication fields, smart mobile power banks are no longer limited to basic power replenishment functions, but are gradually evolving into edge intelligent terminals that integrate battery status sensing, safety risk warning, and user interaction control. Against this backdrop, building a monitoring system capable of seamless, stable, and low-latency data interaction between the three major mobile operating systems—iOS, Android, and HarmonyOS—has become a key technological path to improve product intelligence and safety compliance capabilities. Especially under the increasingly stringent regulatory environment of mandatory standards such as the "Mobile Power Bank Safety Technical Specification," systems must complete the entire chain response from anomaly detection to closed-loop intervention within millisecond-level time windows. This places unprecedented comprehensive demands on the real-time performance, reliability, and platform universality of the underlying communication mechanism.

[0003] In existing technologies, to achieve cross-platform data interaction, the industry mainly adopts two technical approaches: one is a wireless communication-based solution, such as Bluetooth or near-field communication technology; the other is a protocol simulation strategy relying on wired connections, including media transmission protocols or human-machine interface device simulation. While the former has the advantage of physical connection decoupling, it is limited by the inherent characteristics of wireless channels, and is prone to connection interruptions, pairing failures, and power consumption surges in high-interference environments or dense device scenarios, making it difficult to support the high-frequency, low-jitter status data reporting requirements. The latter, while utilizing the USB physical link to ensure bandwidth and stability, faces more complex system compatibility challenges. Specifically, although media transmission protocols can bypass authentication mechanisms on some Android and HarmonyOS devices, they are often identified as camera peripherals in iOS systems, triggering album access permission pop-ups; even in the Android ecosystem, different manufacturers' whitelisting policies for USB device categories prevent the protocol from being properly enumerated on certain models. While game controller simulation solutions based on human-machine interface devices can achieve driverless communication on most consumer terminals, they are completely disabled in high-security environments such as industrial control and government offices due to system policy restrictions, resulting in the complete failure of the communication link.

[0004] However, the root of the aforementioned problems lies not only in the fragmentation of protocol selection, but also more deeply in the security review logic and driver loading mechanisms of mobile operating systems for "data communication devices." Modern mobile operating systems, for privacy and security reasons, generally implement strict permission controls on non-standard USB devices. Any attempt to exchange low-level data through custom device classes or proprietary protocols may trigger system-level authorization pop-ups or even be directly blocked. While this mechanism effectively curbs the potential threat of malicious hardware, it also inadvertently constructs an "invisible barrier" between legitimate smart peripherals and the terminal system. Crucially, even if some solutions can bypass the permission verification during the initial connection phase, their data transmission paths often still need to traverse multiple application frameworks and middleware, resulting in a significant increase in communication latency and failing to meet the millisecond-level response requirements for battery safety incidents. The reason for this is that the priority of general data channels in the system kernel scheduling is far lower than that of real-time media streams such as audio and video, and existing solutions fail to effectively utilize the high-priority processing paths reserved by the operating system for specific device categories.

[0005] Under the dual pressures of technological evolution and security compliance, a seemingly insignificant but crucial contradiction has gradually emerged: On the one hand, power banks urgently need a communication carrier with native support across all platforms, requiring no user authorization, and possessing kernel-level low latency; on the other hand, operating systems grant the highest level of driver compatibility and scheduling priority to "audio / musical instrument" standard devices (such as MIDI devices), exempting them from security reviews of conventional data devices as they are considered basic human-computer interaction facilities. This institutional difference provides a potential opportunity for technological breakthroughs, but how to reconstruct the MIDI system-specific messages originally used to transmit instrument tuning parameters into a universal information channel carrying floating-point status data such as battery voltage and current involves deep adaptation of the protocol's underlying encoding rules, byte validity bit limits, and verification mechanisms. Existing technologies have not yet recognized the potential of the MIDI protocol as a carrier in non-audio scenarios, nor have they resolved the mapping conflict between its 7 valid data bits and 8 raw sensor data, nor have they constructed a multi-redundant communication architecture centered on this channel to cope with the risk of protocol failure in extreme environments.

[0006] Therefore, how to establish a mobile power bank data interaction and status monitoring system that combines cross-platform driverless compatibility, kernel-level low-latency response capability, and multiple protocol redundancy protection based on the standard audio device protocol natively supported by the operating system and through the creative reconstruction of system-specific message fields has become a key challenge and an urgent technical problem for those skilled in the art. Summary of the Invention

[0007] The purpose of this invention is to overcome the shortcomings of existing technologies and provide a cross-platform mobile power bank data interaction and status monitoring system, comprising: The smart power bank integrates battery management components and a USB device control module. The terminal device runs a pre-defined operating system, which has native driver support for standard MIDI devices; a USB data path connects the smart power bank to the terminal device. The USB device control module is configured to declare the terminal device as a standard MIDI device conforming to the USBMIDI protocol specification during the device enumeration phase. The battery management component is used to collect the operating status parameters of the power bank and encode them into data frames that conform to the proprietary message format of the MIDI system; the USB device control module transmits the encapsulated SysEx message to the terminal device through the USB data path, so that the terminal device can parse and obtain the operating status parameters through the MIDI communication interface without the need for a third-party driver.

[0008] Preferably, the operating status parameters include: voltage, current, temperature, remaining power, number of cycles, health status, and safety status information; when encoding the SysEx message, the smart power bank adopts a shift mapping algorithm: splitting the original 8-bit data byte into multiple 7-bit data units, and ensuring that the highest bit of each data unit is always 0, in order to adapt to the constraints of the MIDI protocol on data bytes.

[0009] Preferably, the displacement mapping algorithm performs the following steps: performing displacement logic operation on the current original data byte D and the adjacent original data bytes; extracting the specified bits after displacement and recombining them into a first unit and a second unit that meet the 7-bit width constraint; the receiving end restores the original data byte D from the received first unit and second unit through inverse displacement and bitwise OR operation.

[0010] Preferably, the terminal device runs a supporting application, which is configured to: monitor the received SysEx messages in real time, and when the running status parameter is detected to trigger a preset abnormal threshold, directly call the kernel-level audio engine of the operating system; the audio engine writes audio waveform signals of a specific frequency to the audio hardware buffer to bypass the scheduling of the application layer audio service stack, so as to achieve an abnormal alarm response with an end-to-end latency of less than or equal to 10 milliseconds.

[0011] Preferably, the USB device control module has a multi-mode descriptor dynamic switching function, which supports state machine switching between MIDI device mode, MTP media transmission protocol accessory mode and HID human-machine interface device game controller mode; the smart power bank performs priority scheduling according to the handshake state with the terminal device: the initial connection is prioritized to MIDI device mode, and if the communication link fails to be established within a preset time window, it will sequentially downgrade to MTP mode and HID game controller mode.

[0012] Preferably, in the HID game controller mode, the system defines an asymmetric bidirectional encoding mechanism: Downlink control: The terminal device sends vibration parameters of different intensities to the smart power bank to map a corresponding set of control commands, including: stop charging, power limit, status query, fast charging enable switch, sensor calibration, and firmware upgrade; Uplink feedback: The smart power bank encodes and provides feedback on the operating status parameters by simulating the on / off state and pressing duration of the function buttons on a game controller.

[0013] Preferably, the SysEx message adopts a unified frame structure: consisting of a frame header 0xF0, a data payload segment, a CRC check segment, and a frame trailer 0xF7; the data payload segment contains multiple physical quantity fields arranged in big-endian order, and the CRC check segment carries a 32-bit redundancy check code generated based on the IEEE 802.3 standard polynomial to ensure the integrity of data transmitted across protocols.

[0014] Preferably, the smart power bank includes an analog front-end (AFE) circuit, which comprises: a 16-bit Σ-Δ analog-to-digital converter for high-precision voltage sampling; a bidirectional current sensing amplifier, used in conjunction with a precision shunt resistor for current measurement; and a digital temperature sensor connected via an I²C bus.

[0015] Preferably, the supporting application performs multi-level early warning linkage: secondary early warning: when the status parameter meets the first threshold, the UI interface status is updated; primary early warning: when the status parameter meets the second threshold, the kernel-level audio engine is triggered to play an alarm sound, and a downlink transmission power limiting command is synchronously executed; emergency cut-off: when the parameter indicates a serious fault, the smart power bank cuts off the gate drive signal of the internal power semiconductor switch through physical control, forcibly disconnecting the charging and discharging circuit.

[0016] Preferably, the method includes the following steps: establishing a physical connection between the smart power bank and the terminal device, and completing the enumeration and authentication of the MIDI-based device; the smart power bank collects real-time operating parameters of the battery, performs displacement encoding based on 7-bit constraints, encapsulates it into a SysEx data packet, and sends it; the terminal device receives and decodes the data packet through the MIDI interface, and updates the status monitoring cache in real time; and executes corresponding interactive feedback or hardware intervention protection actions based on the matching of the monitoring results and the security policy.

[0017] This invention fundamentally resolves the compatibility and real-time performance conflict in cross-platform mobile power bank communication by migrating the MIDI protocol from the audio control domain to general data transmission scenarios and fully leveraging the operating system's driverless support and high-priority scheduling features for standard audio devices. A triple protocol redundancy mechanism ensures at least one usable communication path in any platform environment, while the alarm sound generation mechanism based on the MIDI audio engine achieves ultra-low latency user access to safety events. The entire system completes a closed-loop process from data acquisition, transmission, and parsing to proactive intervention without relying on any third-party drivers or triggering system permission pop-ups, meeting the mandatory millisecond-level response capability requirements of the "Mobile Power Bank Safety Technical Specification." Attached Figure Description

[0018] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only for this invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of the overall structure of the cross-platform mobile power bank data interaction and status monitoring system described in this invention.

[0020] Figure 2 This is a schematic diagram of the protocol encapsulation and transmission process for data interaction in MIDI device mode by the smart power bank in this invention.

[0021] Figure 3 This is a schematic diagram of the data encoding and command mapping mechanism based on the game controller device simulation mode in this invention.

[0022] Figure 4 This is a schematic diagram illustrating the unified data frame structure described in this invention and its mapping relationship under different communication protocols.

[0023] Figure 5 This is a flowchart illustrating the execution process of the method of the present invention, showing the entire logic from device connection to security response. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to specific embodiments.

[0025] This invention provides a cross-platform mobile power bank data interaction and status monitoring system and method, the specific implementation of which is described below. The system consists of three parts: a hardware layer, a protocol layer, and an application layer. These layers work together through standardized interfaces to achieve highly compatible, low-latency, and highly reliable data interaction and closed-loop security status monitoring across iOS, Android, and HarmonyOS operating systems.

[0026] At the hardware level, the system includes a smart power bank, terminal devices, and a USB-C data cable connecting the two. The smart power bank integrates a Battery Management System (BMS) and a USB Device control module. The BMS is responsible for real-time acquisition of key parameters such as voltage, current, and temperature of the lithium-ion battery cells, and executes charging and discharging control, equalization management, and safety protection logic. The USB Device control module is implemented based on a programmable microcontroller unit (MCU), possessing the ability to dynamically switch device descriptors and supporting enumeration behavior for three device categories: MIDI Class, MTP Camera Class, and HID Gamepad Class. The terminal device is a smartphone or tablet running iOS 12 or later, Android 9 or later, or HarmonyOS 2.0 or later, whose operating system kernel natively supports driverless identification and communication for the above three USB device categories. The USB-C data cable is a full-featured cable, supporting USB 2.0 high-speed data transmission and Power Delivery protocol, ensuring the electrical integrity and signal stability of the physical connection.

[0027] In a preferred embodiment of the present invention, after initial power-on, the USB Device control module first reads the terminal device type identification table pre-stored in non-volatile memory. This identification table, based on historical connection records or factory preset rules, contains several sets of mapping relationships between <operating system signature codes and optimal protocol modes>. If there are no valid historical records, it defaults to prioritizing enumeration as a MIDI Class device. At this time, the control module sends a device descriptor conforming to the USBMIDI Class 1.0 specification to the host, including a standard audio class interface descriptor, a MIDI stream endpoint descriptor, and a manufacturer-defined string descriptor. Upon receiving the descriptor, the operating system recognizes it as an audio peripheral and automatically loads the kernel-level MIDI driver, completing device mounting without user authorization.

[0028] At the protocol layer, the system constructs a unified data frame structure and a triple-redundant communication mechanism. The unified data frame consists of four parts: a frame header, a data segment, a CRC32 checksum, and a frame trailer. The frame header is fixed at byte 0xF0, and the frame trailer is fixed at byte 0xF7, conforming to the MIDI SysEx (System Exclusive) message format requirements. The data segment contains nine fields: battery voltage (mV, 32-bit unsigned integer), charging / discharging current (mA, 32-bit signed integer), battery temperature (°C, 16-bit signed integer), cycle count (16-bit unsigned integer), battery health percentage (8-bit unsigned integer), safety status code (8-bit unsigned integer), remaining battery capacity percentage (8-bit unsigned integer), real-time charging power (W, 32-bit unsigned integer), and UTC timestamp (64-bit unsigned integer). All fields are arranged in big-endian order. The CRC32 checksum uses the IEEE 802.3 standard polynomial. Perform calculations covering the entire data segment content, generate a 32-bit check value, and insert it into the check code field in big-endian order.

[0029] When the system is in MIDI communication mode, the USB Device control module encapsulates the aforementioned unified data frame into a MIDI SysEx message. Since the MIDI protocol stipulates that the highest bit of each data byte must be 0 (i.e., the valid data range is 0x00–0x7F), and raw sensor data is mostly 8-bit or higher bit-width binary values, direct transmission would result in the loss of high-bit information. Therefore, this invention introduces a shift encoding algorithm to preprocess the raw data. Specifically, for each 8-bit raw data byte... It is split into two 7-bit data units. and :

[0030] in These are the two most significant bits of the next byte, used for concatenation to form a continuous data stream. The receiving end performs the reverse operation during parsing:

[0031] This mechanism ensures that any 8-bit data can be losslessly mapped to a MIDI-compliant 7-bit data space, and supports fixed-point representation and reconstruction of floating-point data. The encapsulated SysEx message is sent to the terminal device via interrupt transmission through the USB MIDI stream endpoint.

[0032] After the accompanying application starts on the terminal device, it calls the MIDI API provided by the operating system (such as CoreMIDI for iOS, USB MIDI API for Android, or AudioDeviceManager for HarmonyOS) to enumerate the connected MIDI devices. By comparing the Vendor Identifier (VID) and Product Identifier (PID) in the device descriptor, it confirms the identity of the target smart power bank and establishes a dedicated MIDI input port to listen for the data stream. Upon receiving a SysEx message, the application first strips the frame header and trailer, extracts the intermediate data segment, and performs a CRC32 check. If the check fails, it constructs a retransmission request command and sends it in reverse through the same MIDI channel; if the check succeeds, it parses the parameter values ​​in the order of the fields, updates the local state cache, and triggers subsequent logic processing.

[0033] Furthermore, the system implements a kernel-level low-latency safety response mechanism on top of the MIDI channel. When the BMS detects that any level of safety threshold has been triggered—including but not limited to battery temperature ≥ 60℃, output voltage ≥ 5.3V, charging current ≥ 4.5A, and discharging current ≤ -4.5A—the control program immediately generates a dedicated SysEx alarm message, whose data segment includes an event type code and a timestamp. Upon receiving this message, the application bypasses application-layer audio services (such as AVAudioPlayer or MediaPlayer) and directly calls the system MIDI audio engine (such as iOS's Audio Unit, Android's AAudio, or HarmonyOS's Native Audio API) to write a sine wave sample with a frequency of 2000Hz and a duration of 200ms to the kernel audio hardware buffer. Because this path bypasses the application sandbox and audio mixer, the end-to-end latency can be controlled within 10 milliseconds, meeting the safety specifications for real-time alarms.

[0034] In another embodiment of the present invention, when MIDI communication fails to establish a valid link due to platform limitations or driver malfunctions, the system automatically switches to MTP (Media Transfer Protocol) communication mode. At this time, the USB Device control module reconfigures the device descriptor, declares it as an MTP camera accessory (PTP / MTP Class), and sends a standard MTP device information packet to the host. The terminal device's operating system recognizes it as a media storage device and loads the MTP protocol stack. The accompanying application scans for connected MTP devices by calling the system's MTP API (such as Android's StorageManager or HarmonyOS's FileAccessService) and matches the target power bank based on VID / PID. Data interaction is achieved through extended MTP's GetObject and SendObject commands: control commands are encapsulated as private MTP objects (Object Format Code = 0xFFFF), whose content is the raw byte sequence of a unified data frame; status feedback is completed by creating a new MTP object and uploading it to the device's root directory. This mechanism leverages the widespread support for MTP in Android and HarmonyOS as a reliable backup channel when MIDI fails.

[0035] In extreme cases, if MTP is also unavailable (such as the strict restrictions on non-Apple certified MTP devices in iOS), the system further switches to gamepad device emulation mode. At this time, the USB Device control module loads the HID (Human Interface Device) descriptor, declaring it as a gamepad with a vibration motor. The descriptor defines eight numeric buttons (Buttons 0–7) and a vibration intensity parameter (Rumble Intensity, 8 bits). The accompanying application enumerates all connected gamepad devices through the system HID API (such as iOS's Game Controller framework, Android's InputDevice API, or HarmonyOS's InputEventHub) and filters out target devices with matching VID / PID. Control commands are issued by setting the vibration intensity parameter, with the following numerical mapping: 0 indicates stop charging, 32 indicates limit output power to 10W, 64 indicates query current status, 96 indicates enable fast charging protocol, 128 indicates disable fast charging, 160 indicates trigger sensor calibration, 192 indicates clear operation log, and 224 indicates enter firmware upgrade mode. Battery status data is encoded using combinations of on / off states from eight buttons: each button corresponds to a flag indicating the presence of a field in a unified data frame (e.g., Button 0 indicates voltage is active, Button 1 indicates current is active, and so on); the duration of the button press (in milliseconds) quantifies the numerical value of that field. For example, if the voltage is 4200mV, then Button 0 remains pressed for 4200 milliseconds. The application decodes the field values ​​by listening to the timestamp differences of button events and reassembles them into a complete data frame.

[0036] The BMS module employs high-precision analog front-end circuitry for data acquisition. The voltage sampling channel uses a 16-bit Σ-Δ analog-to-digital converter (ADC) with a reference voltage of 2.5V, a range of 0–5.5V, and a resolution of 0.1mV. Bidirectional current detection is achieved through a low-drift operational amplifier and a precision shunt resistor (5mΩ resistance, temperature drift ±25ppm / ℃), supporting a ±5A measurement range with an accuracy better than ±1%. Temperature sensing utilizes a digital output NTC sensor with an I²C interface, a resolution of 0.1℃, and a temperature range of -20℃ to +85℃. The default data acquisition frequency is 1Hz, which can be dynamically adjusted to 0.5Hz or 2Hz via host computer commands. Raw sampled values ​​are processed by an 8-bit moving average filter to suppress switching noise and electromagnetic interference. Furthermore, each unit undergoes zero-point offset calibration before leaving the factory. Calibration parameters (including voltage offset, current zero-point error, and temperature compensation coefficient) are stored in EEPROM and automatically loaded upon each power-on for real-time data compensation, ensuring measurement consistency over long-term operation.

[0037] At the application layer, the supporting application program incorporates multi-level security warning and intervention strategies. The secondary warning conditions include the number of cycles ≥ 800 times, health level ≤ 80%, single charging time exceeding 4 hours, etc. When triggered, only a non-modal prompt box is displayed on the graphical user interface, and the status bar icon is changed to a yellow warning color. The occurrence of a first-level security event (such as the aforementioned temperature, voltage, and current exceeding the limit) triggers a three-level linkage response: First, a full-screen modal warning window pops up to prevent the user from performing other operations; Second, the system vibration service is called (such as UIFeedbackGenerator for iOS, Vibrator for Android, or VibratorManager for HarmonyOS) to generate a vibration feedback with a duration of 500 ms and a medium intensity; At the same time, an alarm sound is played through the MIDI audio channel; And an instruction to limit the power is immediately sent to the smart power bank, forcing the output power of the DC-DC converter to be clamped below 10 W. If the event continues to deteriorate, for example, the temperature rises to 70 °C or the output voltage continues to be higher than 5.3 V for more than 2 seconds, it is determined to be in a severe fault state, and the application program immediately sends an emergency shutdown instruction (SysEx message type code = 0xFF). After receiving this instruction, the control program of the smart power bank turns off the gate drive signal of the charging and discharging MOSFET of the main control MCU, physically cuts off the electrical connection between the battery and the output port, completely isolates the energy circuit, and prevents the spread of thermal runaway.

[0038] In a specific embodiment, the smart power bank is connected to a smartphone running Android 13 via a USB-C cable. The power bank MCU detects no historical records and enumerates itself as a MIDI device. The Android system successfully loads the MIDI driver, and the application program discovers the device and establishes communication through the USB MIDI API. The BMS collects data at a frequency of 1 Hz, encodes the displacement, and encapsulates it into SysEx messages for transmission. The application program receives one frame per second and updates the UI display after passing the verification. When the battery cell is artificially heated to 62 °C during the simulation test, the BMS immediately generates an alarm SysEx, the application program triggers an alarm sound of 2000 Hz within 8 milliseconds, and limits the output power. After the user confirms, the system resumes normal monitoring.

[0039] In the comparison, a traditional communication scheme based on the CDC (Communication Device Class) virtual serial port was used, connecting the same power bank to the same Android 13 device. Because the Android system requires manual authorization for non-whitelisted USB serial port devices, a permission request dialog box pops up upon initial connection, requiring the user to manually click "Allow" to establish communication. Without authorization, the application cannot obtain any status data, and security events cannot be reported. Even after authorization, serial port data transmission relies on Java-layer InputStream reading, resulting in an end-to-end latency exceeding 150 milliseconds, failing to meet millisecond-level response requirements.

[0040] The table below compares the communication establishment success rate, average latency, and security incident response capability of the embodiments of the present invention and the comparative examples on different platforms:

[0041] The above data demonstrates that this invention, through the cross-platform native support of the MIDI protocol, completely circumvents communication barriers caused by the operating system's permission model and achieves sub-10-millisecond security alarm response by leveraging the kernel audio path. The triple protocol redundancy mechanism ensures that at least one effective communication link can be established in any mainstream mobile operating system environment, significantly improving system robustness and user experience.

[0042] In summary, the cross-platform mobile power bank data interaction and status monitoring system and method of this invention, through a multi-functional USB Device control module at the hardware layer, a unified frame structure and triple-redundant communication architecture at the protocol layer, and a multi-level security linkage strategy at the application layer, constructs a cross-platform monitoring system that requires no user authorization, has low latency, high reliability, and is fully closed-loop. Its technical solution is fully disclosed, and those skilled in the art can reproduce all the functions of this invention based on the above description and conventional electronic engineering practices.

[0043] The embodiments described above are only used to illustrate the technical solutions of this application, and are not intended to limit it. 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; and these 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, and should all be included within the protection scope of this application.

Claims

1. A cross-platform mobile power bank data interaction and status monitoring system, characterized in that, include: The smart power bank integrates battery management components and a USB device control module. The terminal device runs a pre-defined operating system, which has native driver support for standard MIDI devices. USB data path, connecting the smart power bank to the terminal device; The USB device control module is configured to declare the terminal device as a standard MIDI device conforming to the USB MIDI protocol specification during the device enumeration phase. The battery management component is used to collect the operating status parameters of the power bank and encode them into data frames that conform to the proprietary message format of the MIDI system; the USB device control module transmits the encapsulated SysEx message to the terminal device through the USB data path, so that the terminal device can parse and obtain the operating status parameters through the MIDI communication interface without the need for a third-party driver.

2. The cross-platform mobile power bank data interaction and status monitoring system according to claim 1, characterized in that: The operating status parameters include: voltage, current, temperature, remaining power, number of cycles, health status, and safety status information; when encoding the SysEx message, the smart power bank adopts a shift mapping algorithm: splitting the original 8-bit data byte into multiple 7-bit data units, and ensuring that the highest bit of each data unit is always 0, in order to adapt to the constraints of the MIDI protocol on data bytes.

3. The cross-platform mobile power bank data interaction and status monitoring system according to claim 2, characterized in that, The displacement mapping algorithm performs the following steps: performing displacement logic operations on the current original data byte D and the adjacent original data bytes; extracting the specified bits after displacement and recombining them into a first unit and a second unit that meet the 7-bit width constraint; the receiving end restores the original data byte D from the received first unit and second unit through inverse displacement and bitwise OR operation.

4. The cross-platform mobile power bank data interaction and status monitoring system according to claim 1, characterized in that: The terminal device runs a supporting application, which is configured to: monitor the received SysEx messages in real time, and when the running status parameter is detected to trigger a preset abnormal threshold, directly call the kernel-level audio engine of the operating system; the audio engine writes audio waveform signals of a specific frequency to the audio hardware buffer to bypass the scheduling of the application layer audio service stack, so as to achieve an abnormal alarm response with an end-to-end latency of less than or equal to 10 milliseconds.

5. The cross-platform mobile power bank data interaction and status monitoring system according to claim 1, characterized in that: The USB device control module has a multi-mode descriptor dynamic switching function, which supports state machine switching between MIDI device mode, MTP media transmission protocol accessory mode and HID human-machine interface device game controller mode; the smart power bank performs priority scheduling according to the handshake state with the terminal device: the initial connection is prioritized to MIDI device mode, and if the communication link fails to be established within a preset time window, it will sequentially downgrade to MTP mode and HID game controller mode.

6. The cross-platform mobile power bank data interaction and status monitoring system according to claim 5, characterized in that: In the HID game controller mode, the system defines an asymmetric bidirectional encoding mechanism: Downlink control: The terminal device sends vibration parameters of different intensities to the smart power bank to map a set of corresponding control commands, including: stop charging, power limit, status query, fast charging enable switch, sensor calibration, and firmware upgrade; Uplink feedback: The smart power bank encodes and provides feedback on the operating status parameters by simulating the on / off state of the function buttons on a game controller and the duration of the press.

7. The cross-platform mobile power bank data interaction and status monitoring system according to claim 1, characterized in that: The SysEx message adopts a unified frame structure: it consists of a frame header of 0xF0, a data payload segment, a CRC check segment, and a frame trailer of 0xF7. The data payload segment contains multiple physical quantity fields arranged in big-endian order, and the CRC check segment carries a 32-bit redundancy check code generated based on the IEEE 802.3 standard polynomial to ensure the integrity of data transmitted across protocols.

8. The cross-platform mobile power bank data interaction and status monitoring system according to claim 1, characterized in that: The smart power bank includes an analog front-end (AFE) circuit, which comprises: a 16-bit Σ-Δ analog-to-digital converter for high-precision voltage sampling; a bidirectional current sensing amplifier, used in conjunction with a precision shunt resistor for current measurement; and a digital temperature sensor connected via an I²C bus.

9. The cross-platform mobile power bank data interaction and status monitoring system according to claim 4, characterized in that, The accompanying application performs multi-level early warning linkage: secondary early warning: when the status parameter meets the first threshold, the UI interface status is updated; primary early warning: when the status parameter meets the second threshold, the kernel-level audio engine is triggered to play an alarm tone, and downlink transmission power limiting instructions are synchronized. Emergency Cut-off: When parameters indicate a serious fault, the smart power bank physically cuts off the gate drive signal of the internal power semiconductor switch, forcibly disconnecting the charging and discharging circuit.

10. A cross-platform mobile power bank data interaction method based on the system according to any one of claims 1 to 9, characterized in that, Includes the following steps: Establish a physical connection between the smart power bank and the terminal device, and complete the enumeration authentication based on MIDI-class devices; The smart power bank collects real-time battery operating parameters and performs displacement encoding based on 7-bit constraints, encapsulating the data into SysEx data packets for transmission; the terminal device receives and decodes the data packets via a MIDI interface, updating the status monitoring cache in real time; based on the matching of the monitoring results with the safety policy, it executes corresponding interactive feedback or hardware intervention protection actions.

Images