D1 comms reverse engineering

[robertf]

airbag looks easy. 4800 bps, header, message checksum

alarm looks similar, 9600 bps, tons of bytes in the message but looks easily broken down into components like door switches.

I cant tell what's going on with ABS. it uses the k-line but it's not structured like iso9141. maybe VPW. Im sure the GEMS ECU is going nuts ignoring the trash on the serial line


I dont think even the scantool.net stuff will work, Im leaning towards arduino with a linbus adapter

 

[discostew]

I’ve got access to an old WABCO box. Is there anything to be learned from that thing?

wabco box is what we called the diagnostic tool specific to ABS.

 

[robertf]

Maybe, but I've got to figure out what language its talking first.
I've read about some features on other scan tools that this scantool doesnt have. that have to do with bleeding the system. This one only does codes and live data.

I think its 10400bps with a 25ms frame start and end bit, no start or stop bits mixed in. Haven't encountered anything like this before, kind of like j1850 but not enough to use an off the shelf tool

 

[discostew]

i have no clue as to how the messages are bundled. At my level it just looks like a solid packet of messages or it’s abnormal. I was aware of the differences in bps rates and understand that’s why it’s so damn hard to access all systems.
How about the latest greatest version of T4 software on a few discs. Would that help?

 

[nmstec]

ISO9141 K & L-line. Not linbus, which is much newer and very different.

K & L line look like a stream of unrelated messages, because as opposed to canbus and other protocols, K-L protocols split a single message into multiple packets.

To see who says what, use your scanner to request comms, and see what the first packet is. It will identify the address its on first, then the ECU will respond. You can also unplug the scanner during communication, and the ECU will attempt to reconnect by spamming the same message a few times. Theres your two addresses and message structure.

e.g: Scanner sends address -> Ecu responds with 55 for sync -> (scanner reconfigures to new baud rate from the sync byte) -> ECU then sends either 0808 or 9494 -> Scanner responds with an inverted value of either key. Aaand thats your init process.

For more information: https://www.obdclearinghouse.com/Files/viewFile?fileID=1380

 

[robertf]

only reason I want to use linbus adapter is the physical layer is the same as 9141, and you can get a dev board that makes it very easy to go from ttl to single wire for 6 bucks on amazon.

I havent seen any traffic on the L line, and its for sure not 9141-2 with the slow baud init and header addressing scheme.

Here's a sample. This is all from the K-line. the 25 uSec bit seems to be a frame start marker. I'm going to divide the durations of the other segments by 1/10400 to get the bit count.

It looks like the scantool is sending 00000000 and the ecu is responding with 00111111 11000000 00000000, but I could be way off.

Value	uSec
1	25
0	829
1	24
0	258
1	833
0	14884
1	24
0	509
1	25
0	1198
1	104
0	416
1	312
0	1678
1	25
0	828
1	25
0	668
1	728
0	104
1	104
0	1678

 

[robertf]

ISO9141 K & L-line. Not linbus, which is much newer and very different.

K & L line look like a stream of unrelated messages, because as opposed to canbus and other protocols, K-L protocols split a single message into multiple packets.

To see who says what, use your scanner to request comms, and see what the first packet is. It will identify the address its on first, then the ECU will respond. You can also unplug the scanner during communication, and the ECU will attempt to reconnect by spamming the same message a few times. Theres your two addresses and message structure.

e.g: Scanner sends address -> Ecu responds with 55 for sync -> (scanner reconfigures to new baud rate from the sync byte) -> ECU then sends either 0808 or 9494 -> Scanner responds with an inverted value of either key. Aaand thats your init process.

For more information: https://www.obdclearinghouse.com/Files/viewFile?fileID=1380

Apologies, you were correct about the L line. I think I had ground and channel 0 swapped on the Salae. Itd be nice if they didnt use black for both sig and ground. L line traffic now makes sense. 5 baud init, 0x8A. No inversion handshake, jumps right into 9600 on the reply.

K line has some trash on it, but thats easily ignored. Now to sort out the framing

 

[robertf]

0x40 0x80 LIVE DATA REQUEST BRAKE PEDAL PRESSED

0x8F 0x40 0x10 0xC1 0x86 0x7C 0x00 0x7C 0x00 0x7C 0x0 0x7C 0x00 0xFF 0x0F 0x00

0x40 0x80 LIVE DATA REQUEST BRAKE PEDAL NEUTRAL

0x8F 0x40 0x11 0xC4 0x8c 0x7C 0x00 0x7C 0x00 0x7C 0x0 0x7C 0x00 0xFF 0x0F 0x00



0x82 0x24 0x03 0x80 TOGGLE ABS LAMP TEST

0x04 RESPONSE

0x82 0x24 0x0C 0x80 TOGGLE ABS LAMP

0x04 RESPONSE

0x82 0x24 0x03 0x80 TOGGLE ABS LAMP

0x04 RESPONSE

0x82 0x24 0x00 0x80 TOGGLE ABS LAMP

0x04 RESPONSE

0x82 0x24 0x03 0x80 TOGGLE ABS LAMP

0x04 RESPONSE

0x82 0x24 0xFF 0x80 EXIT TOGGLE ABS LAMP TEST

0x04 RESPONSE


0x11 0x80 READ CODES (This one had lots of stored codes)

0x8D 0x11 0x04 0x41 0xFF 0x00 0x00 0x40 0x00 0x40 0x00 0x40 0x00 0x00

So in the live data and code reading the lower nibble of the first byte appears to be length. ABS toggle doesn't fit the mold, but I'll keep digging. No apparent cheksum, and request frame doesn't look like it has length. 4 and 8 look like addresses.

 

