HK1084269B - Method for managing an audio network - Google Patents

Description

Method for managing audio network

Technical Field

This description relates to managing audio networks.

Background

Family members may hear different audio selections in different rooms, however, no additional source is required for each room. A centralized source, such as a CD changer (CD changer) or digital music player connected to a master device in a master room, may be accessed and controlled by slaves in other rooms communicating with the master device.

Disclosure of Invention

In general, in one aspect, the invention features a method for a multi-zone audio communication network including at least one master device and a plurality of slave devices. The method includes the master device receiving a message including a command from a remote control or a control button on the device and transmitting the command to one or more slave devices.

Implementations may include one or more of the following features. The master device processes the message before sending and controlling the slave device. The command is transmitted to the one or more slave devices via the master device without being processed by the master device. The remote control controls both the master device and the slave device. The command is sent on a first communication channel between the master device and the slave device. The audio stream and commands are multiplexed on the first communication channel. The audio stream is transmitted on a second communication channel between the master device and the slave device. The first communication channel comprises a wireless channel. The slave device is dynamically configured to a plurality of regions via the remote controller. The slave device is also connected to a local audio source, from which the slave device selects for reproduction and an audio stream.

In general, in another aspect, the invention features a multi-zone audio network control system including: a master device and one or more slave devices; the master device includes circuitry that receives messages including commands from the remote control or control buttons on the device and sends the commands to the slave device.

In general, in another aspect, the invention features a method for an audio communication network including at least one master device and a plurality of slave devices, the method including: the master device controls one or more slave devices using a communication protocol, including: assigning a plurality of priorities to a plurality of messages; the highest priority pending message is sent from the master to the slave.

In general, in another aspect, the invention features a method for an audio communication network including at least one master device and a plurality of slave devices, the method including: controlling one or more slave devices from a master device using a communication protocol, comprising: assigning a plurality of priorities to a plurality of messages; in response to the polling message from the master device, a pending message of highest priority is sent by the slave device to the master device.

Implementations may include one or more of the following features. The highest priority pending message includes information for controlling the slave device.

In general, in another aspect, the invention features a method for an audio communication network including at least one master device and a plurality of slave devices, the method including controlling the plurality of audio devices from the master device, including polling a first group of audio devices in an off state for a first period and polling a second group of audio devices in an on state for a second period, wherein the second period is shorter than the first period.

Implementations may include one or more of the following features. Polling all members of the second group of audio devices, then polling a single member of the first group of audio devices, and repeating these steps in a sequential loop.

In general, in another aspect, the invention features a method that includes: when an audio device is in an on state, the slave master device controls one of the plurality of audio devices based on a zone associated with the audio device for playback from a source.

In general, in another aspect, the invention features a method that includes: when the audio device is in the local state, one of the plurality of audio devices is controlled from the master device, including transmitting all commands for the audio device that were transmitted by the master device but were not processed by the master device.

In general, in another aspect, the invention features a method that includes: controlling one of the plurality of audio devices from the master device includes monitoring keystrokes from a remote control for the audio device while the audio device is in a non-responsive state.

In general, in another aspect, the invention features a method for message synchronization for an audio communication system, the method including: the slave master device includes a plurality of audio devices controlled by the transmission of a plurality of messages, wherein each message is transmitted as a continuous string and wherein a predetermined minimum time delay is maintained between the end of a first message and the start of a second message.

In general, in another aspect, the invention features a method for an audio communication system, the method including: the plurality of audio devices are controlled from the master device over a wired network for one or more wired audio devices and over a wireless network for one or more wireless devices.

Implementations may include one or more of the following features. An acknowledgement is received in response to the polling message from each wired audio device and aggregate polling information is received from a wireless device indicating the status of the wireless device. A wireless device providing aggregate polling information locally polls the wireless devices for a predetermined period. The one wireless device transmits the aggregate polling information for a predetermined period of time.

In general, in another aspect, the invention features a method for an audio communication system, the method including: transmitting a plurality of audio streams over a network; and controlling one or more audio devices on the network to play each of the plurality of audio streams.

Implementations may include one or more of the following features. One of the plurality of audio devices is controlled to switch to playing a second of the plurality of audio streams based on a message from a master device on the network. The message includes information specifying the audio stream.

In general, in another aspect, the invention features a method for an audio communication network including at least one master device and a plurality of slave devices, the method including: transmitting an audio stream from an audio source comprising a network resource and a local resource attached to the audio device; and displaying information related to the audio source on the audio device.

In general, in another aspect, the invention features a method for an audio communication network including at least one master device and a plurality of slave devices, the method including: a message basically consisting of a header field, an address field, an argument field and a verification field is transmitted.

Implementations may include one or more of the following features. When the message is a polling message, the argument field of the message does not include any bytes, while the most significant bits of the address field identify the audio region of the audio device for play, and the least significant bits of the address field identify the audio device being polled.

In general, in another aspect, the invention features a method for an audio communication network including at least one master device and a plurality of slave devices, the method including: a message is received that consists essentially of a header field, an address field, an argument field, and a validation field.

In general, in another aspect, the invention features a method for an audio communication network including at least one master device and a plurality of slave devices, the method including: a message basically consisting of a header field, an address field, an argument field and a verification field is assembled.

Implementations may include one or more of the following features. And sending the message.

In general, in another aspect, the invention features an audio communication protocol for an audio communication network including at least one master device and a plurality of slave devices, the protocol including: a message format basically consisting of a header field, an address field, an argument field and a verification field. In some implementations, when the message is a polling message, the argument field of the message does not include any bytes, while the most significant bits of the address field identify an audio region for an audio device to play and the least significant bits of the address field identify the audio device being polled.

Advantages of the invention may reside in one or more of the following. The audio network control system is capable of operating with interchangeable slave devices (e.g., audio playback or audio information display devices). This allows multiple price points to be combined by mixing or matching master and slave devices. The slaves may use a common communication protocol. The master device need not be aware of the slave device characteristics or the specification of the user interface, and the slave devices may have a common set of capabilities in addition to using a common communication protocol. For example, all slave devices may respond to mute, un-mute and volume commands in a similar manner. Alternatively, certain slave devices (e.g., wireless devices) may share some common part of a common communication protocol (e.g., message format), but may be different in other respects (polling process).

The audio network control system also provides a seamless experience to the user across multiple rooms and multiple remote controls (remotes). In the remote control room, the system behaves substantially the same as it does in the main room. The role of the slave device is substantially the same as that of the master device in that it does with its own remote control. To achieve this seamless capability, the master device can dispatch commands received from a remote control (e.g., a Radio Frequency (RF) or infrared remote control) to the appropriate slave device. In order to guarantee interoperability with future slave devices with new characteristics, the master device can transmit unknown commands to the slave devices. The master device does not need to know what these commands are. In this regard, the master device acts as a router for determining where commands come from and are to be transmitted to. In some cases (e.g., audio source change commands), the commands are sent to a command handler of the master device. In other cases (e.g., unknown commands), the commands are routed directly to the slave device. The determination is based on the status of the slave device and the received command. In this way it is possible to create a system that can be extended to new types of slave devices.

Some slave devices may themselves be systems and may include control integration for other connected devices. Such control automation is typically accessed via a local remote control of the slave device. Remote access control automation from the master device may be supported via the routing mechanism described above. The master device does not need to do any additional processing to accommodate control integration at the slave device.

The communication protocol includes prioritized messages that allow local buttons on the speakers to control the main console. When the slave device is able to send all kinds of commands, such as status, back to the console, the highest priority message is a "control" command, e.g. when a local button on the slave speaker is pressed. The control commands are used to control the host console.

Other features and advantages of the invention will be apparent from the following description, and from the claims.

Drawings

FIG. 1A is a diagram of an audio network control system in a multi-room environment;

FIG. 1B is a diagram that diagrammatically represents the communication protocol of the audio network;

FIG. 2 is a diagram of hardware interfaces of master and slave devices;

fig. 3 is a circuit diagram of a transmitter;

FIG. 4 is a pulse timing diagram;

fig. 5A and 5B are circuit diagrams of a receiver;

fig. 6 is a layout view of pins;

FIGS. 7 and 8 are views of the connection of the pins;

FIGS. 9 and 10 are timing diagrams of communication protocols;

