University of Victoria Faculty of Engineering

Fall 2002 Work Term Report

Embedded Communication System for an Autonomous Underwater Vehicle

University of Victoria Autonomous Underwater Vehicle Club 1706 Mortimer Street

Victoria, British Columbia, V8P 3A8

Donovan Parks 9905396

Computer Engineering dparks@uvic.ca

January 4, 2003

In partial fulfillment of the requirements of the B. Eng. Degree

Supervisor's Approval: To be completed by Co-op Employer I approve the release of this report to the University of Victoria for evaluation purposes only.

This report is to be considered: __ Not Confidential __ Confidential

Signature: Position: Data: Name: Email: Fax #: If a report is deemed CONFIDENTIAL, a non-disclosure form signed by an evaluator will be faxed to the employer. The report will be destroyed following evaluation. If the report in NOT CONFIDENTIAL, it will be returned to the student following evaluation.

Donovan Parks AUVic 1706 Mortimer Street Victoria, British Columbia, V8P 3A8 Mr. Roel Hurkens Co-op Coordinator Faculty of Engineering University of Victoria P.O. Box 1700 Victoria, British Columbia, V8W 2Y2 January 4, 2003 Dear Mr. Roel Hurkens: The attached Work Term Report entitled “Embedded Communication System for an Autonomous Underwater Vehicle” is being submitted as partial fulfillment of the requirements for work term III and as credit for ENGR446. Engineering and computer science students from the University of Victoria established a group, known as the AUVic, in April 2001 to design and construct an autonomous underwater vehicle (AUV). The AUV is design to compete in the annual International AUV Competition hosted by the Association for Unmanned Systems International (AUVSI). AUVic attended the 5th International AUV Competition hosted by the AUVSI and the U.S. Office of Naval Research where we placed 12th out of 15 teams. A respectable placing for a first year team and one that resulted in the team being awarded a “Best New Rookie Team” award. The latest information on the AUVic can be found at www.engr.uvic.ca\~auv. I have been involved with the AUVic since its inception. From April 2001 to August 2002, I acted as lead programmer and have now taken the position of team captain. I have several responsibilities on the team which include organizing team meetings, ensuring the project remains on schedule, and designing and implementing the motor controller. However, this report will focus on the specification, design, implementation, and testing of an embedded communication system for the AUV. It will focus on the analysis used to develop the specifications for the system, design trade-offs encountered, the implementation of the design, and the test cases used to ensure the specifications were met. My colleague, Zahid “Ziko” Rajabali, was responsible for establishing the AUVic and acted as team captain from April 2001 to August 2002. I would like to thank Ziko for providing me with such a wonderful opportunity, encouraging me to take over as team captain, and for his continued assistance on the project. I hold all of the AUVic team members in the highest regard as they have proven to be capable engineers and professional colleagues. Finally, I would like to thank all of the AUVic sponsors as this project would not be possible without their support. Sincerely, Donovan Parks dparks@uvic.ca 4B Computer Engineer

i

Table of Contents

List of Tables and Figures ...................................................................................................... iii Summary .............................................................................................................................. iv Glossary ................................................................................................................................v 1.0 Introduction.......................................................................................................................1

1.1 History of the AUVic .......................................................................................................1 1.2 The AUVSI International AUV Competition ......................................................................1 1.3 Scope ...........................................................................................................................3

2.0 Background Information on Communication Systems ..........................................................4

2.1 Layered Approach to Communication Systems ................................................................4 2.1 Physical Layer Terminology and Metrics..........................................................................5

2.1.1 Communication Channels ........................................................................................5 2.1.2 Network Topographies .............................................................................................6 2.1.3 Data Rate................................................................................................................7 2.1.4 Hardware Address...................................................................................................8 2.1.5 Number of Nodes and Network Length......................................................................8

2.2 Network Access Layer Terminology and Metrics ..............................................................8 2.2.1 Packet Structure ......................................................................................................8 2.2.2 Packet Efficiency and Throughput .............................................................................9

2.3 Transport Layer Terminology and Metrics......................................................................10 2.4 Standard Communication Protocols ..............................................................................10 2.5 Rational for a Distributive System..................................................................................11

3.0 Specifications of AUVic-CS ..............................................................................................13

3.1 Physical Layer Specifications ........................................................................................13 3.2 Network Access Layer Specifications ............................................................................14 3.3 Transportation Layer Specifications...............................................................................15 3.4 Other Specifications .....................................................................................................16

4.0 Design of Communication Layers .....................................................................................17

4.1 Design of Physical Layer ..............................................................................................18 4.1.1 Selecting a Communication Protocol .......................................................................18 4.1.2 Hub: An I2C to RS232 Converter............................................................................20 4.1.3 Infrastructure of AUVic-CS .....................................................................................20

4.2 Design of Network Access Layer...................................................................................21 4.2.1 Flow of Packets .....................................................................................................21 4.2.2 Packet Structure ....................................................................................................22 4.2.3 Network Services ...................................................................................................24

4.3 Design of Transport Layer ............................................................................................25 4.3.1 Detectable Corrupt Packet (Checksum)...................................................................26 4.3.2 Lost Packets (Communication Timer)......................................................................26 4.3.3 Corrupt Length ......................................................................................................27 4.3.3 Undetected Communication Errors .........................................................................27 4.3.4 Dallas 1-Wire Reset Network ..................................................................................27

5.0 Design of Peripheral Operation ........................................................................................29

5.1 I2C Protocol ................................................................................................................29 5.2 Typical Operation.........................................................................................................30 5.3 Handling Communication Errors....................................................................................32

ii

6.0 Design of Hub Operation .................................................................................................34 6.1 Typical Operation.........................................................................................................34 6.2 Handling Communication Errors....................................................................................38 6.3 Communication with the Hub ........................................................................................39 6.4 Watchdog Timer ..........................................................................................................39

7.0 Design of Host Operation.................................................................................................40

7.1 Round-robin Schedule..................................................................................................40 7.2 Typical Operation.........................................................................................................41 7.3 Handling Communication Errors....................................................................................41

8.0 Implementation of AUVic-CS............................................................................................44

8.1 Selection of Programming Language.............................................................................44 8.2 Structural Organization of AUVic-CS Software...............................................................46

9.0 Testing of AUVic-CS .......................................................................................................49 10.0 Conclusions ..................................................................................................................53 11.0 Recommendations ........................................................................................................53 Cited References ..................................................................................................................55 General References ..............................................................................................................55 Appendix I – Error Codes ......................................................................................................56

iii

List of Tables and Figures

FIGURES Figure 1.1 Obstacle Course for the 5th AUVSI International AUV Competition [1].........................2 Figure 1.2 Barcode from 5th AUVSI International AUV Competition [1] ........................................2 Figure 1.3 AUViking Peripheral Overview .................................................................................3 Figure 2.1 Forming a Packet to Send over a Communication System.........................................5 Figure 2.2 Select Network Topographies ..................................................................................7 Figure 2.3 Common Packet Format..........................................................................................8 Figure 4.1 AUVic-CS Overview..............................................................................................17 Figure 4.2 Typical Network Operation ....................................................................................22 Figure 4.3 Packet Structure ...................................................................................................22 Figure 4.4 Acknowledge Packet .............................................................................................24 Figure 4.5 Error Packet .........................................................................................................24 Figure 4.6 Diagnostic Packet .................................................................................................24 Figure 4.7 Status Packet .......................................................................................................25 Figure 4.8 End Mission Packet ..............................................................................................25 Figure 4.9 Shutdown Packet ..................................................................................................25 Figure 5.1 I2C Write with 7-bit Address [7]..............................................................................29 Figure 5.2 I2C Read with 7-bit Address [7]..............................................................................30 Figure 5.3 Flow Chart for Peripheral on the AUVic-CS ............................................................31 Figure 6.1 Reception and Forwarding of Packets from Host.....................................................35 Figure 6.2 Main Processing Loop of Hub................................................................................36 Figure 6.3 Requesting Reply from a Peripheral .......................................................................37 Figure 6.4 Communication Timer ISR.....................................................................................38 Figure 6.5 Reset Packet ........................................................................................................39 Figure 7.1 Round-robin Schedule ..........................................................................................40 Figure 7.2 Main Processing Loop of Host ...............................................................................43 Figure 8.1 Structural Organization of AUVic-CS Software ........................................................47

TABLES Table 2.1 Properties of Select Standard Communication Protocols ..........................................11 Table 3.1 Physical Layer Specifications ..................................................................................14 Table 3.2 Packets Requiring Transmission at 10Hz.................................................................14 Table 3.3 Network Access Layer Specifications ......................................................................15 Table 3.4 Network Access Layer Specifications ......................................................................16 Table 4.1 Comparison of I2C and RS485 Protocols.................................................................19 Table 4.2 Comparison of CRC Table Look-up Algorithms ........................................................26 Table 5.1 Response by Slave to Various Communication Errors ..............................................32 Table 9.1 Testing of Communication Errors ............................................................................50 Table 9.2 Throughput of Communication on Serial Channel ....................................................51 Table 9.3 Throughput of Communication on D1W Channel......................................................51 Table 9.4 Throughput of Communication on I2C Channel ........................................................52

iv

Summary

A group of students from the University of Victoria are actively involved in designing and building an autonomous underwater vehicle (AUV). The goal of this club is to develop an AUV capable of competing in the 6th International AUV Competition to be held in the summer of 2003 by the Association for Unmanned Vehicles International (AUVSI). This years AUV, AUViking, is the second AUV developed by the University of Victoria AUV club (AUVic). In order to operate autonomously an AUV contains a range of sensors to collect information about its environment and at least one actuator to allow it to interact with the environment. A communication system is commonly used to allow a central processing unit to communicate with all sensors and actuators aboard the AUV. The central processing unit is responsible for setting the properties of actuators based on the information provided by the sensors. This report discusses the specification, design, implementation, and testing of an embedded communication system suitable for the small, low-cost AUV. The AUVic communication system (AUVic-CS) allows for communication between a high speed, embedded PC104 board and all sensors and actuators (collectively referred to as peripherals) aboard AUViking. Communication with all peripherals is done through a well-defined protocol enforced by the AUVic-CS. This effectively “black boxes” each peripheral, allowing them to be designed in parallel and allowing a logical decomposition of the systems functionality into physically and logically isolated sub-systems. The AUVic-CS consists of three types of components: the host, the hub, and peripherals. These components make up a distributed system based around a linear bus, half-duplex Inter-Integrated Circuit (I2C) network. A master/slave architecture is used with the host effectively acting as the master and the peripherals being slaves. Centralized processing is performed by the host who polls each sensor, analyzes the received data, and sets the motor speeds and directions based on this analyses. Communication between the host and peripheral requires a protocol translator as the host used by the AUVic has only a serial communication port. The hub provides this translation by forwarding packets received from the host to the I2C network. Peripherals are responsible for providing functionality required by the AUV. A unique feature of the AUVic-CS is a Dallas 1-Wire (D1W) reset network. Using this network, the hub has the ability to reset any peripheral in the AUV. This is used to provide recovery from errors that would otherwise prevent the AUVic-CS from operating. The error handling capabilities of the communication system along with the D1W reset network ensures a reliable communication system is achieved. Implementation and testing completed to date has functionally verified the design of the AUVic-CS and determined many of its qualitative properties. Software for peripherals, the hub, and a simplified version of the host is complete and tested to functionally verify the AUVic-CS. Measurements of the throughput and operating lengths of the D1W and I2C networks have shown the AUVic-CS to be suitable for use in AUViking. Full testing of the systems ability to detect and recover from errors, including resetting devices via the D1W reset network, has also been complete ensuring the reliability of the system. A small amount of work remains before the AUVic-CS will be in a state suitable for AUViking. Implementation of the host software and extensive testing to verify proper operation of the entire AUVic-CS must be completed. In addition, the cabling and connectors that will be used on each node to connect to the AUVic-CS backplane must be selected before the printed circuit board for the hub and peripherals can be finalized. This is the minimum amount of work remaining for an AUV capable of competing in the 6th International AUV.

v

Glossary Actuator Device used to interact with the environment (i.e. mechanical arm,

motors, laser).

API An application programming interface is a collection of software function that encapsulates (hide) functionality required by a user application.

Backplane Collection of wires used to bring common power and signal lines to nodes on a network.

Black-boxed Logical concept that is used to describe a software program or physical device that can be used by knowing only its interface. No knowledge of the inner workings of the software program or physical devices is required. For example, a TV is black-boxed as one does not require knowledge of how a TV operates in order to effectively use it.

Broadcasting Network services allowing a packet to be sent to all nodes on a network.

D1W The Dallas 1-Wire protocol was developed by Dallas Semiconductors to allow inexpensive networks of sensors, control devices, identification devices, and memory chips to be created that requires only one communication line.

Full-duplex A communication channel that is capable of sending and receiving data simultaneously (see half-duplex).

Half-duplex A communication channel that is capable of sending and receiving data, but not simultaneously (see full-duplex).

I2C The Inter-Integrated Circuit protocol was developed by Philips Inc. for the high speed transfer of data between IC in close proximity to each other.

LED A light emitting diode (LED) is an electrical device capable of producing visible light. Often used in electrical circuits to indicate state information (i.e. power is on, an error has occurred).

Nodes Generic term referring to any device on a communication system that can accept packets (i.e. has an address).

Packet Collection of data fields that allow information to be sent and processed by nodes on a network.

RS232 A standard developed by the Electronic Industries Association that specifies signal voltages, signal timing, mechanical connectors, etc. A simplified version of this standard is used for serial ports on personal computers.

Sensor Device used to gather qualitative information about the environment (i.e. temperature sensor, humidity sensor, sonar sensor).

1

1.0 Introduction An autonomous underwater vehicle (AUV) is a robot designed to work in an aquatic environment. It is autonomous as no human assistance is required for operation. This is in contrast to a remotely operated underwater vehicle (RUV) which is controlled by a human operator by send signals to the RUV through a cable. In order to operate autonomously, an AUV must contain a range of sensors to collect information about its environment and at least one actuator to allow it to interact with the environment. A communication system is commonly used to allow a central processing unit to communicate with all sensors and actuators aboard the AUV. The central processing unit is responsible for making intelligent decisions based on the information provided by the sensors and controlling the actuators. This report discusses the specification, design, implementation, and testing of the communication system to be used on the AUV currently being developed by the University of Victoria Autonomous Underwater Vehicle club (AUVic).

1.1 History of the AUVic

In April 2001, the AUVic was formed by Zahid Rajabali with the goal of competing in the 5th International AUV Competition hosted by the Association for Unmanned Vehicle Systems International (AUVSI) and the U.S. Office of Naval Research in July 2002. During the next 16 months the team designed and built the AUVic’s first AUV, the Antitanic. The AUVic realized its goal and placed 12th out of 15 teams in the 5th International AUV Competition. A respectable placing for a first year team and one that resulted in the AUVic being awarded a “Best New Rookie Team” award. The goal for this year’s team is to finish in the top half of field at the 6th International AUV Competition, to be held in late July 2003. In order to meet this year’s goal a more sophisticated AUV is required. While the Antitanic was a successful first generation AUV, it contains many design flaws that have only become transparent in hindsight. Work on the team’s second generation AUV, the AUViking, began in August 2002. The latest information on the AUVic is available at http://www.engr.uvic.ca/~auv.

1.2 The AUVSI International AUV Competition

The AUVSI (www.auvsi.org) was established in 1972 and is the world’s largest non-profit organization devoted to unmanned systems with members from government organizations, industry, and academia. Their mission statement is “to promote and support the unmanned systems community through communication, education and leadership.” In order to achieve this, the AUVSI holds a series of conferences and annual competitions including the International AUV Competition.

