Results 1 to 9 of 9

Thread: GM Mode 2C and AA request/responses

  1. #1
    Newbie
    Join Date
    Feb 2010
    Posts
    4

    GM Mode 2C and AA request/responses

    Hi all,
    I would like to write my own software that requests some GM PIDs, but not sure what the scanner is expecting when it's sending a mode 2C and AA request.

    I don't have a GM car that I can use, so wanted to write a quick emulator.

    When requesting for Throttle position the scanner sends

    7e0 04 2c fe 00 11

    and

    7e0 03 aa 04 fe

    Anyone know what sort of response the scanner is expecting?

    Thanks!

  2. #2
    Constant Bitrate
    Join Date
    Jan 2010
    Posts
    130
    This is not a trivial question with a simple answer. You are basically showing part of a GMLAN transaction.

    The 0x2C request is the Dynamic PID, or 'DPID' request, and the AA is the actual request for data. The reason that the AA has params is you control requested rate and formatting.

    Clearly you are looking at CAN, which is, I think, even more complicated than GMLAN over J1850 VPW. Some responses will be over non standard handshaking pairs. That is, typically in standard mode (11 bit) CAN, there is an offset of 8 between the ID the ECU uses to talk to you and the ID you use to physically talk to it. You can see this by requesting standard DTCs or something like VIN from any generic CAN ECU. But for some GM modules, the pairs are just 'known', you can't find them by a simple formula.

    Also, some requests result in completely nonstandard responses. Typically, the first byte in an OBD-II CAN response will tell you if it is self contained, or a multi packet response. But some GMLAN data streams don't follow the ISO protocol.

    The common paths to detailed GMLAN knowledge are generally choice a) pay GM $50K and enter a non disclosure agreement or b) reverse engineer, which I can personally attest is quite a bit of work. So I don't think you'll find a lot of folks who are free and easy with the knowledge.

    Personally, I'd say that what you appear to be trying to do - essentially spy on someone else's software and pick up a little know how, is not all that difficult. However, I'd put the odds of writing a GMLAN implementation without even investing in some second hand ECU's for the bench at about 0%.

    -jjf

    Edit: Although not all ECU's support them, a lot of basic stuff can sometimes be gotten via mode 22 PIDs, which generally follow the standard OBD-II communication rules. That might be a simpler path for you.

  3. #3
    licensed to kill - FKA kev000
    Auto Apps:loading...
    tripzero's Avatar
    Join Date
    Aug 2006
    Location
    16.40618, 120.61106
    Posts
    2,494
    This is slightly off-topic but somewhat relevant, what kind of info/control can you gain by using GMLAN specific stuff over what's available in the standard OBDII protocol? You mention throttle position, that's available through OBDII. Why do you need to do anything GMLAN specific to get it?

    I'm not trying to play devils advocate, I'm curious because I have a GM vehicle and would love to do stuff with the GMLAN if only I know what it was capable of.

    PS, you should make your software work on Linux. Then you will be put on the awesome list.
    Former author of LinuxICE, nghost, nobdy.
    Current author of Automotive Message Broker (AMB).
    Works on Tizen IVI. Does not represent anyone or anything but himself.

  4. #4
    Newbie
    Join Date
    Feb 2010
    Posts
    4
    I know Throttle posistion is available using generic OBD-II but I'm just using it as an example.

    jfitzpat: Thanks for the response. I didn't realise that GMLAN was so far removed from the ISO standard.

  5. #5
    Constant Bitrate
    Join Date
    Jan 2010
    Posts
    130
    Quote Originally Posted by tripzero View Post
    This is slightly off-topic but somewhat relevant, what kind of info/control can you gain by using GMLAN specific stuff over what's available in the standard OBDII protocol? You mention throttle position, that's available through OBDII. Why do you need to do anything GMLAN specific to get it?

    I'm not trying to play devils advocate, I'm curious because I have a GM vehicle and would love to do stuff with the GMLAN if only I know what it was capable of.

    PS, you should make your software work on Linux. Then you will be put on the awesome list.
    FWIW, most the J1979 (standard OBD-II) stuff is emissions related. Some things, that are of real interest for tuning, like 'knock count' and 'injector pulse width', are only available via non standard PID's. Not nec. critical, for example, you can often infer knock by watching spark advance, and I'd much rather be looking at wideband than IPW, but very very useful.

    -jjf

    Edit: FWIW, I did go to the trouble to make some SDK pieces Linux compilable, but I can see why commercial offerings are scarce.

  6. #6
    licensed to kill - FKA kev000
    Auto Apps:loading...
    tripzero's Avatar
    Join Date
    Aug 2006
    Location
    16.40618, 120.61106
    Posts
    2,494
    Quote Originally Posted by jfitzpat View Post
    fwiw, most the j1979 (standard obd-ii) stuff is emissions related. Some things, that are of real interest for tuning, like 'knock count' and 'injector pulse width', are only available via non standard pid's. Not nec. Critical, for example, you can often infer knock by watching spark advance, and i'd much rather be looking at wideband than ipw, but very very useful.

    -jjf

    edit: Fwiw, i did go to the trouble to make some sdk pieces linux compilable, but i can see why commercial offerings are scarce.
    sdk?
    Former author of LinuxICE, nghost, nobdy.
    Current author of Automotive Message Broker (AMB).
    Works on Tizen IVI. Does not represent anyone or anything but himself.

  7. #7
    Low Bitrate
    Join Date
    Jul 2005
    Location
    Michigan
    Posts
    70
    When requesting for Throttle position the scanner sends

    7e0 04 2c fe 00 11

    and

    7e0 03 aa 04 fe

    Anyone know what sort of response the scanner is expecting?
    The answer is you should reply with:

    Request: 7E0 04 2C FE 00 11 - Place 0x0011 PID into Dynamic DPID 0xFE
    Reply: 7E8 02 6C FE 00 00 00 00 00 - Positive Repsonse

    Request: 7E0 03 AA 04 FE - Request at a Fast Rate Dynamic DPID 0xFE (which now contains 0x0011 Throttle Position)
    Reply: 5E8 FE XX 00 00 00 00 00 00 00 - Where XX is the throttle position. - Data.

    Request: 7E0 01 3E - Should occur around once every 3 seconds - Tester Present, sent to let the ECM known that it should continue sending the 5E8 message.
    Reply: 7E8 01 7E 00 00 00 00 00 00 - Positive response.

    -Good Luck

  8. #8
    Newbie
    Join Date
    Feb 2010
    Posts
    4
    chewwtoy: you sir are a champion

  9. #9
    Low Bitrate
    Join Date
    Jul 2005
    Location
    Michigan
    Posts
    70
    [bow]...[/bow]

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
  •