Cirrus Logic CobraNet User Manual

Digital Audio Networking Processor

™

CobraNet

Programmer’s Reference

CobraNet

Version 2.5

Preliminary Product Information

http://www.cirrus.com

This document contains information for a new product. Cirrus Logic reserves the right to modify this product without notice.

DS651PM25

CobraNet

Features

CobraNet

❒ Real-time Digital Audio Distribution via Ethernet ❒ No Overall Limit on Network Channel Capacity ❒ Supports Switched and Repeater Fast Ethernet Networks ❒ Fully IEEE 802.3 Ethernet Standards Compliant ❒ Fiber Optic and Gigabit Ethernet Variants Supported ❒ Ethernet infrastructure can be used simultaneously for

audio and data communications.

❒ Free CobraCAD™ Audio Network Design Tool ❒ High-quality Audio Sample Clock Delivery Over Ethernet ❒ Uncompressed 16-, 20-, and 24-bit Audio Transport ❒ Professional 48 khz and 96 kHz Sample Rate ❒ Low (1-1/3 ms) Latency ❒ Flexible Many-to-many Network Audio Routing

Capabilities

❒ Available in a family of modules and low-cost devices,

most without licensing fees or royalties.

CobraNet Interface

❒ Auto-negotiating, 100-Mbit, Full-duplex Ethernet

Connections

❒ Up to 64 Audio Channel I/O Capability ❒ Implements CobraNet protocol for real-time transport of

audio over ethernet.

❒ Local Management via 8-bit Parallel Host Port ❒ UDP/IP Network Stack with Dynamic IP Address

Assignment via BOOTP or RARP

❒ Remote Management via Simple Network Management

Protocol (SNMP)

❒ Available module form factor allows for flexible integration

into audio products.

❒ 120-MIPS Digital Signal Processor ❒ Non-volatile Storage of Configuration Parameters ❒ Safely Upgrade Firmware over Ethernet Connection ❒ LED Indicators for Ethernet Link Activity, Conductor

Status, and Fault Annunciation

❒ Watchdog Output for System Integrity Assurance ❒ Comprehensive Power-on Self Test (POST) ❒ Error and Fault Reporting and Logging Mechanisms

Host Interface

❒ 8-bit Data, 3- or 4-bit Address ❒ Virtual 24- or 32-bit Data and Addressing ❒ Polled, Interrupt, and DMA Modes of Operation ❒ Configure and Monitor CobraNet Interface ❒ Transmit and Receive Ethernet Packets at 100-Mbit Wire

Speed

Digital Audio Networking Processor

Asynchronous serial interface

❒ Full-duplex Capable ❒ 8- and 9-bit Data Formats ❒ Standard Baud Rates up to 115.2 kbps ❒ Transmitter Tri-state Control for Multi-drop Networking

Synchronous Serial audio Interface

❒ 4 Bi-directional Interfaces Supporting Up to 64 Channels

of Audio I/O

❒ 48 kHz and 96 kHz Sample Rates ❒ 64FS, 128FS, and 256FS Bit Rates Supported ❒ Supports numerous synchronous serial formats including

❒ Up to 32-bit Data Resolution

Audio clock interface

❒ 4 Host Audio Clocking Modes for Maximum Flexibility in

Digital Audio Interface Design

❒ Low-jitter, 512FS (24.576 MHz) Master Clock Oscillator ❒ Synchronize to Supplied Master and/or Sample Clock ❒ Sophisticated jitter attenuation assures network

perturbations do not affect audio performance.

Audio routing and processing

❒ Single-channel Granularity in Routing from Synchronous

Serial Audio Interface to CobraNet Network

❒ Two levels of audio routing indirection absorbs any quirks

in audio I/O interface design in host system.

❒ Local Audio Loopback and Output Duplication Capability ❒ Peak-reading Audio Metering with Ballistics

CobraNet

General Description

CobraNet is a combination of hardware (the CobraNet interface), network protocol, and firmware. CobraNet operates on a switched Ethernet network or on a dedicated Ethernet repeater network. CobraNet provides the following additional communications services for an Ethernet network.

• Isochronous Audio Data Transport

• Sample Clock Distribution

• Control and Monitoring Data Transport

The CobraNet interface performs synchronous-toisochronous and isochronous-to-synchronous

Digital Audio Networking Processor

conversions as well as the data formatting required for transporting real-time digital audio over the network.

The CobraNet interface utilizes standard Ethernet. It has the added capability to carry and utilize other Ethernet and IP compatible protocols for control and monitoring such as Simple Network Management Protocol (SNMP) and User Datagram Protocol (UDP) through the same network connection. This capability is shown below as unregulated traffic. Data communications and CobraNet applications can coexist on the same physical network in most cases.

Isochronous Data

(Audio)

Ethernet

Control Data

Figure 1. Digital Audio Distribution via Ethernet

Unregulated

Traffic

Clock

CobraNet Programmer’s Reference

Contacting Cirrus Logic Support

For all product questions and inquiries contact a Cirrus Logic Sales Representative. To find the one nearest to you go to www.cirrus.com

IMPORTANT NOTICE

Cirrus Logic, Inc. and its subsidiaries ("Cirrus") believe that the information contained in this document is accurate and reliable. However, the information is subject to change without notice and is provided "AS IS" without warranty of any kind (express or implied). Customers are advised to obtain the latest version of relevant information to verify, before placing orders, that information being relied on is current and complete. All products are sold subject to the terms and conditions of sale supplied at the time of order acknowledgment, including those pertaining to warranty, indemnification, and limitation of liability. No responsibility is assumed by Cirrus for the use of this information, including use of this information as the basis for manufacture or sale of any items, or for infringement of patents or other rights of third parties. This document is the property of Cirrus and b furnishing this information, Cirrus grants no license, express or implied under any patents, mask work rights, copyrights, trademarks, trade secrets o other intellectual property rights. Cirrus owns the copyrights associated with the information contained herein and gives consent for copies to be made of the information only for use within your organization with respect to Cirrus integrated circuits or other products of Cirrus. This consent does no extend to other copying such as copying for general distribution, advertising or promotional purposes, or for creating any work for resale.

CERTAIN APPLICATIONS USING SEMICONDUCTOR PRODUCTS MAY INVOLVE POTENTIAL RISKS OF DEATH, PERSONAL INJURY, OR SEVERE PROPERTY OR ENVIRONMENTAL DAMAGE (“CRITICAL APPLICATIONS”). CIRRUS PRODUCTS ARE NOT DESIGNED, AUTHORIZED OR WARRANTED FOR USE IN AIRCRAFT SYSTEMS, MILITARY APPLICATIONS, PRODUCTS SURGICALLY IMPLANTED INTO THE BODY,

UTOMOTIVE SAFETY OR SECURITY DEVICES, LIFE SUPPORT PRODUCTS OR OTHER CRITICAL APPLICATIONS. INCLUSION OF CIRRUS PRODUCTS IN SUCH APPLICATIONS IS UNDERSTOOD TO BE FULLY AT THE CUSTOMER’S RISK AND CIRRUS DISCLAIMS AND MAKES NO WARRANTY, EXPRESS, STATUTORY OR IMPLIED, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR PARTICULAR PURPOSE, WITH REGARD TO ANY CIRRUS PRODUCT THAT IS USED IN SUCH A MANNER. IF THE CUSTOMER OR CUSTOMER’S CUSTOMER USES OR PERMITS THE USE OF CIRRUS PRODUCTS IN CRITICAL APPLICATIONS, CUSTOMER AGREES, BY SUCH USE, TO FULLY INDEMNIFY CIRRUS, ITS OFFICERS, DIRECTORS, EMPLOYEES, DISTRIBUTORS AND OTHER AGENTS FROM ANY