The International AUV Competition requires an AUV to be designed and built that is capable of completing the obstacle course specified by the AUVSI. Details of this year’s obstacle course have not been published, but it is expected to be similar to last year’s course. Last year, the course consisted of a validation gate and two concentric rings of barcodes placed on the bottom of the pool (see Figure 1.1). The AUV is required to locate and pass through the validation gate before proceeding to identify the barcodes. Identification of a barcode consists of measuring it’s depth from the surface and determining the binary code it represented (see Figure 1.2).

2

Figure 1.1 Obstacle Course for the 5th AUVSI International AUV Competition [1]

Figure 1.2 Barcode from 5th AUVSI International AUV Competition [1] To successfully complete the AUVSI AUV competition requires an AUV that can perform the following tasks:

• perform controlled dives and maneuvers independent of any human operator • locate and pass through a validation gate • identify barcodes on the bottom of the pool • read barcodes to determine the binary code they contain • accurately record the depth of the barcodes

3

An AUV capable of performing these tasks requires a wide range of sensors and a motor configuration capable of movement in all three spatial directions. It is the communication system that brings together all of the sensors and motors by providing a communication link between them and a central processing unit.

1.3 Scope This report will cover the specification, design, implementation, and testing of the communication system used on AUViking. The AUViking contains a suite of sensor and actuator systems (peripherals) to allow it to complete the tasks required by the AUVSI International AUV Competition (see Figure 1.3). It is the responsibility of the communication system to allow the central processing unit (denoted as the host processor in the AUViking) to communicate with these peripherals. The major focus of the report will be on the quantitative analysis done to determine the specifications and ensure the design meets these specifications. Different design trade-offs will be discussed and justification given for each trade-off. The implementation of the system will be examined with a focus on ensuring the developed software is maintainable and extendable. Different tests used to ensure the specifications are met will then be discussed and the results of the tests reported.

Figure 1.3 AUViking Peripheral Overview Understanding the specification and design decisions made for the AUVic communication system (AUVic-CS) requires knowledge of:

• layered approach to communication system • physical layer terminology and metrics • network access layer terminology and metrics • transport layer terminology and metrics • benefits gained from a distributed communication system

Each of these aspects will be examined before the AUVic-CS is discussed. Readers familiar with communication systems may wish to skip Section 2.0.

4

2.0 Background Information on Communication Systems An understanding of the general structure, terminology, and metric of a communication system are essential to understanding the specification and design decisions made for the AUVic-CS. The layered approach to structuring a communication system will be introduced followed by examining the physical, network access, and transportation layers in more detail. The AUVic-CS does not contain an interconnection or application layer so will not be explored in detail. This section will conclude with a discussion on the benefits of a distributed system to rationalize its use in AUViking.

2.1 Layered Approach to Communication Systems

A communication system can be divided into five independent layers: physical, network access, interconnected network, transport, and application [2]. Each layer must interact with the layer below it and provide an interface to the layer above it. This layered approach allows individual layers to be modified or completely replaced while requiring a minimum of modification to other layers. The physical layer details the physical interface between nodes in the system. This includes the hardware capability nodes on the network must have, transmission medium utilized, network topography, electrical specification of signals, supported data rates and other matters determined by physical components comprising the physical network. Exchange of data is the primary goal of a communication system. It is the network access layer which specifies how information is exchanged on the network. It provides logical structure to the signals transmitted via the physical layer to allow devices on the network to unambiguously communicate with each other. This logical organization of data is commonly referred to as a packet. This layer is concerned with giving unique address to all nodes on the network, the structure of packets, maximum packet size, invoking network services (i.e. broadcasting packets), and all other issues regarding the transfer of data between nodes on the network. The interconnected network layer specifies how packets pass between two networks that are physically connected by a router. The router uses the information provided in this layer to determine how to move packets across multiple networks. This layer is only required if packets can move between different networks. A requirement of any communication system is to ensure the reliable exchange of data on the network. A packet may fail to reach its destination or become corrupt before reaching its destination. In either case, the transport layer provides functionality to detect and recover from the problem. The application layer provides application specific interfaces for different user applications. These interfaces included functionality to allow files to be transferred, emails to be sent, etc. Embedded systems, such as AUViking, often run only a single, specific application and do not require the communication system to provide an application layer. The communication system for a typical embedded system is so integral to the system itself that it can be thought of as the application layer. Each layer adds functionality to the communication system. This is best illustrated by looking at how a packet is modified by each layer (see Figure 2.1). An application wishes to send data to a node on the network. This is the only information that the application software on the destination node is interested in, but several fields must be added to these data bytes in order to form a packet the communication system can process. A checksum is often added to the packet by the transportation layer in order to allow the transportation layer at the destination node to determine

5

if the packet became corrupt during transmission. If an interconnected network layer is required it would add additional fields to the packet to allow it to traverse networks. Several fields are added by the network access layer to allow the destination node to receive and process the packet. This packet is transmitted a bit at a time by the physical layer.

Figure 2.1 Forming a Packet to Send over a Communication System Once a node receives a packet, each layer processes it using the fields added by its corresponding layer on the transmitting node (consider Figure 2.1 with the arrows reversed). For example, in many communication systems, it is the responsibility of the network access layer to check the destination field to determine if the packet is indeed addressed to this node (in other communication systems this address checking is performed in hardware). After a layer finishes processing a packet it removes the fields specific to that layer and passes it to the next layer until the packet contents reach the destination nodes application layer.

2.1 Physical Layer Terminology and Metrics The physical layer determines many factors of the communication system and limitations in the physical structure of the communication system cannot be overcome by other layers. Because of this, considerable care must be taken when designing the physical layer. This section will discuss the factors which influence the design of a communication system. Electrical characteristics, cable selection, connector types and many other physical properties of a communication system should be defined in the physical layer. However, since these factors do not influence the design of other aspects of the communication system they will not be explored. These properties of the communication system can be determined at any time and modified as required without affecting the rest of the system. For example, the exact signal voltages and timing required to transmit bits on the network is critical to proper operation of the communication system. Fortunately, these details will be hidden in the physical layer as they are implemented directly in hardware or provided by a software application programming interface (API). Since no layer, except the physical layer, needs to be aware of the precise electrical characteristics of the network they do not influence the design of the rest of the system.

2.1.1 Communication Channels The physical layer determines if the communication channel between nodes is simplex or duplex. A simplex channel is one that can operate in only a single direction (i.e. a node can only transmit data). All modern communication systems use either a full-duplex or half-duplex channel to allow nodes to transmit and receive data.

6

In a full-duplex channel nodes can transmit and receive data simultaneously, whereas in a half-duplex channel a node can be either transmitting or receiving. The telephone communication system is full-duplex, but a radio system is only half-duplex as an individual is either talking or listening, but never both. Both full-duplex and half-duplex communication systems are common. It is important to realize that if the physical layer is designed to be half-duplex it is not possible to “patch” it in another layer to make it full-duplex.

2.1.2 Network Topographies

Network topography defines how nodes on the network are physically connected together. It determines the data pathways between nodes and affects the length of wiring required and the modularity of the network. Many possible arrangements exist and the most common ones are illustrated in Figure 2.2. In a star topography it is common for only the node at the center to have any processing power. This is the prototypical design for a centralized network. However, if the peripheral nodes contain processors then a distributed star topography occurs. The advantages of this topography are:

• allows nodes to be hot-swapped • failure of a node does not break the communication system • all nodes can communicate simultaneously with the central node

The disadvantage of a star topography is a strong dependency on the central node occurs. Expansion of the network is limited by the connections provided by the central node and peripheral nodes often use multiple communication protocols. For example, the central node may contain 4 serial ports, 2 USB ports, and a peripheral port. The network could then support a maximum of 7 peripheral nodes, but would require 3 different communication protocols. Nodes in a ring topography form a closed loop with each node directly connected to the node before and after it. It appears that all nodes could simultaneously talk to its two adjacent nodes if the ring was full-duplex. This is true, but in practice it is hard to organize such a communication structure. Instead a token is passed around the ring and only the node that currently holds the token may send packets. The advantages of this topography are:

• requires a small wiring harness • easily expandable to accommodate more nodes • provides a standard connection for all nodes • all nodes use the same communication protocol

If a node fails in a ring topography, communication may fail completely or be temporarily interrupted. In the latter case, it is necessary to explicitly program the network access layer to recover from a lost node (i.e. pass the token back and forth across the resulting linear chain). Similarly, the ring topography does not support hot -swapping as it would break the ring. A multi-drop or linear bus topography consists of a shared data bus which all nodes connect to. The advantages of this topography are:

• requires a small wiring harness • allows nodes to be hot-swapped (disconnected and connected during operation) • easily expandable to accommodate more nodes • provides a standard connection for all nodes • failure of a node does not break the communication system • all nodes use the same communication protocol

The disadvantage of a linear bus is the network access layer must determine which node can transmit data in order to avoid a bus collision (two nodes trying to transmit data on the same data

7

line at the same time). If the bus is half-duplex only a single node can transmit data. A full-duplex node would allow a pair of nodes to be transmitting data.

Figure 2.2 Select Network Topographies

A linear bus is often organized into a master/slave or multi-master architecture to avoid bus collisions. The master/slave architecture avoids bus collisions by specifying one node as the master and all other nodes as slaves (see Figure 2.2). Only the master is allowed to initiate communication on the network ensuring that a bus collision never occurs. This architecture can be thought of as a polling network where the master continually polls (asks) slaves for data and send slaves command packets. Many systems are well suited to this architecture as the slaves become sensors and actuators in the system and the master becomes the central processing unit, performing integrated processing on sensor data and issuing commands to the actuators. The disadvantage is packets cannot be directly sent between slaves (they must be routed through the master). A multi-master architecture can be used when several nodes need to be able to communicate with each other. This architecture is essentially the same as the master/slave architecture except the node which is the master changes during operation. Different schemes are used to allow the nodes which are currently slaves to become the master. In this way, each node has a turn at being master and can communicate with all other nodes during this time. Obviously, this architecture is more complicated to implement, but can lead to significant improvement in throughput for systems where multiple nodes must communicate with each other.

2.1.3 Data Rate

Data rate (or baud rate) is a measure of how many bits are sent between nodes per unit of time (measured in bits per second). The maximum achievable data rate is limited by the physical layer of the communication system. Increasing the maximum achievable data rate of a communication system typically required the entire physical layer to be replaced and may require modification to other layers. The cost of the physical layer is also tightly coupled with the required data rate. Because of this, it is critical that a communication system specify the required data rate.

8

2.1.4 Hardware Address

Hardware addressing indicates if address detection is done in the physical or network access layer. If hardware addressing is available, then addressing can be done in the physical layer and there is no processing overhead for nodes checking to see if packets are addressed to them. More importantly, hardware addressing indicates that the hardware is capable of detecting when a new packet is being sent which can often be exploited to significantly reduce the complexity of the network access and transportation layers.

2.1.5 Number of Nodes and Network Length

The number of nodes that a network can support is determined by the physical structure of the network and the design of the network access layer. The physical layer restricts the maximum number of nodes, as signal voltages and timing must remain within the electrical specifications of the network. Each node increases the length of cabling required which, together with the node hardware, increases the resistance and capacitance in the signal lines. This results in signal degradation that may cause signals to move outside the electrical specification of the network.

For the same reasons, the maximum length of the network is determined by the physical layer. In practice, the physical layer can usually be modified to accommodate more nodes or increased cable length by using better cabling or placing repeaters along the line to reduce the degradation of signals. However, the increased cost of implementing the physical layer may limit this possibility.

2.2 Network Access Layer Terminology and Metrics

The network access layer is responsible for defining a packet format that will allow data to be transmitted between nodes. At a minimum, the packet must contain a field specifying what node should accept the packet. It is common for the network access layer to define several other fields in the packet. Two metric commonly associated with a communication system are packet efficiency and throughput. Both of these are associated with packets and largely determined by the network access layer.

2.2.1 Packet Structure

Figure 2.3 shows a common packet format for embedded systems. The content field is provided by the user application and is the data that needs to be delivered across the communication system. All other fields are used by the communication system to ensure a packet can be reliably transmitted and processed by the receiving node. The checksum field is added by the transport layer and will be discussed in section 2.3.

Destination Source Length Content

Checksum Figure 2.3 Common Packet Format

Each node on the network is given a unique address. A packet is delivered to a node by setting the destination field to this unique address. When a packet is placed on the network the destination field is checked (either in software or hardware) by each node and will only be

9

processed if the destination field matches its address. The destination field must be long enough to allow each node on the network to have a unique address.

The destination field is often used to invoke network services and a range of addresses is reserve to indicate these services. For example, a destination of 0 is often used as a broadcast address. That is, when the destination field is set to 0 all nodes should process the packet.

The source field indicates where the packet originated by setting it to the unique address of the transmitting node. Depending on the system architecture a node may require this information in order to send a reply. Nodes can also use this field to process packets differently depending on the source of the node. Use of this field is highly dependent on the system and is not always necessary.

Once a processor has started receiving a packet it requires a method of determining when the last bit is received. Two methods are commonly used to achieve this: stop character and length field. A stop character is a special byte that indicates the end of a packet. A processor using this method continues to receive bytes until the stop character is received. This method is often used on networks that send only alpha-numeric characters as there are several characters that can be used as the stop characters. Networks that send raw data rarely use a stop character since any character may be sent as a content byte. For these systems a length field can be added to the packet that indicates the number of content bits in a packet. A processor knows the number of protocol bits (destination, source, etc.) in a packet so can easily determine how many bits must be received to form the complete packet. The disadvantage of this approach is the length field needs to be longer than a single byte if packets can have more than 255 content bytes.

2.2.2 Packet Efficiency and Throughput Packet efficiency is a measure of how much overhead, in terms of bits, there is when transmitting a packet over a communication system. It can be defined as the ratio of content bits to total bits in the packet. A content bit is data that an application wishes to transmit over a communication system. For example, if an application wishes to send 80 bits of content to a node and the final packet contains 104 bits (80 content bits + 8 bit destination + 8 bit source + 8 bit length) then the packet efficiency is 80/104 = 0.77 or 77%. A related metric is throughput. Throughput is a measure of how many bits can be sent between nodes per unit of time (measured in bits per second). This is different than data rate which indicates the rate bits are transmitted. Throughput accounts for the overhead of processing packets, applications processing received data, and a reply being generated. A communication channel may operate at a data rate of 115.2Kbps, but only have an average throughput of 30Kbps. The data rate of the channel will be the same regardless of the packet structure, type of packet, and number of content bits in the packet. The throughput is directly affected by packet structure (as it affects how long it takes to process a packet), type of packet (as it may affects what processing must be done before a reply can be generated), and number of content bits (more content bits will likely result in more processing being required before a reply can be generated). Because of this it is difficult to gauge the throughput of a communication system before it is complete, but it is throughput and not data rate that is important. Throughput can be increased by increasing the systems data rate or reducing the time it takes nodes to process packets and generate replies.

10

2.3 Transport Layer Terminology and Metrics The most common problem faced by a communication system is packets becoming corrupt during transmission. This will result in a packet being lost if the destination field of the packet is corrupt. The transport layer must ensure that packets arrive at their destination and that the packet is received without error. Many architectures can be used to ensure packets are received correctly. The most common method is to require a reply to every packet sent over the network. This reply is either a simple acknowledge packet, a packet contain data requested by the transmitting processor, or an error packet indicating a problem has occurred. The transport layer can now detect that a packet is lost by using a timer. The transport layer of the transmitting processor starts a timer when a packet is sent over the network. If a reply is not received within a given time frame the transport layer concludes that the packet is lost. Detection of a corrupt packet is handled using a checksum. A checksum is calculated using the bits in a packet and is transmitted along with the packet. The receiving processor then re-calculates the checksum from the received packet and compares it to the received checksum. If the checksums do not match then an error has occurred. The transport layer of the receiving processor will then cause the communication system to send back an error packet indicating the error. Together, these two methods provide robust recovery from communication errors. Recovering from these errors is usually done by re-transmitting the packet. After several attempts at delivering the packet the transport layer may conclude that the destination is invalid or the environment too noisy to successfully deliver the packet. At this point, an error can be reported to the application layer.

