1997 F-Body ECM

[kur4o]

I can say an avt-852 cable[expensive] will work for sure. Some extra bytes need to be sent.
obdXpro[moderatelly priced]
https://obdxpro.com/
should also work. It also supports elm shit.

obdlink cable might not work due to limited upload buffer.

I am sure your home brew cable will yield great interest too, and there will be some guys testing for sure.

[NomakeWan]

obdXpro[moderatelly priced]
https://obdxpro.com/
should also work. It also supports elm shit.

And as a reminder, I have one of these cables and would be willing to loan it out to anyone doing development on the 96-97 LT1/LT4 PCMs. I do not have access to a '96 Corvette at present so I cannot help directly, but I can at least help that way. :)

[Tom H]

I can't find any reference to modes $35 or $37 anywhere other than the SAE J2190. That only give me the generic details of the mode. If we can't find the detail of these modes, I plan to use:

MM $35 MODE
LH LENGTH HIGH: $00
LL LENGTH LOW (LENGTH NOT TO EXCEED 64 --> $40)
AH ADDRESS HIGH: $00 AND $01 VALID ($01 YIELDS BANK 1 RESULT)
AM ADDRESS MIDDLE 8BITS
AL ADDRESS LOW 8BITS
CRC CYCLIC REDUNDANCY CHECK

SAE J2190: MODE $37 REQUEST
H0 H1 H2 D0 CRC
4C 18 F0 $37 CRC

H0 NO IFR
3 BYTE HEADER
PHYSICAL ADDRESSING
NODE-TO-NODE
H1 $18 LOAD SERVICE PORT
H2 $F0 TESTER
MM $35 MODE
CRC CYCLIC REDUNDANCY CHECK

-Tom

[Tom H]

Cut/paste error...

SAE J2190: MODE $35 REQUEST
H0 H1 H2 MM D1 D2 D3 D4 D5 CRC
4C 18 F0 $35 LH LL AH AM AL CRC

H0 NO IFR
3 BYTE HEADER
PHYSICAL ADDRESSING
NODE-TO-NODE
H1 $18 LOAD SERVICE PORT
H2 $F0 TESTER
MM $35 MODE
LH LENGTH HIGH: $00
LL LENGTH LOW (LENGTH NOT TO EXCEED 64 --> $40)
AH ADDRESS HIGH: $00 AND $01 VALID ($01 YEILDS BANK 1 RESULT)
AM ADDRESS MIDDLE 8BITS
AL ADDRESS LOW 8BITS
CRC CYCLIC REDUNDANCY CHECK

SAE J2190: MODE $37 REQUEST
H0 H1 H2 D0 CRC
4C 18 F0 $37 CRC

H0 NO IFR
3 BYTE HEADER
PHYSICAL ADDRESSING
NODE-TO-NODE
H1 $18 LOAD SERVICE PORT
H2 $F0 TESTER
MM $35 MODE
CRC CYCLIC REDUNDANCY CHECK

[kur4o]

I think mode 35 was used for reading bin from early vpw PCMs. It was removed later but upto blackboxes it was built in the code. Not sure if it is present in ee but might be there.


Here is some typical usage of mode 35

[27:968] - Written data

6c 10 f0 [35] [00] [08 00] [00 10 00] .l.ð5......
35 mode
00 submode
0800 size of dump
00 10 00 address of dump
[01:09:796] - Read data

