OBDX Development - Developer Tools and Suggestions

Programs / Tools / Scripts
Cincinnatus
Posts: 305
Joined: Fri Jul 30, 2021 5:49 pm
cars: 97 Corvette
92 Camaro
2005 Silverado
2001 Savana 2500
1998 c3500hd
1998 tahoe

Re: OBDX Development - Developer Tools and Suggestions

Post by Cincinnatus »

Don't some elm devices have a physical switch for ms-can?
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

Cincinnatus wrote:Don't some elm devices have a physical switch for ms-can?
They sure do!

Our case doesnt have a spare opening to add a switch in on. When we redesign the case, itll be made large enough to have that extra relay anyways. But for those wanting to use the GT on a Ford MS CAN line, itll require adding a harness or switch mechanism.


Now, I went to do an update on a VE Series1 SSV radio today, which did an update on the graphics section (Large and slow). The GT failed a few times surprisingly.

So... I had a look at what was going on.. and I kept receicing this flow control message:
644 30 00 00 1E

What makes this unique is that the flow control bytes do actually have meaning as seen by the breakdown below:
ISO_FlowControl.PNG
ISO_FlowControl.PNG (41.01 KiB) Viewed 1993 times
Looking at the breakdown, 1E actually means wait 30ms between frames sent (Thats a BIG gap!).
Now, the default the GT is setup for is 1.5ms (1500micros) which has been fine for everything that I have dealt with so far. But clearly thats 20times faster then what it wants.

This resulted in the radio missing messages because its too slow. Its a very simple fix, but I have not personally come across this before even when using remote programmers that I use regularly, although the GT is significantly faster then anything else I have used so its able to shoot off messages alot faster then other tools I have dealt with.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

Well I think I solved the Kline development, older Holden Barinas use Kline. I have access to one of those so can actually develop with that!
It does not use the L-line.. but.. thats fine, it appears theres a very small percentage of vehicles that use L, so best focus on the majority protocol.

Time to drag the laptop to it and log some data!

*Edit
Yep thats confirmed.. just pulled a log from DPDU and thats Kline.
It also supports J2534 updates so I can log the update process to check what J2534 commands are used.

Just bought a unit that I can work with on the bench, and can then move to in car after its working.

On an interesting note, I see that pins 8 and also 13 are used on the DLC which indicate serial comms to airbags and door locks. The workshop manual indicates that UART and Keyword2000 (Kline) are used on this vehicle, so I wonder if that correlates to ALDL?
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by antus »

Yep, ALDL is often referred to as serial or uart, since thats what the bit format is, the only difference is voltage and duplex.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

Learning about ISO 9141 is ISO 14230 (keyword2000)... now our main difference:
1) ISO 9141 is suppose to only be up to 12bytes of data per command, ISO 14230 is up to 255 bytes
2) BOTH can use K and L line. I was under the impression that the L line was only on ISO 9141.. but.. its actually used in both
3) ISO 14230 can use slow of fast init.

Documents ISO 14230-1 and ISO 14230-2 explain indicate K and L line used. Even though L is optional, it may be used by some modules thus its kinda vital to have. The L line is a literal exact copy of K line data sent, but is only used in the initialization process... its never used for actually reading data back.

Format is:
FMT, Tgt, Src, Len, Sid+ Data bytes, CS

FMT = Format byte - this indicates the lengh of the message and header message form. (bit 6,7=0 is no address info, bit 6=1 is Exception Mode (CARB - 0x68 or 0x48), bit 7=1 is Physical addressing, bit 6 and 7 = 1 is Functional Addressing.
Then bits 0 to 5 are the length of the data, if all 0 then it uses the optional Len byte.

Tgt = Target address byte (Optional) - not used if FMT byte has bit 6/7 = 0.
Src = Source Address byte (Optional) - not used if FMT byte has bit 6/7 = 0.
Len = only present if bits 0 to 5 in FMT = 0. Allows messages greater then 64.

So technically we can have the following header byte configurations:
1) FMT only
2) FMT, Len
3) FMT, Tgt,Src
4) FMT, Tgt,Src, Len