2.4 Standard Communication Protocols Several communication protocols are widely used in communication systems. Protocols exist for communication between chips residing on a single board to processors spanning the entire globe. The former usually specifies only the physical layer and a portion of the network access layer while the latter specifies all layers of the communication system. A comprehensive review of all available protocols is beyond the scope of this paper. Protocols considered for the AUVic-CS will be highlighted in this section. These protocols were selected as they are widely available as an integrated component on lower end microcontrollers and deliver a good balance between simplicity, required processing power, data rate, and error detection. Important properties of these protocols are summarized in Table 2.1 and a general description of each protocol is given below:

• Inter-Integrated Circuit (I2C): I2C is a two wire data bus that operates in either a master/slave or multi-master configuration. It was designed to allow communication between processors and is widely used in audio/visual equipment, PC motherboards, and in “smart” batteries [3]. It specifies the physical layer of the network and some features of the network access layer (namely, how nodes are addressed on the network). A network of arbitrary size is well suited to this protocol and support is provided for 7-bit or 10-bit addressing.

• Serial Peripheral Interface (SPI): SPI is a 4 wire data bus that operates in a master/slave

configuration. Multi-master functionality can be achieved, but is not directly supported by the protocol. SPI was designed for interfacing microcontrollers to peripheral (keypad, LCD, external memory, etc.), but can be used for inter-processor communication. The

11

protocol does not scale well to arbitrary sized networks, as individual chip select lines are required for each node on the network if high data rates are required.

• RS485: RS485 is a two or four wire data bus (depending if full or half-duplex operation is

required) that uses differential voltage transmission to allow for long cable lengths. It can be configured into any topography, but is typically used in a master/slave linear bus or multi-master architecture. Only the physical layer is specified and address detection is often done in software (newer RS485 components support hardware address detection). A network of arbitrary size is easily handled as suitable hardware can support 256 nodes.

• Dallas 1-Wire (D1W): D1W is a single wire bus that operates in a master/slave

configuration. Multi-master operation is not possible. It was designed to allow an inexpensive network of integrated circuits (ICs) to be built. The slow data rate of the D1W protocol limits its application in many communication systems.

• Controller Area Network (CAN): CAN is a 2 wire data bus that operates in an Aloha

linear bus configuration. The bus has no master and nodes are not assigned addresses. Instead, all packets are given an identification number and each node determines what packet types it should process. Packets are placed on the network using a priority scheme and resolve bus collisions using an Aloha-type scheme. Both the physical and network access layers are specified by the protocol. The protocol was designed for use in automotive industry during the late 1980’s and is well suited to an arbitrary size network.

Table 2.1 Properties of Select Standard Communication Protocols 1 Communication is always initiated by the master. 2 A cascaded master/slave architecture is possible that keeps the total number of bus lines required to 4, but this architecture does not scale well to arbitrary sized networks requiring high data rates.

2.5 Rational for a Distributive System A distributed system contains multiple processors distributed throughout an environment with the capability of communicating with each other. These processors may work together by allowing collaborative processing of information (i.e. parallel processing), data/application/resource sharing (i.e. typical personal computer network), or each specialize in controlling a subset of tasks in the overall system (i.e. intelligent peripherals). In all cases, the computational ability of the system is contained in multiple processors. Several advantages are obtained by using a distributed system. A distributed system allows the systems engineer to break the system into smaller, more manageable subsystems. Each of these subsystems performs a high level function required by the systems. This provides a clear

Protocol Duplex Standard Data Rates (Kbps)

Length Cost Multi-Master Support

Standard Topography

Hardware Addressing

Bus Lines Required

I2C Half 100/400/3400 ~4m @ 400Kbps

Low Yes Master/Slave Linear Bus

Low 2

SPI Full2

312.5/1250/5000 ~4m @

312.5Kbps Low No Master/Slave

Linear Bus1

Low 3 + 1 per slave

2

RS485 Full 0-1000 100m @ 1Mbps

Med-ium

Yes Not Specified

Medium 2 (Half-duplex) 4 (Full-duplex)

D1W Half 0-16.3 100m + @ 16.3 Kbps

Low No Master/Slave Linear Bus

Medium 1

CAN Full 250/1000 40m @ 1Mbps

High Yes Linear Bus High 2

12

mapping between system functionality and structure that aids in the design, development, testing, and future expansion of the system. Each subsystem communicates with the system through a standardized, well-defined interface and there are no dependencies between subsystems. This allows all subsystems to be built in parallel and integrated into the system one at a time. Subsystem can be tested independently and the system tested incrementally as each subsystem is added. These factors combine to reduce the time required to build the system. Since each subsystem provides high level functionality to the system, it is often possible for the system to operate in a useful manner before all systems are complete or if a subsystem fails. It is often possible to expand a distributed system simply by adding a subsystem that follows the interface defined for the system. This promotes an incremental approach to building the system where only the smallest subset of subsystems required to produce a useful system need be initially designed and built.

13

3.0 Specifications of AUVic-CS The final specifications set for the AUViking drive all decisions made in the design of the AUVic-CS. Specifications for the AUVic-CS were formed by considering the algorithms AUViking requires to complete the AUVSI International AUV Competition and the communication that is required between subsystems in order to implement these algorithms. A detailed understanding of the algorithms AUViking will use and an understanding of each subsystem is required to fully appreciate the development of the specifications stated here. Additionally, these specifications reflect changed that became clear only as the AUVic-CS design progressed. This level of understanding is beyond the scope of this paper, but when possible justification for specifications will be provided. It is hoped the AUVic-CS system will be robust enough to find application in future AUVs developed by the AUVic. The specifications developed in this section will indicate additional requirements that would increase the expandability and flexibility of the AUVic-CS. These additional specifications were followed where time and money permitted.

3.1 Physical Layer Specifications Several specifications are required to properly define the physical layer of a communication system (network topography and architecture, hardware addressing, network length, number of nodes, data rate). Each of these specifications will be developed here with the exception of data rate. The data rate required is a consequence of the desired throughput. In the next section, the desired throughput will be determined and an estimate of the data rate necessary to achieve this throughput calculated. Table 3.1 summarizes the physical layer requirements for the AUVic-CS. The algorithms used by AUViking require data from multiple sensors. This implies that one of the nodes in the system will have to act as a central processing unit capable of gathering data from multiple sensors and making decisions based on this data. The remaining nodes are all intelligent peripherals that benefit from not being able to communication with each other as this ensures they are independent on other subsystems. From the discussion in section 2.1.2 it is clear this system is well suited to a master/slave architecture. Master/slave architecture requires only a half-duplex communication channel and uses the linear bus topography which is supported by many standard protocols (see Table 2.1). Hardware supporting a multi-master slave configuration would allow the system to expand to this architecture if required in future generations, but this architecture will not be used on AUViking in order to keep peripherals independent from each other. An initial design of the AUViking hull is complete. The dimensions have not been finalized, but will be approximately 30cm x 80cm x 30cm (L x W x H). If the length between the main branch of the wiring harness and each node is 10cm then a wiring harness of 80cm + 6*10cm = 140 cm (the width of AUViking is 80cm and there are 6 peripherals on AUViking) should be sufficient. To allow for a more flexible wiring harness design and future expansion the minimum wiring length is specified as 300 cm. In addition, it is desirable to have a bus that can be expanded beyond 300 cm to aid in further future expansion (even if a repeater or other hardware solution is required to allow this expansion). The design of AUViking has progressed to a point where it is clear there will be seven nodes on the network. It is unlikely the number of peripherals on future generations of the AUV will exceed 16, making it a suitable minimum value for the specification. In practice this requirement is easily achieved by all the protocols specified in section 2.4.

14

Hardware addressing is beneficial as it can often be exploited to simplify the network access and transportation layers and reduces the processing required by nodes. For these reasons it is desirable for the AUVic-CS to support hardware addressing. However, it has not been made a requirement as these benefits are not substantial enough to discard software addressing.

Specification Required by AUViking Desired for Future Expansion Network Topography and

Architecture master/slave, linear bus master/slave, linear bus with

multi-master support Hardware Addressing desirable desirable

Length 300 cm expandable beyond 300 cm Number of Nodes 16 16

Data Rate 100 Kbps expandable beyond 100 Kbps Table 3.1 Physical Layer Specifications

3.2 Network Access Layer Specifications

Two metrics are commonly associated with the network access layer: packet efficiency and throughput. This section will reveal that packet efficiency is a poor measure of a communication systems performance so does not require specification. Throughput is the important metric of a communication system and the required throughput of the AUVic-CS will be discussed in detail. Table 3.3 summarizes the network access layer specifications for the AUVic-CS. The nature of the AUVic-CS implies the packet efficiency will be poor as most packets contain few content bytes. A better measure is the number of additional bits required by the communication system in order to reliably transmit a packet. Even this measure is not of particular importance though as additional bits may allow packets to be processed faster. That is, higher packet efficiency does not necessarily indicate the system will have a higher throughput. Here we will determine the desired throughput of the AUVic-CS. The master node of AUViking communicates with each peripheral in a round-robin fashion. Table 3.2 indicates all the packets that will be transmitted by the master along with the total length of each packet and the length of the reply sent by the slave (assuming 3 bytes are required by the AUVic-CS: destination, length, checksum). In order for AUViking to be responsive it is believed these packets must be transmitted at 10Hz. To achieve this, the throughput of the AUVic-CS must be 1260 bytes/sec = 10.08 Kbps.

Packet Length of Packet (in bytes)

Length of Reply (in bytes)

3 * Set Motor 3 * 6 = 18 3 * 4 = 12 3 * Get Motor Flags 3 * 4 = 12 3 * 5 = 15 Get Pressure Data 4 6

Get Battery Voltages 4 10 Get Temperature Flags 4 6

Get Sonar Data 4 10 Get Inertial Guidance Data 4 6

Get Compass Data 4 7 Total: 54 72

Table 3.2 Packets Requiring Transmission at 10Hz Before the master can send another packet it must receive a reply to the previous packet. A communication session can be defined as:

1. the master sending a packet 2. a slave processing the packet 3. a slave generating a reply

15

4. a slave sending a reply 5. the master processing the reply

If steps 2, 3, and 5 took zero time then the throughput and data rate would be almost equal. They are not equal as most communication protocols send one or two extra bits for each byte sent. These extra bits are used either as an acknowledgement that the last byte was received (I2C uses this approach) or to aid in synchronizing clocks for communication systems that do not share a clock line (RS485 uses this approach). If the worst case of 2 extra bits for a byte is assumed and steps 2, 3, and 5 took zero time the data rate of 12.6Kbps would be sufficient. To estimate the time required by steps 2, 3, and 5 it will be assumed each step can be accomplished in 1000 assembly language instructions. This is a gross exaggeration of the number of instructions that will typically be required. As will be seen later, the processor used for each node requires 200ns to execute an assembly language instruction. A time of 3000 * 200ns = 0.6 ms is easily sufficient for steps 2, 3, and 5. In one second the AUVic-CS must be able to handle 120 communication sessions (there are 12 packets that must be sent at 10Hz) so the total time spent on steps 2, 3, and 5 is 120 * 0.6 ms = 72 ms. This indicates the AUVic-CS must be able to handle a data rate of 12.6Kbits in 928 ms = 13.5Kbps. All of the communication protocols can easily handle this data rate (see Table 2.1). With the exception of the D1W protocol, a data rate of ~100Kbps is easily achieved. This data rate would allow for future expansion and allow the AUViking to operate at a higher frequency if desired. Since the throughput requirement of the AUVic-CS may increase significantly for future generations (either because the number of packets or frequency to send packets increases) it is desirable to use components that would allow higher data rates to be achieved.

Specification Required by AUViking (Kbps)

Desired for Future Expansion (Kbps)

Packet Efficiency not specified not specified Throughput (absolute minimum) 13.5 13.5

Table 3.3 Network Access Layer Specifications

3.3 Transportation Layer Specifications

The AUVic-CS does not define any quantitative specifications for the transport layer. However, several types of communication errors can occur and the transport layer should be able to recover from all of them. Recovering from a communication error simply means the communication system will be able to continue sending packets within a reasonable amount of time. It does not mean that every packet will be processed as expected. For example, if the destination field of a packet becomes corrupt such that it is sent to a node other than the intended node and the checksum is still valid (unlikely, but not impossible if multiple bits in the destination and checksum fields are corrupt) then a communication error will occur that the AUVic-CS cannot detect. The node will attempt to process the packet and may successfully interpret it as a valid packet type resulting in the node taking an undesirable action (i.e. it may set the motor speed to 0 even though the original packets intent was to get the compass data). This situation is unlikely, but possible. Section 5.0 will discuss steps taken to minimize the possibility of this situation occurring.

16

3.4 Other Specifications The following specifications are qualitative in nature and result from the nature of the AUVic. They are important as they represent real constraints faced by the group, but they do not directly affect the functionality of the AUVic-CS. Table 3.4 summarizes these additional specifications. A major constraint of the AUVic is a limited budget to complete the project. Funding for the project is through sponsorship, making it impossible to determine the exact budget. The end result of this is that the cost of the AUVic-CS should be kept low while still meeting all requirements for the AUViking and allowing for future expansion where possible. The AUVic-CS consists of several identical nodes (at least from the point of view of the communication system) so it is desirable to keep the cost per node at a minimum. The 6th International AUV Competition will be held sometime during the summer - most likely at the end of July. This put a strict timeline on the completion of AUViking. For this reason it is desirable to choose technology that members of the AUVic are familiar with. Most importantly is choosing microcontroller architecture and programming language that is familiar to many of the team members. It is hoped the AUVic-CS will be used on future generations of AUVic AUVs. To aid in this it is desirable to use technology that is widely used and likely to be familiar to future team members. This will make it easier for future teams to learn the AUVic-CS. It is difficult to determine the skill set of future teams, but it seems wise to stick with traditional practices unless there is a compelling reason not to.

Specification Required by AUViking (Kbps)

Desired for Future Expansion (Kbps)

Cost per Node Low Low Ability to Leverage Existing Skills

in the AUVic High High

Easy to Learn AUVic-CS High High Table 3.4 Network Access Layer Specifications

17

4.0 Design of Communication Layers The AUVic-CS consists of three types of systems: the host, the hub, and intelligent peripherals. Figure 4.1 is an overview of the systems on AUViking showing sections specific to the AUVic-CS in red. All peripherals on AUViking communicate with the host via the AUVic-CS with the exception of the camera. The high data rate required by the camera makes placing it on a separate connection a more suitable option. This year’s team is in the early design stage of expanding the AUVic-CS to allow a desktop PC to communicate with AUViking via a wireless Ethernet connection.

Figure 4.1 AUVic-CS Overview The host is the central processing unit in the AUViking. It is responsible for gathering sensor data, processing this data, and setting the actuators (motors) based on sensor data and desired goals for the AUV. Intelligent behaviour emerges from AUViking by mission specific algorithms processing the sensor data and setting the motors accordingly. For example, a simple algorithm on the host is collision avoidance that ensures the AUV is always a minimum distance away from the bottom of the pool by using data from the sonar system. A MSI 300MHz PC/104+ embedded PC is being used for the host on AUViking. This board was purchased for Antitanic and in order to save money will be reused this year. It is a requirement of the communication system to be compatible with the MSI embedded PC. The MSI embedded PC contains 2 RS232 serial ports and 1 free USB port the AUVic-CS could use. As shown in Figure 4.1, a hub (Microchip PIC16F876) was used to attach the host to an I2C network. The hub acts as a protocol translator between the host and the intelligent peripherals. Intelligent peripherals communicate with the hub over a linear bus using I2C and the host communication with the hub using an RS232 serial port. The hub also provides error checking and recovery and has the ability to reset any peripheral on the I2C network by toggling a Dallas 1-Wire (D1W) digital switch contained on each peripheral.

