Analysis of the SAE J1708 protocol - IDT

Volvo Construction Equipment AB
Component Division
Analysis of the SAE J1708 protocol
Raine Saastamoinen
Bachelor thesis report
May - Juli 2008
School of Innovation Design and Engineering
Mälardalen University, Västerås, Sweden
Supervisor and Examiner: Johan Stärner
Supervisors at company: Nils-Erik Bånkestad and Jarmo Talvén

“ Engineers does’nt buy solutions they create them”
LeCroy comersial
2

Abstract
Component Division at Volvo Construction Equipment, develops electronic control units
(ECU) to be used in entrepreneur machines. In an operating vehicle there are several ECU’s
communicating with each other to make everything work as a complete. There are two main
network protocols in use to solve different communication needs. One of them is using the
SAE J1708 physical layer protocol in transmitting of the actual bits when exchanging
information. Manufacturing of the units are made by external suppliers.Up to date, there is a
lack of good tools, to verify that delivered components conforms to the J1708 specifications.
WaveRunner 104 MXi, is an advanced digital oscilloscope with scripting possibilities. It has
been used in this thesis work to find out, whether suitable or not to solve this problem. This
thesis shows that analysis is possible and most important of all, in future potential of being a
great tool for verification.
3

Acknowledgements
Thanks to my supervisors Nils-Erik Bånkestad and Jarmo Talvén at VCE Component Division
for professional guidance. Pushing me in the right direction when stumbeling into difficulties
(especially after that important meeting the very first week). My supervisor at Mälardalen
University, Johan Stärner, a friendly professional for support and important advices. Despite
having summer vacation, taking time to read and comment my report. Annika Nerén and
Peter Sävström for aid and patience shown in the laboratory environment. Magnus Åkesson,
always giving a helping hand when needed and for having many good ideás. Also special
thanks to Mikael Back, making this opportunity possible, to finish my studies at this
interesting and challenging company. Toni Riutta for being a god friend with the heart at
right place, I wish you all the best.
A special thought to my family and belowed ones. Being there, listening, supporting,
encouraging and all to help me to the finishing line.
And last but not the least to all the people at location, showing that, despite all serious work
dealt with, there is always room for laughter. Surrounded by a great atmosphere it has been a
delightful experince to work here.
Thank you all!
Raine Saastamoinen
4

Contents
1 Introduction …….….….…………………………………………………….……………..6
2 Background ...……………………………………………………………….……………..6
3 Problem formulation.……………………………………………………….…………..….7
4 Thesis outline……………………………………………………………….…………..….8
5 The SAE J1708 protocol………………………………………………….…………..……8
6 TheWaveRunner 104 MXi DSO ..……………………………………….…………..…….8
6.1 WaveScan, an advanced search and analysis tool……. .………….…………..……..11
6.2 LabNotebook ..………………………………………………………………..……..12
6.3 Custom DSO…. . ……………………………………………………………….……13
7 Requirements on analysis…….……………………………………………………….…..13
7.1 Voltage levels on the bus..………….………………………………………………...14
7.1.1 Bus state levels..……....………………………………………………………….14
7.1.2 Bits and voltage differences ……………………………………………………..15
7.2 Single bits………………………………………………………………………….…15
7.2.1 Verify bit time….…………………………………………………………….…..15
7.2.2 Low-to-high delay…. ……………………………………………………….…..15
7.2.3 High-to-low delay .. ….. ………………………………………….....……….…..15
7.2.4 Higher frequecies………………………………………...……………………….15
7.3 Characters……………….……………………………………………… ……….…..16
7.3.1 Interpretation………………. …………………………………… ………….…..16
7.3.2 Character time duration………………………………………….………….……16
7.4 Messages………………………….…………………………………………….……16
7.4.1 Idle state…………………………………………………………………….……16
7.4.2 Inter byte delays…………………………………………………………….……16
7.4.3 Message lengths ………………. ………………………………………….…….17
7.5 Further analysis……………………. .……………………………………….………17
7.5.1 Unknown-zone…………………..……………………………………….………17
7.5.2 Traffic load on bus………………… ………………..….….….………….. ……17
7.5.3 Count collisions………………………………………………………………….17
7.5.4 Monitor communication………………….……………………….. ……………17
7.5.5 Decode messages……………………………………………….. ………………17
8 Method ………………………………………..………. .. ………….. …………………18
8.1 Workplace simulation equipment……….……………. ………….. ………………..18
8.2 Laboratory simulation equipment……….………………. …….. …………………..18
8.3 Measurement to be done for voltage levels. ………... ….. .. …….. ………………..18
8.4 Measurement to be done for single bits .…….…….….……..... ……………………19
8.5 Measurement to be done for characters .……….……..……. ………………………20
8.6 Measurement to be done for messages..…………..………….. ……………………..20
8.7 Measurement to be done for further analysis ………. .….….……………………….20
9 Results…………………………………………………….. .……………………………..20
9.1 Analysis of results …..……………………….. ……………………………………..22
10 Future work/recommendations.. …………….. ………………....………………....……34
11 Summary and conclusions ……..………..…...…..………………………………………36
References…………………………….….…….……………..…...………..……………37
Appendix A… …….…….…….…………………………………………………………38
Technical data……..…………………………………………………………………38
Sample code………………………….….….………………………………………..39
5

1. Introduction
Volvo Construction Equipment (VCE) is one of the leading manufacturers of construction
machines on the world market. Wheel-, and backhoe loaders, excavators and articulated
haulers are some of the products (see fig.1). This big company is divided into several
divisions responsible for specific areas. One of them, Component Division has the global
responsibility for developing and manufacturing powertrains and electronic systems. This
thesis work is made at a department, within Component Division in Eskilstuna. In here
development take place in making new hardware and software solutions for the electronic
control units (ECU), used by the machines. Software is developed on both platform and
application level. The hardware is devoloped together with external suppliers, which by the
end makes the actual manufacturing of the ECU’s.
Figure 1. Wheel-, and backhoe loaders, excavators, articulated haulers, motor graders and road machinery are
products developed by VCE.
2. Background
First of all, a very brief explanation to what an ECU is doing. An ECU, electronic control
unit, is a small embedded computer that has specific behaviour implemented in it to take care
of certain parts of a vehicle. Engine, transmission, hydraulics, cabin, instrument and so on
have their own ECU’s. A real-time operating system is in use to schedule and decide on
which task (a small piece of program), may execute what and when. Different tasks read
sensor values, others make decisions upon that and some make actuators to react accordingly.
The beaty of this is having the possibility to tune in some small specific details or change of
characteristics and behaviour of a vehicle with changes in software (of cource with
limitations). The trend is with increasing count of modules per vehicle.
In an operating vehicle there are several ECU’s communicating with each other to make
everything work as a complete. Communication between these autonomous nodes that the
ECU’s represent, make the use of network protocols a necessity. There are two main
protocols in use to solve different communication needs. First there is the CAN (Controller
Area Network) according to J1939 standard in use for most of the data communication [8],[9].
With CAN being the primary bus, it allows critical interchange at high speeds among the
connected modules. The second alternative in use is a protocol following the SAE (Society of
Automotive Engineers) J1587 standard [12],[14]. A rather old standard, yet offering the
advantages of a proven by use, reliable but rather slow communication service, used mainly
for secondary or less urgent data exchange in the form of…
• loading new software to the platform
• dataset loading
• on-vehicle test
• diagnosis / faultcodes
6

