Investigation of technical and communicational

problems with the remote key for Volvo cars

Master of Science Thesis in the Master Degree Programme
Communication Engineering

PER OLSSON

Department of Signals and Systems

Division of Communication Systems, Information Theory and Antennas
CHALMERS UNIVERSITY OF TECHNOLOGY
Göteborg, Sweden, 2013
Report No. EX012/2013
 In memory of Linnéa Appelgren.
1921-10-07 to 2012-11-23

My grandmother’s greatest wish was to see me graduate from Chalmers; sadly she
never got the chance since she died just a few months before. She longed for being
present at my presentation even if she knew that she would not be able to
understand anything I was talking about. But she was always so proud of me, her
only grandson, and she told every person she met that I was a student at Chalmers.

I miss your phone calls, even if you always managed to call when the movie I was
watching became the most exiting but now I am glad that you did.
I will always remember you and all the fun we had.

Your beloved grandson

 Abstract

The objective of this thesis is to investigate possible problems that can occur within
the Remote Key (RK) system in Volvo cars and develop new methods for detecting
the problems. The system is divided into four areas, the RK, the wireless channel,
the Radio Frequency Receiver (RFR) and the Central Electronic Module (CEM).
Solutions are developed in order to determine in which of these areas the problem is
located. For the RK, the RFR and the CEM, several robust systems are developed
and for the wireless channel one system is developed that uses a small amount of
memory for detecting interference. The common requirements for the developed
solutions include low memory constraints and computational power and they need
to be implemented in a software based manner. All these methods will result in
an enhanced troubleshooting system which will help the mechanic locate the error.
To establish in which order to use the developed methods troubleshooting trees are
developed.
As an extra task a simulation is created with the purpose of investigating which
modulation technique will work better for future implementations, and also how
much the system could gain by implementing repetition code and interleaving. How-
ever, this simulation was too time-consuming thus it was not fully completed.
List of Abbreviations
ACK Acknowledgment

AES Advanced Encryption Standard

BER Bit Error Rate

CAN Controller Area Network

CEM Central Electronic Module

CH Channel

DiCE Diagnostic Communication Equipment

DIM Drivers Information Module

DTC Diagnostic Trouble Code

GFSK Gaussian Frequency Shift Keying

GGD DHA Generic Global Diagnostic Diagnostic Host Application

ID Identification number

KV Keyless Vehicle

LIN Local Interconnect Network

LOS Line Of Sight

NVM Non Volatile Memory

PAM Pulse Amplitude Modulation

PTS Swedish Post and Telecom Authority

RAM Random Access Memory

RF Radio Frequency

RFR Radio Frequency Receiver

RK Remote Key

RSSI Received Signal Strength Indication

S-FMEA System Failure Mode and Effect Analysis

SI System Increment

SNR Signal to Noise Ratio

TBD To Be Determined

TPMS Tyre Pressure Monitoring System

VIDA Volvo Information and Diagnostics for Aftersales

WUP Wake Up Pattern

List of Figures
1 Block diagram of the system architecture . . . . . . . . . . . . . . . . . . . . . . 5
2 Transmitting procedure for the two channels . . . . . . . . . . . . . . . . . . . . . 6
3 Transmitting procedure for the two channels with comfort burst . . . . . . . . . 6
4 The RFR’s polling intervals for the different channels . . . . . . . . . . . . . . . . 7
5 RF protocol header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6 Diagram of the channel statistic counters . . . . . . . . . . . . . . . . . . . . . . 21
7 SI counter self synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

List of Tables
1 Timing intervals for RK’s sending sequences . . . . . . . . . . . . . . . . . . . . . 6
2 Polling intervals for the RFR with and without a TPMS . . . . . . . . . . . . . . 8
3 Presentation of the histogram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4 Typical values of the counters in the histogram . . . . . . . . . . . . . . . . . . . 16
Contents
1 Introduction 2
1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Software description 3
2.1 VIDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 VIDA draft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 GGD DHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Overview of the system architecture 4

3.1 Remote Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Radio Frequency Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3 Central Electronic Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4 Description of the system communication protocol . . . . . . . . . . . . . . . . . 8
3.4.1 Local Interconnect Network . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4.2 Controller Area Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4.3 Radio Frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4.4 Low Frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.5 When to use the RF or the LF protocol . . . . . . . . . . . . . . . . . . . . . . . 10
3.6 Problems with today’s troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Developed methods 11
4.1 LF and RF usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2 Case 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.1 Methods and solutions implemented in the RK . . . . . . . . . . . . . . . 12
4.2.2 Methods and solutions implemented in the RFR . . . . . . . . . . . . . . 14
4.2.3 Methods and solutions implemented in the CEM . . . . . . . . . . . . . . 16
4.3 Case 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.4 Case 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5 Other improvements 18
5.1 Repetition code and interleaving . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2 Channel statistic counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.3 Self synchronization for the SI counter . . . . . . . . . . . . . . . . . . . . . . . . 21

6 Encountered problems 22

7 Conclusion 23

8 Discussion 24
9 Further Work 25

References 26

A Possible problems i

B Specification for the equipment ii

C Specification for VIDA vi

D Troubleshooting tree for the ideal case ix

E Troubleshooting tree for the second case xi

F Troubleshooting tree for the third case xiii

1 Introduction
Today when mainly everything is wireless so are of course the keys to our cars. The Volvo
customer can sometimes encounter problems with their remote keys (RK) when trying to unlock
or lock the car. If this happens repeatedly, the customer has no other alternative than drive to
a garage where a garage mechanic can have a look at the problem. However, today there are
few ways to actually determine what the problem is and the mechanic has to some extent guess
what the problem could be and therefore often starts by replacing the cheapest parts. This
tends to give many unnecessary replacements of working equipment, which cost a lot of money.
This thesis will focus on how this can be improved, simplifying the detection of problems for
the mechanic and helping the developers finding possible problems at an early stage.

1.1 Purpose

The purpose is to investigate and develop new methods for troubleshooting and diagnosing the
RK. In conjunction with the developed methods, guidelines will also be written to describe how
to use the methods. If possible, the guidelines will be implemented in Volvo Information and
Diagnostics for Aftersales (VIDA) as guidance for the mechanics when searching for errors. For
more detailed information about the system, see Section 2.1.
This will enhance the garage mechanic’s possibilities to determine the customer’s problem
and pinpoint the location within a certain area. Even if the customer delivers the car and
only says "My car will not lock/unlock" these enhanced methods will help the mechanic to find
the issue. The remote system shall be divided into at least four areas where the methods for
finding the issue must be feasible and reliable. These new methods shall to the possible extent
be implemented in both present and next generations of RKs. The proposed solutions shall
not require any new hardware and impose high storage requirements in order to make them
affordable in terms of cost when implementation takes place.

1.2 Scope

Since this thesis subject contains many different problems for different Volvo models, delimita-
tions within scope have to be considered. Firstly, this thesis will not handle RKs with two-way
communication. This is mainly because these systems differ from each other and this form of
communication is not as important as the one-way communication with Radio Frequency (RF).
Another kind of RK that will not be handled in this thesis are so-called Keyless Vehicle (KV)
remotes. This is because the KV system does not use the Radio Frequency Receiver (RFR)
as receiver instead; a keyless vehicle module is used, which is totally different from the RFR.
Secondly, this thesis will not deal with cryptography, meaning how the information is encrypted
and decrypted. Thirdly, it will not consider human errors such as the customer pointing the
RK to another car, point it in the wrong direction etc. Moreover, it will not take into consider-
ation any mechanical failure. Finally, the thesis will only cover the chain from "pressure at the

2
button" to "click-sound from the locks", it will not cover what happens after that i.e., the flash
from lights.

1.3 Method

The methods mainly used throughout this thesis are theoretical and are applied to problems
already on the market but also to potential problems, not yet occurred. The problems will be
verified to some extent using programs provided by Volvo, such as Generic Global Diagnostic
Diagnostic Host Application (GGD DHA) and VIDA. To rank the severity of the problems the
principle of System Failure Mode and Effect Analysis (S-FMEA) will be used.
An investigation for finding possible problems was performed, where the focus was on brain-
storming ideas of possible and impossible errors that could occur. The investigation showed that
several possible problems exist (see entire list in Appendix A) within the RK system. Hence,
the most reasonable were selected. The problems were selected using S-FMEA and ranking the
problems according to their occurrence probability, their severity if they occur and if a solution
already exists.
To develop solutions to the selected problems, both theoretical studies and practical tests in
cars were used. Besides the literature studies including Volvo specifications, the wiring diagrams
and schematics were investigated in order to conduct measurements and locate all components
to find workable solutions. When all tests were performed and a greater knowledge of the
system architecture was detained, the elaboration of the new methods could begin. The new
methods required exhaustive discussions with the advisors at Volvo to find out if the solutions
were too complex or not possible to implement. This was due to their huge need for memory or
computational capacity. This led to much iterations before presenting the final results. Besides
developing methods for the selected problems, other methods and protocols were developed
to enable working and communication possibilities between the developed methods and the
existing systems. The final solutions are presented in Section 4.

2 Software description
In this section a brief description of the programs that are used in this master thesis will be
presented.

2.1 VIDA

VIDA is a software provided by Volvo for the garage mechanic, serving as guidance in order
to find issues and problems claimed by the customer. VIDA helps the mechanics to repair,
troubleshoot and service Volvo cars by providing information about service, spare parts, diag-
nostic troubleshooting and software downloads which are all integrated in one system. There
are two main systems for VIDA: VIDA on WEB and VIDA (which is installed on the mechanics
computer) [1], [2]. The system is used as follows:

3
 1. If available, add customer complaints.

2. Connect the Diagnostic Communication Equipment (DiCE), a communication tool be-

tween the computer and the car provided by Volvo.

3. Start the initial communication and check if there is any activated Diagnostic Trouble
Codes (DTC). A DTC is set when a problem occurs in order to help the mechanic locate
the problem and remain set until the mechanic has corrected the problem and reset the
DTC.

4. If any DTCs are found, the mechanic just clicks on the DTC that shall be corrected and
then follows the instructions given from the system.

2.2 VIDA draft

VIDA draft is a version of VIDA on WEB where the developers can test their troubleshooting
methods to check that they work correctly, before releasing it to the mechanics. This system
also provides more freedom when used in a test environment. One big advantage is that the
system supports virtual vehicles allowing to perform a diagnosis in the car and save all the
information to a file. This file can be used back at the office to test the new functions without
being physically present at the car. However, since it is only a virtual car there is no way to
obtain status changes, so the function can be tested but if a new error would occur in the car
it will not be shown in the virtual car.

2.3 GGD DHA

GGD DHA is a system used when developing systems in cars. This program contains all
variables that are transferred within the car. It can access all variables and commands allowing
reading and/or writing to these variables. It is also possible to read DTCs, part numbers,
upload new software to the different modules etc. This system is useful when testing new
systems since in VIDA you do not have access to all variables, which you have in GGD DHA,
but in GGD DHA you do not get access to the technical description of how you replace parts,
troubleshooting etc. However, in GGD DHA it is possible to create automatic sequences that
read or write to the variables making it unnecessary to be at the computer all the time. When
writing to a variable, it is possible to set the sensor values to the required values making it
possible to simulate different conditions in a car even if the conditions have not occurred.

3 Overview of the system architecture

In the system today there is a RK that transmits the information with RF to the RFR which in
turn sends the information to the Central Electronic Module (CEM) over a Local Interconnect
Network (LIN) bus. The CEM processes the received information which is then sent over a
Controller Area Network (CAN) to the nodes, which are e.g., the lock in the doors and the

