Cracking the K-line

calbiker

Well-known member
Just starting out, trying to make sense of the K-line. Help is welcomed.

I built a comparator circuit that converts the 12V K-line signal down to 5V which is then read by Arduino Uno, and then uploaded to a laptop and read by a program called Putty.

There's 5 attached files reading the K-line when ScanGauge is active. In order to keep it simple, the first 4 files have SG programed to just display one parameter (4 times). The 5th file reads FIA, H2O, LOD, VOLT. The engine was not turned on. LOD = 0, FIA & H20 were in the upper 60's, and VOLT about 11.2V.

In case anybody is interested, here's the Arduino code I'm using to read the voltage converted K-line on Uno pin 2.

#include <SoftwareSerial.h>

SoftwareSerial mySerial(2,3); // RX, TX
void setup()
{
Serial.begin(115200);
Serial.println("Hey There");

mySerial.begin(10400);
}
void loop()
{
static int count = 0;
if (mySerial.available())
{
int inByte = mySerial.read();
if (inByte == 0x01 && count >= 5)
{
Serial.println(' ');
count = 0;
}
Serial.print(inByte, HEX);
Serial.print(' ');
++count;
}

}
 

Attachments

220629

Well-known member
Interesting stuff. :thumbup:

It's way above any understanding that I have so I can only offer encouragement.

Have fun. Keep us informed.

:cheers: vic
 

calbiker

Well-known member
Not sure this is fun...

Here's a couple of documents for Keyword Protocol 2000. This is supposed to be equivalent to ISO 9141 which Mercedes is supposed to be using.

http://www.alfa145.co.uk/obd/14230-2s.pdf
http://www.alfa145.co.uk/obd/14230-3s.pdf

Message structure: header, data bytes, checksum

Header:

1. Format byte
The format byte contains 6 bit length information and 2 bit address mode information.

2. Target address byte
This is the target address for the message.

3. Source address byte
This is the address of the transmitting device.

4. Length byte
This byte is provided if the length in the header byte (L0 to L5) is set to 0. It allows the user to transmit messages with data fields longer then 63 bytes.

Data Bytes
The data field may contain up to 255 bytes of information. The first byte of the data field is
the Service Identification Byte.

Checksum Byte
The Checksum byte (CS) inserted at the end of the message block is defined as the
simple 8-bit sum series of all bytes in the message, excluding the Checksum

Here's a summary of the SG data loop. I'm not sure why the "1" is generated at the start of a line and "F1" at the end. The Arduino sketch insets a line feed when it reads 0x01. I don't know the rational for this. There's nothing in the protocol for ending transmission with 0x01. Transmission ends with the check sum. This data has no correlation with the protocol. Not sure if the sniffer is at fault.


LOD
1 10 F7 84 F1 12 41 10 0 61 39 C2 33 F1

1 C F3 84 F1 12 41 C 0 0 D4 C2 33 F1

1 4 EB 83 F1 12 41 4 0 CB C2 33 F1

1 D F4 83 F1 12 41 D 0 D4 C2 33 F1

1 F F6 83 F1 12 41 F 39 F C2 33 F1

FIA
1 10 F7 84 F1 12 41 10 0 64 3C C2 33 F1

1 C F3 84 F1 12 41 C 0 0 D4 C2 33 F1

1 D F4 83 F1 12 41 D 0 D4 C2 33 F1

1 F F6 83 F1 12 41 F 38 E C2 33 F1
1 5 EC 83 F1 12 41 5 3C 8 C2 33 F1

H2O
1 10 F7 84 F1 12 41 10 0 61 39 C2 33 F1

1 C F3 84 F1 12 41 C 0 0 D4 C2 33 F1

1 D F4 83 F1 12 41 D 0 D4 C2 33 F1

1 F F6 83 F1 12 41 F 39 F C2 33 F1
1 5 EC 83 F1 12 41 5 3C 8 C2 33 F1


Volt
1 10 F7 84 F1 12 41 10 0 64 3C C2 33 F1