[nmstec]

They didn't really do checksums back then. Closest implementation of it was a "Inverted" or XOR of the data received. I don't believe Landrover was ever sophisticated enough for it until BMW ate them. I do have the information for the BMW generation of K & L protocol, but nothing for this gen.

 

[robertf]

Still picking away at this.

One of the issues I ran into with the GEMS reader app is what platform to run it on. My paying gig deals with industrial automation. I have little need for GUI development skills and that app showed it. The pc and mac app were dependent on 3rd party stuff to get the GUI working, then there were DLL problems on the windows side when accessing serial ports. The android revision solved most of those issues, but who uses android? It was painful to dig out the 5 year old tablet and charge it up whenever I needed to do some ECU work.

I don't keep up with all the changes in web development and cloud stuff, but I recently discovered the web serial api along with the slightly older bluetooth api. HTML GUI stuff is easy so I've setup a domain and server and ported about half of the GEMS app to it as proof of concept and its very promising. Just about anything that can run chrome, edge, or brave that isn't iOS should work with what I have planned. You can see what others have done with these apis at www.serialterminal.com .

Once I get the ABS and airbag stuff a little more polished I'll share the domain and what hardware is needed to get the browser to talk to it.

 

[salvvia]

0x40 0x80 LIVE DATA REQUEST BRAKE PEDAL PRESSED

0x8F 0x40 0x10 0xC1 0x86 0x7C 0x00 0x7C 0x00 0x7C 0x0 0x7C 0x00 0xFF 0x0F 0x00

0x40 0x80 LIVE DATA REQUEST BRAKE PEDAL NEUTRAL

0x8F 0x40 0x11 0xC4 0x8c 0x7C 0x00 0x7C 0x00 0x7C 0x0 0x7C 0x00 0xFF 0x0F 0x00



0x82 0x24 0x03 0x80 TOGGLE ABS LAMP TEST

0x04 RESPONSE

0x82 0x24 0x0C 0x80 TOGGLE ABS LAMP

0x04 RESPONSE

0x82 0x24 0x03 0x80 TOGGLE ABS LAMP

0x04 RESPONSE

0x82 0x24 0x00 0x80 TOGGLE ABS LAMP

0x04 RESPONSE

0x82 0x24 0x03 0x80 TOGGLE ABS LAMP

0x04 RESPONSE

0x82 0x24 0xFF 0x80 EXIT TOGGLE ABS LAMP TEST

0x04 RESPONSE


0x11 0x80 READ CODES (This one had lots of stored codes)

0x8D 0x11 0x04 0x41 0xFF 0x00 0x00 0x40 0x00 0x40 0x00 0x40 0x00 0x00

So in the live data and code reading the lower nibble of the first byte appears to be length. ABS toggle doesn't fit the mold, but I'll keep digging. No apparent cheksum, and request frame doesn't look like it has length. 4 and 8 look like addresses.

Dont forget about the xxx thro down.
You truckers are way over my head, I hope you get that shit figured out because, it sounds like the 1s and zeros are going nuts.

P.S. i hope the grammar police is satisfied...

 

[discostew]

Still picking away at this.

One of the issues I ran into with the GEMS reader app is what platform to run it on. My paying gig deals with industrial automation. I have little need for GUI development skills and that app showed it. The pc and mac app were dependent on 3rd party stuff to get the GUI working, then there were DLL problems on the windows side when accessing serial ports. The android revision solved most of those issues, but who uses android? It was painful to dig out the 5 year old tablet and charge it up whenever I needed to do some ECU work.

I don't keep up with all the changes in web development and cloud stuff, but I recently discovered the web serial api along with the slightly older bluetooth api. HTML GUI stuff is easy so I've setup a domain and server and ported about half of the GEMS app to it as proof of concept and its very promising. Just about anything that can run chrome, edge, or brave that isn't iOS should work with what I have planned. You can see what others have done with these apis at www.serialterminal.com .

Once I get the ABS and airbag stuff a little more polished I'll share the domain and what hardware is needed to get the browser to talk to it.

Hey Robert, is there anything you could figure out by looking at how this thing works? It’s an Android tablet from JLR.

 

[robertf]

probably. at a minimum it's probably gotva few more features that I haven't been able to copy yet

 

[jymmiejamz]

Hey Robert, is there anything you could figure out by looking at how this thing works? It’s an Android tablet from JLR.

That thing is useless

 

[discostew]

That thing is useless

it’s hard to use because the menus choices don’t make any sense. I admit it’s not great and definitely not worth what they charge. But I’ve actually fixed a few cars with it.

 

[discostew]

They didn't really do checksums back then. Closest implementation of it was a "Inverted" or XOR of the data received. I don't believe Landrover was ever sophisticated enough for it until BMW ate them. I do have the information for the BMW generation of K & L protocol, but nothing for this gen.

Hey in true Discoweb form please allow me to highjack your thread Robert, I’m working on a network problem on a 2010 Impala. What they call a low speed data bus. Looks like GM Class 2 serial data to me.
So I started out looking at a no crank deal. I find that Class 2 bus down (held low). I chase that down to be the climate control head. I take that out of the circuit and the whole network looks good on my scope. But I still can’t communicate with an Autel scanner on that network. But everything on the high speed twisted pair ( looks like CAN Bus ) I can access.
So here is my question. The BCM is the gateway module between those 2 networks. Is it a fragile circuit that could have been damaged by my shorted climate control head? Because it seems to me the data from the class2 side is active at the BCM( per my scope) but nothing is crossing over to the twisted pair high speed data bus.
Long winded I know. Any thoughts? Ideas?