Figure 2: The electronic system
J1587 describes the application level in a protocol suite according to the OSI Model 1 . It
defines format of the messages and data to be sent that is of general value. It describes a
standard to use for...
“ electronic data interchange between microcomputer systems in
heavy-duty vehicle applications” [12].
This application layer protocol is to be used together with the SAE J1708 standard [13][15].
In a protocol suite, this one defines the data link-, and physical layer.
3. Problem formulation
How well does the ECU’s implement the recommended practice when data interchanged? The
main objective of this thesis work is to make measurements and analysis of the SAE J1708
physical layer protocol in use. Up to date there has been a lack of good supporting tools to
verify such things easily.VCE having a vision, invested in an advanced digital signal
oscilloscope with scripting possibilities. LeCroy’s WaveRunner 104 MXi has been used in
this thesis work to find out, whether suitable or not to solve the aforementioned problem.
1 The OSI Model describes a layered, abstract description for communications and computer
network protocol design
7

4. Thesis outline
To solve this thesis work, a logical work flow has been identified.
1. First of all getting deeper knowledge of the SAE J1708 protocol.
2. Studying the WaveRunner 104 MXi oscilloscope with focus on sorting out different
alternatives for measurement and analysis.
3. Establish a specification of requirements on what to analyse.
4. Do the required measurement needed for analysis.
5. Make analysis of gathered material and present results.
5. The SAE J1708 protocol
One of the protocols in use is the SAE J1708. A standard that implements a bidirectional,
serial communication link among modules containing microcomputers [13]. Like
aforementioned with an application layer protocol on top of it, this one defines the data link-,
and physical layer and is paired with EIA-485 (also formerly known as RS-485), giving the
electrical specifications to it [10]. Here the primary concerns are the actual transmitting of the
bits when ECU’s exchange information on the bus. Among other things the standards
describe…
• voltage levels
• timing constraints
• defining format of characters
• bus access mechanisms
• error detection and handling
• hardware interface with cables, allowed lengths, number of units and so on.
Later in the report, when presenting the requirements on what to analyse, deeper explanations
will be given to why certain measurement are required in verification of correct behaviour.
6. The WaveRunner 104 MXi DSO
The purpose of this topic is to give data on the WaveRunner 104 MXi digital signal
oscilloscope (hereafter refered as DSO). This quite extensive information, with intensions of
having the reader to get a feeling of the power of this instrument. Many things are ready in the
DSO to make life simpler to an engineer, but the real strength comes with the ability to
develop custom solutions with scripts. Following information in here is more or less gathered
from the company homesite, product commercials and accessible manuals on this site [1].
“ A single-shot acquisition is a series of digitized voltage values sampled on
the input signal at a uniform rate. It is also a series of measured data values
associated with a single trigger event. The acquisition is typically stopped a
defined number of samples after this event occurs: a number determined by
the selected trigger delay and measured by the timebase.” [2]
The DSO is delivered with windows XP operating system installed, presenting a well known,
easy to use environment. It is possible to attach common peripherals such as mouse and
8

keyboard to use the instrument simply as a ordinary computer. If the built-in display of the
DSO feels too small, it may be connected to another screen. There is three different solutions
when navigating within the DSO menus. By a touch sensitive screen, a mouse or simply use
physical buttons and knobs on front panel of the intrument.
Figure 3. LeCroy WaveRunner 104 MXi [3].
The DSO has 4 input channels in where to connect appropriate probes for measurement.
These are called C1, C2, C3 and C4 when navigating within the instrument. Other channels to
display traces and do work on when specific functions applied on are identified as...
Parameters (P1-P8)
Memory channels (M1-M4)
Math channels (F1-F4)
Zooming channels (Z1-Z4)
and (Q1-Q4) used for pass/fail testing
Parameters are measurement tools that determine a wide range of waveform properties. Use
them to automatically calculate many attributes captured signals. Some examples could be
rise-time, rms voltage, base, top and peak-to-peak voltage. Result is presented in one of the
specified P1 – P8 traces available. There are completely ready to use parameter modes to
perform maesurement on waveforms in the typical amplitude (vertical) and time (horisontal)
domains. Custom parameter groups with possibility to make own choises from the built-in
functions to apply and finally by programming in VBScript to add, what ever, new own
custom functionality. Any of the parameters and their values may be presented together with
statistical values such as their average, high, min and max values if desired.
Memory channels M1-M4 are there to use when saving acquired waveforms. Easy to recall
when further analysis has to be done (a principle used in this thesis, more on this later).
The DSO has built-in mathematical functions to apply on acquired waveforms. This to
perform math on them and displaying the result in one of the four math traces F1- F4. The
easy-to-use graphical interface simplifies setup of up to two operations on each function trace.
Math traces can be chained together to perform math-on-math. If this is not enough, possible
9