4
alarm module. An alternative method of transmitting information between the RK and the
CEM is to insert the RK into the ignition slot, which then uses LF to retrieve the information.
In Figure 1 an overview of the system is presented. The system can be divided into five parts;
the RK, the wireless channel, the RFR, the CEM and the nodes. However, the nodes are not
considered in this thesis [3], [4].

LF protocol Ignition
Slot
RF protocol

RFR LIN
CEM CAN
Node

Figure 1: Block diagram overview of the system architecture.

3.1 Remote Key

When you press a button on the RK a signal is transferred to the microprocessor that decides
which message shall be sent. The message is then encrypted with the Advanced Encryption
Standard (AES). After the encryption the message is modulated using first Manchester code
and then Gaussian Frequency Shift Keying (GFSK). The modulated message is transferred to
the oscillator and finally to the antenna. To ensure that the sent command from the RK is
a new command and not a recorded one, a System Increment (SI) counter is used. When a
button is pressed the counter is increased and the value is inserted to the message. Hence, an
alteration of the sent message is always performed. More about how the CEM determines if it
is a recorded message or not, can be found in Section 3.3.
The RK uses two different frequencies to ensure that the message is received by the RFR, a
so-called redundancy system. The RK used in this master thesis uses frequencies 433.6700 MHz
and 434.2510 MHz. The RK starts with sending Wake Up Pattern-messages (WUP-messages)
to ensure that the RFR is awake before sending the message. The WUP-messages consist of
multiple WUP, each WUP is 8 bit long. The transmitting procedure is as follows: First WUP-
messages along with the message are sent on channel (CH) 1 with frequency 433.6700 MHz.
After that the same sequence is sent on CH 2 with frequency 434.2510 MHz as presented in
Figure 2.
Figure 3 illustrates the transmitting procedure when a button is pressed for a longer time,
which will be sent as a comfort burst. Some car models use this for different application
while others just discard it. The main difference between the first message and the comfort
message is that WUP-messages are only sent the first time but the preamble and the rest of
the message, comfort frame, are transmitted again. The reason why WUP-messages are not

5
 Burst
Block 1

WUP Frame Channel 1

Block 2

WUP Frame Channel 2

T1 T1

T2 T2
TSpace
T3

Figure 2: Transmitting procedure for the two channels.

transmitted again is because the RFR has already awakened and therefore it continues to record
the comfort frames. This also saves a lot of battery since the sending time is shortened. The
different time intervals for the sending sequences are presented in Table 1 [4–8].

Burst Comfort burst 1 Comfort burst 2

Block 1

WUP Frame Frame Frame Channel 1

Block 2

WUP Frame Frame Frame Channel 2

T1 T1

T2 T2 T2 T2 T2 T2
TSpace TBurst TComfort TComfort TComfort
T3

Figure 3: Transmitting procedure for the two channels with comfort burst.

Table 1: Timing intervals for the RK’s sending sequences.

Label Time [ms]

T1 Duration of WUP-messages 166.7
T2 Duration of the frame 32.3
T3 Start of transmission on CH 2 250
T𝑆𝑝𝑎𝑐𝑒 Space between blocks in RK burst 51
T𝐵𝑢𝑟𝑠𝑡 Space between RK burst and comfort burst 101
T𝐶𝑜𝑚𝑓 𝑜𝑟𝑡 Space between comfort frames 68

6
3.2 Radio Frequency Receiver

The RFR is constantly polling to ensure the signals from the RK are received. To start recording
the information, more than 11 WUP have to be received else the RFR will not record the rest of
the information. When the recording criterion is fulfilled, the RFR records the signal to detect if
it was a correct signal. The RFR searches for the preamble to synchronize the signal whereupon
it decodes the message, first by decoding the GFSK and then by decoding the Manchester code.
The RFR checks that the message checksum corresponds and that the Identification number
(ID) is valid for this car. A non corresponding checksum will result in discarding the message.
However, if a valid ID and corresponding checksum are received, the RFR sends a message to
the CEM requesting that contact is initiated over LIN. When the CEM has established the
connection over the LIN bus, the RFR sends the message to the CEM for further validation.
If the first message (sent on CH 1) was accepted by the CEM, the message sent on CH 2 will
be received by the RFR but not evaluated and therefore not forwarded to the CEM. This is
because there is no reason for the CEM to get a duplicate of an already approved message.
However, if the first message is discarded the second message will be sent. The message sent
to the CEM also contains information about the channel used for transmission. However, a
correct received message on CH 1 result in the message from CH 2 is not forwarded. Hence,
the channel statistic counter, which is described in Section 5.2, will give an incorrect result.
The RFR scans the ether for 1.9 ms for CH 1 and 2 and depending on whether the vehicle
has a Tyre Pressure Monitoring System (TPMS) or not the polling time is slightly different.
As seen in Figure 4 vehicles with a TPMS polls more often and uses a different channel CH 3,
due to shorter WUP-messages from the TPMS sensors. The different times for these systems
can be found in Table 2. Deciding on the polling time is a trade-off between battery life and
the time needed for the command to be processed. Since, if the RFR is polling too seldom the
WUP-messages would have to be longer reducing the battery life in the RK and also increasing
the time for the command to be processed. But if polling more often, the car battery life will
be reduced and the command time decreased. For regular use the battery life will not be any
problem but if the car is left for a longer period the risk for having a battery with no power is
increased [9–11].

TCH3 TCH1 TCH2

CH3 CH1 CH2 CH3 CH3 CH3 CH3 CH1 CH2

TDUTY2
TDUTY1

TDUTY1

Figure 4: The RFR’s polling intervals for the two channels; with a TPMS, dashed lines; without
a TPMS, solid lines.

7
 Table 2: Polling intervals for the RFR with and without a TPMS [11].

Label Time without a TPMS [ms] Time with a TPMS [ms]

T𝐶𝐻1 1.9 1.9
T𝐶𝐻2 1.9 1.9
T𝐶𝐻3 - 1.3
T𝐷𝑈 𝑇 𝑌 1 148.1 151.2
T𝐷𝑈 𝑇 𝑌 2 - 37.8

3.3 Central Electronic Module

When the CEM (master) gets the message from the RFR (slave) to initiate contact it initiates
the LIN bus and then waits until it receives the message transmitted from the RFR. The CEM
checks that the encryption is correct, if it is correct the CEM decrypts the message, otherwise
the message is discarded. The CEM then validates if the ID is correct and if the SI counter value
corresponds to the correct rules and after that the CEM checks what command was sent from
the RK. The CEM distributes this command over CAN to the nodes (the lock in the doors, the
alarm module, door windows etc.) which perform their tasks. To ensure that the message was
not eavesdropped and recorded the CEM checks if the SI value sent from the RK is higher than
the value stored in the CEM. If it is not higher, then the message is considered to be a recorded
message and the CEM will discard the message and not perform the intended action. The CEM
has the capability of storing large amounts of data compared to the RK and the RFR. This is
due to the fact that the CEM is larger in size and has larger storage capabilities, which can be
used to store logs or other valuable information. Since the CEM does not have to be awake as
often as the RFR, it is easier to increase memory in the CEM. Even if more memory drains
the battery faster, the CEM is not powered on as often as the RFR. Hence, increasing memory
capacity in the RFR drains more battery than increasing memory capacity in the CEM.

3.4 Description of the system communication protocol

This section explains how the different protocols, which are used in the system, work. The
explanations are both general and specific for Volvo use.

3.4.1 Local Interconnect Network

LIN is a serial communication system that is intended for distributing information in a vehicle.
The LIN system has won its success given its hardware and wire simplicity and low cost.
The communication is based on the Serial Communication Interface (Universal Asynchronous
Receiver/Transmitter) data format, a format that uses a single master and multiple slaves.
For synchronization of nodes without their own clock, the master’s clock is used. Another
advantage with the LIN system is that almost every microprocessor available on the market has
the necessary hardware on the chip to handle this kind of communication. It is also possible to

8
determine the latency time for the system which gives the developer an easy way of knowing
exactly how long time it will take for the information to arrive at the master/slave. The master
is monitoring the bus and determines the order and priority of the messages; it also receives
WUP-messages from the slave nodes. The slave receives or transmits data when the correct ID
is sent from the master and received by the slave. All slaves can listen to the information on
the bus; however it is only the slave with the correct ID that handles the information [12], [13].

3.4.2 Controller Area Network

CAN is a serial communication bus system that is designed to provide a robust, simple and
efficient communication system for vehicles and was developed in the early 1980’s. The CAN
system is an asynchronous multi master system that uses carrier sense multiple access/collision
resolution to determine access. All messages have their own identifier which is unique within the
network and serve as a priority for the messages. Hence, the message with the lowest identifier
has the highest priority. The nodes have to wait until a bus idle period is detected and when
this occurs they can start transmitting. If two or more nodes try to transmit at the same time,
by monitoring each bit they can check if they had the highest priority or if they should stop
transmitting and wait until the next bus idle period. When the node tries to send a message it
sends its ID number and if it has not detected a 0 bit on the bus which it has not sent, then it
has the highest priority and can continue with transmitting its message [14].
Today Volvo is using two types of CAN, one high speed CAN and one low speed CAN. This
is because there are some functions that need a higher speed. The high speed is mainly used
in the engine compartment in component such as the automatic transmission. The low speed
CAN is used where time is not as critical such as when instructing a node to open the door. By
giving different priority messages a defined sending frequency it became possible to calculate
exactly how much time it would take to deliver a message. By doing this the bus idle interval
could be shorter which would speed up the pace for which the bus could be used.

3.4.3 Radio Frequency

As written in Section 3.1 Volvo uses two different frequencies both located within the open
frequency band which is free for anyone to use. According to the Swedish Post and Telecom
Authority (PTS) the open frequency band is between 433.050 MHz and 434.790 MHz and there
are a lot of different devices using that frequency band. This is why Volvo has decided to use
two frequencies close to the end of the free spectrum. According to PTS the most common used
frequency within this spectrum is 433.92 MHz and by using two frequencies relatively far from
that frequency the interference will be reduced [5], [15], [16].
Figure 5 presents the header of the RF protocol, used by Volvo for the selected car models.
For the simulations performed as an extra task, the 64 bits used are located in the Data Link
Payload; more about the simulation in Section 5.1.

9
Synchronization Physical Physical Payload Physical
Header Header Footer
Preamble Start of Short Frame Data Data Data End Of
Frame Frame Length Link Link Link Message
Delimiter Bit Header Payload Footer
24 bit 24 bit 1 bit 7 bit Up to 16 Byte 2 bit

Figure 5: Header of the RF protocol.

3.4.4 Low Frequency

LF has a frequency range between 300 Hz - 30 kHz [17]. LF can be used for transmitting
information over short and long distances. For example, short range communication is used
within the ignition slot between the RK and the LF transceiver. When the RK is inserted
into the ignition slot the distance becomes small enough for the LF to read the information
from the RK. When the RK is put into the ignition slot the LF creates an electromagnetic
field which induces power to the RK. By doing this, the battery in the RK can be too low for
unlocking the car but it will still be able to start the car since the LF will induce enough power
to communicate with the RK.
The main advantage with the LF protocol is the two-way communication, which implies
that it is possible to get an acknowledgment (ACK). Besides, it would also be possible to
communicate with the remote and directly tell it what it shall do. Another big advantage is
that since the RK is in the ignition slot during the whole trip, the LF protocol could be called
whenever the CEM is not occupied, implying that the CEM can decide when to use the LF
protocol. This means that it is possible to transfer more data since time is not an issue.