ND ALL LIABILITY, INCLUDING ATTORNEYS’ FEES AND COSTS, THAT MAY RESULT FROM OR ARISE IN CONNECTION WITH THESE USES.

Cirrus Logic, Cirrus, the Cirrus Logic logo designs, CobraNet, and CobraNet Silicon Series are trademarks of Cirrus Logic, Inc. All other brand and product names in this document may be trademarks or service marks of their respective owners.

CobraNet Programmer’s Reference

Table of Contents

Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

General Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.1 CobraNet Terminology ........................................................................................................7

1.2 Protocol ...............................................................................................................................9

1.2.1 Beat Packet......................................................................................................... 9

1.2.2 Isochronous Data Packet (or Bundle) .................................................................9

1.2.3 Reservation Packet ............................................................................................. 9

1.2.4 Serial Bridge Packet............................................................................................ 9

1.3 Timing and Performance ................................................................................................... 10

1.4 Bundle Addressing types ..................................................................................................11

2. Control Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1 Serial Bridge......................................................................................................................12

2.2 Packet Bridge.................................................................................................................... 13

2.2.1 Packet Bridge Buffer Data Format ....................................................................13

Processor-dependent Layout of Packet Bridge Buffers..............................13

24-bit HMI Packet Bridge Buffer Data Format ............................................14

32-bit HMI Packet Bridge Buffer Data Format ............................................14

2.2.2 Packet Bridge Receive Filtering........................................................................ 15

3. Network Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1 CobraNet Audio.................................................................................................................16

3.2 Serial Bridge......................................................................................................................16

3.3 Packet Bridge.................................................................................................................... 16

3.4 BOOTP..............................................................................................................................16

3.5 RARP (partial support) ......................................................................................................17

3.6 ICMP (partial support) ....................................................................................................... 17

3.7 ARP................................................................................................................................... 17

3.8 IP....................................................................................................................................... 17

3.9 UDP...................................................................................................................................18

3.10 TFTP ...............................................................................................................................18

3.11 SNMP.............................................................................................................................. 18

4. Audio Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1 Audio Routing Channels ...................................................................................................19

4.2 Bundle Transmitters .......................................................................................................... 20

4.3 Bundle Receivers .............................................................................................................. 20

4.4 Loopback...........................................................................................................................20

4.5 Output Channel Duplication .............................................................................................. 20

4.6 Meters ............................................................................................................................... 21

4.7 Low-latency Audio Support ............................................................................................... 21

4.8 96 kHz Sample Rate Support............................................................................................23

5. Management Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.1 Flash ................................................................................................................................. 25

5.2 Persistence .......................................................................................................................26

5.3 Watch Dog ........................................................................................................................26

5.4 SNMP Extension Agent..................................................................................................... 27

6. Management Interface Variable Reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.1 Legend .............................................................................................................................. 28

6.2 Data Types........................................................................................................................ 29

6.2.1 DisplayString ..................................................................................................... 29

6.2.2 OID.................................................................................................................... 29

6.2.3 IpAddress .......................................................................................................... 29

6.2.4 PhysAddress ..................................................................................................... 30

6.2.5 TimeTicks.......................................................................................................... 30

CobraNet Programmer’s Reference

Table of Contents

6.2.6 Counter .............................................................................................................31

6.2.7 Counter2 ...........................................................................................................31

6.2.8 Integer ............................................................................................................... 31

6.2.9 Integer16 ........................................................................................................... 32

6.2.10 Integer48 ......................................................................................................... 32

6.3 MIB-II Variables.................................................................................................................33

6.3.1 System .............................................................................................................. 33

6.3.2 Interface ............................................................................................................ 37

6.3.3 Address Translation .......................................................................................... 45

6.3.4 IP....................................................................................................................... 46

6.3.5 UDP................................................................................................................... 53

6.3.6 SNMP................................................................................................................ 55

6.4 CobraNet Variables........................................................................................................... 65

6.4.1 Firmware ........................................................................................................... 65

6.4.2 Hardware Identification .....................................................................................68

6.4.3 Flash .................................................................................................................69

6.4.4 Errors ................................................................................................................74

6.4.5 Conductor..........................................................................................................77

6.4.6 Conductor Information....................................................................................... 79

6.4.7 Packet Bridge....................................................................................................81

6.4.8 Serial Bridge...................................................................................................... 86

6.4.9 Interrupt Control ................................................................................................ 89

6.4.10 Audio ............................................................................................................... 92

6.4.11 Receivers ...................................................................................................... 101

6.4.12 Transmitters .................................................................................................. 105

6.4.13 Synchronization............................................................................................. 110

6.4.14 SNMP Monitor ............................................................................................... 113

6.4.15 MI Monitor ..................................................................................................... 114

6.4.16 IP Monitor ...................................................................................................... 116

6.4.17 IF Monitor ...................................................................................................... 117

6.5 DSP Extensions ..............................................................................................................119

6.5.1 Processor ........................................................................................................ 119

6.5.2 Control............................................................................................................. 120

7. Recommended User Interface Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

7.1 Channel Assignments and Labeling................................................................................ 122

7.1.1 Audio I/O Map ................................................................................................. 122

7.1.2 Bundle Assignments .......................................................................................122

7.2 Conductor Priority ...........................................................................................................123

7.3 Name...............................................................................................................................123

8. Error Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

8.1 Recoverable Errors ......................................................................................................... 124

8.1.1 Receive and Transmit Errors .......................................................................... 124

8.1.2 Faults ..............................................................................................................124

8.2 Unrecoverable Errors ...................................................................................................... 124

8.2.1 Fatal Faults .....................................................................................................124

8.2.2 POST Failure ..................................................................................................125

9. Error Code Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

9.1 Legend ............................................................................................................................126

9.2 Error Code Interpretation ................................................................................................127

9.2.1 24-bit Error Code Interpretation ......................................................................127

9.2.2 32-bit Error Code Interpretation ......................................................................127

9.3 Error Codes Listing .........................................................................................................128

10. Glossary of Terms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

1. Overview

1.1 CobraNet Terminology

CobraNet is a technology that combines state of the art audio and communications technologies. While each have their own terminology, the following terms are used to refer to elements specific to CobraNet.

Audio Channel—A CobraNet digital audio channel operates with a sample rate 48 kHz or 96 kHz and a sample size of 16, 20, or 24 bits.

Bundle—A Bundle* is the basic CobraNet audio routing element and can carry 0 to 8 audio channels. Bundles are assigned a number which determines both which interface the Bundle is routed to and in what manner. The range within which the Bundle number falls determines whether it is routed as a multicast, unicast, or private type. Bundles are numbered 1 through 65535. CobraNet interfaces are capable of sending and receiving multiple bundles simultaneously. Bundle numbers are described in more detail in Table 2.,

"Bundle Numbering" .

Bundles were formerly referred to as channels or network channels and may be seen represented as such in some SNMP

variable names and older documentation.

CobraNet Programmer’s Reference

Overview

CobraNet Device—A CobraNet device is any equipment containing one or more CobraNet interfaces.

CobraNet Interface—The CobraNet interface is the hardware (or hardware design) and software supplied by Cirrus Logic to manufacturers of CobraNet enabled equipment. Several generations of the CobraNet interface exist and will interoperate with each other:

CS4961xx and CS1810xx - A family of CobraNet chips containing one or more 32-bit, 120-MIPS DSP cores, RAM and audio I/O circuitry.