fig. 11-15 are bit sequences of data fields.

Detailed Description

1. Overview

FIG. 1A illustrates an audio network control system that includes a network of audio devices in a multi-room environment. The system includes a master device 110 and a slave device 112A located in a first room 120, slave devices 112B and 112C located in a second room 122, and slave devices 112D-112F located in a third room 124. The master device 110 may include, for example, a stand-alone console or a control program that uses the communication capabilities of a computer (e.g., a desktop, laptop, or handheld computer). Slave devices 112A-112D may comprise any of a variety of different devices including speakers, electronic devices with audio playback and/or recording capabilities, or devices that collect and/or display information about audio streams. The slave device communicates with the master device 110 via a communication channel (e.g., a wired bus or a wireless channel) according to a communication protocol 140 that includes a master device interface and a slave device interface as schematically illustrated in fig. 1B, as shown.

The user may control either device directly via local control buttons on the master or slave device or using one or more remote controls, such as remote control 130 for the master device or remote control 132 for the slave device. The IR remote control may provide controls similar to those located on the corresponding device. Commands from an IR remote control may be propagated to devices located in the same room as the IR remote control. Commands from the IR remote control may cause the local device to change state in some manner in response to received commands (e.g., turn on/off, change station, adjust volume, etc.).

In some implementations, one remote control, such as master remote control 130, may control both master device 110 and slave devices 112A-112D. For example, the RF remote control may control a master device, one or more slave devices, or both a master device and a slave device. In some implementations, the RF remote control does not directly control the slave device. Instead, a command issued from the RF remote controller is first transmitted to the master device, which then either acts on the command or transmits it to the slave device to function.

To coordinate the fact that the slave device can be controlled directly or through a single RF remote control, polling is used to obtain status information about the slave device. When the status of a slave device is changed using controls on the slave device or the IR remote control, the polling process obtains information about the changed status and provides it to the master device so that the master device knows the status of the slave device (or in some implementations at least a subset of the statuses such as on/off status, volume level, and mute status). Commands issued directly to the device via a physical interface or via an IR remote control may be treated differently than commands issued via an RF remote control (or a remote control in the same room as the master device). An IR remote control in the same room as the master device can issue commands through the master device and then serve the same function as an RF remote control located in a different room from the master device.

The remote control can comprise a two-way remote control. For example, a command is issued from the remote control to the master device, and data is sent back from the master device to the remote control for display to the user. The data provided back may be status conditions of various devices connected to the network or may be data related to various functions of the host device, such as data contained on a hard disk drive containing digital works to be performed for a user.

In some implementations, the slave devices 112A-112D also communicate with each other. In some implementations, the audio network control system 100 includes more than one master device.

The audio network control system 100 may be divided into multiple "zones". Each device is identified by an address, each room is identified by a room code, and each zone is identified by a zone code. For example, zone 1 may include devices in a first room and a second room (room a and room B), and zone 2 may include devices in a third room (room C).

Under normal operation, the master continuously polls all connected slaves to determine if they are on the network and on. For example, in one implementation, there are four possible states for the slave: "on", "off", "local", or "no response". Other implementations may include fewer or more than four states for the slave device. The command processing of the master device according to the status of the slave device proceeds as follows:

in all states, the master device 110 routes volume and mute commands from the master device 130 to the slave devices with matching room codes according to the communication protocol 140, as will be described in detail below. As a result of the polling, when the master device finds that the slave device has been switched on, the master device 110 will activate the appropriate zone and start playing the last selected source. If the zone is already playing, the slave device will join the current source for that zone. If master device 110 determines that all slave devices connected to a given zone are "off" or "local," that zone will be powered down.

When a slave device is in the "on" state, the master device will naturally process control commands known to the master device. Such as an unknown command from a slave device and having new characteristics that the master device 110 cannot recognize, is transmitted to the appropriate slave device. This allows the master device 110 to be extended to new classes of slave devices that may include appending new commands.

When a slave device is in the "local" state, all commands, including transport commands, are passed through the master device 110 to the appropriate slave device. The master device 110 does not process the transmit command locally. This substantially allows context sensitive transport commands to span all internal transports of the master device 110 and local transports of the remote control device.

When a slave device is in the "off" state, all commands, including the transmit command, are passed through the master device 110 to the appropriate slave device. This allows the slave device to be powered up by sending a local source selection command or an on/off command. In the case of an "on/off" command, the slave device will power up in its previously selected source. If the source is the master device 110, its status is set to "on" to be captured in the next polling cycle. This scheme is highly scalable, since each slave manages its own behavior, while the master 110 only needs to know a minimum amount about each slave.

When the slave device is in an "unresponsive" state (as would be the case, for example, with a third party amplifier), all commands, including the transmit command, are passed through the master device 110 to the appropriate slave device, as described above in the "off" state. However, the master device 110 will manage the on/off state variables for these slave devices by keeping track of the on/off and source selection keys from their remote controls. The master device 110 will know when to properly close an area (e.g., when all rooms using it are closed). If a slave powers up and starts responding on the network, the on/off status information in its response will be given higher priority and used to update the on/off status variable of the master 110 for that room.

2. Communication protocol

The communication protocol 140 allows the master device to support a predetermined number (e.g., 15 for an exemplary implementation) of networked slave devices, each of which has a unique address (no more than one slave device may use a given address). These addresses are for example RoomA, RoomB, RoomC, etc., up to RoomO (for 15 slave devices). The 16 th address (RoomP, effectively) is reserved for broadcast messages (intended for all slaves). The 15 slaves can play one of the audio streams (or none) of zone 1, zone 2 or any one of the additional zones at any given time in response to a remote command. Thus, for the communication protocol 140, a particular slave device can be identified by the room code alone, and any zone information sent to the slave device simply informs it of the audio stream to be played.

The communication protocol 140 has "plug and play" capabilities. New slaves may be added to the network at any time without powering down the entire network or other slaves, and without shutting down master 110.

One slave address (e.g., RoomO) may be used as the shared address and zone 2 variable audio output assigned to the master 110. Volume up/down commands set to the address from the RF remote control activate slave messages and control an internal volume control chip that feeds the zone 2 variable audio output.

3. Master circuit

3.1 general description

Fig. 2 shows an implementation of a master device of the stand-alone console 200. The hardware interfaces of console 200 include a control data bus 202, an audio interface 204, and a +10VTurn-On signal 206. The control Data bus 202 is a two-wire (Data and GND), bidirectional, half-duplex interface intended to be connected from the console 200 to a networked slave device 208. All data and control messages are sent via this bus 202. The message notification (messaging) is fixed at 19.2kbps and follows the packet and timing rules defined below.

Network lengths of up to 150 feet (from console 200 to the furthest slave on any module architecture (stub)) may be supported using cable connections that conform to one (or a combination) of the chain or star configurations described below. The networked slave devices are electrically connected in parallel.

The data signal has a 1k ohm pull up resistance to +5V at the console endpoint, and pauses at +5V (normally high) when no message is sent. The networked slave device optionally includes a 1 mega ohm pull-up resistor to the local +5V supply to bias the data signal to a known state when taken offline from the console. In some implementations, signaling (from console 200 and networked slaves) is accomplished through open collector transistors that pull the data signal down to local GND.

3.2 transmitter details

In this example, each slave is connected to the bus 202 signal through an open collector transistor capable of withstanding +5V and can be pulled down completely (ensuring saturation) with the worst case pull-up resistance (approximately 650 ohms, taking into account the effects of 15 slaves). Since the bus 202 may be arranged throughout the room and may pass through significant sources of electrical noise, a filter/guard should be provided (up to 100pF on the bus). Fig. 3 shows an exemplary output portion of a bus transmitter. Other transmitter layouts are possible. The electrical parameters of the transmitter are as follows:

a 120 foot speaker cable would load the network with an additional capacitance of about 0.1 uF. Thus, the waveforms shown in fig. 4 represent worst case drive waveforms for a start bit driven by a slave device onto a maximum length network loaded by a worst case number of speakers. Note the bit expansion due to bus capacity. The bit fall time should be about 10 times faster than the bit rise time. The parameters of this example are as follows:

3.3 receiver details