Next is our Service Identification (Sid) Byte. this is our "mode" byte and its values are defined in ISO 14230-3, and it matches the common setup we are use to with CANbus ect.

Following this is our data bytes, this will vary depending on the mode ect.

And finally our checksum, this is a simple 8bit sum of all the bytes in the message, so FMT through to the last data byte.

Its worth noting the length byte includes the Sid and databytes but does not include the checksum.

Next up is understanding the initialization process (keybytes).
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

antus wrote:Yep, ALDL is often referred to as serial or uart, since thats what the bit format is, the only difference is voltage and duplex.
Yeah, just on some weird pins. But again, could be a DIY harness for those wanting to communicate to those modules. Should be able to extract the required pins by using tech2win and seeing what dpdu does.

It’s not idea, but it’s cheap connectors to build a little harness. Could even add a simple switch to flick between different pins on a DIY harness!
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by antus »

different pins are used in commodores too, eg for srs with bcm bridging the busses on request otherwise it keeps the second bus isolated. just like you can have more then 1 can pin(s), and other gateway devices on newer vehicles can.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

antus wrote:different pins are used in commodores too, eg for srs with bcm bridging the busses on request otherwise it keeps the second bus isolated. just like you can have more then 1 can pin(s), and other gateway devices on newer vehicles can.
That would make sense. I think its the VR/VS vehicles where a tool I was monitoring was sending data still down pin 9 for ALDL.. yet airbags was on a different pin, but nothing was actually connected to that pin inside the scantool!

But for these other buses in the Barina, they do not connect up anywhere else. I brought up their communication network diagrams and they are absolutely isolated. Ill connect up tech2win anyways and see what it does for pin selection. Maybe Im wrong and it somehow addresses to the other modules through something else... somehow :lol:
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

So we have two sets of possible frames we can receive:
1) ISO 9141 style which is used when the CARB option is used (48 and 68 first byte) and requires a 'timeout' style formatting to find end of frame.
2) ISO 14230 which has length byte which allows easier processing.

Option 2 is how the barina is setup, an example frame from tech2win is:
81 11 F1 81 04

Where we can see our FMT is 0x81, which is bit 7 = 1 (Physical addressing) with a length of 1 byte.
As we have physical addressing, this means we will have a target(11) and source(F1) bytes.

81 is then our service identifier byte.. in this case it stands for Escape Code. I don't quite understand this yet, documentation says that this means "manufacturer Specific Service Identifier", so this will be a GM specific mode. And finally 04 which is our checksum (81+11+F1+81 = 04)

The response from this is:
83 F1 11 C1 6B 8F 40
So 83 = 3 data bytes
F1 = Target address
11 = Source
C1 = 0x81+40 = response to Sid
6B 8F = data bytes
40 = checksum

In this case, we have no idea what the 6B 8F data bytes means. It might be coincidental.. but 6B in ASCII is the letter K.. maybe this signifies only K line is used?
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
kur4o
Posts: 948
Joined: Sun Apr 10, 2016 9:20 pm

Re: OBDX Development - Developer Tools and Suggestions

Post by kur4o »

Code: Select all


--> 05 00 81 11 F1 81  -Init message
--> 07 00 83 F1 11 C1 EF 8F _response
--> 06 00 80 11 F1 01 3E -idle keep alive message
--> 05 00 81 F1 11 7E -response
--> 07 00 80 11 F1 02 1A 81 mode 1a submode 81 pcm info request
--> 11 26 00 A2 F1 11 5A 81 04 90 6F 62 03 98 6A 03 99 44 03 92 44 03 91 6B 03 94 64 03 95 02 03 96 66 03 97 66 03 9A 02 FF 
What you see with 81 11 F1 81 message is the bus init message, sent from the tool. Exact meaning is unknown. It varies from ecm and manufacturer. It needs to be software configurable.

Than to keep bus open an idle message should be sent each 2 seconds, if there is no other activity.

ACtuall bus init is to set bus high and low in specific sequence and for specific time. I think at 5 baud fast init, you send some specific byte that handles the timing exactly. Immediately after that the init message is sent, if successful the pcm will response. If no response is got, retry the 5baud sequence.
Post Reply