CM-2 - A modular CobraNet interface based on a CS4961xx device.

CM-1 - A modular CobraNet interface based on a 24-bit, 100 MIPS DSP.

Silicon Series Reference Design - A CobraNet design based on the CS1810xx

or CS4961xx. This is essentially a CM-2 without the modular circuit board and host interface connector.

24-bit Platform - CobraNet interfaces based on 24-bit DSPs: Reference design, CM-1.

32-bit Platform - CobraNet interfaces based on 32-bit DSPs: CS4961xx and CS1810xx, CM-2.

Reference Design - A CobraNet interface design based on a 24-bit, 40 MIPS DSP.

Conductor—The conductor is the CobraNet interface elected to provide master clock and transmission arbitration for the network. The role of the conductor and the means for selecting a conductor are described elsewhere in this document. All CobraNet devices other than the conductor operate in a performer role.

Isochronous cycle - One or more CobraNet bundles are transmitted each isochronous cycle. The period of an isochronous cycle is 750 Hz or 1-1/3 mS

CobraNet Programmer’s Reference

Overview

Host Management Interface (HMI) - The hardware (8-bit bi-directional parallel interface) and protocol for accessing MI variables locally. The HMI is described in detail in the CS4961xx/CS1810xx Hardware Manual and CM-1 Hardware Manual.

Management Interface (MI) - The set of variables used to control and monitor the CobraNet interface. MI variables are accessible both locally through the Host

Management Interface (HMI) and over the network using Simple Network Management Protocol (SNMP). MI variables are described in detail in Section 6. "Management

Interface Variable Reference" on page 28.

Packet Bridge - A function provided by the CobraNet protocol which allows a CobraNet interface to send and receive raw Ethernet packets over the same Ethernet media used for audio transmission.

Performer - A CobraNet interface which receives its transmission permissions and master clock from a conductor. In the event a conductor fails, the CobraNet protocol will automatically promote a performer to become the new conductor.

Receiver - A logical entity within the CobraNet interface capable of receiving one Bundle.

Serial Bridge - A function provided by the CobraNet protocol which allows a CobraNet

interface to send and receive asynchronous (i.e. RS-232) data over the same Ethernet media used for audio transmission.

Transmitter - A logical entity within the CobraNet interface capable of transmitting one Bundle.

1.2 Protocol

The CobraNet protocol operates at the Data Link Layer also referred to as OSI Layer 2 or MAC layer. CobraNet uses four basic packet types described below. All CobraNet packets are identified with a unique Ethernet protocol identifier (0x8819) assigned to Cirrus Logic. As CobraNet is a Local Area Network (LAN) technology and not a Wide Area Network (WAN) technology, CobraNet does not utilize Internet Protocol (IP) to transport audio. Packet Bridge packets are generic packets and are not identified as CobraNet packets. Packet bridging is discussed in more detail in Section 2.2 "Packet Bridge" on page 13.

1.2.1 Beat Packet

A multicast packet with an address of 01:60:2B:FF:FF:00 and which contains network operating parameters, clock and transmission permissions. The beat packet is transmitted 750 times per second from a single CobraNet device on the network (the conductor) and indicates the start of the main isochronous cycle. Since the beat packet carries the clock for the network, it is sensitive to delay variation. If the delay variation specification shown in Table 1 on page 10 is not met, CobraNet devices may not be able to lock their local sample clocks to the network clock. The beat packet is typically small (on the order of 100 bytes) but can be large on a network with numerous active bundles.

CobraNet Programmer’s Reference

Overview

1.2.2 Isochronous Data Packet (or Bundle)

A multicast or unicast packet. A stream of isochronous data packets carries an audio bundle. Though the size of the packet is dependent on the number and format of the audio channels contained in the bundle, isochronous data packets are typically large. A bundle carrying 8 channels of 20-bit audio at 48kHz sample rate in the standard latency mode is approximately 1300 octets.

Isochronous data packets are transmitted in response to receipt of the beat packet. However when low-latency modes are utilized, isochronous data packets are transmitted twice or four times per isochronous cycle. The first transmission is in response to beat packet receipt, the other transmissions are made at evenly timed intervals thereafter.

Because CobraNet devices buffer isochronous data packets, out-of-order delivery of data packets is acceptable as long as the packet forwarding delay specifications in Table 1 on

page 10 are not exceeded.

1.2.3 Reservation Packet

A multicast packet with an address of 01:60:2B:FF:FF:01 used by the CobraNet protocol to allocate bandwidth and establish connections between CobraNet interfaces. CobraNet devices transmit reservation packes as needed or typically once per second at minimum.

1.2.4 Serial Bridge Packet

A multicast or unicast packet used to bridge asynchronous serial data between CobraNet interfaces. Serial bridging is discussed in more detail in Section 2.1 "Serial Bridge" on

page 12.

CobraNet Programmer’s Reference

Overview

1.3 Timing and Performance

CobraNet provides real-time audio delivery and requires real-time performance from the network on which it is deployed. The best means of insuring a network will deliver the performance required by CobraNet is to verify the design using Cirrus Logic’s CobraCAD CobraNet modeling software (available for download at www.cirrus.com). The design check feature in CobraCAD assures that the performance requirements shown in Table 1 are met and that the network is capable of delivering the bandwidth required to support the modeled application.

Table 1. Network Performance Requirements

Parameter Maximum Comments

Beat Packet Delay Variation 250µs

If delivery of beat packets periodically varies from the nominal delay by more than this value, then the Receivers may loose sample lock or fail to meet clock delivery specifications.

Forwarding Delay, 5-1/3ms latency

Forwarding Delay, 2-2/3ms latency

Forwarding Delay,

1-1/3ms latency

Maximum Forwarding Delay 5000µs Audio cannot be delivered at any latency with extreme forwarding delays.

Maximum Forwarding Delay Variation, 5-1/3ms latency

Maximum Forwarding Delay Variation, 2-2/3ms latency

Maximum Forwarding Delay Variation, 1-1/3ms latency

a. Store-forward delay on a 100Mbit Ethernet connection is 121us (assuming maximum length packets). This forwarding

delay specification is only achievable on an audio-only dedicated network. The lowest latency achievable with CobraNet on a non-dedicated network is 1-2/3ms (using the 1-1/3ms latency mode with an rxMinDelay setting of 0x40 to make receivers tolerant to queuing delays introduced by non-audio traffic).

500µs

250µs

125µs

1000µs

500µs

250µs

Forwarding delay is the sum of store forward, queuing and propagation delays. Forwarding delay includes delay variation - i.e. 150µs forwarding delay + 250µs delay variation = 400µs. Thus tolerance of forwarding delay is reduced in the presence of delay variation. When forwarding specification is exceeded, audio is delivered reliably with additional latency. rxDelay and rxMinDelay can be used to observe and control this adaptation to forwarding delay.

Delay variation exceeding these specifications will result in unreliable audio transport due unstable rxDelay determination. In some cases this may be addressed through manual rxMinDelay setting.

1.4 Bundle Addressing types

Multicast bundles represent a least common denominator for audio interoperability in

CobraNet networks. Bundles sent with multicast destination addresses are delivered indiscriminately to all CobraNet interfaces and thus have the potential of overloading a network. Care should be taken to insure that an excessive number of multicast bundles are not used. See Bundle Assignments in CobraNet Systems (available for download at

www.cirrus.com

Unicast bundles are sent to only one destination on a network. However, in the event that more than one CobraNet interface is set to receive the same bundle number, the CobraNet protocol may, according to rules governed by the txUniCastMode and txMaxUnicast variables, cause unicast bundles to be sent as multicast or multi-unicast when necessary. Multi-unicast will use unicast addressing to send up to four copies of the same bundle to different CobraNet interfaces.The default configuration for txUnicastMode insures that unicast bundles are never multicast.

Private bundles are a special case of unicast or multicast bundles. The transmitter's MAC address, in addition to the bundle number, is required to fully qualify a private channel at the receiver. Like unicast bundles, these may be either unicast or multicast based on txUnicastMode.

) for a discussion of issues associated with multicast bundles.