18

Each intelligent peripheral is a self contained unit that communicates using the protocol defined by the AUVic-CS. Peripherals are effectively black -boxed as only the communication protocol needs to be known to interact with it. An intelligent peripheral is responsible for providing an interface that adheres to the AUVic-CS protocol and allows the host to request all required information from the peripheral and set any peripheral properties. A common backplane containing power and signal lines is routed to each peripheral and the hub. Power lines provide each peripheral with +5V, +12V, -12V, and ground. The signal lines consist of both the I2C and D1W network lines and an end mission signal line. An external switch controls the end mission line and is used to informs all systems when a mission run is completed or aborted. Each layer of the AUVic-CS will be examined with a focus on justifying the design decisions made. These decisions lead to the system shown in Figure 4.1 and specify several other properties of the AUVic-CS.

4.1 Design of Physical Layer

The most important design decision for the physical layer is the communication protocol that will be used. Almost all aspects of the physical layer will be defined in the specification of the selected communication protocol. All that remains in the design of the physical layer is selecting components compatible with the communication protocol and designing the infrastructure (cabling, connectors, etc.).

4.1.1 Selecting a Communication Protocol The decision of what communication protocol to use determines several of the properties the physical layer will have (available data rates, network topography, maximum number of nodes, etc…). All of the protocols being considered have little influence on the design of the network access layer. For these reasons it is appropriate to discuss the selection of a communication protocol in conjunction with the design of the physical layer. Comparing Table 2.1 to the specifications developed in section 3.0 it is clear that the I2C and RS485 protocols are most appropriate for the AUVic-CS. Both protocols meet all the specifications of the AUVic-CS and allow for future expansion. The SPI protocol is not appropriate as it does not scale well to arbitrary networks and has no multi-master support. The D1W protocol does not support the required data rate specified for the AUVic-CS, making it unacceptable. Finally, the CAN protocol was not considered in detail due to its high cost per node and because the AUVic team has no experience with an Aloha linear bus architecture. Table 4.1 compares the I2C and RS485 protocols based on the characteristics given in Table 2.1. The table is far from conclusive in determining what protocol is more suitable. The importance of each characteristic must also be considered:

• Duplex: The RS485 protocol can accommodate a full duplex channel, but in many communication systems this ability is not utilized. The reason for this is communication systems often use a master/slave linear bus topography which is half-duplex by nature as the master initiates all communication. It has already been determined that the AUVic-CS is well suited to this topography.

• Standard Data Rates: It is critical that the selected protocol be able to operate at (or above) the specified data rate. Both the I2C and RS485 protocols can operate at the 100 Kbps specified for the AUVic-CS and can handle higher data rates if required in the future. It should be noted that both the I2C and RS485 protocols can be set to any desired data

19

rate less than their maximum specified value, but typically operate at one of the standard data rates.

• Length: It is unlikely that the communication system on any AUV developed by the AUVic team will require a length greater than 4m. If required, the maximum length of the I2C network can be expanded by using a current amplifier on the bus lines [4].

• Cost per Node: Many low cost microcontrollers contain an I2C and a TTL serial port, but few have a RS485 port. Because of this the cost per node of using RS485 is slightly higher as a TTL serial to RS485 converter is required for each node. The microcontrollers used in AUViking cost ~$15 and a TTL serial to RS485 converter IC cost ~$2.

• Multi-Master Support: Multi-Master support is desirable as it may be required in the future. Both protocols contain multi-master support.

• Standard Topography: The RS485 protocol can be configured for any topography which may prove advantageous in the future. However, AUViking will use a linear bus topography and this topography is widely used because of the advantages discussed in section 2.1.2.

• Hardware Addressing: The I2C protocol has the advantage of supporting hardware addressing (see section 2.1.4).

• Bus Lines Require: Given the short length of the AUVic-CS network the number of bus lines is of little importance. In longer networks this factor is important as the cost of cables can become the dominating cost of the network.

Characteristic I2C RS485 Favored Protocol Duplex Half Half or Full RS485 Standard Data Rates (Kbps) 100/400/3400 0-1000 Neither Length ~4m @ 400Kbps 100m @ 1Mbps RS485 Cost Per Node Low Medium I2C Multi-Master Support Yes Yes Neither Standard Topography Linear Bus Not Specified RS485 Hardware Addressing Yes No I2C Bus Lines Required 2 2 (Half-duplex)

4 (Full-duplex) Neither

Table 4.1 Comparison of I2C and RS485 Protocols The decision to use the I2C protocol was driven largely by the decision to use Microchip PIC16F87x microcontrollers and because it supports hardware addressing. This microcontroller was selected as current team members have experience with this family of microcontrollers, they are readily available, inexpensive, widely used, and directly support I2C communication. In addition, Hi-Tech Software generously donated their PIC C compiler to the AUVic team. Due to the timeline to complete AUViking, it was determined that all software should be written in C to leverage the teams’ familiarity with this language and the advantages of a high level language. Selection of the I2C protocol defines several properties of the physical layer. Detailed information about the I2C protocol can be found in [5]. Important properties for the AUVic-CS and the selection of different I2C protocol options are discussed here:

• Data Rate: Although it is possible to operate the PIC16F87x I2C module at any data rate under 1Mbps, it is desirable to use one of the standard I2C data rates so I2C devices can be connected to the network. A data rate of 400Kbps was selected as it will allow for future expansion and/or packets to be sent at a rate greater than 10Hz and is a standard data rate support by most I2C devices.

• Number of Nodes: The I2C protocol supports 7 and 11-bit addressing. A 112 nodes (the other 16 nodes provide network services such as broadcasting) can exist on the network with 7-bit addressing which is more than sufficient for AUViking.

• Broadcasting: The I2C protocol supports broadcasting of packets by setting the address to 0.

20

• Data Lines and Length: An I2C network consists of a data line (SDA) and a clock line (SCL). Both lines are open-collector and require a pull-up resistor. If the length of the network needs to be increased, the pull-up resistors can be replaced with an active current source. Pull-up resistors allow a network length of 4m when operating at 400Kbps.

• Master/Slave Linear Bus: The I2C protocol supports multi-master operation, but AUViking operates in a strict master/slave configuration. In the AUVic-CS the master is the hub and the slaves are the peripherals.

4.1.2 Hub: An I2C to RS232 Converter Using the MSI embedded PC board is a requirement of the AUVic-CS. To connect the host to the I2C network requires an RS232 to I2C converter. It was decided to use a PIC16F876 to implement an intelligent RS232 to I2C converter or hub. The use of a hub has many advantages over a straight RS232 to I2C converter that are utilized in the AUVic-CS. The hub allows the MSI embedded PC to seamlessly connect to the I2C bus and provides error detection, error recovery, and the ability to reset peripherals. When the host sends a packet to a peripheral via the hub it will handle any communication errors reported by the peripheral. Typically, an error reported by a peripheral will result in the hub sending the packet again. This reduces the processing demands on the MSI board. A unique feature of the AUVic-CS is made possible through the use of a hub. The hub allows the host to communicate over a Dallas 1-Wire (D1W) network that provides the ability to reset individual peripherals in AUViking. Resetting a peripheral can often allow them to recover from programming errors in the device itself or from communication errors on the I2C network. The RS232 channel between the host and hub currently operates at 115Kbps. This is significantly slower than the 400Kbps the I2C network is operating at. Strictly speaking the hub is the master on the I2C network, but since the hub simply forwards packets sent by the host it is often convenient to think of the host as the master. This means all communication on the I2C bus originates from the host and must travel through the slower RS232 channel. Both the host and hub are capable of operating at data rates up to 1Mbps if a suitable clock rate is used for the hub. As of this writing, a crystal capable of producing the clock rate required for the hub to operate at speeds higher than 115Kbps has not been obtained. Such a crystal will be used in the final production of the host and the data rate of the RS232 channel increased to around 460 Kbps (a standard RS232 data rate) to match the 400Kbps data rate of the I2C network.

4.1.3 Infrastructure of AUVic-CS The infrastructure for the AUVic-CS consists of the processors, electronic devices, cabling, connectors, and other physical entities that comprise the communication system. A peripheral is free to use any processor that can meet the specification and design requirements for the AUVic-CS, but all peripherals currently in production are using a Microchip PIC16F876. The hub is also a Microchip PIC16F876, in order to keep the number of different processors being used to a minimum (a slower processor with less inputs and outputs could have been used for the hub). As previously discussed, the host is a MSI 300MHz PC/104+ embedded. No electronic devices are required for the AUVic-CS outside of simple pull-up resistors for the I2C and D1W line(s). An I2C network consists of an open-collector data line (SDA) and clock line (SCL) which both require a pull-up resistor. The single D1W line is also open-collector and

21

requires a pull-up resistor. The RS232 connection consists of two data lines, but requires no external components. The RS232 connection between the host and hub is accomplished by using a standard 9-pin serial connector. Two lines are used for the required data lines and a third for a common ground. The remaining pins are left unconnected. A standard 9-pin serial connector was used for simplicity as serial cables are widely available. A more complicated wiring harness (referred to as a backplane) is required between the hub and each peripheral. As of this writing, the cabling and connectors have not been determined. However, the lines required have been specified as follows:

• Power Lines: All peripherals will receive 5V, 12V, -12V, and ground. The current rating for the entire network is 5V @ 3A, 12V @ 2A, -12V @1A.

• I2C Lines: All peripherals will receive the SDA and SCL lines for the I2C bus that must be connected to open-collector pins. The pull-up resistors will be located on the hub board.

• D1W Line: All peripherals will receive a single line for the D1W bus that must be connected to an open-collector pin. The pull-up resistor will be located on the hub board.

• End Mission: All peripherals will receive the end mission signal. It is recommended that this signal be attached to an interrupt pin to ensure a peripheral promptly responds to the signal. This signal informs all peripheral that a mission run is over and is triggered by toggling an external switch on the AUV. The AUVSI competition rules require that all systems cease processing and collecting data when a mission run has ended and that all actuators (i.e. the motors) move to an idle state.

• Additional Lines: Two additional lines are being carried along the backplane. These lines are connected to output pins on the hub and can be used for future expansion. These lines should be connected to input pins on the peripherals.

4.2 Design of Network Access Layer

The network access layer is responsible for defining a packet structure that will allow data to be transmitted between nodes and processed by the receiving node. In order to define the packet structure, it is beneficial to first examine who may transmit packets and when packets can be transmitted. Combined, these restrictions determine how packets flow throughout the network. This section will conclude by examining the network services provided by the AUVic-CS.

4.2.1 Flow of Packets The AUVic-CS operates as a half-duplex network with strict rules controlling the flow of packets. The rules governing the AUVic-CS are: 1. all communication starts with a packet sent by the host 2. the host requires a reply to every packet This design is typical for a communication system using a master/slave linear bus topography. The master/slave architecture requires all communication to be initiated by the host (master). Since the host acts as the central processing unit in AUViking it is natural for it to initiate communication by sending out a packet requesting information from a sensor or setting a property of an actuator. It is possible for the host to initiate communication by allowing a given peripheral (slave) to send the first packet. This gives control of what information to send to the peripheral. This is not suitable for AUViking as there is no way for the peripheral to know what sensor information is currently required by the host. A reply is required for every packet to ensure it is received and the checksum is valid. By requiring a reply packet the majority of communication errors can be detected and gracefully

22

recovered from (see sections 5, 6, and 7). Although it is possible for a communication error to go undetected (see section 3.3 for an example), requiring a reply reduces this possibility to an acceptable level. The reply packet is an essential part of the transportation layer and an analysis of the probability of an undetected communication error occurring will be calculated in section 4.3. These two rules are sufficient to describe the operation of the AUVic-CS. Figure 4.2 illustrates how a typical packet moves through the network. The host sends a packet to the hub via RS232. If the packet is addressed to the hub then it immediately processes the packet and sends a reply to the host. The host is now free to send another packet. Otherwise, the packet is for a peripheral on the I2C network and the hub will simply forward the packet as it is received from the host. It is a requirement of all peripherals that they send a reply to every packet they receive. The hub forwards any data it received on the I2C network to the host. The host is free to send another packet only after it has received a reply. These rules imply several invariants about the AUVic-CS:

• a peripheral can only receive a packet from the host • a peripheral can only send a packet that is a reply to the host • packets addressed to the hub come from the host • the hub can only send a packet that is a reply to the host • a reply must be sent for every packet received • the host can only receive a packet that is a reply

Figure 4.2 Typical Network Operation

4.2.2 Packet Structure

The packet structure used must allow packets to be sent to specific nodes and should strive to keep the time required to process packets to a minimum. A balance is required between keeping packet efficiency high (thereby reducing the number of bits that must be sent per packet) and providing enough information to allow nodes to process packets in a timely and logical manner. Figure 4.3 shows the packet structure used by the AUVic-CS.

Destination \ Source (1 Byte) Length (1 Byte)

Type (1 Byte) Contents (0-20 Bytes)

Checksum (2 Byte) Figure 4.3 Packet Structure

Each node on the I2C network along with the host is given a unique address. The destination/source byte is used to send packets to a specific node on the network. The half-duplex nature of the AUVic-CS, along with the fact that all packets originate from the host, is taken advantage of to allow a single byte to represent either the destination or source of a packet. This allows the host to check who a reply packet is from. This is useful as the host may send a packet to a node of the I2C network, but receive a reply from the hub indicating that an error has occurred. When a packet is traveling from the host to the hub or a node on the I2C network the destination/source byte represents the intended destination of the packet. When a packet is traveling from the hub or a node on the I2C network the destination/source byte represents the

23

source of the reply packet. For example, if the host sends a packet to the port motor controller then the destination\source is set to the port motor controller address. The reply from the port motor controller also sets the destination\source byte to the port motor controller address to indicate it is the source of the reply. There is no need to indicate that the reply is for the host as replies are always for the host. The length byte indicates the number of content bytes in a packet. The minimum length of a packet is 0 (destination/source, length, type, 0 content bytes, checksum) and the maximum length of a packet is set to 20 (destination/source, length, type, 20 content bytes, checksum). The length byte is used by nodes on the network to determine when a complete packet is received. Setting the maximum length of a packet reduces the amount of memory required by a node to receive a packet. Since an entire byte is being used for the length field, the maximum length could be set as high as 255 bytes. Unfortunately, this would require each node to have 259 bytes of data memory available to receive a packet. On a low cost microcontroller this is a significant amount of memory (for example, the PIC16F876 has only 386 bytes of data memory). The type byte informs a node on the network what sort of packet it has received. Every packet that a node can receive must have a unique type byte so it knows how to correctly process the packet. For example, the motor controllers can accept over 15 different packet types (set motor, set acceleration, set current limit, etc...) and must perform a different action for each type of packet. How the content bytes are interpreted is dependent on the packet type. For example, when a motor controller received a set motor packet it interprets the 2 content bytes as a 16-bit word where the MSBit indicates the direction and the 10 LSBits represents the motor speed between 0 (stop) and 1023 (full speed). It is the responsibility of each peripheral in the system to define what packet types it can accept and the format of any content bytes in these packets. The checksum is used by the transportation layer to help ensure packets are received without error. Details on the checksum used by the AUVic-CS have been left to section 4.3. A total of 40 bits (1 byte destination/source field, 1 byte length field, 1 byte type field, 2 bytes checksum) are required for the AUVic-CS system to transmit and process a packet. This results in relatively low packet efficiency as many packets have only a few content bytes. Here it will be argued that using 40 bits is justified. Almost all modern processors are more efficient at processing groups of bits that are a multiple of 8. The reason for this is beyond the scope of this paper, but it stems from the fact that memory is organized into bytes. For this reason, a checksum that is one or more bytes is typically used to allow it to be computed quickly. Section 4.3.1 will justify the use of a 16-bit as opposed to 8 or 32-bit checksum. The minimum number of bits required for the remaining three fields is 18 bits. To accommodate 32 nodes as specified for the AUVic-CS requires the destination/source field to be a minimum of 5 bits. However, the I2C protocol specifies that addresses must be either 8 or 12 bits in length (actually, 7 or 11 bits plus a bit indicating if a read or write operation is to follow) so the destination/source field is set to 8 bits. The length field could be set to 5 bits to indicate a packet of length 0 to 31 and the type field set to 5 bits to allow 32 packet types to be specified. Most communication protocols require data to be sent one byte at a time and the I2C protocol is not an exception to this rule. Therefore, either 8 or 16 bits can be used for the length and type fields. A single byte is not sufficient as peripherals may define more than 16 packet types (thus, the type field requires a minimum of 5 bits) and setting the maximum length of a packet to 8 (so it could be represented in 3 bits) was considered unacceptable as this would mean some replies would require two packets in order to transmit the desired information.