1 C F3 84 F1 12 41 C 0 0 D4 C2 33 F1

1 D F4 83 F1 12 41 D 0 D4 C2 33 F1

1 F F6 83 F1 12 41 F 38 E C2 33 F1
1 5 EC 83 F1 12 41 5 3B 7 C2 33 F1

LOD, Air, H2O, Volt

1 10 F7 84 F1 12 41 10 0 61 39 C2 33 F1

1 C F3 84 F1 12 41 C 0 0 D4 C2 33 F1

1 4 EB 83 F1 12 41 4 0 CB C2 33 F1

1 D F4 83 F1 12 41 D 0 D4 C2 33 F1

1 F F6 83 F1 12 41 F 39 F C2 33 F1
1 5 EC 83 F1 12 41 5 3C 8 C2 33 F1
 

312d

Member
by no means i do understand what you are trying to achieve, since this is a stretch to my mind, but i saw days ago a video explaining can communications, and i think i got a general idea of how it works this digital stuff from that video, unfortunatelly it is not related to this ISO9141 protocol, but this might help others to unveil one layer of the onion.
cheers.
https://www.youtube.com/watch?v=RRbrk3SdSKA
 

calbiker

Well-known member
I should state my objectives. Worst case scenario is to learn a little about the k-line. Best case is to be able to communicate with the transmission to get for example transmission temperature. Even better, to achieve the knowledge base to replicate DAD functions.

I got a break through in understanding my logged data. The Volkswagen K-line Communication Description document helped a lot.
https://www.google.com/search?q=k-line+communication&ie=utf-8&oe=utf-8

The paper describes 3 types data exchanges:
1. Initialization, start communication
2. Start Communication response message
3. Data Exchange

1. Initialization, start communication (from tester)

The Start Communication request message:

format byte = C1
target address byte = 33
source address byte = F1 (this is the tester)
service ID byte = 81
check sum = 66

C1 33 F1 81 66 And that's what I'm reading

2. Start Communication response message (from vehicle)

format byte = 83
target address byte = F1
source address byte = 12
service ID byte = C1
the key bytes yy zz = EF 8F
check sum = C5

83 F1 12 C1 EF 8F C5 Again, that's what I'm reading

3. Data Exchange
The paper doesn't go into much detail. It starts out from the tester:

For vehicle key bytes 8F EF the Service 1 PID 00 request message is:
C2 33 F1 01 00 E7

I'm reading a slight variation:
C2 33 F1 01 0D F4

What I learned so far that the Putty data log has entries starting with 1 and ending in F1. This is not the real start and end of a data exchange. The Arduino sketch chose 01 as the point to insert a carriage return. A carriage return doesn't actually belong there. That's not a problem as long as we know F1 is not the end of a data exchange and that the following byte is 01.


by no means i do understand what you are trying to achieve, ...
 

220629

Well-known member
This may not apply.

VW and MB both have a Bosch brand ECM aka ECU. Does that set the K-line communication protocols, or do the various brand vehicles make complex custom changes?

If Bosch sets the standard it may be worth researching some of their information.

:cheers: vic
 

220629

Well-known member
This overview by Ord is probably basic, but maybe there are some clues.

Ord article said:
Sprinter Electrical Systems
BY DAVID A. KOLMAN ON MAR 11, 2010

http://www.vehicleservicepros.com/article/10329448/sprinter-electrical-systems

With most domestic vans and light trucks, the level of connectivity and complication is minimal compared to a Sprinter. The key to proper service and repair of this vehicle is the CAN - the Controller Area Network. Also called the CAN-Bus, it is a vehicle standard designed to allow all control units to communicate with each other and share data over a simple wired network.

The Sprinter is 100 percent Mercedes-Benz, not a Dodge/Freightliner chassis with a Mercedes engine. As such, the Sprinter is not an a la carte vehicle that has components picked from multiple suppliers like many domestic trucks. It has all Mercedes components, designed to work together at the factory.