response1
6c f0 10 75 00 54
response2
6d f0 .10 36 00 08 00 00 10 00
c9 9c 00 01 c9 a0 00 01 .6......Éœ..É*..
c9 b8 00 01 c9 bc 00 01 c9 c0 00 01 c9 c4 00 01 ɸ..ɼ..ÉÀ..ÉÄ..
c9 c8 00 01 ca 0c 00 01 ca 10 00 01 ca 14 00 01 ÉÈ..Ê...Ê...Ê...
ca 18 00 01 ca 1c 00 01 cf 8e 00 01 cf 92 00 01 Ê...Ê...ÏŽ..Ï’..
cf 96 00 01 cf 9a 00 01 cf 9e 00 01 cf b6 00 01 ϖ..Ϛ..Ϟ..϶..
cf ba 00 01 cf be 00 01 cf c2 00 01 cf c6 00 01 Ϻ..Ͼ..ÏÂ..ÏÆ..
d0 0a 00 01 d0 0e 00 01 d0 12 00 01 d0 16 00 01 Ð...Ð...Ð...Ð...
d0 1a 00 01 eb 4c 00 01 eb 50 00 01 eb 54 00 01 Ð...ëL..ëP..ëT..
eb 58 00 01 eb 5c 00 01 ec 18 00 01 ec 1c 00 01 ëX..ë\..ì...ì...
ec 20 00 01 ec 24 00 01 ec 28 00 01 ec 3e 00 01 ì ..ì$..ì(..ì>..
ec 42 00 01 ec 46 00 01 ec 4a 00 01 ec 4e 00 00 ìB..ìF..ìJ..ìN..
3e c6 00 00 3e d6 00 00 3e fc 00 00 3f 22 00
.............................
41 f9 00 03 b1 54 30 38 a9 1c 32 2e ff fc 60 0e Aù..±T08©.2.ÿü`.
41 f9 00 03 b0 14 30 38 a9 1c 32 38 a9 34 74 14 Aù..°.08©.28©4t.
4e b9 00 03 50 4c 02 40 [74 fb]

[74 fb] block checksum

[01:10:000] - Written data

06 6c 10 f0 76 00 54 .l.ðv.T

Small pause

6c 10 f0 [35] [00] [08 00] [00 18 00] .l.ð5......

And so on

This is with built in reading from 97 blackbox pcm.

[Tom H]

Thank you kur40

Brings more questions though: The '97 has no mode 35, that's why I am doing it first. What is a blackbox pcm? Do you describe the '97 as ee? I have never understood the way ecms are described/broadcast codes and so on. This would make a great post for me if the situation could be explained.

-Tom

[kur4o]

ee=lt1
blackbox= 96-99 vortec trucks pcm. It have the same casing and similar connectors as lt1 pcm, but uses more powerfull processor motorola 68332.96-97 have 2 128kb intel memory chips. 98-99 have a single larger 512kb memory.

Look for some left over subroutine that can response as mode 35. The example is the standart communication but you can upload some code and dump the bin in many other ways. Or read it byte by byte if there is mode 23.

[Tom H]

I have worked through a number of issues and finally have my Srecord download in working reliably. If it's going to be of use to others, you will need to build my interface (cable) or use a commercially available cable. The one that folks seem to have is the OBDX Pro VT. If you have one of these, answers to a few questions would be a help to me.

- The OBDX Pro VT Command Set Reference Guide has no info about serial port setup. It would be a help to know the baud rate, parity, stop bit requirements.

- I would like to transmit, receive and check my own CRC. This is what my homebrew interface supports. Is this cable capable?

- Can I suppress the cable's generation of header and just send the hex.


-Tom

[In-Tech]

Hi Tom,
I have an ObdX pro if it will help with your development. I also have a GM MDI and an AVT852 and old school AVT 838 serial amongst many other things. I don't remember reading of your interface, I apologize. If you can point, I will build one.
I don't have the answer about cable generation of header but the same concept has bothered me for quite some time.
Let me know what I can do to help :)
-Carl

[Tom H]

Hi Tom,
I have an ObdX pro if it will help with your development. I also have a GM MDI and an AVT852 and old school AVT 838 serial amongst many other things. I don't remember reading of your interface, I apologize. If you can point, I will build one.
I don't have the answer about cable generation of header but the same concept has bothered me for quite some time.
Let me know what I can do to help :)
-Carl

Hi Carl,
I have not written the interface up yet. At the moment it seems to detect break at random times when there is no break. Works 95% but as always fixing the last bit takes some time. I hope to have it to you soon. Regarding the cable, I might take you up on it just so I can test. The interface is a little different. On mine, what the PC sends is what goes out on the link. My PC generates the header in bytes THIS is different from the ELM327 which forces the user to configure a header and sends it before each frame. I also check CRC in PC software to ensure correct reception. These are the main differences control of header, CRC generation/checking and communications. Doesn't seem like too much, so I figure a conditional compile. It would get complicated if there are several more interfaces.

It would be an assist if you plugged the cable into your PC, set up a terminal and confirmed the rate is same as ELM (that is 38,400 8N1). All you need to do is send it "ATZ" and the reply should let us know if you are connected.

IF that works and you feel like trying just a bit more, it would be interesting to hook it to an LT1 and send the following:
ATSH 4C 10 F0
ATH1
28 00

And see if it replies 4C F0 10 68 00 5E Or if the cable swallows the 5E

The interface should be posted soon. It uses the Arduino Nano (which I now seem to use for everything) three transistors a handful of resistors and an 8.2V Zener diode. Just need to get the bugs out.

-Tom

[kur4o]

I think obdx cable is a true hex with emulated elm compatability. WHich means you can configure it to send a message the way you want it.

Maybe some 2-3 bytes header to specify message length and some instruction byte???

Also as far as I know all cables handle the crc byte on hardware level. Maybe there is some settings that can show the crc onincoming on sure on outgoing messages.

I guess your cable is transparent and arduino is just a gateway for communication.

The elm comm speed can be easily reconfigured on boot up. Most are set to 38000 or 115000 as a default. You can make it user configurable or crawiling an ATZ message on different bauds till you get a response.

[sherlock9c1]

Hi Tom, I'm just getting this hooked up. I sent ATZ and got back A41 T54 Z5A. Then I got ?3F 0D 0A >3E. I was playing around with some of the other commands and the >3E seems to appear at regular intervals. I have a whole lot of other questions about realterm and will email you.

[In-Tech]

Hi Tom,
I am glad sherlock is helping you, I have been jammed up on the chassis dyno and have two more marine race engines we are trying to finish on the engine dyno this weekend. I'll check in when I get some time freed up :)

[JimCT_9C1]

Been following along - I have both the OBDX Pro VT and OBDLink SX cables for logging my 1996 Caprice 9C1 LT1, so did some testing.


Ran the tests Tom H was looking for:
- Tested both OBDX Pro and OBDLink SX
- Port settings of 38400 8N1 no flow control in system control panel (Windows10)
- With ATH1 showed the full response - the reply had both the header and CRC/checksum bytes

- 4C F0 10 68 00 5E

- Same results from both cables


The different cables liked different terminal settings so as pointed out above by kur4o there may be some testing to find to find the right combination for a particular or unknown cable. Some connectivity test results with cable default settings:

Cable	Port	Terminal	Connect
OBDX Pro VT	38400	38400	Yes
OBDX Pro VT	38400	115200	Yes
OBDX Pro VT	115200	38400	Yes
OBDX Pro VT	115200	115200	Yes
OBDLink SX	38400	38400	No
OBDLink SX	38400	115200	Yes
OBDLink SX	115200	38400	No
OBDLink SX	115200	115200	Yes

Tested cases for earlier questions on the OBDX Pro - with this cable it seems there are two ways to send your own combined header/data message using either the extended DXSD command or the Direct Vehicle Interface protocol. I tested DXSD and it works for sending header/data as a single message; I haven't done anything with DVI. The OBDLink SX has a similar extended STPX command that supports combined header/data messages - tested that one successfully as well.

Both cables calculate the outgoing (to vehicle) message CRC/checksum in the cable itself, and can pass back to the PC the CRC/checksum on incoming (from vehicle) messages. I didn't see a command to turn off the CRC generation for outgoing messages for the OBDX Pro, but maybe it's there. The OBDLink provides an extended command to disable the CRC generation, but I haven't tested it yet.

Hope this helps answer some questions - and that others with additional insights and experience weigh in.

Jim

[sherlock9c1]

Hey Jim, thanks for chiming in. Tom H and I have been going back and forth testing comms with my OBDXPro VT.

I'm using the RealTerm open-source terminal program set for the same settings you mentioned.

After some pre-settings,

ATH1
ATAL
ATSP2
ATS1
ATSH 48 6A F0
01 00

We were able to use DS XD and then the message to communicate directly with the ECM.

Example: request freeze frame data:

DX SD 4C 10 F0 12 00 FF FF

Based on testing this morning, if you omit DX SD, you get a different answer. It's been awhile since I've read machine hex so it's all greek to me at the moment; Tom emails me commands and I email the response back. I wonder if DVI mode will obviate the need for the DX SD prefix, but it's trivial to add.

I've tested out the instruction sets available for the user guide; as an aside, being able to query the battery voltage is a nice feature. Manual available here: https://obdxpro.com/downloads/