24

4.2.3 Network Services The AUVic-CS defines several standard packets that all peripherals on the I2C network and the hub must be able to respond to. These standard packets are network services that provide the host with a uniform way to handle commonly required tasks. Each of these network services (Acknowledge, Error, Diagnostic, Status, End Mission, Shutdown) along with broadcasting will be discussed. An acknowledge packet provides nodes with a uniform way to reply to a packet. The reply to all packets should be of this type unless otherwise specified. Having a uniform packet type for replies simplifies the logic required to process replies. Figure 4.4 gives the structure for an acknowledge packet.

Destination (1 Byte)

Length (1 Byte) Type (10)

Contents (Variable) Checksum (2 Byte)

Figure 4.4 Acknowledge Packet Error packets provide a uniform way in which nodes can report an error to the host. A single content byte is used to indicate the type of error. Appendix I contains a listing of predefined error types that is very comprehensive, but a peripheral is free to define other error codes if required. For example, if a node determines that a packet is corrupt because the checksum check fails then it can respond with an error packet with the content byte set to SLAVE_CRC_FAILED. Figure 4.5 gives the structure for an error packet.

Destination (1 Byte)

Length (0) Type (15)

Error Code (1 Byte) Checksum (2 Byte)

Figure 4.5 Error Packet The diagnostic packet is used by the host to determine if a given address is present on the system. During initialization the host can send out diagnostic packets to determine what peripherals are currently attached to the network. The host can indicate an error if a given peripheral is not present. Ideally, the host would then try to accomplish its mission with the peripherals that are currently available. In practice, it may be more economical to simply resolve the error. The reply to a diagnostic packet is a diagnostic packet and not an acknowledge packet in order to allow the host to take special action for diagnostic packet if desired. The structure of the diagnostic packet is given in Figure 4.6.

Destination (1 Byte)

Length (0) Type (1)

Checksum (2 Byte) Figure 4.6 Diagnostic Packet

A status packet is used to query a peripheral for its current state. The response to this packet is dependent on the peripheral, but should contain the value of all properties that can be modified by “set” packets. That is, any property of a peripheral that can be modified by sending it a packet should have its current value contained in the reply to a status packet. For example, the motor controllers implement a “set temperature limit” packet so will provide the current temperature limit

25

setting in the reply to a status packet. The number of content bytes and how they are interpreted is defined by each peripheral. Figure 4.7 gives the structure of a status packet.

Destination (1 Byte)

Length (1 Byte) Type (3)

Contents (Variable) Checksum (2 Byte)

Figure 4.7 Status Packet The end mission packet informs a peripheral that a mission run is over. At the end of a mission all sensor must stop collecting data and all actuators should be brought to an idle state. The end mission packet allows the host to determine that a mission should be considered complete. During a competition run the end mission signal will be generated by toggling an external switch and the signal delivered to each node explicitly. The structure of the end mission packet is given in Figure 4.8.

Destination (1 Byte)

Length (0) Type (4)

Checksum (2 Byte) Figure 4.8 End Mission Packet

The shutdown packet informs a peripheral that it should immediately shutdown. In normal operation this packet should not be used. It is intended to be used as an emergency shutdown of all systems. The action taken to a shutdown packet is dependent on the peripheral. For example, a motor controller should immediately turn off the motors upon receiving a shutdown packet whereas the sonar system should simply stop collecting data. Figure 4.9 gives the structure for a shutdown packet.

Destination (1 Byte)

Length (0) Type (2)

Checksum (2 Byte) Figure 4.9 Shutdown Packet

Broadcasting is supported by the AUVic-CS in order to allow the end mission and shutdown packets to be delivered to all peripherals in a timely and convenient fashion. In addition, broadcasting is directly supported by the I2C protocol making it simple to implement. All peripherals and the hub should accept and process broadcasted packets. The hub will send a reply to the host indicating that the broadcasted packet was sent over the I2C network. However, no verification is done to ensure that all peripherals correctly received the packet.

4.3 Design of Transport Layer The transportation layer is responsible for detecting communication errors and allowing the communication system to recover from them. Four different classes of communication errors are possible: lost packets, corrupt length, detectable corrupt packets, and undetectable corrupt packets. All of these errors result from packets becoming corrupt during transmission due to electrical noise in the environment. All four classes of communication errors will be examined in this section. The methods used by the transport layer to detect and recover from lost packets, corrupt length, and detectable corrupt packets are discussed along with steps that can be taken to minimize the likelihood and effect of

26

undetectable corrupt packets. This section concludes with a discussion on the Dallas 1-Wire reset network used on the AUVic-CS to provide recovery from extreme errors.

4.3.1 Detectable Corrupt Packet (Checksum) The goal of the transportation layer is to ensure the majority of communication errors can be detected. This can be accomplished by adding a checksum to the packet. The AUVic-MC uses a 16-bit cyclical redundancy check (CRC) checksum based on the CCITT polynomial (x16+x12+x5+1). [6] can be consulted for more information on how a CRC checksum is generated. When a node receives a packet it calculates the expected checksum and compares it to the received checksum. If the two checksums do not agree, then the node can conclude the received packet contains errors. A CRC checksum is used in the AUVic-CS as it provides robust detection of burst errors [7]. A burst errors pattern of length b begins and ends with bits in error separated by b-2 bits that may or may not be in error. For example, a burst error pattern of length 5 can be written as …000ExxxE000… where 0 indicates a bit that is not in error, E indicates an error bit, and x indicates a bit that may or may not be in error. Burst errors are common in communication systems making CRC checksums a popular choice. Table 4.3 compares 8-bit, 16-bit, and 32-bit CRC algorithms based on table look-up. Table look-up CRC algorithms require substantially more memory than more traditional CRC algorithms, but reduce the processing time to a level more suitable for low speed microcontrollers. Note that the look-up table can be placed in program memory of which several kilobytes are usually available on even cheap microcontrollers (the PIC16F876 has 8K of program memory). It was deemed that a 16-bit CRC checksum provided the best mix of characteristics. The increased possibility of receiving a corrupt packet that passes the CRC check – an undetected communication error – from using an 8-bit CRC is too high. The seriousness of undetected communication errors will be discussed later in this section. A 32-bit CRC checksum requires too much program memory and causes an unacceptably low level of packet efficiency. Characteristic 8-bit CRC 16-bit CRC 32-bit CRC Memory (bytes) 256 512 1024 Processing Time (per byte)1 400 ns 1000 ns 2000 ns Worst-case Burst Error Detection (%) 99.219 99.997 99.999 1 Assuming a PIC16F876 using a 20MHz clock

Table 4.2 Comparison of CRC Table Look-up Algorithms

4.3.2 Lost Packets (Communication Timer)

A packet becomes lost on the network when the destination field of the packet becomes corrupt during transmission such that no node on the network receives the packet. A communication timer is used on both the hub and host to allow recovery from lost packets on the I2C and RS232 channels, respectively. The time to set the communication timer to can be determined from the length of the packet and by taking into account the processing time required by the destination node. For simplicity, both timers have been set to a worst case value for all packets by noting the longest possible packet is 25 bytes (destination/source byte, length byte, type byte, 20 content bytes, 2 checksum bytes). The hub timer is set to expire in 1.325 ms. The I2C bus operates at 400Kbps and requires 9 bits for every byte transmitted (after each byte an acknowledge bit is sent). A 25 byte packet will require 225 bits to be transmitted which requires 225 bits * 400Kbps = 562.5 µs. If we assume it

27

takes 1000 instructions to process the packet (a gross exaggeration) and are using a processor requiring 200ns per instruction (which is the case for a PIC16F876) then 200 µs must be allowed for processing. The communication timer is not stopped on the hub until a complete reply is received for reasons the will be discussed below. The reply could consist of 25 bytes so another 562.5 µs must be allowed. This results in a worst case time of 1.325 ms. The host timer is set to 4.54 ms. The RS232 channel operates at 115Kbps and sends 10 bits for every byte transmitted (an additional start and stop bit are sent with each byte). A 25 byte packet will require 250 bits to be transmitted which requires 250 bits * 115Kbps = 2.17 ms. Since the hub forwards bytes immediately it causes no appreciable delay. Sending a packet from the host to a peripheral is well modeled by simply assuming they are directly connected by a 115Kbps channel. The same assumptions about the time required to process a packet are used here to give a total time of 2.17ms + 200 µs + 2.17 ms = 4.54 ms.

4.3.3 Corrupt Length A corrupt length may indicate fewer or more content bytes than are actually contained in the packet. In the former case, the checksum will likely fail resulting in a detectable communication error. However, in the latter case a more serious error occurs. Since the receiving node is expecting more content bytes than have been sent it will end up waiting indefinitely for more bytes. This is unacceptable. Sections 5, 6, and 7 will discuss how this situation is handled for a peripheral, the hub, and the host, respectively.

4.3.3 Undetected Communication Errors

An undetected communication error occurs when a packet is corrupt, but still arrives at a node with a valid checksum. Along with the low probability of this occurring, the nature of how packets are sent on AUViking will minimize problems resulting from such an error. For example, if a set motor packet is corrupt such that it still has a valid CRC then the motors will indeed be set incorrectly, but a new set motor packet will be sent every 1/10th of a second thus minimizing the problem.

A few additional steps have been taken to further minimize the probability of a serious error occurring due to an undetected communication error. Some of these steps effectively turn an otherwise undetectable communication error into a detectable communication error as they determine that, although the package has a valid checksum, it is making a request that is incorrect. There steps include:

• nodes returning an error packet if they receive a packet type that is not recognized • placing bounds on the range certain peripheral properties can take and reporting an error

if a packet indicates the property should be set outside this range • allowing any node to be reset if it is deemed to not be working properly

4.3.4 Dallas 1-Wire Reset Network

The Dallas 1-Wire reset network allows the hub to reset any peripheral on the I2C network. Each peripheral contains a DS2406 D1W digital switch that can reset a peripheral when the hub toggles the switch. It is a requirement of the communication protocol that all peripherals on the I2C network provide this capability. Each DS2406 IC has a unique address that is burnt into it at the factory. This address is guaranteed to be unique and allows multiple DS2406’s to reside on a D1W bus. During design time this address is read from the device and related to the I2C address of the peripheral by the host. The host can inform

28

the hub to reset a given peripheral by sending it a reset packet with the appropriate D1W address (see section 6.3). This background network was integrated into the AUVic-CS to allow recovery from malfunctioning peripherals. A peripheral may be malfunctioning due to a programming error in the device itself or because of an undetected communication error. In either case, the physical nature of the I2C bus makes it possible for a malfunctioning device to block communication on the network. This would effectively leave AUViking “dead in the water”. Resetting a device will likely resolve this problem and a design requirement of AUViking ensures peripheral will continue to operate with only a momentary glitch in operation (see section 5.3).

29

5.0 Design of Peripheral Operation Each peripheral adds functionality to AUViking that can be accessed using the AUVic-CS. The functionality provided by each peripheral and the manner in which this functionality is implemented is unique to each peripheral. In order to hide this complexity, all peripherals provide a well-defined interface to allow access to the functionality it provides. This section explores the design specifications that every peripheral must adhere to. Failure to meet these specifications may result in the AUVic-CS failing to operate. The specifications here make no assumptions about the peripheral allowing peripherals to use a wide set of processors and electrical components. All peripherals reside on the I2C network and an understanding of the I2C protocol is required to understand the required operation of peripherals. Aspects of the I2C protocol essential to the AUVic-CS are explained here. A complete discussion of the I2C protocol can be found in [5].

5.1 I2C Protocol

The I2C network in AUViking is configured as a standard master/slave, linear bus. Communication is done over a single data line (SDA) and clock line (SCL). Data is transferred one byte at a time and the peripheral must acknowledge each byte before operation continues. The master controls the rate data by controlling the SCL line. The logic level of the SDA line must only be changed when the SCL line is low. Data is read from the network on a low to high transition of the SCL line. This allows two unique conditions to occur on the bus that are exploited by the I2C protocol. A start condition is generated by pulling the SDA line low when the SCL line is high and a stop condition is generated by allowing the SDA line to float high when the SCL line is high. The start condition signal informs all devices on the network that the master will be placing an address onto the network and the stop condition informs peripherals that the communication sequence is over and that their receive logic should be reset. The master starts a write sequence by first generating a start condition. In the next 7 clock pulses (SCL going from low to high) the master places the address onto the bus and on the 8th clock pulse the master pulls the SDA line low to indicate a write operation (see Figure 5.1). An additional 9th clock pulse is sent by the master to allow the peripheral to acknowledge (ACK) it has received the last byte by pulling the SDA line low. Failure to ACK indicates that the address was not recognized by any peripheral on the network. Data is now sent to the peripheral 8-bits at a time followed by an ACK from the peripheral. The peripheral can indicate that no more data should be placed on the bus by issuing a not acknowledge (NACK) on the 9th clock pulse after a byte is read. However, in the AUVic-CS a slave never issues a NACK and communication is always terminated by the master generating a stop condition to inform the slave that no more data will be placed on the network.

Figure 5.1 I2C Write with 7-bit Address [8]

30

Figure 5.2 illustrates an I2C read operation. Like a write operation, a start condition is generated followed by the address of the peripheral the master wishes to read data from. The 8th byte is set high to indicate a read operation. The peripheral now sends an ACK bit on the 9th clock pulse from the master by holding the SDA line low. By keeping the SDA line low the peripheral can take as much time as required to prepare the data to send to the master. Once the peripheral is ready to send a byte it lets the SDA line float high causing the master to generate clock pulses and read in the byte. On the 9th clock pulse the master sets the state of the SDA line and the peripheral latches the value. On an ACK, the slave can hold the SDA line low and prepare another byte to send. A NACK indicates that the master does not wish to read any more data from the peripheral. The communication sequence is terminated by generating the stop condition.

Figure 5.2 I2C Read with 7-bit Address [8] The AUVic-CS takes advantage of the nature of the I2C protocol to reduce the resource requirements of peripherals. By exploiting the I2C protocol the amount of RAM, program memory, and timers available on a peripheral can be reduced. It is a requirement of the AUVic-CS that peripherals use devices that can distinguish between an address byte and a data byte in hardware (by looking for a start condition). That is, there is a flag set in hardware to indicate if the currently received byte is an address (and thus the start of a communication sequence) or a data byte. It is expected that the majority of microcontrollers with I2C hardware will meet this requirement. Section 5.2 and 5.3 discusses in detail how this is exploited to simplify the communication logic and remove the need for a communication timeout timer.

