Docstoc

Truck - Trailer Wireless Connection

Document Sample
Truck - Trailer Wireless Connection Powered By Docstoc
					Truck-Trailer Wireless Connections




Issued by: Mikael Gunnarsson
Scania Infotronics AB
4 Dec. 01
Truck – Trailer                                                   Mikael Gunnarsson
Wireless Connection                                                      4 Dec. 01




Preface

This master thesis project has been carried out during the fall of 2001 at Scania
Infotronics AB. The project comprises 20 credits and is the completion of a Master
of Science degree in Electric Engineering at the Royal Institute of Technology in
Stockholm, Sweden. It has been a fun and rewarding period and I have really
enjoyed the experience. I would like to thank all the helpful people at Scania
Infotronics and in particular my advisor Mattias Sjögren.

I would also like to thank Erland Nilsson, who developed the BTerm application
that has been used in this project and whose knowledge in the BlueTooth area has
resulted in many interesting discussions.




                                                                        Page 2 of 56
Truck – Trailer                                                       Mikael Gunnarsson
Wireless Connection                                                          4 Dec. 01




Abstract
Scania Infotronics is a subsidiary of Scania AB that works with IT-solutions for
heavy vehicles. In one of Scania Infotronics’ projects a handheld computer is
installed in a truck and connected to the vehicle’s data bus. From this data bus it is
possible to collect a vast amount of data that is generated by the truck. The problem
today is that the data bus does not reach into any trailers that are coupled to the
truck, and no data can therefore be gathered from the trailers. A wireless link
between the truck and the trailer would solve this problem. Possibly the unit
installed in the trailer should be made portable in order for it to be easily moved
between different trailers.

This project will examine some of the technologies currently available that could be
used to solve this. This will include studies of technologies such as DECT and
BlueTooth. Some other technologies will be discarded in an early stage and others
will be more thoroughly examined. During the implementation phase a prototype
will be created for testing and evaluation.

There has already been lots of work done as some of these wireless technologies
have been around for a while and they are well standardized and widely deployed.
What makes this project difficult is choosing the most suited technology for use in
the very special environment that the truck and its trailer constitute. Furthermore the
hardware and the software necessary are expected to raise interesting problems
requiring new solutions.




                                                                            Page 3 of 56
Truck – Trailer                                                                                      Mikael Gunnarsson
Wireless Connection                                                                                         4 Dec. 01



Contents

1 Introduction ............................................................................................................. 7
   1.1 Background ...................................................................................................... 7
   1.2 Scania Infotronics AB ...................................................................................... 7
   1.3 Truck – Trailer wireless connection ................................................................ 7
     1.3.1 Existing system ......................................................................................... 7
     1.3.2 Project goal ............................................................................................... 8
2 Wireless Technologies .......................................................................................... 10
   2.1 DECT ............................................................................................................. 10
     2.1.1 History .................................................................................................... 10
     2.1.2 Air interface ............................................................................................ 11
     2.1.3 DECT standard ....................................................................................... 11
     2.1.4 DECT application profiles ...................................................................... 12
     2.1.5 Message format ....................................................................................... 13
     2.1.6 Networking ............................................................................................. 14
     2.1.7 Data transfer speed .................................................................................. 14
     2.1.8 Comments ............................................................................................... 15
   2.2 BlueTooth ...................................................................................................... 15
     2.2.1 History .................................................................................................... 15
     2.2.2 Air interface ............................................................................................ 15
     2.2.3 The BlueTooth standard .......................................................................... 16
     2.2.4 Message format ....................................................................................... 17
     2.2.5 Networking ............................................................................................. 18
     2.2.6 Data transfer speed .................................................................................. 20
     2.2.7 Comments ............................................................................................... 20
   2.3 Other technologies ......................................................................................... 20
   2.4 DECT vs. BlueTooth ..................................................................................... 21
     2.4.1 Air Interface ............................................................................................ 21
     2.4.2 Identification and authorization .............................................................. 22
     2.4.3 World coverage ....................................................................................... 22
     2.4.4 Capabilities ............................................................................................. 22
     2.4.5 Costs and availability .............................................................................. 23
3 Controller Area Network ...................................................................................... 25
   3.1 Introduction .................................................................................................... 25
   3.2 General principles .......................................................................................... 25
     3.2.1 Message formats ..................................................................................... 26
     3.2.2 Extended CAN ........................................................................................ 26
     3.2.3 Arbitration ............................................................................................... 27
     3.2.4 Bit timing ................................................................................................ 28
     3.3.1 Error types ............................................................................................... 28
     3.3.2 Controller modes..................................................................................... 29
   3.3 Standards ........................................................................................................ 30
     3.3.1 SAE J1939 .............................................................................................. 30
     3.3.2 ISO 11992 ............................................................................................... 30
   3.4 Networking .................................................................................................... 30
   3.5 CAN Gateways .............................................................................................. 31
     3.5.1 Address Assignment ............................................................................... 31



                                                                                                              Page 4 of 56
Truck – Trailer                                                                                       Mikael Gunnarsson
Wireless Connection                                                                                          4 Dec. 01


4 Prototype development ......................................................................................... 33
  4.1 BlueTooth module ......................................................................................... 34
     4.1.1 Packet types ............................................................................................ 34
     4.1.2 HCI Command Packets ........................................................................... 34
     4.1.3 HCI Event Packets .................................................................................. 36
     4.1.4 Initialization ............................................................................................ 36
     4.1.5 Inquiry ..................................................................................................... 37
     4.1.6 Create connection ................................................................................... 37
     4.1.7 Data transfer ............................................................................................ 38
  4.2 MB90543 Fujitsu microcontroller ................................................................. 39
  4.3 The Prototype ................................................................................................. 39
     4.3.1 Sending HCI commands ......................................................................... 40
     4.3.2 RS232 serial interface ............................................................................. 40
     4.3.3 Gateway CAN messages ......................................................................... 40
     4.3.4 Description of how the prototype works. ................................................ 41
5 Protocol ................................................................................................................. 44
  5.1 Message formats ............................................................................................ 45
     5.1.1 Command message format ...................................................................... 45
     5.1.2 Return parameters format ....................................................................... 45
     5.2.1 Bt_Inquiry ............................................................................................... 46
     5.2.2 Bt_Initialize ............................................................................................ 47
     5.2.3 Bt_Connect ............................................................................................. 47
     5.2.4 Bt_Disconnect ......................................................................................... 48
  5.3 Examples ........................................................................................................ 49
6 Evaluation & Testing ............................................................................................ 50
7 Conclusions ........................................................................................................... 51
8 Future work ........................................................................................................... 52
  8.1 Hardware ........................................................................................................ 52
  8.2 BlueTooth Product Qualification ................................................................... 52
  8.3 Security .......................................................................................................... 52
  8.4 Testing a CAN gateway ................................................................................. 53
References ................................................................................................................ 54
Appendix A .............................................................................................................. 56




                                                                                                               Page 5 of 56
Truck – Trailer                                                                                 Mikael Gunnarsson
Wireless Connection                                                                                    4 Dec. 01



Tables & Figures
Table 1: DECT layers .............................................................................................. 12
Table 2: DECT Data services profiles ..................................................................... 13
Table 3: BlueTooth frequencies worldwide ............................................................. 15
Table 4: BlueTooth profiles ..................................................................................... 17
Table 5: Source ID's in a road train ......................................................................... 32
Table 6: HCI packet types ....................................................................................... 34
Table 7: UART speed setting................................................................................... 35
Table 8: Hex dump from initialization..................................................................... 37
Table 9: Example of a HCI ACL Data Packet ......................................................... 39


Figure 1: Current CAN system in the truck ............................................................... 8
Figure 2: Placement of wireless nodes ...................................................................... 9
Figure 3: DECT message format ............................................................................. 13
Figure 4: BlueTooth message format ....................................................................... 17
Figure 5: A BlueTooth scatternet network .............................................................. 19
Figure 6: CAN Data frame....................................................................................... 26
Figure 7: CAN message priority .............................................................................. 27
Figure 8: CAN bit timing calculation ...................................................................... 28
Figure 9: State diagram of the CAN controllers ...................................................... 29
Figure 10: Road train ............................................................................................... 32
Figure 11: Prototype system overview .................................................................... 33
Figure 12: BlueTooth module from Ericsson .......................................................... 33
Figure 13: HCI Command Packet message format ................................................. 34
Figure 14: HCI ACL Data Packet message format .................................................. 38
Figure 15: L2CAP header format ............................................................................ 39
Figure 16: Flowchart showing the prototype in runtime. ........................................ 41
Figure 17: Flowchart showing reception of CAN messages ................................... 42
Figure 18: Reception of an ACL Data packet containing a CAN message ............. 43
Figure 19: Prototype command message format ..................................................... 45
Figure 20: Prototype return parameter format ......................................................... 45
Figure 21: Procedure to make a connection ............................................................. 49
Figure 22: Prototype test-system ............................................................................. 50




                                                                                                         Page 6 of 56
Truck – Trailer                                                      Mikael Gunnarsson
Wireless Connection                                                         4 Dec. 01



          1 Introduction
1.1 Background
Due to the rapid technical evolution during the recent years the integration of
information technology into vehicles has grown rapidly. Today many electronic
control units can be found in for example a truck. They are increasingly
interconnected to form an information exchange system between different parts of
the vehicles such as the brake system, the gearbox or sensors (for example giving
information about the amount of fuel). Some of the data provided by these units
may be of interest to the driver (or others such as the fleet operators or for vehicle
maintenance). In one of Scania Infotronics’ projects a handheld computer is
installed in a truck and connected to the vehicle’s data bus. From this data bus it is
possible to collect a vast amount of the data that is generated by the truck.

1.2 Scania Infotronics AB
Scania Infotronics is a subsidiary of Scania AB that works with IT-solutions for the
truck industry. They were founded in April 1999 and are located in Kista – the heart
of Sweden’s “Wireless Valley”. Their objective is to use information technology to
link both the driver and vehicle to the Internet making the truck more and more a
“moving office”. One of Scania Infotronics products is called FAS. It is a fleet
management system built for the Microsoft Pocket PC platform. This software runs
on a Casio Cassiopeia E-125, which is a small handheld computer. More about
Scania Infotronics, their products and business concept can be found at their web
page1.

1.3 Truck – Trailer wireless connection
The task of this project is to evaluate which technology would be most suitable for
a wireless connection between a truck and its trailer. Aspects to have in mind are:

      -    The technology has to be well standardized. This makes it easy to get parts
           for production, documentation on the technology and aid from others.
      -    The hardware has to be low-cost.
      -    The technology must work well in various countries along the route of the
           truck in question.
      -    A data rate of at least 100 kbps is needed.

1.3.1 Existing system
A Control Area Network (CAN) data bus (described in chapter 3) is today built into
the truck. To this bus various components of the vehicle is connected exchanging
data with each other. This data bus is a part of the vehicle and is shown in Figure 1
as the “Internal bus”.

In the truck’s cabin a Casio Cassiopeia E-125 is mounted and connected to an
external CAN bus. Between the external CAN bus and the one in the truck there is a
gateway also developed by Scania Infotronics. An overview is shown in Figure 1.


1
    http://www.infotronics.scania.com


                                                                           Page 7 of 56
Truck – Trailer                                                     Mikael Gunnarsson
Wireless Connection                                                        4 Dec. 01




Figure 1: Current CAN system in the truck
The purpose for having two separate CAN buses and a gateway between them is
that on the Internal bus there are CAN messages that doesn’t comply with the J1939
standard (explained in Chapter 3.3). These messages don’t pass through into the
external bus or are edited to fit the standard before forwarding. The gateway shown
in Figure 1 is explained in Chapter 4 because the hardware is used in the prototype
development.

Scania Infotronics has developed software that collects and analyses data such as
time, distance, road speed and fuel usage. Through these data it is possible to
monitor a driver’s performance, to analyze his/hers driving skills, and to calculate
the cost of a specific route. After a trip the collected data can be transferred from
the vehicle for synchronization with a PC in the office for further processing.

The fact that Scania Infotronics AB uses Pocket PC as platform enables a PDA,
such as the Cassiopeia E-125 to be of use to a truck driver for many purposes in
addition to the FAS product.

1.3.2 Project goal
The main reason for choosing a wireless link between the truck and the trailer is to
avoid more cables between them. In addition, if the system in the trailer is to be
portable between different trailers it is much easier to have a system physically
separate from the one in the truck. As mentioned earlier, the goal of this project is
to decide what technology to use and to create some kind of prototype for
demonstration. The project specification says that there is a J1939 CAN [18] bus in
the truck and that it is to be connected to an ISO 11992 [16] CAN bus in the trailer.
Between these a wireless link is to be inserted, as shown in Figure 2.




                                                                          Page 8 of 56
Truck – Trailer                                                                     Mikael Gunnarsson
Wireless Connection                                                                        4 Dec. 01



                     Handheld                   Wireless link nodes
                     Computer




                       CAN - SAE J1939                  CAN - ISO 11992
Figure 2: Placement of wireless nodes
Scania Infotronics also wishes to have possibilities to send other data in parallel
with CAN messages. They are currently using a MB90543 microcontroller from
Fujistu for the gateway between the internal and external CAN bus (see Figure 1).
This microcontroller has two CAN interfaces and two RS232 serial interfaces. The
microcontroller is to be used in this project2 when building a prototype to multiplex
the CAN messages with serial data into the wireless link and to separate them on
the other side. It has to be programmed to do this using the ANSI C programming
language. The system is supposed to be very low-cost, approximately 200 SEK. It
should also be able to run on battery power in certain situations so a low-power
system is also desired.

If this scenario should be changed is something that will be discovered later in the
project. It is not clear today what the system will look like and what kind of
information should be collected from the trailer. Things that might be of interest
include real-time values of the temperature of the cargo or some kind of video
camera in the trailer or on the external back of the trailer. A camera facing
backwards could in some situations help the driver to reverse against a dock to
unload cargo. As mentioned earlier there currently is no CAN bus in trailers and it
is not clear if all trailers should be equipped or if the parts providing data in the
trailer should all have wireless connections. Depending on these answers the
scenario using the ISO 11992 CAN bus will be dramatically altered.

The goal for this project is to initiate the development of a wireless link that enables
the CAN-bus to reach into the trailer. The outcome should provide a ground for
Scania Infotronics to continue the research and in the future come up with a
complete product.




       2 Wireless Technologies


2
 This does not mean that the finished product will use the Fujistu microcontroller. It is just going to
be used in testing the link.


                                                                                           Page 9 of 56
Truck – Trailer                                                                   Mikael Gunnarsson
Wireless Connection                                                                      4 Dec. 01


During the last two decades technology has evolved rapidly. With the introduction
of different wireless technologies the term “mobility” is often used. People using
electronic devices don’t want to be attached by cables; they want to be free to move
around. At home cordless telephones are becoming common and at offices wireless
technologies are being used to provide a network connection to ones laptop or PDA
at all time and in all locations.

In the truck industry there are an increasing number of electric systems being
integrated into vehicles. Sensors are no longer just mechanical and advanced
systems for data communication between different parts are being used. Although
such communication has been (and still is) working fine with wires and the CAN
standard, there might for some information exchange be more appropriate to have
via a wireless alternative. Subsystems can then easily be moved between different
vehicles and there is no need for permanent installation. A sensor providing
information about the temperature could be placed anywhere at and still connected
to the system without having to figure out where to place the wires.

This project focuses on creating a wireless link between the truck and its trailer.
There are two different technologies that are more suitable for this than others. One
of them is DECT and the other is BlueTooth. The following text introduces these
two standards and gives some explanation as why other technologies available are
not as suitable.

2.1 DECT
Digitally Enhanced Cordless Telecommunication (DECT) is a digital wireless
technology that originated in Europe in the end of the 1980’s [3] [4]. Most people
think of DECT as a cordless telephone technology but actually it provides far more
than that. It is able to work together with technologies such as GSM, ISDN and
many others; while providing a data transfer at the rate of 552 kbps in one direction.

2.1.1 History
Analogue cordless telephones have been around in Europe since the early 1980’s
and during the first half of that decade the transition to digital technology started.
This enabled more phones to co-exist within a small space, prevented
eavesdropping and allowed controlled switching between base stations thus
providing a wider coverage area. Two standards were created to make this happen.
One of them was a standard called CT2, which was invented in the UK and the
other was called CT3, a Swedish standard.

European Telecommunications Standards Institute3 (ETSI) decided to merge these
two standards (CT2 & CT3) into one standard that would be valid throughout
Europe. The result was that DECT was born in January 1988.

Today DECT is a standard that is used in a large number of countries: Europe,
Australia, a large part of Asia, northern Africa and almost all of South America use
this standard. The North American Personal Wireless Telecommunication (PWT)

3
    http://www.etsi.org, a non-profit organization whose mission is to produce telecommunications
    standards that will be used throughout Europe


                                                                                       Page 10 of 56
Truck – Trailer                                                                    Mikael Gunnarsson
Wireless Connection                                                                       4 Dec. 01


standard is a standard used in North America. It is built on DECT, but uses another
frequency allocation and modulation scheme.

2.1.2 Air interface
The MC/TDMA/TDD principle
DECT uses a technique called Multi Carrier (MC) / Time Division Multiple Access
(TDMA)/ Time Division Duplex (TDD). DECT operates in the 1880 – 1900 MHz
range and it uses ten carrier frequencies, each with a spacing of 1.728 MHz. The
time spectrum is subdivided into 10 ms timeframes. Each of these timeframes is
divided into 24 timeslots (TDMA). This gives a total of 240 channels (10
frequencies * 24 timeslots).

For telephony services the timeframe is divided into two parts of 12 timeslots each
(using TDD). One of them is used for transmission and the other for reception.

For basic speech services two timeslots with 5 ms (i.e. 12 timeslots) separation is
used. They are paired together to provide full duplex coded speech each with a data
transfer rate of 32 kbps. For data transfer several channels can be combined to
provide data transfer at a maximum aggregate rate of 552 kbps.

Dynamic channel selection
While other technologies use so called “frequency hopping”4 to minimize
interference DECT uses another approach. DECT uses something called dynamic
channel selection and allocation. As explained earlier a basic telephone
conversation uses only two timeslots out of 240 per timeframe. This leaves time for
analyzing the link. Every 30 seconds the unit scans all unused timeslots to create a
list of unoccupied channels. The list is called a Received Signal Strength List
(RSSL). In the list are entries for each one of the timeslot/carrier combinations. A
low value in the list indicates a timeslot that is free and non-interfered and a high
value represents busy channels. If the connection between a base station and the
portable is getting worse they will switch to a new timeslot after sending the
information via both the new and the current channel for a short while. This double
information transmission is to prepare for timeslot shifting. If the interference was
only temporarily the shifting will be cancelled.

2.1.3 DECT standard
The DECT Common Interface (CI) standard is well documented by ETSI in eight
separate parts [6]-[13], see Table 1. The standard is divided into several layers
similar to the OSI layer structured model and describes the air interface between a
DECT Fixed Part (FP) and a Portable Part (PP). These eight documents are the base
standard and they contain details of all messages and procedures used in DECT
equipment.




4
    Algorithms to switch between channels (frequencies) and prevent interference


                                                                                        Page 11 of 56
Truck – Trailer                                                      Mikael Gunnarsson
Wireless Connection                                                         4 Dec. 01




                       Part    Title
                       1       Overview
                       2       Physical layer
                       3       Medium Access Control layer
                       4       Data Link Control layer
                       5       Network layer
                       6       Identities and Addressing
                       7       Security aspects
                       8       Telephony
Table 1: DECT layers
Two other DECT base standards are Wireless Relay Station (WRS), which
describes a DECT unit capable of relying radio transmissions and the DECT
Authentication Module (DAM), which is a programmable chip card that deals with
authentication similar to the SIM cards used in GSM telephones.

2.1.4 DECT application profiles
Not all of the messages and procedures of the base standard are used in the various
applications that use DECT technology. A specific application might require only a
subset of these procedures. To make the standard friendlier to interoperability
between products from different manufactures a number of DECT Profile
Standards have been declared. These standards specify the minimum requirements
for interoperability between different devices complying with a profile. The main
differences are related to message formats and protocol setups. In all DECT systems
the radio requirements described in the DECT common interface are being
followed.

Generic Access Profile
The Generic Access Profile (GAP) [14] is the basic standard profile for any DECT
application supporting 3.1 kHz telephony service. Procedures are described to
establish, maintain and release connections. This is the base for all future DECT
speech profiles.

Data Services Profiles
DECT provides powerful wireless data capabilities. A suite of profiles for data
transfer (DSPs) has been developed by ETSI [5]. Each of these profiles is optimized
for a specific service and the specification describes several possible user scenarios
in wireless computing. Six different types of services have been defined; Type A to
F. A brief overview is shown in Table 2.




                                                                          Page 12 of 56
Truck – Trailer                                                                                  Mikael Gunnarsson
Wireless Connection                                                                                     4 Dec. 01




     Type            Description
     A               Low speed with a throughput of up to 24kbps optimized for burst data to low
                     complexity applications
     B               High speed data transfer with a data rate up to 552kbps
     C               Non-transparent connection of data streams requiring Link Access Protocol
                     (LAP), optimized for high reliability
     D               Transparent and isochronous connection of synchronous data streams
                     optimized for continuous data.
     E               Short message transfer or paging
     F               A service type build upon types A and B supporting teleservices such as fax

Table 2: DECT Data services profiles
DECT Packet Radio Service
The DECT packet Radio Service (DPRS) specifies common features and services
for all packet data applications. It contains all requirements of and replaces the
earlier mentioned data profiles A, B and C. Some of the key features of DPRS are:
    - High-speed user data transfer at 552 kbps in one direction.
    - DECT Multibearer and asymmetrical operation (the slots are reserved to
        increase speed in one direction).
    - High spectrum efficiency, the air interface is used only when there is data to
        transmit.
    - Automatic Repeat Request (ARQ) mechanisms.

2.1.5 Message format
DECT uses a TDMA structure that repeats in frames of 11520 bits. A frame repeats
every 10 ms, thus the data is transmitted at a bit rate of 1152 kbps. Every frame is
divided into 24 timeslots (as explained earlier) and every timeslot therefore contains
480 bits. An overview of a timeslot is shown in Figure 3. Each frame consists of
three fields: the synchronization, data and the guard field.

Frame
 0       1   2   3   4   5   6   7     8   9     10   11   0      1   2   3   4     5   6    7     8   9   10   11



Timeslot
      Sync.-field, 32bits                      D-field, 388bits                   Z-field,       Guard-Space,
                                                                                   4bits            56bits



D-field
                     A-field, 64bits              B-field, 320bits                X-field, 4bits


Figure 3: DECT message format


Synchronization field
The synchronization field contains 32 bits. The first 16 of them are preamble and
the last 16 are the packet synchronization word. They are transmitted as packet bit
numbers p0 - p31.



                                                                                                       Page 13 of 56
Truck – Trailer                                                       Mikael Gunnarsson
Wireless Connection                                                          4 Dec. 01




Data field
The data field carries user information. It contains 388 bits transmitted as p32 -
p419. It is divided into the A-field, B-field and the X-field. The A-field contains
packet header data and the B-field contains data from higher levels. The X-field
contains redundancy bits calculated from the B-field content.

Just after the data field there is a 4 bit long Z-field. The Z-field may be used by the
receiver for early detection of unsynchronized interference sliding into the end of
the physical packet. It is transmitted as p420 – p423 and is identical to the X-field.

2.1.6 Networking
A DECT network is built up of one fixed part (FP) and one or more portable parts
(PP). The FP acts like a basestation to whom the PP can connect. If two PP’s wants
to connect to each other (or the network that the fixed part is connected to) it is
done thru the FP. A connection is always initiated by the PP but the FP can page the
PP with a “could you please connect to me” message.

There are two different mobility classes, mobility class 1 and mobility class 2.
Mobility class 1 units are used in local area applications. In this case a FP contains
a static list of the PP’s that are allowed to connect. Mobility class 2 is meant for
public application where the PP can roam between different fixed parts.

Connection establishments
A DECT basestation is continuously transmitting on - at least - one channel, thus
providing a beacon function for portable parts to lock on to and synchronize with.
The basestation transmits in a broadcast fashion in all messages information about
its identity and system capabilities. It also scans idle receive channels in a
sequential way to establish a link with portable parts.

The portable parts look in their RSSI list (mentioned earlier) for a channel that is
heavily used and starts to accept reception on this channel. If no basestation is
found it continues to go thru the list until it finds a channel used by a basestation.
When synchronization is accomplished the portable checks the message
broadcasted by the basestation to see if it is allowed to connect. Then the portable
part looks in its RSSI list again to see which channel to use and then asks for a link
set up.


2.1.7 Data transfer speed
By combining several channels into a multi-frame one can achieve a higher bit rate.
The normal bit rate of a channel for user information is 32 kbps. This utilizes the
320-bit B-field mentioned earlier. The X-field only provides a 4-bit error check of
the data field, which is not enough protection for data transmission. To solve this
DECT provides another format for the B-field called Protected B-field. The B-field
is now divided into four parts each containing 64 bits of data and 16 bits of CRC
error check. This reduces the data transfer speed to 25.6 kbps. The Data link control
layer uses two bytes for various services (not explained here). This reduces the data
transfer speed further to 24kbps. A total of 23 channels can be combined for


                                                                           Page 14 of 56
Truck – Trailer                                                             Mikael Gunnarsson
Wireless Connection                                                                4 Dec. 01


transmission in one direction (the last channel is used for acknowledgements in the
opposite direction). This will give a total of 23 channels * 24kbps = 552 kbps data
transfer speed.

2.1.8 Comments
It might be a possible solution to use DECT in this project. DECT has been around
for a while and the standard feels “mature”. It is rather insensitive towards
interference because of the frequency band that is for DECT only. It is also a
standard that is valid in a large number of countries. One thing however that might
be a problem is the situation in which one wants to connect to an anonymous trailer.
Currently the A and B application profile, which are of interest here supports
mobility class 1 only. In this class a static list of the portable parts that are allowed
to connect must be kept in the fixed part.

2.2 BlueTooth
BlueTooth uses a radio interface in the 2.45 GHz frequency band to enable portable
devices to connect to each other via short-range wireless connections. The name
BlueTooth is taken from Harald BlueTooth, who was a Nordic Viking king during
the 10th century. The name doesn’t have anything to do with the technology. Instead
it points out the connection between the Nordic countries and the development of
the standard.

2.2.1 History
In 1994 Ericsson Mobile Communications AB in Lund, Sweden started to
investigate the possibilities of a radio interface between a mobile telephone and its
accessories [1]. The intention was to come up with a technology that was low-cost,
low power, small and secure in an unlicensed frequency band. This interface was
going to be a replacement for wires between phones and PC’s, wireless headsets,
etc. The interest in such a standard resulted in Ericsson, Nokia, Intel, Toshiba, and
IBM forming a special interest group (SIG). The purpose for doing so was to
achieve a mix of business areas for this new technology and to promote widespread
adoption. In May 1998 the BlueTooth consortium announced itself and since then
the SIG has grown rapidly.

2.2.2 Air interface
BlueTooth operates as in the 2.45 GHz band. In most countries the band ranges
from 2400 to 2483.5 MHz [22]. In Spain and France the frequency band is narrower
(as shown in Table 3). This frequency band is one of the Industrial-Scientific-
Medical (ISM) bands and is a frequency band that is free for unlicensed use. Garage
door openeners, microwave ovens, baby monitors, and wireless technologies such
as wireless LAN (WLAN) are just some examples of users of these frequencies.

               Geography                              Regulatory Range
               USA, Europe and most other countries   2.400 - 2.4835 GHz
               Spain                                  2.445 - 2.4835 GHz
               France                                 2.4465 - 2.4835 GHz
Table 3: BlueTooth frequencies worldwide




                                                                                 Page 15 of 56
Truck – Trailer                                                      Mikael Gunnarsson
Wireless Connection                                                         4 Dec. 01


The frequency hopping principle
Because of the large number of users in the ISM band, BlueTooth has to deal with
several sources of interference. A desirable way to do this would be to avoid
frequencies used by other nearby devices. To achieve this BlueTooth uses a
technique called frequency – hop (FH) spread spectrum.

The band used by BlueTooth is (in most countries) 83.5 MHz wide. This band is
divided into 79 carriers (called slots) with 1MHz spacing. In countries such as
Spain and France that have only a part of the band there are only 23 slots. 1600
times a second BlueTooth switches its transmission frequency between these slots
forming a communication channel. The hopping sequence is calculated based on a
pseudorandom number derived from the identity number of the master device of a
specific network. This periodic switching between frequencies means that if there is
another narrowband device nearly this device it will only interfere a small amount
of the time.

Transmitter characteristics
BlueTooth units are divided into three classes with different transmit powers.
Products that are available on the market now have a maximum transmit power of
10mW. This gives them a maximum range of 10 meters. Future BlueTooth units
will have a maximum transmit power of 100mW, which raises the range to a
maximum of 100 meters. In these units there is power control, which makes it
possible to keep the devices from emitting more than the necessary power.


2.2.3 The BlueTooth standard
The BlueTooth specification is available for download at the BlueTooth website5. It
consists of two documents, Volume 1, Core [20] and Volume 2, Profiles [21]. Like
DECT and most other technologies of this kind, the BlueTooth protocol is build in
layers similar to the OSI model. Volume 1, Core is divided into several parts
describing everything from the radio interface to the interoperability with other
technologies such as IrDA and WAP. It also contains rules and details about
connections and message formats.

Volume 2, Profiles consists of a number of different profile specifications (similar
to DECT). There is a Generic Access Profile, which describes the lower layers of
the protocol stack and there are a number of other profiles, which are listed in Table
4. These profiles define protocols and procedures for BlueTooth to implement
different types of applications.




5
    http://www.BlueTooth.com


                                                                          Page 16 of 56
Truck – Trailer                                                               Mikael Gunnarsson
Wireless Connection                                                                  4 Dec. 01




   Profile name                            Description
   Generic Access Profile                  Describes how devices are to behave in
                                           standby and connecting states. It includes
                                           requirements related to discovery, link
                                           establishment and security procedures.
   Service Discovery Application Profile   Defines protocols and procedures that shall be
                                           used to locate services in other BlueTooth-
                                           enabled devices
   Cordless Telephony Profile              Describes how to use the 3-in-1 telephone,
                                           which is a usercase for; A: making calls via a
                                           basestation, B:making direct intercom calls
                                           between      two     terminals,     C:accessing
                                           complementary services provided by a
                                           external network
   Intercom Profile                        Focusing on the inter-com part of the 3-in-1
                                           usercase.
   Serial Port Profile                     Defines requirements for the set up of a
                                           emulated serial cable connection
   Headset Profile                         Requirements for headset devices
   Dial-Up Networking Profile              Defines requirements for the use of BlueTooth
                                           technology in for example modems.
   Fax Profile                             Requirements to send and receive fax message
   LAN Access Profile                      To access a LAN using PPP
   Generic Object Exchange Profile         Base standard for exchanging objects such as
   (GOEP)                                  files via BlueTooth
   Object Push Profile                     Describes usage of the GOEP to send objects
   File transfer Profile                   Usage of GOEP to send files
   Synchronization Profile                 Usage of GOEP for synchronization of for
                                           example a PDA with a laptop
Table 4: BlueTooth profiles

2.2.4 Message format
As mentioned before, interference is reduced by a frequency-hopping scheme. By
switching frequency 1600 times a second every frequency is only used for 625s.
Therefore all transmissions are divided into 625s timeslots. In one timeslot one
unit is allowed to transmit one message. The master device is allowed to send
during even-numbered and the slave(s) at the odd-numbered timeslots. All
BlueTooth messages consist of three entities as shown in Figure 4. The Access
Code and the Header are of fixed size: 72 and 54 bits respectively. The Payload can
range from zero to a maximum of 2745 bits.




Figure 4: BlueTooth message format




                                                                                    Page 17 of 56
Truck – Trailer                                                     Mikael Gunnarsson
Wireless Connection                                                        4 Dec. 01


Access Code
Each packet starts with a access code. This part of the message is used for
synchronization, DC offset compensation and identification. The access code is
divided into three parts:
    - Preamble: Consists of four bits that facilitate DC compensation.
       It is either 1010 or 0101 depending on the following bit.
    - Sync word: A 64-bit code word that is derived from the master’s identity
       code.
    - Trailer: This is another 4-bit word that is appended to the Sync word if there
       is a header following the access code. It is used for extended DC
       compensation.

The Header
The header part of the BlueTooth frame contains link control information. It is built
up of six fields:
    - AM_ADDR: A 3-bit active member (AM) address of the eight member
        piconet network.
    - TYPE: A 4-bit word that tells the kind of message (there are 16 available).
    - FLOW: One bit for the flow control of packets.
    - ARQN: 1-bit acknowledge indication.
    - SEQN: A 1-bit message numbering to filter out retransmissions.
    - HEC: A error check for the header field

The Payload
Packets can be sent between two BlueTooth devices, either synchronously in a
point-to-point link (voice) or asynchronously (data). Depending on the message
type the appearance of the payload varies. Usually they contain data from a higher
layer, a header and error check.

2.2.5 Networking
Unlike other wireless technologies there is no distinction between base stations and
terminals in BlueTooth; every device is identical. As mentioned before, three bits in
the access code section of the data packet represent the address of a unit. This
means that there can be a maximum of eight participants in a BlueTooth network.
When a network is formed one of the participants becomes the master and all others
are considered as slaves. Usually the unit that establishes the first connection
becomes the master, but during the network’s lifetime it is possible for a slave to
switch to take the master’s role. However there is only one master at any time in
each network.

The system clock and the identity of the master are central parts in the frequency
hopping technology. The communication channel is determined by the hop
sequence and by the phase in this sequence. The phase is set by the master’s system
clock and its identity. All connected slaves use their own system clocks together
with an offset to synchronize themselves to the master’s clock.

A BlueTooth network such as the one described above is called a piconet. Different
piconets have different hop sequences and are controlled by different masters.
However in some slots there might be packets sent simultaneously on the same


                                                                         Page 18 of 56
Truck – Trailer                                                       Mikael Gunnarsson
Wireless Connection                                                          4 Dec. 01


frequency by units belonging to different piconets. In these cases the packets
interfere and the data is lost. All piconets are uncoordinated and synchronization
between piconets is not allowed. A BlueTooth unit can in a time-division-
multiplexing (TDM) fashion be participating in several piconets forming a so-called
scatternet. A unit can be the master of only one piconet at the time (and slave in
others). Figure 5 shows examples of a network (scatternet) configuration with a
master (and one slave) that is a member of two Piconets.




Figure 5: A BlueTooth scatternet network
Connection establishments
When a BlueTooth unit isn’t connected to a Piconet it is said to be in a standby
mode. In this state the unit “wakes up” once every 1.28 seconds to listen for paging
messages containing a wake-up sequence. A subset of 32 slots has been chosen
from the 79 available6. During this listening time (which lasts for 18 hops) the unit
compares the access code in received messages with one that is calculated from its
own identity and if they match a connection-setup procedure is started.

The paging procedure assumes that the unit that is connecting to the one in standby
mode knows that unit’s identity and preferably its native clock. If that is not the
case an inquiry procedure takes place. The paging unit then transmits an inquiry-
access code, which is common to all BlueTooth units. If a unit in standby mode
receives this message it replies with its identity and clock. After the master receives
info about all units within range it (after a selecting process) sends paging messages
to those units to which a connection is wanted. After the paging procedure has
occurred, the newly formed piconet is kept alive by the frequency hopping sequence
described earlier.

There can be additional slaves that don’t have an active member address
synchronized to a specific piconet; they are in a “parking mode”. A piconet can
have a maximum of 256 slaves parked, which can become active very quickly
(because there is no need for paging / inquiry) and begin to communicate in the
piconet.



6
    In France and Spain the subset consists of 16 carriers.


                                                                           Page 19 of 56
Truck – Trailer                                                     Mikael Gunnarsson
Wireless Connection                                                        4 Dec. 01


2.2.6 Data transfer speed
Links between two BlueTooth units can be established in two ways. Either an
Asynchronous Connectionless (ACL) or a Synchronous Connection Oriented
(SCO) connection type is made. The SCO links provides circuit-switched point-to-
point connection mostly used for voice traffic. The data rate for a SCO link is 64
kbps. ACL links are used for data transmission with mainly packet-switched point-
to- point (or multipoint) connections. An ACL link can provide a data rate of 721
kbps in one direction and 57.6 kbps in the other (if there is no error correction).

2.2.7 Comments
There are products already on the market that makes it possible to send CAN
messages via BlueTooth between two physically separate CAN buses. An example
of such a product is WAVEcan from Kvaser AB7. However WAVEcan is not
suitable as a part of the system in this project. As mentioned earlier the goal is to
develop a link, which makes it possible to send other data in parallel with the CAN
messages. WAVEcan only has one CAN interface providing a maximum transfer
speed of 125 kbps. It doesn’t provide for example a serial interface (RS232) or
similar interface. If one were to send other data in parallel (without encapsulating
them in a CAN message, thus having one more CAN controller to do that) to the
truck from the trailer this could be solved with other wireless technologies (or more
BlueTooth units) but in this project a single point-to-point link is desired only for
communication to and from the trailer.

BlueTooth might be a very good solution to this project. The BlueTooth units are
low-cost and have low power consuming. A couple of things that might be a
problem are the range of 10 meters and the different frequencies in some countries.
But it will probably not be long before units with a transmit power of 100 mW are
available making the link more insensitive for interference within short range.


2.3 Other technologies
BlueTooth and DECT have been chosen as candidate technologies in this project
due to reasons such as worldwide usability, low-cost, the current system constraints,
and desires from Scania Infotronics mentioned earlier in the project goal, Chapter 1.
To decide which of them that is going to be used, a further look into these two
standards needs to be made. Besides these two technologies there are other wireless
solutions available today. For various reasons they have been discharged in an early
stage of the pre-study phase.

Wireless Local Area Networks known as WLAN’s are widely used. They provide
possibilities to for example connect to the company network at a speed of 11Mbps.
WLAN devices are available as both PCMCIA and Compact Flash cards thus they
can easily be put into a PDA such as the Cassiopeia. If one were to use a WLAN
card directly in the Cassiopeia there could of course be a simpler hardware system
in the truck. There would be no need for attaching the PDA to the vehicle (other
than for power supply). On the other hand the software would have to be altered to
support collecting of data from the CAN bus thru the WLAN card. There would

7
    http://www.kvaser.se


                                                                         Page 20 of 56
Truck – Trailer                                                       Mikael Gunnarsson
Wireless Connection                                                          4 Dec. 01


also be need of some kind of basestation and two other clients sending data from the
two CAN buses located in the truck and the trailer.

This project’s focus in on the sending of CAN messages via a wireless connection.
What hardware that is to be connected to the CAN bus or what kind of computer
should display the information to the driver are not of significance. The link should
be of use to any CAN system regardless of the choice of hardware that is attached
to the CAN busses. Scania Infotronics has no interest in having a CAN bus
connected directly to the Cassiopeia via the cards mentioned above. The gateway is
supposed to be a standalone device and not dependent on what device that are
presenting data in the truck.

There are other technologies similar to 802.11 WLAN (Hyper LAN8 and HomeRF9)
but they are not suitable for the same reasons as with WLAN.

Another wireless technology worth mentioning is IrDA10. It is a standard that
provides wireless data transfer using infrared radiation. In this project one can skip
any thought of using IrDA regardless of its capabilities because IrDA needs a direct
“line of sight” between sender and receiver and this may not exist between the truck
and the trailer.


2.4 DECT vs. BlueTooth
To compare DECT and BlueTooth there are a number of different aspects to
consider. They have different frequency bands, channel allocations, and methods to
prevent interference. The identification and authorization methods are also
different. Other things to consider are costs and availability. In addition the project
only lasts for 20 weeks and there is much to be done in that time.

2.4.1 Air Interface
Today BlueTooth products have a transmit power that gives a range of 10 meters.
That is much shorter than DECT, which has a range of 50 meters indoors and 300
meters outdoors (with no buildings or walls to penetrate). However, there are
expected to be BlueTooth products with a higher transmitting power available,
which gives a range of 100 meters.

BlueTooth uses the ISM band and has to cope with interference from many other
sources such as Wireless LAN’s, garage door openers and, even microwave ovens.
DECT uses a frequency band that is devoted to DECT units. In BlueTooth’s
defense one should mention the frequency hopping principle that BlueTooth uses.
By continuously switching between different frequencies, interference from another
transmitting device only interfere a fraction of the time. DECT has another
approach, it only switches channel if needed. In a situation in which there are no
other DECT units within range there is much less need for DECT to prevent
interference because of the frequency band that DECT alone uses.

8
  http://www.etsi.org
9
  http://www.homerf.org
10
   http://www.irda.org


                                                                           Page 21 of 56
Truck – Trailer                                                        Mikael Gunnarsson
Wireless Connection                                                           4 Dec. 01




2.4.2 Identification and authorization
Within this area and the “unknown trailer” scenario described in the following
paragraph, BlueTooth is more suited than DECT. DECT is a better choice when it
comes to a network that has known identities of the participants and when these
don’t change very often.

Consider the following scenario:

    1. A driver wants to connect his truck to one of three trailers that are
       parked beside each other. He doesn’t have a list of identities with him;
       this is the “unknown trailer” case. The difficulty now is to get access
       to the transceiver in the right trailer and to separate the transceivers
       in the trailers from each other.

    2. Upon connection the truck has to be “locked” to the chosen trailer. If
       for example he pulls up next to another trailer at a stop sign that has a
       similar system, these two must not be able to connect to each other in
       any way. The trailer must not allow a second truck to get access to
       data and the truck must not mistake the other trailer for its own.

Keeping the session intact from other systems can always be solved with software.
What needs to be considered is how we can communicate with the “unknown
trailer”. In DECT the fixed part (located in the truck) has a list of identities of those
trucks that are allowed to connect. One cannot ask a device for its address through
the air. In BlueTooth, by using the inquiry – page procedure it makes it possible for
the driver to get a list of all trailers within range and then using an interface on for
example the Casio Cassiopeia, located in the truck, can chose one of them. Of
course the driver needs to know which identity number to use. Possible a
microcontroller in the trailer could be programmed to present the license plate or ID
number of the trailer, but that is a matter of software development.

What differs in this case is how new identifications are made.

2.4.3 World coverage
DECT and BlueTooth use different frequency bands. To choose technology one has
to take into consideration what frequencies are allowed in which countries.

BlueTooth has a narrower frequency band in Spain, France, and Japan. This means
that there is no compatibility between those units and the ones used for example in
Sweden. One cannot travel into Spain with BlueTooth units that use 79 slot
hopping.

DECT on the other hand is a European standard valid thru all of Europe and most of
the world except North America.

2.4.4 Capabilities
When it comes to data transfer rates there is not a significant difference between
DECT and BlueTooth. BlueTooth has a maximum data transfer rate of ~720 kbps in


                                                                            Page 22 of 56
Truck – Trailer                                                      Mikael Gunnarsson
Wireless Connection                                                         4 Dec. 01


one direction with no error correction and DECT has a maximum data transfer rate
of ~550 kbps with error correction. The DECT modules looked at during this
project only support ~100 kbps via a serial interface.

2.4.5 Costs and availability
This Chapter was added to give Scania Infotronics some examples of available
development kits.

DECT
Two companies providing DECT modules and development kits have been
contacted: Höft & Wessel11(H&W) in Germany and Inventel12 in France.

H&W has a development kit containing 2 DECT modules and the hardware and
software needed to set up and configure the modules. The modules can be used both
as fixed and portable parts and they support Data Service Profiles A.1/B.1 and C.2.
It has a maximum data transfer rate of 104 kbps thru a RS232 serial interface. The
DECT protocol stack is completely implemented and "ready-for-use" in the H&W
DECT module so normally there is no need for further software implementation.
The price for the evaluation kit is 7500 SEK and supplementary unit costs 500 –
900 SEK depending on volume.

Inventel’s DECT modules are not as predefined as H&W’s. They support the
Generic Access Profile and due to this RS232 serial interface they have a maximum
transfer rate of 115 kbps. Another thing that differs from H&W’s product is that the
fixed and portable parts are not identical units; they are two different products. The
price for Inventel’s evaluation kit is 20000 SEK and each supplementary unit cost
2500 SEK.

BlueTooth
Two companies providing BlueTooth modules and development kits have been
contacted; Inventel13 in France and Teleca Comtec14 in Sweden. Teleca Comtec are
distributors of Ericsson BlueTooth Application Tool Kit. This evaluation kit
contains one BlueTooth 1.0B module with RF output power class 2 (~10 meter
range) and the software and hardware needed to understand and test the theory and
applications of BlueTooth short-range radio communication. This development kit
costs 12500 SEK (there is a student offer for 5000 SEK). As there is only one
BlueTooth module in each kit one must buy two kits to have a wireless link.

Inventel also has a BlueTooth development kit. This BlueTooth module differs in
three main areas.
     The module supports the BlueTooth 1.1 standard
     It has RF output power class 1 (~100 meter range)
     It supports multipoint operation (a master is capable of sending messages to
       more than one slave without having to broadcast the message)

11
   http://www.hoeft-wessel.com
12
   http://www.inventel.com
13
   http://www.inventel.com
14
   http://www.comtec.teleca.se


                                                                          Page 23 of 56
Truck – Trailer                                                    Mikael Gunnarsson
Wireless Connection                                                       4 Dec. 01


The cost for this development kit is 20000 SEK and each supplementary unit cost
1700 SEK.

It is hard to say which offer is best. While one can look into the specification of
each module (within each technology) the aspects such as support, documentation,
and usefulness of the included software are also important. There isn’t much info on
these aspects on any of their websites and thus my choice must be based on
intuition and the reputation of the company in question. Following are links to the
web pages that contain each offers (accessed 2001-09-24)

DECT- Höft & Wessel
The DECT module: http://www.hoeft-wessel.com/inhalt/en/comsys/86010.htm
The development kit: http://www.hoeft-wessel.com/inhalt/en/comsys/kit.htm

Inventel
The DECT module: http://www.inventel.com/dect_modules.html
The BlueTooth module: http://www.inventel.com/blue_modules.html
The development kits are not found on their web site.

Teleca Comtec
The BlueTooth products: http://www.comtec.teleca.se/products.asp


The Ericsson Application and Training Toolkit was chosen and bought from Teleca
Comtec




                                                                        Page 24 of 56
Truck – Trailer                                                      Mikael Gunnarsson
Wireless Connection                                                         4 Dec. 01



        3 Controller Area Network

During the late 1970´s technical solutions began to provide communication between
different elements of advanced vehicle systems. Anti lock braking systems, engine
management systems, traction control, air conditioning control, central door
locking, and powered seat and mirror controls are just some examples of features in
a vehicle that need to exchange information with sensors of different types.

In the early 1980s the Robert Bosch company provided a solution that later become
a standard to be used in the kind of systems mentioned above. The system was
named CAN [19], and is short for Control Area Network. The CAN protocol has
grown into a worldwide technique used in areas besides the vehicle industry. CAN
controllers are used in various systems such as elevator controls, navigation
systems, and medical equipment. The list below shows some of the important
milestones in the CAN development history.

        1982: Bosch starts the development of the CAN – bus
        1985: Intel joins the project.
        1986: The first CAN standard is published
        1987: The first working products appear
        1988: CAN chips available on the market
        1990s: Mercedes, Scania, and Volvo start using the CAN standard


3.1 Introduction
A CAN bus consists (in a simplified form) of two wires that runs through the
relevant parts of a vehicle. Messages are sent in a broadcast fashion, which means
that all connected devices receive all messages sent. A message that is to be sent
between two specific connection nodes via these wires doesn’t contain a destination
address, but rather utilizes a message identifier unique to this type of message. This
makes it possible for a self-selective number of receivers to pick up the message
(this technique is similar to multi-cast). Each node receives the message and checks
the identifier to see if the message is relevant for them. This makes it very easy to
add new nodes that are purely receivers. No further adjustment to the existing
system has to be made since these nodes are simply passive receivers. This makes
possible many new information logging and viewing applications.

3.2 General principles
As mentioned earlier a CAN bus consists of two wires. One of them is called
CAN_high and the other CAN_low. Information is sent by changing the voltage
levels on these wires and measuring the potential difference. A logical dominant bit
is sent by setting the level on CAN_high to high and CAN_low to low. A logically
recessive bit is sent by setting CAN_high to low and CAN_low to high. When the
bus is idle it will constantly be recessive. To make the bus more insensitive towards
electrical interference the two wires should be a twisted pair.




                                                                          Page 25 of 56
Truck – Trailer                                                        Mikael Gunnarsson
Wireless Connection                                                           4 Dec. 01


3.2.1 Message formats
CAN uses four different kinds of messages that have a maximum payload of 94
bits. The messages are sent by non-return to zero encoding with bit stuffing. Bit
stuffing is used to prevent any unwanted DC components on the link; an extra
recessive bit is added after five consecutive dominant bits has been transmitted. The
four types of messages are Data, Error, Remote and Overload frames. The CAN
supports two message frame formats, their differences are explained following a
general explanation of the kinds of messages.

Data frame
This is the mostly used type of message and it is divided into four major parts
(Figure 6).
    - The Arbitration field that holds the identifier (and priority, to be discussed
       later). The size of this field is 11 or 29 bits depending on the standard used,
       i.e., CAN 2.0A or CAN 2.0B.
    - The Data & Control fields hold a maximum of eight bytes of data together
       with three bits containing the size of the data and two bits of information
       about the message format.
    - The CRC field, which contains a 15-bit checksum.
    - The Acknowledgement bit. Every connection node that has received the
       message successfully sets this bit to one so that the transmitter can see that
       at least one has received the message and therefore it need not perform a
       retransmission.

  Arbitration              Control                 Data             CRC Field
   Identifier, 11   Number      Type of     Data, 0 to 8 bytes         CRC       Ack,
     or 29 bits     of bytes,   message,                             checksum,   1bit
                      3bits      2bits                                 15bits


Figure 6: CAN Data frame
Remote frame
The remote frame is a kind of request – response frame. It could for example be
used to request the data frame described above. The frame looks exactly like the
data frame except that the data field only contains the size of the requested frame.
Remote frames are rarely used in real implementations.

The Error frame
The Error frame is used when a node detects a fault and wants to make all other
nodes aware of this fault in order that the transmitting node will retransmit the
message. This frame consists of an error flag, which is 6 bits of the same value
(thus violating the bit-stuffing rule) and an error delimiter, which is 8 recessive bits.
The error delimiter provides some space for other nodes to also send an error flag
upon detecting the first error frame being sent.



3.2.2 Extended CAN
There are two different formats of CAN messages defined. CAN 2.0A (known as
Standard CAN) and CAN 2.0B (Extended CAN). The difference between these is
that 2.0A uses an arbitration field of 11 bits whilst 2.0B has 29 bits. The CAN 2.0B


                                                                             Page 26 of 56
Truck – Trailer                                                      Mikael Gunnarsson
Wireless Connection                                                         4 Dec. 01


standard therefore has a payload maximum of 112 bits. A bit in the control field is
used to determine the format of a specific message. CAN controllers using the 2.0B
can be configured to send 2.0A messages if there are controllers connected to the
bus that doesn’t support 2.0B.

3.2.3 Arbitration
The nodes of the CAN bus are connected in a logical AND fashion. The dominant
bit corresponds to a logical bit-value of zero and the recessive bit equals one. This
means that if a node is sending a recessive bit and another node tries to send a
dominant bit the bus will turn dominant. This is used to avoid collisions and to
achieve priority between the nodes that are trying to access the bus.

CAN use a technique called Carrier Sense Multiple Access with Collision Detection
and Arbitration on Message Priority (CSMA/CD + AMP). The arbitration occurs
bitwise. When a node wants to send a message it starts by listening if the bus is idle
and if so, it will start the transmission. This might lead to a situation when two
nodes start their transmission at the same time. This is avoided by bitwise
arbitration. While a node is transmitting it also listens to the bus. If the bus turns
dominant while the node is sending a recessive bit (because of the AND function
described earlier) the node will cancel its transmission and try again when the bus is
idle. The message already on the bus will not be interfered with by this node’s
message again because of the AND function.

The identifier in the Arbitration field determines the priorities of the messages. The
identity bits are sent first in a message and because of the arbitration on message
priority the message with the lowest identifier number will be transmitted first.
Whilst in other technologies all messages are cancelled in case of a bus access
conflict. But in this case the message already on the bus will not be destroyed. This
improves the real-time aspects of message delivery.




Figure 7: CAN message priority
In Figure 7 [19] node number 2 wins the competition for the bus. Node number 1
and 3 lose at the 7th and 3rd bit respectively. When a node loses it automatically
becomes a receiver for the message that gains access to the bus. Again it is worth
mentioning that there is no time lost because there is no need for re-transmission.



                                                                          Page 27 of 56
