Page 2 of 3 FirstFirst 123 LastLast
Results 16 to 30 of 38

Thread: Tuner Pro V5 and OBDII plug-in?

  1. #16
    Super Moderator
    Join Date
    Mar 2011
    Location
    Camden, MI
    Age
    35
    Posts
    3,026
    that's...... so odd.

    why would they purposely make the OBD2 PID request protocall with more overhead than necessary?
    1995 Chevrolet Monte Carlo LS 3100 + 4T60E


  2. #17
    Administrator
    Join Date
    May 2011
    Location
    Lakes Region, NH
    Age
    54
    Posts
    3,844
    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.

  3. #18
    Fuel Injected! JP86SS's Avatar
    Join Date
    Aug 2011
    Location
    Browns Town (Cavs too)
    Posts
    59
    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

  4. #19
    Administrator
    Join Date
    May 2011
    Location
    Lakes Region, NH
    Age
    54
    Posts
    3,844
    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

  5. #20
    Administrator
    Join Date
    May 2011
    Location
    Lakes Region, NH
    Age
    54
    Posts
    3,844
    Here's a link to GM mode 6 PIDs.
    http://service.gm.com/gmspo/mode6/

    These can also be used as scan data.

  6. #21
    Fuel Injected! JP86SS's Avatar
    Join Date
    Aug 2011
    Location
    Browns Town (Cavs too)
    Posts
    59
    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

  7. #22
    Super Moderator
    Join Date
    Mar 2011
    Location
    Camden, MI
    Age
    35
    Posts
    3,026
    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.
    1995 Chevrolet Monte Carlo LS 3100 + 4T60E


  8. #23
    Fuel Injected! JP86SS's Avatar
    Join Date
    Aug 2011
    Location
    Browns Town (Cavs too)
    Posts
    59
    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

  9. #24
    Administrator
    Join Date
    May 2011
    Location
    Lakes Region, NH
    Age
    54
    Posts
    3,844
    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?

  10. #25
    Fuel Injected! JP86SS's Avatar
    Join Date
    Aug 2011
    Location
    Browns Town (Cavs too)
    Posts
    59
    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

  11. #26
    RIP EagleMark's Avatar
    Join Date
    Feb 2011
    Location
    North Idaho
    Age
    63
    Posts
    10,477
    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!
    -= =-

  12. #27
    Fuel Injected! JP86SS's Avatar
    Join Date
    Aug 2011
    Location
    Browns Town (Cavs too)
    Posts
    59
    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

  13. #28
    Fuel Injected! JP86SS's Avatar
    Join Date
    Aug 2011
    Location
    Browns Town (Cavs too)
    Posts
    59
    Here is a sample of my data:
    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
    definition seems to be getting what I'm asking for, but...
    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).
    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)
    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?

    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

  14. #29
    Fuel Injected! JP86SS's Avatar
    Join Date
    Aug 2011
    Location
    Browns Town (Cavs too)
    Posts
    59
    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

  15. #30
    Fuel Injected!
    Join Date
    May 2011
    Location
    Alamogordo, NM
    Posts
    330
    sorry to 'jack your thread but where the heck did you guys learn all this?! LOL

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •