Sae J1708
Sae J1708
Sae J1708
Component Division
2
Abstract
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.
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
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…
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...
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.
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.
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].
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.
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…
• 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 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…
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.
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.
“Since the scanning modes are not simply copies of the hardware triggers,
but "software triggers," the capability is much greater.” [2]
6.2 LabNotebook
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.
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.
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.
Verify differences for bus state levels greater than or equal to 0,2 V. (4.2).
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).
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
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
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.
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 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.
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).
Verify total amount of time for one character within 10 * bit time. (6.2).
7.4 Messages.
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).
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
7.5.1 Unknown-zone
• 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).
Make the instrument to monitor and notify, or log, events of interest not following the
recommended practice in the SAE J1708 standard [13].
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…
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.
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).
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.
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.
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…
…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.
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.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.
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
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
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).
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).
24
Figure 10: High sample rate acquisition
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
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.
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…
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).
28
Figure 17: 38.400 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?
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).
31
Figure 23: Unit to identify
32
Figure 25: 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 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 ).
• Develop a ‘J1708 DECODER’ with VBScript that monitors and decodes messages in real-
time 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).
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.
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
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.
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).
Acquisition Processing
• Time Resolution (minimum, single-shot): 200 ps (5 GS/s); 100 ps (10 GS/s)
38
Sample code
Function Update()
'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
End Function
39