to implement own functionality by coding in VBScript, JScript or MATLAB. This makes the
DSO so powerful.
Although the DSO offers a lot of functionality in standard mode, VCE have purchased some
additional hardware and software options as well. It has been upgraded with…
• More memory added, 512 MB
• A Master Analysis Package (XMAP), that includes…
o Advanced Math Package (XMATH). Allowing math on waveforms from
input channels (C1 - C4), memories (M1 - M2) or other math channels (F1 -
F4)
o Customisation Package (XDEV). If Analysis, Custom DSO and plug-in
choosen in instrument menu topics, it is possible to create own graphical user
interfaces (GUI). An interface with buttons connected to macros that activate
some described ActiveX control. If Custom DSO in Basic mode activated. This
will enable easy to use access to own instrument set-ups to be launced with
defined buttons.
o Jitter and Timing Analysis Package(JTA2). Enabling math and parameter
selections in Math and Measure menus
• CANbus TDM. An external Trigger, Decoding and Measurement module. With this
module monitor and verify that operation, reliability and performance of CAN-nodes
take place as they should. This is adding a set of tools for simultaneous testing of both
physical-, and data link layer.
• Built-in serial data decoders available in the DSO are: CAN, UART, LIN, SPI, I2C,
FlexRay and RS-232.
In the bottom line this is an oscilloscope. A digital one making all the things expected but also
capable of many things beyond that of an ordinary oscilloscope. One special feature comes
with the rapid signal processing power and large memory when acquiring waveforms.
Waveforms that can be further processed with software if desired when having JTA2 and/or
XMATH packages installed. This possibility to make additional things to the normal
hardware triggers and applying software processing on measured waves is one of the things
that makes this DSO so special.
“The high 10 GS/s maximum sampling rate and
extremely long 25 Mpts memory guarantee you are capturing
all of the details in your signals.” [3]
The speed is there to get all the details. How about the quality and how accurate are the
digitized readings? Following statements makes one realize the very high demands that could
be set upon the precision of the measurements.
10

• Let the instrument adjust it self to surrounding room temperature.
• Adjust measuring probes with aid of a built-in, adjustable calibration signal.
• Deskew whenever need of compensating for different lengths of cables, probes, or
anything else that might cause timing mismatches between signals.
There exist many alternative settings to choose from when displaying captured signals.
If not happy with the standard plot, change colour, change to persistence mode and view in a
3D mode. Possible to change plotting between line or punctuation mode, splitting windows to
separate different channels and if in monochromatic persistence mode, possible to simulate
the look of sweeps as they were in the old analog oscillocopes. Some other features in short…
• Use of cursors to manual measurements, still useful in many cases. Descriptive labels
may be turned on, showing what parts of a signal that is measured and how.
• Zooming in and out wanted parts of one or more particular channels...
• ...automatically done when applying filtering criterias used by WaveScan software. It
can be used to scan and search either on saved waveforms or making it during live
acquisitions with highlighting areas when features of interest found.
• With ScanHisto, show statistical distribution of found events. Find out how values of
parameters are distributed over many measurements. Once a histogram is defined and
generated, measurements can be performed on the histogram itself (see fig.4).
• Fast Fourier Transforms (FFT). For a large class of signals, one could gain greater
insight by looking at spectral representation rather than time description.
• Reporting and documenting results is important. It is made easy with the included
LabNotebook software.
• The additional XDEV package make it possible to set-up the instrument and making
of own GUI’s to launch macros that run own ActiveX 2 content.
• If not enough with the more than 250 built-in functions covering lots of mesurement
needs, then the DSO offers scripting possibilities to create own solutions in case
needed (XMATH and/or JTA2 packages required)
Figure 4. Histicons provide a fast, dynamic view of parameters and wave shape characteristics [2].
2 ActiveX components is a term used to denote reusable software components that are based on Microsoft
Component Object Model (COM). ActiveX controls provide encapsulated reusable functionality to programs
and in this case it can be described with Visual Basic to set-up the instrument.
11

Some of the software to use with the DSO and mentioned above, deserves a closer look. This
is because they enable exciting possibilities for analysis in searching for a solution to this
thesis. Remembering that following information is more or less gathered from the company
homesite product commercials and accessible manuals in here [1]. Let us start with…
6.1 WaveScan, an advanced search and analysis tool
This software is a powerful tool when working with acquisitions and deeper analysis of
captured waveforms. First WaveScan enables the user to trigger on unusual events to capture
and then offering scanning of special events of interest. Fast processing of data, gives
possibility to scan and monitor millions of events. Make a selection from available
measurement modes and filters or implement own solutions by coding in VBScript, JScript,
MATLAB or Mathcad. This may be done on any input-, math channel or memory trace.
Search criteria may be selected from several modes such as frequency, pulse width,
amplitude, etc.
“WaveScan provides the ability to locate unusual events in
a single capture (i.e., capture and search). It also “scans”
for an event in many acquisitions over a long period of time.
Select from more than 20 search modes (frequency, rise
time, runt, duty cycle, etc.), apply a search condition and
begin scanning.” [4]
When using software triggering (enabling WaveScan functionality), one must select what kind
of action to take on events found…
• None
• Audible Beep
• Stop Acquisition
• Save Waveform(s)
• Pulse AUX Output
• Print (Save) Screen Image
• Save to LabNotebook
Identified events are highlighted and surrounded by a red box. There exist a user selectable
table to be displayed with found features and their values. All found events are individually
time stamped and indexed in the table from which one can select them for further
view/analysis.
6.2 LabNotebook
“Since the scanning modes are not simply copies of the hardware triggers,
but "software triggers," the capability is much greater.” [2]
LabNotebook is there to extend documentation capabilities of the DSO.
12

“LeCroy's LabNotebook feature extends the documentation capabilities of your
oscilloscope. It allows you to create an annotated notebook entry containing all
displayed waveforms, the setup of the DSO, and user-supplied annotation.” [2]
These savings can then be converted to pdf, rtf or html and printed or emailed. If the default
report layout lack something, configure your own (with own company logo in the header!).
All notebook entries are stored in an internal database. Besides storing the waveform having
16-bit resolution for integer or floating point data, LabNotebook also stores panel setups (the
setup of the DSO) and parameter measurements in the database.
“LabNotebook is a unique inter-active measurements database and report
generator that can be of inestimable value in the day-to-day use of your LeCroy
oscilloscope. “ [7]
With the flashback feature all data is available for recall at any time. Recall the state of the
DSO, including the saved waveforms and the DSO setup, and proceed with additional
measurements. This makes it easy to continue work where last finished. In case needed,
LabNotebook offers capability to back up the database to external media.
6.3 Custom DSO
“The instrument provides powerful capability to add your own parameters,
functions, display algorithms, or other routines to the oscilloscope user interface
without having to leave the instrument application environment. You can
customize the instrument to your needs by using the power of programs such as
Excel, Mathcad, and MATLAB, or by scripting in VBS. Whichever method
you use, the results appear on the instrument's display together with the signals
that you started with. This ability offers tremendous advantages in solving unique
problems for a large range of applications…” [2]
CustomDSO, in its Basic mode, allows creation of DSO setups that can be called by the touch
of a single button. Basic mode may also recall own functionality implemented in VBScripts
that can set up all or part of the oscilloscope and do many other things. Another more
powerful feature is the PlugIn, which allows adding of ActiveX controls to a setup. These
controls are powered by routines written in Visual Basic. With ActiveX controls it is possible
to create own graphical user interfaces (GUI:s) to suit desired preferences. [2]
7. Requirements on analysis
The main objective of this thesis work is to make measurements and analysis of the SAE
J1708 physical layer protocol in use. Having thoroughly studies on the protocol, made it
possible to pinpoint important things to measure. There is a logical structure to work with that
follow from the basic voltage levels on the bus, interpreting the ones and zeros transmitted, to
finally end up with describing complete messages.
13