3.5 When to use the RF or the LF protocol

In the system there are two possible ways of transmitting the information from the RK to the
CEM: with the LF protocol via the LF transceiver and with the RF protocol via the RFR. The
RF protocol is used from the RK to the RFR while the LF protocol is used between the ignition
slot and the RK. The ideal way would be to use the LF protocol due to possibilities of having
two-way communications which implies the possibility of getting confirmation that the message
has been received.
Only using the RF protocol would be considered as a backup plan if it would prove to be
impossible to use the LF protocol for this purpose. The RF protocol handles the communication
for inter alia unlocking and locking, and since especially the unlocking sequence has a tight time
span it would not be possible to add much data. However, it could be possible to add a few
more bits to the sending sequence which would not deteriorate the unlocking time noticeably.
An additional byte in the sending sequence translates into approximately 2 more milliseconds

10
to send a message which is an increase with approximately 6 %. It would be preferable to
have information of at least 2 byte, due to the storage needed from the developed methods.
This alone would require two separate transmissions from the remote, since only one byte is
reasonable to add to each message. But with the RF protocol there is no way to ensure that the
message has been received by the CEM. Therefore, a three times repetition of the byte would
be preferred, since one message may be lost due to interference and one may be lost when a
button is pressed outside the range from the car. This means that the actual transmission would
have to be 6 before the message could be delivered. During this time new problems can occur,
changing the status of the RK which will not be reported for yet another 6 transmissions. This
makes it harder to pinpoint the exact time when the problem occurred. The RF protocol is also
heavier to use, in the sense that it needs a lot more power than using LF which will reducing
the battery life of the RK.

3.6 Problems with today’s troubleshooting

The troubleshooting routines that exist today in VIDA are almost nonexistent. The routine
states that if the car does not lock/unlock, there is something not working with the RK. There
are some methods in VIDA that are related to the system that this thesis handles. For example,
if there is a starting problem, a short section about the RK appears, basically describing that if
there is no connection with the RK, replace it. There is also a system called TPMS which uses
the RFR when receiving the information. However, there are only troubleshooting methods for
the TPMS sensor itself, where a special tool is used to troubleshoot the system. There are other
systems like KV that have better troubleshooting methods; however they are not applicable on
the system that this thesis is about. To improve VIDA a more enhanced and better explained
guide needs to be created.

4 Developed methods
In this section the developed routines and methods will be presented and explained in more
detail than in the specification written for Volvo, see Appendix B and Appendix C. There are
three main sections:

Case 1: which is the ideal case when rewriting the software for the CEM, the RK and the RFR
and new routines for VIDA.

Case 2: when rewriting the software for the CEM and new routines for VIDA.

Case 3: where only the VIDA routines are updated.

4.1 LF and RF usage

There are different uses for both LF and RF which for this thesis could be useful in different
cases. Two-way communication through LF can be useful when having the car at service and

11
the mechanic needs to run a diagnostic. The usefulness with LF in this case is that when using
LF at a short range the remote will not use its own battery. Therefore, it does not matter if
the battery is empty since LF will induce power to it anyway. This gives it better possibility
to find the actual error since low power will not be a problem. By only using RF the battery
life will be lowered since the RF protocol uses more power. But a combination of both LF and
RF is a compromise that can prove to be beneficial due to its versatility. It can be used both
in models with and without KV entailing that only one system needs to be developed. This is
of course a compromise of battery use, reliability due to noise and comfort.

4.2 Case 1

The solutions for the selected problems are software changes since hardware changes are costly
and are hard to implement due to all additional tests needed to be performed. For example, if a
new hardware were to be implemented there is a risk that it will affect and/or interfere with the
already existing hardware which then could decrease (or increase) the performance. However,
software changes in the RK and the RFR are also costly to implement and therefore this section
is the ideal case. When starting a new project it could be possible to implement these changes
from the beginning with almost no cost at all. Implementing these software changes in the
RK and the RFR after they have started to be manufactured is too expensive and therefore
not probable. In order to get a clear view of how to use these functions, in what order to use
them and which component to change, a troubleshooting tree was developed and is presented
in Appendix D

4.2.1 Methods and solutions implemented in the RK

In this section the methods developed for the RK is presented.

Battery Reset Counter: this solution handles problems with poor battery connection in the
RK. Detecting poor battery connection is difficult since there is no indication about its
occurrence except for power loss. The only solution found is to let the RK remember
when the power is lost and report it to the CEM when inserted into the ignition slot.
Since the RK has limited memory the proposed solution is to use a 3 bit counter stored in
a Non Volatile Memory (NVM) and at every battery reset increment this counter. If the
counter has reached seven (maximum value in a 3 bit counter) it shall freeze to prevent an
overflow, thus reporting seven to the CEM. Seven cases for the number of occurrences is
a reasonable choice considering the size of the counter, storage restrictions and possibility
of bad connections during the times the RK is away from the ignition slot.
The enumeration of the counter would preferably be performed in the initiation se-
quence, so if a power reset occurs the counter is enumerated when the RK is restarting.
Using this solution no extra hardware is needed, it is just a software change which was
the goal.

12
 There is also an alternative to the solution where a Random Access Memory (RAM)
is used instead of a NVM. Instead of storing the counter in a NVM an increasing sequence
can be stored in RAM, this will however only indicate that a power reset has occurred but
not how many. The counter starts at zero and is enumerated on every button press, when
it reaches 20 below the top value it shall stop enumerating. Hence, if no power resets
occur, the counter will stay on that value. But if a battery reset occurs, the counter
will be reset, but during the microprocessors initiation sequence the counter is set to 19
below the top value and then enumerates as before with each button press. This roughly
indicates when a battery reset occurred and that is has occurred. When reported to the
CEM, the CEM sends an ACK which then resets the counter to zero again.

Stuck Button: this solution detects if any of the buttons are or have been stuck since the last
service. The solution is based on 5 bits stored in a NVM and 5 bits in RAM, where each
bit represents a different button. The reason for having both a RAM and a NVM is that
the RAM stores the current condition, while the NVM stores the condition since the last
service. The system already has a timer that counts if the button has been stuck for more
than 6 seconds, if so the button is disconnected. As an addition, it shall also set both
the corresponding bits in the NVM and in the RAM if detecting a stuck button. When
the RK later detects that the button is no longer stuck it resets the corresponding bit in
RAM but does nothing with the bit in the NVM. This is reported to the CEM and stored
in the log, when the RK is inserted into the ignition slot. When the mechanic then reads
the log it is possible to see if a button has been stuck. The mechanic is also the only one
able to reset the NVM bit. Hence, they know that if no bit is set then there has been no
stuck button since the last service.

RK history: this function stores the last five commands generated from pressed buttons and
since no important data needs to be saved, the preferred memory type storing the data
is in a RAM. Even if a battery reset would occur and the RK history is lost it will not
make the mechanics’ job harder. If the data is lost the mechanic can easily press five
times on the RK himself to see what is registered. The information from this function
is transmitted by LF when the RK is put into the ignition slot and VIDA is requesting
this information. Using the RK history the mechanic can compare it against the remote
request history stored in the CEM. If they correspond, the problem is located after the
CEM, indicating that the problem is either in the CAN bus, the nodes, the mechanical
locks or some other place.

Key versions: the main reason with this method is to inform the mechanic whether the RK
corresponds to the car or not. If the car has a new RFR and an old RK that do not
match, this function can help to detect the error. It also checks if the current frequency
in the RK corresponds with the value originally assigned in factory. Every hundredth
button press the chip shall compare the value stored in the RK with the given value from

13
 the frequency crystal chip. The assigned frequency shall be stored in a NVM and be
readable by LF. It can also be interesting to store the serial number, manufacturing date
or something similar besides the frequency.

Check internal error: this is a kind of vague function since what it reveals is supposed to be
decided by the RK developers, but its purpose is to display if there are any internal errors
in the RK. The proposed solution includes one byte available for the developers. If there
is limited space a flag could be used instead to report that internal errors have occurred.
When this is read via LF by the CEM and errors have occurred, the CEM store the byte
or flag in the log and set a DTC. When the mechanic later reads the log and get the DTC
the mechanic only needs to see whether the developers have decided if the RK shall be
replaced or not.

LF Diagnose Protocol: this is more of a protocol and a link between the LF-receiver/transmitter
and the RK. With this protocol it shall be possible to retrieve the information from the
RK when requested. Besides reading, it shall also be possible to write to certain variables
in the RK for reset purposes among others.

4.2.2 Methods and solutions implemented in the RFR

In this section the methods developed for the RFR is presented.

CEM not responding (flag): this is just a bit that indicates if the RFR tried to send an
initiation message to the CEM which for some reason did not receive it. This flag is also
set if the CEM receives the message but fails to initiate the LIN-bus. One second after
the RFR tried to initiate communication with the CEM and no response is detected,
the flag shall be set. When the RFR later manage to initiate communication with the
CEM, the RFR shall send the flag telling the CEM that connection was earlier tried to
be established but failed. When the CEM has received the flag it send an ACK to the
RFR which, when received the ACK, resets the flag.

Histogram for Received Signal Strength Indication (RSSI) and time the RFR been
awake: to enable the detection of disturbances, noise and interference, some form of
signal strength from the noise needs to be stored. Since many limitations exist such as
what and how the function can be implemented many of the proposed suggestion was
discarded. However, one solution was considered to be best suitable for this problem.
The solution is based on six counters, five for the different RSSI values and one for the
time the RFR has been awake.
One counter shall be able to count to at least 65535 (which is the largest number in a
2 byte counter) and shall be increased if the signal consists of common background noise.
The four other counters will be increased if the RSSI value corresponds to the range the
four counters represent, which is the average RSSI from 20m, 15m, 10m and 5m. These

14
 four counters need a limit at, at least 255, this also applies for the counter keeping track
of the time the RFR has been awake, further on referred to as time counter. Since timers
are expensive, the time counter is preferably increased when the RFR enters a certain
section in the software representing that the RFR has been awake for more than a certain
time. This is performed when the RFR decides whether the recorded sequence was a valid
WUP or not. A valid WUP yield that the received signal was not just noise; it was a RK
or a similar device transmitting on the same frequency with the same WUP-messages.
All the correct and accepted RK (corresponding to the car) requests will not increase any
counter. By not increasing the counters, this leads to that the RSSI values presented,
represents either other RKs or noise and interference.
For a better understanding see Table 3. The table shows a total of 334 scans (summa-
tion of the counters for 20 m, 15 m, 10 m and 5 m) where the received signal were stronger
than the background noise and out of these, 94 were disturbances. For example, consider
a customer that complains about the car not unlocking unless close enough (5 meters) and
a histogram such as in Table 3 is retrieved. One can infer that some kind of interference
or disturbances are cancelling the signal from the RK or being so much stronger that the
RK signal does not manage to break through. Scanning the ether approximately every
second will fill the buffers after approximately 18 hours, if increasing the scanning rate
to 1.3 second it would last one day. To construct a simple solution an identical set of
counters are added which starts increasing when the first buffer is full. When the second
buffer also is full, the first is erased and restarted. Using two identical sets of buffers
ensures that at least one completely full buffer will be available for the mechanic to read
or to be stored in the log.

Table 3: An example of how the histogram can be presented for the mechanic.

RSSI counters Time counter

Noise 20m (255) 15m (255) 10m (255) 5m (255) RFR been awake
(65535)
65535 49 20 67 198 240
Total number of press: 334 of which 94 were interference or disturbances

Since the RK sends the information on two different frequencies and the suggested
solution only detects noise and interference on one of those frequencies, one frequency has
to be discarded. The frequency used for CH 1 is always used since the RK always send
on CH 1 first. Hence, CH 2 is preferably discarded since that frequency is not always
used. To detect interference on both CH 1 and 2 a duplicate set of counters is needed to
be used. Implying that for detecting interference etc., on both frequencies a total of four
identical sets of counters would be needed which requires a lot of space. An alternative
can be that both CH 1 and 2 are scanned and if only noise is detected the noise counter

15
 is increased once, but if there is a RSSI value on either one or both channels that counter
shall be increased. This however will not tell which channel that has interference only
that there is interference on either one or both channels. Assumptions of which channel
contains interference can be made by using the channel statistic counter. If there is a lot
of interference detected and the channel statistic counter reveals that messages only is
received on CH 2 one can assume that all interference is located at CH 1.
Table 4 shows typical values for when the interference is located at different distances.
In the table some values are bolded, these can be suspected to contain the interference
and disturbance.

Table 4: An example of typical values for the counters for different cases where the interference
and disturbances are located at different distances.

RSSI counters Time counter

Interference distance:
Noise 20m 15m 10m 5m RFR been awake
(65535) (255) (255) (255) (255)
No interference 65535 126 39 24 12 201
5m 65535 49 20 67 198 240
10 m 65535 20 13 154 3 125
15 m 65535 63 176 20 5 185
20 m 65535 212 7 21 13 86

4.2.3 Methods and solutions implemented in the CEM

In this section the methods developed for the CEM is presented.

Log space: since the majority of the proposed solutions detect intermittent problems it is
interesting to know when the problem occurred instead of just knowing that it did. By
having this in mind DTCs are not an optimal solution and therefore a log is more ap-
propriate. The log shall be structured like a rolling buffer, the first event logged shall be
stored at the first position and so on. When log-buffer is filled the oldest event is erased
and replaced by the new one. Another reason for storing the time is, since the events are
stored in a non chronological order the time help arranging the events in chronological
order when displayed. See Appendix B to find out which methods are included in the log.

Rejected message: this solution is to detect why a received message is rejected. If the message
manages to travel all the way to the CEM and then gets rejected by the CEM, it is useful
to know why the message was rejected. The possible reasons to why a message is discarded
are that the RK ID was correct but the encryption did not match, SI counter value does
not correspond, the checksum does not correspond or that the RK ID is incorrect.

16
SI counter values: Since the RK encrypts its SI value it is impossible to know the current SI
value of the RK. To read the value a message will have to be sent from the RK to the CEM,
when requested. The CEM decrypts the message, retrieves the SI value and displays both
the SI value from the CEM and the message, for comparison by the mechanic. The SI
values are displayed in VIDA and depending on if they correspond or not appropriate
action will have to be taken.

Display stuck button on Drivers Information Module (DIM): this solution is mainly
for reducing the amount of unnecessary times the customer has to take the car to the
mechanic. If the DIM shows that a specific button is stuck, the customer can try to
loosen it before calling the mechanic saving time and money for both the customer and
Volvo. Given that the most probable reason for the button to get stuck is dirt or particles
of dust inside the RK, careful cleaning can solve the issue. By giving the customers
the opportunity of cleaning the RK themselves, unnecessary garage visits can be avoided.
Mechanical or electrical problems with the buttons rarely occur; hence it is more probable
that the problem is caused by dirt or something similar.

RFR lets through everything: at some garages there are special boxes for detecting if the
RK is transmitting or not but with this solution this box can be replaced with any other
car that is compatible with that key. It simply disables the filter in the RFR that detects
the valid keys. When the filter is turned on, which is the normal case, the RFR will
discard all RKs which do not have the corresponding ID for that vehicle. On the other
hand, when the filter is turned off, all RKs are let through which makes it possible to
read via VIDA if the RK ID was received or not. If the ID was received the RK works,
in the sense that it can send a message with correct WUP-messages etc., but it does not
reveal if the encryption was correct or not. This is also a way to determine if the RFR is
functional. If a car has problem somewhere with the RK system, by using this function
the mechanic can take another RK from another car and try it. If the CEM receives
the signal the RFR is working but if the CEM is not receiving the message something is
wrong with either the RFR, the LIN or the CEM.

4.3 Case 2

This sections explains the possible solutions when having access to implementing changes in
VIDA and the CEM software. This case, as expected, also incurs into expenses, however they
are less costly compared to Case 1, Section 4.2. When only changing the software in the CEM
it is not possible to get the same accuracy in pinpointing exactly where the problem is located
as in Case 1. However, some of the functions from Case 1 can be used and for some of those
who cannot be used, there are other solutions instead. Case 2 also presents an increase in the
mechanics effort to pinpoint the problem due to that the alternative solution requires measuring
at the components instead of run a program from VIDA. A troubleshooting tree was created in

17
order to establish how, when and in which order the methods should be used, see Appendix E.

Current measurement on the RFR: since the histogram is not available in the cars today,
it is possible to instead measure the current used by the RFR. When the RFR only
polls and there is no signal except background noise the RFR will typically use 10 mA.
Meanwhile, if there is a message with the correct WUP-messages, preamble etc., it will
use approximately 30 mA. But if the message is correct and the RFR woke the CEM and
contact was initiated over the LIN, the RFR will typically use around 130 mA. So by
measuring the current it is possible to say whether the message is received or not.
Some difficulties exist, when measuring over the fuse another car component uses the
same fuse and since that component uses power as well there can be some pollution.
However, the current used by the RFR will still increase with these intervals. Hence,
this method will still be able to use even if it will be harder to detect when the other
component is powered on. It is possible to reduce the pollution by simple procedures, for
example: by removing the DiCE, wait for one minute and lower the background light in
the DIM, these components will use less power and therefore reduce the pollution. This
solution however only gives the current status whether there is disturbances or not, which
means that the disturbances that may be at the customers house will not be detected.

Communication detected on LIN: this instructs the CEM to monitoring LIN constantly
and if anything is sent over LIN, it will be indicated in VIDA. If something is transmitted
over LIN the RFR works, implying that the problem is either in the RK, the CEM or
after the CEM.

4.4 Case 3

In this third case, only the instructions in VIDA can be changed, implying that these restrictions
make it difficult to pinpoint the exact component to replace. However, it will give a clearer
view of in what area to start looking. Compared to today’s case when the mechanic has to
guess, this will at least give the mechanic a way to determine whether it is the RK, the RFR
or the CEM that shall be changed. In some cases there can be either one of them and then the
mechanic will have to replace the cheapest one first. For getting a clearer view of how to use
these functions, in what order to use them and which component to change, see the developed
troubleshooting tree in Appendix F.

5 Other improvements
During this thesis work other improvements were found but not fully investigated. It could be
concluded that the channel statistic could be improved, as well as including repetition code and
interleaving to gain time diversity and also the self synchronization for the SI counter. These
sections describe some thoughts that can be used to improve these subjects but were not fully
investigated.

18
5.1 Repetition code and interleaving

As an extra task, an investigation about different modulation techniques, repetition code and
interleaving were performed because the work was completed ahead of schedule. To model the
system a Rician Channel is used as the communication link between the RK and the RFR.
A Rician channel was chosen because the signal, when testing the RK at Volvo, has Line Of
Sight (LOS) which would make it possible to compare the result from the test at Volvo with the
simulations. However, the comparison is not performed in this thesis. Since this is a model of
the reality it was decided to disregard the reflections and scattering experienced by the signal
when travelling through the glass and chassis to the RFR, placed inside the car.
In a study performed by US roads it is claimed that the average walking speed for older
people is approximately 1.25 meters per second and for younger people 1.51 meters per second
[18]. To get a value between these two values, the speed of 1.4 meters per second was chosen,
which is close to what the Swedish transport administration use in their calculations [19].
This value is needed to estimate an average Doppler shift that can be used in the simplified
Matlab model. The intention with the simulation was to demonstrate the advantages with using
repetition code and interleaving compared to not using it. The simulation was also suppose to
confirm that switching to GFSK instead of Pulse Amplitude Modulation (PAM) which was used
in an older system, was a good decision.
Instead of writing all equations and creating own functions it was decided to use Matlab’s
communication toolbox which probably saved a lot of time and got rid of many human errors
when creating the Rician channel. However, the knowledge of how the communication toolbox
works were limited which became an issue. More about the problems can be read in Section 6.
What can be said is that in theory interleaving and repetition would perform better than
not using it. In this case the suggestion is to repeat the 64 encrypted bits which is located in
the data link payload of the RF protocol header, see Figure 5, and send them with the rest of
the message. By adding a repetition of 3 and interleaving the time for sending that sequence
would be approximately 22 ms longer which is an increase of almost 70 %, calculated with the
bit rate used today. By increasing the bit rate to from 5.76 kbit/s to 7.62 kbit/s, which is the
highest bit rate that the existing hardware can manage, the total time with repetition would be
41.2 ms which is only 8.9 ms slower than what is used now (32.3 ms). So if the time is the only
thing taken into account then there is no problem implementing repetition and interleaving.
This increase of data that need to be transmitted results in the sending time being 27.5 %
longer, resulting in that the battery will last shorter time. However, the decrease of battery
time is not equal to 27.5 % since the WUP-message is sending for 166.7 ms and is the one that
drains the most power. So if having a scenario where in normal case two comfort frames (one
for each channel) will be sent, there will be 2 complete WUP-messages and 4 frames. Without
repetition and interleaving it would take 462.6 ms of sending time, and with repetition and
interleaving it would take 501.8 ms which is only 8 % more. This means that the battery life
would decrease with at most 8 % but taking into account that the microprocessor drains battery

19
even in standby mode and that the battery itself loses capacity only by aging, the total battery
decrease is certainly less than 8 %. Only considering sending time and battery life, adding
repetition code and interleaving will not cause any problem.
By using repetition and interleaving, extra redundancy is added. By saving the demodulated
message from CH 1 and CH 2 a third message with a different interleaving distance and more
repetition can be constructed. If the first message contains errors and the second message also
contains errors, the probability of these errors occurring at the exact same bits is low. Hence,
when constructing a message with double repetition the decryption will be better and the errors
will be corrected. Since the third redundancy message would consist of 6 repetitions the majority
decision will not work if using hard decision decoding. However, if using soft decision decoding
the majority decision could still be used.

5.2 Channel statistic counter

The channel statistic counter uses two different counters each counting to 255. If the message is
received on CH 1 counter one will be increased and counter two decreased, which are from the
beginning 128 and 127. The problem today is that the RFR does not inform the CEM that the
message was received on CH 2 if it was correctly received on CH1, which makes the counters
quickly adopt the values 255 and 0. There are different solutions to this problem. Instead of
just sending the channel where the message was received first, a message can be sent when both
messages are or should have been received telling which channel the message was received at. If
the message was received at both channels none of the counters are increased. A second, slightly
different alternative could be to let the RFR check if the both message were received and skip
sending the information of which channel it was received and just sending the message to the
CEM. If it just received the message on one channel it sends that information to the CEM.
Or a third alternative could simply be, changing the position of the channel statistic counter
from the CEM to the RFR instead. By doing this the information sent on the LIN bus will be
decreased. The RFR can in fact easier keep track on which channel it received the message.
When the mechanic wants to know how the channels have been used, the mechanic only needs
to command the CEM to request the statistics from the RFR and display it in VIDA.
By doing a small scale investigation it was concluded that the majority of all the counters
seen in Figure 6 had become 255/0. In other words, it is only receiving on CH 1. For those
counters the channel statistic does not provide any more information. Since even if the message
once only would be received on CH 2 it would be overwritten next time the message is received
on CH 1 again. What is interesting from the investigation is that there are a few cars which only
receive the messages on CH 2. One conclusion drawn is that by using two channels, problems
for these cars have been decreased. However, they probably have more problems than other
customers with two working channels.
If a working channel statistic counter like the third alternative would be used and scanning
for both frequencies it could be possible to use it in combination with the RSSI histogram and

20
to determine on which channel the interference was detected.

Typical values of the Channel Statistic Counter

350

300

250
Number of cars

200

150

100

50

0
CH 1 / CH 2 CH 1 / CH 2 CH 1 / CH 2
00 / FF 80 / 7F FF / 00
Only receiving on CH 2 Receiving on both CH 1 & 2 Only receiving on CH 1

Figure 6: Diagram over the channel statistic counters from the cars in the investigation.

5.3 Self synchronization for the SI counter

In Figure 7 the proposed procedure for synchronizing the RK SI value with the SI value stored
in the CEM is presented, this solution builds on a simplified version of Microsoft Challenge-
Handshake Authentication Protocol v.2 [20]. Due to lack of probability for the SI value becoming
invalid and security reasons this implementation was not developed further. It was decided that
the risk of lowering the security was worse than possibly having a RK changing its SI value
too much. By using this kind of synchronization the RK SI value can be lower than the value
in the CEM and after the synchronization the value would correspond. But if someone would
have eavesdropped and recorded a message it would just be to replay it near the car resulting
in that the car would unlock. The probability that this would happen can be considered low,
but it is not worth the risk and that is the reason why developing this implementation was not
continued. However, if someone with more knowledge about cryptography would have a look
at it; it may be possible to develop something similar not lowering the security. Another reason
for not developing this further is, in those cases SI values becomes invalid it is better to know
that it has occurred than hiding the problem.

21
RK CEM
Key ID Key ID
Secured Key Secured Key

AES(Wrong SI value)

AES(Challenge 1 from the CEM)

AES(hash(Secured Key || challenge 1) || RK challenge)

AES(hash(Secured Key || RK challenge) || challenge 2 from the CEM)

AES(hash(challenge 2 || SI value))

Figure 7: Suggested procedure for the self synchronization if the SI counter value has become
invalid.

6 Encountered problems
During this thesis many small issues have occurred, but one major was in one of the specifications
from Volvo. The specification stated that the system needed more than 11 bits of all WUP-
messages (each WUP-message is 8 bit long). However, this was poorly described in a table and
it was assumed that the system needed more than 11 WUP instead of bits. When performing
simple calculations it makes more sense that it shall be 11 complete WUP instead of bits. With
11 bits the total wakeup time would be approximately 2 ms and with 11 WUP-messages the
total wakeup time would be approximately 15 ms. Since the RFR poll every 148.1 ms and the
RK sends with a length of 166.7 ms, see Figure 4 and Table 2, this implies that if the RFR
needs more than 11 WUP it needs 15 ms of overlap to ensure that the RFR wakes up. This
leaves around 3 ms to initiate the system etc. However, if the RFR only needs more than 11
bits it only needs an overlap of 2 ms to ensure that the RFR is awake, which means that the
initiation sequence for the RFR would take almost 16.5 ms which does not seem reasonable.
Another encountered problem was the simulation of the system where repetition code, inter-
leaving, GFSK, Manchester code, different frequencies and much more should be implemented.
Since this simulation was supposed to be something Volvo could reuse later it was decided to
only use built-in Matlab functions. The decision was based on that the person using it later
would be able to better understand the code since there is help for Matlab’s functions but with

22
own written functions commenting is extremely important. Using the built in communication
toolbox turned out to be a big issue and since something is wrongly implemented, the verifica-
tion the simulation was supposed to provide could not be presented. However, the theoretical
knowledge and the suggestions still exist but verifying it would have contributed to determine
exactly how much the system would have gained. A big issue was that the channel compensation
could not be performed as in theory, by using the conjugate of the channel and multiply with
the received signal. The biggest issue was probably when agreeing to add this extra task to the
master thesis the extent of the simulation was estimated to low. To make a correct and fully
working simulation much more time is needed. Another big issue was also the simulation time,
one simulation when using 1000 iterations of each Signal to Noise Ratio (SNR) takes between
two and three days. If instead running the simulation until at least one error occurs for each
SNR the simulation can take more than one week. A more powerful computer and Matlab that
can use all cores and not only one would improve the usage and the troubleshooting of the
simulation.

7 Conclusion
In this thesis an investigation of new methods for troubleshooting Volvo cars has been performed.
The conclusions that can be drawn from this thesis are that it is possible to implement many
troubleshooting functions by only changing the software. All these software changes can be
of great help for both the mechanics and the developers. For the developers many of these
functions can be used for finding possible errors before the system is released while for the
mechanics to discover which component to change. By simple means the possibility of finding
the faulty component has increased tremendously even for those cars where only the routines
in VIDA will have been changed. It can also be concluded that finding simple means to detect
intermittent problems is hard since it often require much storage or computational capacity
which is not always possible to due to restrictions with battery time (power consumption), cost
and size. As stated in Section 1.1 the remote system should be divided into at least four areas
and the proposed troubleshooting methods cover all those four areas, even if some less than
others. The hardest area to cover and make a good method was the wireless channel since
detecting disturbances that occur over time when not having much storage or computational
power is very hard.
For the RK the proposed solution will help the mechanic pinpointing the problem. Using
these solutions many unnecessary parts earlier changed will not need to be changed. Since when
using these solutions the faulty part can be located and changed, instead of guessing and change
parts random. This will help Volvo save a lot of money since they pay for all spare parts and
services the first years, affected by the warranty. It will also help saving the environment. By
implementing these functions it is possible to locate when the problem is caused by the RK and
replace it. The greatest contribution with the solutions for the RK is that they focus on finding
intermittent problems earlier undetected.

23
 To detect intermittent problems of interference when the customer leave their car for service,
the histogram can be used. When reading the histogram indications of disturbances is displayed
giving the mechanic possibility of decide whether it is a fault in the car or just interference at
the customers location.
The proposed solutions for the CEM, has as main purpose to store the information from the
other functions and to help the mechanic by displaying the stored information. To simplify for
the costumer, one solution is to display simple errors in the DIM which will save time for both
the customer and the mechanic and money for Volvo.
Beside all the developed methods, three troubleshooting trees were developed to establish in
which order all methods should be used. Specification for how the methods and the functions
in VIDA should be designed has also been developed.
By adding repetition and interleaving the BER can be lowered and an extra redundancy
implemented. The cost for implementing this is an 8.9 ms longer response time and less than 8
% battery losses.

8 Discussion
Even if some of these implementations may cost a lot to implement, that cost will probably be
saved later since the number of faulty replaced spare parts will be lowered. Since Volvo pays
for those parts the first years, a lot of money can be saved. Not only with the cost for the
parts, but also for the work performed by the mechanics. Since if it takes less time finding
the faulty part and change it, the less the cost per car for Volvo. With faster service more
cars can be serviced during the same day, providing a good service for the customers. Since
knowing that the repairs only takes a short while, the customer can leave the car during the
morning and collect it e.g., after work, thus not needing to be without their car for a long time.
If these solutions are implemented in the next generation of RK before everything is created,
manufactured and placed in the factory, the cost for implementing these features will be small
compared to implementing them later.
In retrospect it can be concluded that using the built in functions in Matlab for the sim-
ulation, was a wrong decision. If in advance, knowledge of the long computational times and
complexity would have been known, the decision would have been to write all equations as own
functions to have a better control over them. The risk for human errors would have increased,
however it would have been easier to troubleshoot since knowledge of the code structure would
have been better.

24
9 Further Work
Since the simulation program did not become completely finished there are a few more things
that could be implemented. First adding the correct frequencies and add so that the second
message is sent on CH 2. When that is implemented the combination of the first and the second
message could be implemented so that a Bit Error Rate (BER) curve can be plotted for the
extra redundancy. To make the simulation work even better, different modulation techniques
could be implemented so that it is easier to compare between the BER of e.g., PAM and GFSK.
The main improvement is that the code needs to be optimized since for the moment a simulation
can take up to three days which is not good.
As discussed in Section 8 the code is preferred to be rewritten using own functions which
would improve the simulation time tremendously. Since this simulation were more time consum-
ing then from the beginning thought, a recommendation would be to create a more reasonable
time plan and if still considered valuable outsource the development to another company.

25
References [13] Motorola - tz0052, Digital DNA,
“LIN protocol description,” http:
[1] VIDA startguide, Volvo Car Corporation,
//[Link], May 2003, Power
2011.
Point, Accessed on 2012-11-29 10:38.
[2] Instruktioner för VIDA-prenumeration,
[14] CiA, “Controller area network - device de-
Volvo Car Corporation, 2012.
sign,” [Link] accessed on
[3] E. Fritzson, “SJB CEM 6B Remote Con- 2013-01-08 11:54.
trol 042 01 VCC,” Apr. 2007, unpublished
[15] The Swedish Post and Telecom Au-
Volvo document.
thority, “Radiostörningar - fjärrkontrollen
[4] E. Lundberg, “NOTE SRD 31804382 017 fungerar inte?” [Link] ac-
01 Remote 111024,” Jan. 2009, unpub- cessed on 2013-01-23 09:58.
lished Volvo document.
[16] The Free Dictionary. Radio frequency.
[5] R. Obermaier, “Keys Device spec internal [Link] The
AB,” Nov. 2006, unpublished Volvo docu- Free Dictionary. Accessed on 2013-01-17
ment. 15:20.

[6] G. Stani, “Continental - Volvo P1007 [17] National Encyclopedin, “Långvåg, low fre-
RK,” Aug. 2008, unpublished Volvo doc- quency,” [Link] accessed on
ument. 2013-01-15 15:20.

[7] Chipcon, “CC1070 Single Chip Low Power [18] TranSafety, Inc., “Study Compares Older
RF Transmitter for Narrowband Sys- and Younger Pedestrian Walking Speeds,”
tems,” Datasheet, Jan. 2010. [Link] accessed on
2012-11-29 08:34.
[8] S. Emborn, “QTT P1 MY08 - RKE - Out
of sync,” Mar. 2008, unpublished Volvo [19] The Swedish Transportation Authority
document. and Banverket, Förstudie Kiruna, ny
järnväg, 2005, ch. 15 Tillgänglighets-
[9] Aunkofer, “TRX Y28x DeviceSpec AC fi-
analys resecentrum, pp. 57–64.
nal,” May 2006, unpublished Volvo docu-
ment. [20] B. Schneier, Mudge, and D. Wagner,
“Cryptanalysis of Microsoft’s PPTP Au-
[10] J. Schmid, “CEM TRX Serial Inter-
thentication Extensions (MS-CHAPv2),”
face Specification,” Jul. 2008, unpublished
October 1999.
Volvo document.

[11] S. Hammes, “Y28x RF Systemspec,” May

2006, unpublished Volvo document.

[12] LIN Sub BUS, “Technical Overview

of LIN,” [Link] ac-
cessed on 2012-11-28 09:28.

26
 A Possible problems

Possible problems Chosen Solution

problems already exists
Remote Key:
Poor battery connectiont X
Battery is out of power X
Short-circuit due to moist environment
"Short-circuit due to salt from sweaty environment"
Antenna broken
Buttons stops working X
Buttons stuck X
The crystal is broken
Encryption error X
Modulation error
Forgets ID number
PLL calibration in CC1070
Increment SI in a wrong way X
Short-circuit, RK works but drains battery very fast