CobraNet Programmer’s Reference

Overview

Note: Transmitted bundles must have a unique bundle number assigned to them. More than one transmitting interface cannot use the same bundle number. Multiple receiving interfaces can receive the same bundles.

Hexadecimal

Bundle

Number

0 0 Null

1-0xFF 1-255 Multicast

0x100-

0xFEFF

0xFF00-

0xFFFF

Decimal

Bundle Number

256-65279 Unicast

65280-65535 Private

Designation Usage

Table 2. Bundle Numbering

Unused bundle. Disables transmission/reception when selected.

Transmitted by a single CobraNet interface and received by any number of interfaces.

Transmitted by a single CobraNet interface. Dependent on txUnicastMode and txMaxUnicast settings may be received at a single (default case), a few (multiple unicast case) or a large number (multicast case) of interfaces.

Individual transmitters locally allocate private channels. The bundle number is conditioned on the transmitter's MAC address. There are 256 of these bundles per transmitter thus the total number of private bundles is virtually unlimited as the bundle numbers are unique to a particular MAC address.

Transmission

Addressing

Never transmitted. Never transmitted.

Always multicast

Generally unicast but may multicast if txUnicastMode variable is adjusted.

Transmission

Mode

Always transmitted.

Only transmitted when at least one receiver is identified via reverse reservation.

CobraNet Programmer’s Reference

Control Communications

2. Control Communications

2.1 Serial Bridge

Asynchronous serial data may be bridged across the network using the serial bridge hardware and software. The CobraNet interface has a two wire logic-level asynchronous interface. Characters received on the interface are buffered and placed in the payload of a special serial bridge Ethernet packet. The packet is then transmitted onto the network with unicast or multicast addressing as configured. It is received at the destination CobraNet interface where the data in the packet is re-serialized and presented on the serial interface. Many standard asynchronous serial formats are supported. With proper physical interface circuitry, this port can be made to support RS-232, RS-422 or RS-485 standards. Multi-drop two-wire interfaces are also supported.

The bridging feature can be useful in a CobraNet product as either an internal or external control interface. Used externally, the appropriate transceiver, such as an RS-232 driver chip, is connected to the logic-level pins and in turn connected to a standard connector, such as a DB-9 or DB-25, on the back panel. This allows control of external serial interfaced devices remotely over Ethernet.

RS-485 Multi-drop

CobraNet

Interface

etwork

Figure 2. Serial Bridging, External Application

Ethernet Network

CobraNet

Interface

RS-232 Connection

Internal application of the serial bridge allows serial communications over the network between host processors which are incorporated into CobraNet devices. Using this communication scheme reduces engineering effort in integrating CobraNet into audio products that already accomplish control communications via serial link.

Micro-

controller

CobraNet

Interface

Ethernet Network

CobraNet

Interface

Micro-

controller

Figure 3. Serial Bridging, Internal Application

Although the serial bridging feature strives to transmit data at wire speed, delays are introduced by the process of serializing, de-serializing, and prioritizing the serial bridge packets. These delays are typically on the order of 10ms or less.

See Table 6.4.8 on page 86 for details on the MI variables used to control serial bridging.

2.2 Packet Bridge

The packet bridge provides a means for using the CobraNet interface as if it were an Ethernet controller by providing a basic capability to send and receive raw Ethernet packets. A CobraNet device utilizing a host processor with network stack can use this feature to transmit and receive both control and audio data over the same network connection.

In the simplest implementation, the host sees the packet bridge as several control variables, a receive buffer, and a transmit buffer which are accessed via the HMI interface. Ethernet data packets are transferred in both directions over the host port using the same HMI semantics used to read and write other MI variables.

More advanced implementations can take advantage of interrupt and DMA modes of HMI operation as well as some HMI operations specifically tailored to packet bridge functions.

CobraNet Programmer’s Reference

Control Communications

Refer to Table 6.4.7 on page 81 for details on the MI variables used to control packet bridging.

2.2.1 Packet Bridge Buffer Data Format

Packets are transmitted by writing raw packet data to bridgeTxPktBuffer. Packets are received by reading bridgeRxPktBuffer. Data in both buffers shares the same format. The first word of the buffer specifies the byte length of the data that follows. Byte length includes the14-byte Ethernet header. The Frame Check Sequence (FCS) is automatically appended to transmitted packets and automatically checked and stripped from received packets. The FCS is not included in the packet data or byte length specification. Byte length should be in the range 14 to 1514.

2.2.1.1. Processor-dependent Layout of Packet Bridge Buffers

Refer to Ta bl e 3 and Table 4 on page 14 for organization of data within bridge buffers for 24- and 32-bit platforms. All data marked as unused/0 will be received as 0 and must be set to 0 when writing the buffer prior to transmission.

For both platforms, requested transmissions shorter than the 60-byte Ethernet packet minimum will be padded to 60 bytes with indeterminate data.

CobraNet Programmer’s Reference

Control Communications

Table 3. Packet Bridge Buffer Layout, 24-bit Platforms

MS Middle LS

Word 1

Word 2

Word 3

Word 4

Word 5

Word 6

Word 7

Word 8

Word n

Packet byte length MS Packet byte length LS unused/0

Destination MAC byte 2 Destination MAC byte 3 unused/0

Destination MAC byte 4 Destination MAC byte 3 unused/0

Destination MAC byte 6 Destination MAC byte 5 unused/0

Source MAC byte 2 Source MAC byte 1 unused/0

Source MAC byte 4 Source MAC byte 3 unused/0

Source MAC byte 6 Source MAC byte 5 unused/0

Protocol identifier LS Protocol identifier MS unused/0

Payload byte 2 Payload byte 1 unused/0

...

Payload byte n Payload byte n-1 unused/0

... ... unused/0

2.2.1.2. 24-bit HMI Packet Bridge Buffer Data Format

Packet byte length is specified in the two MS bytes of the first word. The LS bytes will read 0 on receipt and must be set to 0 for transmit. Transmit byte length is rounded up to the nearest even multiple of 4. Receive byte length indicates the actual number of bytes received.

2.2.1.3. 32-bit HMI Packet Bridge Buffer Data Format

Packet data begins with the second word. Transmission order of each word is MH, MS, LS, ML.

Table 4. Packet Bridge Buffer Layout, 32-bit Platforms

MS MH ML LS

Word 1

Word 2

Word 3

Word 4

Word 5

Word 6

Word n

Byte length MS Byte length LS unused/0 unused/0

Destination MAC byte 2 Destination MAC byte 1 Destination MAC byte 4 Destination MAC byte 3

Destination MAC byte 6 Destination MAC byte 5 Source MAC byte 1 Source MAC byte 2

Source MAC byte 4 Source MAC byte 3 Source MAC byte 6 Source MAC byte 5

Protocol identifier LS Protocol identifier MS Payload byte 2 Payload byte 1

Payload byte 4 Payload byte 3 Payload byte 6 Payload byte 5

...

Payload byte n-2 Payload byte n-3 Payload byte n Payload byte n-1

... ... ... ...

2.2.2 Packet Bridge Receive Filtering

