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.
Last edited by JP86SS; 09-16-2012 at 09:29 PM.
86 Monte, 406, Hyd Roller, 700R4 beefed, G3-APU1 and NVSRAM 730, S_AUJP
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...
86 Monte, 406, Hyd Roller, 700R4 beefed, G3-APU1 and NVSRAM 730, S_AUJP
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
86 Monte, 406, Hyd Roller, 700R4 beefed, G3-APU1 and NVSRAM 730, S_AUJP
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
86 Monte, 406, Hyd Roller, 700R4 beefed, G3-APU1 and NVSRAM 730, S_AUJP
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
1990 Chevy Suburban 5.7L Auto ECM 1227747 $42!
1998 Chevy Silverado 5.7L Vortec 0411 Swap to RoadRunner!
-= =-
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.
86 Monte, 406, Hyd Roller, 700R4 beefed, G3-APU1 and NVSRAM 730, S_AUJP
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
86 Monte, 406, Hyd Roller, 700R4 beefed, G3-APU1 and NVSRAM 730, S_AUJP
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.
86 Monte, 406, Hyd Roller, 700R4 beefed, G3-APU1 and NVSRAM 730, S_AUJP
sorry to 'jack your thread but where the heck did you guys learn all this?! LOL
Bookmarks