Radio Frequency Receiver:

Too many bit errors X
Too few WUP is received X
Antenna broken
"Synchronization error due to incorrect preamble"
Recognition error X
CEM do not respond and therefore never initiate LIN X
Poor cabling contact X
Connections affected by verdigris X
Cabling short-circuit to ground X

Central Electronic Module:

Loses memory of valid key ID’s X
Interference on LIN-bus
Decryption error X
Noise, message not recognized
Communication error with nodes du to error on CAN bus X
Increment SI in a wrong way
CEM hang due to car battery power too low

Other Errors:
Cable harness errors in or to car doors X
Hood sensor error
"Car battery empty or looseness with cables" X
Software error which create infinite loop where CEM waits for a
register to adopt a value before exiting the loop.
Trunk opens when inserting RK in ignition slot whereby the car
won’t start
Wrong RK frequency from factory X

i
Written by: polsso10 2012-11-12
Last saved by: Per Olsson

B Specification for the equipment

Battery Reset Counter
Remote Key
Purpose: Count how many battery resets that has occurred since an ACK was received.
Requirements: A counter that is triggered every time a battery reset has occurred, this value shall be stored in a
Non Volatile Memory, NVM, to ensure that it is not erased when a battery reset occurs. The
counter shall, preferably, count to at least 7 if maximum value is reach then it shall stay at that
value until reset. Resetting the counter shall only happen when an ACK-message is received.
Functions: Would be implemented in RK diagnostic in VIDA.
Alternatives: If there are problems with saving in a NVM an alternative, however not as good as the first
suggestion, is to save it in RAM instead. The implementation would then have to be change, the
alternative consists of a counter that counts up on every button press and when the counter
reaches the highest value minus 20 it shall freeze on that value. If a battery reset occurs the
counter shall be set to highest value minus 19 and continue to count up on every button press.
Reset to 0 shall only happen when an ACK-message is received

Stuck Button
Remote Key
Purpose: Indicate if any button is stuck or has been stuck.
Requirements: 5 bits (one for each button) which are stored in a NVM and 5 bits (one for each button) which
are stored in RAM. The already existing counter that checks if a button is pressed more than 6
seconds will be used to set the bits. If a button is pressed for more than 6 seconds the counter
tells the RK to ignore the press and at the same time it also sets both the corresponding bits to
indicate that that button has been stuck. Reset for the RAM-bits occurs when RK detects that
the button no longer is stuck. Resetting the NVM-bits is done manually by the mechanic when
the car is in for service. This shows the mechanic that a button has been stuck since the last
service.
Since there is no timer in RK, a counter counting the number of button presses since the button
was stuck can be of use to get some indication when it occurred. The counter can also be stored
in RAM and be reset when the button is released.
Functions: Would be implemented in RK diagnostic in VIDA.
Alternatives: If there is limited space then this can work with only 2*3 bits, 3 bits for NVM and 3 for RAM.
001-101 represent the different buttons. 110 indicates that two buttons are stuck and 111 if more
than two buttons are stuck, this is however less robust.

RK History
Remote Key
Purpose: Stores the last 5 commands that were generated from a pressed button.
Requirements: Save latest 5 commands (5 bits per command) sent or should have been sent, preferably saved
in RAM.
Functions: Would be implemented in Read last RK command in VIDA
Alternatives: If there is limited space the number of stored values could be decreased. If further reduction is
needed 3 bits instead of 5 can be used, where 001-101 represent the different buttons.

Key Variants
Remote Key
Purpose: Check that the RK frequency corresponds to that car.
Requirements: Store the type of key in a NVM and on every 100 button press, the key shall compare the stored
value with the value in the frequency/crystal chip. If the value does not correspond then set the
internal error flag. The value stored in the NVM shall also be able to read from via LF so that
the mechanic can check that it is the correct key to that type of car.
It could also be interesting to store the serial number or manufacturing date or something
similar so it can be checked whether the RFR and RK are compatible or not.
Functions: Would be implemented in RK diagnostic in VIDA.

ii
Written by: polsso10 2012-11-12
Last saved by: Per Olsson

LF Diagnose Protocol
Remote Key
Purpose: Act as a link between the RK functions and LF receiver
Requirements: Shall be able to read Battery Reset Counter, Stuck Button, Key Variants and any other internal
errors, that the manufacturer recommends, and possibly Initiate RK Command via LF. This is to
be done when the message "RK Diagnose" is received via LF and then the information will be
transfer via LF. It shall also be able to reset the Battery Reset Counter when an ACK is
received.
When "Last RK Command" is received via LF shall it read the RK History and send it back via
LF
Functions: RK Diagnose and Last RK Command

CEM not responding (flag)

Radio Frequency Receiver
Purpose: Indicate that RFR tried to send a message to CEM which for some reason did not wake up
Requirements: When RFR tries to communicate with CEM, which for some reason does not reply, a flag is set.
This flag is set if CEM has not answered within 1 second. When CEM awakes and wants to
communicate with the RFR then the RFR shall first reply and say that it tried to send a message
but CEM never answered and after that send the information that CEM asked for. However if a
request for open/lock the door is received then RFR shall first send that information to CEM
and after that send the message that RFR tried to communicate with CEM.
Functions: Log
Alternatives: A bit can be added to the sequence that is transferred from the RFR to CEM so that CEM
always know if something has happened. If the bit is 0 then everything is ok and if it is 1 then
RFR has tried to communicate with CEM.

Histogram for RSSI and time RFR been awake

Radio Frequency Receiver
Purpose: Detect if there has been any intermittent disturbances
Requirements: 6 counters (5 for RSSI and 1 for time) 1 that shall be able to count from 0 up to at least 65535
(Counter 1, C1) and 5 that shall be able to count from 0 up to at least 255. Counter 1-5 belongs
to the RSSI values and C6 belong to the time RFR is awake. These counters shall have a
doublet so one set of counters is written/enumerated first and then the others. The RFR scans
the ether every seventh (To Be Determined, TBD) TDuty1 ms and scans for TPC1/TPC2 ms. The
received data is then processed and the RSSI is calculated and compared to the different
intervals to decide which counter to incremented. C1 will be enumerated if the RSSI < W, C2
will be enumerated if W < RSSI < X, C3 if X < RSSI < Y, C4 if Y < RSSI < Z and C5 if RSSI
> Z. C6 is incremented when the RFR has entered the code section that determines whether is
was a correct WUP-message or not. If it was correct then C6 is enumerated else it's not.
If the received signal is an authorized signal, then no one of the counters shall be incremented.
But if there is a correct WUP and preamble but incorrect key ID then the counters shall be
enumerated.
When one of the counters reaches its top value, all counters shall freeze and the old data from
the doublet register shall be reset to 0 and restart incrementing the counters.
When a request comes for reporting the histograms both the histograms, the one that is complete
and frozen and the other that is recently started, shall be reported.
The histogram can be saved in RAM.
Functions: Log and Read Histogram

iii
Written by: polsso10 2012-11-12
Last saved by: Per Olsson

Log space
CEM
Purpose: Detect problems that has happened before
Requirements: Shall be able to store a sequence of data in a buffer and when the buffer is full, the oldest
sequence is overwritten. The sequence that shall be able to store is. Global time (4 Bytes),
Battery Reset Counter (3 bits), Stuck Button (5 bits), CEM not responding flag (1 bit),
Histogram for RSSI and time (14 (or 7) Bytes), Rejected Messages (3 bits) and if there is
anything else that the manufacturers suggest.
This is preferably stored in a NVM to ensure that the information is safe even if a reset would
occur. Total: 20 Byte (19 Byte and 4 bits)
Functions: Would be read by a VIDA function
Alternatives: Entries that is a minimum to store for detecting intermittent problems: Global time (4 Byte),
Battery Reset Counter (3 bits), Stuck Button (5 bits), Histogram for RSSI and time (7 Byte),
Rejected Messages (3 bits).

Rejected messages
CEM
Purpose: To see why a message is being rejected
Requirements: When requested; store the reason why a RK message was not accepted, multiple reasons shall
be able to store. The reasons are that the message was rejected because: Correct ID but
encryption did not match, SI counter values do not correspond, Checksum do not correspond,
Wrong ID

SI counter values
CEM
Purpose: Check if the SI counters value corresponds.
Requirements: When requested decrypt RK message and return RK SI value and CEM SI value

Show stuck button on DIM

CEM
Purpose: Enlighten the costumer that a button on their key is stuck.
Requirements: 3 seconds after the costumer has started the engine, use LF to read if any of the buttons are
stuck. If there is any then display a message in the DIM saying that "Button XXX is stuck,
please release it after the engine is turned off".

Check internal error

Remote Key
Purpose: Indicate if there are any internal errors in the RK
Requirements: Allocate 1 byte that the RK developer can use for detecting internal errors. 10 seconds after the
costumer has started the engine, use LF to read if there are any internal errors from the "internal
error byte". If there is any then set an error code saying "internal error RK".

RFR lets through everything

CEM
Purpose: Remove the filter in RFR so that it won't reject any message
Requirements: When instructed CEM sends an updated version of the RFR config where the filter bit is set to 0
so everything is let through after 20 (TBD) seconds send the original config file so that the filter
is set to active again. If this routine is called again before the 20 seconds is over then what is left
of the first 20 seconds shall be discarded and a new time period of 20 seconds shall be started.

iv
Written by: polsso10 2012-11-12
Last saved by: Per Olsson

When to log
CEM
Purpose: Describe when to save different information to CEM's Log Space.
Requirements: When the driver's door is opened with a key then CEM shall send a request for Histogram from
RFR and CEM not responding flag. When received the information store it to Log. Wait 10
(TBD) seconds after the engine has started and requests the RK information and store it to the
same log place as the other information.
If CEM receives the "CEM not responding"-flag save the event.
If a RK message is rejected then save the reason.

When to read from RFR

CEM
Purpose: Describe when to read the information from RFR
Requirements: Read the information from RFR:
- when the driver door is opened with the key.
- 10 seconds after the engine has started

When to read via LF

CEM
Purpose: Describe when to read the information from RK via LF
Requirements: Read the information from RK:
- 10 (TBD) seconds after the engine has started
- 1 (TBD) second after the driver door is opened with the key and key position is set to "key in
slot".

What to read from RFR

CEM
Purpose: Describe what parameters that shall be read from RFR.
Requirements: The different parameters that shall be read from RFR are:
- CEM not responding flag
- Received Signal Strength Indication histogram

What to read from RK

CEM
Purpose: Describe what parameters that shall be read from RK.
Requirements: The different parameters that shall be read from RFR are:
- Battery Reset Counter
- Stuck Button
- Button history
- Key Variants

v
Written by: polsso10 2012-11-12
Last saved by: polsso10

C Specification for VIDA

Read Log
VIDA - CEM
Purpose: Being able in an easy way to read and understand the values stored in the log in CEM.
Requirements:
1) Read the result from the log in CEM
2) Display the result as follows
a. For global time; read the current value for CEM and read the value from the log, recalculate
the value and display it as YYYY-MM-DD hh:mm:ss
b. For the Battery Reset Counter read the value and display it, if it is larger than 0 highlight the
number.
c. For the Stuck Button value, read and display it and if a button is stuck then highlight and
display it. Translate the binary number to the name of the button e.g. Unlock button.
d. For CEM not responding flag just show: CEM responds to RFR: Yes/No.
e. If any message has been rejected, display why. Correct ID but wrong encryption, SI counter
value to high/low, Checksum not corresponding or wrong ID
3) Ask the mechanic to search for any error in the log, such as Battery Reset Counter larger than 0
etc.
4) Give the mechanic 6 choices
a. Battery Reset Counter > 0: Change RK or alternative try to bend the spring.
b. Stuck button: Change RK or alternative try to loosen it.
c. CEM responds to RFR – No: Contact Help Desk
d. Rejected message: Contact Help Desk
e. No errors logged: Give the mechanic a choice: is the problem a permanent or an intermittent
problem. Continue with the troubleshoot tree.