Consequently, the Sprinter does not diagnose like Dodge, Isuzu or Ford vehicles. Mercedes vehicles log a lot of fault codes and event codes for most operational faults. Being able to read and understand fault codes on all control units is vital to diagnose CAN-Bus problems.

To better understand the fundamentals of the Sprinter's electrical system, Fleet Maintenance Magazine editor David A. Kolman visited with Eric J. Ord, a highly regarded independent source of Sprinter technical information. Ord has developed three separate scan tools for the Sprinter, one of which was delivered to all the locations in the U.S. and Canada for the world's largest fleet operator. Over the years, Ord has conducted more than 100 training courses on the Sprinter and has written numerous technical materials on Sprinter diagnosis and repair.

Ord is managing director of Megara LLC. With offices in the U.S. and Europe, the company is involved in projects with several commercial and municipal fleets on Sprinter vehicles, as well as other projects for U.S. and foreign military customers with Mercedes-Benz vehicles.

NUMEROUS CONTROLS


For most domestic vans and light duty trucks, the CAN-Bus traditionally has limited application, usually with the few sensor values shared between the engine, transmission and instrument cluster, Ord explains. With Sprinter, there are a lot of control units and sensors that, share information and transmit signals.

On the average model year 2002 to 2006 Sprinters, there are generally around 11 or more individual control units on one CAN-Bus network, he says. For 2007 to 2010 models, there can be more than 29 control units on three networks.

"Without a CAN-Bus network, a Sprinter would have either miles of wire or many duplicate sensors or both," he says. "The cost of all of this copper would add thousands of dollars to the vehicle price and hundreds of pounds of weight.

"The Sprinter is a Mercedes and Mercedes parts tend to be expensive. If the approach to solving a problem is just to replace parts until the problem goes away, that will put you upside down on the vehicle quickly."

CAN BEGINNINGS

The vehicle CAN-Bus concept was pioneered in Germany by Robert Bosch GmbH in the 1980s. Daimler-Benz AG was one of the first to adopt CAN-Bus for vehicles. In 1991, Mercedes-Benz started using a CAN-Bus for communications between electronic control modules (ECM) in passenger cars on the W140 S-Class 600SEL .

For commercial vehicles, the CAN-Bus has been implemented since the 1990s in two forms: a two-wire CAN for vans and light commercial vehicles, and a four-wire CAN for trucks and heavy equipment. The difference between the two CANs is double redundancy of signals versus single redundancy. Both systems use a twisted pair cabling to minimize interference.

When Mercedes designed the Sprinter back in the 1990s, Ord says the company saw the need to have all of the control units and sensor values shared over an automotive/industrial standard Bus system. The earliest European Sprinters had a very simple CAN with very few components linked. For North American Sprinter models, starting in 2002, CAN-Bus is used for all main systems and controls for powertrain, interior, chassis, etc.

There are other types of automotive networks which use fiber optic cables to broadcast complex network messages using light pulses, notes Ord. For 2007 to 2010 Sprinters, the MOST (Media Oriented Systems Transport) fiber optic network is used in some vehicles for in-vehicle entertainment, communications and navigation systems.

For 2002 to 2005 Sprinters, there is only one network (see Diagram 1): chassis/powertrain CAN (CAN C low speed). For 2007 to 2010 Sprinters, there are four (see Diagram 2): powertrain/chassis M-CAN (ISO CAN C high speed); interior (body) I-CAN (ISO CAN B low speed); diagnosis D-CAN (high speed proprietary MB protocol); and Digital Media Bus for radio/navigation system (MOST).

The networks connect to each other through gateway modules, he says. These gateway control units serve the same purpose as a network hub switch on an office computer network for different rooms or groups. The gateway control units, which also serve as a sort of translator from one type of network to the other, are arranged as follows:

• The instrument cluster (IC) is the interface between M-CAN and I-CAN.

• The electronic ignition switch (EIS) is the interface between M-CAN and I-CAN and between D-CAN and OBD2 diagnostic connector.

• The radio (COMMAND Audio Gateway) is the interface between I-CAN and MOST.