1. voltage levels
2. bits
3. characters
4. messages
5. further analysis
Further analysis part was included here as well, although not possible to solve everything.
Mainly because this makes one to think further in possible development. At this state, positive
if being able to decide whether this could be done or not with this instrument in the future
(obviously of major interest for VCE). Some experimenting here but primary effort put on
measuring and verifying the first four levels of requirements.
The requirements to measure will be numbered to be refered to later in the thesis. Also the
reader should note that enclosed section numbers do reference to the specifications given in
SAE J1708 Revised OCT93 and that words in bold face letters are there to highlight important
ones used in the standard.
7.1 Voltage levels on the bus
7.1.1 Bus state levels
Verify differences for bus state levels greater than or equal to 0,2 V. (4.2).
The information is transmitted on a differential bus e g. a bit is interpreted as in a difference
of voltage levels between the twisted pair of wires. A logical ’1’ when point A is at least 0.2
V more positive than point B. ’0’ when the opposite is the case, B > A
Figure 5: Points to be measured, A and B, are given by this picture from the SAE J1708 Revised Oct93 [13].
14

7.1.2 Bits and voltage differences
Verify that received bits follow differences in voltage levels between the wires (point Rx to
be measured in fig.5).
7.2 Single bits
7.2.1 Verify bit time
Verify that the duration of one bit time, high and low logic levels, do not exceed stated limits
(104,17 µs ± 0,5 %). (6.1)
This specific pulse width complies to 9600 baud, e g. maximum count of analog signal
transitions per second given by the frequency formula
f = 1/(104,17*10^-6) = 9599,69 Hz.
This frequency, and how content of one character is represented, is consistent with standard
universal asynchronous receiver/transmitter (UART) communication. More in 7.3.1
7.2.2 Low-to-high delay
Verify that low-to-high transition delays at the receiver do not exceed 10 µs. (A.6).
Active low-to-high transition delay, is a delay on the transmitted signal, due to added
capacitance by nodes connected to the serial bus. This delay between sending and receiving of
bits should remain at the same value regardless of number of nodes in the system. Upper limit
in the recommended practice is a maximum count of 20 nodes.
7.2.3 High-to-low delay
Passive high-to-low transition delay. A delay that do increase with the load. It should not be
more than 2,3 µs for 20 connected nodes.
Verify high-to-low transition delays within 0,6 – 2,3 µs. (A.5).
7.2.4 Higher frequencies
Verify that measurements, as done in 7.2.1 – 7.2.3, also is valid for higher frequencies used
with standard UART communication in the system [16].
15

7.3 Characters.
A character is consistent with standard universal asynchronous receiver/transmitter (UART)
communication. A character shall consist of 10 bits. Starting with one low logic level bit,
followed by 8 bits of data and ending the character with a high logic level bit. A low logic
level bit has the opposite level of a bus in idle state according to 7.4.1
7.3.1 Interpretation
Verify that a character is interpreted correctly. A logic ’0’ start bit indicating the beginnig of a
new character. This followed by 8 bits of data, least significant bit (LSB) first and by having
the most significant bit (MSB), logic level ’1’ ending the character. (6.2).
7.3.2 Character time duration
Verify total amount of time for one character within 10 * bit time. (6.2).
7.4 Messages.
A message consist of 3 – 21 characters in length. A message identifier (MID), followed by
1 - 19 characters of data and ending up with a checksum. The total length of a message is
limited to 21 characters when vehicle running. If speed = 0 and engine RPM = 0, longer
messages are allowed to be exchanged. (6.3.5).
7.4.1 Idle state
Verify prior sending of a new message, that the communication link has remained at a high
logic level (e.g no other message on the bus), for a duration of at least 12 * bit time. This is
true if the transmitting node is able of distinguishing a stop bit from other high-logic, idle line
bits. If not, this should count to 19 * bit time. (5.2).
Accessing the bus is made in a random manner. This is based on among other things, the
specified priority for that message, resulting in a value called bus access time. This bus
access time tells how long the bus should have been in an idle state before a specific message
is allowed accessing the communication channel. (5.2.1.1).
7.4.2 Inter byte delays
Verify that delays between characters inside a message, interbyte delay, do not exceed
2 * bit time. (6.3.1).
16

7.4.3 Message lengths
Verify length of messages in between 3 – 21 characters when measuring in a system that
simulates a running vehicle.
7.5 Further analysis
7.5.1 Unknown-zone
Study duration of ’unknown-zone’ prior sending of a new message.
Prior transmitting of a new message, following requirements must be met:
• The bus must have been in an continuous idle state, for a time duration of
at least a bus access time specific to this message and
• then finally confirm that immediately prior attemt to send, still having the bus
in idle state.
This ’unknown-zone’ is the time between meeting all requirements and the actual transmitting
of the first byte. (5.2.1).
7.5.2 Traffic load on bus
Make presentation of traffic load on the bus.
7.5.3 Count collisions
Make presentation of number of collisions.
7.5.4 Monitor communication
Make the instrument to monitor and notify, or log, events of interest not following the
recommended practice in the SAE J1708 standard [13].
7.5.5 Decode messages
Decode messages on the bus. If having the possibility to decode messages and presenting this
i plain text, one would gain lot of useful insight when confirming functionality and behaviour
of a system. With aid of decoded messages it would be straight forward to find answers to
questions such as…
• If collisions are common, who is most often involved?
• Does a specific message have right settings in priority?
• What specific bus access time a message has?
17