The packet bridge can allow only selected packets to be passed to the bridge buffer or allow copies of packets to be sent to the bridge buffer. The value of the bridgeRxFilter variable controls the filter mode. With bridgeRxFilter = 0x10 or 0x01 the packet bridge sends selected packets of unknown protocol to the HMI interface via the packet bridge buffer. With bridgeRxFilter = 0x02 or 0x08, copies of selected packets are passed both to the packet bridge and are processed by the CobraNet interface. The packet bridge never passes audio data packets or beat packets to the host. The operation of packet bridge filtering is shown in Figure 4 below.

Ethernet

Packet

CobraNet Programmer’s Reference

Control Communications

0x10 Bridges all Packets with

Unknown Protocol

(Usually Custom Control Protocol)

CobraNet?

0x8819

Reservation

Request?

Beat

Packet?

Serial Bridge

Packet?

Audio

Bundle?

N=Special

Case

Process

Reservation

Request

Process

Beat Packet

Process

Serial Bridge

Packet

Process

Audio Bundle

0x08 Copies all IP Packets and Forwards to Host Processor

ARP/RARP?

Process

ARP or RARP

Request

IP?

Packet

DestinationIP=

ipMonCurrentIP?

SNMP?

TFTP?

BOOTP?

Packet Dropped

SNMP Agent

TFTP Server

BOOTP Client

Process

Packet Bridge

RxPktBuffer

0x02 Copies Reservation Requests and Forwards to Host Processor

0x01 Bridges Special 0x8819 non-audio Packets

Figure 4. Packet Bridge Receive Filtering

The default value of BridgeRxFilter is 0x01. When BridgeRxFilter is set to 0x08 and/or 0x02, the CobraNet interface and the host processor can independently process the same packets. The Host processor can use 0x08 in order to respond to packets with IP addresses other than the address assigned to the CobraNet interface. Care must be taken in the host processor software when using these modes to ensure that the CobraNet interface and Host Processor do not both respond to the same packets.

CobraNet Programmer’s Reference

Network Stack

3. Network Stack

CobraNet ServicesInternet Protocol Suite

Applicatio

Transport

Network

Logical Link

Physica

3.1 CobraNet Audio

This includes transmission and reception of audio data packets and reservation requests, implementation of conductor arbitration, and the ability to serve in either conductor or performer roles. CobraNet audio is a self-contained service that spans from Logical Link (2) to Application (7) layers.

3.2 Serial Bridge

This service provides bridging of asynchronous serial streams over the Ethernet network. This self-contained service spans from the logical link to the Application layer. The serial bridge service is discussed in Section 2.1 "Serial Bridge" on page 12.

BOOTP SNMP TFTP

UDP

ICMP

Figure 5. CobraNet Network Stack

IP RARP ARP

802.3 Ethernet

Fast Ethernet Inter face

CobraNet

Audio

Serial

Bridge

Packet Bridge

3.3 Packet Bridge

This service simply allows the CobraNet interface to operate as an Ethernet controller for a connected host. This service works at the logical link layer and provides access to the network without providing any actual network services. The packet bridge feature is discussed in Section 2.2 "Packet Bridge" on page 13.

3.4 BOOTP

The boot protocol (BOOTP) is supported as specified in RFCs 951 and 1542. Network clients use BOOTP to receive an IP address from a BOOTP server.

Clients needing an IP address will broadcast a BOOTP request packet. A BOOTP server on the network will respond with a BOOTP response containing the preferred IP address for the client to use. Use of BOOTP simplifies the error-prone task of assigning unique IP addresses to devices on a large network. BOOTP is carried via UDP/IP and, as such, is able to pass through properly configured routers.

BOOTP requests are transmitted by the CobraNet interface on a randomized schedule as recommended in the RFCs. Requests are sent out frequently at startup and then taper

down to an approximate 2-per-minute minimum rate. Two conditions must be met before a CobraNet device will send out BOOTP requests:

• The device must not already have an IP address. Apart from BOOTP, there are two other means for a CobraNet interface to obtain an IP address - RARP and the ipMonitor variables.

• The device must be attached to a switched network. In order to avoid producing unregulated traffic, BOOTP requests are not transmitted on a repeater network.

Upon receipt of a valid BOOTP response, a CobraNet device will change its IP address to the IP address indicated by the BOOTP response. It is not necessary for a response to be paired with a specific request to be considered valid.

3.5 RARP (partial support)

RFC 903 defines reverse address resolution protocol (RARP). Network clients use RARP to receive an IP address from a central server. RARP differs from BOOTP in that it is carried at the logical link layer (Layer 2) and thus cannot pass through IP routers.

RARP is comprised of request and response packet types. Upon receipt of a valid RARP response packet, a CobraNet device will change its IP address to the IP address indicated by the RARP response. The CobraNet network stack does not transmit RARP request packets.

CobraNet Programmer’s Reference

Network Stack

RARP is the means used by the CobraNet Discovery application (Disco) and CNDisco object for IP address assignment.

3.6 ICMP (partial support)

Internet control message protocol (ICMP) is an administrative protocol defined in RFC

972.

CobraNet devices which have been assigned an IP address will respond to ICMP echo (commonly referred to as ‘ping’) requests. No other ICMP support is implemented in the CobraNet network stack.

3.7 ARP

Address resolution protocol (ARP) is used by the IP protocol to translate IP addresses to MAC addresses according to RFC 826.

A host seeking a MAC address associated with an IP address broadcasts an ARP request. The device using the specified IP address replies with an ARP response packet. In this way the requesting host obtains the MAC address for the target device.

The CobraNet interface responds to ARP requests when appropriate. CobraNet will not generate ARP requests. For this reason the CobraNet can only respond to IP messages and cannot initiate IP communications.

3.8 IP

The internet protocol (IP) is defined in RFC 791. IP is a network protocol (layer 3 of the OSI 7-layer networking model) responsible for routing of packets and segmentation and reassembly of packets.

CobraNet Programmer’s Reference

Network Stack

The CobraNet implementation of IP has the following limitations:

• Segmentation and reassembly is not supported. Segmentation is primarily utilized by stream based TCP protocols that can generate large data packets. Reassembly capability can be necessary on heterogeneous networks (those comprising multiple network technologies such as Ethernet, FDDI, and ISDN).

• Cannot initiate IP communications; can only respond to incoming messages. The CobraNet implementation does not support net mask and default gateway concepts required to initiate communications to other subnets. Furthermore, CobraNet's implementation of ARP does not support generation of ARP requests.

3.9 UDP

User datagram protocol (UDP) is defined in RFC 768. UDP is a transport protocol (layer 4 of the OSI 7-layer networking model) responsible for maintaining the integrity of data. UDP is an extremely simple protocol which, by design, defers the data integrity problem to application protocols in higher network layers.

CobraNet fully supports UDP.

3.10 TFTP

3.11 SNMP

Trivial file transfer protocol (TFTP) is defined in RFC 783. TFTP supports file read and write via a UDP/IP transport. The CobraNet implementation of TFTP supports only binary reads and writes to a specific set of files. This is the mechanism used to update firmware in a CobraNet interface. The TFTP file names correspond to the different sectors of the FLASH memory and can differ in name and size for different revisions of CobraNet interface hardware.

Firmware update is a complex process best accomplished by use of an encapsulated software module, such as the PACNFirm object library, or by use of the CobraNet Discovery program which are aware of the data structures and protocol utilized.

Version 1 of the simple network management protocol (SNMP) is defined in RFC 1157. The CobraNet SNMP interface is version 1 compliant.