CAN OVERVIEW

"To begin with, it is important to know that the CAN Data Bus is a bi-directional Bus, that is, each connected control unit is able to send and receive messages," says Ord.

The CAN Data-Bus consists of a twisted-pair cable that is similar to network cables used for computer networks or telecommunications. All control units (computers) that are in the vehicle are connected to these cables. CAN cables are connected together at junction boxes or Z-splices, also called the J-Splice in some factory literature because Mercedes uses a "J" for junction to describe the location. Splices are soldered connections.

CAN-Bus cables express specific voltages when they are active and when they are idle. Each CAN cable is either CAN H, for high, or CAN L, for low. With CAN H cables, the voltage rises when CAN is active; with CAN L cables, the voltage drops when the CAN is active. Depending on the vehicle, type of CAN and speed inherent, voltage levels are a fixed value when sending or receiving.

Data is transmitted over both cables with the Bus levels being a mirror image of each other. In other words, if the level on one cable is 0, the other cable transmits the level 1 and vice versa, as a replacement for on/off signals from analog components in older systems.

"CAN-Bus cables are a twisted pair design. If troubleshooting wiring problems and a pair of cables are found twisted to each other, you may have just found the CAN-Bus network cables. The twisted pair wire concept is used for two reasons: for voltage fault identification and as a redundant safety concept. If a voltage peak occurs on just one line due to interference problems, the receivers can identify this as a fault and ignore the voltage peak.

"The twin cable design is also handy if a short circuit or interruption occurs on one of the two CAN lines. Software in the control units can reroute messages by switching to a single line. The damaged data line is shut down with CAN message speed slowed, but not stopped. Software on networked control units manages how and when the control units on CAN can send and receive messages."

DATA FLOW

The data flow path is important to understand for effective diagnosis, Ord points out. The 2002 to 2006 Sprinter CAN is set up in order of data flow. The engine control module is the first ECU, the immobilizer control unit (referred to as WSP for Chrysler; SKREEM by Mercedes-Benz) is the last. The CAN terminates at the ECM (CDI/CR control unit) and at the immobilizer control unit with a 120O resistor. In the 2007 to 2010 Sprinter, data flow is different as there are several networks and interfaces between the networks.

Each control unit sends and receives the messages, but only some will use them. Messages are sent along the whole CAN-Bus to all ECUs that are connected, explains Ord. The messages are disregarded and just sent along if it has no function for that ECU. The message will continue until it reaches the intended recipient for processing into a function or change.

In practical terms, a message from the crank sensor sends "engine speed" to the ECM. That message will be sent by the ECM along the CAN-Bus so "engine speed" can be accepted by the automatic transmission, instrument cluster, brake and traction system and other control units that have a need to process the message (see Diagram 3).

"The same message would just pass through a control unit that could not use the data and continue to pass along through the network unit it reached the endpoint terminating control unit."

CAN messages are a piece of data that contains seven parts, says Ord, and the CAN protocol allows up to 2,048 different message types. Each message is 8 bytes of data. This 8-byte message is also called the CAN Data Telegram. Each part of the message is important and provides the necessary information so that the content of the message can be received and used by the applicable control unit.

Within the message contents, the CAN Data Telegram shows which sensor sent it, the priority, the intended recipient (single ECU address or multiple ECU addresses), the subject (status of component X), the content of the message (actual data bytes), acknowledgment of receipt and end comment. As these messages can relate to status or operation, the contents can vary within the standards.

CAN-Bus software and hardware create an efficient network post office for messages. "To avoid confusion and a loss of data, each message can only be sent when the CAN Data Bus is free," Ord explains. "If several control units simultaneously start to send a message, a procedure called arbitration initiates. With arbitration, the network determines which message has the highest priority. Priorities are set due to the specific function initiated by the message."

By way of example, a message that contains "driver airbags deployed" has higher priority than "blower fan level." If a control unit's message is halted during arbitration, the sender will automatically repeat the message transmission as soon as the CAN network is free again.