The bus receiver detects the slow transmission on the network and relays it to the microprocessor. The receiver circuit sets a low speed receive threshold of about 2.6V for the slave device and 3V for the console 200. No hysteresis is provided in this example. Thus, multiple transitions may be experienced on the edges of the noisy bits. If the slave cannot tolerate these transitions at its receiving algorithm, hysteresis should be added. Standard universal asynchronous receiver/transmitter (UART) devices and other schemes such as sampling bits near the center of a bit cell can tolerate multiple conversions. Reception schemes that use edge triggered interrupt decoded data to measure network high/low time periods (times) may require hysteresis unless there is sufficient delay in interrupting the traffic program before re-arming. Ideally, the software should perform a debounce scheme to perform pseudo-hysteresis regardless of the circuit used.

The bus receiver should also be tolerant to network transients. The receiver circuit is thus tapped off the protection node of the transmitter output stage, as shown in fig. 3. In this arrangement all data transmitted by the network slave will be fed back to its own receiver. The software should be robust enough to tolerate this. Exemplary +5V and +3.3V bus receiver circuits are shown in fig. 5A and 5B, respectively. The electrical parameters of the transmitter are as follows:

3.4+10V Turn-On line

The console 200 provides a +10V Turn-On signal 206. This signal is low (2.2K pulled down to ground) when there is no slave active in a given area, and high (current limited high side PNP switch providing from +8.8V to +10V depending on the load) when one or more slaves are active. The maximum drive capability is about 75mA at + 8.8V. Therefore, if the slave device uses this line for other purposes (Energy Star (power save mode) etc.), then consideration must be given to avoid causing each slave device to pull down a current higher than 5mA (5 mA-75 mA/15 slave device). Any such current pull-down should be temporary to reduce console power dissipation.

3.5 Audio interface details

The slave device interfaces include an audio interface 204 and a control data bus 202 as described herein. One type of audio signal output for a networked slave device is a fixed output (e.g., always sent at full volume). The volume control is performed in the slave device. This provides the maximum signal-to-noise ratio at the slave device. Variable outputs are also provided, for example to support legacy slave devices. The one or more audio signal outputs may be analog, digital, or a combination of analog and digital outputs. The distribution of audio signals will be described below in terms of a network of slave devices, i.e., a "smart speaker system" comprising a plurality of "smart" speakers having the capability to communicate with the master device 110 in accordance with the communication protocol 140.

For a "main room" smart speaker system, the console 200 provides differential digital audio streams based on S/PDIF on the zone 1 speaker output mini-DIN terminals 1 and 2, as will be described below. This audio stream is configured for a (non-standard) 3Vpp output level when loaded by the speaker, and is isolated and balanced by the transformer. A 390pF filter capacitance to ground was added, thereby reducing emissions. The console 200 can generate an audio stream at any data rate (frames per second (FPS)) from, for example, 48 to 192 kFPS. The console 200 can generate digital audio in any of the compression formats, such as PCM, AC-3, DTS, MPEG-2, or AAC formats. The compression format is recognized and decoded by the speaker.

With respect to the "non-main room" smart speaker system throughout the house, as will be described in detail below, a pair of analog stereo outputs (left/right for zone 1 and left/right for zone 2) are provided on the zone 2 speaker output mini-DIN connector. These left/right pairs are fixed outputs. The full scale (maximum) output signal is about 2Vrms and a typical playback level is about 300 and 400 mVrms. The playback levels for the console internal and external audio sources are scaled up in the console to play in equal amplitude.

These outputs are standard, single-ended analog outputs, driven essentially by an operational amplifier, with a series resistance of about 50 ohms added to each output. A 47uFDC suppression capacitor may be added to each output signal in the console, followed by a 100K ohm resistor, each referenced to analog ground of the console. It is desirable that this output impedance be able to drive up to 15 loudspeakers (with input stages defined below) without suffering from unwanted attenuation or loss of low frequency response. Wiring guidelines will be provided below to ensure proper area/area insulation and noise shielding.

Region 2 speaker output connector terminals 1 and 2 also provide a left/right variable analog signal pair for variable input speakers. These signals are the same as the zone 2 fixed output on terminals 3 and 4, but will be attenuated by the zone 2 volume control chip within console 200.

It has been found that the length of the audio cable routed through the house is susceptible to picking up an audible amount of noise. The speaker interfacing with the control data bus 202 should be configured as a differential amplifier at its audio input stage. As a reference for these differential amplifier inputs, a dedicated audio reference will be sent from the console 200 and included in the other network conductors. The wiring details will be described below. In some implementations, the characteristics of the networked speaker audio interface include:

the region 1 and region 2 input differential amplifier circuits should be identical (same gain, noise, order (floor) and bandwidth, consistent with the audio quality target of the speaker).

A differential amplifier should be used, all leads being balanced.

The resistance of each lead as viewed from the network should be 20K ohms or more. This allows, for example, a differential amplifier to be configured with a 10K ohm resistance at each lead.

Each lead should be capacitively coupled to the network, so that all capacitors have equal values. Each networked slave device may have its own capacitor value based on the expected frequency response.

The dedicated audio reference signal should be used for the differential amplifier as follows: region 1 left/right and region 2 left/right. To avoid audio current flowing back into the signal and thus damaging the zone 1/zone 2 isolation, an audio reference should be used only for the NON-INVERTING lead of the differential amplifier. No more than 1 microAmp (microAmp), rms of audio current should be conducted to the audio reference signal. This maintains an insulation of 92dB (considered to be an acceptable minimum).

A smart speaker developed for interfacing with the console 200 should have the ability to select one from two possible audio stream zone 1 streams or zone 2 streams. The selection is controlled via smart speaker commands. The smart speaker thus provides a 2-input, stereo audio Multiplexer (MUX) at its network audio input under the control of the microprocessor managing the smart speaker messages. To save costs, it should be prudent to configure the MUXs before the differential amplifiers to avoid degrading their performance or losing some of the above-mentioned characteristics.

3.6 Console speaker output mini-DIN connector

The console 200 has two 9-pin speaker output mini-DIN connectors, one for zone 1 and one for zone 2. Fig. 6 shows an exemplary pin arrangement for viewing a 9-pin mini-DIN connector (when inserted therein). The connector includes a conductive housing 600. The output pins of the connector are as follows:

region 1:

pin 1: S/PDIFO digital audio signal for main speaker (Z1_ NETO).

Pin 2: S/PDIF1 digital audio signal for the main speaker (Z1_ NET 1).

Pin 3: fixed LEFT analog audio signal for region 1 (Z1_ LEFT). Is not changeable.

Pin 4: zone 1 fixes the RIGHT analog audio signal (Z1_ RIGHT). Is not changeable.

Pin 5: and (3) ground.

Pin 6: the +10VTurn On signal for zone 1 (Z1_ TURON).

Pin 7: smart speaker DATA for zone 1 (Z1SPKR _ DATA).

Pin 8: and (3) ground.

Pin 9: is not connected.

A housing: and (3) ground.

Region 2:

pin 1: region 2 variable left analog audio signal (OUTLVAR).

Pin 2: region 2 variable right analog audio signal (OURVAR).

Pin 3: region 2 fixes the LEFT analog audio signal (Z2_ LEFT).

Pin 4: zone 2 fixes the RIGHT analog audio signal (Z2_ RIGHT).

Pin 5: buffered region 1 fixes the right analog audio signal (BZ1_ R).

Pin 6: the +10Vturn On signal for region 2 (Z2_ TURON).

Pin 7: smart speaker DATA for zone 2 (Z2SPKR _ DATA).

Pin 8: and (3) ground.

Pin 9: buffered region 1 fixes the left analog audio signal (BZ1_ L).

A housing: and (3) ground.

3.7 input Mini-DIN connector for networked speakers

The networked smart speakers likewise have a 9-terminal mini-DIN connector for connection to bus 202. The connector accepts left/right audio for zone 1 and zone 2, as well as data lines, digital ground and a separate ground that is used as a reference for the audio differential amplifier. Alternatively, a +10V Turn on signal may be introduced. Although these amounts total only 8 conductors, the speaker will be specified to use the same 9-pin mini-DIN as the console (although only a single one with respect to the pair), in order to allow the cable to be reversible.

The mini-DIN pinouts for the speakers are as follows:

pin 1: not connected (zone 2 of the console may change left analog audio).

Pin 2: unconnected (zone 2 of the console may change right analog audio).