A management information base (MIB) is associated with any SNMP implementation. CobraNet supports the standard MIB for network devices as defined in RFC 1213 “MIB-II” in addition to its own MIB for CobraNet-specific objects.

The CobraNet MIB file is available for public download in order to facilitate full use of the CobraNet SNMP interface via SNMPv1 compliant applications.

4. Audio Paths

CobraNet Programmer’s Reference

Audio Paths

Synchronous

Serial Receivers

RX1

RX2

RX3

RX4

Up to 8 Channels Each

TX1

TX2

TX3

TX4

Up to 8 Channels Each

Synchronous Serial

Transmitters

Audio Buffering

Audio Routing

Channels

0 (Silence)

audioMap

Ethernet

32 33

Transmitters

TxSubMap

Dup Variables

RxSubMap

Receivers

audioLoopSrc

audioDupSrcaudioDupDst

Loop Variables

audioLoopDst

Outgoing

Audio Bundles

Audio Output Metering

audioMeterMap

Audio Input Metering

Incoming

Audio Bundles

Ethernet

NOTES: 1. Do not alter audioMap, use txSubMap and rxSubMap to control routing to/from Bundles and SSI.

2. The number of transmitters and receivers may vary depending on the implementation.

Figure 6. CobraNet Interface Audio Model

4.1 Audio Routing Channels

There are 65 audio routing channels within a CobraNet interface numbered from 0 to 64. Channels 1 through 32 are used to route audio from the Synchronous Serial Interface (SSI) to the network transmitters. Channels 33 through 64 are used to route audio from

CobraNet Programmer’s Reference

Audio Paths

the network receivers to the SSI outputs. Routing channel 0 is a special logical channel used to supply silence to a transmitted channel or serve as a “bit bucket” when receiving from the network.

Audio arrives and leaves the interface through the SSI receivers and transmitters. As each sample arrives it is buffered. The mapping of audio input and output channels to audio I/O buffer offsets is fixed (and non-intuitive). To accommodate channel numbering differences of different CobraNet devices, the audioMap variables allow a mapping from audio I/O buffer offsets to routing channel numbers. This mapping is preset by the manufacturer and should never need to be altered.

4.2 Bundle Transmitters

A Transmitter is a logical entity within the CobraNet interface capable of transmitting one bundle of up to 8 audio channels. Input audio routing channels (0, 1 through 32) are mapped into Bundles associated with a particular transmitter via the txSubMap variables associated with that transmitter. There are 8 txSubmap variables associated with each transmitter, each of which can be set to a particular routing channel number. The first txSubMap variable sets the routing channel that will be transmitted in the first audio channel in the bundle. The second txSubmap variable selects the source for the second audio channel to be transmitted in the bundle...and so on.

Audio resolution (sample size) and sample rate (48 kHz or 96 kHz) are determined by other transmitter parameters discussed in this document.

4.3 Bundle Receivers

A Receiver is a logical entity within the CobraNet interface capable of receiving one bundle of up to 8 audio channels. Output audio routing channels (0, 33 through 64) are mapped from the receiver via the rxSubMap variables. There are 8 rxSubMap variables associated with each receiver, each of which can be set to a particular routing channel number. The first rxSubMap variable selects the routing channel that will receive the first audio channel in the bundle. The second rxSubMap variable specifies mapping the second audio channel in the bundle...and so on.

4.4 Loopback

The loopback object provides a means for the interface to transfer audio channels internally. Loopback overcomes the limitation that a device cannot receive its own transmission and also allows the audio I/O system to be tested locally.

The audioLoopSource and audioLoopDest variables control this feature.

4.5 Output Channel Duplication

The audio routing channel mapping facilities allow a single routing channel to be mapped to any number of audio channels in any number of network transmitters (Bundles). It is, however, not possible to direct an audio channel in a network receiver to multiple audio routing channels for output through multiple SSI channels or ports.

Output channel duplication allows output routing channels to be copied to other output routing channels. This feature is implemented as a separate set of “dup” paths controlled

by audioDupSource and audioDupDest variables. An output can be specified as the source for a duplication by multiple “dup” paths. Output duplication is accomplished without incurring additional audio latency. See Section 6.4.10 "Audio" on page 92 for more information.

4.6 Meters

Metering is provided for all 64 audio routing channels. The first 32 meters can be mapped to the 32 input routing channels. The second 32 meters are used to meter the output routing channels. Mapping is controlled by the audioMeterMap variable

Metering is disabled by default to conserve processing cycles. Meters are peak detecting with simple first-order decay ballistics. Ballistics are comprised of an instantaneous attack and exponential decay time programmable via audioMeterDecay variable. Ballistics are adjusted globally for all meters. All level measurements are peak level (as opposed to RMS, for instance). Level is indicated in 24-or 32-bit positive signed values. A cumulative peak hold element on each meter allows accurate detection of any clipping condition. See

Section 6.4.10 "Audio" on page 92 for more information.

4.7 Low-latency Audio Support

CobraNet Programmer’s Reference

Audio Paths

Low-latency modes are supported on CobraNet interfaces without need for hardware changes to the CobraNet interface or CobraNet Device. The default mode of operation is 5-1/3 mS latency at 48 kHz sample rate.

Running in low-latency mode requires more processing power, implying a trade-off between the number of channels supported and reduction of latency. Some referencedesign-based products need to operate at reduced channel count to support lower latency. Depending on selected sample size, sample rate, and latency, newer CobraNet interfaces may be subject to some limitation in channel capacity, number of transmitters and receivers, and multiple unicast transmission count.

The following table shows CM-1 channel capacity for several latency and sample rate operating modes. Eight-channel bundles with 20-bit resolution, unicast to a single destination or multicast is assumed.

Low-latency modes also place additional demands on network performance. Specifically, in order to achieve the desired latency, forwarding delay across the network needs to be reduced by approximately the same factor that audio latency is reduced. These requirements bring into play new network design rules.

Lower latency is achieved by transmitting smaller audio packets at a higher rate. A restriction on the number of audio channels allowed in a bundle is due to a restriction on

CobraNet Programmer’s Reference

Audio Paths

the maximum size of an Ethernet packet. Therefore Lower-latency modes have relaxed restrictions in this area. Audio channel count restrictions are summarized below.

Table 5. Bundle Capacity Limits as a Function of Ethernet Packet Size

Latency

16 bit, 48 kHz 20 bit, 48 kHz 24 bit, 48 kHz 16 bit, 96 kHz 20 bit, 96 kHz 24 bit, 96 kHz

5-1/3 ms 8 8 7 5 4 3

2-2/3ms 888887

1-1/3ms 888888

Bundle capacity or maximum channel count may be limited in some cases by both the allowable Ethernet packet size and by the processor bandwidth required to handle lower latency and/or higher sample rate modes. Limitations imposed by packet size are illustrated in Ta bl e 5 . Limitations imposed by additional bandwidth requirements are discussed in the Hardware Reference Manual applicable to the particular CobraNet Interface.

Channels per Bundle

CobraNet Programmer’s Reference

Audio Paths

A CobraNet interface operates at a single latency and sample rate mode as specified by the modeRateControl variable. This latency mode applies to all incoming and outgoing audio at the interface.

Table 6. txSubFormat and rxSubFormat1 Values

txSubFormat Value Resolution Sample Rate Latency

0 No Signal

0x044000 16 bit 48 kHz 5-1/3 ms

0x054000 20 bit 48 kHz 5-1/3 ms

0x064000 24 bit 48 kHz 5-1/3 ms

0x148000 16 bit 96 kHz 5-1/3 ms

0x158000 20 bit 96 kHz 5-1/3 ms