"CAN messages are not just to broadcast status automatically," says Ord. "Some messages are requests for data from one control unit to another. The air conditioner/heater control unit may send a request message to the engine control unit for 'coolant temperature' to avoid overheating and the appropriate control unit then reacts to the request. Since 'coolant temperature' is used by several control units that continuously monitor this CAN message in real time, if the engine control unit is busy, another could send the coolant temperature status to the air conditioner/heater."

If there are any network problems or missing data, both the sending control unit and any receiving control units on the CAN-Bus will log either fault codes or CAN event codes.

PRACTICAL TROUBLESHOOTING

When control units and components are networked, a different approach is necessary to diagnose problems. Common faults can include drivability issues (low power, transmission in limp-home mode, etc.), convenience issues (no a/c, poor heat output, etc.) or operational issues (power windows not functioning, doors will not lock, etc.). When a drivability or operational problem is being addressed on a vehicle with CAN-Bus, limited knowledge of how CAN works can lead to a long and difficult process that may or may not yield any results.

Because the Sprinter is a fairly complex vehicle that has a lot of electronic control units, Mercedes engineers built in a very comprehensive fault logging capability in each control unit, Ord says. For many control units, there are hundreds of possible fault codes that provide a solid roadmap to pinpoint the cause of many types of vehicle problems. "Most CAN-Bus network problems are identified by the control units through fault codes; this is the first place to start the diagnostic process."

Understanding fault codes, also known as diagnostic trouble codes (DTC), "is the most important first step in identifying where a CAN-Bus network problem has occurred," Ord emphasizes. "It is critical that suitable scan tools be used for testing - ones that will actually recognize all of the control units, not just engine and transmission.

"CAN networking is one of the reasons that generic OBD2 scanners and multi-make scan tools are practically useless on Sprinters. They don't allow diagnosis of all the control units, so faults can't be easily pinpointed in a whole system, and keep in mind, all control units are on CAN."

An enhanced feature that is available on 2007 to 2010 model Sprinters is CAN Event Codes. These specifically relate to CAN network message traffic. CAN Event Codes provide very specific information relating to the CAN message, sender and anticipated recipient. "That makes troubleshooting easier because it breaks the possible causes down to a few likely suspects."

MORE INFORMATION

Additional information on CAN-Bus can be found in Daimler and Dodge service literature and through some aftermarket sources such as Robert Bosch publications. A complete guide to fault codes for Sprinters, plus helpful troubleshooting information, can be found in The Complete Sprinter Fault Code Guide - North American Edition, written by Ord. The format of the book, soon to be available on Amazon.com, is not diagnostic tool specific so it can be used by any technician, no matter the types of OEM and/or aftermarket scan tools.

"With the right tools and techniques, electrical issues on Sprinters can be easily overcome and problems solved efficiently," Ord concludes. "With the wrong approach, money is wasted on parts thrown into a vehicle until eventually the right thing is replaced."
vic
 

calbiker

Well-known member
Here's the cleaned-up data file from ScanGauge reading FiA (input air). ScanGauge displays 4 parameters. In this measurement, I set all 4 parameters to FiA.

HEX data starting with C1, C2 are sent by SG, and 83, 84 are sent from vehicle.
The last byte is the check sum (eg. 66, C5, EC). The CS is calculated by adding all the bytes together prior to the CS. In other words, C1+ 33 + F1 + 81 = 266. The last two digits of the sum 266 is 66. 66 is the checksum. I've checked the other entries for correct CS values.

The next step is to understand what they're saying.

