Patent Description:
With more and more audio algorithms are created and performed in the Vehicle Amplifier, the real-time data monitoring becomes more and more important. And the real-time data monitoring needs to support different data type, different data sampling rate and different data channels number. Currently there is no available tool to support the real-time data monitoring including the above three features at the same time. <CIT> describes systems and techniques for general purpose input/output (GPIO)-to-GPIO communication in a multi-node, daisy-chained network. In some embodiments, a transceiver may support GPIO between multiple nodes, without host intervention after initial programming. In some such embodiments, the host may be required only for initial setup of the virtual ports. In some embodiments, GPIO pins can be inputs (which may change virtual ports) or outputs (which may reflect virtual ports). In some embodiments, multiple virtual ports may be mapped to one GPIO output pin (with the values OR'ed together, for example). In some embodiments, multiple GPIO input pins may be mapped to one virtual port. For example, multiple GPIO input pin values may be OR'ed together, even if they come from multiple nodes.

The drawings referred to here should not be understood as being drawn to scale unless specifically noted. Also, the drawings are often simplified and details or components omitted for clarity of presentation and explanation. The drawings and discussion serve to explain principles discussed below, where like designations denote like elements.

Embodiments herein describe a system and a method of real-time data monitoring for vehicle amplifier system based on A2B bus. Usually, there are more and more algorithms which are performed in the vehicle amplifier system, such as the Road Noise Cancellation (RNC) algorithm, the Internal Engine Sound Synthesis (iESS) algorithm, and so on. With the system and the method described herewith, the tuning engineer can easily monitoring all the data in the vehicle amplifier for different data type, different data sampling rate and different numbers of data channels.

<FIG> illustrates an overview block diagram of system <NUM> for real-time data monitoring according to one or more embodiments. When performing tuning operation, the system <NUM> includes an amplifier <NUM> in a vehicle, a USB-to-A2B Box <NUM> which is connected to the amplifier <NUM>, and a monitoring device <NUM> connected to the USB-to-A2B Box <NUM>. The USB-to-A2B Box <NUM> is configured to transfer the data from the vehicle amplifier <NUM> to the monitoring device <NUM> for realizing the real-time data monitoring. The monitoring device <NUM> may be a personal computer, laptop, monitor, or any device that could run various applications.

<FIG> illustrates a block diagram of the system <NUM> for real-time data monitoring with details according to one or more embodiments. Similar with <FIG>, the system <NUM> includes a vehicle amplifier <NUM>, a monitoring device <NUM>, and a USB-to-A2B Box <NUM> which is connected between the amplifier <NUM> and the monitoring device <NUM>.

The amplifier <NUM> may include, for example, a digital signal processor (DSP) <NUM>, which may be preset a package protocol therein (the package protocol will be described below in details) and package the monitoring data into one or more physical A2B channels according to the data package protocol. The packaged data is passed through a master A2B <NUM>, and transferred to the USB-to-A2B Box <NUM> via an A2B interface <NUM>.

The USB-to-A2B Box <NUM> is configured to transfer the data from the vehicle amplifier <NUM> to the monitoring device <NUM> for realizing the real-time data monitoring. The USB-to-A2B Box <NUM> may include, for example, an A2B interface <NUM>, a slave A2B <NUM>, a processor <NUM> and a USB interface <NUM>. The USB-to-A2B Box <NUM> receives the packaged data, via the A2B interface <NUM>. The packaged data may be passed through the slave A2B <NUM> and the processor <NUM> and then be transferred to the monitoring device <NUM>, for example, via the USB interface <NUM>.

When the monitoring device <NUM> receives the packaged monitoring data, for example, via a USB interface <NUM> thereof, it can unpackage the transferred data by a visualizer application <NUM> according to the data package protocol and display the unpackaged monitoring data for the tuning engineer to monitor the data from the vehicle amplifier. The monitoring device <NUM> may be a personal computer, laptop, monitor, or any device that may run various applications.

In the system <NUM>, the data between the amplifier <NUM> and the USB-to-A2B box <NUM> is transferred by the A2B bus. The A2B bus may support maximum <NUM> physical data channels at <NUM> physical sampling rate in real-time. The data length is 32bits for every channel. The data between the USB-to-A2B box <NUM> and the monitoring device <NUM> is transferred by the USB bus. For supporting the monitoring of more than <NUM> physical data channels, the DSP <NUM> in the amplifier packages the monitoring data into the physical A2B data channels from the sampling rate of running data to the physical sampling rate, i.e., <NUM>. To do this, a data package protocol will be constructed to define how to package the monitoring data into the physical A2B data channel. The DSP in the amplifier follows the data package protocol to package the monitoring data. The data package protocol is constructed to support different monitoring data types, different monitoring data channel number and different monitoring data sampling rate. The data package protocol will be described below referring to <FIG>.

<FIG> illustrates an example regarding how to package monitoring data into data stream in one physical A2B channel according to a data package protocol. Based on the data package protocol, a data frame is configured to include one synchronization data unit (e.g., SYNC indicated in <FIG>), at least one information data unit (e.g., MAGIC indicated in <FIG>) and at least one monitoring data unit (e.g., DATA indicated in <FIG>) in one physical A2B channel. The frame showed in <FIG> is just an example for illustration. The length of the data frame may vary based on the sampling rate of the monitoring data.

For example, the SYNC data unit may be filled with a SYNC value for synchronizing the monitoring data in one physical A2B data channel. For example, it may be fixed as 0x68686868. The MAGIC data unit may be configured to include four sub-units which are respectively filled with four values represent different information. The length of each sub-unit may be a byte. For example, as indicated in <FIG>, the four sub-units may include a MAGIC ID sub-unit, an ID sub-unit, a SR sub-unit and a NS sub-unit. The MAGIC ID sub-unit is only an identification mark and may be fixed as, such as 0xBB. The ID sub-unit indicates the monitoring signal type. The user can totally define <NUM> signal types. The SR sub-unit indicates the sampling rate of the monitoring data, which is the running sampling rate of the monitoring data in DSP algorithm. The user may define only <NUM> sampling rate values. Other values are invalid. The NS sub-unit indicates the monitoring data channels number.

In one example, assuming a Road Noise Cancellation (RNC) algorithm is running in the amplifier, and <NUM> channels of sensor signals (ACC signals), <NUM> channels of microphone signals (MIC signals) and <NUM> channels of speaker signals (SPK signals) in <NUM> sampling rate needs to be monitored in real-time. That is, the monitoring data sampling rate is <NUM> and the physical A2B channel sampling rate is <NUM> as discussed above. So the number of the total data channels at <NUM> sampling rate in one physical A2B channel may be calculated as follows: <MAT>.

At the same time, the number of the data channels that will be consumed at <NUM> if using only one physical A2B channel, may be calculated as follows: <MAT>.

The CHtotal data channels is equal to the CHconsumed data channels, which means one physical A2B channel is enough for in the example. The data package result is given in <FIG>.

In another example, assuming a RNC algorithm is running in the amplifier, and <NUM> channels of ACC signals, <NUM> channels of MIC signals and <NUM> channels of SPK signals in <NUM> sampling rate needs to be monitored in real-time. That is, the monitoring data sampling rate is <NUM> and the physical A2B channel sampling rate is <NUM>. So the number of the total data channels at <NUM> sampling rate in one physical A2B channel may be calculated as follows: <MAT>.

The CHtotal data channels is less than the CHconsumed data channels, which means one physical A2B channel is not enough in this the example. The user needs to consider to move the last <NUM> SPK signals to the second physical A2B channel.

So the total data channels at <NUM> sampling rate in two physical A2B channels may be calculated as follows: <MAT>.

Also, the number of the data channels that will be consumed at <NUM> sampling rate if using two physical A2B channels, may be calculated as follows: <MAT>.

The CHtotaL data channels is larger than the CHconsumed data channels when using the two physical A2B channels. So the user needs to use two physical A2B channels for the packaged monitoring data in this example. The packaged data stream based on the data package protocol discussed above is showed in <FIG>.

Moreover, in another example, in the case that the Internal Engine Sound Synthesis (iESS) algorithm is running in the amplifier, the user needs to monitor <NUM> iESS signals at <NUM> sampling rate in real-time. That is, the monitoring data sampling rate is <NUM> and the physical A2B channel sampling rate is <NUM> as discussed above. So the number of the total data channels at <NUM> sampling rate in one physical A2B channel may be calculated as follows: <MAT>.

The CHtotal data channels is equal to the CHconsumed data channels, which means one physical A2B channel is enough for in the example. The packaged data stream based on the data package protocol discussed above is showed in <FIG>.

<FIG> illustrates a schematic view of packaged data in a physical A2B channel in the example of monitoring <NUM> channels of ACC signals, <NUM> channels of MIC signals and <NUM> channels of SPK signals in <NUM> sampling rate, and <FIG> is a partially enlarged view of <FIG> and <FIG> visually illustrate the packaged data stream according to the data packaging protocol discussed above.

<FIG> illustrates a schematic view of displaying for monitoring data in the visualizer. Although <FIG> shows ACC signal of the RNC algorithm in one channel as an example, it is presented just for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed.

In addition to the above examples, the data package protocol includes two special cases for <NUM> sampling rate and <NUM> sampling rate data monitoring at the same time. For the case of <NUM> data monitoring, there is no "place" in the data stream for the SYNC and the MAGIC pattern. In this case, the monitoring data may be considered as a signal with <NUM> sampling rate when the visualizer does not find the SYNC and MAGIC. However, the visualizer may not know the type of the signal.

For the case of <NUM> data monitoring, the user can place the SYNC pattern or MAGIC pattern in the data stream. In this case, if the visualizer detects only SYNC pattern with one following sampling data, then the sampling rate could be considered as <NUM>. If the visualizer detects only MAGIC pattern with one following sampling data, then the visualizer can extract the information from MAGIC and obtain the information of data type, data sampling rate and the number of data channel. It can be understood from another hand, in the case that only MAGIC pattern with one following sampling data can be detected, it can be derived by the visualizer that the data sampling rate should be considered as <NUM>, and the number of data channel should be fixed to <NUM>.

<FIG> illustrates a flowchart of a real-time data monitoring method for a vehicle according to one or more embodiments. As shown in <FIG>, at block <NUM>, a packaging step may be performed, for example by a DSP in the vehicle amplifier. The monitoring data is packaged into one or more physical A2B channels according to a data package protocol.

Then, at block <NUM>, the packaged monitoring data is transferred via a A2B bus. The packaged data is transferred by the amplifier to the USB-to-A2B box via the A2B bus. Then, the USB-to-A2B box transfer the packaged data to the monitoring device for example, via the USB bus.

At block <NUM>, the packaged monitoring data is unpackaged and the unpackaged monitoring data is displayed for the user. For example, the packaged monitoring data may be unpackaged by a visualizer in the monitoring device which has predetermined the data package protocol. Then, the unpackaged data is displayed for the user. By using this method showed in <FIG>, the user can monitor all the data in the vehicle amplifier for different data type, different data sampling rate and different data channel numbers. Furthermore, all the data can be monitored at the same time.

<FIG> illustrates a method of packaging data based on the data package protocol according to one or more embodiments. As shown in <FIG>, at block <NUM>, a first number value of total data channels for monitoring data may be calculated. For example, a first number value of total data channels may be calculated based on a sampling rate of monitoring data and an A2B channel sampling rate.

At block <NUM>, a second number value of consumed data channels for monitoring data may be calculated in the case of using one physical A2B channel. For example, a second number value of consumed data channels for monitoring data may be calculated based on the number of the signal types, the total number of signals and the number of information data unit for one physical A2B channel.

At block <NUM>, the first number value is compared to the second number value. If the first number value is equal to or larger than the second number value, then at block <NUM>, packaging monitoring data into one physical A2B channel. If the first number value is less than the second number value, then at block <NUM>, packaging monitoring data into more than one physical A2B channel.

The different examples, embodiments, and aspect described herein discuss monitoring all the data in the vehicle amplifier for different data type, different data sampling rate and different data channel numbers to optimize the user's convenience for system tuning.

Aspects of the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit," "module" or "system.

The present disclosure is a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out the method according to any one of claims <NUM>-<NUM>.

Claim 1:
A method of real-time data monitoring for a vehicle, comprising:
Packaging (<NUM>) monitoring data into one or more physical Automotive Audio Bus, A2B, channels according to a data package protocol;
Transferring (<NUM>) the packaged monitoring data via a A2B bus; and Unpackaging (<NUM>) the transferred data and displaying the unpackaged monitoring data,
characterised in that the data package protocol is configured to form a data frame including one synchronization data unit, at least one information data unit and at least one monitoring data unit for one physical A2B channel;
the synchronization data unit is filled with a value for synchronizing the monitoring data in one physical A2B data channel;
the information data unit includes four sub-units which are respectively filled with four values, each represents one of an identification, a signal type, a sampling rate and a number of data channels for the monitoring data; and wherein
the monitoring data unit is filled with the monitoring data associated with the information data unit.