Text preview for : FedXSmartSpeaker1.6.pdf part of Bose LS 28,35,48 series II BoseLink series II Protocol Specifications
Back to : FedXSmartSpeaker1.6.pdf | Home
Postman2/FedX Hardware Interface Specifications
P2/FedX Smart Speaker Interface Spec DS 268891
Rev 1.6
7/28/03
REVISIONS .................................................................................................................................................................5 1.0 SPEC OVERVIEW .........................................................................................................................................6
1.1 SCOPE ...................................................................................................................................................................6 1.2 DEFINITIONS .........................................................................................................................................................6 1.3 GUIDING PRINCIPLES ............................................................................................................................................6 1.4 NEW FEATURES ....................................................................................................................................................7 1.5 OPERATIONAL OVERVIEW ....................................................................................................................................7 2.0 FEATURES OF THE POSTMAN2/FEDX SMART SPEAKER BUS ............................................................9 2.1 2.1 2.2 2.3 2.4 DIFFERENCES FROM POSTMAN1 ...........................................................................................................................9 NUMBER OF SPEAKERS SUPPORTED PER ZONE.....................................................................................................9 PLUG AND PLAY CAPABILITY ..............................................................................................................................9 SUPPORT FOR LSA1 ON ZONE2 ............................................................................................................................9 SUPPORT FOR A SINGLE LEGACY VARIABLE SPEAKER.........................................................................................9
3.0 PHYSICAL (HARDWARE) INTERFACE ..................................................................................................... 10 3.1 OVERVIEW OF THE PHYSICAL BUS ..................................................................................................................... 10 3.2 TRANSMITTER DETAILS ..................................................................................................................................... 10 3.2.1 Reference Transmitter Circuit ................................................................................................................... 10 3.2.2 General Transmitter Electrical Requirements ........................................................................................... 11 3.2.3 Worst-Case Drive Waveforms ................................................................................................................... 11 3.3 RECEIVER DETAILS ............................................................................................................................................ 12 3.3.1 Reference Receiver Circuits....................................................................................................................... 12 3.3.2 General Receiver Electrical Requirements ................................................................................................ 12 3.4 +10V TURN-ON LINE ........................................................................................................................................ 13 3.5 AUDIO INTERFACE DETAILS............................................................................................................................... 13 3.5.1 Console S/PDIF Output for the Main Room .............................................................................................. 13 3.5.2 Console Analog Outputs for Non-Main Rooms ......................................................................................... 13 3.5.3 Differential Inputs for Networked Speakers............................................................................................... 13 3.5.4 Zone1/Zone2 Input Selection MUX for Networked Speakers .................................................................... 14 3.6 THE P2/FEDX CONSOLE SPEAKER OUTPUT MINI-DIN CONNECTORS................................................................ 14 3.7 THE INPUT MINI-DIN CONNECTOR FOR NETWORKED SPEAKERS ...................................................................... 15 3.8 CABLING DETAILS ............................................................................................................................................. 15 3.8.1 Bose Pre-Terminated Cables ("Zone 2 Expansion Cables") for New Speakers ........................................ 15 3.8.2 Using the Bose System Cable (257187) with New Speakers ...................................................................... 16 3.8.3 Connecting Legacy AM5P/20P Speakers .................................................................................................. 16 3.8.4 Connecting Legacy LSA1 Speakers ........................................................................................................... 16 3.8.5 Connecting Legacy 901P Speakers ............................................................................................................ 17 3.8.6 Mixing Legacy and New Speakers On the Same Network ......................................................................... 17 3.8.7 Using Existing Bose Wall Plates, etc. ........................................................................................................ 18 4.0 LOW-LEVEL PROTOCOL BASICS .............................................................................................................. 19 4.1 ALLOWABLE LOGIC LEVELS .............................................................................................................................. 19 4.2 ALLOWABLE BIT WIDTHS .................................................................................................................................. 19 4.3 MESSAGE TIMING REQUIREMENTS .................................................................................................................... 20 4.4 GUARANTEEING MESSAGE SYNCHRONIZATION ................................................................................................. 20 4.5 RECOMMENDATIONS FOR SOFTWARE DRIVERS ................................................................................................. 21 4.5.1 Optimized Low-level Receiver ................................................................................................................... 21 4.5.2 Transmit/Receive Timing for the Master ................................................................................................... 21 5.0 MESSAGE PACKET OVERVIEW.................................................................................................................. 22 5.1 HEADER BYTE (1ST MESSAGE BYTE) ................................................................................................................ 22 5.2 CONSOLE MESSAGE ADDRESS BYTE (2ND MESSAGE BYTE).............................................................................. 22
5.3 SPEAKER MESSAGE ADDRESS BYTE (2ND MESSAGE BYTE) .............................................................................. 23 5.4 ARGUMENT BYTE(S) .......................................................................................................................................... 23 5.5 VERIFIER BYTE (LAST MESSAGE BYTE) ............................................................................................................ 23 6.0 RULES FOR EXCHANGES ............................................................................................................................ 24 6.1 ONLY THE MASTER GENERATES SPONTANEOUS MESSAGES ............................................................................. 24 6.2 THE MASTER NEVER INTERRUPTS AN EXCHANGE IN PROGRESS ....................................................................... 24 6.3 A SLAVE ONLY TRANSMITS IMMEDIATELY FOLLOWING MESSAGES ADDRESSED TO IT ................................... 24 6.4 A SLAVE MUST REPLY TO EVERY MESSAGE ADDRESSED TO IT ....................................................................... 24 6.5 A SLAVE MUST REPLY WITH THE HIGHEST-PRIORITY INFORMATION CURRENTLY PENDING ........................... 24 6.5.1 Highest Priority: Non-Poll Query Replies ............................................................................................... 24 6.5.2 Medium Priority: Pass_Key_Code Messages .......................................................................................... 24 6.5.3 Medium Priority: Download_Information Messages .............................................................................. 25 6.5.4 Lowest Priority: Poll Replies ................................................................................................................... 25 6.6 A MASTER CONTINUOUSLY POLLS ALL SPEAKERS, BUT AS A LOW PRIORITY .................................................. 25 6.7 A MASTER MUST TRANSMIT THE HIGHEST-PRIORITY MESSAGE CURRENTLY PENDING .................................. 25 6.7.1 Highest Priority: Non-Poll Queries and Control Messages .................................................................... 25 6.7.2 Medium Priority: Pass_Key_Code Messages .......................................................................................... 25 6.7.3 Medium Priority: Download_Information Messages .............................................................................. 25 6.7.4 Lowest Priority: Polls .............................................................................................................................. 25 6.8 ONLY ONE SPEAKER WILL BE POLLED DURING A QUERY EXCHANGE ............................................................. 25 6.8 FULL LIST OF COMMANDS USED OUTSIDE THE MAIN ROOM ............................................................................ 26 6.8.1 POLL and POLL REPLY Messages (Headers 0x00/0x80) ....................................................................... 26 6.8.2 ON/OFF Message (Header 0x01) ............................................................................................................. 26 6.8.3 PASS_KEY_CODE Message (Headers 0x0D/0x8D) ................................................................................ 26 6.8.4 SET_MAIN_ATTENUATION Message (Header 0x02) ............................................................................ 26 6.8.5 QUERY_SPEAKER_INFO Message (Header 0x0B) ................................................................................ 26 6.8.6 DOWNLOAD_INFORMATION Message (Headers 0x0A/0x8A) ............................................................. 26 7.0 THE POLLING CYCLE .................................................................................................................................. 27 7.1 7.2 7.3 7.4 7.5 OVERVIEW ........................................................................................................................................................ 27 POLLING CYCLE TIMING DETAILS..................................................................................................................... 27 TYPICAL POLL AND REPLY MESSAGE BYTES ..................................................................................................... 28 USING THE PASS_KEY_CODE MESSAGE AS A REPLY (HEADER 0X8D .......................................................... 28 USING THE DOWNLOAD_INFORMATION MESSAGE (0X8A) AS A REPLY .................................................. 28
8.0 HIGH-LEVEL SPEAKER CONTROL ISSUES ............................................................................................ 29 8.1 MASTER/SLAVE CONFIGURATION ..................................................................................................................... 29 8.2 ROOM ADDRESSING MUST BE UNIQUE ............................................................................................................. 29 8.3 MANAGING SEPARATE PHYSICAL BUSES FOR ZONE1 AND ZONE2 .................................................................... 29 8.4 SPEAKER CONTROL MODES .............................................................................................................................. 29 8.5 DETECTING NEW SPEAKERS.............................................................................................................................. 30 8.6 POWERING-UP NETWORKED SPEAKERS ............................................................................................................ 30 8.7 DETECTING SPEAKER STATUS CHANGES THROUGH POLLING ........................................................................... 30 8.7.1 Speaker Turn On/Off.................................................................................................................................. 30 8.7.2 Speaker Source Changes .......................................................................................................................... 30 8.8 MANAGING SPEAKER STREAM SWITCHING ....................................................................................................... 30 9.0 MESSAGE DEFINITIONS .............................................................................................................................. 31 9.1 QUICK REFERENCE TABLES .............................................................................................................................. 31 9.2 MESSAGES SENT BY THE CONSOLE ................................................................................................................... 32 9.2.1 POLL Message (Header 0x00) ................................................................................................................. 32 9.2.2 ON/OFF Message (Header 0x01) ............................................................................................................. 33 9.2.3 SET MAIN ATTENUATION Message (Header 0x02) .............................................................................. 34 9.2.4 SET SECONDARY LEVELS Message (Header 0x03) .............................................................................. 35 9.2.5 SET EQ TYPE/TONE LEVELS Message (Header 0x04) .......................................................................... 36
9.2.6 SET SPEAKER MODE Message (Header 0x05) ...................................................................................... 37 9.2.7 CONTROL EFFECTS Message (Header 0x06) ........................................................................................ 38 9.2.8 SELECT AUDIO INPUT Message (Header 0x07) ................................................................................... 39 9.2.9 SELECT DECOMPRESSOR Message (Header 0x08) ............................................................................. 40 9.2.10 SELECT POST PROCESSING Message (Header 0x09) ........................................................................ 41 9.2.11 DOWNLOAD INFORMATION Message (Header 0x0A) ....................................................................... 42 9.2.12 QUERY SPEAKER INFO Message (Header 0x0B) ................................................................................ 43 9.2.13 PASS KEY CODE Message (Header 0x0D) ........................................................................................... 44 9.2.14 INSTALLER SERVER PUSH Message (Header 0x11) ........................................................................... 45 9.2.15 INSTALLER SERVER EXEC Message (Header 0x12) ........................................................................... 46 9.3 MESSAGES SENT BY SPEAKERS ......................................................................................................................... 48 9.3.1 POLL REPLY Message (Header 0x80)...................................................................................................... 48 9.3.2 DOWNLOAD INFORMATION Message (Header 0x8A) ......................................................................... 49 9.3.3 QUERY SPEAKER INFO REPLY Message (Header 0x8C) ..................................................................... 50 9.3.4 PASS KEY CODE Message (Header 0x8D) ............................................................................................. 52 9.3.5 QUERY INSTALLER SERVER REPLY Message (Header 0x13).............................................................. 53 10.0 DETAILS RELATED TO ARROW .............................................................................................................. 54 10.1 OVERVIEW ...................................................................................................................................................... 54 10.2 MESSAGE ROBUSTNESS THROUGH ARROW..................................................................................................... 54 10.3 MANAGING ARROW MESSAGE LATENCY ........................................................................................................ 54 10.4 GENERAL RESPONSIBILITIES OF THE SLAVE .................................................................................................... 54 10.4.1 The Slave's Local Polling Cycle ............................................................................................................. 54 10.4.2 Priority of Console Messages Over Local Polling ................................................................................. 55 10.4.3 Local Retry Rules for the Slave ............................................................................................................... 55 10.5 GENERAL RESPONSIBILITIES OF THE MASTER ................................................................................................. 55 10.5.1 Buffering Speaker Poll Replies to Use Locally ....................................................................................... 55 10.5.2 Substituting Higher-Priority Speaker Messages for Poll Replies ........................................................... 56 10.5.3 Responsibilities for Higher-Priority Console Messages ......................................................................... 56 10.5.4 Responsibilities During a Query Exchange ............................................................................................ 56 10.5.5 Requesting Retries from Slaves ............................................................................................................... 56 11.0 DETAILS RELATED TO COBALT2 ........................................................................................................... 57 12.0 DETAILS RELATED TO BALLPARK ........................................................................................................ 58 12.1 NETWORK MASTER/SLAVE RESPONSIBILITY .................................................................................................. 58 12.2 LATENCY OF MESSAGES ................................................................................................................................. 58 12.3 SHARING SMART SPEAKER WITH ETAP .......................................................................................................... 58 13.0 DETAILS RELATED TO SA2/SA3............................................................................................................. 59
13.1 STANDARD MODE ........................................................................................................................................... 59 13.1.1 Pass_Key_Code ...................................................................................................................................... 59 13.1.2 Mute_All_Assert .................................................................................................................................. 59 13.1.3 Mute_All_De-assert ................................................................................................................................ 59 13.2 GANGED MODE ............................................................................................................................................ 59 13.2.1 Maintaining State Synchronization ......................................................................................................... 59 13.3 LEGACY SUPPORT......................................................................................................................................... 59
Revisions
Rev 1.0 1.1 1.2 1.3 Date 2/10/03 2/25/03 3/4/03 5/23/03 By Details of Changes Created initial revision, based on Extensions to the Normal Protocol document. Still need to add info about using existing Bose wall plates, etc. Modified sections 3.3.1 and 3.3.2 to add a reference receiver circuit for speakers with 3.3Vrails, but no +5V rails. Modified the splitter diagram in section 3.8.6 to disconnect pins 1-2 from the New Speaker end. This allows Ballpark to output audio on these pins. Added Mute All Assert and De-Assert message definitions to section 9.2.3. Updated the Section on LSA. Updated console message Address byte definition: now zone bits must be set to 1111 for all Polls, Queries and Set Main Attenuation messages (any spontaneous console messages unrelated to remote button presses, and which should NOT cause stream-select changes in the speaker). Added section 8.8 to describe this. Refined the definition of Mute All to include ALL speakers, regardless of the source being listened-to (local sources or the two networked streams/zones). Also refined the definitions for which messages are used by speakers to control switching between networked streams. Removed the zone 1111 definition, since this is needed for Mute All assert/de-assert broadcasts. Zone switching is now limited by definition to be controlled only by On/Off messages and Pass-Key-Code messages--zone bits of all others are ignored. Changed RoomG references to RoomO (room address for the remote controlling the variable outputs), per Marketing's . Also, integrated Bill 's re-write of Setion1 (adding Guiding Principles, etc.). Published to WindChill as DS268891 revision A (clayj).
1.4
5/29/03
1.5
6/17/03
1.6
7/28/03
,
1.0 Spec Overview
1.1 Scope
The Postman1 Normal protocol was developed to allow bidirectional control of Cobalt2-class speakers at 4800 baud. The NPP process has recently produced a need to expand the protocol to support a network of "speakers" with numerous new features. This spec seeks to define an expanded form of the Normal protocol which enables these new features. Furthermore, this spec provides the necessary hardware interface and cabling details required to properly define, create and install networked devices. To guarantee compatibility with other network devices, and to avoid corruption of networked control signals and audio streams, the guidelines described in this document should be followed as closely as possible.
1.2 Definitions
Console: A Lifestyle head unit capable of sending Smart Speaker commands. Slave Device: A Smart Speaker or integrated system which functions as a playback device for a Lifestyle console. Network mode: The mode in which a slave device plays back audio from the Lifestyle console. Local mode: The mode in which a slave device plays back audio from its internal transports or a locally connected device. This audio is not passed through the Lifestyle console.
1.3 Guiding Principles
This section outlines the guiding principles behind the design of the Smart Speaker specification. This serves as a high level description of how a Lifestyle system should operate in a multi-room environment. A primary goal behind the design of the Smart Speaker specification was to create a system with interchangeable playback devices. This allows multiple price points to be assembled by mixing and matching consoles and slave devices. In order to ensure interoperability with future devices, all slave devices must look the same to the console. They must all speak a common protocol. The Lifestyle console should not need to know the specifics of the slave device's features or UI. In addition to speaking a common protocol, all slave devices must have a common set of behaviors. For instance, all slave devices must respond to mute, unmute, and volume commands in a similar manner. Another goal behind the design of the Smart Speaker specification is to provide the user with a seamless experience across multiple rooms and multiple remotes. The system should behave largely the same in a remote room as it does in the main room. A slave device should function largely the same when using the Lifestyle remote as it does with its native remote. In order to accomplish this seamless behavior, the Lifestyle console must dispatch commands received from an RF remote to the appropriate slave device. To ensure interoperability with future devices with new features, the Lifestyle console must be able to pass unknown commands through to the slave device. The console need not know what the command is. In this respect the console functions as a router, determining where a command came from and where it should be sent to. In some cases (e.g. a source change) the command is sent to the console's command processor. In other cases (e.g. an unknown command), the command is routed directly to the slave device. This decision is based only on the state of the Smart Speaker and the command received. In this way it is possible to create a system that is extensible to new types of slave devices. Some slave devices will themselves be systems, and will include control integration for other connected devices. Such control automation will normally be accessed through the slave device's native remote. It is logical to ask how that control automation could be accessed from the Lifestyle remote. Such control automation is available to the extent that it can be supported via the above routing mechanism. No additional processing will be done by the Lifestyle console to accommodate control integration at the slave device.
1.4 New Features
· Some speakers may be hardwired to the network, and others connected through Arrow-class wireless transceivers. Such transceivers will transfer 1-way audio from the console to networked speakers, and 2-way Smart Speaker control information between the console and speakers. Latencies for such transceivers need to be supported. · Speakers will no longer be dedicated (necessarily) to a specific zone. Instead, the 15 networked speakers will be able to dynamically jump from one zone to another. Changes may need to be made in the protocol's addressing to allow this. · Speakers may have a local means for choosing between Postman2/FedX networked audio or its own local sources (Ballpark will have an internal tuner and CD player, for example). Such means may include source select buttons on the speaker itself, or on local remote controls (IR, for example). The protocol must provide a method for identifying when speakers are and are not listening to networked audio, so the console can power up/down appropriately. A polling structure needs to be implemented to identify these changes. · Variants of RF remote controls should be capable of controlling both the Postman2/FedX console as well as the speakers' local sources. The protocol needs to expand to allow transport, volume/mute and other proprietary speaker-only keys from these remotes to be relayed down the Smart Speaker bus for use by the speaker at any time, including in local playback mode or OFF mode. · Lower priority: Local buttons on the speakers themselves may need to control the FedX console. The protocol needs to support a means for transmitting these key commands from the speaker back to the console. Potentially, this should also include a means to make more direct changes to FedX system status variables (source being played, track, station, presets, etc.). · Lower priority: Speakers may have local VFD's, etc., capable of displaying FedX source information as well as local source information. The protocol needs to define a means for broadcasting FedX source-related information to interested speakers, as well as (potentially) a means for specific speakers to request such information on demand. · Lower priority: Ballpark-class products may need to push display information onto a local Hermes-class remote control (when Hermes is controlling Ballpark's local sources). The protocol needs to expand to allow source-related information to be passed up to the console, to be brokered out to the RF remote.
1.5 Operational Overview
This section contains a brief overview of how a multi-room Lifestyle system operates under normal circumstances. It is intended to give the reader a basic understanding of what goes on in the system, without all of the detail. It is not intended to cover every possible scenario, and is not a substitute for the complete documentation found later in this document and others. Under normal operation, the Lifestyle head unit continuously polls all connected Smart Speakers to determine if they are on the network and turned on. There are four possible states for a Smart Speaker: "On", "Off", "Local" or "Not Responding". The console's command processing proceeds according to the state of the speaker as follows: In all states the Lifestyle head unit will route volume and mute commands from the Lifestyle remote to the slave device (with the matching room code) via the Smart Speaker protocol. When, as a result of polling, the Lifestyle console discovers that a slave has been turned on, it will light up the appropriate zone and begin playing the last selected source. If the zone is already playing, the speaker will join the current source. In the event that the Lifestyle console determines that all speakers connected to a given zone are either off or local, it will power down that zone.
When the slave device is in the "On" state, transport controls are processed natively by the Lifestyle's internal transports or by the UEI subsystem. Keycodes that are not native to the Lifestyle unit will be passed through to the remote device. This allows the Lifestyle console to be extensible to new classes of slave devices which may require additional controls beyond those currently envisioned. When the remote device is in the "Local" state, all controls, including transport controls, will be passed through the Lifestyle head unit to the remote device. Transport controls will not be processed locally by the Lifestyle head unit. This allows fully context sensitive transport controls across all the Lifestyle internal transports as well as the remote device's local transports. When the remote device is in the "Off" state, all controls, including transport controls, will be passed through the Lifestyle head unit to the remote device. This allows the remote device to be powered up by means of sending a local source select command or an On/Off command. In the case of an On/Off command, the remote device will power up in its previously selected source. If the source was the Lifestyle head unit, the state is set to On, which will be caught in the next polling cycle. This scheme is highly scaleable in that each remote device manages its own behavior, and the Lifestyle needs to know only a minimal amount about each remote device. When the remote device is in the "Not Responding" state (as will be the case for third-party amplifiers, for example), all controls, including transport controls, will be passed through the Lifestyle head unit to the remote device, exactly as for the Off state, above. However, the console will manage on/off state variables for these slaves by keeping track of on/off and source select keypresses from their remotes. This is necessary so that the console will know when to properly shut-down a zone (when all rooms using it are off). Note: if a slave powers-up and begins replying on the network, the on/off state information in its replies will be given higher priority, and used to update the console's on/off state variables for that room.
2.0 Features of the Postman2/FedX Smart Speaker Bus
2.1 Differences from Postman1
The Postman2/FedX Smart Speaker protocol is based on the Normal protocol used in Postman1, but includes some significant changes. The nature of these changes makes the two protocols incompatible. In brief, they include: · Increasing the signaling speed from 4800 bps (bits per second) to 19.2k bps. · Tighter restrictions on message packetization and message/reply timing. · Adding a direction bit to message headers (indicating whether a message is being sent by the P2/FedX console, or by a speaker). · Changes to the speakers' Address byte. · Eliminating the 1-byte speaker ACK. Speakers now reply with a 4-byte Poll_Reply message as a default, but can substitute higher-priority messages, if any are pending. · Implementing a new polling cycle, by which the console remains in continuous contact with all speakers. · New message type definitions, including a means for passing-through remote control keypresses from the console to speakers, and vise-versa. · A new capability for speakers to reply with all message types. Details of each of these changes are provided in the next sections.
2.1 Number of Speakers Supported per Zone
Postman1's Normal protocol allowed up to 7 speakers on each of its two sub-networks (Zone1 and Zone2), each with addresses from A to G. To fully identify a given speaker, the system needed both room and zone addressing. This has changed somewhat for P2/FedX. The P2/FedX Smart Speaker protocol is defined to allow a console to support up to 15, total, networked speakers, each with a unique address (no more than one speaker may use a given address). These addresses are referred to in this document as RoomA, Room B, RoomC, etc., up to RoomO. A 15th address (RoomP, effectively) is reserved for broadcast messages (intended for ALL speakers). These 15 speakers may play EITHER the Zone1 or Zone2 audio signals (or neither) at any given time, in response to remote control commands. Therefore, for P2/FedX, the room address ALONE identifies a specific speaker-- any zone information sent to a speaker simply informs it of the audio stream meant to be played.
2.2 Plug and Play Capability
New speakers can be added to the network at any time, without powering-down either the network or the speakers, and without turning off the console.
2.3 Support for LSA1 on Zone2
Because the Postman2/FedX console has two separate (though time-shared) Smart Speaker buses, the console can use two different communication protocols for each Speaker Output connector. Cobalt2 will be connected to the Zone1 Speaker Output (using the protocol in this document). If no other new speakers are required to be attached to the Zone2 Speaker Output, its protocol can be set via the OSD to Legacy, to support connecting a single LSA1.
2.4 Support for a Single Legacy Variable Speaker
One speaker address will be shared with the P2/FedX Zone2 variable audio outputs. Volume Up/Down commands from an RF remote control set to this address with initiate Smart Speaker messages as usual, but will ALSO control the internal volume control chip feeding this Zone2 variable output (available from the Zone2 Speaker Output miniDIN on the back of the console). Presently, this shared address is defined to be RoomO. Note: Postman1 used RoomG.
3.0 Physical (Hardware) Interface
The Postman2/FedX Smart Speaker Interface uses essentially the same circuit as Postman1. The physical interface remains the same, with slight improvements to tolerate the increase in bit rate and increased speaker loading. The complete hardware interface consists of the bus (control data) interface, audio interface, and a +10V Turn-On signal to support legacy speaker systems. NOTE: no attached network device may disable network communication or degrade its audio quality at any time, including while OFF or while unplugged/unpowered.
3.1 Overview of the Physical Bus
The Smart Speaker Bus is a two-wire (Data and GND), bidirectional, half-duplex interface intended to be connected from the Postman2/FedX console to each networked Smart Speaker. All data and control messages are sent via this bus. Messaging is fixed at 19.2kbps, and follows packetization and timing rules defined in this document. Network lengths up to 150 feet (from the console to the furthest speaker on any stub) can be supported, with cabling following either a daisy-chain or star configuration (or combinations thereof)-- the only requirement is that electrically all networked speakers must be wired in parallel. Provisions have also been made to support use of the relatively high capacitance, yellow, 8-conductor, Bose-provided speaker wire sold through PTS. Suggested connection guidelines are provided below. Loading has been calculated to support up to 15 networked speakers, provided that they follow the hardware guidelines defined here. The Data signal has a 1K Ohm pullup resistor to +5V at the console end, and idles at +5V (normally high) when no messages are being sent. Networked speakers may optionally include a 1Meg Ohm pullup resistor to a local +5V source to bias the Data signal to a known state when disconnected from the console. All signaling (from the console as well as networked speakers) is achieved through open-collector transistors which pull the Data signal to a local GND. More detailed circuit requirements are provided below.
3.2 Transmitter Details
As described, each device interfacing to the bus must signal through an open-collector transistor capable of tolerating +5V, and able to fully pull-down (guaranteeing saturation) with the worst-case pullup resistance (about 650 Ohms, factoring in the effect of 15 receivers). Since the bus will be strung throughout a home, and potentially past significant electrical noise sources, filter/protection components should also be provided (100pF, max on bus).
3.2.1 Reference Transmitter Circuit
For reference, the suggested output section of a bus transmitter is: +5V (+/- 10%)
1K (for console) 1Meg (for speakers) 2SC3395 (PT192603), or equiv. Transmit data (from micro)
100 Spark Gap
To Smart Speaker Bus (Data signal)
>5V
100pF
To Receiver NOTE: if the micro uses a standard UART, another logical inversion may be needed, preceding this stage.
3.2.2 General Transmitter Electrical Requirements
Regardless of the transmitter topology used, it is essential that its parameters be controlled as follows: Parameter Capacitance connected directly across the bus (Speaker Data to ground) Transmit logic Low on the bus Allowable Value 105pF, max (100pF, 5% capacitor, max). < 1.0V, max. with a test circuit consisting of a 618 Ohm pullup resistor from Speaker Data to +5V (modeling the effect of 15 worstcase receivers). This is roughly equivalent to the performance of a saturated NPN with 100 Ohms series resistance, as suggested. High impedance at the transmitter (open-collector NPN). Local transmitters may have no less than 1M Ohm, min, pullup to a local +5V rail.
Transmit logic High on the bus
3.2.3 Worst-Case Drive Waveforms
120 feet of Bose speaker cable would load the network with about .01uF of extra capacitance. Therefore, the following would represent a worst-case drive waveform for a start bit driven by a slave onto a maximum-length network loaded by the worst-case number of speakers. Drawing is NOT to scale. Note the widening of the bit due to bus capacitance. Bit falltimes should be about 10 times faster than risetimes under all situations. Maximum-length network (worst-case) drive waveform using suggested transmit and receive circuits:
5V Risetime dictated by bus capacitance. 3V tfall trise 0.86V, max.
520.83uSec transmitted pulse
Parameter Maximum expected total load capacitance Worst-case data fall time (tfall) Worst-case data rise time (trise)
Worst-Case Value .012uF, including cable capacitance and 105pF filter capacitors per network device. 0.6uSec (time to fall from 5V to 3V, with .012uF capacitance and a maximum number of network devices). 11.2uSec (time to rise from 0.2V to 3V, with .012uF capacitance and minimum number of network devices).
3.3 Receiver Details
Bus receivers must detect low-going transitions on the network and relay them to the micro. The following circuit sets a low-going receive threshold at about 2.6V for speakers and 3V for the console. No hysteresis is provided in this example-- therefore some multiple-transitions may be experienced on the edges of noisy bits. Devices must add hysteresis in the event that their receive algorithms cannot tolerate these transitions. Standard UARTs and other schemes which sample bits near the center of bit cells, for example, will optimally tolerate multiple transitions. Receive schemes which decode data by using edge-triggered interrupts to measure network high/low times might require hysteresis, unless sufficient delay exists in the interrupt service routine before re-arming. Ideally, software should implement a debounce scheme to implement pseudo-hysteresis, regardless of the circuit used. Bus receivers must also tolerate network transients. The receiver circuit is therefore tapped off the protected node of the transmitter output stage, as shown in the Transmitter Details diagram above. NOTE: in this topology, all data transmitted by a network device will be fed back into its own receiver. Software must be robust enough to tolerate this.
3.3.1 Reference Receiver Circuits
For reference, the suggested +5V and +3.3V bus receiver circuits are: +5V (+/- 10%) 30.0K (for speakers w/+5V rails) 23.3K (for console) 10.0K From protected node, above (see transmitter circuit). MMBT3906 or equiv. 10.0K +3.3V (+/- 10%) 100.0K For speakers with only 3.3V rails From protected node, above (see transmitter circuit).
18.0K
Received data (to micro)
Received data (to micro) 10.0K
MMBT3906 or equiv.
NOTE: if the micro uses a standard UART, another logical inversion may be needed, following this stage.
3.3.2 General Receiver Electrical Requirements
Regardless of the receiver topology used, it is essential that its parameters be controlled as follows: Parameter Low-Going Receive Threshold Maximum allowable current drawn from the bus when in the logic high state. Maximum source current drawn from a speaker receiver when the bus is in a logic low state. Allowable Value 2.6V, nominal, for speakers. 3.0V, nominal, for console. 33uA, max. (Equivalent to a 150K Ohm resistor to ground.) 150uA, max. (Equivalent to a 33.3K Ohm resistor to +5V, or a 22.0K Ohm resistor to +3.3V.)
3.4 +10V Turn-On Line
To support legacy AM5P/AM20P and 901P speakers, the Postman2/FedX console will provide a +10V Turn-On signal, with a drive circuit identical to CD-20, LS50 and LS28/35 (Postman1). This signal will be low (2.2K pulldown to GND) when no speakers are active on a given Zone, and high (current-limited high-side PNP switch, providing from +8.8V to +10V depending on load). Maximum drive capability is about 75mA at +8.8V. Therefore, if speakers use this line for any other purpose (Energy Star, etc.), care should be taken to avoid drawing more than 5mA per speaker (5mA = 75mA / 15 speakers). Any such current draw should also be only temporary, to reduce console power dissipation.
3.5 Audio Interface Details
The complete Smart Speaker interface consists of audio signals as well as the control bus just described. The audio signals for all new networked devices are fixed output (always sent at full volume)-- requiring any volume control to be implemented in the speakers. This guarantees maximum signal to noise at the speakers. A variable output is also provided, however, to support legacy speakers. To support the Cobalt2 speaker system in the main room, a digital output is provided.
3.5.1 Console S/PDIF Output for the Main Room
For the Main Room speaker system (Cobalt2 for the Postman2/FedX system), the console provides a S/PDIF-based differential digital audio stream on the Zone1 Speaker Output mini-DIN, pins 1 and 2 (see connector pinout, below). This stream is configured for a (non-standard) 3Vpp output level, when loaded by the speaker, and is transformerisolated and balanced. 390pF filter caps to ground are added to reduce emissions. This stream will be limited to a 48kFPS (48K frames/Sec) data rate, maximum, when connected to Cobalt2 (which cannot handle streams with faster rates). The Postman2/FedX console hardware is capable of generating up to 192kFPS streams, however, which may be put to use in future variants of the product, with future speaker systems. The Postman2/FedX console will output digital audio in PCM, AC-3, DTS, MPEG2 and possibly AAC formats. The compressed formats must be identified and decoded by the Cobalt2 bass box. Only one speaker is intended to connect to this S/PDIF audio stream.
3.5.2 Console Analog Outputs for Non-Main Rooms
To connect to non-main room speaker systems throughout the house, a pair of analog stereo outputs (Zone1 and Zone2) are provided on the Zone2 Speaker Output mini-DIN connector (see pinout, below). As mentioned, these left/right pairs are both fixed-output. Full-scale (maximum) output signals are about 2Vrms, with typical playback levels being about 300-400mVrms. Playback levels for all console internal and external audio sources have been gain-scaled in the console to play at equal amplitudes. These outputs are standard, single-ended analog outputs, driven essentially by op amps, with about 50 Ohms added series resistance on each output. 47uF DC blocking capacitors are added in the console to each output signal, followed by 100K resistors referencing each to the console's analog ground. It is expected that this output impedance can drive up to 15 speakers (with input stages defined below) without suffering either unwanted attenuation or loss of low-frequency response. Cabling guidelines are provided below to guarantee proper zone/zone isolation and noise shielding. The Zone2 Speaker Output connector pins 1 and 2 also provide a left/right variable analog signal pair, for variableinput legacy speakers (AM5P/20P and 901P). These signals are identical to the Zone2 fixed outputs on pins 3 and 4, but are able to be attenuated by the Zone2 volume control chip inside the console.
3.5.3 Differential Inputs for Networked Speakers
Long lengths of audio cable routed through a house have been found to be susceptible to picking up audible amounts of noise. Speakers interfacing to the Smart Speaker bus should therefore configure differential amplifiers at their audio input stages. As a reference for these diff amp inputs, a dedicated Audio Reference will be sent from the
console and included with the other network conductors. See cabling details, below. The full list of requirements on a networked speaker's audio interface are: · Zone1 and Zone2 input diff amp circuits should be identical (same gain, noise floor and bandwidth, consistent with the audio quality goals of the speaker). · Diff amps should be used, with all legs equally balanced. · Resistance looking into each leg from the network should be 20K Ohms or greater. This allows diff amps configured with 10K Ohm resistors in each leg, for example. · Each leg should be capacitively coupled to the network, with all capacitors of equal value. Each networked device is free to choose their own capacitor values, based on desired frequency response. · The dedicated Audio Reference signal should be used for all diff amps: Zone1 Left/Right as well as Zone2 Left/Right. To avoid audio currents flowing back into this signal which could destroy Zone1/Zone2 isolation, Audio Reference should be used for the NON-INVERTING legs of the diff amps only. In general, no more than 1 microAmp, rms, of audio current should be induced onto the Audio Reference signal. This maintains 92dB isolation (considered an acceptable minimum).
3.5.4 Zone1/Zone2 Input Selection MUX for Networked Speakers
All Smart Speakers developed to interface with Postman2/FedX will have the ability to select one of two possible audio streams: the Zone1 stream or the Zone2 stream. Selection will be controlled via Smart Speaker commands. Speakers should therefore provide a 2-input, stereo audio MUX at its network audio input, under control of the micro managing Smart Speaker messages. NOTE: configuring this MUX ahead of the diff amps, to save cost, must be done carefully, to avoid diminishing their performance or violating the above requirements.
3.6 The P2/FedX Console Speaker Output Mini-DIN Connectors
The Postman2/FedX console has two 9-pin Speaker Output mini-DIN connectors, one for Zone1 and one for Zone2. Their pinout is as follows: ZONE1: Pin 1: S/PDIF0 digital audio signal for Cobalt2 (Z1_NET0). Pin 2: S/PDIF1 digital audio signal for Cobalt2 (Z1_NET1). Pin 3: Zone1 fixed Left analog audio signal (Z1_LEFT). CANNOT be made variable. Pin 4: Zone1 fixed Right analog audio signal (Z1_RIGHT). CANNOT be made variable. Pin 5: GND. Pin 6: +10V Turn On signal for Zone1 (Z1_TURNON). Pin 7: Smart Speaker Data for Zone1 (Z1SPKR_DATA). Pin 8: GND. Pin 9: No connect. Shell: GND. Pin 1: Pin 2: Pin 3: Pin 4: Pin 5: Pin 6: Pin 7: Pin 8: Pin 9: Shell: Zone2 variable Left analog audio signal (OUTLVAR). Zone2 variable Right analog audio signal (OUTRVAR). Zone2 fixed Left analog audio signal (Z2_LEFT). Zone2 fixed Right analog audio signal (Z2_RIGHT). Buffered Zone1 fixed Right analog audio signal (BZ1_R). Will be shorted by old cables. +10V Turn On signal for Zone2 (Z2_TURNON). Smart Speaker Data for Zone2 (Z2SPKR_DATA). GND. Buffered Zone1 fixed Left analog audio signal (BZ1_L). GND.
ZONE2:
Looking into a 9-pin mini-DIN connector (as when plugging into it) the connector pins are:
8
5 shell 2 9
7
4 1
6 3
Pin 9 is new to P2/FedX. Postman1 only had an 8-pin mini-DIN.
3.7 The Input Mini-DIN Connector for Networked Speakers
Networked Smart Speakers will likewise have a 9-pin mini-DIN connector for connecting to the Smart Speaker bus. This one connector must take in Left/Right audio for both Zone1 and Zone2, a well as the Data line, digital ground, and a separate ground to use as a reference for the audio diff amps. Optionally, the +10V Turn On signal could be brought in, as well. Although all-together this only amounts to only 8 conductors, the speakers will be defined to use a 9-pin mini-DIN identical to the console's (though only a single, as opposed to a dual) to allow cables to be reversible. The speakers' mini-DIN will be pinned-out as follows: Pin 1: Unconnected (console's Zone2 variable Left analog audio). Pin 2: Unconnected (console's Zone2 variable Right analog audio). Pin 3: Zone2 fixed Left analog audio signal. Pin 4: Zone2 fixed Right analog audio signal. Pin 5: Zone1 fixed Right analog audio signal. Pin 6: +10V Turn On signal for Zone2. Pin 7: Smart Speaker Data for Zone2. Pin 8: Audio Reference (dedicated ground for diff amps). NOT tied to speaker's product ground. Pin 9: Zone1 fixed Left analog audio signal. Shell: GND, used as the speakers' digital (product) ground. NOT shorted to pin 8 GND in the speaker.
3.8 Cabling Details 3.8.1 Bose Pre-Terminated Cables ("Zone 2 Expansion Cables") for New Speakers
Cables provided by Bose for customers to connect new-style Smart Speakers (A2, LSA2, Ballpark, etc.) to the P2/FedX console Zone2 Speaker Output will be constructed as a 1:1 pass-through of pins 3 through 9, with separate shields as follows. Note: pins 1 and 2 are not connected, and the cable is reversible. Console End Audio Reference
shell
Speaker End
shell
Speaker Data +10V Turn-On 8
5 9 2
7
4 1
6 3
8 Z2 Fixed Left Z2 Fixed Right Z1 Fixed Left Z1 Fixed Right
5 9 2
7
4 1
6 3
3.8.2 Using the Bose System Cable (257187) with New Speakers
Professional installers, when using the 8-conductor Bose System cable, part number 257187 (4 shielded, twisted pair) to connect new-style speakers to the console, should make connections as follows (identical to above, using twisted pair):
Console End Audio Reference
shell
Speaker End
shell
(twisted pair) 8
5 9 2
Speaker Data +10V Turn-On 8 7
9 2 4 1 6 3
7
4 1
6 3
(twisted pair)
Z2 Fixed Left Z2 Fixed Right Z1 Fixed Left Z1 Fixed Right
5
(twisted pair)
3.8.3 Connecting Legacy AM5P/20P Speakers
AM5P/AM20P's CANNOT plug into the Zone1 Speaker Output of P2/FedX. The Zone1 connector left/right audio outputs cannot be configured as variable outputs (as Postman1's could, via the OSD), so these speakers are not supported in Zone1. AM5P/AM20P's can plug directly into the Zone2 Speaker connector and operate properly, and can co-exist with newer speakers (LSA2, A2 and Ballpark). They use the Zone2 Variable Left/Right signals on pins 1&2, as well as the +10V Turn-On Line on pin 6. Pin 8 is used to shield the Turn-On line and provide speaker ground. The shell ground is used for Audio Reference in this speaker. The same cables used to connect these speakers to CD20 (LS20) and the MRI (LS40) can be used here. NOTE: these cables will internally short pin 5 to the shell ground, making the Zone1 Fixed Right output unusable for new speakers-- a special splitter must be used to prevent this (connecting the console shell to the splitter output's pin 5, but leaving this output's shell floating) if these speakers need to share Zone2 with new speakers.
3.8.4 Connecting Legacy LSA1 Speakers
LSA1's CANNOT plug into the Zone1 Speaker Output of P2/FedX. The Speaker Data signal on the Zone1 connector is used for communicating to Cobalt2, and must therefore use the Normal protocol. The LSA1 used the Legacy protocol, which cannot be supported on the same bus as the Normal protocol. A single legacy LSA1 CAN plug into the Zone2 Speaker Output of P2/FedX, with the same cable used to plug LSA1 into CD20 and MRI (LS40/50). This cable picks-up the Zone2 Fixed Left/Right signals on pins 3&4, as well as the Speaker Data signal on pin 7. Pin 8 ground is picked-up for product ground and the shell ground is used to shield audio conductors and as a reference for the LSA1's diff amps. NOTE: The LSA1 requires the P2/FedX console to be set to the Legacy protocol via the OSD, which will make it unable to simultaneously support any new-style speakers (LSA2, A2, Ballpark, etc.).
3.8.5 Connecting Legacy 901P Speakers
901P is another variable-input speaker, like the AM5P/AM20P. Therefore, it CANNOT be plugged into the Zone1 Speaker Output (which has only fixed outputs-- see AM5P/AM20P, above). 901P CAN co-exist on Zone2 with newer speakers. It uses the same signals as AM5P/AM20P, in a similar way. NOTE: its standard CD20/MRI cable also shorts pin 5 to the shell. As above, it will therefore also require a special splitter if newer speakers are to share the Zone2 signals.
3.8.6 Mixing Legacy and New Speakers On the Same Network
As mentioned above, if any of the existing Bose speaker cables are plugged into the Zone2 Speaker Output of Postman2/FedX, the Zone1 Fixed Right audio output signal on pin5 will be shorted to ground. This is a result of the fact that older consoles used pin5 as a Room Sense input (consoles would monitor this pin, and know that a cable was plugged-in when they saw this pin shorted to ground). Since the Fixed Right audio output is buffered, it is safe to short this signal to ground if newer-style speakers do not need to be supported. However, if new speakers need to be mixed with legacy speakers, a special splitter must be used. The connections in this splitter would be as follows (Console end is male, Speaker Output ends are female):
Console End Audio Reference
shell
New Speaker Output
shell
8
5 9 2
7
4 1
6 3
(not twisted)
Speaker Data +10V Turn-On Z2 Fixed Left Z2 Fixed Right Z1 Fixed Left Z1 Fixed Right
5
8
9 2
7
4 1
6 3
(not twisted)
(not twisted)
Legacy Speaker Output (for LSA1, AM5P & 901P) (not twisted) Speaker Data +10V Turn-On Z2 Fixed Left Z2 Fixed Right Z2 Variable Left Z2 Variable Right 8
5 2
shell
7
4 1
6 3
(not twisted)
(not twisted)
The splitter's Legacy output has the following features: 1. Cables plugging into it which short pin5 to the shell will not short Z1 Fixed Right to GND. 2. Its pin 8 ground can be used for digital GND (for the Data signal, as well as +10V Turn-On). 3. Its shell ground is shorted to pin5, and can be used for Left/Right audio shielding. The splitter's New Speaker output is a full pass-through of pins 3 through 9 (and shell) from the console mini-DIN. New Speakers will never use the pin1-2 Variable audio signals, and in fact may use pins 1-2 as audio outputs for accessories (Ballpark pedestals, for example), so these are not included in the splitter.
3.8.7 Using Existing Bose Wall Plates, etc.
This needs to be fleshed-out.
4.0 Low-Level Protocol Basics
In general, the Smart Speaker protocol remains a one-wire (two wires, including ground), bidirectional, half-duplex, signaling scheme between the P2/FedX console and a set of networked speakers. All communication is sent via the Speaker Data conductor on the cables run from the Speaker Output mini-DIN connectors on the back of the P2/FedX console to the networked speakers. The idle state for this signal is a logical high (+5V), pulled-up via a 1K Ohm resistor in the console (see the previous Physical Interface section). All transmissions are achieved by directly keying open-collector transistor stages in the console and speakers. The P2/FedX Smart Speaker protocol is modeled after RS-232, with a 19.2k bps bit rate, one start bit, one stop bit and no parity bits (identical to Postman1, except that the bit rate has been increased from 4800 bps to 19.2kbps). Message bytes are defined later in this document. NOTE: All message bytes are sent LSB (least significant bit) first, per the RS-232 standard.
4.1 Allowable Logic Levels
Logic levels for signaling are as follows (as seen on the Speaker Data conductor of the Smart Speaker bus): Message Bit Logic Level on the Smart Speaker Bus Logic High Logic Low Logic Low Logic High Logic High 1V, max on bus. 4.5V, min on bus. < 2.6V < 3.0V > 2.6V > 3.0V Notes
Idle State Start Bit Data 0 Data 1 Stop Bit Xmit Logic Low Xmit Logic High Rcv Logic Low (slaves) Rcv Logic Low (console) Rcv Logic High (slaves) Rcv Logic High (console)
Console pullup to +5V. Open-collector pulldown to GND. Open-collector pulldown to GND. Console pullup to +5V. Console pullup to +5V. NOTE: same as return to Idle state. Only one device transmitting. 1K pullup to +5V at the console. With 15 receiver loads. 1K pullup to +5V at the console. Console pulls all the way to .1V. Slaves pull down through series resistors.
4.2 Allowable Bit Widths
The 19.2kbps data rate used by all networked devices must be guaranteed to be within 0.5% of the nominal rate. This ensures edge accuracy out to each byte's Stop bit of +/- 5% (+/- 10%, assuming worst-case timing error for both the transmitter and receiver). Allowable bit widths are therefore defined to be as follows: Message Bits All (Start Bit, Stop Bit, Data 0, Data 1) Bit Widths 52.083uSec, nominal. Tolerance +/- .5% (+/- .26uSec). NOTE: Allowable error includes all clock error due to crystal accuracy, temperature drift and aging, etc.
NOTE: these tolerances apply to bit widths as generated by bus transmitters. Actual received bit widths may be distorted on worst-case networks (see Section 2.2.3).
4.3 Message Timing Requirements
To guarantee speaker synchronization, messages will be formally required to be packetized (sent as one continuous burst, without delays between bytes), with inter-message timings strictly controlled, as follows: Parameter Longest logic High time within the body of a message. Allowable delay between message bytes (console or speakers). Required network idle time before sending console messages ("Synchronization Delay") Allowable delay between the end of a console message and the start of a speaker's reply. Allowable delay between console queries and speaker replies. Requirement 9 bits = 469uSec, nominal, at 19.2kbps. 0 uSec. 1.066mSec, min. 767uSec, max. Notes This would correspond to a byte with value 00h. Included here for reference only. All message bytes must be sent out as one continuous burst, without pauses between. End of the last stop bit (from speaker or console) to beginning of console's start bit. End of the console's last stop bit to the beginning of the speaker's first start bit. True for ALL types of replies. Speaker reply, when ready, must wait to be sent immediately following (within 767uSec) the next poll from the console.
TBD by high-level software.
Message example for a common 4-byte command and reply, as seen on the network (note: bus idles high):
End of previous message.
Console Message
2.08mSec 40 bits Header Address Argument Verifier Reply Delay 767uSec, maximum 6mSec Exchange Time, Including Sync Delay Header
Speaker Reply
2.08mSec 40 bits Address Argument Verifier
Start of next message.
Sync Delay 1066uSec, minimum
Sync Delay 1066uSec, minimum
4.4 Guaranteeing Message Synchronization
As shown in the table above, the console always needs to ensure that the network has been idle for at least 1.066mSec before initiating a new transmission. This delay is intentionally longer than the allowable delay between console messages and speaker replies, so that devices on the network can use simple timeouts to re-synchronize with the console whenever necessary (ideally, on an ongoing basis). The recommended timeout for speakers to use for re-synchronizing to the console is 916uSec ( 916uSec = 767uSec + (1.066mSec - 767uSec)/2. ). In other words, if a speaker identifies that the network has been idle for 916uSec, that speaker can re-arm its receive routine and will properly capture the next console message from its beginning. Speakers can identify the end of an inbound console message by waiting for the first network idle time of safely greater than 469uSec (the longest possible string of 1's within the body of a message). The recommended timeout is about 521uSec. This gives speakers 246uSec to examine the received message and begin its ACK/reply, as required, before 767uSec. If these message timings are adhered to, no loss of synchronization should occur (network devices should never improperly lose track of where the beginning and end of messages are). Nonetheless, message address and verifier bytes should be examined to confirm that all received messages are valid. Furthermore, if a network idle time long enough to identify the end of a message is detected, any partially-received messages less than 4 bytes long should be deleted, and re-synchronization should take place.
4.5 Recommendations for Software Drivers 4.5.1 Optimized Low-level Receiver
Standard hardware UART receivers provide optimum protection against noise and jitter/slew distortion, and are recommended. To approximate this performance in software where hardware UART's are not available, a bitbanged receive routine should work as follows: 1. After synchronization has been confirmed and an inbound message can be expected, the data input should be armed with an edge-triggered interrupt. 2. When the first edge of a message is detected (the first start bit of the first byte), it should be debounced by immediately re-sampling 1-2 more times to reject noise (though noise should be extremely rare on typical networks). If found to be valid, a state machine driven by auto-reloaded 52.083uSec timeouts should be implemented to sample the next 10 bits as close to the center of the bit cells as possible. 3. The first 8 stages of this state machine will collect message bits. Each of the 8 message bits should be quickly sampled 1-3 times at the center of the bit cell, and the proper value stored away. 4. The timer interrupt routine for the 9th bit (the stop bit) should confirm that the bus is in the idle (high) state, and re-arm the edge-triggered interrupt for the next byte's start bit. 5. If a new byte's start bit edge is detected before the 10th 52.083uSec interrupt, cancel the 10th timer interrupt and assemble a new incoming byte as before (using this edge to re-synchronize the timing of the 10-bit sampling engine). However, if the 10th 52.083uSec interrupt expires first, the message is over. Process accordingly. Slaves can immediately begin generating their reply.
4.5.2 Transmit/Receive Timing for the Master
The Postman2/FedX console will have a hardware UART assigned to the Smart Speaker interface. The following scheme will minimize the interrupts associated with managing this UART: 1. Transmit the full outbound message at once (N bytes), setting the UART to interrupt the system when done. For messages longer than the16 byte maximum UART buffer in the CS98200 (rare), interrupts will need to be used to transmit the messages piecemeal, in the largest blocks possible (up to 16 bytes). Note: this should be done as to introduce no noticeable delays between bytes. 2. Once the outbound message is finished, enable the UART receiver and set it to interrupt after one r