FiA Input Air
C1 33 F1 81 66 Start comm from tester
83 F1 12 C1 EF 8F C5 Response from vehicle
C2 33 F1 01 05 EC
83 F1 12 41 05 3B 07
C2 33 F1 01 10 F7
84 F1 12 41 10 00 64 3C
C2 33 F1 01 0C F3
84 F1 12 41 0C 00 00 D4
C2 33 F1 01 0D F4
83 F1 12 41 0D 00 D4
C2 33 F1 01 0F F6
83 F1 12 41 0F 38 0E
C2 33 F1 01 10 F7
84 F1 12 41 10 00 64 3C
C2 33 F1 01 0C F3
84 F1 12 41 0C 00 00 D4
C2 33 F1 01 0D F4
83 F1 12 41 0D 00 D4
C2 33 F1 01 05 EC
83 F1 12 41 05 3C 08
C2 33 F1 01 10 F7
84 F1 12 41 10 00 64 3C
C2 33 F1 01 0C F3
84 F1 12 41 0C 00 00 D4
C2 33 F1 01 0D F4
83 F1 12 41 0D 00 D4
C2 33 F1 01 0F F6
83 F1 12 41 0F 39 0F
C2 33 F1 01 10 F7
84 F1 12 41 10 00 61 39
C2 33 F1 01 0C F3
84 F1 12 41 0C 00 00 D4 00
C1 33 F1 81 66 Start comm from tester **** Strange, communication starts over again
83 F1 12 C1 EF 8F C5 Response from vehicle
C2 33 F1 01 0D F4
83 F1 12 41 0D 00 D4
C2 33 F1 01 05 EC
83 F1 12 41 05 3C 08
 

calbiker

Well-known member
Things are moving along. Here's a plot of RPM when revving the engine. ScanGuage is requesting rpm. Arduino is sniffing the K-line. Data goes into Excel for rpm calculation and graphing.

rpm = (256 * A + B) / 4

A & B are the rpm data bytes after a HEX-TO-DEC conversion.
 

Attachments

calbiker

Well-known member
Just in case anybody wants to also sniff the K-line, I made a mod to the Arduino sketch. The logged data should now start with the initial byte of a transmission and end with the checksum byte.

BTW, I was looking for the battery voltage data on the K-line. ScanGuage does not request bat voltage from the ECU. I'm assuming SG has an on-board a/d and measures the 12V wire the OBD2 connector provides.

Next up is DAD. We'll see what he has to say.

Arduino sketch to sniff the K-line:
#include <SoftwareSerial.h>

SoftwareSerial mySerial(2,3); // RX, TX

const uint32_t DataDelay = 10000; //Delay in us to determine when transmission ends
uint32_t startMicros; //
static boolean busyFlag = false;

void setup()
{
Serial.begin(115200);
Serial.println("Hey There");

mySerial.begin(10400);
}
void loop()
{

if (mySerial.available() > 0)
{
int inByte = mySerial.read();
Serial.print(inByte, HEX);
Serial.print(' ');
busyFlag = true;
startMicros = micros();
}

else
{
if (busyFlag == true && micros() > (startMicros + DataDelay))
{
Serial.println(' ');
busyFlag = false;
}
}
}
 

calbiker

Well-known member
I have nothing that high tech. I'm old school. I use a land line at home and use a very basic phone when traveling.

There's already hardware available to up-link many vehicle functions to a smart phone. The ELM 327 with bluetooth can give a smart phone lots of vehicle info. But it can't communicate with the transmission of a T1N. That's because the transmission has a separate K-line (pin 11 of the OBD2 connector, while pin 7 is the only mandated line which goes to the ECU). At least that's how I think it works. We'll soon find out.



I wonder if this app could help with your objective:
 

calbiker

Well-known member
Some of this data can make your head spin.

Here's what I get when connecting DAD and checking for fault codes at the ECM (there are not faults). The first 3 bytes are part of the header. First byte is format, second is target address and third byte is source address. The second byte is either 12 or F3 (depending who's talking) and the third byte is again either 12 or F3.

12 = ECM
F3 = DAD

The first 2 lines are the standard start communication protocol.
81 12 F3 81 07 *********** from DAD to ECM
83 F3 12 C1 EF 8F C7 ****** from ECM to DAD

After that it goes into the unknown.

Some lines just have "0". That's probably noise on the bus that the sniffer picks up.