Truck – Trailer                                                      Mikael Gunnarsson
Wireless Connection                                                         4 Dec. 01


3.2.4 Bit timing
Each data bit on the bus is divided into four segments. Each of the segments is
divided into a number of time quanta. The four different segments are:

       Synchronization Segment
       Propagation Segment
       Phase Segment 1
       Phase Segment 2

The synchronization segment is used for synchronization of the clocks.
The propagation segment is needed to compensate for bus delay.
The sampling point is decided by setting the split point between the phase segments
(Figure 8).




Figure 8: CAN bit timing calculation
The environment in which CAN is used often demand high robustness and the
consequences of system failure can be grave. There is elaborate error handling built
into the CAN protocol, both when it comes to error detection and discovering the
point of failure.




3.3.1 Error types
There are five different types of errors defined:
   - Bit error: When a node transmits a bit it also listens to see if the value on the
       bus is the same as the one that is being transmitted. This is not done during
       the arbitration process.
   - Bit stuffing error: As mentioned earlier, if five bits with the same value are
       to be transmitted, then an extra bit with the opposite value will be added to
       avoid DC components on the bus. If six successive bits with the same value
       are discovered on the bus then a bit stuffing error is generated.
   - Frame check error: Some of the fields in a message never change, i.e. the
       standard defines exactly what levels must occur and when. If these rules are
       violated a frame check error is generated.
   - ACKnowlegement error: If the transmitting node discovers that no other
       node has set the acknowledgement bit recessive an ACK error is generated.
   - Cyclic Redundancy Check (CRC): Each message contains a CRC
       checksum, which is a number mathematically calculated from the bits in the
       message. If the receiver calculates a number different than the one stated in
       the message a CRC error is generated.



                                                                          Page 28 of 56
Truck – Trailer                                                        Mikael Gunnarsson
Wireless Connection                                                           4 Dec. 01


3.3.2 Controller modes
To discover errors in the transmitted messages is not enough to make a robust
system. There must be some kind of mechanism to trace the source, which
generated the error. In the CAN protocol this is done by two counters integrated in
all controllers (nodes). If a controller discovers an error it will send out an error
message on the bus, thus destroying the message currently on the bus. All the other
nodes will then also (if they haven’t already) discover the error and also send out an
error message.

Every controller contains two counters; the Receive Error Counter (REC), which is
for error messages received and the Transmit Error Counter (TEC), which is for
those sent. If a controller receives an error message it will increment it’s REC by
one and if the controller as a transmitter detects a fault the TEC will be incremented
by eight. This is because there is a large possibility that the controller in question is
causing the failure. There are three different error states (modes) that the controllers
can be in: Error Active, Error Passive and Bus Off mode.

Error Active mode
If a controller while in “normal” mode detects an error and increments one of its
counters it will go into error active mode. If it receives error-free messages the
relevant counter will decrement and if more error messages are received it will
increment to a maximum of 127. This mode takes care of temporary faults.

Error Passive mode
When the TEC exceeds 127 the controller will go into error passive mode. The error
messages sent by this controller differ from the “normal” messages and it will not
destroy any message currently on the bus. Other controllers will receive the error
message and increment their REC by one. Long before their REC counter exceeds
127 this controller will go into the bus off mode and their counters will start
decrementing.

Bus Off mode
In this mode either of the counters has exceeded a value of 255 and the controller
will stop all communication. It will no longer be active on the bus and all other
controllers can continue without interference. The controller will go back to normal
mode after some kind of hardware or software reset. Figure 9 shows the different
modes along with conditions for mode switching.




Figure 9: State diagram of the CAN controllers



                                                                            Page 29 of 56
Truck – Trailer                                                    Mikael Gunnarsson
Wireless Connection                                                       4 Dec. 01


3.3 Standards
Amongst the available standards this thesis will focus on J1939, which is the
standard used by Scania in their trucks, and ISO 11992. ISO 11992 is a relatively
new standard used in trailers. There are two major differences between these two
standards. One is the voltage level and the other is the rate at which data is
transmitted. Both of these standards use the CAN 2.0B (extended CAN) message
format.

3.3.1 SAE J1939
A CAN bus that follows the J1939 standard [18] has a maximum data rate of 250
kbps. Below are the voltage levels for a recessive and a dominant bit displayed.

               Dominant bit                           Recessive bit
             CAN_H >> CAN_L                         CAN_H < CAN_L
             CAN_H = 3.5 V                          CAN_H = 2 - 3 V
             CAN_L = 1.5 V                          CAN_L = 2 - 3 V
              Vdiff  =2V                             Vdiff   =0V




3.3.2 ISO 11992
The ISO 11992 standard [16] uses a maximum data rate of 125 kbps on the bus.
The voltage levels are higher. ISO 11992 is supposed to be used in tougher
environments with more interference and longer wires. Below are the voltage levels
for a recessive and a dominant bit for the ISO 11992 standard. Vs can be 12V or
24V depending on the environment.


               Dominant bit                           Recessive bit
              CAN_H = 2/3 Vs                         CAN_H = 1/3 Vs
              CAN_L = 1/3 Vs                         CAN_L = 2/3 Vs
              Vdiff = -1/3 Vs                        Vdiff  = 1/3 Vs


3.4 Networking
Both the J1939 and the ISO 11992 standards use a 29bit identifier. The identifier is
divided into three major parts; Priority, Parameter Group Number (PGN) and
Source-Id. These standards also contain tables of the PGN assignments and
parameter specifications of different messages. Following are short descriptions of
each of the identifier fields.


Priority
The first three bits are priority bits. There are eight priority levels. Due to the
bitwise arbitration procedure described earlier the highest priority is 0 and the
lowest is 7. After these three bits there are two bits reserved for future use.




                                                                        Page 30 of 56
Truck – Trailer                                                      Mikael Gunnarsson
Wireless Connection                                                         4 Dec. 01


Parameter Group Number
The parameter group number is two bytes long and divided into two parts. The first
byte is called PDU format (PF) and identifies a specific group of data. The second
byte is called PDU specific (PS) and depends on the PDU format. It can together
with the first byte identify one specific type of information intended for a specific
destination or it can be a group extension.

Source-Id
The source-id represents the identity of a specific device. It is one byte long and a
CAN bus is therefore not able to have more than 28 = 256 different devices
attached.


3.5 CAN Gateways
The CAN gateways have two major purposes. One of them is to gateway CAN
messages between two CAN buses. The messages can be filtered to keep the two
buses from interfering with, and to reduce the load that they place on each other.
Another reason to use a gateway is to make it possible to have a larger range
between the different devices that needs to exchange CAN messages. As described
in Chapter 3.2 arbitration is made bitwise and this means that every bit that is sent
out on the bus must reach every connected node before the next bit is sent. Due to
this a CAN bus has a maximum length and/or data transfer rate. The longer the bus
is the lower the transfer speed has to be in order for the signal to reach every node.
If two devices that are placed far from each other needs to exchange messages one
can have these on two separate CAN buses and have two gateways between them
using a high speed link to connect these gateways. Further information on high-
speed links between CAN buses and extending CAN networks can be found in a
paper written by George Thomas[15].

3.5.1 Address Assignment
A road train consists of one commercial vehicle and one or more towed vehicle(s).
Dolly axles within the road train are treated as towed vehicles as well (see Figure
10). A problem arises if there for example is two identical alarm units connected to
two different CAN buses (they can’t be connected to the same bus because every
unit on a bus has to be unique). They both have the same source-id and send the
same kind of data, thus having the same PGN. If there is one of these alarm units
placed in each of the towed vehicles in Figure 10 there is no way that a device
located in the commercial vehicle analyzing alarm messages could know from
which of them a message originated. A salvation to this problem is found in the
ISO11992 standard. In the following explanation the commercial vehicle is called
“the truck” and the towed vehicles are called “trailer A”, ”trailer B” and so on.




                                                                          Page 31 of 56
Truck – Trailer                                                           Mikael Gunnarsson
Wireless Connection                                                              4 Dec. 01




