1997 F-Body ECM

[sherlock9c1]

JimCT_9C1, I can only get to the car once or twice a day to test things; so if you can access it faster, fantastic.

Tom says the next steps are:

1. Establish how to get rid of needing DX SD every command. Or test out what's written in section 2.35 of the manual so that we only need to send the command? Alternatively, switch to DVI mode and follow the formats and examples listed in section 3.2.
2. Perhaps use DVI to eliminate the ">" which would make the API a lot simpler.

Tom asked to run several requests and then capture the output so he can see what's returned between commands, which will make parsing easier. Example commands:

• 4C 10 F0 12 00 FF FF (Request Diagnostic Freeze Frame Data)
• 4C 10 F0 17 01 00 (Request Status of Diagnostic Trouble Codes)
• 4C 10 F0 20 (Return to Normal Operation)

[kur4o]

I say switch to dvi protocol. This DX SD is some kind of extended elm commands set implemented.
I think dvi is much closer to avt type of protocol in pure hex. No need to convert anything in ascii.

[kur4o]

3.11.7.
Set/Get Validate CRC on Network Frames
This ON by default
, thus
CRC’s are validated on read.
Request to set: 
33 02 0
7
XX 
YY
Where XX is:  00= CRC OFF, 01 = CRC ON 
YY is normal checksum
Response: 
43 02 0
7
XX YY
Request to Get: 
33 01 0
7
YY
YY is normal checksum
Response: 
43 02 0
7
XX YY
3.11.8.
Set/Get Display CRC in Received Frame
This is 
OFF by default
, thus d
oes not display CRC 
in received frames to PC
.
Request to set: 
33 02 0
8
XX YY
Where XX is:  00= CRC OFF, 01 = Display CRC in returned frame
YY is normal checksum
Response: 
43 02 0
8
XX YY
Request to Get: 
33 01 0
8
YY
YY is normal checksum
Response: 
43 02 0
8
XX YY

How to set crc in dvi mode

o enable using the DVI protocol, you must first send the ELM string command DX DP 1 which will
change from ELM to DVI protocol

[kur4o]

To send in dvi mode use

10 [xx] message [yy]

xx= length of message
yy= is some sort of frame checksum used by the tool.[it is not the crc byte]

edit:
YY = Checksum (Sum of bytes and inversed)

ff-(a+b+c+D+...)

[JimCT_9C1]

Sherlock - glad you're up and running with the OBDX Pro and making progress. I have Realterm as well so that's a common foundation to work from.

Glad to help with testing, but unfortunately I will be away from the car for the next few days so won't be able to do more in-car testing this week.
In the meantime, I will start looking into the DVI protocol.

Jim

[sherlock9c1]

Some experimentation:
After the required:
ATSP2 and
AT SH 4C 10 F0 <-- this allows you to skip writing "DX SD 4C 10 F0" where 'DX SD' is the ELM command to send data, and '4C 10 F0' is the header.

Then you can simply send a command and get the response in ELM mode.

Switching to DVI was successful using the command: DX DP 1, which returns "OK"

Then in Realterm you need to make some changes:
Display Tab:
- Select 'Display as' Hex[space].
- Activate 'Half Duplex'

Send Tab:
- All numbers must have the 0x prefix. This may be obvious to you but it stumped me for a bit.
- \n after should be activated

After that I confirmed that you don't need to send the header, just the message, as kur4o indicated.

Here's where I got stuck: Say I want to send a $27 command; following the format listed in the manual and by kur4o, I send:
27 01 01 D6, then I receive an error code: 7F 02 27 01 56
Which seems to indicate received $27 was an error $01 invalid command.

Same with 29 00 D6; I got 7F 02 29 01 54

I tried several different commands and got nothing but 7F error code messages, all 01 invalid.

[Tom H]

Sherlock - glad you're up and running with the OBDX Pro and making progress. I have Realterm as well so that's a common foundation to work from.

Glad to help with testing, but unfortunately I will be away from the car for the next few days so won't be able to do more in-car testing this week.
In the meantime, I will start looking into the DVI protocol.

Jim

Thank you Jim. Testing should start soon. -Tom

[Tom H]

Some experimentation:

...

Here's where I got stuck: Say I want to send a $27 command; following the format listed in the manual and by kur4o, I send:
27 01 01 D6, then I receive an error code: 7F 02 27 01 56
Which seems to indicate received $27 was an error $01 invalid command.

Same with 29 00 D6; I got 7F 02 29 01 54

I tried several different commands and got nothing but 7F error code messages, all 01 invalid.

