Page 3 of 5 FirstFirst 12345 LastLast
Results 41 to 60 of 81

Thread: j1850 3 byte Header format

  1. #41
    HP Tuners Owner Keith@HPTuners's Avatar
    Join Date
    Sep 2002
    Location
    Chicago, IL
    Posts
    6,394

    Re: j1850 3 byte Header format

    DEFINATELY great info!

    Keep on having that fun, I wish I was doing the same thing.!!
    We got this guy Not Sure, ...

  2. #42

    Re: j1850 3 byte Header format

    Quote Originally Posted by Michael
    Physical Messages
    =================
    I did notice, that back on page one, you gave some examples for VIN...
    "
    Request GM VIN
    Send: $6C,$10,$F1,$3C,$01,$F2
    Send: $6C,$10,$F1,$3C,$02,$F3
    Send: $6C,$10,$F1,$3C,$03,$F4
    Vin: 6H8VTK69FYL012345
    "
    When I use these commands, I do not get the same CRC. Is this CRC between the tester and the computer? (and for explanation purposes, you stripped off the extra 'proprietary' bytes for your type obd tool?)
    If this is the case, then I'm guessing that between the tool and the vehicle, the CRC is re-created in the tool before sending out to the vehicle....???

    -troubled.
    Yes, my bad, sorry.
    Our software never "sees" the CRC, the last byte in the examples above is a checksum between the PC and the interface. The interface generates and checks the CRC automagically
    Paul

  3. #43
    Guest
    Guest

    Re: j1850 3 byte Header format

    So... I'm curious about strateges for pulling DTC codes... When I execute a 6c 10 f1 19 ff ff 00 (all status, all group), I get flood of data shooting back at my little tool, and it simply can't handle it... Partly becuase I wait 300uS after the last trasistion before I print it out my rs-232 at 115200... And while I'm in the middle of printing that out, I'll get another intrupt telling me that there's MORE data coming from the J1850 bus. which before I just ignored it (killed the frame)... Now, I've rewritten the code so I can buffer up to 4 frames...

    My question is, This "ff ff" is obviously going to grab pretty much all codes from the PCM, instead, I'm curious as to how one usually 'asks' the PCM for DTC's... either at a more managable rate, or... see my next question...

    Another question is, is the mode $19 the best for recieving codes? or should I just create a buffer large enough to handle it??? (and how many frames is usually expected)....

    - I am forcasting that next response to be... "Geez Michael, you much have a pile of dung that run's like crap, if you have a flood of trouble codes pouring out at you.."

    p.s. Yeah, I'm having fun... but, I wish I could have worked on this thing last night, but thurday's are the "drinking with friends night"... and tonight... well.... Lets just say, it wouldn't be very "romantic" of me if I left the misses in the house while I was in the garage playing... (valentines day today) So...perhaps I'll be able to get some work in saturday or sunday...

  4. #44

    Re: j1850 3 byte Header format

    Geez Michael. you must have... uh.. never mind.. ;D

    is that actual stored trouble codes its passing? Or is it just dumping every known DTC out the port?
    Business Network Solutions - for all your PC, network, printer and computer security needs.

  5. #45

    Re: j1850 3 byte Header format

    Quote Originally Posted by michael
    So... I'm curious about strateges for pulling DTC codes... When I execute a 6c 10 f1 19 ff ff 00 (all status, all group), I get flood of data shooting back at my little tool, and it simply can't handle it...
    - I am forcasting that next response to be... "Geez Michael, you much have a pile of dung that run's like crap, if you have a flood of trouble codes pouring out at you.."
    It's scary when you first see 60-70 trouble codes appear but do not fear, this is how I believe it works...

    Each trouble code usually has multiple conditions that must occur before the code can be considered pending. A pending code must usually occur multiple times (multiple drive cycles) before it is considered current. (Although some codes are current immediately i.e. bad O2 sensor).

    If a single condition out of the multiple occurs then the code is marked as immature. It cannot and should not be treated as a trouble code.

    The $XX byte in the following command:
    $6C,$10,$F1,$19,$XX,$FF,$00
    is the status byte. It has the following "bitmapped" values:
    $80 - MIL is illuminated
    $40 - Pending trouble code
    $20 - Old code - MIL was illuminated for this code but is no longer illuminated.
    $10 - History code with freeze frame data available.
    $08 - Manufacturer specific status (I do not know what this means).
    $04 - Manufacturer specific status (I do not know what this means).
    $02 - Current code.
    $01 - Immature code.

    Basically you'll get a lot of $01 and a lot of $20 codes. Both of these can be ignored - they are NOT trouble codes. They are either immature or old codes.

    To get real trouble codes you should request only
    $80+$10+$02=$C2

    To get real trouble codes AND pending trouble codes request:
    $80+$40+$10+$02=$D2

    Obviously you can make up your own combinations to suit your needs.

    Regards
    Paul

  6. #46
    Tuner in Training
    Join Date
    Dec 2002
    Location
    Posts
    27

    Re: j1850 3 byte Header format

    ive been following this. very interesting. now if i understood what all you were saying that'd be even better !

  7. #47
    Guest
    Guest

    Re: j1850 3 byte Header format

    O.k.... So I've got the mode 0, pid's 1-20 down... I've also played with the various j2190 routines...
    I'm now, planning to write a little dos display (probably just use the basic video bios to plot real-time bar graphs for all the data), Now I'm wondering, is there anything else that I'm missing? Any other fun little command set's other the reading pid's 0-20 and the j2190's?


  8. #48

    Re: j1850 3 byte Header format

    That's about all there is to it. Addictive, aint it?
    Paul

  9. #49

    Re: j1850 3 byte Header format

    I may have to stop playing with hardware and start trying to make my brain explode! Can't let you software people have ALL the fun now can we? ;D
    Business Network Solutions - for all your PC, network, printer and computer security needs.

  10. #50
    Guest
    Guest

    Re: j1850 3 byte Header format

    What about the ISO interface? Anybody can tell me if there are differences? I have to make a school report about the ISO interface. Unfortunately there is very little information about this protocol to find. Looking forward to hear!

    Regards,

  11. #51
    Guest
    Guest

    Re: j1850 3 byte Header format

    O.k... So, I'm now starting to think about rev 2 of my little toy...
    I quickly learned that it's important to be able to store multiple messages in a que before transmitting them back to the host computer, because if you don't, another message will come right when your in the middle of a rs-232 transmit and you'll miss the next frame of data. So, my next design will store all messages coming and going in a external sram... and relaying them while the bus is idle.
    I'll have a bank for 8096 bytes of 'going to the car' data, and another bank of 8096 bytes of 'coming from the car' data. The reason for this is becuase I remeber the conversation about the 4096 bytes of data. I will also be adding charactor's for control charactor's, end of frame's etc... so, I figure 8096 is plenty. I would be able to utilize near that capability yet, but I figure as I get more in tune (no pun intended), I'll be able to use it.

    So, there it is... Any thing I left out?



  12. #52
    Potential Tuner
    Join Date
    Feb 2003
    Location
    Posts
    5

    first post...

    Hi all,

    I've been reading your posts and I'm wondering if you're able to answer my questions...

    I have the following hex code that is being sent to my car via my remote car starter. This code is for opening my doors:

    88 C7 A2 30 11 55 AA C4

    When I start decoding this transmission I get stuck.

    88: Priority of 4, 3 byte header, no IFR, Functional Addressing...

    C7: according to J2178-4, C7=External Access on p. 369 of the HS-3000 and page 41 of the J2178-4 document found on a website given earlier on this board.

    Also of note is that the W-bit is a 1.

    A2: is the secondary address byte or in binary 10100010, Q-bit = 1, C-bit = 0 thus, WC = 10 -> report status

    bits(5-0): 100010 or 0x22 which signifies door handle switch active, also p. 369 of HS-3000

    30: is the extended address which should be on p. 378 of the HS-3000 but isn't listed. However if one goes to p. 260 of the HS-3000 you can see that this extended address (0b00110000) has an RR=00 and thus it is a geographical address and XXX=110 and YYY=000, thus giving me the trunk row and all columns...

    I stopped decoding the signal here... I didn't bother getting into the 11 55 AA C4 part though I assume C4 is the CRC but haven't verified it...

    Can someone help me decode this message???

    What I believe it does is the following: It unlocks all doors and disarms the factory alarm.

    I have more questions but I'll post them seperately.

    Thanks

  13. #53
    Potential Tuner
    Join Date
    Feb 2003
    Location
    Posts
    5

    a few more deocding quizzes...

    Hi all,

    Here's a few more codes I'd like decoded.

    When I press the door lock/unlock button (I forget whether it was lock or unlock) on my panel in my truck (a 2002 GMC Envoy) I get the following codes:

    8A C5 A0 A1 22 5F
    68 C4 40 11 00 1F F8
    8A C5 A0 21 22 96

    Similar to my last post I came across parts that were not defined in the HS-3000 manual....

    Thanks

  14. #54
    Guest
    Guest

    Re: j1850 3 byte Header format

    Verret,
    I've pretty much learned, that if it's not in the hs-3000, it's probably at NTI, accessible by subscribtion services at a rate of $5,000 a year (minimum subscription).
    I've already gone through the whole, upset, then sad, then angry, the accusing, then worry, then back to angry again... then, I finally settled with

    "ah, screw it... those darn GM people, all they want is money, and the NTI people too... so next time there in my back yard, and they ask me for a beer... I'll know what to tell them!!!"

    -venting

  15. #55

    Re: j1850 3 byte Header format

    verret: Just out of curiosity.. what are you using to read the code?
    Business Network Solutions - for all your PC, network, printer and computer security needs.

  16. #56
    Guest
    Guest

    Re: j1850 3 byte Header format

    o.K. .... I'm ready to start testing my 4X mode recieve capabilities... I know that an 0x04 in the fourth byte will tell me that I need to switch to 4x mode, but how should I initiate it? Do I just got tell the PCM: 6C 10 F1 04 XX ?


  17. #57
    Tuner in Training
    Join Date
    Dec 2002
    Location
    Yardville NJ
    Posts
    40

    Re: j1850 3 byte Header format

    It seems you always use $6C as the first byte in the three byte header for physical addressing for GM. Couldn't you use $4C, $2C or $0C as a higher priority first byte to win arbitration on the J1850?

    (or would this dissrupt the bus)


  18. #58
    Guest
    Guest

    Re: j1850 3 byte Header format

    Ya know... I thought about that too. But if stopped thinking about it becuase pretty much everytime I talk to the pcm, I get a response... regardless...

    As a matter of fact, somethiing I'm currently trying to understand... if you watch the bus without sending any messages out on it, you can see the bus is fairly busy. So, when I initiate communication, I get a response back, and then, the other commands that occur regularly, seem to walk on top of the information I'm recieving (if I ask for "all" trouble codes ). I know this becuase I detect many "breaks" between initiators... I'm guessing that the regular traffic that occurs, doesnt miss a beat, and just keeps on sending... and of course, the added info that I ask for creats a "very crowded" bus...
    But, to answer your original question, Yea, I've thought of it, but I don't think it matter's because I 'always' get a response no matter what priority I send.

  19. #59

    Re: j1850 3 byte Header format

    A fairly well equipped vehicle (lots of eletronic extras) will have a message schedule of around 10-15 messages per second. Most of these messages are only 5-6 bytes long, including the 3 header bytes and the CRC.

    Take the worst case example where ALL messages are the full 12 bytes:

    Start of frame symbol=200us
    short pulse width=64us
    long pulse width=96us
    (average pulse width=96us)
    Interframe seperator=300us
    1 frame (of 12 bytes) = 200+(96*8*12)+300 = 9,716us
    which is just under 10ms
    Which means a FULLY saturated bus should be able to handle 100 (12 byte) frames per second.

    So given the 10-15 frames of normal message scheduling, the bus is only 10-15% utilised.

    Due to latencies in the software/hardware processing we have been able to generate up to 90 messages per second (45 send/45 receive) between PC and a PCM.
    That was in a controlled environment, using a benchtop PCM with no other modules on the bus.

    In reality, scan tool software should be configured to send no more than 10 messages per second. 10 messages per second is the SAE recommended maximum scan tool message transmission frequency.

    Regards
    Paul

  20. #60
    Potential Tuner
    Join Date
    Feb 2003
    Location
    Posts
    5

    Re: j1850 3 byte Header format

    RoboGeek: I've written some firrmware for a PIC according to the J1850 standard and I'musing the Motorola MC33390 to do my wave shaping.

    all: I have the HS-3000 (1999 publication) and we've been able to nearly break down the message entirely, however, the datafields and bit-maksing is rather tricky, has anyone messed with that before???

    Also, does anyone have the HS-3000 (2003 pub). I heard it was going to come out Feb. 14, 03 but it looks now like it might not come out til April???