Figure 10: Road train
Every vehicle whether it is towed or not has a source-id that represents the whole
vehicle. Consider the problem described above with two identical alarm units. One
of them is placed in trailer A and the other in trailer B. When the message from the
alarm unit in trailer B passes through a gateway, thus leaving the vehicle it changes
source-id to the id that represents the vehicle. Every receiving unit in another
vehicle then knows from which vehicle the message originated. The source-id for
each vehicle is shown in Table 5 (taken from the ISO11992 standard).

   Name                       Address      Predecessor             Successor
   Commercial vehicle         235 = EB16   Undefined               Towed vehicle pos. #1
   (position #0)
   Towed vehicle pos. #1      201 = C916   Commercial vehicle      Towed vehicle pos. #2
   Towed vehicle pos. #2      193 = C116   Towed vehicle pos. #1   Towed vehicle pos. #3
   Towed vehicle pos. #3      185 = B916   Towed vehicle pos. #2   Towed vehicle pos. #4
   Towed vehicle pos. #4      177 = B116   Towed vehicle pos. #3   Towed vehicle pos. #5
   Towed vehicle pos. #5      169 = A916   Towed vehicle pos. #4   Undefined
   Global dest. address       255 = FF16   Undefined               Undefined
Table 5: Source ID's in a road train


To make the gateway dynamically adjust the source-id on the forwarded message it
has to know where in the road train it is located. If there is a gateway connected to
the bus in the truck the ISO 11992 standard says that there must be an identity
message sent on the bus every 100ms. This message tells the gateway that the bus
that it came from is the bus located in the truck. The gateway then sends a message
backwards in the road train telling everyone connected to the bus in trailer A that
this is the bus located in trailer A. This procedure is then repeated throughout the
whole road train.




                                                                                Page 32 of 56
Truck – Trailer                                                                                        Mikael Gunnarsson
Wireless Connection                                                                                           4 Dec. 01



      4 Prototype development

This part of the report describes the development of a prototype. The reason for
building a prototype is to show Scania Infotronics that the chosen technology is
capable of meeting their requirements on a wireless truck – trailer gateway and to
get a feeling for the potential and limitations of the BlueTooth technology.

The prototype is basically a gateway that uses BlueTooth technology to connect two
physically separate CAN buses. One bus is located in the truck and one is located in
the trailer. The gateway is configured to only let certain types of CAN messages
pass. The reason for doing so is to reduce the load on the CAN bus. Figure 11
shows an overview of the system. Its separate parts are described in Chapter 4.1 to
4.3.


                          RS232
                         Interface                                                        Rs232
                                                                                        Interface
                                            Bluetooth module   Bluetooth module




                                     Fujitsu Microprocessor    Fujitsu Microprocessor


                         CAN bus                                            CAN bus



Figure 11: Prototype system overview
When talking about a BlueTooth system the BlueTooth module is called a Host
Controller and the device that controls the BlueTooth module is called a Host. The
Host can be a microcontroller or a PC and in this project it is the microcontroller
described in Chapter 4.2. As mentioned earlier, this project uses the BlueTooth
Application and Training Toolkit from Ericsson. The hardware consists of a circuit
board (shown in Figure 12) and cables for data transmission. The software consists
of a CD with documentation and the BlueTooth specification. The Host has two
connectors for sending/receiving data. These are a Universal Serial Bus (USB) and
a RS232 serial interface (UART). This project uses the RS232 interface.
                                                                  Antenna
     UART - connector


                                                                                                    BlueTooth module


                                                                                        Power connector &
     USB - connector                                                                    jumper area
Figure 12: BlueTooth module from Ericsson
The common protocol between the Host and the Host Controller is called Host
Controller Interface (HCI) and is described in the BlueTooth Specification. The
HCI has guidelines of how to compose command and data packets. It also tells us
how to read the event packets received from the Host Controller.




                                                                                                            Page 33 of 56
Truck – Trailer                                                   Mikael Gunnarsson
Wireless Connection                                                      4 Dec. 01


Most of the work is focused on the implementation of a chosen subset of the HCI
and how to control the link through CAN messages. The protocol stack and
example applications that were received with the BlueTooth development kit are
Windows compatible versions and are not used in this project. Information on how
the BlueTooth module works is instead taken from documentation delivered with
the development kit and the BlueTooth Specification Version 1.1.

        In the following Chapters the assumed reader is expected to have some
        knowledge in programming (ANSI C), hexadecimal representation of
        numbers, and data communication at byte level.

4.1 BlueTooth module

4.1.1 Packet types
Information between the Host and the Host Controller is sent in packets. There are
three main types of packets: data packets, command packets, and event packets.
There are two kinds of data packets, (asynchronous (ACL) and synchronous (SCI))
and they can be sent in both directions between the host and the Host Controller.
Command packets are sent from the Host to the Host controller and event packets
are sent the other way as replies to command packets. Every packet starts with
information (one byte) that tells the receiver which type of information the packet
holds. The packet types and their corresponding heading byte are shown in Table 6.

                  HCI packet type         HCI packet indicator
                  HCI Command packet      0x01
                  HCI ACL Data packet     0x02
                  HCI SCI Data packet     0x03
                  HCI Event packet        0x04
Table 6: HCI packet types

4.1.2 HCI Command Packets
An HCI Command packet consists of three major parts: a Command code
(OpCode), Parameter Total Length (PTL), and the parameters themselves (see
Figure 13). By reading the OpCode the host (according to the HCI protocol) knows
the length of every parameter.




Figure 13: HCI Command Packet message format




                                                                       Page 34 of 56
Truck – Trailer                                                      Mikael Gunnarsson
Wireless Connection                                                         4 Dec. 01


The OpCode

An HCI Command packet starts with the OpCode, which is a combination of a 6-bit
OpCode Group Field (OGF) and a 10-bit OpCode Command Field (OCF). The
OGF is used to group different commands together and the OCF is (together with
the OGF) one specific command. For example an OGF that is 0x01 tells us that this
is a Link Control Command. Almost all information containing more than one byte
is sent in Little Endian format. This means that the least significant byte (LSB) is
the first in a string of bytes and the most significant byte (MSB) is sent last. Since
the OpCode is two bytes long, it has the least significant byte represented first. The
easiest way to explain the creation of an OpCode is to give an example:

The OpCode HCI_Create_Connection has OGF = 0x01 and OCF = 0x0005. The
first 6 bits are the OGF and the remaining 10 bits are the OCF. Due to the fact that
the OCF has 10 bits one cannot just combine these two into the OpCode 0x0105.
The OGF has to be bit-shifted two bits to the left before adding the OCF. The
OpCode sent to the Host (in hex) is therefore (LSB first) 05 04.

UART Speed settings

The default speed setting for the UART is 57.6 kb/s and can be changed by sending
the command HCI_Ericsson_Set_Baud_Rate. This command is not a part of the
original BlueTooth specification, it is in a group of commands, which are called
Ericsson specific commands and have the OGF 0x3F, which is referred to as
Vendor specific debug commands in the BlueTooth specification. The OCF for the
UART speed is 0x09 and the parameter is a one-byte number that corresponds for a
certain UART speed. A table of various speed settings is shown in Table 7 below.
The parameter values are in binary format.

                       UART speed         Parameter to send
                       460.8 kbps         00000000
                       230.4 kbps         00000001
                       115.2 kbps         00000010
                       57.6 kbps          00000011
                       28.8 kbps          00000100
                       14.4 kbps          00000101
                       7200 bps           00000110
                       3600 bps           00000111
                       1800 bps           00001000
                       900 bps            00001001
                       153.6 kbps         00010000
                       76.8 kbps          00010001
                       38.4 kbps          00010010
                       19.2 kbps          00010011
                       9600 bps           00010100
                       4800 bps           00010101
                       2400 bps           00010110
                       1200 bps           00010111
                       600 bps            00011000
                       300 bps            00011001
Table 7: UART speed setting




                                                                          Page 35 of 56
Truck – Trailer                                                      Mikael Gunnarsson
Wireless Connection                                                         4 Dec. 01


4.1.3 HCI Event Packets

The HCI Event Packet is used by the Host Controller to send information to its
Host. These events can for example be the termination of a connection or various
error occurrences. Events are also sent as answers to commands. During execution
of a command a HCI_Status_Event is sometimes sent and after every command has
been sent and executed a HCI_Command_Complete_Event is sent as a notification
to the host. Like the command packets the event packets consists of three major
parts: the Event Code, the Parameter Total Length, and the parameters themselves.

In the BlueTooth Specification Version 1.1 page 550 to 780, together with the
description of all available HCI commands there is a list of the possible events that
can be generated while executing a particular command and a list of events
containing error codes.

4.1.4 Initialization
An initialization must be performed after power on or after performing hardware
reset on the BlueTooth module. This is simply a set of commands to read and to
change the settings in the module. All settings are returned to default values after
reset. Although most of these are as required at default, there still are some changes
that must be made before it is possible to create a connection. The initialization
used in this project is based on suggested settings found in the Getting Started
folder delivered with the development kit. Depending on what functionality that is
being used there are different requirements on the initialization but the three
commands described below form some sort of minimum requirement to make the
BlueTooth module operational.

1. HCI_Reset, BlueTooth Specification Version 1.1 page 622; The first
   command that has to be sent to the Host Controller is HCI_Reset. This is used
   to synchronize so that the Host Controller reads bits correctly. If the Host or the
   Host Controller loses synchronization in the communication via RS232, then a
   reset is needed. A loss of synchronization in this case means that an incorrect
   HCI packet indicator has been detected, or that the length field in an HCI packet
   is out of range. If the synchronization is lost the Host Controller sends a
   Hardware Error Event to inform the Host about this. The Host Controller then
   expects an HCI_Reset command in order to perform a reset to re-synchronize.
   The Baudrate set by the HCI_Ericsson_Set_Baud_Rate command is maintained
   during software reset

2. HCI_Set_Event_Filter, BlueTooth Specification Version 1.1 page 623; This
   command is used by the Host to specify different event filters. It can be used to
   filter inquiries from other modules so that the Host Controller only responds to
   specified addresses or to a specific Class of Device. This command is also used
   to auto accept connection requests, either from any other device or according to
   a specified filter.

3. HCI_Write_Scan_Enable, BlueTooth Specification Version 1.1 page 647;
   This is one of the more important commands during the initialization and should
   always be executed as the last command of the initialization. The parameters of


                                                                          Page 36 of 56
Truck – Trailer                                                      Mikael Gunnarsson
Wireless Connection                                                         4 Dec. 01


    this command controls whether or not the BlueTooth module will periodically
    scan for page attempts and/or inquiry requests from other BlueTooth modules.
    The module could be set to respond on either Inquiries or Page Scan, both or not
    respond at all. The default configuration is to not respond on any request, since
    the device should wait until after the initialization to announce its existence.

Table 8 below shows a hex dump of the initialization procedure. A number noted
with a means in direction Host to Host Controller and b means Host Controller to
Host. The bytes returned are HCI_Command_Complete_Events. Again it should be
mentioned that the first byte is a packet type indicator.

                            Bytes sent             HCI command
              1a      01 03 0C 00            HCI_Reset
              1b      04 0E 04 01 03 0C 00
              2a      01 05 0C 03 02 00 02   HCI_Set_Event_Filter
              2b      04 0E 04 01 05 0C 00
              3a      01 1A 0C 01 03         HCI_Write_Scan_Enable
              3b      04 0E 04 01 1A 0C 00
Table 8: Hex dump from initialization

4.1.5 Inquiry
After the initialization has been completed, the Host Controller is ready to establish
a connection to another BlueTooth module. A search for nearby BlueTooth devices
has to be made if the certain address is unknown. This is made by the command
HCI_Inquiry that puts the Host Controller in the inquiry mode. During the inquiry
the requesting device transmits an inquiry request on a number of predefined
frequencies, which other devices periodically scan and responds with their unique
48-bit address (BD_ADDR) and their clock offset. The requesting Host Controller
reports all inquiry responses to the Host to notify about the discovery if they aren’t
masked away with an event filter. After the inquiry has finished the Host Controller
sends an Inquiry_Complete_Event to the Host where the total number of inquiry
responds is included as a parameter in the event. More than one discovered device
could be combined and reported in the same event. Since an inquiry can last for
about one minute it is possible to cancel the inquiry by sending the command
HCI_Inquiry_Cancel to the Host Controller to abort the inquiry operation.

4.1.6 Create connection
A new connection is established by using the command HCI_Create_Connection.
The command causes the local BlueTooth device to begin the Page process to create
a link level connection, called an ACL connection. The parameters for this
command are the 48-bit address called the BD_ADDR to the device to which the
connection is to be established, the packet type, which can be multiple by
performing bit-wise OR operation of the different packet types. The next three
parameters, Page_Scan_Repetition_Mode, Page_Scan_Mode and Clock_Offset,
were discovered from the inquiry response, and are used to inform the local Host
Controller the necessary information to set up a connection. The Clock_Offset is not
of huge importance for the creation of the connection but the process will be made
faster when the local Host Controller knows which frequency the remote device is
paging on at that time. The last parameter determines whether the other device may
become master or not. A Connection Complete event is generated on both local and


                                                                          Page 37 of 56
Truck – Trailer                                                       Mikael Gunnarsson
Wireless Connection                                                          4 Dec. 01


remote Host Controller when a connection is established. The event contains the
Connection Handle mentioned in Chapter 4.1.7, if the connection is successful.

When the remote Host Controller receives a connection attempt a Connection
Request event is sent to the remote Host with information of which BD_ADDR that
requested the connection. The connection can be handled automatically depending
on the parameters in the Event_Filter and no Connection Request event is sent to
the Host. Otherwise the remote Host must send an accept or reject connection to the
remote Host Controller within the time specified in the local Host Controller’s
parameter Connection_Attempt_Timeout.

4.1.7 Data transfer

As mentioned earlier there are two types of data packets depending on whether we
have an asynchronous or a synchronous connection. The synchronous data packets
are used for voice transfer and are not used in this project. The asynchronous data
packets are used for data and are being used in this case.

The ACL Data Packet (shown in Figure 14) consists of three major parts. The first
two bytes are the Connection Handle and two flags, the PB Flag and the BC Flag.
The following two bytes holds information on how many bytes of data the packet
holds. Last in the packets is the data itself.




Figure 14: HCI ACL Data Packet message format

The Connection Handle is a channel identification number for a specific
connection. The connection can be point to point or point to multipoint (similar to
multicast packets). It is created upon every creation of a connection. The Packet
Boundary (PB) flag informs a receiver if this is the first packet of a higher layer
message (i.e. start of an L2CAP packet) or a continuing fragment packet. The
Broadcast Flag (BF) indicates weather the packet is a point to point or point to
multipoint packet.

The host assumes that a higher protocol called L2CAP is used. The L2CAP header
(Figure 15) is therefore included in the first four bytes of the data in an ACL Data
Packet. In this project the L2CAP protocol is not used but it contains a field called
the Channel Identifier, which is used to separate different types of data sent over the
link(CAN messages or serial data). The Channel Identifier can here be used to
control the Host on the other side of the link by setting aside values that tells the
Host on the other side that this packet contains a command and not ACL data.




                                                                           Page 38 of 56
Truck – Trailer                                                                                                                                                                             Mikael Gunnarsson
Wireless Connection                                                                                                                                                                                4 Dec. 01




Figure 15: L2CAP header format


An example of a HCI ACL Data Packet with three bytes of information is shown in
Table 9. The first byte is the type of packet indicator and is not a part of the ACL
Data Packet.


                      byte number    0                        1         2         3                4        5           6         7              8         9            10    11
                      transmitted
                      code, in hex   02 01                            20 07 00 03 00 00 00 31 32 33
                                                           Packet_Boundary_Flag
                                     HCI ACL Data packet




                                                                                  remaining in packet, 2


                                                                                                           Number of bytes from
                                                           Connection Handle,
                                                           Broadcast_Flag and




                                                                                  bytes, Little Endian




                                                                                                                                  Channel Identifier,
                      brief
                                                           Bit 6,7 – BC_Flag
                                                           Bit 4,5 – PB_Flag

                                                                                  Number of bytes



                      explanation



                                                                                                           Little Endian



                                                                                                                                  Little Endian
                      of




                                                                                                                                                        First byte in




                                                                                                                                                                             Last byte in
                                                                                                                                                        information




                                                                                                                                                                             information
                      each
                                                                                                           2 bytes,



                                                                                                                                  2 bytes,
                      byte
                                                                                                           byte 9,




Table 9: Example of a HCI ACL Data Packet

4.2 MB90543 Fujitsu microcontroller
The gateway in Figure 2 that separates the two Can buses is a product called FMS
Preparation and is developed by Scania Infotronics. It consists of the MB90543
Fujitsu microcontroller, which is a 16Mhz microprocessor with 128Kbytes of Rom
and 8Kbytes of Ram memory, voltage regulator and circuits to generate signal
levels appropriate to the CAN J1939 standard.

There are two CAN interfaces available of which one is used in this project. There
are also two UART’s on the CPU. One of them isn’t used in the FMS Preparation.
To use it, two cables have to be soldered to two of the CPU pins (pin18, UART0
data output and pin20, UART0 data input). The microprocessor has 16 message
buffers for the CAN interface. Incoming messages can be filtered according to two
mask filters for each interface, thus there is hardware support to receive selective
types of CAN messages. All Can messages are in this project filtered by the
software. The prototype uses two message buffers, one for input and one for output.

4.3 The Prototype
In this part, the prototype is explained. The software is written in ANSI C using a
program called Fujitsu FFMC-16 Family Softune Workbench. The source code isn’t
included in the report but it can be found in a CDR that Scania Infotronics holds.
The CDR contains (apart from the source code) an electronic version of this report,
various standards and documents that has been of use in this project and links to
web pages that holds information regarding DECT, BlueTooth, and the CAN
standard.




                                                                                                                                                                                                 Page 39 of 56
Truck – Trailer                                                           Mikael Gunnarsson
Wireless Connection                                                              4 Dec. 01


A general description of how the prototype works is given in Chapter 4.3.1 to 4.3.4.
This description is divided into four main areas:
    Sending HCI commands.
    RS232 serial interface.
    Gateway CAN messages.
    Description of how the prototype works.

4.3.1 Sending HCI commands
Data is send to/from the BlueTooth module using UART1 on the microcontroller.
How the module works is described in Chapter 4.1 and following is a short
description of how this is represented in ANSI C code.

Every used HCI command has a method defined in the file Bt.c/Bt.h (these are
source code files found on the CDR mentioned above). The easiest way to describe
this is by giving an example:

The command HCI_Reset described in Chapter 4.1.4 performs a software reset of
the module. The method creates an array of bytes that are to be sent to make a reset.
The bytes are (in hex) 01 03 0C 00. The method CreateOpcode combines the OGF
and the OCF to the two byte OpCode described earlier. The datatype uint8 equals
an Unsigned Short Integer and uint16 equals an Unsigned Integer. The method
Terminal_SendString sends these bytes to the BlueTooth module through the
UART1 interface. HCI_Command is defined to equal 0x01.

void HCI_Reset(void)
              {
              uint8           OGF           = 0x03;
              uint16          OCF           = 0x0003;
              uint16          Opcode        = CreateOpcode(OGF,OCF);
              char OutputString[4];
              OutputString[0]               = HCI_Command;
              OutputString[1]               = Opcode & 0xFF;
              OutputString[2]               = Opcode >> 8;
              OutputString[3]               = 0x00; //Number of remaining bytes
              Terminal_SendString(OutputString,4);
              }

4.3.2 RS232 serial interface
A serial connection in parallel with the CAN bus is provided via the UART0
interface of the Fujitsu microcontroller. Every byte that arrives to the UART0 is
forwarded to the other side of the BlueTooth link and sent out on its Hosts UART0.
There is no error correction; all bytes are just encapsulated into ACL Data packets
(containing a maximum of eight bytes of payload per packet) and forwarded.

4.3.3 Gateway CAN messages
The prototype is configured to let all CAN messages pass. This is because it is not
decided what the link should be used for and it is easier for testing purposes to just
gateway all messages. The prototype can be placed anywhere in the road train and it
will adjust a location parameter according to the received identity message
mentioned in Chapter 3.5.1. It will also send a new identity message backwards in
the road train. All messages that pass the gateway will (unless they are from another


                                                                                  Page 40 of 56
Truck – Trailer                                                                                                Mikael Gunnarsson
Wireless Connection                                                                                                   4 Dec. 01


vehicle) have their source ID changed to the ID of the vehicle. The source ID’s are
according to the ISO11992 standard.

4.3.4 Description of how the prototype works.
On every power-up, reset, or re-initialization the Host (the Fujitsu microcontroller)
initiates the two UART’s, the CAN interface, and sends the HCI commands used to
initiate the Host Controller. After the initialization the Host goes into an infinitive
loop constantly checking the input buffers of the two UART’s. The variables
location, master and connection is used to keep control of where in the road train
the device is, if it is a master or a slave in a connection, and if there is a connection.
A flowchart of the process is shown in Figure 16.

UART1; receives data from the BlueTooth module, which is either an ACL Data
packet or an Event from the module and processes it. If the first byte doesn’t
indicate an ACL Data packet or Event, synchronization is assumed to be lost and
the Host will re-initialize.
UART0; receives data from whatever device is connected to the RS232 interface,
encapsulates it in an ACL data packet and sends it thorough the link to the other
vehicle.

        Initialize UART0,
           UART1, and
        Bluetooth module.     Go into a loop                                Yes
          Set Location,      waiting for data         Data received                     Read first byte
         Connected, and     from the UARTs               UART1
          Master status
             variables
                                                         No                    Event                      ACL Data
                                                                                         Packet type



                                                                    Read next two                             Read next four
                                                                       bytes                                     bytes

                                                                                                Unknown



                                                                Read remaining         Reset the device      Read remaining
                                                                    bytes                                        bytes




                                                                 Process Event                              Process ACL Data
                                                                    packet                                       packet




                                                No
                                                      Data received
                                                         UART0

                                                              Yes

                                                     Encapsulate into
                                                     ACL Data packets
                                                        and send




                                                       End of loop




Figure 16: Flowchart showing the prototype in runtime.



                                                                                                                       Page 41 of 56
Truck – Trailer                                                            Mikael Gunnarsson
Wireless Connection                                                               4 Dec. 01


Every CAN message that is received generates an interrupt. The program then
checks the message to see if the CAN message holds data that is to be forwarded or
if it holds a HCI command (see Chapter 4.3.5) for the Host Controller. If the
messages hold data and there is a connection between the two vehicles, it
encapsulates the CAN message in an ACL Data packet and forwards the message
via the link to the Host on the other side. The procedure is shown in Figure 17



                                       Gateway
                                       operating

                        No
                                              Yes


                                                           Yes
                                      master and
                                   identity message

                                                          Set location
                                        No                 variable



                                                         Change identity
                                                          message to fit
                                                           next vehicle
                              No       location
                                     variable valid


                                             Yes


                                   Change source-ID
                                   if the message is
                                    from this vehicle




                                   Encapsulate CAN
                                     message and
                                   send through link



                                   END INTERRUPT

Figure 17: Flowchart showing reception of CAN messages




                                                                                Page 42 of 56
Truck – Trailer                                                       Mikael Gunnarsson
Wireless Connection                                                          4 Dec. 01


On the other side the message is received as an ACL Data packet, de-capsulated and
sent out on the CAN bus. If the message is an identity message the location variable
is set. The procedure is shown in Figure 18.


                               Extract Can
                              message from
                             ACL Data packet




                                Is identity    Yes
                                message

                                               Set location
                                                variable
                                No




                            Send message out
                              on CAN bus

Figure 18: Reception of an ACL Data packet containing a CAN message




                                                                           Page 43 of 56
Truck – Trailer                                                    Mikael Gunnarsson
Wireless Connection                                                       4 Dec. 01



              5 Protocol

As described earlier the system consists of a BlueTooth module connected to a
microcontroller via a serial RS232 interface. The microcontroller has a CAN
interface that is connected to a CAN bus. When a connection is made between
devices connected to physically separate CAN buses they can exchange a selective
type of CAN messages. The microcontroller receives a CAN message, looks into
the message ID and decides whether it is allowed to pass the message through the
BlueTooth link to the other CAN bus. If so it encapsulates the CAN message into a
BlueTooth ACL data packet and sends it to the receiver on the other bus. That
receiver extracts the message and sends it out on the bus.

Management of the BlueTooth module is mostly made by the microcontroller but
some commands has to be made manually to give the user some control of when to
for example initiate or terminate a connection. To make this possible a number of
commands to send to the microcontroller through its CAN interface has been
defined. These commands makes it possible to ask the Host Controller for a list of
other nearby BlueTooth devices and to make (or terminate) a connection to one of
these devices.

The following list of commands is a modified subset of available commands
according to the BlueTooth Specification Version 1.1. These commands provide
possibilities to initialize and in some ways control the BlueTooth module through
the CAN interface of the Host. As mentioned earlier most of the management of the
BlueTooth device is done by the microcontroller and these commands gives a user
possibility to control link establishment by extracting some of the information from
the BlueTooth device through the CAN bus.

The Host takes an incoming CAN message, extracts the relevant data and builds a
HCI command to send to the Host Controller. At the moment the following
commands are available:

    -  Bt_Initialize: This command resets the Host and executes the setup of the
       BlueTooth module to make it prepared to create a connection as a slave or a
       master.
   - Bt_Inquiry: This command starts an inquiry process in which the
       BlueTooth module searches for other devices.
   - Bt_Connect: This command makes a connection to a certain device.
   - Bt_Disconnect: This command terminates the connection between two
       devices.
These commands are described in Chapter 5.2. Chapter 5.3 gives an example of
how to make a connection.

Appendix A informs Scania Infotronics how to connect the different parts of the
prototype to make it operational.




                                                                        Page 44 of 56
Truck – Trailer                                                              Mikael Gunnarsson
Wireless Connection                                                                 4 Dec. 01


5.1 Message formats

5.1.1 Command message format
A CAN message can have a maximum payload of 8 bytes. In a CAN message that
contains a HCI command to the BlueTooth module the payload has been divided
into three major parts; the command code, the number of parameters, and the
parameters themselves. The message format of such a message is shown in Figure
19. The first byte consists of the command code (bit 7 to bit 4) and the number of
parameters (bit 3 to bit 0).

                      0                           7                     15
                      Command         Number of           Parameter 0
                      code            remaining
                                      bytes
                                                      .
                                                      .

                      Parameter n-1                       Parameter n

Figure 19: Prototype command message format


5.1.2 Return parameters format
Some of the commands will have return parameters (Events) that are sent back to
the commanding device in a CAN message. The Event code in the first byte tells us
which Event that was generated as response. The format is shown in Figure 20.
These return parameters contain some of the information of the events sent by the
host to the host controller. Details of the parameters are given together with the
corresponding command in Chapter 5.2

                      0                           7                     15
                      Event code                          Parameter 0
                                                      .
                                                      .

                      Parameter n-1                       Parameter n

Figure 20: Prototype return parameter format




                                                                                  Page 45 of 56
Truck – Trailer                                                        Mikael Gunnarsson
Wireless Connection                                                           4 Dec. 01


5.2 Prototype commands

5.2.1 Bt_Inquiry

   Command                   Code                        Command Parameters
   Bt_Inquiry                0x02                        Inquiry_Length,
                                                         Num_Responses

Description:
This command will cause the BlueTooth device to enter Inquiry Mode. This mode
is used to discover any unknown and nearby BlueTooth devices. To make a
connection between two BlueTooth devices the address and info about their system
clocks are needed. There are two command parameters; Inquiry_Length, which sets
the maximum time that the inquiry may last and Num_Responses, which limits the
number of responses accepted.

The return parameters are sent in one separate CAN message for each response. The
message holds information the unique address of the answering devices.

Command Parameters

  Inquiry_Length                                                        Size: 1 Byte
   Value                    Parameter Description
   N = 0xXX                 Maximum time that the Inquiry may last.
                            Range: 0x01 – 0x30
                            Time = N*1.28 sec
                            Range: 1.28 – 61.44 sec

  Num_Responses                                                         Size: 1 Byte
   Value                   Parameter Description
   0x00                    Unlimited number of responses (within chosen time)
   0xXX                    Maximum number of responses before the Inquiry is
                           halted
                           Range: 0x01 - 0xFF


Event (Event code = 0x02)
An Event is sent in return with the address of the answering device.


  Return Parameters                                                     Size: 7 Bytes
   Value                      Parameter Description
   0x06                       Number of remaining bytes
   0xXXXXXXXXXXXX             BT_ADDR of the answering device




                                                                            Page 46 of 56
Truck – Trailer                                                         Mikael Gunnarsson
Wireless Connection                                                            4 Dec. 01




5.2.2 Bt_Initialize

   Command                    Code                        Command Parameters
   Bt_Initialize              0x01                        -

Description:
This command resets the BlueTooth module and makes the appropriate initiations
to make it operational. No command parameters are defined and all variables such
as transfer rates have default values.

Command Parameters
None

Return Parameters
None

5.2.3 Bt_Connect

   Command                   Code                         Command Parameters
   Bt_Connect                0x03                         Connect_To

Description:
This command will cause the BlueTooth device to connect to the device whose
address is given in the Connect_To parameter.

Command Parameters

  Connect_To                                   Size: 6 Bytes
   Value            Parameter Description
   N              = The BT_ADDR of the device to which a
   0xXXXXXXXXXXXX   connection is demanded


Event (Event code = 0x03)
An Event is sent in return with the result of the connection attempt.

  Return Parameters                                                      Size: 1 Byte
   Value                    Parameter Description
   0x00                     Connection successfully completed
   0x01 – 0xFF              Connection failed to complete. See BlueTooth
                            Specification Version 1.1 Page 766 for error codes.




                                                                             Page 47 of 56
Truck – Trailer                                                    Mikael Gunnarsson
Wireless Connection                                                       4 Dec. 01


5.2.4 Bt_Disconnect

   Command                   Code                        Command Parameters
   Bt_Disconnect             0x04                        -

Description:
This command will cause the BlueTooth device to terminate the connection
between the two CAN buses.

Command Parameters

  Disconnect From                                                    Size: 1 Byte
   Value                            Parameter Description
   0x05                             Event code

Event (Event code = 0x05)
An Event is sent in return to confirm that the disconnection is completed. There are
no parameters, just the Event code.




                                                                        Page 48 of 56
Truck – Trailer                                                                                           Mikael Gunnarsson
Wireless Connection                                                                                              4 Dec. 01




5.3 Examples
To separate incoming CAN messages that are to be gatewayed from the ones
containing HCI commands a PGN has to be assigned to represent HCI commands.
In the file Can.h amongst the source code files this is done by this row:
#define BlueTooth_command_PGN 0x010F
In a similar way CAN message sent in return containing Events also have a unique
PGN: #define Event_CAN_message_to_be_transmitted 0x030F000F

These values does not comply with any standard; they are only for testing purposes

Figure 21 shows the procedure to achieve a connection.


                      Local device                         Timeline                   Remote device

                       Send Bt_Inquiry
               PGN: Bluetooth_Command_PGN
           Parameters: Inquiry length, Num responses
               Data in CAN message: 22 04 01
                  ~5s and max one respons



                                                                                    Receive Inquiry respons
                                                                                 PGN: Event_CAN_message_....
                                                                        Parameters: The BT_ADDR of the answering
                                                                                              device
                                                                           Data in CAN message: 02 xx xx xx xx xx
                                                                      xx .. Is the address in Little Endian format the first
                                                                                     byte is the Event code.




                         Send Bt_Connect
                 PGN: Bluetooth_Command_PGN
         Parameters: The BT_ADDR of the remote device
            Data in CAN message: 36 xx xx xx xx xx
            xx .. Is the address in Little Endian format



                                                                                 Receive Connection complete
                                                                                 PGN: Event_CAN_message_....
                                                                        Parameters: The BT_ADDR of the answering
                                                                                              device
                                                                           Data in CAN message: 02 xx xx xx xx xx
                                                                      xx .. Is the address in Little Endian format the first
                                                                                     byte is the Event code.




Figure 21: Procedure to make a connection




                                                                                                                   Page 49 of 56
Truck – Trailer                                                                    Mikael Gunnarsson
Wireless Connection                                                                       4 Dec. 01



         6 Evaluation & Testing
To test the prototype, CANalyzer and LAPcan were used15. LAPcan is a two-
channel CAN interface for the PC Card (PCMCIA) bus and CANalyzer is a
application that makes it possible to send and receive CAN messages from a CAN
bus via the LAPcan card. Through the laboratory at Scania Infotronics there is a
CAN bus installed and a PC with CANalyzer and LAPcan card is connected to this
bus. When the prototype was tested or demonstrated this represented the truck. A
laptop, also equipped with CANalyzer and LAPcan represented the trailer. These
two computers were connected via their CAN busses and, of course the prototype.
To test the parallel serial connection a third computer was used and the prototype
devices were connected to COM1 and COM2. Two terminal applications were used
to send data between these two serial ports. The test system is shown in Figure 22.

                                       Stationary computer to test
                                          the serial connection




                                      COM1                   COM2
                 Stationary PC with
               CANalyzer and LAPcan                                  Laptop with CANalyzer
                                                                          and LAPcan




                                              Wireless
                                              gateway


                    The Truck                                             The Trailer

Figure 22: Prototype test-system
The tests were done manually by sending CAN messages with CANalyzer and
typing hex values in the terminal applications. The tests showed that the prototype
worked as expected and that CAN messages were sent and received according to
the address regulations in the ISO11992 standard and the protocol designed and
explained in Chapter 5.

No field-tests were made and the type of tests that should be considered when
dealing with a CAN gateway are further discussed in Chapter 8.4.




15
     Both CANalyzer and LAPcan can be found at http://www.kvaser.se


                                                                                         Page 50 of 56
Truck – Trailer                                                     Mikael Gunnarsson
Wireless Connection                                                        4 Dec. 01



      7 Conclusions
Personally I have grown quite fond of the Bluetooth technology. There are more
and more "one-chip" solutions becoming available on the market, they are small,
low power and at least "supposed to" be low cost in a couple of years, and the
technology is developed to cope with a large amount of interference. There are a
large number of areas where I think Bluetooth might be a good alternative for
cables, not just as a CAN gateway. For example, when looking behind my PC at
home it is easy to see many opportunities to replace cables! Generally all kinds of
portable systems that are temporarily set up in a location could benefit from
Bluetooth. I have had a pleasant time working with the Ericsson Bluetooth
development kit and I hope to continue to learn more about this technology and
work professionally with it as an engineer.

BlueTooth as a technology is capable on meeting the requirements in this project.
At least when it with a reasonably amount of effort comes to connect the HCI and
CAN protocols. As discussed in Chapter 8, there still is need for a further look into
the hardware. Theoretically there shouldn’t be any problem. BlueTooth is, as
mentioned earlier, designed to cope with interference, but one should consider the
range when deciding the placements of the nodes. Of course there is always need of
more bandwidth, regardless of what technology one uses. If I for example have a
camera attached to the trailer, more bandwidth would result in better quality. But
one must ask oneself what bandwidth is needed to get the job done. If one look at
the system without the gateway there are two CAN buses that are to be connected.
They have a data transfer rate of 250 or 125kbit/s depending of which standard to
follow. By choosing BlueTooth, with a capacity of 460 kbit/s through the UART,
we still have about 200kbit/s left for the parallel serial connection via the same
BlueTooth module.

Basically what we do here is shuffling bytecode between the two nodes in a point-
to-point connection. The HCI protocol that the BlueTooth follows suits our needs.
There is no need to lift the communication up to higher levels (such as L2CAP or
similar in other technologies). The BlueTooth technology also has great potential
when it comes to dynamically make connections to various unknown devices. As
mentioned earlier it is possible to ask an anonymous device for its unique address
over the air and it is easy to block the device from answering any other inquiries
when a connection has been made. A BlueTooth device has via the HCI protocol
support to block or allow connection attempts automatically or by sending events to
the Host (microcontroller). The job is to develop some kind of protocol between the
BlueTooth device and the CAN bus. One example of how to do this is partly made
in the prototype where it is possible to make and terminate a connection via CAN
messages.




                                                                         Page 51 of 56
Truck – Trailer                                                       Mikael Gunnarsson
Wireless Connection                                                          4 Dec. 01



      8 Future work


8.1 Hardware
Clearly the next step is to further examine the hardware needed to turn this
prototype into a possible future product. This project has shown that Bluetooth is
capable of meeting the requirements and that it is possible (with a reasonably
amount of effort) to develop software that can handle communication with CAN
messages via a Bluetooth device. An important issue if one was to continue making
a gateway using BlueTooth would be to carefully choose between different Host
controller candidates. The microprocessor that was used in this project has some
compatibility problems with the BlueTooth module used. As mentioned earlier the
UART speeds are not compatible. Alternatively since the microcontroller itself is
capable of supporting a data transfer rate of 500kbps, another approach would be do
consider other Bluetooth devices that support a compatible transfer rate.

8.2 BlueTooth Product Qualification
To get a product qualified as a BlueTooth product there are a number of test cases
that the product must pass thus an important question is if one should seek
Bluetooth Product Qualification. If so, then it will be important to consider how
much work is needed to put such a product on the market. This is something that
hasn’t been looked into in this project. If one were to look into this, then good place
to start would be the Bluetooth website, http://www.bluetooth.org or to contact
Ericsson, concerning their development kits for product qualification.


8.3 Security
The security aspect is something to have in mind when further designing a future
product. These aspects haven’t been further investigated because it is not yet
decided what kind of information that is to be sent through the link. It is also not
clear whether the gateway should be a standalone product or a part of a larger
system in a future product. As soon as one has a clearer picture one should consider
if there is any need to take, and if there is, decide how to deal with the security
issues. To block any external connection attempts is easily done with the HCI
command HCI_Set_Eventfilter thus there is not really any need to further
investigate how to accomplish a block for external devises. The focus should
instead be in deciding what security is needed. Is there any need at all to protect the
data sent through the link? Are any settings being made through the air that could
be altered externally?




                                                                           Page 52 of 56
Truck – Trailer                                                      Mikael Gunnarsson
Wireless Connection                                                         4 Dec. 01


8.4 Testing a CAN gateway
As mentioned in Chapter 6, the testing of the prototype has been focusing on testing
the software (and the prototype) in a laboratory environment. The prototype, as it is,
is not ready to be tested further in a larger scale according to any testing procedure
that Scania Infotronics might have.

In a product such as a wireless gateway, testing is divided into four major areas:
hardware capabilities, rules and regulations concerning CAN gateways, software,
and the standards that are involved. It is difficult to give a suggestion concerning
how to proceed with the testing of the prototype and a future product, since as
mentioned earlier, it is not (yet) decided whether this wireless gateway is to become
a separate product or a part of a larger system. In addition, Scania Infotronics does
not completely follow the standards for CAN, because the regulations on identity
numbers for different CAN messages gave them no address space for their own
messages. That is one of the reasons that they have a separate external CAN bus
(shown in Figure 1). However, as soon as there is some kind of specifications of
what the system will look like and what the gateway is to be used for, a testing
procedure will have to be designed to verify that the functionality meets the product
specifications.




                                                                          Page 53 of 56
Truck – Trailer                                                              Mikael Gunnarsson
Wireless Connection                                                                 4 Dec. 01



References

  [1]   BLUETOOTH- The universal radio interface for ad hoc, wireless connectivity,
        http://www.ericsson.se, accessed Aug 2001.

  [2]   DECT frame structure, Wireless Multimedia Laboratory, http://user-
        www.ie.cuhk.edu.hk/~wmm96/frame.htm, accessed Aug 2001.

  [3]   DECT, The standard explained, DECT Forum, http://www.dectweb.com/, accessed Aug
        2001.

  [4]   ETR 178: “Radio Equipment and Systems (RES); Digital European Cordless
        Telecommunications (DECT); A high level guide to the DECT standardization”.

  [5]   ETS 185: “Radio Equipment and Systems (RES); Digital European Cordless
        Telecommunications (DECT); Data Services Profile (DSP); Profiles overview”.

  [6]   ETS 300 175-1: “Radio Equipment and Systems (RES); Digital European Cordless
        Telecommunications (DECT); Common Interface (CI); Part 1: Overview”.

  [7]   ETS 300 175-2: “Radio Equipment and Systems (RES); Digital European Cordless
        Telecommunications (DECT); Common Interface (CI); Part 2: Physical (PHL) layer”.

  [8]   ETS 300 175-3: “Radio Equipment and Systems (RES); Digital European Cordless
        Telecommunications (DECT); Common Interface (CI); Part 3: Medium Access Control
        (MAC) layer”.

  [9]   ETS 300 175-4: “Radio Equipment and Systems (RES); Digital European Cordless
        Telecommunications (DECT); Common Interface (CI); Part 4: Data Link Control (DLC)
        layer”.

  [10] ETS 300 175-5: “Radio Equipment and Systems (RES); Digital European Cordless
       Telecommunications (DECT); Common Interface (CI); Part 5: Network (NWK) layer”.

  [11] ETS 300 175-6: “Radio Equipment and Systems (RES); Digital European Cordless
       Telecommunications (DECT); Common Interface (CI); Part 6: Identities and addressing”.

  [12] ETS 300 175-7: “Radio Equipment and Systems (RES); Digital European Cordless
       Telecommunications (DECT); Common Interface (CI); Part 7: Security features”.

  [13] ETS 300 175-8: “Radio Equipment and Systems (RES); Digital European Cordless
       Telecommunications (DECT); Common Interface (CI); Part 8: Speech coding and
       transmission”.

  [14] ETS 300 444: “Radio Equipment and Systems (RES); Digital European Cordless
       Telecommunications (DECT); Generic Access Profile (GAP)”.

  [15] George Thomas, “Extending CAN networks by incorporating remote bridging”,
       http://www.ccontrols.com/pdf/extendingcan.pdf, accessed Aug 2001
  [16] ISO 11992, ISO standard, http://www.iso.ch, accessed Aug 2001.

  [17] Kvaser Homepage http://www.kvaser.se, accessed Aug 2001

  [18] Kvaser homepage, SAE J1939 tutorial, http://www.kvaser.se/can/hlps/j1939.htm, accessed
       Aug 2001




                                                                                  Page 54 of 56
Truck – Trailer                                                             Mikael Gunnarsson
Wireless Connection                                                                4 Dec. 01


  [19] Mike Schofield, “Controller Area network, An Introduction to CAN – The serial data
       communications bus”, http://www-ife.tu-graz.ac.at/Lokal/Tech/Can-Bus/schofield.htm,
       accessed Aug 2001

  [20] The BlueTooth specification; Volume 1 Core, v.1.1, http://www.BlueTooth.com, accessed
       Aug 2001.

  [21] The BlueTooth specification; Volume 2 Profiles, v.1.1, http://www.BlueTooth.com,
       accessed Aug 2001.

  [22] White paper BlueTooth, http://www.ausystem.com, accessed Aug 2001.




                                                                                 Page 55 of 56
Truck – Trailer                                                               Mikael Gunnarsson
Wireless Connection                                                                  4 Dec. 01



Appendix A
This Appendix tells any user of the prototype how to connect its parts.

The prototype consists of three parts:
    The Fujitsu Microcontroller (FMS preparation)
    The BlueTooth module shown in Figure 13.
    A MAXIM RS232 circuit that converts the signal from the UART1 (CMOS)
       to standard RS232 levels.
These will be referred to as: microcontroller, BlueTooth module, and MAXIM.

The microcontroller is a power supply to the BlueTooth module and the MAXIM.

All connectors have been numbered and Table X below described each of them.


Due to the compatibility problems between the UART speed settings the BlueTooth
module has to be initialized from an external computer upon power on. This is done
as follows:

Connect all three parts according to Table X. After the BlueTooth module has
powered up, connect it to the COM1 port of a PC and start a terminal program that
can send byte-code (non ASCII). In this project a program called Bterm 16 was used
and can be found on the CDR mentioned earlier.

The speed of the UART1, to which the BlueTooth module is to be connected, is set
at 9600baud. To set the BlueTooth module to the same speed, send the following
bytes to the module:
              01 03 0C 00 01 09 FC 01 14

The first four bytes reset and synchronize the BlueTooth module. The following
five sets the UART speed of the module to 9600baud. Finally change the connector
back to the one connected to the MAXIM.


     Connector     Description
     number
     1             Connect this to the UART1 connector of the microcontroller, the
                   red wire to pin #1.
     2             Connect this to the jumper area (Figure 13) of the BlueTooth
                   module (Figure 12), red wire to pin #1.
     3             Connect this to the two wires connected directly to the CPU of
                   the microcontroller.
     4             Connect this to the UART connector (Figure 13) of the
                   BlueTooth module


16
 BTerm is a terminal application developed by Erland Nilsson, cad@canit.se. This application
makes it possible to write bytecode that is to be send out on a COM port.


                                                                                    Page 56 of 56

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:131
posted:11/19/2010
language:Swedish
pages:56