Trying to monitor the data bus with an ELM327

[ironduke]

I'm not at the shop anymore, but yes.. When I was using plain mode I could type atrv and get back voltage, 0105 for coolant temp, 0902 for vin, etc and it spit back the correct response.. When I had hex selected I had to type in hex equivalent of of ascii, like 39 32 for 0902.. in plain mode you type on the bottom left of the screen, should see what your typing and then it sends everything when you hit return, that is when you should see send and receive led's flicker, not for every key as you type it. I can take some screen shots tomorrow and double check everything, only had a couple minutes at the end of the day and when I found the plain versus hex it operated just as you described in hex mode so honestly stopped trying to figure anything else out..

[DS106Q]

in plain mode you type on the bottom left of the screen, should see what your typing and then it sends everything when you hit return, that is when you should see send and receive led's flicker, not for every key as you type it.

Well this is interesting! I didn't notice any place in the bottom left for input. Normally terminal programs such as this are live (so to speak) and don't buffer data till a carriage return. Instead they send each character as one types it. Based on your description, I'm assuming there's an option that (which I didn't notice) to buffer the data and then send it when the program sees a $0D carriage return.

This could also explain why hex commands are working with my interface. I didn't see a way to send hex in real time with CoolTerm so I wrote the values to files and sent it to the COM port. That too would end up sending all the characters at once ending with the carriage return. Thus, it sounds to me like the key (no pun intended) is to not attempt sending individual keystrokes, but instead to send full strings ending in a carriage return.

I'll have to look into this tomorrow when I'm back in front of the laptop and ELM interface. I'm curious what your results would be if you turn this option (I'm assuming it's an option) off. Furthermore, any chance you have a J1850 VPW vehicle laying around you could test the ATMA command with? That's the real kicker because when I execute it, it appears to enter monitoring mode, but it's so quiet I don't even get crickets!

[ironduke]

in plain mode you type on the bottom left of the screen, should see what your typing and then it sends everything when you hit return, that is when you should see send and receive led's flicker, not for every key as you type it.

Well this is interesting! I didn't notice any place in the bottom left for input. Normally terminal programs such as this are live (so to speak) and don't buffer data till a carriage return. Instead they send each character as one types it. Based on your description, I'm assuming there's an option that (which I didn't notice) to buffer the data and then send it when the program sees a $0D carriage return.

This could also explain why hex commands are working with my interface. I didn't see a way to send hex in real time with CoolTerm so I wrote the values to files and sent it to the COM port. That too would end up sending all the characters at once ending with the carriage return. Thus, it sounds to me like the key (no pun intended) is to not attempt sending individual keystrokes, but instead to send full strings ending in a carriage return.

I'll have to look into this tomorrow when I'm back in front of the laptop and ELM interface. I'm curious what your results would be if you turn this option (I'm assuming it's an option) off. Furthermore, any chance you have a J1850 VPW vehicle laying around you could test the ATMA command with? That's the real kicker because when I execute it, it appears to enter monitoring mode, but it's so quiet I don't even get crickets!

For me, in terminal mode there was Raw mode or Line mode and they both ended up functioning the same..
Raw sends each key as you type it but nothing happens until you press enter and it sends the return.
Line mode doesn't send anything until you press enter.. The elm didn't seem to care, I got the same response each time.

Did not even know you could create a file and send a file, I assumed you just wanted to be able to configure the connection as needed and type atma and record/log

[DS106Q]

For me, in terminal mode there was Raw mode or Line mode and they both ended up functioning the same..
Raw sends each key as you type it but nothing happens until you press enter and it sends the return.
Line mode doesn't send anything until you press enter.. The elm didn't seem to care, I got the same response each time.

I see that under Options then "Terminal" it shows "Raw Mode" and "Line Mode." I didn't notice this previously, and I just tried it. Sure enough, in raw (what I called live/real time) mode I don't get any response from the unit other than to repeat the last command (as though it's only getting the carriage return). Additionally, none of the hardware LEDs flash till I press the enter key (where I get one simple quick flash).

If I switch it to "Line Mode" I get the text box in the lower left you described above. If I type an AT command in there and press enter, it sends the command and the ELM interface responds properly! This is great news because now I can control it. I'm just confused as to why raw mode doesn't work.

Regardless, I still don't get any data when using the ATMA command.

[ironduke]

For me, in terminal mode there was Raw mode or Line mode and they both ended up functioning the same..
Raw sends each key as you type it but nothing happens until you press enter and it sends the return.
Line mode doesn't send anything until you press enter.. The elm didn't seem to care, I got the same response each time.

I see that under Options then "Terminal" it shows "Raw Mode" and "Line Mode." I didn't notice this previously, and I just tried it. Sure enough, in raw (what I called live/real time) mode I don't get any response from the unit other than to repeat the last command (as though it's only getting the carriage return). Additionally, none of the hardware LEDs flash till I press the enter key (where I get one simple quick flash).

If I switch it to "Line Mode" I get the text box in the lower left you described above. If I type an AT command in there and press enter, it sends the command and the ELM interface responds properly! This is great news because now I can control it. I'm just confused as to why raw mode doesn't work.

Regardless, I still don't get any data when using the ATMA command.

Someone else might be able to help a lot more but I am guessing it's not automatically deciding on the correct protocol..
You are able to send at commands back and forth now with the elm, which is a start, now you want to see the ecm respond..

your trying to use vpw, correct?
What is the response of atdp?? I can only guess it's not showing j1850 vpw..
Try atsp2 and then try atma..

[DS106Q]

To clarify, everything has been working well with HEX values and now I can send ASCII characters either via the "Line Mode" or by putting them into a file and sending it to the COM port. I should have tried the ASCII characters with the file method previously, but just assumed they wouldn't work because when I was sending them in raw mode, I got nothing but a carriage return. As mentioned above, it turns out that if I use line mode I can send either HEX or ASCII and get correct responses.

Thus I'm able to set the protocol. It finds it fine in Auto mode (SP0) but I have been setting it with ATSP2 (like you mentioned). I can then query both physical and functional addresses and get valid responses.

However, if at any time I switch to raw mode, everything stops and I only get my last command over and over and over again till I switch back to line mode. Very weird!

So, to recap, as long as I leave CoolTerm in Line Mode it's fine. However, when I type ATMA it enters monitoring mode, but nothing (and I mean nothing) appears on the terminal screen until I press enter at which point it says "STOPPED" (as expected).

I'm assuming this is a shortcoming of the ELM as @antus said. The good news is that I ordered a VXDiag VCXNano and an hoping to use Universal Patcher logger to capture the data I'm looking for.

Of course, I'll need a scan tool to request the mode 6 data (to capture the syntax) connected at the same time. Hopefully, there won't be an issue with having both a J2534 passthru device and a scan tool connected to the J1850 VPW bus at the same time. I know scan tools usually use F1 as their address so hopefully it won't conflict with the VCXNano. If so, then it'll be back to the drawing board!

[kur4o]

Universal patcher is configured to work with elm devices too, you can give it a go and report if it works or not. I have tested it only with obdlink device, so a cheap china crap device might not work as expected.

[DS106Q]

Universal patcher is configured to work with elm devices too, you can give it a go and report if it works or not. I have tested it only with obdlink device, so a cheap china crap device might not work as expected.

Wow, that's awesome! I'll certainly give it a whirl and report back with the results.

BTW, this v2.1 is an el cheapo, but I also have an expensive American made serial port (meaning non-USB) one that's v1.5. The only reason I haven't been using it (other than I'll need to dig it up) is because the last laptop I had with a 9-pin serial port runs Windows XP and, these days, most Windows software packages don't support XP.

[DS106Q]

No luck with using the ELM interface with Universal Patcher. I direct it to the correct serial port and set the baud rate, but it just says "Connection failed. Check Settings"

[antus]

The problem with the ELM protocol is that depending on what firmware it is, it'll only monitor for a certain amount of time, or a certain amount of messages received. Most of them wont just go in to monitoring mode and send you what it sees on the bus and keep doing it. So you need to set protocol, timeouts, number of messages, sending tool present (or something else) and then listen until you get 1 or more responses, or NO DATA (or whatever it sends) then send another packet outbound to wake it up again, and you might miss some data between the elm stopping and starting again. So it's not a great tool for the job. That's one of the reasons we looked at the old allpro elm clone back in the day - because with open source code we could make it monitor full time (and did in a hacky way while got the reflash process working). But at the end of the day the manufacturer of the allpro who was selling it was aiming at hobbyists, not the amount of people wanting to flash their cars, and he stopped selling them, and later we found the hardware wasn't all that reliable anyway. So there are better non-elm options, like the xpro, or a (good) J2534 device.