• How often do some node access the bus?
• Do we have correct checksum count?
8. Method
To start with the first measurements to be done with the DSO is to get familiar with it.
Learning by doing. At my service there is (in the beginning), a single ECU connected thru
devices to a PC. I shall call this ‘test-bench’environment, the Workplace simulation
equipment. Access to the ‘real-world’ simulation measurements (hereafter Laboratory
simulation equipment) on a complete system in use will be done at a later phase. Both systems
will be used to gather data to analyse and compare. There are different things accessible from
one and/or both systems when collecting important data to this thesis work. One example of
this could be, having delays in mind, that measures are expected to give different results/data
depending on the total number of connected ECU’s that do communicate.
8.1 Workplace simulation equipment
This equipment makes it possible to edit and send own messages to a single connected ECU
at the other end. A computer having the J1587 Navigator program may communicate by
sending messages having UART format, passing a converter and when reaching connected
ECU, having data interpreted according to the physical layer J1708 protocol (the UWA in
between is required for serial communication thus converting UART characters to J1708
standard sent). This is something to remember because measurements made here will differ
from the ’real-world’ simulated environment measurements in the laboratory. One big
advance of this is however that it was possible to solder physically contacts to otherwise
unreachable Tx and Rx on the ECU. This made it possible to gather information and make
further conclusions on how to make alternative measurements in a system at operating mode
(without physical Tx and Rx available).
8.2 Laboratory simulation equipment
Here newly developed electronic equipment is tested thouroughly. The ’measurement-rigs’
environment is meant to simulate a complete running vehicle, in my case a wheel loader.
(Wow! It was an exiting experience to see all this, at the leading edge of technology).
Measurement is done by connecting probes to the bus on the fly (point A and B, figure 5)
Several connected nodes communicating will have influence on bits of information travelling.
There is expected to be transition delays due to added capacitance when several nodes
connected. The added capacitance comes from transmit/receive filters that is in use for electro
magnetic interference (EMI) suppression. This will influence the shape of square waves to
stretch out and has to do with releasing charge in capacitors.
8.3 Measurement to be done for voltage levels
Work is to be done from the basic physical requirements and up, according to the analysis
topics. Starting with the voltage levels on the bus …
18

7.1.1 Measurement to be done both at the Workplace and Laboratory environments. Use of
own settings, chosen from the parameter functions in the DSO. Functions are for the
waveforms in the typical amplitude (vertical) domains. Acquire longer sequence to
verify same behavior over long time. Sample rate not of primary concern.
7.1.2 The vision of a powerful tool for verification of ECU’s behaviour, has to operate on
the only accessible points A and B on the bus. The only place to hook probes to, just
to minimize work and time on preparations. The laboratory is in tight scheduled use
and if in future wanting to verify on a vehicle in the field, then this criteria must be
met. No mixing with the ECU’s prior to measurement. This leads us to difficulties
when trying to measure things where physical access to Rx is a necessity to get exact
answers (1.2, 2.2 and 2.3. switching levels at right differences and transition delays in
mind). This was the case for the ‘real’ measurements to be done at the Laboratory
simulation equipment. The single ECU unit in use at Workplace, however gave
permissions to solder physical attachments to both Tx and Rx. From measurements
made on the physically available points, conclusions and ideas can be made for
alternative approximative measurements for verification of Laboratory settings.
Nevertheless, measurement made on physically available Tx and Rx at Workplace
with one connected node. Send the message 085 127 001 with having a calculated
checksum of 043 added by the J1587Navigator program. This script gives an easy to
understand waveform to analyse. From this it is possible to measure a lot of
information. Bit times for ones and zeros, interbyte delays and interpretation of a
character. Same answers from complete system in use can to some extent be done with
built-in functionality of the oscilloscope, namely with WaveScan with proper settings.
8.4 Measurement to be done for single bits.
At the Workplace it is straightforward to verify delays between transmitting and receiving.
Set high sample rate to obtain high quality in measurement, though we are talking about
actions that are expected to take place in times around and less than a millionth of a
second. In Laboratory, by using WaveScan once again for 7.2.1 but better accuracy
manually for 7.2.2 and 7.2.3. Trig on whatever message on the bus and save for analysis.
The Laboratory environment is in heavy use when development of new products take
place. Tight scheme and not wanting to interfere with ‘real’ work going on made a change
in strategy. Don’t sit in the Laboratory more than just hooking on probes on the bus and
acquire waveforms at different sample rates and save them in the instrument with the
LabNotebook feature. Analyse material at other location in calm.
A short explanation to why not use maximum rates all the time. Remembering that…
“The high 10 GS/s maximum sampling rate and
extremely long 25 Mpts memory guarantee you are capturing
all of the details in your signals.” [3]
…although having memory enough to store this 25 Mpts in 16 bit resolution, be sure of that
a samplerate of 10 GS/s fills this up in just 2.5 ms. So very high quality samples of a
waveform gets only that short trace of information. A single character is supposed to be
19

around 10*104,17 µs = 1.04 ms, hence able of capturing about two characters. Obviously
thought in sample rates has to be accordingly to how long sequences interested in.
7.2.4 Communication is done at speeds of 9600 baud accordingly to the standard. There is
although a possibility to speed things up when using the same protocol while loading
new software to an ECU. Making some acquisitions once again at different rates. This
is made in Laboratory and saved with LabNotebook for future analysis.
8.5 Measurement to be done for characters.
7.3.1 For Workplace environment, earlier measurement from 7.1.2 can be used. For
Laboratory, where physical attachements to Tx and Rx are simply not available this
has to be solved with some other method. This I will present later, revealing that once
again WaveScan offers a quick answer when setting up with search criteria and filters.
7.3.2 Methods used in 7.3.1 works here as well.
8.6 Measurement to be done for messages.
7.4.1 WaveScan feature makes things simpler to an engineer once again.
7.4.2 Measurement to be done at both Workplace and Laboratory. This time with higher
settings in sample rates. Expecting very short delays. Acquisitions made on several
different ECU’s to reveal specifics for each and all.
7.4.3 Make assumptions based on the large amount of aqcuisitions made when analysing.
More work to be done here if wanting automatic measurement. Conclusions have been
made, returning to this topic later.
8.7 Measurement to be done for further analysis.
Most effort to be put into solving earlier stated requirements. Some reflections and
conclusions made at this exciting topic comes later.
9. Results
Following table show a very brief summation of what has been possible to view/measure with
the DSO at this state. Some values presented together with picture numbers in where to find
specific data. Much more measuring and monitoring to make on existing systems before
giving guarantees of behaviour. So far everything looks accordingly to the specifications.
Custom made scripts should be able solve problems concerning 7.5.1 - 7.5.5. WaveScan
feature of the DSO, with proper settings, offers a very useful software tool in search for some
events of interest.
20