5.2 Typical Operation Typical operation is for the hub to transmit a packet to a peripheral and then request a response to the packet. The hub requests a response to all packets to ensure the packet was received by the peripheral without error. The peripheral receives a packets, processes it, and sets up a reply packet for the hub. A race condition occurs between the peripheral preparing the reply packet and the hub requesting the reply. If the hub were to request a reply from a peripheral too soon it would read back an error packet. Peripherals are responsible for handling this situation by holding the SDA line low until it is ready to transmit a reply as discussed in section 5.1. This ensures the hub always reads back the intended reply from a peripheral regardless of the time it takes for a peripheral to process a packet. Figure 5.3 gives a flow chart illustrating suitable logic for a peripheral on the AUVic-CS. The “Receiving New Packet” and “Transmit Reply” functions are contain in the I2C interrupt service routine (ISR) that is called whenever a byte is received on the I2C network. Although it is possible to built a peripheral with a processor that does not provide interrupt support for the I2C network, it is not recommended. The “Program Start” function runs whenever the ISR is not running. I2C communication will be slow relative to any microcontroller so a peripheral spends the majority of it’s processing time “Perform(ing) Slave Processing” as desired.

31

Figure 5.3 Flow Chart for Peripheral on the AUVic-CS When a hub sends a packet to a peripheral the peripheral executes the “Receiving New Packet” logic. As discussed in section 5.1, the peripheral can determine that a new packet is to be read by checking a hardware flag and the last bit of the address byte. Once a packet is received successfully the “Packet Received” flag is set to inform the “Program Start” logic that the packet should be processed.

32

Transmitting a packet is handled by the “Transmit Reply” logic. The race condition discussed above is handled by using a “Master Reply” flag which informs the “Program Start” logic that the hub is pending a response and the “Packet Received” flag which informs the “Transmit Reply” logic that the last packet is still being processed and the reply packet is not ready yet.

5.3 Handling Communication Errors The reply packet from a peripheral is always a valid reply packet. The reply packet is set to indicate an unknown error until a packet is successfully received or a specific error is detected. This ensures the hub will receive a valid error packet as a response should a communication error occur. When a valid packet is received, the reply packet is set accordingly. Once the hub reads the reply packet or starts to send a new packet to the peripheral, the reply packet is reset to an unknown error packet. If the peripheral is able to determine the cause of a communication failure it sets the error code of the reply packet appropriately. This aids in debugging and can be used by the hub to determine how to respond to the error packet. Until a valid packet is received or an error can be detected by the peripheral, the reply packet indicates an unknown error. Figure 5.3 indicates the communication errors that can be detected by a peripheral. An “Unknown RX State” error occurs if the hub sends a peripheral more bytes than expected and an “Unknown TX State” error occurs if the hub requests more bytes than the total length of the reply packet. A “CRC Failed” error is reported on a checksum error and an “Unknown Packet Type” error indicates that the peripheral cannot recognize the packet type. Table 5.1 lists the errors that will be reported for different communication errors. In all cases it is assumed that the checksum is still valid. Otherwise, most errors simply result in the peripheral indicating that the checksum was invalid (the exception to this is corruption of the length byte).

Test Response To Hub Destination Corrupt – address not on I2C network ERROR_I2C_TIMEOUT

Destination Corrupt – addressed to incorrect peripheral

Depends on Peripheral (likely an invalid packet type)

Length Corrupt – indicates additional content bytes ERROR_SLAVE_UNKNOWN

Length Corrupt – indicates too few content bytes ERROR_SLAVE_I2C_CRC_FAILED

Type Corrupt – indicates an unknown packet type ERROR_SLAVE_PKT_TYPE_UNKNOWN

Type Corrupt – indicates a valid packet type Depends on Peripheral (in general, this is a serious error)

Any Content Byte Corrupt Depends on Peripheral and Packet Type (in general, this is a serious error)

Checksum Corrupt ERROR_SLAVE_I2C_CRC_FAILED

Table 5.1 Response by Slave to Various Communication Errors

The I2C protocol is exploited to remove the need for a communication timeout timer. To illustrate why a communication timeout timer is required with many protocols consider the following example. Assume the length byte of a packet becomes corrupt and indicates that the length of the packet is 255 bytes (the maximum length that could be specified). Th e peripheral will now stay in the “Read Packet Contents” state (see Figure 5.1) until 255 bytes are received. After trying to send the packet to the peripheral several times and receiving only error packets as replies (as the peripheral is still looking for more content bytes) the hub will conclude that the

33

peripheral is not operating correctly. The hub can now use the D1W network to reset the peripheral, but this is not a desirable way to resolve the problem as it disrupts the operation of the peripheral. As such, it is typical to use a communication timeout timer. In this scheme when the hub detects an error packet from a peripheral it waits a set period of time before attempting communication again. This delay from the hub allows the communication timeout timer on the peripheral to expire which will cause an interrupt. During the interrupt service routine the communication logic will be reset so the peripheral is ready to receive another packet from the hub. The use of a communication timeout timer is typical when using the RS232 protocol as it has no mechanism to indicate the start or end of a packet (the hub uses such a timer for RS232 communication with the host). The use of a communication timeout timer requires an available timer on every peripheral and a method for the hub to delay before sending a reply. This required delay by the hub also results in slower recovery from communication errors. A communication timeout timer is not required with the I2C protocol if a hardware flag is set whenever a start condition occurs. The peripheral can now use this flag to determine if it needs to reset the communication logic. For example, if the length byte should become corrupt as illustrated above, the peripheral will recover as it resets the communication logic when a new packet (which begins with a start condition being generated) is sent from the hub. When a communication timeout timer expires it is indicating that the logic should be reset to accept a new packet – this is precisely what explicit detection of a start condition does. This allows a peripheral to recover from any communication error as the communication logic is always reset at the start of receiving or transmitting a new packet. An important design requirement of peripherals is they must not contain state information. Removing all state information from a peripheral allows it to be reset with minimal affect on its operation. This is exploited by the host to allow recovery from otherwise fatal errors. The following two cases illustrate how state information can easily be removed from a peripheral and why this results in only minor disruption of the peripherals operation:

• Inertial Guidance System: The goal of the inertial guidance system (IGS) is to estimate the position of AUViking by using a 3-axis compass and an accelerometer. The current position of AUViking could be stored in the IGS, but this would result in the position state information being lost upon a reset. Instead, the IGS simply indicates the relative movement of AUViking since the last time it was polled and the host keeps track of the position of AUViking. A small lost in positional accuracy will occur after a reset, as the current relative position information in the IGS will be lost.

• Motor Controller: Resetting a motor controller will cause the attached motor to stop moving. The desired speed of the motor is determined by the host using data from all sensors on AUViking. This desired speed is sent to the motors at a frequency of 10Hz or greater so only a minor disruption in operation occurs.

Some peripherals may contain properties that are sent only once during initialization. For example, the motor controllers have properties specifying current and temperature limits that are set by the host only once during initialization of AUViking. It is the responsibility of the host to resend this initialization information after it resets a peripheral.

Resetting of a peripheral to recover from an error should only be used when no other recovery method is available. Alternative methods can often avoid the minor disruption of the peripherals operation that result from resetting. These disruptions are designed to be minimal, but are still undesirable and could hamper the operation of AUViking if they occur regularly.

34

6.0 Design of Hub Operation The hub is an integral component of the AUVic-CS. It is an intelligent protocol translator between the host and I2C network capable of detecting and recovering for communication errors, resetting peripherals using the D1W background network, responding to network services, and monitoring itself to determine if it is malfunctioning. All of these aspects will be examined here.

6.1 Typical Operation

In typical operation the host sends a packet to the hub that is addressed to a peripheral on the I2C network. Figure 6.1 provides a flow chart of the logic used to receive packets from the host. Packet reception is handled in an ISR. At the start of receiving a packet a communication timer is set to aid in recovering for communication errors (see section 6.2). Upon reception of the destination byte the hub determines if the packet is addressed to itself. If not, a flag is set that indicates that all bytes received should be forwarded to the I2C network. Upon reception of each byte the hub logic determines what part of the packet it is and processes the byte accordingly. When the checksum byte is received the hub sets the packet state to RECEIVED or ERROR depending on the validity of the checksum. As shown in Figure 6.1, on reception of the destination byte a check is also made to determine if the packet should be broadcasted. A broadcasted packet requires special attention as the hub and all peripherals must process the packet and no response is required from any of the peripherals. The hub will provide the host with a response in order to meet the protocol requirements discussed in section 4.2.1. Figure 6.2 is a flow chart of the main processing loop of the hub. When a packet is received the state will be set to either RECEIVED or ERROR. If it is set to ERROR the hub sends an error packet to the host as a reply and than resets the communication logic. The error type will report what type of error has occurred (see section 6.2). Otherwise, the hub checks the forward and broadcast flags to determine how to proceed. If the packet is for the hub (forward flag not set or broadcast flag set) than it is processed by the hub and an appropriate reply sent to the host. Otherwise, the hub must request a reply from the peripheral the packet was forwarded to. Figure 6.3 is a flow chart of the logic used to request a reply from a peripheral. A communication timer is set to allow recovery from errors and than the hub attempts to read the reply. Upon successfully reading a reply it is forwarded to the host.

35

Figure 6.1 Reception and Forwarding of Packets from Host

36

Figure 6.2 Main Processing Loop of Hub

37

Figure 6.3 Requesting Reply from a Peripheral

38

6.2 Handling Communication Errors The hub must handle communication errors on the serial link and on the I2C network. Error detection is not performed on the D1W link. If an error occurs on the D1W network the result is the desired peripheral will not be reset. The host is free to attempt resetting a peripheral multiple times. Communication errors on the serial link are handled by the 16-bit CRC checksum and the communication timer. Most communication errors result in one or more bits in the packet being corrupt. This results in a CRC check failure that will be reported to the host so it can re-transmit the packet if desired. However, as illustrated in section 5.3, a communication timer is required to handle the possibility of the length byte becoming corrupt or bytes being lost. The communication timer is set when the destination byte of a packet is received. If the communication timer expires it indicates a communication error as a complete packet should have been received in this time frame. Figure 6.4 illustrates the logic of the communication timer ISR. If the serial communication timer expires when attempting to receive a packet from the host then a reply packet is sent to the host indicating that the timer has expired. The hub now resets it’s packet receive logic in preparation to receive the next packet (possibly a resend of the last packet). An I2C stop condition is also generated to inform all peripherals that the hub has finished forwarding the current packet.

Figure 6.4 Communication Timer ISR Figure 6.3 illustrates the error recovery performed by the hub over the I2C network. A communication timer is used to ensure the hub does not wait indefinitely for a reply. If a packet is forwarded by the hub to a peripheral that does not exist on the I2C network (i.e. the destination byte is invalid or became corrupt) then the hub would wait indefinitely for a reply. When the

39

communication timer expires (see Figure 6.4) it sets a flag that causes all I2C read operation to return immediately. The hub will then send an error packet to the host indicating the I2C timer expired. If the timer has not expired, the hub checks to see if the checksum of the reply packet is valid and that the peripheral is not reporting an error. On an invalid checksum the hub requests the reply from the peripheral again. On an error packet the hub resends the last packet and requests the reply again. After a user defined number of attempts at obtaining a valid response the hub reports an error packet to the host. If a valid response is received it is forwarded to the host.

6.3 Communication with the Hub

Like peripherals on the I2C network the hub has an address that allows the host to send packets to it. The hub can accept diagnostic, shutdown, end mission, status, and reset packets. The effect of this network services on the hub are:

• Diagnostic: The host sends the hub a diagnostic packet to check if the hub is present and communicating properly. This allows the host to report an error if communication with the hub fails.

• Shutdown: Causes the hub to turn off all indicator LED’s. • End Mission: Causes the hub to turn off all indicator LED’s. • Status: The hub has no user programmable settings so simply returns a status reply

packet with no content bytes. • Reset: The host can reset any peripheral by sending a reset packet to the hub. In order

for the host to reset a specific peripheral is must know the D1W address of the digital switch connected to that peripheral. This is accomplished by a simple lookup table that relates I2C addresses to D1W addresses. Figure 6.5 gives the packet structure for a reset packet.

Destination (1 Byte)

Length (0x06) Type (0xA0)

D1W Address (6 Bytes) Checksum (2 Byte)

Figure 6.5 Reset Packet

6.4 Watchdog Timer A watchdog timer is used on the hub to make it more robust. When the hub is operating as desired, it will reset the watchdog timer often enough that it never expires. If the watchdog timer does expire (0.9-4.2 sec) it indicates a serious problem has occurred and the hub will reset itself. Resetting the hub should allow it to recover from any errors and allow communication between the host and I2C and D1W networks to continue. If the watchdog timer is found to be expiring, it indicates a serious error that should be properly debugged. The watchdog timer is provided to make the hub more robust, but should not be used as a method to recover from a known error.

40

7.0 Design of Host Operation The host is responsible for communicating with all sensors on AUViking, processing the data from these sensors, and determining how to best set actuators on AUViking in order complete the AUVs mission. The algorithms used to process sensor information and follow mission plans is critical to AUViking, but have no influence over the AUVic-CS so will not be discussed. This section will focus on how the host interacts with the communication system.

7.1 Round-robin Schedule A straight forward, round-robin schedule is used on AUViking in order to obtain sensor information and set actuators at a roughly periodic rate. A round-robin schedule operates by simply sending packets in the order they are listed in the schedule and wrapping around to the start of the schedule after the last packet in the schedule is sent. The round-robin schedule is simple to implement and the desired 10Hz packet frequency can easily be obtained. Its limitation is that it has no functionality to send some packets more frequently than others. An alternative scheduling system could be used that allowed more flexibility over how often a packet was sent. For example, a timer could be used to only send the battery voltage packet only once a second as this sensor information is not required at 10Hz or a priority scheme could be used that indicates the relative frequency packets should be sent. The round-robin schedule can simulate relative priorities by scheduling some packets more often than others. However, the high data rate of the AUVic-CS allows these more complicated scheduling systems to be avoided as there is no harm in receiving packets more often than required as long as all packets are sent at the desired frequency. The round-robin schedule that will be used on AUViking is shown in Figure 7.1. Note that it contains more packets than were used in section 3.2 to determine the required data rate for the system. These extra packets (marked with a * in Figure 7.1) are not required by the algorithms on AUViking, but have been added as they provide extra information about the state of AUViking that may provide useful information when testing AUViking and because the high data rate of the AUVic-CS makes it possible to send these packet while still meeting the required 10Hz packet frequency.

3 * Set Motor 3 * Get Motor Flags

3 * Get Motor Status* Get Pressure Data

Get Battery Voltages Get Temperature Flags

Get Sensor Status* Get Sonar Data

Get Sensor Status* Get Inertial Guidance Data

Get Compass Data Get IGS Status*

Figure 7.1 Round-robin Schedule

41

7.2 Typical Operation A simplified, high level overview of how the host operates is given in Figure 7.2. When AUViking first comes online it initializes the system (turns off LED’s, clears system variables, etc.) and makes sure the AUVic-CS is operating correctly by sending a diagnostic packet to the hub and all peripherals. If an error results from any of the diagnostic packets all systems are sent the diagnostic packet again until either no errors are reported or the AUVic-CS is deemed to be malfunctioning. Ideally, AUViking would attempt to determine what systems are online and try to complete the mission with only these systems. In practice, this is time consuming to implement and it is easier to simply have the host report an error so the problem can be resolved. From the point of view of the AUVic-CS the operation of the host is trivial. It simply sends all packets using the round-robin schedule followed by processing the received data. The result of processing the data is how to set the motor speed and directions to best complete the current goal of AUViking. This information is sent to the motors with the set motor packet that is at the top of the round-robin schedule. This process is repeated until the mission is completed or aborted. A mission may be aborted either by the host determining the maximum mission time has elapsed or an external switch being toggled. At this time all systems are sent an end mission packet and the AUV is brought to the surface by slowly turning off the motors.