Pin 3: region 2 fixes the left analog audio signal.

Pin 4: region 2 holds the right analog audio signal.

Pin 5: region 1 fixes the right analog audio signal.

Pin 6: the +10V Turn On signal for region 2.

Pin 7: smart speaker data for zone 2.

Pin 8: audio reference (dedicated ground for differential amplifier). Not connected to the product ground of the loudspeaker.

Pin 9: region 1 fixes the left analog audio signal.

A housing: ground is used as a digital (production) ground for the loudspeaker. The ground pin 8 in the speaker is not short-circuited.

3.8 routing details

In some implementations, the cable connecting the smart speaker to the console 200, zone 2 speaker output, has individually shielded 1: 1 Pass-through (Pass-through) pins 3 through 9, as shown in fig. 7. Pins 1 and 2 are not connected and the cable is reversible. When a speaker is connected to console 200 using an 8 conductor cable (available from Bose corporation, part number 257187) having 4 shielded twisted wire pairs, the connection shown in fig. 7 may be made.

Some conventional speakers (AM5P/AM20P, Bose corporation) may be plugged directly into the speaker connectors of zone 2 and work properly, and may co-exist with newer speakers (LSA2, a2, and Ballpark, Bose corporation). They use zone 2 variable left/right signals on pins 1 and 2, and a +10V Turn-on line on pin 6. Pin 8 is used to shield the Turn-on line and provide a speaker ground. The housing 600 is used as an audio reference in this speaker. These cables connect the internal shorting pin 5 to the housing ground, leaving the fixed right output of zone 1 unused for new speakers. If these loudspeakers need to share area 2 with a new loudspeaker, a special divider is used to avoid this (connecting the console's housing to the divider's output pins 5, but keeping the output's housing floating).

If any conventional speaker cable is plugged into zone 2 speaker output of console 200, then zone 1 fixed right audio output signal on pin 5 will be shorted to ground. Since the fixed right audio output is buffered, this signal can be shorted to ground if newer speakers do not need to be supported. However, if the new speaker is mixed with the conventional speaker, a specific separator is used. The connections in this divider are shown in fig. 8 (console terminal male and speaker output terminal female).

The conventional output of the separator has the following characteristics:

1. a plugged-in cable that shorts pin 5 to the housing will not short Z1 to the fixed right GND,

2. the ground of its pin 8 can be used for digital GND (for digital signals, and +10V Turnon).

3. Its housing ground is short-circuited to the pin 5 and can be used for left/right audio shielding.

The new speaker outputs of the divider are from the console mini-DIN full through pins 3 to 9 (and housing). The new speaker never uses the pin 1-2 variable audio signal, but can actually use the pin 1-2 as an audio output for an auxiliary device (e.g., a Ballpark base), so that these are not included in the separator.

4. Communication protocol details

The communication protocol 140 uses a single wire (two wire, including ground), two-way, half-duplex, signaling scheme between the console 200 and a set of networked speakers.

All communications are sent via speaker data conductors on cables running from speaker output mini-DIN connectors on the back of console 200 to the networked speakers. The idle state of this signal is a logic high (+5V) pulled up via a 1K ohm resistor in the console. The transmission is achieved through a direct keying (keying) console 200 and an open collector transistor stage in the speaker.

The protocol 140 uses a 19.2Kbps bit rate, a start bit, a stop bit, and non-parity bits. The message bytes are defined as follows. In the following example, the LSBs (least significant bits) of all message bytes are sent first.

4.1 allowable logic level

The logic levels for signaling are as follows (as seen on the speaker data conductor of bus 202):

4.2 bits wide

The 19.2kbps data rate used by all networked devices is guaranteed to fall within 0.5% of the rated rate. This guarantees an edge accuracy of the stop bit per byte to +/-5% (+/-10%, assuming worst timing error for both transmitter and receiver). Thus, the bit width is defined as follows:

these tolerances are applied to the bit widths as generated by the bus transmitter. On the worst-case network, the bit width actually received may be distorted.

4.3 message timing

To provide speaker synchronization, messages are grouped (sent as one continuous burst with no delay between bytes), and the internal message timing is controlled as follows:

fig. 9 shows an exemplary message (bus 202 idle high) for a common 4-byte command and reply as seen from the network.

4.4 message synchronization

As shown in the above table, the console 200 ensures that the network has at least 1.066mSec of idle time before starting a new transmission. This delay is intentionally longer than the delay allowable between console messages and speaker responses, enabling devices on the network to resynchronize with the console (ideally on an ongoing basis) when needed using a simple timeout. The recommended timeout for the speaker to resynchronize with the console is 916uSec (916uSec 767uSec + (1.066mSec-767 uSec)/2). If the speaker recognizes that the network has been idle for 916uSec, the speaker can re-prepare its receiving program and will start capturing the next console message correctly from it.

The speaker can identify the end of the inbound console message by waiting for the first network idle time that is really longer than 469uSec (the longest possible string of 1 (1's) within the message body). The recommended timeout is approximately 521 uSec. This gives the speaker 246uSec to check the received message and start its ACK/acknowledgement before 767 uSec.

If these message timings are recurring, then no loss of synchronization will occur (the network device should never inappropriately lose track of the beginning and end of the message). Nevertheless, the bytes of the message address and authenticator (verifier) should be checked to confirm that all received messages are valid. Furthermore, if it is detected that the network idle time is long enough to identify the end of the message, any partially received message of less than 4 bytes should be deleted and re-synchronized.

4.5 software drivers

4.5.1 Low-level receiver

Standard hardware UART receivers provide protection against noise and jitter/wobble distortion. Approaching this performance in software when a hardware UART is not available, the bit-bumped receiver program works as follows:

1. after confirming synchronization and an inbound (inbound) message may be expected, an edge triggered interrupt should be utilized to provide data input.

2. When the first edge of the message (the first start bit of the first byte) is detected, the noise should be rejected by resampling 1 to 2 more times immediately (debounce) (although noise is very rare on typical networks). If found valid, a state machine driven by the automatic reload 52.08uSec timeout should be implemented to sample the next 10 bits as close to the center of the bit cell as possible.

3. The first 8 stages of the state machine will collect the message bits. At the center of the bit cell, each of the 8 message bits should be sampled 1-3 times quickly and the appropriate value stored.

4. The timer interrupt routine for bit 9 (stop bit) should confirm that the bus is in an idle (high) state and re-provide an edge-triggered interrupt to the start bit of the next byte.

5. If the start bit edge of the new byte is detected before the 10 th 52.083uSec interrupt, the 10 th timer interrupt is removed and the newly input byte is combined as before (using this edge to resynchronize the timing of the 10-bit sampling engine). However, if the 10 th 52.083uSec interrupt expires first, the message ends. And thus the process ends. The slaves may immediately start generating their responses.

4.5.2 Transmit/receive timing of a Master device

In some implementations, the console 200 has a hardware UART assigned to the smart speaker interface. The following scheme will minimize the interrupts associated with managing the UART.

1. All out-of-band messages (N bytes) are sent at once. When the transmission is completed, the UART is set to interrupt the system. For messages longer than 16 bytes in the (rare) maximum UART buffer in the CS98200, the messages are sent segment by segment using interrupts, in the largest possible block (up to 16 bytes). This should be done so as not to introduce significant delays between bytes.

2. Once the out-of-band message ends, the UART is enabled and set to interrupt after receiving the byte (the first interrupt should occur within 1.288mSec, where 1.288mSec 767uSec response delay +520.83uSec first byte length). A timer interrupt is additionally provided to terminate at about 1.34 mSec.

3. If the 1.34mSec timer interrupt expires before the first full byte is received from the slave, then it is assumed that the slave is not activated and proceeds to poll the next slave.

4. Otherwise (if the slave responds), the interrupt continues on every byte received, and subsequent bytes should be received every 520.83 mSec. However, since a 1.066mSec synchronization delay is used before the console message, a 1.066mSec timeout (reset after each received byte) should be used to detect the end of the slave message.

Fig. 10 shows the message sequence in the case of a reply from a speaker and in the case of no reply from a speaker.

5.0 message packet overview

A message packet is defined as a set of bytes sent by a bus master (e.g., console) or slave (e.g., speaker). All bits of the message packet are set to one continuous burst (burst) with no breaks or delays between bytes. Messages of various lengths may be supported. Some implementations use the Header/Address/extensions/Verifer (Header/Address/argument/authenticator) format, as will be described below.

5.1 header byte (first message byte)

Messages on the bus 202, whether from the console/master or speaker/slave, start with a 1-byte header (this is the first byte sent). Bit 7 of the header is reserved to indicate whether the message was sent by the console 200 or by the speaker. For console messages, bit 7 is set to 0, and for speaker messages, bit 7 is set to 1.

Fig. 11 shows a diagram of the entire header byte including start and stop bits.

H7.. H0 (position 7.. 0): an 8-bit header identifier (see header definition described below). Thus, there may be 256 independent commands (128 from console to speaker, and 128 from speaker back to console, with bit 7 identifying the sender).

DIR (bit 7): a message direction indicator of 1 byte (0: transmitted from console/master, 1: transmitted from speaker/slave).

5.2 Console message Address byte (second message byte)

With respect to smart speaker messages, the second byte contains the message addressing. Fig. 12 shows a diagram of address bytes.

R3.. R0 (position 3.. 0): room number (0000-. Allowing 15 specialized rooms (called a-0). 0000B room a, 0001 + 1110B room B to 0, 1111B all rooms are used for broadcasting.

Z3.. Z0 (position 7.. 4): region number (0000-. Allowing 15 dedicated zones. Each region can be used to identify an intended audio stream.

When console messages do not cause the speakers to change their input stream/region selection, 0000 b-region 1, 0001-region 1110 b-region 2-regions 15 and 1111 b-all-regions are used.

Examples of address bytes (ignoring start/stop bits) are: zone 1, room a: 00000000b, zone 2, room I: 00011001 b.

The zone information contained in the address bytes is passed to the console 200, for example from an RF remote control, and identifies the audio stream selected by the speaker. Examples of valid options are: region 1(0000b), region 2(0001b), and all regions (1111 b). Other options are possible. For example, some options support each room with its own (independent) audio stream.

5.3 speaker message Address byte (second message byte)

The speaker address byte allows the speaker to respond indicating whether the speaker is off or listening to (one of its possible) local sources or one of the audio streams sent from the console 200 (zone 1 or zone 2). The format of this byte is shown in fig. 13.

R3.. R0 (position 3.. 0): as defined for the console 200: one of 15 possible rooms is indicated, but with an undefined 1111b for the speaker (since the speaker does not respond to the broadcast).

Z3.. Z0 (position 7.. 4): 0000-: one of 14 possible regions is played (0010b area 1, 0011b area 2, etc.).

1110 b: and playing the local source.

1111 b: and (7) breaking. Local or network sources are not currently playing.

5.4 argument bytes

After the address byte and before the authenticator byte of the end message, a message argument byte is included. The poll does not contain any argument bytes. Some smart speaker messages contain only 1 argument byte, but a speaker message may contain any number of argument bytes. The message definitions and details of the argument bytes used in the various commands are described below. Each argument byte is transmitted in the format shown in fig. 14.

A7.. A0 (position 7.. 0): an 8-bit message argument.

5.5 Authenticator bytes (last message byte)

The last byte of the smart speaker message is the authenticator byte. This byte is used to confirm that the basic message information is not corrupted. As shown in the message definitions below, within the argument field, a large volume of data payload is authenticated with greater robustness, which is typically a software exclusive or (XOR) of all previous message bytes, including local checksums, etc., although longer message forms may wish to use this byte to verify the header/address. Fig. 15 shows the format of this authenticator byte.

V7.. V0 (position 7.. 0): typically an exclusive or (XOR) of all previous message bytes.

6.0 exchange rules

"exchange" is defined as a set of two bus messages: a message from the console 200 to a particular speaker, and a sequential response sent from that speaker as a return. One of the rules governing this exchange is:

6.1 Only the Master generates an autonomous message

The console 200 is the master of all communications on the smart speaker bus 202. For example, only the console 200 generates spontaneous transmissions on the bus 202.

6.2 the Master does not interrupt the ongoing exchange

Regardless of the importance of the console/master's message being pending, the out-of-band transmission waits until the previously initiated exchange period is complete before initiating a new transmission. Messages from the console 200 or speakers in progress are not interrupted.

6.3 Slave devices only immediately send subsequent messages addressed to it

The slave/speaker is only sent immediately following the console message to which it has been specifically addressed (e.g., the slave does not send after the console broadcast), this rule holds regardless of the importance of the speaker pending message. It is the responsibility of the console to send messages (e.g., polls) to each speaker frequently enough and to ensure that the speaker has the opportunity to return upstream communications.

6.4 Slave devices respond to messages addressed to them

Unless the speaker is in an off state (where the Reply is optional), the slave/speaker replies to the console message to which it is addressed with some form of return message (where the default Reply is Poll _ Reply for the case where the slave has nothing of importance to communicate at that time). The acknowledgement is generated within an allowable delay time period (e.g., 767 uSec).

The speaker may respond to the console message with any of the following:

poll _ Reply message (4 bytes). This is the default speaker response that uses all subsequent polls, commands and queries unless an available higher priority response (including query response) needs to be sent.

PASS KEY CODE message (see message definition).

DOWNLOAD INFORMATION message, (see message definition).

6.5 Slave replies currently pending with highest priority information

The speaker/slave device may have multiple messages pending when the opportunity to send back to the console 200 comes. In this case, the highest priority message should be sent. A general guideline for possible message types is as follows:

6.5.1 highest priority: non-polling inquiry response

If the console 200 has sent a specific inquiry message (other than "poll", see message definition) to the speaker, the speaker will send the appropriate response as soon as possible. Lower priority replies may be sent until the inquiry reply is collected, but once collected, it is given the highest priority in the out-of-band queue.

6.5.2 medium priority: pass _ Key _ Code message

Certain buttons (or their local remote controls) pressed on the speaker/slave product may make an urgent request to change the console audio source, etc. The Pass _ Key _ Code message is defined as follows to transmit the appropriate press to the console 200. These messages should be given medium priority in the out-of-band queue of the slave (they should be pending but above the poll reply when the inquiry reply is available in the queue).

6.5.3 medium priority: download _ Information message

The Download _ Information message is defined below to allow the speaker/slave device to communicate data blocks with the console 200. It may be desirable for the data to generally represent information related to a local source being played from the device (e.g., the current AM/FM station). Such messages are given medium priority, the same as Pass _ Key _ Code. Therefore, they should be buffered in a FIFO in a Pass _ Key _ Code message, which is above the poll response, but is pending when all other specific inquiry responses are in the queue.

6.5.4 lowest priority: poll reply

When there are no other speaker messages in the out-of-band smart speaker queue, then a default Reply called Poll _ Reply (see message definition) is sent. This answer contains only basic information about the speaker on/off status and its volume level, which is considered less important than other classes of answers.

6.6 the Master polls all speakers continuously, but as a low priority

To allow the speakers to send information to the upstream console 200 in a timely manner. A polling message is sent as an opportunity to learn about the change in speaker status. For console messages, the speaker may selectively respond to polling using any of the above-listed messages. Full timing details of the console polling period will be described below. Typically, these polls are sent continuously, but only if there are no higher priority messages in the out-of-band queue of the console.

6.7 the Master sends the highest priority message currently pending

Just like the slave devices, the console/master out-of-band messages are assigned a priority. The highest priority message takes precedence over the lower priority messages as follows:

6.7.1 highest priority: non-polling query and control messages

If a query or control message needs to be sent to a particular speaker, it has the highest priority, see message definition.

6.7.2 medium priority: pass _ Key _ Code message

The console 200 can send RF commands directly to the speakers that are not used by the console. A Pass _ Key _ Code message, defined as follows, is used for this purpose. Such messages have a lower priority than queries but a higher priority than polls. When a Pass _ Key _ Code message is pending, the polling cycle is interrupted and (after any exchange in the process is completed), the Pass _ Key _ Code message is sent, and polling resumes.

6.7.3 medium priority: download _ Information message

The console 200 can Download a large block of data to the speaker using a Download _ Information message (see message definition). This may be used to update the application code for the speakers, etc. These messages are lower priority than the query, but higher priority than the poll. As with the Pass _ Key _ Code message, the polling cycle is temporarily interrupted to send any pending Download _ Information messages.

6.7.4 lowest priority: polling

Speaker polling is assigned a lowest priority which should indicate a period of consecutive messages sent when the console 200 no longer has important information to send. Sending these polls ensures that each speaker has a regular chance of sending a message upstream to the console 200.

6.8 Only one speaker is polled during an interrogation exchange

All interrogation exchanges between the console 200 and the speakers occur as follows:

1. when a query needs to be transmitted, the console 200 interrupts the normal polling cycle (after any exchange in progress is complete) and immediately sends the expected query to the appropriate speaker.

2. The speaker sends its reply in 767uSec, if possible. If not, it responds with a POLL _ RESPONCE message in 767 uSec.

3. The console 200 stops (with) polling all other speakers and only polls the speaker every 6 mSec. The speaker responds with a POLL response message until it is ready for an inquiry response, and once ready, it responds with the expected inquiry response.

4. After receiving the expected query response, the console 200 resumes a normal polling period for all speakers. Alternatively, if the speaker fails to answer at all, or the answer is off, normal polling can resume as judged by the higher level software.

6.8 full List Command used outside the Main Room

The speaker in the "main room" uses the message definition described below. Speakers outside the main room use only limited control messages: such as volume up/down, mute/un-mute, and on/off. All other special controls for the speaker can be handled by passing remote control commands transparently through the console to the speaker (using Pass _ Key _ Code commands), where they will be interpreted appropriately.

The following is a list of commands that may be received by non-main room speakers. See message definition, below are details of composing the message.

6.8.1 Polling and Polling response messages (header 0x00/0x80)

The poll is the lowest priority message, determined by the polling period, sent by the console 200 to all speakers continuously. The console 200 uses to continuously monitor the on/off, local/network and volume/mute status of all speakers and provide frequent opportunities for speakers to send messages to the console 200. Interrupts whenever a high priority message needs to be sent. The speaker typically replies with polling replies, but if any are pending, replaces the higher priority reply.

6.8.2 on/off message (header 0x01)

This message may be used by the console 200 to turn the speakers on or off. The speaker may also be turned on after receiving a number of different passing RF remote control buttons or after receiving a command from a local IR remote control. In these cases, polling is used to detect its power-up.

6.8.3PASS _ KEY _ CODE message (header 0x0D/0x8D)

This message may be used by the console 200 (using header 0x0D) to convey speaker-specific RF remote control commands. The console 200 may not interpret these commands at all. Using header 0x80, the speaker will be able to communicate the push of the button upstream back to the console 200.

6.8.4SET _ MAIN _ ATTENTION message (header 0x02)

The console 200 may use the Mute and Return _ to _ Last _ Volume arguments as a broadcast in response to a full Mute event.

6.8.5QUERY _ SPEAKER _ INFO message (header 0x0B)

The console 200 uses the message to determine the various speakers attached. Console 200 may also use Query _ Main _ Activity and Query _ Download _ Info _ State arguments

6.8.6DOWNLOAD _ INFORMATION message (header 0x0A/0x8A)

This message (header 0x0A) may be used to push the status information of console 200 into the speaker, or may be used to send other data blocks to the speaker (possibly application code updates, etc.). Using header 0x8A, the speaker can upload the data block to the console using this message type (e.g., source related data will be displayed).

7.0 Polling cycle

7.1 overview

The standard response to the poll may provide basic speaker status information regarding its on/off status, local/network listening mode, its mute status and its volume level. The speaker has the ability to replace its standard poll reply with a higher priority message (if pending), providing an opportunity to transmit important button presses and data blocks upstream to the console 200.

Speakers connected to the network may be disconnected for extended periods of time. When switched off, the speakers need only be polled occasionally to detect the moment when they are switched on by a keystroke. However, speakers that are both connected and turned on should be polled quickly to ensure good response time to messages sent upstream to the console 200. Thus, polling cycles are described that can meet these needs, and their performance is controlled so as to be predictable and gracefully degraded as the number of speakers that are switched on increases.

7.2 Polling cycle timing details

The polling process organizes the 15 possible speakers into two lists: the currently on speaker and the speaker that is not currently on (disconnected or disconnected). The console first polls all members of the currently on speaker list (up to 15, in order) and then polls a single member (if any) that is not on the on list. This represents a sub-period of the polling period. The sub-period is then repeated (without interruption) using the same list of on speakers, but without the next member of the list of off speakers (in a round robin fashion).

For example, if only speaker a is switched on. Then, the total polling period should be:

AB. AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, and then this is repeated without interruption. The total number is 14 subcategories.

One sub-period 11 mSec. The total period is 153 mSec.

If it is known that only speakers C and G are switched on, then the polling period should be:

CGA, CGB, CGD, CGE, CGF, CGH, CGI, CGJ, CGK, CGL, CGM, CGN, CGO, and then repeated. For a total of 13 sub-periods.

One sub-period is 16mSec, and the total period is 214 mSec.

If all speakers are switched on, the polling period should be:

ABCDEFGHIJKLMNO, and then repeated. 15 sub-periods.

One sub-period is total period-82 mSec. This results in a maximum latency for messages from the speaker to the console.

If all speakers are off, the polling period will be the same as if all speakers were on. 15 sub-periods.

The longest total period is any 7 speakers turned on, the rest turned off.

One sub-period 44 mSec. The total period is 351 mSec. This has the longest latency for identifying that the speaker is on.

When each SUBCYCLE of the polling cycle is completed, the list of speakers of the on and off groups should be updated based on the polling response. The previously not switched on loudspeaker that answered switched on in the last sub-period will be immediately moved to the switch-on list. All previously switched on speakers that answered off or failed to answer for all 5 total sub-periods will be moved to the off list. When polling is first initiated after a console reset, all speakers are in the off-list.

7.3 exemplary Polling and reply message bytes

Unless a console or speaker has a higher priority message to transmit, the system will default to a polling cycle using messages of the following format:

console polling (3 bytes)

First (header) byte: 0x00 (polling message).

Second (address) byte: according to existing normal protocols.

Third (authenticator) byte: according to existing normal protocols.

Speaker poll answer (4 bytes):

first (header) byte: 0x80(POLL REPLY).

Second (address) byte: speaker address bytes, including on/off/local/network status.

Third (argument) byte: the volume/mute state is entered as follows:

argument details:

position 6.. 0: the main attenuation level of the loudspeaker, according to the existing standard protocol.

Bit 7: a mute state: mute 1.0 is not mute.

Fourth (authenticator) byte: according to existing standard protocols.

7.4 use the PASS _ KEY _ CODE message as a response (header 0x8D)

As with any of the console messages below, this (4 byte) message following the console poll message will be returned if available for transmission, rather than the SPEAKER INFO acknowledgement (0x 8C). The argument byte will contain a key code identifier associated with one of the 256 possible button meanings. Description of the drawings: existing key codes for IR/RF remote controls may be used if possible.

7.5 use DOWMOAD _ INFORMATION message (0x8C) as reply

This (N byte) response, which follows any console message that includes a poll, will be returned instead of the speech _ INFO response (0x8C), if available for transmission. The argument/data byte contains any type of data, high level command, or query (all now undefined) intended for the console. This can be used to transfer data related to the local source to the console for display on the remote control. This also allows the speaker to directly command source changes etc. or request area/source special status information for local display (tuner station playing etc.).

8.0 advanced speaker control issue

8.1 Master/Slave architecture

There is only one master on a given bus. The bus master may initiate a transmission at any time as long as the bus is idle (it allows all messages and replies in the current process to be completed before initiating a transmission) and as long as it complies with the message timing details described below.

The speakers only send the following messages to them through the console. However, as described below, any console message may be used as an opportunity for the speaker to initiate transmission.

8.2 Room addressing is dedicated

The new speaker added to the network has a dedicated 4-bit room address (RoomA to RoomO, matching the remote control that is trying to run the speaker) that is set appropriately before connecting to the network.

8.3 message separation physical bus for zone 1 and zone 2

The console 200 has two separate physical smart speaker buses (one for each speaker output connector). Zone 1 and zone 2 audio streams are available on the zone 2 speaker output connectors, and zone 2 speaker data signals are also available on the zone 2 speaker output connectors. The room B to room 0 speakers may be plugged into the zone 2 speaker output connectors and may be controlled using the zone 2 speaker data signals.

8.4 speaker control mode

Smart speaker messages are defined to allow two different modes of controlling the speaker: a main mode and a pass mode. The master mode command allows a control unit (e.g., a console) to track all critical speaker parameters and communicate these parameters to the speakers as absolute values at the appropriate time. The pass-through mode allows the low-intelligence control unit (as simple as the IR/Smart speaker protocol bridge) to efficiently pass remote control messages directly to the speaker. In this mode, the speaker keeps track of the critical parameters (last volume level before muting, etc.).

A console wishing to control networked speakers via a master mode maintains a table that describes the available characteristics (type and range of control, etc.) of each speaker to be controlled.

8.5 detecting new loudspeaker

After power-up (hardware reset), the networked speaker is responsible for entering the OFF STATE (hardware muted, with its lowest current STATE). In this state, only the hardware responsible for the network interface is operable. The Speaker can receive and reply to (at least) the poll message, Query Speaker Info message, and on/off message.

Since the console continuously polls all possible speaker room addresses, the speakers newly added to the smart speaker bus are detected as soon as they reply to the polling. Once the new Speaker has been detected, the console will transmit a Query Speaker Info message to identify its type.

8.6 power-on networking speaker

An on/off message should first be used to turn on any command other than the POLL or Query Speaker Info message to the networked speakers. This allows the hardware of the speaker to become fully operational. The console 200 will delay as appropriate to allow the power up process to be completed. If a table describing the power-on delay for each networked speaker is not available, console 200 will use a default delay time of 1 second.

8.7 detecting speaker status changes by polling

During polling, bit 7..4 of the address byte that the speaker responds to will contain information about its ON/OFF state and the source it is playing (zone 1, zone 2, or its own local source), as follows:

z3.. Z0 (position 7.. 4): 0000-: one of 14 possible areas is played (0010b area 1, 0011b area 2, etc.).

1110 b: and playing the local source.

1111 b: and (5) disconnecting. Local or network sources are not currently playing.

By monitoring these bits, the console can detect when a subsequent change in the vital state occurs.

8.7.1 speaker on/off

The speakers may be switched on or off by means of buttons on the unit itself or an IR remote control via them, or via remote control commands that simply pass through the console but do not need to understand their meaning. Using the address Z3., Z0 bits, the console 200 monitors the on/off status of each speaker. This allows the console 200 to be powered down when, for example, all speakers are turned off.

8.7.2 speaker source variation

Similarly, the speakers may be switched between zone 1 and zone 2 (or local sources) without having to use the console 200 to pre-process it. By monitoring the state of the same address bits, console 200 can detect such a source change and take appropriate action (such as powering up/down the appropriate audio path).

8.8 managing speaker stream switching

The speakers have the ability to select either area 1 or area 2 networked analog output from the console. The speaker will enable this selection to be performed automatically by reacting to the zone bit in the address byte of each console Pass _ Key _ Code message (header 0x0D) and on/off message (header 0x 01). These messages are transmitted to the speaker as a direct result of the button press on their RF remote control and therefore have their zone bits (which are transmitted directly from the remote control to the speaker) set precisely when received in a message from the remote control. Since the console responds to the pressing of all remote control source (AM/FM, AUX, CD/DVD, etc.) buttons, an on/off message is included that ensures that the networked speakers are turned on and non-muted when a source is selected. The Pass _ Key _ Code message transmitted to the speaker playing the local source does not switch the speaker out of local mode.

Pass _ Key _ Code messages delivered to the speakers and with On/OFF button arguments allow them to power up in the source (network or local) they last played. If the speaker chooses to play a networked stream/region at this point, then in this case it selects the stream indicated in the message address (as opposed to the last played stream).

9.0 message definition

9.1 fast reference table

9.2 messages transmitted by Console

The following messages are an example of a set of message definitions that may be communicated by the console 200. '

9.2.1 Polling message (header 0x00)

The sender: control console

Total bytes: 3

Queue priority: is low in

The polling message is the only 3 byte message specified so far. The 4 most significant bits of its address byte identify the appropriate audio region for speaker playback. The 4 least significant bits identify the speaker being polled (by its room number, as set by speaker DIP switching).

The argument is not needed so it is omitted to preserve network bandwidth.

The polling message is transmitted, which acts as if it were simply in the form of a query to obtain polling response information, and the speaker is provided with regular opportunities to transmit any other important messages.

Polling messages

9.2.2 on/off message (header 0x01)

The sender: control console

Total bytes: 4

Queue priority: height of

The on/off message informs the addressed smart speakers to be fully powered up in preparation for playing audio, or to be powered down after a conversation. Note that: when the source button on the remote is pressed, this command is used by the console to ensure that the speaker is fully powered up, unmuted, and the desired network input stream is selected.

On/off message

It is desirable to require a certain amount of time for the lead wire (rail) of the speaker power supply, etc., to be set before being un-muted (or perhaps before the speaker is ready to receive other commands). After being switched on, the system can address this issue in three ways:

1. the readiness of the SPEAKER can be queried by the console (using the QUERY SPEAKER STATUS command, ON/OFF state arguments) before issuing a command to configure its SPEAKER mode, attenuation level, etc.

2. The speaker may simply choose not to respond to a subsequent command such as SETSPEAKER MODE before being ready to mute.

3. The console may establish a delay (typically about 1 second) between transmitting the on/off message and transmitting any subsequent messages.

9.2.3 setting the Main decay message (header 0x02)

The sender: a console.

Total bytes: 4.

queue priority: high.

The set primary attenuate message command addresses the smart speakers to change their master volume setting to the indicated level. Note that: the argument contains a new level expressed as dB of attenuation, where 0dB represents the maximum volume of the loudspeaker. The available dynamic range of the Speaker is conveyed by the Query Speaker Info answer.

Setting a master damping message

9.2.4 set Assist level message (header 0x03)

The sender: control console

Total bytes: this queue priority: height of

Setting assistance level messages

9.2.5 set EQ type/tone level message (header 0x04)

The sender: control console

Total bytes: 4

Queue priority: height of

Setting EQ type/tone messages

9.2.6 set speaker mode message (header 0x05)

The sender: control console

Total bytes: 4

Queue priority: height of

Set speaker mode message

9.2.7 control effect message (header 0x06)

The sender: control console

Total bytes: 4

Queue priority: height of

Selecting effect messages

9.2.8 selection of Audio input message (header 0x07)

The sender: control console

Total bytes: 4

Queue priority: height of

Selecting audio input messages

9.2.9 select decompressor message (header 0x08)

The sender: control console

Total bytes: 4

Queue priority: height of

Selecting decompressor messages

9.2.10 selection post-processing message (header 0x09)

The sender: control console

Total bytes: 4

Queue priority: height of

Selecting post-processing messages

9.2.11 download information message (header 0x0A)

The sender: control console

Total bytes: 5-255

Queue priority: medium and high grade

The DOWNLOAD INFORMATION message has a format that allows up to 250 bytes of data to be transferred to the speaker via the smart speaker packet itself, where the payload (including local checksums, etc.) may be defined as desired. Variables for these messages can be defined to write directly to the VFD of the speaker, or to announce changes in the console state (new source/new track/station being played, etc.)

Downloading information messages

9.2.12 Inquiry speaker information message (header 0x0B)

The sender: control console

Total bytes: 4

Queue priority: height of

Interrogating speaker information messages

9.2.13 transport Key code messages (header 0x0D)

The sender: control console

Total byte 4

Queue priority: medium and high grade

In this case, transmitting the key code message is used by the console to transmit the RF remote control button press to the speaker. The argument byte contains the key code byte as received from the RF remote control.

Transmitting key code messages

9.3 messages transmitted by the loudspeaker

The following is an example message that may be transmitted by the speaker (network/slave).

9.3.1 Polling reply message (header 0x80)

The sender: loudspeaker

Total bytes: 4

Queue priority: is low in

Polling response message

9.3.2 download information message (header 0x8A)

The sender: loudspeaker

Total bytes: 5-255

Queue priority: medium and high grade

Downloading information messages

9.3.3 Inquiry speaker information response message (header 0x8C)

The sender: loudspeaker

Total bytes: 4

Queue priority: height of

Inquiry speaker information response message

9.3.4 transport Key code messages (header 0x8D)

The sender: loudspeaker

Total bytes: 4

Queue priority: medium and high grade

In this case, the speaker sends a local speaker button press to the upstream console using a transmit key code message. The argument bytes should contain the key code bytes received from the speaker's local IR remote control.

Transmitting key code messages

10.0 Wireless device

In an exemplary audio network system including wireless devices, the wireless devices are responsible for the integrity of messages transmitted over the wireless channel. It applies the downstream transmitted message from the console to the speaker (downlink) and then passes it back ("return link"). Any additional error protection/correction is added by the wireless transceiver to ensure an agreed level of robustness.

No poll from the console is transmitted across the wireless link. Instead, the wireless slaves will locally poll the speakers attached to them and respond to the wireless master once every 20 mSec. The wireless master device will buffer the replies and transmit them locally to the console in response to appropriate polling. Details will be provided below. In some cases, the wireless master device also generates a default reply (header 0x80) in response to all other (i.e., higher priority) messages from the console until the inquiry reply is returned via the return link.

The slave device implements a smart speaker interface, the presence of which causes the speakers to be connected "identically enough" to the console. This includes polling the speakers in a manner similar to the console, interrupting the polling to immediately transmit a message downstream to the speakers, and combining all of the polling response information and sending it to the console via a return link. Polling of slaves is somewhat simplified, so that a given topology advantage is that one wireless slave is dedicated to each network speaker.

10.1 local Polling cycle for Slave devices

Since the console-generated polling is not transmitted to the slave devices, each slave device actively identifies its associated speaker and manages the local polling period. The wireless slave device need only poll the single speaker attached to it-no local polling is needed for the other speakers. To determine the room code of the speaker attached to it, the wireless slave device will make a relatively simple version of the polling cycle performed in the console, as follows:

1. the wireless slave device will continuously poll all possible speakers until one is found that answers.

2. The wireless slave device then polls only that speaker at a rate of 20 mSec.

3. If the speaker stops responding, the wireless master device begins polling all possible speakers again until the responding speaker is found (which may be a new room code).

To ensure that one poll response is combined in time within each 20mSec return link time period, the slave device will synchronize in time the local polling periods of the wireless slave devices, thereby enabling polling exchanges to occur immediately prior to the transmission of each return link message (starting approximately earlier than 6mSec, allowing time for the combination of the replies included in the return link messages). Thus, a high priority message (local button press, etc.) to the speaker will experience a latency of about 20mSec before there is an opportunity to transmit from the slave device to the wireless master device (first time).

10.2 priority of Console messages during local Polling

As described previously, the transmission of console messages takes priority over the polling information recovered from the speakers. Thus, when a slave device receives a message from the console that is intended for a speaker attached to it (e.g., a PASS _ KEY _ CODE message), the message should be immediately transmitted to the speaker regardless of the timing of the local polling period.

10.3 local retry rules for Slave devices

Each slave device needs to manage two cases where retries can be used.

The speaker fails to reply to a message transmitted to the local speaker of the slave device.

A situation where a message transmitted by the slave device (slave speaker) to the console via the return link (e.g., a PASS _ KEY _ CODE message from the speaker) is not properly received by the wireless master device.

In the first case, the slave device locally manages the console's message to the speaker for immediate retry. The rule requires only one retry. If the retry interferes with the scheduled local polling of the Yankee 0 device, it is still acceptable.

The second case assumes that some feedback from the wireless master device to the slave device immediately follows the transmission of a message via the return link. Such feedback should be defined to be included during every next wireless 20mSec polling period. In practice, it should take the form of requesting a retry from the wireless master device to each affected (affected) slave device. If the slave device sees this retry request, it should again forego transmitting polling information to the wireless master device in its next opportunity to transmit information over the return link, but rather support transmitting the last speaker message again. The retry mechanism should continue as long as the message needs to be delivered to the wireless master device and managed by the wireless master device. Here, 100mSec (5 retries) may be a better limit. Note that speaker polling can continue through the retry case to allow the speaker polling information to be updated (overwritten, not buffered) and messages to be buffered in a (small) queue for the opportunity to wait for the next transmission via the return link

10.6 general responsibilities of Wireless Master device

As mentioned, the wireless master device satisfies the console polling protocol by replying to all messages and polling information received from the speakers/slaves at the appropriate time, and in fact, can virtually assume that the console is hardwired to its set of speakers. There is little departure from this situation. The details are as follows.

10.6.1 caching speaker poll acknowledgments for local use

As long as there are no higher priority pending messages from the speakers, the wireless device sends a Poll _ Reply (0x80) message to all connected speakers in response to all console messages. To generate these Poll _ Reply, it buffers the return link messages generated by the slave's local polling period and formats the appropriate Reply using the messages within the timing constraints.

Since the polling information represents ongoing updates of the same state variable, the buffer of polling state for each speaker will only be one message deep and will be continually updated as updated data is taken from the speaker. If the wireless master device receives invalid reply data (invalid checksum, etc.) from a given speaker, the wireless master device will reply to the console with the (old) data stored in its buffer. If the wireless master fails to receive a valid poll reply message from a given speaker within 5 seconds, the wireless master will empty the poll status buffer associated with that speaker and begin rejecting replies when the console polls. It is the responsibility of the console to eliminate that speaker, etc., from the list of on speakers.

10.6.2 Replacing higher priority speaker messages for poll acknowledgments

As described in the previous section, the speaker replies to the console with pending messages with the highest priority return message (where the poll reply is used as a default). Thus, to simulate this, the wireless master device identifies from a given speaker the time when a message with priority over Poll _ Reply is pending and replaces the message with the default Poll _ Reply after the next console message for that speaker. If both medium and high priority messages are pending, the high priority message is transmitted first.

Communicating these higher priority messages to the console does not destroy the poll status buffer for each speaker. Once the higher priority message is delivered to the console, the wireless master will Reply back with a Poll _ Reply message.

10.6.3 responsibility for higher priority console messages

As described, the wireless master device responds to all console messages. This is true regardless of the priority of the console messages (see message definitions). The response begins within the 767uSec window described above. Once the console is answered, the radio subsystem assumes responsibility for reliable delivery of all medium or high priority console messages to the speaker (including managing retries) since the console thereafter believes that they have been received by the speaker and may lose the ability to manage retries at a higher level.

10.6.4 enquiring about responsibilities during the exchange

As described in the previous section, when the console transmits a query to a particular speaker, it (console) will stop polling other speakers until the response is returned. Instead, it will continue to poll the speakers for which an acknowledgement is pending. In this case, the wireless master device simply continues to respond to the polling of the console until:

1. the console decides to abandon and resume polling the other speakers, or

2. The desired speaker where the inquiry reply comes will be given priority by the wireless master device over the polling reply and thus transmitted to the console in response to the next available poll.

10.6.5 requesting retries from the slave device

Since the wireless return link is less reliable than the downlink, high priority messages from the slave device may be corrupted upon arrival at the wireless master device. In this case, the wireless master device may continue to request retries from the slave device until the message is transmitted intact.

Claims (4)

1. A method for an audio communication system, comprising:

controlling a plurality of audio devices from a master device over a wired network for one or more wired audio devices and over a wireless network for one or more slave wireless devices;

receiving an acknowledgement from each wired audio device in response to a polling message from the master device; and

receiving from one of the slave wireless devices acting as a wireless master device, in response to a polling message from the master device, aggregate polling information indicating a status of slave wireless devices, wherein the master device's polling message is not transmitted to slave wireless devices other than the wireless master device, the aggregate polling information including information that the slave wireless device locally polls for and replies to an attached audio device.

2. The method of claim 1, wherein the slave wireless device locally polls for attached audio devices for a predetermined period.

3. The method of claim 1, wherein the wireless master device transmits the aggregate polling information at predetermined time intervals.

4. The method of claim 1, further comprising:

receiving, at each of the slave wireless devices, a message from the wireless master device, wherein the message consists of a header field, an address field, an argument field, and an authenticator field;

determining whether the message is a polling message based on an argument field of the message, wherein when the message is a polling message, the argument field of the message does not include any byte;

if the message is a polling message, an audio zone for play by the slave wireless device is identified based on the 4 most significant bits of an address field of the message, and the slave wireless device being polled is identified based on the 4 least significant bits of the address field.