Your command to get the security seed assumes that the header is pre-pended with the commands above. The mode $27 and submode $01 are all that is needed. The "7F" general error is because there are the wrong number of parameters sent. in my case the transcript runs as follows:

Frame: 4C 10 F0 27 01 71
Frame: 4C F0 10 67 01 58 3D 27


The request header 4C 10 F0, mode/submode 27 01 CRC 71

I believe your mode $29 has a similar problem, the command is only the mode. Try sending header, $29, crc. That should work.

-Tom

[JimCT_9C1]

Thank you Sherlock and Tom -

My understanding of DVI is that it is separate and independent of the ELM protocol. Therefore the ATSH has no effect and the header must be included in the DVI message data block (See Section 3.5 and Tom's post above). The DVI command to send a message to the vehicle is $10. There are no $27 or $29 DVI commands, hence the invalid command error. Sherlock, if you get a chance give the $10 command a try with the full request in the data block. I will try some off-car tests myself - I suspect I will get different bus-type errors with no vehicle present.

Regarding the ELM ATSH command - yes it's nice to not have to type/send the header each time. However, since it's the only way to change the header in the basic ELM instruction set, it can be something of a burden if you are changing headers in a string of requests and need to issue a new ATSH each time. For such cases, using the DXSD command' with its embedded header can be beneficial.

Thanks too for sharing the Realterm setup info - that eases the learning curve. I believe I saw the later versions have a direct hex option on the Send tab so you don't need the 0x or $ prefix. I downloaded an updated version, but haven't installed to verify.

Hope the above is helpful,

Jim

[sherlock9c1]

Jim - I'm using RealTerm 2.0.0.70; the chatter on SourceForge looks like 3.0.0.27+ has an option to send as hex. EDIT - I found a 3.0.0.30 beta download site and will try it after work.

Tom - the DVI errors as listed in the OBDXPro VT user's manual are:

The configuration errors possible include:
const uint8_t Error_InvalidCommand = 1;
const uint8_t Error_RecvTooLong = 2;
const uint8_t Error_ByteWaitTimeout = 3;
const uint8_t Error_InvalidSerialChksum = 4;
const uint8_t Error_SubCommandIncorrectSize = 5;
const uint8_t Error_InvalidSubCommand = 6;
const uint8_t Error_SubCommandInvalidData = 7;

Ah, so that's why kur4o listed 10 as the first byte in the DVI messages! OK, I'll update them and try again tonight.

Joel

[sherlock9c1]

Doublecheck me. I think the correct DVI format for an example ELM message is:

ELM: DX SD 4C 10 F0 23 00 0E 00

DVI: 10 XX 4C 10 F0 23 00 0E 00 YY where XX is message length, and YY is checksum.

So the message length XX would be 07;

and YY = 0x194; inverse = FFF-194 = E6B, so YY = 6B.

Thus, DVI message is 10 07 4C 10 F0 23 00 0E 00 6B

Am I doing this right?

[JimCT_9C1]

Realterm updates are available under the "News" tab on the sourceforge page, along with a description of each release and a link to the developer's download page with all the installers. V3.0.0.33 is listed the next non-beta update after V2.0.0.70, so that is my planned next step with Realterm versions. V3.0.1.44 beta looks like it may be useful in the future with its capture feature enhancements. I have downloaded both versions, but haven't installed them.

I am currently using V2.0.0.70 as you are, and am planning to continue to get my feet wet with this version and the DVI protocol before updating.

Jim

[sherlock9c1]

I'm going to try to update RealTerm before my next post; I'd like to get to the point where Tom can just send me a txt file to pump into the interface and then send the capture file back to him, so we can test his read and write routines.

[kur4o]

You can also check AVT-hex terminal. I am not sure it will work with x-pro but you can give it a try. It have a source code available and can process some simple scripts.

[sherlock9c1]

Updated to RealTerm 3.0.1.44; much nicer to send in hex!

But, now I'm getting an error (from the cable) on the carriage return and line feed; nothing from the PCM yet in DVI protocol:
Sending: 10 07 4C 10 F0 23 00 0E 00 6B 0D (where 0D is carriage return)
I get: 7F 02 0D 01 70
10 07 4C 10 F0 23 00 0E 00 6B 0A (where 0A is line feed)
I get: 7F 02 0A 01 73

If I remove those endings, I'm not getting a response from the PCM in DVI protocol. Yes the ignition is on, engine off. Reading more of the manual, I think we have to use the 0x08 Receive from Network Normal command first to receive from the PCM? I'm not quite sure how to set that up.