7.3 Handling Communication Errors

Communication errors will occur and it is critical that the host be able to respond correctly to any communication error it might receive. There are two possible sources of errors that host must be able to detect: a lost packet on the RS232 link and an error packet as a reply. As shown in Figure 7.2, a communication timer is used to ensure a response is received in a reasonable amount of time (~5ms as shown in section 4.3.2) in order to detect lost packets and all responses are checked to determine if a communication error is being reported. A valid response to any communication error is to resend the packet. This is due to the fact that the most likely cause of a communication error is noise in the environment corrupting the packet. Because of this, the host will always resend a packet three times before assuming further action is required. After receiving three consecutive errors the host will report the error via an LED and to the dockside PC via TCP/IP (if the TCP/IP channel is available). This situation represents a serious error that indicates the environment is too electrically noisy or a logical error exists in one of the systems (for example, a peripheral has entered a logical state that is causing it to continually calculate the checksum incorrectly). The action taken by the host is determined by the last communication error it receives as it assumes all three communication errors were the same to simplify the error handling logic. This is a reasonable assumption as logical errors will most likely result in the same communication error whereas an electrically noisy environment will result in random errors. Since there is no action the host can take to improve the level of electrical noise in the environment the host simply assumes the error is a logical one and that all three errors were the same. Given that proper testing is done on each system before and after it is integrated into AUViking it is reasonable to assume that any logical errors that appear in a system (host, hub, or peripheral) will be due to a rarely occurring event (i.e. a specific communication error, a unique sequence of packets). Recovering from such an error is difficult as the system has likely entered a state it was

42

not intended to enter. Even if the logical error can be determined it is highly probable the host will not be able to resolve the problem by simply sending it a certain sequence of packets. The hub and all peripherals have been designed so they can be reset without seriously affecting their operation. This design requirement allows a peripheral to be reset at any time in order to attempt recovery from unforeseen errors. The host uses this to attempt recovery once three communication errors have been received. A check is made to determine if the error is being reported by the hub or a peripheral. If the hub is reporting the error the host will wait for 5 seconds in order to allow the watchdog timer on the hub to expire. This will reset the hub and hopefully resolve the error. For peripherals, the D1W reset network is used to reset the peripheral in hopes of resolving the error. In either case, the host assumes the error is resolved and simply continues on to the next packet in the round-robin schedule. There are several situations where this error recovery mechanism will fail. As an example, if the hub were in a state where it is clearing the watchdog timer, but failing to respond to packets then the AUVic-CS will cease to operate. No communication system is without the possibility of failure which is why many commercial systems contain redundant communication channels and backup systems. For financial reasons this is not feasible on AUViking and the nature of AUViking makes it reasonable to simply perform a system wide reset should the current recovery mechanisms fail.

43

Figure 7.2 Main Processing Loop of Host

44

8.0 Implementation of AUVic-CS Only implementation details effecting the maintenance and expansion or specification for the AUVic-CS are discussed in this section. A maintainable system is one requiring a minimum amount of work to modify existing functionality and an expandable system is one requiring a minimum of work to add new functionality. Maintainability is required to minimize the work required to make a new peripheral compatible with the AUVic-CS. An expandable system will allow future teams to extend the AUVic-CS to suit their needs with minimal difficulty. Details related to programming the host, the hub, and peripherals to interact with the AUVic-CS are not discussed as it is a straight forward implementation of the design developed in the previous section. More importantly, these low level implementation details have little direct effect on the maintainability or expandability of the AUVic-CS. It is important to efficiently implement the logic required by each system to keep the time required to process packets to a minimum. The implementation efficiency is most drastically affected by the choice to use either assembler or a high level programming language which is discussed in detail in this section. The selection of a programming language also influences the time required for implementation, learning required by current and future team members, and to some extent the cost of the system. Software for the AUVic-CS was developed in C. The benefits of the C programming language over other high level languages will be discussed in this section along with the rational for using a high level language over assembler. Since most peripherals will share a processor with the AUVic-CS it is essential that a language be chosen that will accommodate the majority of AUVic team members as they will be required to program in the same language. Maintainability and expandability are both strongly influenced by the structural organization of a software system. A system with a well developed structural organization will allow for high re-use of code as related functionality will be contained in separate modules. This promotes maintainability as modification of existing functionality requires a minimum amount of code to be modified and new peripherals in the system can easily access the available functionality. Expandability is achieved as the structural organization makes it clear where new functionality should be placed and peripherals are already setup to use this structural framework so require a minimum amount of modification. Implementation of the code required for the hub and peripherals is complete and tested. The results of testing are discussed in section 9.0 to show that the specifications for the AUVic-CS are met. The code required for the host has not yet been implemented. Due to the length of the source code it is not included in this report. It is available directly from the author (Donovan Parks, dparks@uvic.ca) upon request.

8.1 Selection of Programming Language

Programming for the AUVic-CS was implemented in C using a compiler from Hi-Tech Software. C is a commonly used high level language (HLL) for embedded systems and has many advantages over assembler and other HLL making it desirable for the AUVic-CS. The decision to use C will be explored in this section. A HLL (such as C) was chosen over assembler for the following reasons:

• Familiarity: Familiarity with a language reduces the development time of a project and the quality of the resulting code. Given the wide spread use of HLL languages it is far more likely future team members will be familiar with a given HLL language than Microchip PIC assembly. The current team has experience with C, C++, Java, Motorola HC11 assembly, and Microchip PIC assembly; with the most team members having experience with Java and C.

45

• Development Time: Using a HLL reduces the required development time as it provides a

higher and more natural level of abstraction from the underlying hardware. Many details that are the responsibility of the programmer when using assembly are handled automatically by a HLL language (for example, the location of variables in memory). A HLL reduces the amount of code that must be written and debugged as a single HLL instruction will usually replace several assembly language instructions.

• Portability: An assembler instruction set is different for every family of microcontrollers

whereas most HLL are defined by an industry standard. Porting assembly code to a new microcontroller requires all of the code to be re-written as the new instruction set will have different instructions available and use different syntax rules. A HLL defined by an industry standard makes porting much easier as the language remains identical regardless of the microcontroller family. Some work still remains as the method required to configure communication ports, timers, etc. may be different and the memory location of configuration bits will surely be different. However, large portions of the code can be re-used without any modifications and most of the other code will require only minor modifications.

• Code Size: Functionality implemented using assembler will require less program memory

than functionality implemented using a HLL. The amount of additional program memory required depends on both the HLL used and the specific compiler. This advantage is made less significant as modern microcontrollers contain several kilobytes of program memory.

The Microchip PIC16F876 has 8K of program memory. This is far more than required by the hub regardless of the language used. Peripherals must share the program memory between the AUVic-CS and the functionality it must implement. The AUVic-CS code for a peripheral requires under 0.5K when implemented using the Hi-Tech C compiler making any saving that will result from moving the code to assembler minimal.

• Processing Time: A peripheral must share the processor with the AUVic-CS so it is advantageous to reduce the processing time required to receive and process packets. For the AUVic-CS operating at ~400 Kbps the time required to receive and process a packet is significant. The time required to receive a byte at 400 Kbps is 20 us. A PIC16F876 microcontrollers can execute an instruction in 200ns making it possible to execute 100 instructions in 20 us. Every byte received invokes the ISR and requires some action to take place as discussed in section 5.2. The 100 instructions that can be executed are split between this action and the peripheral completing its own processing.

This means a peripheral could have significantly less available processing time when receiving a packet. Unfortunately, due to hardware addressing, a peripheral requires no processing time when the current packet on the AUVic-CS is for a different peripheral. Since there are 6 peripherals on the system, a peripheral will only be receiving a packet approximately 1/6 of the time. This gives peripherals 100% use of the process for the majority of the time they are operating. A high processing time is still desirable though as it will reduce the time to process a packet which will increase throughput. For this reason it is desirable to use assembly language as it reduces the number of instructions that must be executed.

It was deemed that the benefits of a HLL outweighed the benefits of using assembly. Specifically, the reduces development time gained by using a high level language is critical given the short time frame AUViking must be completed in. The major benefit to using assembly is the increased processing speed achieved. However, most HLL provide a mechanism to allow for assembly code to be interlaced with HLL language code so time critical functionality can be

46

implemented as efficiently as possible. This allows sections that must be made as efficient as possible to be written in assembler (although, these sections will lose the other benefits of a HLL such as portability). Five different HLL languages were considered for use: Java, C++, C, Just Another Language (JAL), and Basic. Selection of the C programming language results from the following points:

• Java and C++: Java and C++ compilers are not widely available for small microcontrollers as they are object oriented languages and object oriented code results in larger code size. This larger code size and correspondingly slower execution speed is unacceptable to many embedded systems. These compilers are not available for the Microchip family of microcontrollers.

• JAL: JAL is a custom language developed for use specifically with Microchip microcontrollers. It was initially consider because it is available free to the general public. However, since it is a custom language many of the benefits of a HLL are lost. No team members have familiarity with JAL and it does not lend itself to porting as JAL compilers are not available for different microcontrollers.

• Basic: Basic suffers from many of the same problems as JAL as it is not defined by an industry standard. This reduces the portability of code and probability that future team members will be familiar with the specific dialect of Basic being used. Current team members have no experience with Basic. Finally, Basic is not as widely used as some other HLL languages and is rarely used in commercial settings.

• C: The C language is widely used on embedded systems as C compilers produce efficient code both in terms of size and speed. Unlike JAL and Basic, an industry standard is defined by the American National Standards Institute (ANSI) for the C language. Current team members have familiarity with the language and its wide use in embedded system, operating systems, and desktop applications make it likely future team members will be familiar with the language.

Many companies make C compilers compatible with Microchip PIC microcontrollers. The Hi-Tech C compiler was chosen largely because of its reputation as the best ANSI C compiler available for Microchip PIC microcontrollers and because Hi-Tech Software was generous enough to donate a copy to the AUVic.

8.2 Structural Organization of AUVic-CS Software The structural organization of the AUVic-CS is defined by dividing functionality between files. This allows a node to only include the functionality it requires and promotes code reuse as functionality can reside in a single, well-defined location. The C programming language supports this by allowing files to be included in other files thereby exposing the functionality they implement. A strong structural organization results in maintainable and expandable code. Figure 8.1 shows the organization used in the AUVic-CS. It consists of 7 files that completely implement the functionality required by the hub, host, and peripherals to interact with the communication system. Additional files should be used to implement the functionality required by each peripheral and the host. The goal of the organization depicted in Figure 8.1 is to ensure that each piece of functionality or information required by the AUVic-CS is implemented or defined only once while keeping the code that must be included by each node to a minimum. Defining functionality only once results in more maintainable code as any modifications required to a piece of functionality need not be repeated multiple times. Expandability is also made easier as it is clear which files a new node must include. Reducing the amount on code that must be included by a node obviously reduced the amount of program memory occupied by the AUVic-CS, but more importantly makes it clear what functionality is required by a node.

47

Figure 8.1 Structural Organization of AUVic-CS Software For example, the AUVic-CS could use a structural organization consisting of a single file that would be included by all nodes. This file would include all functionality and information required by every node. However, this organization not only requires all nodes to include code they will not use, but also hides what functionality each node is required to implement. The organization in Figure 8.1 makes it clear that a peripheral, for example, does not require the functionality specified in the Hub, Hub Packet Definition, and Host Files, so can be ignored by an individual expanding the system to contain a new peripheral. The AUVic-CS Definition File defines information requires by all nodes. This includes the structure for packets, address of all nodes, packet type used to identify network services, and available error codes. By including all this information in a single file included by all nodes it ensures they are all using the same information. This aids in maintenance and expandability. For example, if a new error code needs to be added to the system only the AUVic-CS Definition File needs to be modified to give all nodes access to the new error code. The Network Service Implementation File provides implementation code for generating acknowledge, diagnostic and error packets. The implementation of end mission, shutdown and status packets is done in the Hub File and Peripheral Network Service File(s) as these packets are specific to each node. Note that the definition of all network services is done in the AUVic-CS Definition File as the host must know the packet types to use for network services to use them, but does not implement network services. The Peripheral, Hub, and Host Files contain functionality specific to each of these node types. This includes the logic developed previously in this report for each of these node types (transmitting and receiving packets, forwarding packet for the hub, round-robin scheduling for the host, etc.) and functionality to initialize required communication ports (I2C, serial, or both). The Peripheral File contains only functionality that can be used by all peripherals. Each peripheral adds unique functionality to AUViking and must define a unique interface (set of packets) for use with the AUVic-CS. The packets each peripheral can accept and the packet type to identify these packets is defined in a Peripheral Packet Definition Files that is unique to each peripheral. Similarly, the hub has a Hub Packet Definition File that identifies the packets it can accept. These files are included by the host as it required knowledge of the packet types defined by a peripheral in order to communicate with the peripheral.

48

This structural organization successfully allows all functionality and information to be contained in only a single file while requiring nodes to only include functionality and information they require. Each file implements a logic set of functionality and/or information making it clear how the system can be expanded and simplifying maintenance. The most likely expansion is the addition of peripherals which requires only a new Peripheral Network Service File and Peripheral Packet Definition File in order for the peripheral to be able to communicate on the AUVic-CS.

49

9.0 Testing of AUVic-CS Testing of the AUVic-CS was performed to ensure it is operating correctly and meets the specifications. The host has not yet been implemented so the following tests were performed by implementing a simplified version of the host logic on a PIC16F876. This simplified logic allowed for a round-robin schedule, but did not perform any error recovery. Instead, any errors were simply reported to a desktop PC. No procedure exists to ensure a system will continue to perform as desired under all situations except to individually test each situation. In practice, this is usually not possible as the number of situations is too great and/or no method is available to enumerate all possible situations. Verification that a system is operating correctly is usually done by conducting selected tests. The following tests have been conducted on the AUVic-CS to verify (but not guarantee) proper operation:

• Hub Communication Test: This test verifies the communication channel and corresponding logic required for packets to be transmitted between the host and hub is operating correctly. The test consisted of sending every packet defined by the hub to ensure the expected reply was received by the simplified host.

• Peripheral Communication Test: This test verifies the operation of the hub forwarding

logic and peripheral receive and transmit logic. Only the AUVic motor controller (AUVic-MC) peripheral is complete as of this writing. To extensively test this peripheral and the AUVic-CS, all packets defined by the AUVic-MC were sent to ensure the expected reply was received by the hub and forwarded to the simplified host. Each peripheral will undergo the same testing to ensure it is operating with the AUVic-CS as required.

• D1W Reset Network Test: A network of six DS2604 D1W switches was setup in order to

test the D1W reset network. The network was tested by sending a reset packet from the host to the hub for each switch.

Error Detection and Recovery Test: To test the error detection and recovery operation of peripherals and the hub different communication errors were simulated. These errors were simulated by deliberately transmitting a packet with one of the fields set incorrectly, but the checksum adjusted to indicate a valid packet. If the checksum were not adjusted the majority of these test cases would report a checksum failure error. Table 9.1 indicates the tests that were performed and the response received by the simplified host. A description of the error codes is available in Appendix I.

Two types of tests were performed: single error and permanent error. Single error tests indicate the first packet sent was invalid, but following packets were valid. This is done to test recovery from a communication error. Permanent error tests indicate a corrupt packet is sent continuously and are conducted to determine the final response received by the simplified host. Once the host is implemented, further testing will be required to ensure it is properly detecting and attempting recovery from communication errors.

50