0x168000 24 bit 96 kHz 5-1/3 ms

0x042000 16 bit 48 kHz 2-2/3 ms

0x052000 20 bit 48 kHz 2-2/3 ms

0x062000 24 bit 48 kHz 2-2/3 ms

0x144000 16 bit 96 kHz 2-2/3 ms

0x154000 20 bit 96 kHz 2-2/3 ms

0x164000 24 bit 96 kHz 2-2/3 ms

0x041000 16 bit 48 kHz 1-1/3 ms

0x051000 20 bit 48 kHz 1-1/3 ms

0x061000 24 bit 48 kHz 1-1/3 ms

0x142000 16 bit 96 kHz 1-1/3 ms

0x152000 20 bit 96 kHz 1-1/3 ms

0x162000 24 bit 96 kHz 1-1/3 ms

rxSubFormat is a read only variable indicating the format of the audio data being received and decoded. It will have the same value as txSubFormat with the exception of the least-significant bit. i.e. 16-bit, 48 kHz sample rate, 5 1/3-mS latency = 0x44001 when the data is being successfully decoded.

modeRateControl must also be set to the correct value necessary to support the mode selected by txSubFormat.

4.8 96 kHz Sample Rate Support

A CobraNet interface may operate at either 48 kHz or 96 kHz but not both rates simultaneously. A device operating at 48 kHz cannot receive audio from a device operating at 96 kHz and vice versa. However, CobraNet interfaces operating at 96 kHz and 48 kHz audio may co-exist on the same network.

CS4961xx, CS1810xx, CM-2, and CM-1 based interfaces are required for 96 kHz sample rate operation. No hardware changes are required to support the increased sample rate on these platforms. 96 kHz is not supported in the legacy CobraNet Reference Design.

CobraNet Programmer’s Reference

Audio Paths

Sample rate is selected by the modeRateControl variable. modeRateControl selects both sample rate and audio latency. 96 kHz sample rate and low-latency modes can be used together.

rxSubFormat indicates the type and status of audio date being received. The LS bit of this variable indicates whether data in the sub channel is being decoded. A value of 0 indicates inability of the interface to decode the received data. An interface operating at 48 kHz cannot decode 96 kHz audio. An interface operating at 96 kHz cannot decode 48 kHz audio.

Processing 96 kHz audio requires twice the bandwidth. At 5-1/3 ms latency, all of the data is transmitted in one packet and thus the number of channels that can be transferred per bundle may be reduced. Lower latency modes can support more channels at 96 kHz, as the data is distributed across 4 packets at 1-1/3 mS and 2 packets at 2-2/3 ms latency. See Table 5., "Bundle Capacity Limits as a Function of Ethernet Packet Size" for more detail on this topic.

When operating in 96 kHz mode, the Master Clock remains at the standard 24.576 MHz. However, in 96 kHz mode, the Sample Clock Output (FS1) will change to support a 96 kHz signal. If a sample clock cascade and/or reference clock input is supplied, this signal may be either 48 kHz or 96 kHz in 96 kHz mode but must be 48 kHz in 48 kHz mode.

Table 7. Bit Clock Rates

Synchronous Serial Port Operating Mode 48 kHz SCK Rate 96 kHz SCK Rate

64Fs (2 channels x 4 interfaces) 3.072 MHz 6.144 MHz

128Fs (4 channels x 4 interfaces) 6.144 MHz 12.288 MHz

256Fs (8 channels x 4 interfaces) 12.288 MHz 24.576 MHz

5. Management Interface

The Management Interface (MI) is the means by which the CobraNet interface is controlled and monitored. Integral to the management interface are the MI variables. The MI variables are read and written via the Host Management Interface (HMI) or remotely over the audio network via SNMP. Both methods operate on the same common set of MI variables. The CobraNet device is configured in real time as the variables are changed.

Variables may have read-only, read/write, or read/write-persistent attributes. All variables are given an initial value at startup. The value of all variables can be read. Read/write and Read/write-persistent variable types can be both read and written. The value of persistent variables is saved in flash memory and the variable is restored at startup to the last value written. See Section 5.2 "Persistence" on page 26 for more detail on persistent variables. All MI variables are documented in the Section 6. "Management Interface Variable

Reference" on page 28.

MI variables fall into three classes. CobraNet-specific variables allow for configuration and monitoring of CobraNet functionality such as audio transmission and reception. A second class of variables known as SNMP MIB-II variables provides a uniform means of monitoring a network device. These variables are primarily concerned with performance and configuration of the network interface and associated protocols. A third class of product-specific variables may exist when a manufacturer makes use of SNMP extension agent capabilities. This third class of variables is used for controlling and monitoring product-specific features and functions.

CobraNet Programmer’s Reference

Management Interface

5.1 Flash

Flash memory may be updated via TFTP or through HMI. The HMI flash memory access mechanism allows flash contents to be read and written via the host port. This provides functionality for the HMI similar to that which TFTP provides via the network.

The mechanism cannot allow direct access to the flash memory. Instead a request to read or write flash is performed by supplying the flash address (flashTAddress), byte length (flashTLength), transfer direction (flashTDirection), and data (bridgeTxPktBuffer). The request is then initiated by writing to flashTRequest.

The flash memory is a byte-wide device. On 24-bit CobraNet platforms, the transmit buffer is comprised of 3-byte words. The mapping between the byte-wide flash data and the wider buffer memory is as follows.

Table 8. Flash Layout, 24-bit Platforms

MS Middle LS

First Word

Second Word

Byte 3 Byte 2 Byte 1

Byte 6 Byte 5 Byte 4

CobraNet Programmer’s Reference

Management Interface

On 32-bit CobraNet platforms, the transmit buffer is comprised of 4-byte words. The mapping between the byte-wide flash data and the wider buffer memory is as follows.

Table 9. Flash Layout, 32-bit Platforms

MS MH ML LS

5.2 Persistence

The persistence feature causes values written to Read/write-persistent type variables to be written to flash and for these stored values to be restored during startup. With the persistence feature disabled, Read/write and Read/write-persistent variables behave identically. Persistence is enabled by setting the flashPersistEnable variable.

With persistence enabled, values written to Read/write-persistent variables are written to flash by a background task according to a schedule designed to prevent excessive write cycles on the memory and to avoid interference with other critical functions. In extreme cases it can take up to 1 minute to store changed values. However, the persistence feature is implemented such that it is safe to remove power at any time with the caveat that the values recalled may not include changes made immediately prior to removal of power. Variable values will never become corrupted due to unexpected loss of power or network connection.

flashPersistAck can be used to ensure that variables have been stored to non-volatile memory prior to removal of power.

First Word

Second Word

Byte 4Byte 3Byte 2Byte 1

Byte 8Byte 7Byte 6Byte 5

5.3 Watch Dog

The watch dog is a digital signal from the CobraNet interface provided to allow fault detection. The watch dog signal is toggled periodically by firmware to indicate normal operation. The toggle rate may drop to as low as 5 Hz on occasion, depending on processor load. Actual minimum, maximum, and nominal toggle rates can be found in the Hardware Reference Manual applicable to the particular CobraNet interface.The watch dog signal will stop toggling following detection and reporting of a fatal error condition. The interface should be reset and re-initialized when absence of the watchdog signal is detected.

Use of the watchdog requires external hardware and/or software. A hardware solution may be implemented with a “microprocessor manager” chip such as the DS1236 from Dallas/Maxim. A software solution could involve wiring the watch dog signal to an I/O port, timer, or interrupt on the host processor and then wiring the CobraNet reset signal to a general purpose output. Software on the host processor would monitor the interval between watch dog transitions and assert the reset signal if the interval exceeds the maximum period.

