Hi Fratink
In preparing a reply I was under the impression most vehicles used CAN....how wrong was I !
Just a look at this page a bit later put me straight and scrolling down to the table Vehicle Messaging Protocols shows a few in common use.
https://en.wikipedia.org/wiki/Vehicle_busSo when looking up some links for ISO9141 I stumbled on another Wikipedia page with this:
https://en.wikipedia.org/wiki/On-board_diagnosticsISO 9141-2. This protocol has an asynchronous serial data rate of 10.4 kBaud.
It is somewhat similar to RS-232; however, the signal levels are different, and communications happen on a single, bidirectional line without additional handshake signals. ISO 9141-2 is primarily used in Chrysler, European, and Asian vehicles.
RS-232 is considered similar to UART so that's what I'd initially try which it seems you have.
For any protocol we must determine what the idle state is in relation to the data packet and for most it is idle high therefore the first edge of all packets is falling so it's best to set our trigger for such.
I like to start by obtaining rock solid triggering on the edge of any old packet and for this to happen you require 2 very simple settings to be correct:
Edge, already mentioned
and the prevention of retriggering
until after any packet has finished.
This is accomplished by first determining the widest packet and setting trigger Holdoff for a little more.
How to do it.
Set a timebase with a few packets displayed, it doesn't matter that triggering isn't stable and press Run/Stop.
Find the widest packet and in the timebase you are using count the graticules that packet is covering. Multiply this count by the timebase setting and you have your holdoff value.
Now, in the Trigger Setup menu with the correct edge set and holdoff sufficient until after the packet is finished press Run/Stop and you should have rock solid stable triggering. Don't proceed until you have.
Now it's time to make settings to decode, first by selecting the correct protocol, baud rate, assigning channels and setting thresholds then engage decode Display.
Next, depending on the timebase chosen will determine how many packets are displayed and if there is enough room on the decode line to show the decoded result.
We can use the H Pos control to shift the trigger position left so to fit the result on the display or preferably zoom out so many packets are displayed and then engage Zoom for a dual timebase split display where we will have many packets in one window and just a portion of these in the zoomed display.
In the zoomed portion we can use the H Pos to pan through the whole primary timebase inspecting decoded results all the way.
So if you have your head around all that we can look at methods to capture the very start of a stream or packets within it.
For the first packet we could just use Single shot so when the packet stream starts (key switch or whatever) we capture the edge of the first packet and then as many as the scopes memory can hold.
This is where a slow primary timebase is your friend as memory depth is greatest and it's not unusual to capture 100's of packets to then be inspected with the zoomed timebase.
Packets within a stream need use of protocol trigger settings which are somewhat more involved which set specific bits on which to trigger on.
Sounds hard but it's not and procedures like these are the real power of a DSO with good memory depth.
I'll leave you with a selection of screenshots with a step by step walk through of how I've done it before preparing this reply albeit they are in CAN.
Home
Help
Search
Login
Register