Requirement nr Result Comment Figure
7.1.1 Bus state levels X 3.6 - 4.0 V 6-9, 20, 22-26
7.1.2 Bits and voltage differences X 10, 12
7.2.1 Verify bit time X 104 μs 13, 14
7.2.2 Low-to-high delay X 5.61 μs 12
7.2.3 High-to-low delay X 91 ns 15
7.2.4 Higher frequecies X 16-19
7.3.1 Interpretation X 11, 14
7.3.2 Character time duration X 1.0399 ms 11, 14
7.4.1 Idle state X 20
7.4.2 Inter byte delays X 0–104.7 μs 21
7.4.3 Message lengths X 22-26
7.5.1 Unknown-zone ---
7.5.2 Traffic load on bus (X) (WaveScan) 20
7.5.3 Count collisions ---
7.5.4 Monitor communication (X) (WaveScan) 27
7.5.5 Decode messages --- (test of script)
Table 1: Results in brief
Having used LabNotebook features offered by the DSO throughout the work when saving
interesting waveforms, makes it easy to present result. A picture contains so much
information. This method of presenting results will be used and commented demand after
another. Let us begin with having analysis to be done on bus state levels...
21

9.1 Analysis of results
Figure 6: Voltage levels on bus, workplace
Voila! This is how things can be presented with this LabNotebook feature of the DSO.
Display with colours if desired, markers with descriptive labels on what is measured and the
parameters P1 – P8 with values obtained by DSO parameter functions.
In the lower left corner, boxes Z1(yellow) and Z2(blue) indicates that a zoom of a trace has
been performed on the original waveform to have a closer look at details. Of cource the
displayed waveforms accordingly to respective colours. The small arrow at the lower left of
the grid, just above the ‘Measure’ text, indicates that the actual trigger that captured the
original waveform did occure earlier in time. Time is intuitively elapsing from left to right in
the picture. From within the ‘Z-boxes’ data is given on how the displayed waveforms and grid
relate in time (horizontal) and voltage (vertical) scales. In this case 415 μs * 10 grids make it
a total of 4150 μs that has ‘ticked’ when leaving the left side and reaching the opposite side of
the screen. Hence this picture displays at least three characters captured when travelling on
the bus. This is how it works. There exists a lot of other built-in features to use. Having in
mind that there is a lot of possibilities in customizing looks and functionality if not enough.
What a fantastic Instrument this is!
Please note that ‘Tbase’ and ‘Trigger’ boxes in lower right corner are used when setting up
the instrument prior to acquiring desired action. Tbase have settings, most importantly, on
sample rates and thus length of captured data in time. Trigger-box, when opened, enables
trigger settings to change. Trigger condition met is the thing that starts the acquisition of data.
Readings inside the Tbase-box tells that the acquisition was made with 25 M samples per
second and with the time/div setting of 20 ms, the original displayed waveform contained of
5 M points of data. (Be aware of following. If working on saved waveform data that has been
uploaded to the instrument, then one must not trust on the values shown in the boxes. These
are then simply content of earlier captures done).
That was a lot of information from one single picture! Lets continue with the work…
22

Figure 7: Voltage levels on bus, laboratory equipment
This capture (fig.7) made on the Laboratory equipment with a live system consisting of
several ECU’s communicating. Analysis of revealed data tell us that everything is nice. What
is shown here are two channels M2 and M3, by that we know this being saved waveforms
uploaded into DSO memory. In the parameter P1 – P4 readings, values are for the red trace.
P5 – P8 have data on the blue trace. The red trace is point A measured on the bus, this
because it toggles at higher voltage levels than the blue. The blue one is a probe attached onto
point B. At least possible to make these conclusions just by hooking probes on the bus on the
run. More information shall follow. Before finishing this one.Voltage levels are toggeling
between top and base readings with 4.772 V and 875 mV for the measured point A on the bus
and 4.097 V – 102 mV at point B (for A and B see fig.5).
Conclusion to make, the analysis on this requirement is proven. Measurements to be read in
the P1 – P8 values, clearly show that bus state levels according to standards are met.
Next to follow, an additional trace from laboratory environment that spans over a very long
period of time. According to M3 data it is a 200 ms * 10 = 2 second long trace. This is made
on a single channel. Because majority of the values are at high voltage levels, a conclusion of
that , point A is measured and displayed here. How do we know that? Remembering that the
bus have to be in an idle state before bus access is allowed. Idle state exist when logical high
level. Those peaks that point down are separate messages exchanged on the bus. Also note
that some peaks are longer than others, reaching negativ potential at some occations.
According to P6, -384 mV. More on this later…
23

Figure 8: Very long trace from bus A with voltage levels
Below, measurement on communication at point B on the bus at Lab. Trace (red) from same
instant as the (blue) A bus above.The yellow pillars show histogram – statistical data together
with parameter measurements. Note that this looks more stable, the peaks are smaller here,
4.8 volts according to P4 : pkpk(M2).
Figure 9: Very long trace from bus B with voltage levels
24

Figure 10: High sample rate acquisition
Workbench measurement having physical connections to Tx and Rx available. This
acquisition (fig.10) is captured at very high sample rate to get the details. The memory traces
show a lot of information. Besides the data needed to verify that receiving bits follow the
differences between bus state levels >= 0.2 V. Persistence mode with colour on displayed
traces helps to sort out when this change in state for Rx occurs. Manual measurement with
cursors. Value that confirms valid behaviour in the M-boxes. Δy = 201 mV.
Figure 11: Measurement with WaveScan
Physical Rx with WaveScan features applied on. Once again a picture that many things can be
read from. This time with annotations included with the LabNotebook. WaveScan gives
highlighted areas on features found and table ldx on left hand side. This (fig.11) show all ‘1’
in a message. Values in table measures the marked areas in the trace, pulse after another.
25