Implementation of the watch dog feature is not mandatory but is recommended. ESD, EMI, and power fluctuation events are not uncommon in audio installations and the ability to survive and recover from such conditions is a prerequisite for passing many electrical certification programs.

5.4 SNMP Extension Agent

CobraNet’s SNMP agent feature allows the CobraNet interface to be monitored and configured over the Ethernet network by an SNMP manager (or managers). An enhancement of this capability is the SNMP extension agent which allows these monitoring and control capabilities to be extended to product-specific features and functionality.

SNMP extensions require use of a host processor attached to the CobraNet interface. The extension agent appears to the processor as additional product-specific variables in the HMI memory space. For status reporting, the host microcontroller writes updated values to the associated HMI locations. SNMP requests can then be used to read these values at any time. Extension values can also be written via SNMP and monitored by the host processor in order to provide a control path to the host processor via SNMP.

Extensions implemented along with the appropriate hardware and host software can be used to control and monitor many useful functions. For example, extension variables can be used to remotely monitor metrics such as gain, clipping and temperature. They can also be used to control functions such as gain, noise gates, and compression. The system will also benefit from the persistence feature, allowing settings for the entire product, not just the CobraNet interface, to be retained through a power-cycle.

CobraNet Programmer’s Reference

Management Interface

By using the extension agent, the entire product may be made SNMP manageable without need for the host processor to be burdened with the complexity of running a network stack and SNMP agent.

CobraNet Programmer’s Reference

Management Interface Variable Reference

6. Management Interface Variable Reference

CobraNet interfaces are configured and monitored by reading and writing Management Interface variables. MI variables may be accessed directly via a processor attached to the Host Management Interface or via the network using SNMP. The method of using the HMI is similar for all CobraNet interfaces but may require specific semantics and may have different word sizes depending on the actual implementation. The HMI interface is described in more detail in the Hardware Reference Manual applicable to the particular CobraNet Interface. Following are detailed descriptions of the size, contents, and effects of the MI variables as well as their HMI addresses and SNMP Object Identifier numbers. All MI variables can be accessed via the HMI but some variable properties render them inappropriate for accessing via SNMP. These exceptions are noted in the variable descriptions where applicable.

6.1 Legend

Name - Name of variable as seen in CobraNet MIB and cobrami.h header file.

Description - Description of the variable including allowed values and usage discussion.

Host Address - HMI addresses are used to access variables via the host port. HMI

addresses have a 24-bit range on both 24- and 32-bit platforms.

SNMP Object ID (OID)- The Object Identifier is the numeric name assigned to a variable according to the SNMP protocol.

Size - Size is indicated for varying-length data types such as DisplayString and OID. Size is not indicated for fixed types whose size is implied by their data type. Note that for fixed types, the word size may differ depending on the processor type.

Count - Number of entries for array or buffer-type variables. Absence of a Count specification implies a single instance variable, and thus a Count of 1.

Type - Data type of the variable. The options and format of data types are described below in detail.

Attributes - Read-only variables can only be read and can not be modified. Read/Write variables can be read and written. Read/Write - Persistent variables can be read and written. If the persistence feature is enabled, values of these variables will automatically be written to flash for recall at startup.

Default - Value assigned to the variable at startup when persistence is disabled. The values of some Read-only variables reflect system conditions and thus may not have a default value.

Version - Firmware version in which the variable was first introduced. Unless otherwise noted in this field, one can assume variables will be available in the version indicated and all subsequent versions.

6.2 Data Types

6.2.1 DisplayString

A DisplayString is an ASCII string comprised entirely of printable characters.

24-bit HMI: The first word indicates the length of the string in characters. Data is stored three characters per 24-bit word. Character order is MS, Middle, LS. For DisplayString variables, documented Size indicates the largest possible word size of the variable. Size includes the length field. The maximum allowable characters for a DisplayString variable is (Size-1)×3.

32-bit HMI: The first word indicates the length of the string in characters. Data is stored four characters per 32-bit word. Character order is MS, MH, ML, LS. For DisplayString variables, documented Size indicates the largest possible word size of the variable. Size includes the length field. The maximum allowable characters for a DisplayString variable is (Size-1)×4.

6.2.2 OID

An SNMP object identifier is the numeric name of an SNMP variable. OIDs are also used for other purposes including system-unique identifiers.

CobraNet Programmer’s Reference

Management Interface Variable Reference

24-bit HMI: OIDs are presented in their native BER encoding. The first word indicates the length of the encoding in bytes. Data is stored three octets per 24-bit word. Character order is MS, Middle, LS. For OID variables documented Size indicates the largest possible word size for the variable. Size includes the length field. The maximum number of octets for the OID variable encoding is (Size-1)×3.

32-bit HMI: OIDs are presented in their native BER encoding. The first word indicates the length of the encoding in bytes. Data is stored four octets per 32-bit word. Character order is MS, MH, ML, LS. For OID variables documented Size indicates the largest possible word size for the variable. Size includes the length field. The maximum number of octets for the OID variable encoding is (Size-1)×4.

6.2.3 IpAddress

An IpAddress is a 32-bit internet protocol (IP) address.

24-bit HMI: Data is stored in the most-significant 16 bits of 2 consecutive 24-bit words as shown in Ta bl e 10 . The least-significant 8 bits of each location are read as zero and must be written as zero.

Word 1

Table 10. IP address Layout, 24-bit Platforms

MS Middle LS

IP address byte 2 IP address byte 1 0

Word 2

IP address byte 4 IP address byte 3 0

32-bit HMI: Data is stored in a single 32-bit word as illustrated below.

Table 11. IP address Layout, 32-bit Platforms

MS MH ML LS

IP address byte 2 IP address byte 1 IP address byte 4 IP address byte 3

CobraNet Programmer’s Reference

Management Interface Variable Reference

6.2.4 PhysAddress

A 48-bit Ethernet media access control (MAC) address.

24-bit HMI: Data is stored in the most-significant 16 bits of 3 consecutive memory locations as illustrated below. The least-significant 8 bits of each location are read as zero and must be written as zero.

Table 12. MAC address Layout, 24-bit Platforms

MS Middle LS

32-bit HMI: Data is stored in two consecutive words as shown below. A third word is unused and reserved for addressing compatibility with 24-bit platforms.

6.2.5 TimeTicks

TimeTicks is an integer encoding for time durations in units of 100ths of a second.

24-bit HMI: An unsigned timer value is available in two successive 24-bit words. A 32-bit timer value and 15-bit fractional extension are available as shown below. The fractional extension may be used to gain additional accuracy. It may be safely ignored for most applications.

Word 1

Word 2

Word 3

Word 1

Word 2

Word 3

MAC byte 2 MAC byte 1 0

MAC byte 4 MAC byte 3 0

MAC byte 6 MAC byte 5 0

Table 13. MAC address Layout, 32-bit Platforms

MS MH ML LS

MAC byte 2 MAC byte 1 MAC byte 4 MAC byte 3

MAC byte 6 MAC byte 5 unused unused

unused unused unused unused

Table 14. TimeTicks Layout, 24-bit Platforms

MS Middle LS

Word 1

Word 2

Timer MS Timer MH Timer ML

Timer LS Fractional LS Fractional MS

32-bit HMI: TimeTicks value is available as two sucessive 32-bit words. A 32-bit timer value, a 16-bit rollover, and 16-bit fractional extension are availabe as shown below. The fractional extension may be used to gain additional accuracy. The rollover extension may

+ 117 hidden pages