RK diagnose
VIDA – Remote Key
Purpose: Run a self diagnose on the RK to determine if anything is wrong with the key.
Requirements:
1) Ask the mechanic to place the RK in the backup reading slot and close all door.
2) Verify that doors are closed.
3) Activate the LF transponder check routine in CEM.
4) Wait one (TBD) seconds or until routine is finished
5) Read LF transponder, check status from CEM.
6) Activate the RF self diagnostic routine in CEM.
7) Wait two (TBD) seconds or until routine is finished
8) Read out results from RF self diagnostics in CEM.
9) Display status of the listed parameters.
a. Looseness with the battery: Yes/No
b. Wrong key model: Yes/No
c. Buttons stuck: display the name for which buttons or what button that is stuck if none is stuck
display "None".
d. SI values corresponds: Yes/No
e. Low Battery: Yes/No
f. RK Detected: Yes/No
g. Valid key in slot: Yes/No
h. RK ID is: Show RK ID
i. RK model is: Show model type and model/manufacture nr?
j. No errors (Only displayed if no errors exist)

vi
Written by: polsso10 2012-11-12
Last saved by: polsso10

10) Give the mechanic a maximum of nine choices:

a. Change remote (If wrong key model = yes, else display nothing)
b. Try to bend the spring else change the remote (If Looseness with the battery = yes, else
display nothing)
c. Try to loosen them else change the remote (If Button stuck != none else display nothing)
d. Contact Help Desk (If SI value corresponds = No, else display nothing)
e. Change battery (If Low Battery = yes, else display nothing)
f. Use troubleshooting methods for "car does not start" (If RK detected = no, else display
nothing)
g. Run Rejected message diagnose routine (If valid key in slot = yes, else display Use
troubleshooting methods for "car does not start")
h. Run RK history (If no errors occurred)
i. Read out once more (start from 3))

Rejected Message
VIDA - CEM
Purpose: Display why the message were rejected
Requirements:
1) Ask the mechanic to make sure all doors are closed
2) Verify that all doors are closed
3) Call the routine "RFR lets through everything" from CEM.
4) Wait 10 (TBD) seconds.
5) During these 10 seconds ask the mechanic to press one of the buttons on the RK
6) When the times up read the result
7) Display the result of the listed parameters
a. Display: The message was rejected because: display the reasons why the message was rejected
and if the message was not rejected, then display nothing.
8) Give the mechanic 5 choices. Depending on where in the troubleshooting tree this function is
called, different answers/choices will have to be displayed.
f. If correct ID and rejected reason is "Correct ID but encryption did not match" display: Contact
Help Desk else display nothing
g. If correct ID and rejected reason is "SI counter values do not correspond" display: Contact
Help Desk else display nothing
h. If correct ID and rejected reason is "Checksum do not correspond" display: Contact Help Desk
else display nothing
i. If wrong ID display: Check that the key belongs to the car otherwise contact Help Desk
j. If nothing is received display:
If there is a valid key in the ignition slot then the antenna is probably broken, replace the RK.
If nothing is received from either the main key or the spare key read the Received Signal
Strength Indication.
If the message is received but the key used is another working key valid for that model, then
run a RK diagnose on the incorrect keys.
If the message is not received even when using a key that is valid for that car model, then
check if CEM awakes.

vii
Written by: polsso10 2012-11-12
Last saved by: polsso10

RK (History)
VIDA – Remote Key
Purpose: Display the last command generated by a button press.
Requirements:
1) Ask the mechanic to press a sequence at the RK that he will be able to remember
2) Ask the mechanic to place the RK in the backup reading slot.
3) Activate the LF check routine
4) Wait one (TBD) second or until routine is finished
5) Read the LF transponder check status
6) Activate the read RK history diagnose routine in CEM
7) Wait one (TBD) second or until routine is finished
8) Read the result from the RK history diagnose routine
9) Display the information in chronological order.
a. Last button pressed: name of the button, e.g. lock or unlock
b. 2:nd last button pressed: name of the button, e.g. lock or unlock
c. 3:d last button pressed: name of the button, e.g. lock or unlock
d. 4:th last button pressed: name of the button, e.g. lock or unlock
e. 5:th last button pressed: name of the button, e.g. lock or unlock
10) Give the mechanic two choices: Did the history correspond to the sequence pressed? Yes/No
a. Yes: Continue in the tree (Read the Received Signal Strength Indication)
b. No: Change the RK

Read the Received Signal Strength Indication

VIDA - CEM
Purpose: Display the histograms that are generated in RFR.
Requirements:
1) Activate the histogram diagnose routine in CEM
2) Wait one (TBD) second or until routine is finished
3) Read the result from the histogram diagnose routine in CEM
4) Sum counter C2, C3, C4 and C5 to X
5) Divide X with C7 convert to percent
6) Divide C2/C7, C3/C7 C4/C7 and C5/C7 and convert to percent
7) Read the Channel statistics from CEM
8) Check the status of the Channel Statistic. If Channel 1 has received more than 90 % (TBD) of
the messages than its okay. Else if Channel 2 has received more than 90 % (TBD) of the
messaged then it's bad since then channel 1 almost never works. Else if in between then neither
good nor bad.
9) Display as follows
Interference within 20 m: percentage from C2/C7
Interference within 15 m: percentage from C3/C7
Interference within 10 m: percentage from C4/C7
Interference within 5 m: percentage from C5/C7
Out of these were "percentage from X/C7" % other RK and "100- percentage from X/C7" where
interference
If CH1 > 90 % then display: nothing
else if CH2>90 % then display: Due to some reason this system is extra sensitive for
interference or RFR does not awakes in time. Try to find if the costumer has added anything
that can interfere with the equipment else call Help Desk.
else display: Due to some reason this system is sensitive for interference.

viii
 D Troubleshooting tree for the ideal case

Are t h e r e any DTC? S t o r e a l l i n f o r m a t i o n t h a t can be l o s t b e f o r e s t a r t i n g t o t r o u b l e s h o o t .

Y: Go t o t h e s e c t i o n t h a t t e l l what t o do f o r t h e s p e c i f i c DTC.
DTC: RFR do not r e s p o n d
DTC: LIN bus c o n n e c t i o n broken
DTC: CAN bus c o n n e c t i o n broken
N: Open t h e d i a g n o s t i c s e r v i c e , a r e t h e r e any i n t e r m i t t e n t p r o b l e m s l o g g e d ?
Looseness in the battery
Change RK o r t r y t o bend t h e s p r i n g s
Button s t u c k
Try t o l o o s e i t e l s e change RK
CEM d i d not awaken and i n i t i a t e d LIN when RFR t r i e d t o send a message .
Contact Help Desk
C o r r e c t ID but wrong e n c r y p t i o n
Contact Help Desk
No p r o b l e m s l o g g e d
Does i t a l w a y s happen t h a t t h e c a r won ’ t open with t h e RK?
Y: Does t h e s p a r e RK work ?
Y: Run RK d i a g n o s t i c ( on t h e i n c o r r e c t RK)
Looseness in the battery
Change RK o r t r y t o bend t h e s p r i n g s
Incorrect frequency
Change RK and c o n t a c t Help Desk
Button s t u c k
Try t o l o o s e i t e l s e change RK
S I v a l u e t o h i g h / low
S y n c h r o n i z e i f p o s s i b l e e l s e change RK and c o n t a c t Help Desk
Low b a t t e r y power
Change b a t t e r y
No RK d e t e c t e d
T r o u b l e s h o o t a s s t a r t i n g problem
V a l i d key i n s l o t ?
Y: Run RFR l e t s t h r o u g h e v e r y t h i n g and c h e c k i f and why t h e message i s d i s c a r d e d
Message d i s c a r d e d s i n c e wrong e n c r y p t i o n
Contact Help Desk
Wrong checksum
Contact Help Desk
Message d i s c a r d e d s i n c e wrong ID
Contact Help Desk , c h e c k s o i t i s a c o r r e c t key and not t h e n e i g h b o u r s key
Message d i s c a r d e d s i n c e wrong S I v a l u e
Contact Help Desk
Message n e v e r r e c e i v e d
Antenna ( p r o b a b l y ) broken , change RK
N: T r o u b l e s h o o t a s s t a r t i n g problem
No problem found
See i f t h e b u t t o n s work , i s t h e r e any broken ?
Y: Change RK
N: Are t h e r e any n o i s e ? Read t h e h i s t o g r a m .
Y: Try t o l o c a t e where i t comes from
N: C a l l Help Desk
N: Run RFR l e t s t h r o u g h e v e r y t h i n g and c h e c k i f and why t h e message i s d i s c a r d e d
Message d i s c a r d e d s i n c e wrong e n c r y p t i o n
Contact Help Desk
Wrong checksum
Contact Help Desk
Message d i s c a r d e d s i n c e wrong ID
Contact Help Desk , c h e c k s o i t i s a c o r r e c t key and not t h e n e i g h b o u r s key
Message d i s c a r d e d s i n c e wrong S I v a l u e
Contact Help Desk
Message n e v e r r e c e i v e d
N: Are t h e r e any n o i s e ? Read t h e h i s t o g r a m .
Y: Try t o l o c a t e where i t comes from
N: Try a n o t h e r RK v a l i d f o r t h a t c a r model .
Message d i s c a r d e d s i n c e wrong e n c r y p t i o n
C o r r e c t s i n c e a n o t h e r RK
Wrong checksum
Contact Help Desk
Message d i s c a r d e d s i n c e wrong ID
C o r r e c t s i n c e a n o t h e r RK
Message d i s c a r d e d s i n c e wrong S I v a l u e
C o r r e c t s i n c e a n o t h e r RK

ix
 Message n e v e r r e c e i v e d
Y: Run RK d i a g n o s t i c ( on t h e i n c o r r e c t RK)
Looseness in the battery
Change RK o r t r y t o bend t h e s p r i n g s
Incorrect frequency
Change RK and c o n t a c t Help Desk
Button s t u c k
Try t o l o o s e i t e l s e change RK
S I v a l u e t o h i g h / low
S y n c h r o n i z e i f p o s s i b l e e l s e change RK and c o n t a c t Help Desk
Low b a t t e r y power
Change b a t t e r y
No RK d e t e c t e d
T r o u b l e s h o o t a s s t a r t i n g problem
V a l i d key i n s l o t ?
Y: Run RFR l e t s t h r o u g h e v e r y t h i n g and c h e c k i f and why t h e message i s d i s c a r d e d
Message d i s c a r d e d s i n c e wrong e n c r y p t i o n
Contact Help Desk
Wrong checksum
Contact Help Desk
Message d i s c a r d e d s i n c e wrong ID
Contact Help Desk , c h e c k s o i t i s a c o r r e c t key and not t h e n e i g h b o u r s key
Message d i s c a r d e d s i n c e wrong S I v a l u e
Contact Help Desk
Message n e v e r r e c e i v e d
Antenna ( p r o b a b l y ) broken , change RK
T r o u b l e s h o o t a s s t a r t i n g problem
No problem found
See i f t h e b u t t o n s work , i s t h e r e any broken ?
Y: Change RK
N: Are t h e r e any n o i s e ? Read t h e h i s t o g r a m .
Y: Try t o l o c a t e where i t comes from
N: C a l l Help Desk
N: I s t h e RFR f l a g s e t ? Read t h e l o g .
Y: Contact Help Desk
N: Read t h e h i s t o g r a m and c h e c k i f RFR been awake more than XX s e c o n d s .
<XX ms : RFR not awaken , change RFR
>XX ms : RFR r e c e i v e s message but d i s c a r d s i t .
R e s e t RFR and l o a d t h e c o n f i g u r a t i o n r o u t i n e . Does i t work ?
Y: Good
N: Change RFR
N: Read t h e h i s t o g r a m , were t h e r e any i n t e r f e r e n c e ?
Y: Try t o l o c a t e where i t comes from
N: How i s t h e c h a n n e l s t a t i s t i c c o u n t e r ? Does o n l y c h a n n e l 2 work ?
Y: The r i s k f o r i n t e r f e r e n c e i s big , change RK o r c o n t a c t Help Desk
N: Contact Help Desk