Left most marking shown at the first row in ldx-table. It is easy to make the feature to show
zeros instead, or why not both. With this kind of data is also possible to verify requirements in
7.3.1 and 7.3.2
Figure 12: Low-to-high transition delay
Low-to-high transition delay as it looks with physical TX and Rx available at Workbench
environment with one single ECU connected. Applying manual measurement with cursors
show Δx = 5.610 μs in lower right corner. This is well within acceptable 10 μs according to
the SAE J1708 standard. Returning to the question of how to search for an answer at ‘real’
measurement on the bus when physical Tx and Rx simply is not there? It is reasonable to get
a very good approximisation when observing the fact that, at the very instant Tx (yellow)
drops in level, the A (blue) shall begin rising. Activate WaveScan with the criteria to measure
between base level of the A bus and when reaching level that is 0.2 V more positive than the
one on B. This will enable automatic measurement to be performed by the WaveScan
software. If not accurate enough, stop and make manual measurement with same assumptions.
Figure 13: Bit times and WaveScan
26

Here WaveScan is in use at the Laboratory (fig.13). Automatically and quickly presenting
data on bit times from the bus. Zoom in and let the software reveal even better readings if the
original waveform acquired at high sample rate.
Figure 14: One character
Of cource there is the possibility to measure manually, now that the interesting features have
been captured. Here one character displayed with highlighted areas. With this kind of data it is
also possible to verify requirements 7.2.1, 7.3.1, 7.3.2 and 7.4.2 on ‘real’ systems. Hence
verified from now on that this particular character consist of…
• One low level startbit (0)
• 8 data bits to follow ( 1101 1010 ).
• Ended by one stop bit (1), with possibly added time for interbyte delay.
Comparing ldx values 6 and 8 from the table, tells us that no interbyte delay noticed. If still
not satisfied make another even more detailed acquisition. Manual use of cursors to measure
time duration of this character gives Δx = 1.0399 ms. According to the standard, within
10 * 104,17 µs = 1.0417 ms ± 0.5 %. This is now verified.
27

Figure 15: High-to-low transition delay
High-to-low transition delay as it looks with physical TX and Rx available in the Workbech
environment with one single ECU connected. Use of very high sample rate. Δx = 91 ns.
This value is expected to grow with connected units. 0.6 - 2.3 µs or below acceptable. The
interested reader should also have noticed the numerous alternatives to present waveforms on
the screen.
This and following page shall reveal content from measurements done when communicating
at higher baud rates. Traces are shown in following order, 9600, 38 400, 57 600 and finally at
115 200 baud (figures 16, 17, 18 and 19).
Figure 16: 9.600 baud
28

Figure 17: 38.400 baud
Figure 18: 57.600 baud
Figure 19: 115.200 baud
Top and base levels at 38.400 baud are getting shorter. Differences in voltage levels may no
longer be interpreted as they should at rates 57k and 115k. New changes in bus state levels
between A and B happens before they even have the state of the previous one. These traces
were catched when flashing ECU with new software in Laboratory. It did not succeed.
Uploading failed, leaving ECU in a corrupted state because some vital data was already saved
in memory before crashing.
29

Figure 20: Idle state times on bus
WaveScan highlighting events from Lab on a trace that spans over 200 ms. Features found
show time for bus in idle state. Sections with peaks are different messages accessing the bus
when fulfilling bus access time based on priority of the message to be sent. Easy to confirm
length of messages with use of cursors. Table show 9 events, a conclusion that 9 – 1 = 8
complete messages displayed. Once again there is some unit sending messages having peaks
larger than usual. Who could this be?
Figure 21: MID, Message Identifier
30

A closer look at messages 1, 2, 4 and even the longer message nr 7 (fig.20). They all show the
same bit pattern in first character. This message identifier (MID) manually decoded to
(0000 0001) equals to 128, identifies a specific ECU. The zoom at this wave (fig.21) clearly
shows the negative overshoot deviating from normal base level. This ECU also differs from
the others in use by having an interbyte delay. Compare bit times for a usual (1) at row 6 in
table, with a stopbit and delay found at row 10. Interbyte delay of this unit counts
approximately, thus obtained with WaveScan, to 104,7 µs.
Next to be presented are several different identified units exchanging data in the Laboratory.
An alternative way of viewing traces here. Some original waveform loaded into DSO memory
and at the same time zoomed in for further analysis. Both visualized at the same time. I leave
comparison of values to the interested reader (figures 22, 23, 24, 25 and 26).
Figure 22: Unit to identify
31

Figure 23: Unit to identify
Figure 24: Unit to identify
32

Figure 25: Unit to identify
Figure 26: Unit to identify
33

10. Future work/recommendations
• Use of EXCEL to add idle state times in ldx table gained with functionality offered by
WaveScan. It might give easy calculation of bus utilization.
• Study use of Histograms in more detail to present statistical distribution of events.
It might give easy calculation of bus utilization.
• Study found collisions closer. Visualised in this capture by having short pulses and
strange wobbeling at top levels in the beginning (2:nd pulse width < 72 μs in fig.27 ).
Figure 27: Collision
• Develop a ‘J1708 DECODER’ with VBScript that monitors and decodes messages in realtime
traffic, highlighting when search criteria met. Further development on tested scripts
with promising result. Let’s have a look…
34

Figure 28: VBScript and simulated RX vs. real physical RX
Above, F1-box shows that VBScript is in use having yellow colour in the trace. It follows the
physical ‘the real’ Rx information very nice (waveform in green colour).
Figure 29: Simulated RX and WaveScan in laboratory environment
VBScript that simulates the missing physical Rx in Laboratory environment. Presented
together with WaveScan having appropriate set-up (fig.29). Simulated Rx follows this nice
too (the yellow trace follow the edges of highlighted features that indicate approximative
times of changes in state calculated by WaveScan). This is propably good enough for
decoding purposes. No need to follow precisely though use of simulated Rx in decoding
35

