Technical OBD - STN1110 & ELM327 question?

Currently reading:
Technical OBD - STN1110 & ELM327 question?

mprowe

New member
Joined
Jun 1, 2015
Messages
32
Points
17
Hi,

I have the MultiECUscanner (from Gendan & using a STN1110 chip). Using the supplied software, it seems to be working. However....

I would like to "get under the hood", so I have been reading the ELM327 datasheet. Page 32 gives advice on talking to a vehicle using a terminal program (putty). This is a log of my session:

[FONT=Courier New, Courier, monospace]>ati
ELM327 v1.3a
>atz
ELM327 v1.3a
>at sp0
OK
>01 00
SEARCHING...
UNABLE TO CONNECT
>

[/FONT][FONT=Courier New, Courier, monospace]Any suggestions on why I'm only getting "Unable to Connect"?

Regards, Martin
[/FONT]
 
Ignition on? Whats you baud rate set to?

Even if you do get a response the data returned has to be mathematically manipulated to make the units make sense e.g.

21 31 Accelerator position is 2 bytes you have to multiply by 0.01 %
21 32 Main injection start is 2 bytes you have to multiply by 0.0234 Deg";
 
Q. Ignition on? A. Yes.

Q. Whats you baud rate set to? A. 115200. Confirmed by log (capture of real-time conversation between Putty & STN1110).

Even if you do get a response the data returned has to be mathematically manipulated to make the units make sense e.g.

Yes. But I can worry about that when I get a response.
I'm after body computer door info - single bit - easy - I hope!

Regards, Martin
 
Set baud rate to 9600 if that doesn't work try 38400
 
Set baud rate to 9600 if that doesn't work try 38400
Thank you Corcai,

Can you be a bit more specific? Change which baud rate?
As I said, I have a Scantool.net OBDLink SX retailed by Gendan. I understand that the data path is something like this:
PC <==> [ FTDI USB to Serial translator <==> STN1110 Serial to ISO translator ] <==> Vehicle.
Components between [ ] are in the OBDLink.

So, although I can (I think!) change the STN1110 baud rate to 38k4 baud (using >STBR 38400?), if I do, I will lose contact because the PC to FTDI link is still stuck at 115k2 baud (at least without the FTDI tools needed to change that that bit of the link path).

Lastly, although I can't (quickly) find the references, I understood that one of the STN1110's USP, is that it is auto speed sensing (on both the UART & ISO) interfaces?

Regards, Martin
 
Brainfart, was thinking of the FTDI baud rate but looking at your paste I can see you're getting a response so the baud rate is fine.

Syntax for auto protocol search is

AT SP 0

i.e. with a space as opposed to at sp0

Then check to make sure the auto protocol has stuck with
AT DP

Then the mode/pid without a space e.g.
0100

Its helpful for clarity and logging to add echo and linefeeds too:

AT E1
AT L1
 
...I can see you're getting a response so the baud rate is fine.

Been busy trying to understand what is going on. So I thought it was time to update with current state. Firstly, I have hacked my Vehicle Interface (VI) so that I can see the traffic to/from the PC and the ELM327 (ST1110). I don't have a USB Sniffer, so I am picking up the RS232 connection in the VI.
obd-capture.png
I then merged the two capture files so that I can see the commands from the PC and the response from the ELM327. One such (simple) conversation looks like this:
spreadsheet.png

From this it seemed to me, only a mater of replicating the conversation from a dumb terminal on the PC, to get the same results. ie Send the AT sequence followed by the Mode+PID, and get an answer? Unfortunately this has proved not to be the case. I just get "No Data".

On the positive side, I am hoping that "No Data" is not a problem with communications, it just that I am asking the question at the wrong time or in the wrong context? But for the life of me, I can't see what I am doing wrong.

Any thoughts will be most welcome.

Regards, Martin
 
Are you pasting in all the commands at once, you may need to allow a delay especially for reset. Also add commands to check the setting after you have set it as the OK response is uniformative.

Where did you get 04021a971 from doesn't look like the right number of bytes?

I can help you with the start of decoding the response
F1 02 50 81 00 00 00 00

F1 - is the address of the adapter so thi smessage is addressd to the STN - "external test equipment" in the ISO spec"
02 - means a single frame response
50 81 is something like diagnostic session started so I don't think 04021a971 is correct.
 
Are you pasting in all the commands at once?

No. The sequence you see in my last over, is taken from a "live" run using a commercial scanning software package. Any handshaking or timings are controlled by that software.

My problems arrive when I try and mimic that same conversation using a dumb terminal (MiniCom) on the PC. In that situation there is (by Comms standards) a very long delay between AT command because I am typing them in one-by-one, by hand. This, I thought may be the problem? Maybe the Vehicle (CAN) interfaces were timing out before I could issue the next command?

Also add commands to check the setting after you have set it as the OK response is uniformative.
This puzzles me? Is this folklore? Or hearsay? The ELM327 datasheet says that if a command is understood, the response is an "OK". And if a command is not understood, the response is a "?"
Where did you get 04021a971 from doesn't look like the right number of bytes?
Okay, I may have been too ready to blame my setup! The "to Car" capture in fact does not have the leading zero. I must have added it to match the length of subsequent strings because I suspected that a byte may have been dropped.

Once again, thank you very much for your input, Corcai
 
Hi Corcai,

I have been doing some more work on this problem over the last week or two. So, I thought I'd bring you up-to-speed and to ask your advice.

As you correctly advised, one of my problems was that entering commands by hand, the ELM327 would time-out and return to some basic starting point. My next command would then not make any sense in the new context. So I have automated my conversation with a Kermit script (a very old terminal program). This script is attached.

I wonder if you would have a look at lines 102 to 122 and offer any pointers to what it is I am doing?

It seems that I need to go through some "process". I can't just ask for the values from "040221301". See lines 134 to 143.

Many more question in hand. But I'll keep it (fairly) short this over!

Best regards, Martin
 

Attachments

  • obd.txt
    3.5 KB · Views: 67
Back
Top