Tuner Pro V5 and OBDII plug-in?

[1project2many]

That makes more sense. I checked the ELM327 documentation. Hyperterm is suggested as the easiest way to communicate with the chip which means yes, ASCII. If you're oldschool enough to have used hyperterm then most of this will seem old hat. I'd copy the text here but the copy I'm looking at is protected so that's not an option. There's slow or fast comms with the ELM (9600 or 38k baud). All responses by ELM are terminated with single carriage return (0D) and optionally, with linefeed as well. AT Z is reset signal to ELM which may be in the file you're looking at. Commands to ELM are preceded with AT while commands intended to be passed onto OBDII controller are only allowed to contain the ASCII codes for hex digits, and all commands must be terminated by carriage return. Any commands sent to ELM by pc take preference over comms on OBDII data and ELM will stop OBDII comms if a new command is received from PC before an answer is returned on OBDII line. Timing is everything.

http://elmelectronics.com/DSheets/ELM327DS.pdf

[1project2many]

Here's a link to GM mode 6 PIDs.
http://service.gm.com/gmspo/mode6/

These can also be used as scan data.

[JP86SS]

Thanks for the help :)
I'm finding out that timing is everything.
I thought I was getting good data until I added 10 items.
Now they seem to be "ghosting" into each other (speed rises with RPM, etc)
I have to go back and see if the plug-in is terminating the command or if I need to.
Could need a delay after each item as well.
seems odd that if my Bluetooth device is seen by the Winders tool it won't connect but if Windows and the BT app do not see the device, it connects at 38.4K.
The rabbit hole is getting deeper...

[RobertISaar]

i believe that's partly why a lot of the ELM327 based applications have PID "priorities". high priority gets updated often, low priority, not so much.

it would seem that the OBD2 communications are pretty picky about message length/repetition.

[JP86SS]

Just looked at my port sniffer log,
Seems you need to terminate request with a CR. (will add ASCii 0D to the end of all my requests and try again)
Man those things come in handy.
Jp

[1project2many]

There's a note in the documentation about a timeout while waiting for data to ensure items don't get lost of missed. Apparently if you know how many data items are going to be returned there's a way around this. I don't know if it's relevant but it was implemented for scantool software to increase refresh rates so it may be applicable.

What are you using for a port sniffer?

[JP86SS]

The 0D at the end seems to cause some strange output.
The returning data now has two "0d" chars at the end and some have a ">" added.
The "space" character has also disappeared from the transmit side of things and the codes are coming out together.
Still returned data but they do seem to be ovewriting each other.
Could be that the plug-in is adding it (CR) already.
May also have something to do with the "7EA" response leading the "7E8" response data.
I want the 7E8 data.
I could be picking up the wrong response. Still need to play with it and record the comms.
A small delay after each macro of request/reply might help.

I downloaded a trial of a Serial Port monitor. It works real good but only has another couple of days to use it.
I'll dig around the net and see if I can find something to use after that.
Just need raw data, although the packet count screen is helpful to see how fast my routines are executing.
I'm 1/3 of what a commercial logger is doing but that could be erroneous counts due to overlapping.

I did see that on one of the logs that the ELM initialization reset the comm to 9600 rate, definition is set for 38.4K