that's...... so odd.
why would they purposely make the OBD2 PID request protocall with more overhead than necessary?
Printable View
that's...... so odd.
why would they purposely make the OBD2 PID request protocall with more overhead than necessary?
So the comms are ASCII representation of hex?? Huh????? Did someone put Microsoft in charge of OBDII PID's???
Maybe I can find time to try hammering away at this PCM I have here using ASCII xmits instead of hex.
I think the communication protocol is in Hex, the Plug-in or the interpreter to the ELM327 is using ASCii based input (and possibly output)
The confusing part is that the existing command in TP has 0x20 indicating Hex but is a hex representation of an ASCii character "space'.
Still wrapping my brain around all of this.
The response from the interpreter/Plug-in appears to be just hex because there is no offset or anything in the response command definition.
Figuring at this point, Send ASCii, Receive in Hex.
the interpreter must be sectioning out the variable size data from the 11 bit CANbus response format.
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
Here's a link to GM mode 6 PIDs.
http://service.gm.com/gmspo/mode6/
These can also be used as scan data.
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...
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.
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
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?
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
Your having fun way over my head... but wouldn't the ADX already done for LS1 have some of this info?
http://www.gearhead-efi.com/Fuel-Inj...cat-OBD2-cable
Never saw that, That would have been helpful a couple weeks ago :)
My file has more in it now though.
The commands are the same as mine so I'll go back to not using the "0D"
If that file has been proven then I may have comm issues on my laptop causing the scrambles.
Here is a sample of my data:definition seems to be getting what I'm asking for, but...Code:000001: ?
000002:
000003: >ATWS
000004:
000005:
000006: ELM327 v1.5
000007:
000008: >ATE0
000009: ATE0
000010: OK
000011:
000012: >ATL0
000013: OK
000014:
000015: >ATS0
000016: OK
000017:
000018: >01001
000019: 410080000001
000020:
000021: >01201
000022: 412080018001
000023:
000024: >01401
000025: 414040000000
000026:
000027: >01041
000028: 410400
000029:
000030: >01001 (Bad command should be 0105, I fixed it!)
000031: 4100BFBFB993
000032:
000033: >01061
000034: 410680
000035:
000036: >01071
000037: 41077F
000038:
000039: >01081
000040: 410880
000041:
000042: >01091
000043: 41097B
000044:
000045: >010A1
000046: NO DATA
I'm getting "ghost data" on the vehicle speed that seems to be the same as the RPM level.
I've checked the commands and response setups and am wondering if I'm displaying the right values at all. (the 1's at the end of the commands are not in my sent string)
The response is set for 1 in all the payload boxes except for the 16 bit (set to 2) or binary 4 byte values that request PID status (set 4).
Seeing how the response also includes the command, should I be using a 2 byte offset or possibly entering the command into the "Header" field as hex characters?Code:000036: >01071 Mode 1, 07 PID request, 1 is added by plug in?
000037: 41077F 41 indicates mode 1, 07 is PID#, 7F is data (8 bit)
Just thinking that may be another part I'm missing.
TIA
found out the 7E8 is the PCM and the other could be a trans controller or another module on the network.
Still trying to make this work.
i'm going to try the header and footers with variable length replys to see if that works better.
sorry to 'jack your thread but where the heck did you guys learn all this?! LOL