Audio Signals Over The Controller Area Network (CAN)

Brendan Donnellyφ and John Cosgrove*

φDepartment of Electrical/Electronic Eng.

Limerick Institute of Technology Moylish, Limerick, Ireland

E-mail: φbrendan.donnelly@lit.ie

* Department of Electrical/Electronic Eng. Limerick Institute of Technology

Moylish, Limerick, Ireland E-mail:* john.cosgrove@lit.ie

___________________________________________________________________________________

Abstract – CAN is a serial communications

protocol for transmitting short control messages in real time embedded systems and can operate at speeds of up to 1Mbit/s. CAN systems are designed to be used in automotive and automation environments where it is likely to have a high number of electromagnetic interferences disturbing the transmitted data. There are numerous applications of CAN carrying real-time data. However CAN has still not become popular for carrying voice streams. In addition to control information, a voice channel running on the same bus may have several advantages. This paper presents and illustrates the effects of introducing a voice channel on the system bandwidth and on other messages.

___________________________________________________________________________________

I INTRODUCTION

The Controller Area Network (CAN) has become the widely accepted de facto standard for automotive networks [1]. In the area of industrial automation and the automotive industry, field busses are used to disseminate time critical messages. CAN was developed in the mid 1980s by Robert Bosch Gmbh, aiming at automotive applications, to provide a cost-effective communications bus for in-car electronics and as alternative to expensive and cumbersome wiring [2]. With an operating time of eight hours per day on 365 days per year and an error rate of 0.7s, one undetected error occurs every thousand years [1].

CAN has gained wider acceptance as a standard in a large number of industrial applications. The priority based message scheduling used in CAN has a number of advantages, some of the most important being the efficient bandwidth utilization, flexibility, simple implementation and small overhead [3].

II Controller Area Network

CAN is a broadcast bus designed to

operate at speeds up to 1Mbit/s. It is a bi-directional bus with multimaster capabilities

[4]. Messages are transmitted consisting of between 1 and 8 bytes of data. Each message has an 11-bit or a 29-bit identifier assigned to it, according to the ‘standard’ or ‘extended’ message format. The smaller the identifier, the higher the priority the message is. The identifier is used as a filter for receiving messages and also to assign the priority of the message. As a common resource, the CAN bus has to be shared by all computing nodes. CAN uses deterministic collision detection to control access to the bus. CAN solves bus contention by taking advantage of certain electrical characteristics. In CAN terminology a ‘0’ bit is called a dominant bit, while a ‘1’ is termed a recessive bit. If multiple stations are transmitting simultaneously and one station transmits a dominant value on the bus, then all monitoring nodes will see a dominant bit. However, only if all stations are transmitting a recessive value will all stations read a recessive bit from the bus [5]. The stations transmit their identifier one bit at a time onto the bus. The transmitting stations also monitor the bus level. If a station transmits a receive value but reads back a dominant value from the bus, then another station with a higher priority message is also trying to access the bus. The station immediately stops transmitting. Because identifiers are unique within a system, the station that is transmitting the last bit of its

Control 2004, University of Bath, UK, September 2004 ID-228

identifier is obviously the message with the highest priority and thus is allowed to transmit the rest of its message [6].

III Voice Over CAN

Transmitting voice over CAN will be useful in situations where a CAN bus already exists and instead of having a different media for voice, the existing CAN bus could be used thus lowering the cost of the application [7]. The main aim of this work will be to implement a fully functional voice channel over the CAN while maintaining the real-time performance of the system. The CAN protocol contains several important features which make it highly suitable for voice communication [8]. These features are:

- Data rates up to 1Mbit/s at a bus length of 40 meters can be achieved. Lowering the data rate results in a longer bus length.

- CAN has a sophisticated error detection protocol, where the probability of an undetected error on the bus is very small. Transmission times in CAN are also guaranteed.

- The performance of the bus is independent of the number of nodes connected to it.

- CAN is a multi-master bus where the nodes don’t have a specific address.

In order to achieve voice communication over CAN, some issues must be solved before the voice channel can be implemented. These issues include:

- Which message format to use - Standard or Extended?

- Is the bandwidth available to the CAN network sufficient for voice transmission?

- The real time performance of the system should not be hindered by the introduction of the voice channel.

- The delay between when the actual audio sample is taken and when it is received is also crucial.

IV Performance Analysis

Each voice message carries 8 audio

samples, its transmission period is 1ms, and the sampling frequency of the audio signal is equal to 8KHz. In order to determine the busload we need to determine the time taken to transmit a voice message. The total number of bits in a standard data frame, with 64 bits of data is 111 bits. However, because of the bit-stuffing rule deployed by CAN, this figure can

be increased to 135 bits, which is the worst-case scenario. By using this figure we are able to determine the worst-case busload for our voice message over all network speeds.

In the case of voice messages being delayed by higher priority messages, the voice messages ready to be transmitted are accumulated in the transmission buffer, which eventually overruns. However the buffer at the receiving side that contains data will be progressively emptied. Both these situations can lead to the loss of some voice samples, especially when the higher priority messages are queued in long bursts.

