Jeremiah J. Flerchinger
31 – JULY – 2006
AN IN-DEPTH LOOK AT THE
TOYOTA AUDIO & VIDEO BUS
(AVC-LAN)
INTRODUCING THE TOYOTA AUDIO BUS (AVC-LAN):
In more historically conventional audio systems, parallel communication is used to exchange
information between components. Control and data signals are transmitted through separate wires for
each signal. In recent years (1998 and later) Toyota has implemented systems of serial communication
to reduce the numbers of wires between audio and other components while maintaining or increasing
functionality.
The importance of this document is that Toyota has little to no information published on their audio bus
system. Information on how audio and video components operate in Toyota automobiles must be
developed by reading and drawing conclusions from circuit diagrams, oscilloscope measurements,
repair manuals, sifting through countless forum postings across the internet, and asking questions of
knowledgeable individuals. This document is a compilation of discoveries relevant to this technology.
Toyota uses a bus system called AVC-LAN to allow more (and greater featured) audio and video
components to be integrated into a vehicle by significantly reducing the number of interconnecting
wires required. Here we will look at the topology, physical interconnects, communication drive type,
and protocol of the AVC-LAN and relevant Toyota system buses. The hope is a detailed understanding
of how audio components interact in Toyota automobiles.
BASIC TOYOTA COMMUNICATION BUSES:
Modern Toyota automobiles typically have 3 major bus systems: the CAN bus, the BEAN bus, and the
AVC-LAN bus. Each of the system buses must inter-operate with the other system buses, so we need a
basic understanding of them. All of the bus systems consist of some “backbone” of a bus network and
many individual nodes or Electronic Control Units (ECU) such as amplifiers, recievers, CD-changers,
automatic locks, or any other component. After a basic introduction to each of these bus technologies
we can delve into the detailed specifics of the AVC-LAN.
The CAN bus is an ISO standard bus for vehicles. It manages the Chassis Electrical System Control
and is responsible for critical activities like engine electrical, and skid control. This system is also used
to provide vehicle diagnostic information for maintenance. A multi-star configuration seems typical of
this bus with a primary bus line that branches into sub bus lines at its extremities then attaches to
multiple device nodes. Differential voltage is applied over twisted pair at 1.5 to 2.5V and 2.5 to 3.5V
for noise resistant signaling. Communication occurs at 500 kbps with 1-8 Bytes of data inside of each
transmitted packet.
BEAN is a Toyota specific standard that operates in a daisy chain loop. It networks the body electric
system and manages items like air conditioning and meter displays. This system is not as time critical
as the CAN network and operates over a single voltage driven wire at 10kbps with 1-11 Bytes of data
per transmission command.
The AVC-LAN is part of the Body Electrical System Control and manages all audio and video related
functions; therefore, it is of primary interest in this discussion. The audio bus is described in Toyota's
own words as follows:
AVC-LAN consist of audio visual systems such as the multi-display, navigation ECU, radio and
player, stereo component amplifier and gateway ECU. Gateway ECU has communication
circuit to correspond with different types of communication data. Different types of
communication data can be shared among communication parts after it goes through gateway
ECU (System Circuits: AVC-LAN Bus, “Prius Wiring Diagram” 80).
The system itself can be considered a subset of the IEBus Standard, which was delevoped by NEC
electronics for automotive use. It is slightly faster than the BEAN bus and has more data per
command, but is still much slower than CAN, since realtime speeds are not required.
AVC-LAN TOPOLOGY & TRANSMISSION:
Topology in the recent Toyota Corolla, Prius, Sienna, and Lexus models have been shown to have a
star topology. All audio and video components are connected to a central head unit that manages all
control signals. This tends to be either an AVC-LAN compatible receiver and/or a multi-display. As
previously stated the AVC-LAN is a derivation of the IEBus. The AVC-LAN operates at 17.8 kbps
with 0-32 Bytes of data in each command, making it compatible with IEBus mode 2.
Data on the AVC-LAN (IEBus mode 2) travels over shielded twisted pair wire. The bus voltage levels
range from -0.5V to 6.0V. Voltage differential is used to represent a logic 1 or zero. A voltage
difference of 20mV or less represents a logic 1, and a voltage difference of 120mV or more represents
a logic 0. Bus ends are terminated with 120 ohm resistors and individual devices (ECU's) on the bus
are protected by 180 ohm series protection resistors.
For the IEBus synchronization is established for each bit. Transmission of each bit consists of a
preparation period, a synchronization period and a data period. Synchronization and data periods are
almost equal in duration. Preparation consists of a period at logic 1. Following that is a logic 0 period
for synchronization. Finally is a period that is either low or high to indicate the bit value. Figure 1
shows the series of logical states that make up each transmitted bit (twice). This can be compared to
figure 2 to see what each bit looks like when actually transmitted over the AVC-LAN.
figure 1: Logical Transmission of AVC-LAN bit
figure 2: AVC-LAN Signal (Header, Master, & Slave field of MFD calling JBL for beep)
Looking at scope captures of figure 2 (where each division is 100 microseconds) the preparation period
takes about 7 micro-seconds, synchronization takes about 20, and the bit data takes about 13
microseconds. The start of a transmission is indicated by an extended high level state for the start bit.
When transmissions are completed the voltage difference drops and maintains a low level.
A specific connector doesn't seem to be required, since Toyota uses multiple connector types on its
audio bus. A six pin Molex connector is common for the IEBus. This connector contains pins for 12V,
Ignition, Ground, TX+, and TX- which correspond to pins 1-5 (respectively) in figure 2. Audio
equipment for Toyota typically uses a 12 pin R4 connector. This is the typical connector for CD
changers, receivers, and amps. As opposed to the typical IEBus connector, the R4 connector contains
additional lines for an eject signal, mute, speaker ground, and stereo speaker lines consisting of R+, R-,
L+, and L-.
As we can see the Toyota AVC-LAN R4 connector provides for a stereo analog audio line to be
included in the same harness as the control lines. Notice there is no auxiliary inputs or outputs for any
device. Rather Toyota uses serial data transmitted over the bus to control which device is supposed to
be using the stereo lines at any given time. Multiple devices may exist on the bus and all may be
capable of injecting audio onto the stereo lines, but the head unit will dictate who is supposed to be
controlling those lines.
figure 3: Typical IEBus Connector
figure 4: R4 Audio Connector
1)12V
2)Ignition
3)Power Ground
4)TX+
5)TX-
1)R+ 2)L+ 3)S-GND
4)MUTE
6)R-
9)TX- 10)TX+
11)Eject
5)12V
8)GND
7)L-
12)Ignition
Toyota also uses other connectors on the AVC-LAN, specifically where video or microphone signals
are required. Many models with integrated navigation, back-up cameras, hands-free telephones, or
DVD-players use N2, N3, and N4 connectors to transport video and microphone signals in addition to
the signals that run through the R4 connectors on the AVC-LAN. Figure 5 shows these connectors on
a 2004 Prius Navigation ECU. The same basic configuration is shared on Sienna, Lexus, and other
models with navigation options. Sienna and Lexus schematics indicate these same connectors are
utilized to integrate entertainment systems.
Video for models prior to 2006 seem to be supported through separate analog Red, Green, Blue, and
Composite Synchronization signals (RGBS) passing through the N3 connectors. Images are NTSC
interlaced with horizontal sync at about 15.75kHz having 30 complete image frames a second (60
interlaced). Resolution on 2004-2005 models is reported to be 800 by 480 (while others say it's 400 by
234). As an interesting side note some individuals have been able to inject VGA signals through the
N3 by using PowerStrip or SwitchResX for Windows and Mac OS X respectively and a homemade
cable harness. Often additional hardware is required, since many graphics cards don't support
composite sync or interlaced modes and these options are rarely advertised even when they do. Some
2006 models are known to transmit video digitally, although the specifics of this are currently vague at
best.
figure 5: Connectors N2, N3, N4 on 2004 Prius Navigation ECU
COMMUNICATION PROTOCOL:
Every command over the IEBus follows a particular format consisting of a Header, Master Address
Field, Slave Address Field, Control Field, Data Length Field, and Data Field(s). Communication is
either from one device to another or is broadcast to all devices on the bus. Each device on the bus has a
unique identifier (address) that says what kind of device it is. Only one device may exist per address,
so multiple devices of the same type may not exist unless there is a secondary identifier they are
capable of assuming.
figure 6: Basic IEBus Communication Frame/Packet
The Header consists of the start bit and a broadcast bit. The start bit has an extra long high signal that
denotes the start of communication and is always considered a 1 (see figure 2). Immediately following
this is the broadcast bit. This bit is a 1 to denote direct communication to another device or 0 to denote
a message broadcast to all devices.
The Master Address Field is composed of 12 bits telling what device is sending the message and 1
parity bit. Even parity is used here and for all other parity checks. Therefore, when the number of 1's
in the master address bits is odd, the parity bit should be set to 1. This will make the number of 1's in
each field (including the parity bit) always even. If this is not the case a transmission error occurred
and the receiving slave device should not acknowledge the transmission.
The Slave Address field is also 12 bits with a parity bit. An additional bit follows, with value 0, that
provides time for the slave device to further increase the voltage differential on the twisted pair and
indicate that it acknowledges the receipt of a valid message to it. Values for the 12 bit addresses come
from a shared list of device type identifiers that are common across Toyota automobiles. For general
broadcast the slave address is set to FFF (hex). Some of the more common and known address
numbers are (in hex):
110 – Multi Function Display (MFD)
140 – AVN
178 – Navigation
1AC – Camera-C
1C2 – TV Tuner 2
1C8 – FM-M-LCD
1F0 – Radio Tuner
230 – TV-Tuner
280 – Camera
17D – Telephone
5C8 – MAYDAY
1F4 – RSA
128 – 1DIN TV
120 – AVX
160 – Audio H/U
144 – G-Book
190 – Audio H/U
17C – MONET
1C0 – Rr-CONT
180 – Rr-TV
1C4 – Panel
1C6 – G/W
1D8 – CONT-SW 1EC – Body
1F1 – XM Radio
1F2 – Sirius
250 – DVD-CH
240 – CD-CH2
3A0 – Mini-Disk CH
360 – CD-CH1
530 – ETC
440 – DSP-Amp
1A0 – DVD-Player
1D6 – Clock
480 – Amplifier
1F6 – RSE
As some additional clarification, 190 seems to be the H/U on the Prius and 160 on the Corolla.
Commands for controlling bass, treble, fade, and balance are completely different between these
vehicles. This may be related to the Prius data pertained to a system with a JBL amp. With this system
440 was addressed by 190, rather than a broadcast from 160, to control these values. Also when
navigation and MFD systems are present, touchscreen events may be sent from 110 to 178.
Four control bits, a parity bit, and an acknowledge (ACK) bit make up the control field. Control field
values themselves vary depending on the receiving device. Documentation of these values are not in
Toyota manuals available to the public. There are groups of home-brew hardware developers that have
compiled some values for AVC-LAN control fields for a few types of hardware. This requires having a
piece of equipment of that type and being able to capture and analyze messages to and from that
equipment. Needless to say these lists are very limited and incomplete.
The data length field tells how many data fields to expect. These values are dependent upon the control
field and slave address, so knowledge about them is also very limited. Data length has 8 bits followed
by a parity and acknowledge bit. Values of 0h1 to 0hF define 1 to 15 trailing data fields and 0h0
denotes 16 trailing data fields. Data fields also consist of 8 bits with parity and acknowledge bits. The
data fields are used to contain information that describe more complex component commands.
Below are some common messages from the 2004-2005 Prius listed in the format
(in hex & excluding parity or ACK
bits):
Request to play Beep dd=1-4 duration :
Press on screen (xx,yy) = (0-FF, yy=0-FF): <1> <110> <178> <8> <0 21 24 78 xx yy xx yy>
<1> <110> <440> <5> <0 5E 29 60 dd>
Balance bl = 09 (left) to 17 (right):
Fade fd = 09 (front) to 17 (back):
Bass bs = 0B (min) to 15 (max):
Mid md = 0B (min) to 15 (max):
Treble tb = 0B (min) to 15 (max):
Volume up vu= 01(min) to 04(max):
Volume down vd= 01(min) to 04(max):
<1> <190> <440> <5> <00 25 74 91 bl>
<1> <190> <440> <5> <00 25 74 92 fd>
<1> <190> <440> <5> <00 25 74 93 bs>
<1> <190> <440> <5> <00 25 74 94 md>
<1> <190> <440> <5> <00 25 74 95 tb>
<1> <190> <440> <5> <00 25 74 9C vu>
<1> <190> <440> <5> <00 25 74 9D vd>
The number of known commands are relatively limited, since Toyota does not publish these. A
standard set of commands must exist, but they are likely only available to partners of Toyota and large
after-market equipment companies. The only definite way to determine if command codes will work,
or to find new command codes, is to try known codes or monitor transmissions from units that work on
the AVC-LAN. See the references listed at the end of this document for additional information or
sources.
PRACTICAL CONSIDERATIONS:
Since many of the parts needed to tap into and work with the AVC-LAN are not accessible to the
general public, mechanics, or dealerships; it can be difficult for individuals to build AVC-LAN
compatible circuits. The largest difficulty appears to exist for finding specialty connectors AVC-
LAN/IEBus driver circuits.
Connectors such as R4 Y-adapters are easily found at dealerships and part stores because of after-
market car stereo equipment. More exotic connectors such as N2, N3, and N4 connectors can not
readily be bought outside of japan. Even then, most individuals are currently forced to buy complete
(and expensive) harnesses and cut off the ends to make adapter cables. Dealerships will not usually be
able to order video AVC-LAN connectors, even though they plainly are listed in the repair manuals.
Places like japanparts.com may be the only result in such instances.
Commercial chips do exist from NEC that handle most issues of communication on the IEBus.
Unfortunately these chips must be purchased in very large quantities and can only listen to broadcasts
or messages directed specifically at them. These chips are targeted at operating as a simple stand-alone
slave device, which makes these chips useless if the construction of a AVC-LAN analyzer, message
interceptor, or similarly operating device is required. Analog comparators or op-amps, when correctly
biased, can convert differential signals into a 0-3.3V or 0-5V digital signal that is more useful with
typical digital electronics. Some proven designs use the LM339 in this capacity. The resulting signal
is then typically sampled at intervals shorter than 7 microseconds by a micro-controller or other digital
logic mechanism, so that major transition states are captured (although 3.3 microseconds aka 300kHz
or less would be safer).
Possibly as time goes on and more products support AVC-LAN the technologies that support it will
become more common and available to the common man. At that time a cost may also become
reduced to build interfaces to the AVC-LAN or competitively priced and more complete and developed
solutions will be available.
CONCLUSIONS:
While all the mysteries of the Toyota automobile audio bus have not been revealed, enough has been
uncovered here to understand and work on basic devices. The AVC-LAN is based upon the more strict
and better known standards of the IEBus. This specifies reasonably well known methods for signal
transmission, definition of logic bits, and message structure in regards to headers and transmitted data.
Specifics of the AVC-LAN are related more to standard addresses of particular types of equipment that
may exist on the bus, control commands, and data fields used to manage devices on the bus.
Being a proprietary format Toyota can and does add ways for new components to interact on this bus
without notice. Still, basic functionality must be maintained to support after-market add-ons and allow
reuse of components across multiple models. Identification of standard device types on the network
was made, as well as some of the messages that are passed between them. This information should stay
the same for common components that will have long lifetimes or go through multiple revisions. The
serial interface of the bus system is flexible enough to allow new features to be added while
maintaining previous features.
Overall enough layers of this system have been adequately revealed here that integration of a simple
device into the audio or entertainment system of a modern Toyota could be further explored and
accomplished. From physical interface to electronic signaling and messaging protocols, the control
mechanism can be reasonably understood and worked with. The AVC-LAN is less of a mystery and
more of a tool that can be used and mastered.