x
 E Troubleshooting tree for the second case

Are t h e r e any DTC? S t o r e a l l i n f o r m a t i o n t h a t can be l o s t b e f o r e s t a r t i n g t o t r o u b l e s h o o t .

Y: Go t o t h e s e c t i o n t h a t t e l l what t o do f o r t h e s p e c i f i c DTC.
DTC: RFR do not r e s p o n d
DTC: LIN bus c o n n e c t i o n broken
DTC: CAN bus c o n n e c t i o n broken
N: Open t h e d i a g n o s t i c s e r v i c e , a r e t h e r e any i n t e r m i t t e n t p r o b l e m s l o g g e d ?
C o r r e c t ID but wrong e n c r y p t i o n
Contact Help Desk
No p r o b l e m s l o g g e d
Has t h e b a t t e r y enough power ?
Y: Does i t a l w a y s happen t h a t t h e c a r won ’ t open with t h e RK?
Y: Does t h e s p a r e RK work ?
Y: Run RK d i a g n o s t i c ( on t h e i n c o r r e c t RK)
S I v a l u e t o h i g h / low
S y n c h r o n i z e i f p o s s i b l e e l s e change RK and c o n t a c t Help Desk
No RK d e t e c t e d
T r o u b l e s h o o t a s s t a r t i n g problem
V a l i d key i n s l o t ?
Y: Run RFR l e t s t h r o u g h e v e r y t h i n g and c h e c k i f and why t h e message i s d i s c a r d e d
Message d i s c a r d e d s i n c e wrong e n c r y p t i o n
Contact Help Desk
Wrong checksum
Contact Help Desk
Message d i s c a r d e d s i n c e wrong ID
Contact Help Desk , c h e c k s o i t i s a c o r r e c t key and not t h e n e i g h b o u r s key
Message d i s c a r d e d s i n c e wrong S I v a l u e
Contact Help Desk
Message n e v e r r e c e i v e d
Antenna ( p r o b a b l y ) broken , change RK
N: T r o u b l e s h o o t a s s t a r t i n g problem
No problem found
Run d i a g n o s e a n y t h i n g d e t e c t e d on LIN?
Y: RFR works , problem i s p r o b a b l y i n RK o r CEM
N: Change RK
N: Run RFR l e t s t h r o u g h e v e r y t h i n g and c h e c k i f and why t h e message i s d i s c a r d e d
Message d i s c a r d e d s i n c e wrong e n c r y p t i o n
Contact Help Desk
Wrong checksum
Contact Help Desk
Message d i s c a r d e d s i n c e wrong ID
Contact Help Desk , c h e c k s o i t i s a c o r r e c t key and not t h e n e i g h b o u r s key
Message d i s c a r d e d s i n c e wrong S I v a l u e
Contact Help Desk
Message n e v e r r e c e i v e d
N: Try a n o t h e r RK v a l i d f o r t h a t c a r model .
Message d i s c a r d e d s i n c e wrong e n c r y p t i o n
C o r r e c t s i n c e a n o t h e r RK
Wrong checksum
Contact Help Desk
Message d i s c a r d e d s i n c e wrong ID
C o r r e c t s i n c e a n o t h e r RK
Message d i s c a r d e d s i n c e wrong S I v a l u e
C o r r e c t s i n c e a n o t h e r RK
Message n e v e r r e c e i v e d
Y: Run RK d i a g n o s t i c ( on t h e i n c o r r e c t RK)
S I v a l u e t o h i g h / low
S y n c h r o n i z e i f p o s s i b l e e l s e change RK and c o n t a c t Help Desk
No RK d e t e c t e d
T r o u b l e s h o o t a s s t a r t i n g problem
V a l i d key i n s l o t ?
Y: Run RFR l e t s t h r o u g h e v e r y t h i n g and c h e c k i f and why t h e message i s d i s c a r d e d
Message d i s c a r d e d s i n c e wrong e n c r y p t i o n
Contact Help Desk
Wrong checksum
Contact Help Desk
Message d i s c a r d e d s i n c e wrong ID
Contact Help Desk , c h e c k s o i t i s a c o r r e c t key and not t h e n e i g h b o u r s key
Message d i s c a r d e d s i n c e wrong S I v a l u e
Contact Help Desk
Message n e v e r r e c e i v e d

xi
 Antenna ( p r o b a b l y ) broken , change RK
N: T r o u b l e s h o o t a s s t a r t i n g problem
No problem found
Run d i a g n o s e a n y t h i n g d e t e c t e d on LIN?
Y: RFR works , problem i s p r o b a b l y i n RK o r CEM
N: Change RK
N: Measure c u r r e n t o v e r RFR, i s t h e c u r r e n t :
Below 30 mA: RFR d o e s not awaken , change RFR
Between 30 mA and 130 mA: RFR r e c e i v e s t h e message but d i s c a r d s i t
R e s e t RFR and l o a d t h e c o n f i g u r a t i o n r o u t i n e . Does i t work ?
Y: Good
N: Change RFR o r RK
Above 130 mA: RFR r e c e i v e s t h e message and s e n d s i t t o CEM
Run d i a g n o s e a n y t h i n g d e t e c t e d on LIN?
Y: Problem with CEM o r a f t e r l y i n g component , measure CAN. Any s i g n a l d e t e c t e d ?
Y: T r o u b l e s h o o t t h e components a f t e r CEM
N: Change CEM
N: T r o u b l e s h o o t f o r s h o r t c i r c u i t a t LIN e l s e c o n t a c t Help Desk
N: How i s t h e c h a n n e l s t a t i s t i c c o u n t e r ? Does o n l y c h a n n e l 2 work ?
Y: The r i s k f o r i n t e r f e r e n c e i s big , change RK o r c o n t a c t Help Desk
N: Contact Help Desk
N: Change b a t t e r y

xii
 F Troubleshooting tree for the third case

Are t h e r e any DTC? S t o r e a l l i n f o r m a t i o n t h a t can be l o s t b e f o r e s t a r t i n g t o t r o u b l e s h o o t .

Y: Go t o t h e s e c t i o n t h a t t e l l what t o do f o r t h e s p e c i f i c DTC.
DTC: RFR do not r e s p o n d
DTC: LIN bus c o n n e c t i o n broken
DTC: CAN bus c o n n e c t i o n broken
N: Does i t a l w a y s happen t h a t t h e c a r won ’ t open with t h e RK?
Y: Does t h e s p a r e RK work ?
Y: Has t h e i n c o r r e c t RK low b a t t e r y power ?
Y: Change b a t t e r y
N: I n s e r t t h e RK i n t o t h e i g n i t i o n s l o t , d o e s t h e c a r r e c o g n i z e t h e RK?
Y: I s i t a v a l i d key ?
Y: Which b u t t o n s g i v e any r e s p o n s e , e . g . p r e s s t h e approach l i g h t d o e s t h e l i g h t s t u r n on ?
A l l : Why i s t h e c a r i n f o r s e r v i c e ? Contact Help Desk
Some : Try t o c l e a n RK, u s e c o m p r e s s e d a i r t o g e t r i d o f d i r t . Does i t work ?
Y: Good
N: Change RK
None : Measure c u r r e n t o v e r RFR, i s t h e c u r r e n t :
Below 30 mA: RFR d o e s not awaken , change RFR
Between 30 mA and 130 mA: RFR r e c e i v e s t h e message but d i s c a r d s i t
R e s e t RFR and l o a d t h e c o n f i g u r a t i o n r o u t i n e . Does i t work ?
Y: Good
N: Change RFR o r RK
Above 130 mA: RFR r e c e i v e s t h e message and s e n d s i t t o CEM
Measure t h e v o l t a g e on LIN . I s t h e r e any v o l t a g e ?
Y: Problem with CEM o r a f t e r l y i n g component , measure CAN. Any s i g n a l d e t e c t e d ?
Y: T r o u b l e s h o o t t h e components a f t e r CEM
N: Change CEM
N: T r o u b l e s h o o t f o r s h o r t c i r c u i t a t LIN e l s e c o n t a c t Help Desk
N: T r o u b l e s h o o t a s s t a r t i n g problem , s e e i f i t i s t h e c o r r e c t RK
N: T r o u b l e s h o o t a s s t a r t i n g problem
N: I n s e r t t h e RK i n t o t h e i g n i t i o n s l o t , d o e s t h e c a r r e c o g n i z e t h e RK?
Y: I s i t a v a l i d key ?
Y: Which b u t t o n s g i v e any r e s p o n s e , e . g . p r e s s t h e approach l i g h t d o e s t h e l i g h t s t u r n on ?
A l l : Why i s t h e c a r i n f o r s e r v i c e ? Contact Help Desk
Some : Try t o c l e a n RK, u s e c o m p r e s s e d a i r t o g e t r i d o f d i r t . Does i t work ?
Y: Good
N: Change RK
None : Check t h e b a t t e r y power i s i t ok ?
Y: Measure c u r r e n t o v e r RFR, i s t h e c u r r e n t :
Below 30 mA: RFR d o e s not awaken , change RFR
Between 30 mA and 130 mA: RFR r e c e i v e s t h e message but d i s c a r d s i t
R e s e t RFR and l o a d t h e c o n f i g u r a t i o n r o u t i n e . Does i t work ?
Y: Good
N: Change RFR o r RK
Above 130 mA: RFR r e c e i v e s t h e message and s e n d s i t t o CEM
Measure t h e v o l t a g e on LIN . I s t h e r e any v o l t a g e ?
Y: Problem with CEM o r a f t e r l y i n g component , measure CAN. Any s i g n a l d e t e c t e d ?
Y: T r o u b l e s h o o t t h e components a f t e r CEM
N: Change CEM
N: T r o u b l e s h o o t f o r s h o r t c i r c u i t a t LIN e l s e c o n t a c t Help Desk
N: Change b a t t e r y and s t a r t t h e t r o u b l e s h o o t from t h e b e g i n n i n g
N: T r o u b l e s h o o t a s s t a r t i n g problem , s e e i f i t i s t h e c o r r e c t RK
N: Reprogram RK, d o e s i t work ?
Y: Good
N: Back two s t e p s and r e d o them , any change ? E l s e c o n t a c t Help Desk
N: How i s t h e c h a n n e l s t a t i s t i c c o u n t e r ? Does o n l y c h a n n e l 2 work ?
Y: The r i s k f o r i n t e r f e r e n c e i s big , change RK o r c o n t a c t Help Desk
N: Contact Help Desk

xiii