Therefore, if we fix the size of the buffers, there is a maximum duration of bus busy time beyond which some audio samples will be lost. These lost samples will cause a degradation of the audio signal being transmitted.

Because many CAN networks are inherently small, many identifiers are redundant. This employs that that standard CAN with 11 bit identifiers will be sufficient for transmitting sound files over the network Table 1 below compares the network speed in relation to the busloads. This table allows us to evaluate if the addition of a voice network between CAN nodes is theoretically possible. Consider a CAN Network operating at a speed of 250Kbit/s. A voice channel could be established using 54% of the network. This is also worst-case analysis. Also note that a voice channel could not be established for a speed of 125Kbit/s as the bus load is greater than 100%.

Tbit Bus Load (%) 1Mbit/s 13.5

500Kbit/s 27 250Kbit/s 54 125Kbit/s 108

Table 1 – Busload Versus Network Speed For a data transfer rate of 250Kbit/s, a single message frame containing 8 bytes of data takes 540�s to transmit. For example, consider a voice payload of 20ms that has to be transmitted over a CAN network. If we assume a sampling rate of only 8KHz, this would allow us to send 8 samples per frame. So for a voice payload of 20ms we would require 20 frames to transmit the voice data in total. Each message frame is assumed to contain the worst-case amount of bits i.e. 135 bits. This means that for the worst-case number of bits for the voice data is

(135 * 20) = 2700 bits. The transfer rate per second is then calculated at 135Kbit/s using the formula

Control 2004, University of Bath, UK, September 2004 ID-228

(Number of Bits per ms) * (1000) This transfer rate is sufficient for voice transmission for a CAN network operating at 250Kbit/s.

V Architecture And Set Up To transmit audio signals over the CAN network, CAN evaluation boards from Infineon Technologies were used. The 32-bit Tricore boards have TwinCAN (two CAN nodes on each board) and also an on-board Analogue to Digital Converter (ADC). The test bed consisted of three Tricore boards, one of which was connected to a sine-wave generator. The three boards were connected together using the CAN. In fact a three station CAN network, shown in Fig. 1 has been set up, in which two stations Va and Vb are responsible for the audio communication, while the third has the function to periodically inject messages onto the bus.

Sound In Sound Out

Fig 1 Set-up of the experiment

VI Experiments The following experiments are to be carried out to see if a voice channel is feasible in a CAN network. These experiments are designed not only to prove the effectiveness of our approach, but also to determine the characterisation of the CAN network under several operating conditions. These conditions include:

1) Burst of Traffic. Periodically, the traffic generator station loads the network with a burst of messages. Each of these messages has a higher priority than the sound message so they are guaranteed to win arbitration to the bus. This scenario creates a time interval in which the bus is unavailable for the sound messages [7]. A diagram of this situation is shown in Fig. 2. The number of

messages and the repetition period are varied so that several bus conditions can be reproduced and analysed.

Burst Repetition Period

Burst Length

Fig 2 Burst Repetition Period

2) The second experiment details a typical message set that is to be sent over the CAN network and is shown below in Table 2. For this experiment 6 messages are sent over the network. The first five messages are all sent from the traffic generator station. The last message contains the sound data and is sent with a lower ID than the other message son the network so as not to disrupt the other data. This method is a good approximation for many automotive systems where the periods of messages may vary significantly and where sporadic messages may occur. The message set was sent over the network using bus speeds of 125Kbit/s, 250Kbit/s, 500Kbit/s and 1Mbit/s. Message Priority

Period Deadline Jitter

1 0.004 0.004 0 2 0.004 0.004 0 3 0.008 0.008 0 4 0.020 0.020 0 5 0.100 0.100 0

100 0.001 0.001 0 Table 2 Message Set

3) The maximum distance that

can be achieved using such a link.

In order to evaluate the performance of the voice channel, the station Va has been fed with a sinusoidal waveform. The signal is then reproduced on the receiving side to show the correct regeneration of the input signal. A sinusoidal signal is a pessimistic signal to transmit, as every sample that is delayed or not transmitted, causes a severe degradation to the signal that is reproduced on the receiving node. [7].

VII Results

The audio sample operated at a frequency of 200Hz. The chosen frequency can easily be generated and heard by humans. The analogue signal was converted to digital using

Va

Traffic Generator

Vb

Control 2004, University of Bath, UK, September 2004 ID-228

the on board 8-bit ADC. The digitalised signal ranged from 0 to 255. The ADC sampled the audio signal every 125�s. This ensured that 8 samples were produced every 1ms which was the same as the transmission period of the audio signal.

Fig. 3 below shows the results when the audio signal is transmitted over an unloaded bus. As expected, a perfectly formed sine wave was reproduced on the receiving side. This confirms the theory detailed in section 4, that an audio signal can be transmitted over the CAN network.

Fig 3 Transmitted Sine wave with traffic on CAN bus

Fig. 4 shows the results when the bus

is filled with messages produced by the Traffic Generator and the Sound Node Va.