=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2016.05.23 10:55:03
Hey There
0
0
0
0
81 12 F3 81 07
83 F3 12 C1 EF 8F C7
82 12 F3 83 00 0A
87 F3 12 C3 00 00 EF 00 78 00 B6
87 12 F3 83 03 04 02 04 14 0A 3A
82 F3 12 C3 03 4D
82 12 F3 1A 86 27
92 F3 12 5A 86 64 71 53 28 79 43 02 28 04 03 45 92 00 06 07 24 BC
84 12 F3 18 02 FF 00 A2
82 F3 12 58 00 DF
0
84 12 F3 18 02 FF 00 A2
82 F3 12 58 00 DF
84 12 F3 18 02 FF 00 A2
82 F3 12 58 00 DF
0
 

calbiker

Well-known member
More data. DAD engine streaming. Engine is idling.

Approximate output data:
RPM: 685
Coolant Temp: 28C
Rail Pressure: 328 Bar
Pedal Valve Sensor 1: 0
Pedal Valve Sensor 2: 0
Activation Period: 6
Intake Pressure: 1004 mbar

It's not that easy understanding this. ScanGauge uses 0C as the PID to request RPM. There is no 0C PID in this data. Likewise, SG uses 05 to get coolant temp. There is no 05 PID in this data. They're talking a different language than the PIDs found here.

https://en.wikipedia.org/wiki/OBD-II_PIDs

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2016.05.23 16:17:46
Hey There
0
0
0
0
0 3C FE
0
0
81 12 F3 81 7
83 F3 12 C1 EF 8F C7
82 12 F3 83 0 A
87 F3 12 C3 0 0 EF 0 78 0 B6
0
87 12 F3 83 3 0 EF 0 78 0 79
82 F3 12 C3 3 4D
82 12 F3 1A 86 27
92 F3 12 5A 86 64 71 53 28 79 43 2 28 4 3 45 92 0 6 7 24 BC
82 12 F3 1A 90 31
93 F3 12 5A 90 57 44 58 50 44 39 34 34 38 36 35 39 36 35 37 39 34 95
82 12 F3 27 1 AF
85 F3 12 67 1 90 3 1E A3
82 12 F3 27 1 AF
83 F3 12 7F 27 12 40
82 12 F3 21 32 DA
9A F3 12 61 32 0 0 0 0 0 0 0 0 0 0 0 1 F4 0 0 0 0 0 0 0 1 2 0 0 2A
82 12 F3 21 22 CA
97 F3 12 61 22 FF 0 0 0 0 0 0 0 0 0 0 0 10 2 0 0 0 0 0 0 45 75
82 12 F3 21 3 AB
A9 F3 12 61 3 7 84 5 8E 3 EA B D9 3 F6 1 F4 1 F4 1 3 E2 4 A 25 1C B 90 12 E5 2 B1 0 0 0 0 0 0 B E1 A D5 5 C2 F0
82 12 F3 21 6 AE
A0 F3 12 61 6 2 AF 5 78 B E1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 26
82 12 F3 21 13 BB
8F F3 12 61 13 B D8 2 CF B 8F 2 AC FF FF B E1 0 EE
83 12 F3 30 58 1 11
85 F3 12 70 58 1 D 0 60
83 12 F3 30 11 1 CA
85 F3 12 70 11 1 7 60 73
82 12 F3 21 32 DA
9A F3 12 61 32 0 0 0 0 0 0 0 0 0 0 0 1 F4 0 0 0 0 0 0 0 1 2 0 0 2A
82 12 F3 21 22 CA
97 F3 12 61 22 FF 0 0 0 0 0 0 0 0 0 0 0 10 2 0 0 0 0 0 0 45 75
82 12 F3 21 3 AB
A9 F3 12 61 3 7 8B 5 7F 3 EA B D7 3 F6 1 F4 1 F4 1 3 E2 4 A 25 1C B 8F 12 76 2 A5 0 0 0 0 0 0 B E1 A DC 5 C1 70
82 12 F3 21 6 AE
A0 F3 12 61 6 2 A3 5 93 B E1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 35
82 12 F3 21 13 BB
8F F3 12 61 13 B D7 2 D3 B 8F 2 A8 FF FF B E1 0 ED
83 12 F3 30 58 1 11
85 F3 12 70 58 1 D 15 75
83 12 F3 30 11 1 CA
85 F3 12 70 11 1 7 57 6A
82 12 F3 21 32 DA
9A F3 12 61 32 0 0 0 0 0 0 0 0 0 0 0 1 F4 0 0 0 0 0 0 0 1 2 0 0 2A
82 12 F3 21 22 CA
97 F3 12 61 22 FF 0 0 0 0 0 0 0 0 0 0 0 10 2 0 0 0 0 0 0 45 75
82 12 F3 21 3 AB
A9 F3 12 61 3 7 6B 5 66 3 EA B D5 3 F5 1 F4 1 F4 1 3 E2 4 9 25 1C B 8F 12 E1 2 AC 0 0 0 0 0 0 B E1 A D7 5 D9 B8
82 12 F3 21 6 AE
A0 F3 12 61 6 2 A2 5 75 B E1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 16
82 12 F3 21 13 BB
8F F3 12 61 13 B D5 2 D1 B 8F 2 9E FF FF B E1 0 DF
83 12 F3 30 58 1 11
85 F3 12 70 58 1 D 19 79
 

