Announcement

Collapse
No announcement yet.

OBD1 1995 Silverado

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • OBD1 1995 Silverado

    I purchased an ALDL cable form ALDLcable.com for use on my chevy OBD (pre OBDII). I have a 1995 Silverado 1500 6.5L turbo diesel.

    Anybody know what software will work for OBD1 systems?
    I have tried several, with no luck. I was kind of rushed when I tried it out last night, but could not get any software to read the data. I will continue trying, but would appreciate anybodys input.

  • #2
    what type of engine is it tbi efi? 5.7 ltr try searching for that in google itll generate some hits ALDL + "your make model" "type of engine"(if you know) etc

    have u tried winaldl that might have it

    also try getting the number off of your ecu and googling that thats how i found mine
    .______
    | '_ |__\___
    [(o)|___(o)] XB
    ._________
    | I__I I_I|_\__I
    [(o)______(o)]b VanPimpin'

    LostReceptions Apps D/L Here

    GPSGasoline- Rewriting

    Draw- SkribblePad for Touchscreens

    iGQwerty-iG3.0 Qwerty Keyboard

    CarPCNetwork

    Comment


    • #3
      It is a 6.5L turbo Diesel engine.

      I have retried a bunch of the applications with no luck. Datamaster, FreeScan, TunerRT, EFILive, WinAdl, ECM852.

      I did however find an application that probes the comport with an F4,56,01,checksum, the Truck echoes the command back, then sends a 25 byte reply of f4,6b,01,00,00,00,00,00,00,00,01,00,00,00,00,00,00 ,00,00,00,00,00,00,00,9f. The 6b in this reply is the number of bytes which is 52-6b, or 25 bytes in decimal, so it is some sort of valid reply. That is the end of the transmission of data.

      Should this data continue to stream?
      How do I know if the cable supplied by ALDLCABLE.COM will work with a 1995 Silverado (pre OBDII) ????

      Anybody know anything about the Pre OBDII cables, what is valid, what isnt???

      TIA.

      Comment


      • #4
        ECM Codes

        Ok, I found the codes on the ECM.

        They are:

        BPAK

        16216935

        Serv No. 16212488

        When I check the broadcast code BPAK on
        http://www.efitune.com/broadcast_codes/

        The only matching ECM ID is: 16212450

        Is this an incomplete list?
        What next?

        Comment


        • #5
          try searching for that ecm num in goggle and the key word obd etc yu might find what ur loking for that way
          .______
          | '_ |__\___
          [(o)|___(o)] XB
          ._________
          | I__I I_I|_\__I
          [(o)______(o)]b VanPimpin'

          LostReceptions Apps D/L Here

          GPSGasoline- Rewriting

          Draw- SkribblePad for Touchscreens

          iGQwerty-iG3.0 Qwerty Keyboard

          CarPCNetwork

          Comment


          • #6
            Well, I have been doing some more research and playing around. Since I am a professional software engineer, I started playing with some source code to probe.exe. I have found that my cable/truck combo has no problem communicating. When I send a request of "F4 57 01 00" I always get a correct response...likewise with other commands.

            I am able read plenty of data from the ECM.

            However one issue that I have is that there is never a steady stream of data from the ECM. It only returns data as the result of a request. It seems all of these aldl programs expect a steady data stream from the ECM.

            I have used PORTMON to monitor com port activity while running most of the applications, and it appears that every single application is just monitoring the port to get data, but my vehicle/cable combo do not provide constant data.

            Is there two protocols here? Why wouldn't any of the aldl programs send requests and get responses?

            The aldlcable.com circuit does not use the more complictated max232 design, is the max232 design required to get constant data flow?

            Anybody know about constant data flow?

            ...

            Comment


            • #7
              Depending on what your trying to do you might try GMTD Scan. I have found it very helpfull in diagnosing Injection, Fuel and Boost issues on two 1995 6.5L TD's. Turbo Scan Basic is free, pro is for cost if your interested.

              http://www.enghmotors.com/basic/default.aspx

              Best of Luck
              Tim

              Comment


              • #8
                Originally posted by geekazoid View Post
                Well, I have been doing some more research and playing around. Since I am a professional software engineer, I started playing with some source code to probe.exe. I have found that my cable/truck combo has no problem communicating. When I send a request of "F4 57 01 00" I always get a correct response...likewise with other commands.

                I am able read plenty of data from the ECM.

                However one issue that I have is that there is never a steady stream of data from the ECM. It only returns data as the result of a request. It seems all of these aldl programs expect a steady data stream from the ECM.

                I have used PORTMON to monitor com port activity while running most of the applications, and it appears that every single application is just monitoring the port to get data, but my vehicle/cable combo do not provide constant data.

                Is there two protocols here? Why wouldn't any of the aldl programs send requests and get responses?

                The aldlcable.com circuit does not use the more complictated max232 design, is the max232 design required to get constant data flow?

                Anybody know about constant data flow?

                ...
                GM's first generation diagnostic platform (OBD1) as well as their second generation (OBD2) both rely on request/response data transmissions. The only way to get constant data flow is to repeatedly be pinging the ECM with requests, and of course, waiting the appropriate amount of time in between for responses (I think GM's max response time is 200 msec) ... but ... where I was headed with this ...

                Why not just buy a product from a company that has already done all the legwork, and has the OE specs to know how to interpret the returned data? It'll be a PITA for you to know the response ranges that the ECM could give you and what they mean ... trust me.
                perk03z06
                --------------------------
                Windows XP PC
                InTruckPC
                P4 3.0 GHz Hyperthread CPU, 1Gb RAM, 120 Gb Hard Drive, DVD/CD-RW, Centrafuse XLE 1.47, 7" Xenarc, GPS, EV-DO via Samsung i730 ... more coming!

                Comment

                Working...
                X