Test Response To Host Corrupt Packet at Host – CRC Error ERROR_SCI_CRC_FAILED Corrupt Packet at Host – Length Byte too Short ERROR_SCI_CRC_FAILED Corrupt Packet at Host – Length Byte too Long ERROR_SCI_TIMEOUT Corrupt Packet at Host – Invalid Packet Type to Hub ERROR_PKT_TYPE_UNKNOWN Corrupt Packet at Host – Invalid Packet Type to Peripheral ERROR_SLAVE_PKT_TYPE_UNKNOWN Corrupt Packet at Hub – Single CRC Error Response Received Correctly Corrupt Packet at Hub – Permanent CRC Error ERROR_SLAVE_I2C_CRC_FAILED Corrupt Packet at Hub – Single Length Byte too Short Response Received Correctly Corrupt Packet at Hub – Permanent Length Byte too Short ERROR_SLAVE_UNKNOWN Corrupt Packet at Hub – Single Length Byte too Long Response Received Correctly Corrupt Packet at Hub – Permanent Length Byte too Long ERROR_SLAVE_UNKNOWN Corrupt Packet at Slave – Single CRC Error Response Received Correctly Corrupt Packet at Slave – Permanent CRC Error ERROR_I2C_CRC_FAILED Corrupt Packet at Slave – Single Length Byte too Short Response Received Correctly Corrupt Packet at Slave – Permanent Length Byte too Short ERROR_I2C_CRC_FAILED Corrupt Packet at Slave – Single Length Byte too Long

Response Received Correc tly or ERROR_I2C_TIMEOUT

Corrupt Packet at Slave – Permanent Length Byte too Long

ERROR_I2C_CRC_FAILED or ERROR_I2C_TIMEOUT

Packet to Invalid Address on I2C Network ERROR_I2C_CRC_FAILED Table 9.1 Testing of Communication Errors

Several of the specifications for the AUVic-CS are qualitative in nature and can not be directly tested. However, testing was complete to ensure the required throughput of 13.5 Kbps and minimum length of 300 cm can be obtained. Direct testing was done for each of these specifications. Minimum length for the I2C network was tested by setting up a network consisting of the simplified host, the hub, and three peripherals on a network 350 cm in length. Extensive testing was done to ensure proper operation could be achieved at this length. This testing consisted of sending packets to each of the nodes and ensuring the expected reply was received. No communication errors were detected as expected for an electrically quiet environment. A maximum operating length has not yet been determined. Testing the minimum length for the D1W network was done by setting up a network of 6 DS2604 switches on a network 350cm in length. Several reset packets were sent to each switch to ensure they were still operating correctly. No communication failures were detected. Like the I2C network, a maximum operating length has not yet been determined. Lack of available nodes has made testing the specified minimum number of nodes impossible. This specification will be tested when and if more nodes become available. The successful testing of the minimum length specification with three nodes is a promising result, but the AUVic-CS should be tested with 16 nodes on a network 300 cm long to verify it meets the specifications. Several tests were conducted to find the throughput of the AUVic-CS. The data rate of the serial and I2C channels are 115Kbps and 400Kbps, respectively. The time taken for a packet to be transmitted and the reply received was measured by a timer on the simplified host. Two measurements were made for each packet type to ensure the measurements were accurate. The packets per second and throughput were then calculated for the packet. Throughput was calculated by: Throughput = [(bits sent + bits in reply) / 2] / time Table 9.2 indicates the results for packets sent between the host and hub. Even when operating at only 115Kbps the specification throughput of 13.5Kbps is easily achieved. All packet types took approximately the same amount of time as little processing is required for any of the packet types.

51

Packet Type

Destination Trial # Time (ms)

Bits Per Packet

(sent/reply)

Packets Per Sec

Throughput (Kbps)

Diagnostic Hub 1 0.95056 40 / 40 1052 42.1 Diagnostic Hub 2 0.95046 40 / 40 1052 42.1

End Mission

Hub 1 0.95068 40 / 40 1052 42.1

End Mission

Hub 2 0.95156 40 / 40 1051 42.0

Shutdown Hub 1 0.95078 40 / 40 1052 42.1 Shutdown Hub 2 0.95046 40 / 40 1051 42.1

Status Hub 1 0.95016 40 / 40 1052 42.1 Status Hub 2 0.95056 40 / 40 1052 42.1

Average: 0.95066 NA 1052 42.1 Table 9.2 Throughput of Communication on Serial Channel

Table 9.3 provides results of sending the reset packet that uses the D1W reset network. The D1W protocol is implemented in software in the hub and operates at ~12Kbps. To reset a device requires a packet of 10 bytes to be sent over the D1W network twice - once to close the switch causing the peripheral to enter a reset state and once to open the switch to allow the peripheral to start operating again. In addition, a delay of 5ms between closing and opening the switch is used to ensure the peripheral has time to enter the reset state. The end result is the D1W reset network has a low throughput. Under normal operation a reset packet will never be sent so the slow throughput is not of concern.

Packet Type

Destination Trial # Time (ms)

Bits Per Packet

(sent/reply)

Packets Per Sec

Throughput (Kbps)

Reset Slave Hub 1 246.6 104 / 40 4 0.291 Reset Slave Hub 2 246.5 104 / 40 4 0.292

Table 9.3 Throughput of Communication on D1W Channel Table 9.4 indicates the results of sending packets between the host and AUVic-MC. Several different packets were tested to determine the influence of different packet sizes and processing times required for packets. An average throughput of 33.4Kbps was achieved – more than double the required throughput. The throughput of each packet type is as expected. For example, although a Set Current Limit and Get Flags packet consists of the same number of bytes the throughput of a Get Flags packet is lower as it requires more processing.

52

Packet Type

Destination Trial # Time (ms)

Bits Per Packet

(sent/reply)

Packets Per Sec

Throughput (Kbps)

Diagnostic Motor Controller 1 1.2214 40 / 40 819 32.7 Diagnostic Motor Controller 2 1.2140 40 / 40 824 32.9

End Mission Motor Controller 1 1.2203 40 / 40 819 32.7 End Mission Motor Controller 2 1.2214 40 / 40 819 32.7

Status Motor Controller 1 3.1221 40 / 144 320 29.5 Status Motor Controller 2 3.1421 40 / 144 318 29.3

Set Motor Motor Controller 1 1.2414 56 / 40 806 38.7 Set Motor Motor Controller 2 1.2497 56 / 40 800 38.4

Set Current Limit

Motor Controller 1 1.1532 48 / 40 867 38.2

Set Current Limit

Motor Controller 2 1.1530 48 / 40 867 38.2

Get Speed Motor Controller 1 1.5591 40 / 56 641 30.8 Get Speed Motor Controller 2 1.5706 40 / 56 637 30.6 Get Flags Motor Controller 1 1.4053 40 / 48 712 31.3 Get Flags Motor Controller 2 1.4006 40 / 48 714 31.4

Average: 1.5624 NA 711.64 33.4 Table 9.4 Throughput of Communication on I2C Channel

These tests of the AUVic-CS indicate it is operating as expected and has verified many of the specifications. It is clear the specified throughput has been met, but further tests are required to ensure the minimum number of nodes specified can be achieved and that the minimum specified length is still feasible with these additional nodes. As each peripheral is completed it will be fully tested with the AUVic-CS to ensure it is operating as expected and to further verify the operation of the communication system. Additional tests to determine the maximum number of nodes and maximum operating length for different number of nodes would be beneficial, but are not essential.

53

10.0 Conclusions The specification, design, implementation, and testing of an embedded communication system appropriate for use on a small, low cost AUV was discussed. Only a small amount of work remains before the AUVic-CS will be in a state suitable for AUViking. This work includes implementing the host software and determining cabling and connectors suitable for the backplane wiring harness. Implementation and testing completed to date has functionally verified the design of the AUVic-CS and shown it meets all specifications that could be tested. This includes measuring the throughput at 33.4Kbps, testing both the D1W and I2C networks at 350 cm (although, only with 6 and 3 nodes on the networks, respectively), and fully testing the systems ability to detect and recover from errors including resetting devices vi a the D1W reset network. Further tests are required to ensure all specifications are met, but initial tests result and the expected capabilities of the communication system would indicate all specifications will be met or exceeded. It is hoped the AUVic-CS will find continued application in AUVs developed by the AUVic. Lengths have been taken to make the expansion of the AUVic-CS possible by allowing the throughput, number of nodes, and network length to all be increased and by providing a sound structural organization to the AUVic-CS software to make the addition of nodes and network features easier. Multi-master operation is available on the I2C network allowing some architectural freedom in future AUVs. Provided the AUVic continues to use a distributed architecture, the AUVic-CS in its entirety or in part should prove useful for many generations of AUVs. 11.0 Recommendations Work remains in order to bring the AUVic-CS to a state where it will be sufficient for AUViking. Implementation of the host software and extensive testing to verify proper operation of the entire AUVic-CS must be completed. In addition, the cabling and connectors that will be used on each node to connect to the AUVic-CS backplane must be selected before the printed circuit board for the hub and peripherals can be finalized. This is the minimum amount of work required before the 6th International AUV Competition. It is desirable for several other tasks to be completed before this years’ competition in order to bring the AUVic-CS to a more robust and finalized state:

• Serial Data Rate: Increasing the data rate of the serial channel will greatly improve the throughput. This additional throughput will allow additional packets to be sent that can aid in debugging the system and allow packets to be sent at a rate greater than 10Hz in order to improve the response time of AUViking.

• Verification of Specifications: Verification that the AUVic-CS can operate at the minimum specified length with the minimum number of nodes would complete testing of the specifications. This would allow next years team to use the AUVic-CS with the knowledge of what minimum values it can operate at.

• Maximum Specifications: Testing to determine the maximum length the serial, D1W, and I2C channels can operate at for different numbers of nodes would provide valuable information to next years team if expansion of the AUVic-CS is required.

If required, additional work can be done to increase the throughput and maximum length of the network. The throughput can be increased by moving the I2C and serial channels to their maximum data rates of 1Mbps. However, at this data rate critical sections of the AUVic-CS software will need to be re-written in assembler to ensure bytes can be processed before the next byte is received. This represents a substantial amount of work and is recommended only if the high throughput is required. The maximum length of the I2C network can be increased by moving

54

to an active current source instead of a simple pull-up resistor on the SDA and SCL lines. However, this will require a new hub board to be built.

55

Cited References [1] AUVSI, “Final Rules for the 5th Annual International Autonomous Underwater Vehicle

Competition,” [Online Document], (2002 April), [cited 2002 December 12], Available at: http://www.auvsi.org/competitions/2002/2002FinalRules.pdf [2] Stallings, William, Operating Systems: Internals and Design Principles, Third Edition,

New Jersey: Prentice Hall, 1998. [3] B. Palmintier, C. Kitts, P. Stang, and M. Swartwout, “A Distributed Computing

Architecture for Small Satellite and Multi-Spacecraft Missions,” 16th Annual AIAA/USU Conference on Small Satellites, [Online Article], (date unknown), [cited 2002 November 19], Available at: http://www.aria.seas.wustl.edu/SSC02/papers/iv-6.pdf

[4] ESAcademy, “The I2C Bus Q&A Section,” [Online Document], (date unknown), [cited

2002 December 6], Available at: http://www.esacademy.com/faq/i2c/q_and_a/i2cqena.htm

[5] Phillips Semiconductor, “The I2C Bus Specification v2.0,” [Online Document], (1998

December), [cited 2002 December 7], Available at: http://www.semiconductors.philips.com/acrobat/various/I2C_BUS_SPECIFICATION_2.pdf [6] Williams, Ross, “A Painless Guide To CRC Error Detection Algorithms,” [Online

Document], (1992 August), [cited 2002 December 5], Available at: http://www.piclist.com/techref/method/math/crcguide.html

[7] Wicker, Stephen B., Error Control Systems for Digital Communication and Storage, New

Jersey: Prentice Hall, 1995. [8] Bowling, Stephen (Microchip), “Using the PICmicro SSP for Slave I2C Communication,”

[Online Application Note], (2000 March), [cited 2002 December 8], Available at: http://www.microchip.com/download/appnote/pic16/00734a.pdf

General References Clark, D. David, “Modularity and Efficiency in Protocol Implementation,” MIT Laboratory for Computer Science, 1982 July. Gatliff, Bill, “Inside Look: Emerald,” Embedded.com, [Online Magazine], ( 2001 November), [cited 2002 November 10], Available at: http://www.embedded.com/story/OEG20011129S0057 Maxim, “Dual Addressable Switch Plus 1-kbit Memory Datasheet,” [Online Datasheet], (date unknown), [cited 2002 December 6], Available at: http://pdfserv.maxim-ic.com/arpdf/DS2406.pdf Microchip, “Guidelines for Reliable 1-Wire Networks,” [Online Application Note], (date unknown), [cited 2002 December 17], Available at: http://pdfserv.maxim-ic.com/arpdf/AppNotes/app148.pdf Microchip, “PIC16F87x Data Sheet,” [Online Datasheet], (date unknown), [cited 2002 December 3], Available at: http://www.microchip.com/download/lit/pline/picmicro/families/16f87x/30292c.pdf Stanek, Jan, “Introduction to RS422 and RS485,” [Online Document], (1998), [cited 2002 December 17], Available at: http://www.hw.cz/english/docs/rs485/rs485.html

56

Appendix I – Error Codes Error Code

Error Name

Purpose

0xE0 ERROR_SCI_CRC_FAILED Indicates hub has detected a CRC error with the last packet received from the host.

0xE1 ERROR_I2C_CRC_FAILED Indicates the hub has detected a CRC error with the last packet received from a peripheral.

0xE2 ERROR_PKT_TYPE_UNKNOWN Indicates the hub has received a packet from the host w ith a packet type it does not know how to process.

0xE3 ERROR_I2C_RX_STATE_UNKNOWN Indicates the hub has entered an invalid state when trying to receive a packet from a peripheral.

0xE4 ERROR_I2C_TX_STATE_UNKNOWN Indicates the hub has entered an invalid state when trying to send a packet to a peripheral.

0xE5 ERROR_SCI_STATE_UNKNOWN Indicates the hub has entered an invalid state when trying to receive or send a packet using the serial port.

0xE6 ERROR_SCI_TIMEOUT Indicates the hub has timed out while waiting to receive a packet from the host.

0xE7 ERROR_I2C_TIMEOUT Indicates the hub has timed out while waiting to receive a packet from a peripheral.

0xE8 ERROR_I2C_MAXIMUM_RETRIES Indicates the hub has tried to resend a packet to a peripheral a user def ined number of times and was unable to deliver it successfully.

0xE9 ERROR_TIMER Indicates the hub communication timer has expired, but the reason is unknown.

0xEF ERROR_UNKNOWN Indicates the hub has encountered a problem receiving the last packet from the host, but the nature of the problem in unknown.

0xF0 ERROR_SLAVE_SCI_CRC_FAILED Indicates a peripheral has detected a CRC error with the last packet received from the serial port (some peripherals can communicate using I2C or the serial port for debugging purposes).

0xF1 ERROR_SLAVE_I2C_CRC_FAILED Indicates a peripheral has detected a CRC error with the last packet received from the hub.

0xF2 ERROR_SLAVE_PKT_TYPE_UNKNOWN Indicates a peripheral has received a packet from the hub with a packet type it does not know how to process.

0xF3 ERROR_SLAVE_I2C_RX_STATE_UNKNOWN Indicates a peripheral has entered an invalid state when trying to receive a packet from the hub.

0xF4 ERROR_SLAVE_I2C_TX_STATE_UNKNOWN Indicates a peripheral has entered an invalid state when trying to send a packet to the hub.

0xF5 ERROR_SLAVE_SCI_STATE_UNKNOWN Indicates a peripheral has entered an invalid state when trying to receive or send a packet using the serial port.

0xFF ERROR_SLAVE_UNKNOWN Indicates the slave has encountered a problem receiving the last packet from the hub, but the nature of the problem in unknown.