smrl

Member
throwing more data at the problem...

http://www.alfa145.co.uk/obd/14230-2s.pdf
http://www.alfa145.co.uk/obd/14230-3s.pdf

This may not be the exact standard used on the Sprinter but I think it's close enough to give a lot of insight as to data structure...
I've been studying up on this a bit. Also saw an interesting video from defcon regarding ECU dumping/flashing and handshaking, using k-line protocol and bosch edc15/16 (t1n's are one of the two?)

https://www.youtube.com/watch?v=jzaUtq57JiQ
https://github.com/fjvva/ecu-tool
 
Last edited:

smrl

Member
See in particular 14230-2s, page 10 (4. Message structure)

One aspect that confuses matters is that it appears as though some messages set up the timing conditions for the response (since it's a one wire protocol, I guess this is for rx/tx arbitration)
 

owner

Oz '03 316CDI LWB ex-Ambo Patient Transport
Have you tried to get transmission temp using DAD? Maybe you don't need to know exactly what's going on, and just need to emulate what the DAD does to get AT temp.

I had the same idea of wanting AT temp, and EOT. My idea was to go directly to the drive CAN bus, which I have done before to get wheelspeeds from the ABS unit. I used a stm32 leaf clone board to do it which has CAN onboard. I have no idea if the temps I'm after are on that link though, never got round to looking for them.
 
Last edited:

calbiker

Well-known member
Eventually I want to connect CAN bus to a ELM327. The ELM327 will be controlled by Arduino. I'm hoping the ELM chip will take care of timing and arbitration.

See in particular 14230-2s, page 10 (4. Message structure)

One aspect that confuses matters is that it appears as though some messages set up the timing conditions for the response (since it's a one wire protocol, I guess this is for rx/tx arbitration)
 

calbiker

Well-known member
No, I haven't gotten to the transmission yet. I've had some problems. First, DAD wouldn't communicate. It started working again only after first connecting to ScanGauge and starting engine.

I have one XP laptop running DAD and another laptop storing the data on Putty. Don't know why, but the serial data won't store on the laptop anymore. It doesn't appear to come in. It did a few days ago, but not now. The USB connection works, as I can still load the sketch into Arduino. The sniffer seems to work OK too, as I can still store serial data on the XP laptop when reading SG, but that laptop is dedicated for DAD.

I'm going to change the sniffer setup. Instead of sending data to a laptop, Arduino will store the data stream on SD memory. I'll connect a SD card reader to Arduino. Further work will have to wait until after the grandchildren have left for the long weekend.

Have you tried to get transmission temp using DAD? Maybe you don't need to know exactly what's going on, and just need to emulate what the DAD does to get AT temp.
 

Top Bottom