Fig 4 Transmitted Sine wave with traffic on

CAN bus

For this example, the burst repetition period was chosen at 20ms and the burst length was set to 10.2ms. This means that the bus was available to the Sound Node Va for 9.8ms. Even with these requirements the audio signal was reproduced perfectly at the receiving Sound Node Vb. However, if the burst length for the Traffic Generator was increased beyond 10.2ms, the received audio signal deteriorated. This is illustrated in Fig. 5. In this example, the burst length was set to 11.3ms, while the repetition period remained at 20ms.

Fig. 5 Audio Signal when Burst Length > 10.3ms

VIII Discussion Of Results

Fig 6 shows all the tests that were carried out in the first experiment. The burst repetition period was varied between 5ms and 40ms. For each of these values a threshold value for the burst length was determined. This shows the maximum length of time that the bus can be occupied if the sine wave is to be reproduced perfectly on the receiving side. Once these threshold values are exceeded, the quality of the audio signal becomes very poor. This situation is depicted in Fig. 5.

0

5

10

15

20

0 10 20 30 40

Bur

st L

engh

Burst Repetition Period

Fig 6 Burst Repetition Period Vs Burst Length

As an example, consider when the burst repetition period is set at 40ms. The maximum length of time that can be taken up by other higher priority messages is less than 50% of the overall burst repetition period i.e. 18.3ms. Using a bus speed of 250Kbit/s, according to Table 1, the voice channel can be established at full audio quality if up to 46% of the overall bandwidth is used by the Traffic Generator, provided the requirement of bus unavailability time does not exceed the values in Fig. 6. The overall bandwidth required does not exceed 65%. However, if any more higher priority messages were sent on the network, then the time values detained in Fig. 6 would be violated, and the audio signal would deteriorate. So to transmit the audio signal in this type of experiment over 35% of the bandwidth cannot be used and is wasted.

Control 2004, University of Bath, UK, September 2004 ID-228

The scheduling method chosen was deadline monotonic. The Traffic Generator produced the first five messages of this message set. Sound Node Vb received all the messages sent in this experiment.

Message Number

250K (�s)

500K (�s)

1Mbit (�s)

1 518 259 129 2 517 259 130 3 512 257 129 4 512 257 129 5 508 255 128

255(Sound) 1015 1018 1016 Table 3 Worst Case Response Time of

Messages Table 3 shows the longest time taken to transmit the messages over the real network. This table shows that even with the addition of the audio messages in the network, the response time of the other higher priority messages was unaffected. Table 4 compares the condition of the audio file in relation to the bus speed. For each of the three bus speeds chosen for this experiment, the reproduced audio signal was excellent. The generated graphs were similar to Fig. 4.

Bus Speed

Condition of Graph

250Kbit/s Excellent 500Kbit/s Excellent 1Mbit/s Excellent

Table 4 Condition of Graphs The third experiment varied the bus

speed and the distance between the Sound Nodes in order to determine if the maximum distance for these speeds as defined by the CiA, could be achieved with an audio signal.

Bus

Speed Distance

(m) 1Mbit 40

500Kbit 100 250Kbit 250

Table 5 Distance Achieved Table 5 shows the distances achieved with respect to the bus speeds. For each of the distances, the audio signal was reproduced perfectly.

IX Conclusion The performance of the voice channel under several bus conditions has been measured. These results demonstrate that audio communication is possible, even when the

network is loaded with higher priority messages.

References [1] Punnekkat,S. et al. (2000) Response Time

Analysis Under errors for CAN. In: Sixth IEEE Real Time Technology And Applications Symposium (RTAS 2000) May 31 - June 02, 2000 Washington, D.C.

[2] Pedreiras, P. & Almeida, L. (2001) A Pratical Approach to EDF Scheduling on Controller Area Network. In: IEEE Proceedings of the 2001 RTSS Workshop, London.

[3] Dobrin, R. & Fohler, G. (2001) Implementing Off-Line Message Scheduling on Controller Area Network (CAN). In: 8th IEEE Int. Conf. on Emerging Technologies & Factory Automation, Nice, France, October 2001.

[4]“Road Vehicles – Interchange of Digital Information – Controller Area Network (CAN) for High Speed Communication”, ISO DIS 11898 (February 1992)

[5] Tindell, K. et al. (1994) Calculating Controller Area Network (CAN) Message Response Times In: Proceedings of IFAC DCCS 9̀4, Toledo, Spain (1994). Pg. 35-40

[6] Hansson, H et al. (2000) Integrating Reliability and Timing Analysis of CAN-Based Systems. In: IEEE Workshop on Factory Communications Systems, September 2000, Portugal.

[7] Baronti, F. et al. (2003) Efficient implementation of voice channels over CANnetworks. In: Proceedings of 9th International CAN Conference, 14-16 October, Munich. Pg 10-8

[8] Mahajan, M. et al. (2003) Voice over CAN. In: Proceedings of 9th International CAN Conference, 14-16 October, Munich. Pg 10-1.

Control 2004, University of Bath, UK, September 2004 ID-228