would be by reading values somewhere in the middle of pulses… Still much work to be done
especially not knowing how use of script slows down acquisitions. A rule of thumb states that
sample rates should be minimum 4 * bit rate. Preferably 10 * bit rate to be able to alert on
some transients as well [5],[6]. This would give sample rates 10 * 9600 = 96kS/s. Sample rate
settings offered by the DSO range from 250 S/s…100 kS/s, 250kS/s, 500kS/s, 1MS/s,
2,5MS/s…5 GS/s (max. 10 GS/s if 2 channel mode in use). One might also expect trouble
with sychronization issues if dealing with several scripts.
11. Summary and conclusions
The main questions made in the problem formulation part of this thesis was
1. how do delivered ECU’s implement the recommended practice when interchanging
data…
2. …and how about the WaveRunner 104 MXi, is it capable of answering this? If so, show
wether it is a suitable tool or not for verification and analysis
From now on this should stay clear! Measured units do behave accordingly and yes, most
important of all, this is a great tool to use. By offering that much, easy to use, built-in
functionality to apply on measurements, makes it a great joy to work with this instrument.
Wether performing live monitoring of communication or analyzing parts of saved acquisition
data.
Document and share results in an easy way with the LabNotebook feature of the DSO. Create
reports and annotate captures if desired. Launch prepared set-up’s to get started quickly with
measurements. Load/save own settings having different functions activated when measuring
or analysing data. This feature makes it possible for a person less involved to make some
measuring as well.
WaveScan offers easy to use functionality to quickly find many events of interest or monitor
and alert when something deviates from the expected. It might not always deliver exact values
but nevertheless capable of finding events that may be further analysed manually in detail. A
tip! Use lower sample rates when searching (faster processing when limiting the amount of
data), when or if found features of interest, make a quick analysis and perform another
acquisition, this time with higher sample rate settings to get all the details.
And finally, custom functionality offered by scripting. Only imagination, processing speed
and memory put limit on what is possible to solve. Concerning this thesis work, additional
information/achievements would be offered if able to make monitoring and decoding of
ongoing communication. With decoded messages it would be straightforward to confirm
stated behavior of a complete system in use, and this only by connecting probes to a running
system. This would make it possible to measure on an operating machine out on the field. It
seems possible to solve complicated problems by adding custom functionality with further
development of scripts. The possibility to insert scripting in the processing chain of the DSO,
gives immense power to this fantastic instrument.
To all the involved people at the VCE Component Division I would say, ‘Congratulations to
money well invested!’
36

References
[1] http://www.lecroy.com
[2] LeCroy, Xi Series Oscilloscopes Operator´s Manual, LeCroy Technical Reference Manual, pages 49-,
109-, 147-, 160-, 167-, 227-, Feb. 2008,
http://www.lecroy.com/tm/library/manuals/WRXi/OperatorsManual/WRXi_OM_REVB.PDF
[3] LeCroy, WaveRunner Mxi Datasheet, LeCroy Corporation, page 2,
http://www.lecroy.com/tm/products/scopes/MType/WaveRunner_MXi/WRMXi.pdf
[4] LeCroy, WaveScan Datasheet, LeCroy Corporation,
http://www.lecroy.com/tm/products/Utilities/WaveScan/wavescan.pdf
[5] LeCroy, How Fast Must I Sample?, LeCroy Application Brief, No.LAB429,
http://www.lecroy.com/tm/library/LABs/PDF/LAB429.pdf
[6] LeCroy, Electronics And DSO Applications, LeCroy Technical Writing,
http://www.lecroy.com/tm/library/AppNotes/HighSpeedElectronics/
[7]LeCroy, LabNotebook, LeCroy Application Brief, No.LAB_WM823A,
http://www.lecroy.com/tm/Library/LABs/PDF/LAB_WM823A.pdf
[8] http://sv.wikipedia.org/wiki/Controller_Area_Network
[9] http://en.wikipedia.org/wiki/J1939
[10] http://en.wikipedia.org/wiki/RS485
[11] http://www.wikipedia.org
[12] Society of Automotive Engineers (SAE) J1587 Recommended Practice, rev February 2002
http://www.sae.org
[13] Society of Automotive Engineers (SAE) J1708 Recommended Practice, rev October 1993
http://www.sae.org
[14] http://en.wikipedia.org/wiki/J1587
[15] http://en.wikipedia.org/wiki/J1708
[16] http://sv.wikipedia.org/wiki/UART
37

Appendix A
Technical data
Technical data for the WaveRunner 104 MXi
Aqcuisition modes for measurements Normal, Auto, Single, and Stop
• Pre-trigger Delay: 0 to 100% of memory size (adjustable in 1% increments or 100 ns)
• Post-trigger Delay: 10,000 divisions in real time mode; limited at slower time/div settings
• Holdoff by Time or Events: 1 ns to 20 s or from 1 to 99,999,999 events
Basic Triggers
• Edge/Slope/Line: Triggers when the signal meets the slope and level condition.
• Width: Triggers on positive or negative pulse widths. Selectable from 500 ps to 20 s or on
intermittent faults (subject to bandwidth limit of oscilloscope).
• Pattern: Logic combination (AND, NAND, OR, NOR) of 5 inputs, triggers acquisition.
• State or Edge Qualified: Triggers on any input source only if a defined state or edge
occurred on another input source. Delay between sources is selectable by time or events.
SMART Triggers
• Dropout: Triggers if signal drops out for longer than a selected time-out , 1 ns- 20 s.
• Glitch: Triggers on positive or negative glitches with selectable widths from 500 ps to 20 s
or on intermittent faults (subject to bandwidth limit of oscilloscope).
• Signal or Pattern Interval: Triggers on intervals selectable from 1 ns to 20 s.
• Runt: Positive or negative runts defined by voltage and time limits, 1 ns - 20 s.
• Slew Rate: Activates a trigger when the rising or falling edge of a pulse crosses two
threshold levels.
Rapid Signal Processing
• Processor: Intel® 2.0 GHz or better with MS Windows® XP Pro Platform
• Processing Memory: 512 MB with VL options
Internal Waveform Memory
Waveform: M1, M2, M3, M4 (Store full-length waveforms with 16 bits/data point.) Or save
to any number of files (limited only by data storage media).
• Trigger Rate: 1,250,000 waveforms per second
Maximum Acquisition Points 2 Ch/4 Ch VL Memory Option 12.5M/25M
Acquisition System All Channels 5 GS/ • 2 Channel Max.: 10 GS/s
Acquisition Processing
• Time Resolution (minimum, single-shot): 200 ps (5 GS/s); 100 ps (10 GS/s)
38

Sample code
‘Sample code written in VBScript to simulate physical Rx
Function Update()
End Function
'VBS code
startData = 0
endData = InResult.Samples - 1
ReDim simulRxArray(InResult.Samples)
scalarData1 = InResult1.DataArray(false)
scalarData2 = InResult2.DataArray(false)
' InResult.DataArray(False) provides integer data from -32768 to 32767.
' InResult.DataArray(True) provides real data
' in the same unit as the vertical scale of the trace.
For i = 0 To endData
if scalarData1(i) > (scalarData2(i) + 800 )then
simulRxArray(i) = 16700
else
simulRxArray(i) = 350
end if
Next
OutResult.DataArray(false) = simulRxArray ' integer data
39