Announcement

Collapse
No announcement yet.

Low Speed GMLAN Interface

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

  • Low Speed GMLAN Interface

    Ok, I’ve been looking around this board for a while, so now for my first post.

    I am looking for a low cost off-the-shelf Vehicle to USB or RS232 adapter for the Low Speed GMLAN. At this time I do not wish to start from scratch and build my own interface, maybe in the future if my ideas pan out.

    This is not an OBDII device, nor will any of the ELM based devices work.

    Purpose is to explore the bus and operate a few items like the door locks. I have read of someone using only the CANHi side of a Two-Wire CAN to read the bus, but this was not a stable platform and sending commands sounded iffy.

    On my vehicle the ECU, TCU, Brakes and Steering are on the 2-Wire Hi Speed GMLAN or “CAN” operating at 500kps. All other communications within the vehicle are on this Low Speed Single Wire CAN.

    There’s been some recent activity on this forum regarding this SW CAN.

    What I know: well think I know
    GM’s “Low Speed GMLAN” is a Single Wire CAN operating at 33.33kps.
    It conforms to SAE standard J2411 & GM standard GMW3089.
    Its Higher Layer protocol is OSEK.

    To help others wishing to develop a project the following CAN transceiver chips interface with it:
    NXP AU5790 SEE IMPORTANT NOTE IN POST #34
    Infineon TLE6255
    Melexis TH8055 or 8056
    Freescale 33897
    On Semiconductor NCV7356

    Anybody make what I am looking for?

  • #2
    Originally posted by Hebe View Post
    Ok, I’ve been looking around this board for a while, so now for my first post.

    I am looking for a low cost off-the-shelf Vehicle to USB or RS232 adapter for the Low Speed GMLAN. At this time I do not wish to start from scratch and build my own interface, maybe in the future if my ideas pan out.

    This is not an OBDII device, nor will any of the ELM based devices work.

    Purpose is to explore the bus and operate a few items like the door locks. I have read of someone using only the CANHi side of a Two-Wire CAN to read the bus, but this was not a stable platform and sending commands sounded iffy.

    On my vehicle the ECU, TCU, Brakes and Steering are on the 2-Wire Hi Speed GMLAN or “CAN” operating at 500kps. All other communications within the vehicle are on this Low Speed Single Wire CAN.

    There’s been some recent activity on this forum regarding this SW CAN.

    What I know: well think I know
    GM’s “Low Speed GMLAN” is a Single Wire CAN operating at 33.33kps.
    It conforms to SAE standard J2411 & GM standard W308GM9.
    Its Higher Layer protocol is OSEK.

    To help others wishing to develop a project the following CAN transceiver chips interface with it:
    NXP AU5790
    Infineon TLE6255
    Melexis TH8055 or 8056
    Freescale 33897
    On Semiconductor NCV7356

    Anybody make what I am looking for?
    Coincidental . I am looking for a source of the SW CAN transceiver chips and google came up with this page.

    Is your car a Pontiac G8? They certainly have the the HS CAN/SW CAN split as you describe.

    Thx.

    Comment


    • #3
      My vehicle is a 2009 HHR.

      It is my belief that all GM vehicles since ~2006 have both the Low and High Speed GMLANS, but what do I know.

      Comment


      • #4
        Originally posted by Hebe View Post
        My vehicle is a 2009 HHR.

        It is my belief that all GM vehicles since ~2006 have both the Low and High Speed GMLANS, but what do I know.
        Well...you do know what you are talking about as that is pretty well correct from 06 on, some 05 but not much.

        Are you mainly interested in the LS CAN for ICE/entertainment reasons?

        Comment


        • #5
          I don't understand the "ICE" term.

          However, I wish to intercept the door lock and unlock command from the remote receiver and the chime on and off commands.

          Comment


          • #6
            Originally posted by Hebe View Post
            I don't understand the "ICE" term.

            However, I wish to intercept the door lock and unlock command from the remote receiver and the chime on and off commands.
            Sorry...TLA: three letter acronym..."In Car Entertainment": ICE.

            Yes that will need the LS CAN.

            Comment


            • #7
              I think that it's possible to use an ElmScan 5, by replacing the CAN transceiver with a SW version, and rewiring the pins to go to pin 1 of the J1962. Then you configure one of the user CAN protocols for 33k, and you should be good to go.
              OBDLink MX: world's smallest, fastest, most advanced OBD/Bluetooth adapter with SW and MS CAN support. Read the review to learn more.
              — Need to look up a diagnostic trouble code? Try the most up-to-date, free DTCsearch.com!

              You cannot send me a private message using this forum. Use my email instead: vitaliy[@]scantool.net.

              Comment


              • #8
                Originally posted by Vitaliy View Post
                I think that it's possible to use an ElmScan 5, by replacing the CAN transceiver with a SW version, and rewiring the pins to go to pin 1 of the J1962. Then you configure one of the user CAN protocols for 33k, and you should be good to go.
                I had considered doing something like what Vitality suggests and had the following problems with the concept:

                * A review of the ELM product manuals from various manufacturers did not reveal a setting for 33.33K. The settings I found seemed to exclude this speed. Are you definitively saying this speed is available on an ELM product? I had earlier in my quest called ELM and they said it did not support what I was looking at doing. Or perhaps I worded my question to them incorrectly.

                * Since I have been looking into this I have now generated a desire to have a good working unit for general OBDII use after this project and do not want to bugger up a perfectly good unit. I don't know about you, but my soldering skills to repeatedly solder a chip in and then back out seem to destroy pads.

                * I am willing to spend a bit more for both capabilities in one product. So I am still looking around.

                I notice you limited your suggestion to the ElmScan 5 and did not mention your newer product, whose name escapes me. Would it be capable of this as well?

                Comment


                • #9
                  ObdPro does a hardware mod that enables you to use the obdpro scantool to talk to the SW CAN. I'm having mine modded as we speak. Seems like there's almost enough demand to enable this by default...
                  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.

                  Comment


                  • #10
                    Originally posted by tripzero View Post
                    ObdPro does a hardware mod that enables you to use the obdpro scantool to talk to the SW CAN. I'm having mine modded as we speak. Seems like there's almost enough demand to enable this by default...
                    I thought that OBDPRO used the ELM 327 command set. That doesn't offer a way to set the 'high voltage' state (SW CAN has 3 states). You can't get to some functionality without that, so perhaps they added a superset command or something.

                    -jjf

                    Comment


                    • #11
                      Originally posted by Hebe View Post
                      I had considered doing something like what Vitality suggests and had the following problems with the concept:

                      * A review of the ELM product manuals from various manufacturers did not reveal a setting for 33.33K. The settings I found seemed to exclude this speed. Are you definitively saying this speed is available on an ELM product? I had earlier in my quest called ELM and they said it did not support what I was looking at doing. Or perhaps I worded my question to them incorrectly.
                      This sounds like Jim Nagy. He tends to say "no" to anything that doesn't fall within his comfort zone. I suppose it makes sense -- who needs extra support headache...

                      Anyway, look at programmable parameters, specifically PP 2C and 2D.


                      * Since I have been looking into this I have now generated a desire to have a good working unit for general OBDII use after this project and do not want to bugger up a perfectly good unit. I don't know about you, but my soldering skills to repeatedly solder a chip in and then back out seem to destroy pads.
                      We have a reflow workstation in our lab, but I agree that if you replace the chip more than once the pads may separate from the PCB.


                      * I am willing to spend a bit more for both capabilities in one product. So I am still looking around.

                      I notice you limited your suggestion to the ElmScan 5 and did not mention your newer product, whose name escapes me. Would it be capable of this as well?
                      OBDLink currently doesn't support setting protocols (ATSP) above 8. We plan to implement this functionality in the coming weeks.


                      I thought that OBDPRO used the ELM 327 command set. That doesn't offer a way to set the 'high voltage' state (SW CAN has 3 states). You can't get to some functionality without that, so perhaps they added a superset command or something.
                      Good point, I forgot that you need to have a way to set the mode bits.

                      Vitaliy
                      OBDLink MX: world's smallest, fastest, most advanced OBD/Bluetooth adapter with SW and MS CAN support. Read the review to learn more.
                      — Need to look up a diagnostic trouble code? Try the most up-to-date, free DTCsearch.com!

                      You cannot send me a private message using this forum. Use my email instead: vitaliy[@]scantool.net.

                      Comment


                      • #12
                        Originally posted by jfitzpat View Post
                        I thought that OBDPRO used the ELM 327 command set. That doesn't offer a way to set the 'high voltage' state (SW CAN has 3 states). You can't get to some functionality without that, so perhaps they added a superset command or something.
                        -jjf
                        My understanding is the 12v over voltage command is only to send "Wake-up" commands to the remaining nodes. Is there some other function the 12V does I am not aware of?

                        Originally posted by Vitaliy View Post
                        Anyway, look at programmable parameters, specifically PP 2C and 2D.Vitaliy
                        I missed that on my first run through of the ELM 327 data sheet. Still don't fully understand it, but that is OK for now.

                        Comment


                        • #13
                          Originally posted by Hebe View Post
                          My understanding is the 12v over voltage command is only to send "Wake-up" commands to the remaining nodes. Is there some other function the 12V does I am not aware of?
                          My recollection is that the high voltage message is also involved in accessing the high-speed/low-speed GMLAN bridge. If you are a radio and want to auto adjust volume based on RPM, turn lights off on key ignition, that sort of thing.

                          I didn't have anything specific in mind, I was just thinking in terms of completeness. If you are going to put in the right transceiver, it seems like it would make sense to give access to the state.

                          In terms of bit rate, they call it 33.33, but everything I've seen suggests that it is 500K / 15, or 33.333333... So, if you can set the rate divisor you are probably OK. The only gotcha would be that most CAN controllers don't just take a rate, like a UART. You also have to program a bunch of segments and propagation delay stuff. I'm not sure if this is inherited from Bosch, whose controller is spectacularly complicated, or what (see Silicon Labs chips and the Bosch companion doc, or the simpler Microchip CAN Module doc to see what I mean). So, I could envision firmware not handling a previously untested super low rate correctly, but you'd have to test it to see.

                          -jjf

                          Comment


                          • #14
                            Originally posted by jfitzpat View Post
                            My recollection is that the high voltage message is also involved in accessing the high-speed/low-speed GMLAN bridge. If you are a radio and want to auto adjust volume based on RPM, turn lights off on key ignition, that sort of thing.
                            In my case the Body Control Module(BCM) acts as the GMLAN bridge and I believe is just another node. In this case the BCM has a node from the low speed CAN and the High speed CAN. One piece of information that passes thru the BCM is vehicle speed, just as you mention for the radio.


                            Originally posted by jfitzpat View Post
                            I didn't have anything specific in mind, I was just thinking in terms of completeness. If you are going to put in the right transceiver, it seems like it would make sense to give access to the state.
                            I think that would be great for any vendor to supply. Hint!!!

                            Originally posted by jfitzpat View Post
                            In terms of bit rate, they call it 33.33, but everything I've seen suggests that it is 500K / 15, or 33.333333... So, if you can set the rate divisor you are probably OK. The only gotcha would be that most CAN controllers don't just take a rate, like a UART. You also have to program a bunch of segments and propagation delay stuff. I'm not sure if this is inherited from Bosch, whose controller is spectacularly complicated, or what (see Silicon Labs chips and the Bosch companion doc, or the simpler Microchip CAN Module doc to see what I mean). So, I could envision firmware not handling a previously untested super low rate correctly, but you'd have to test it to see.

                            -jjf
                            Absolutely correct, according to my recent readings.

                            My understanding, Bosch being the inventor of CAN, licenses all CAN hardware and the conditions of the license is that all products be compatible for both bus lengths and different manufacturers hardware. Every time you buy a CAN chip a royalty has already been paid to Bosch.

                            Comment


                            • #15
                              Originally posted by Hebe View Post
                              In my case the Body Control Module(BCM) acts as the GMLAN bridge and I believe is just another node. In this case the BCM has a node from the low speed CAN and the High speed CAN. One piece of information that passes thru the BCM is vehicle speed, just as you mention for the radio.
                              Now that you describe it, I don't know if the presentation I watched was giving an actual (deployed) or future/hypothetical. The gist was a scheme where dealer shifted acc's could alter what flowed through bridging automatically.

                              Originally posted by Hebe View Post
                              I think that would be great for any vendor to supply. Hint!!!
                              We have a board we use for OEM stuff that is essentially what you seem to want. It isn't really a good fit for the high volume consumer channel, but I suppose it could conceivably be an OEM product. We have a couple of other board/module OEM items now.

                              My hesitation is rather or not the firmware is at the right level for these sorts of applications. Right now it is basically SW and DW CAN passthru with basic filtering and rate control. It has no higher level protocol knowledge of GMLAN, in fact we use it on several, very different, systems. Making the host application wholly responsible for something like GMLAN is pretty demanding. Without researching it, I wouldn't be sure if certain timing requirements are hard to meet.

                              Probably not with SW, it's pretty slow and very forgiving. But I'll have to think about it before I consider mentioning it to the powers that be.


                              Originally posted by Hebe View Post
                              Absolutely correct, according to my recent readings.
                              Well, the last time I counted it has been my mis... uh, good fortune, to have worked with 7 different CAN modules, all with their own quirks and umpteen registers (to be fair, some are a lot more aggravating than others).

                              -jjf

                              Comment

                              Working...
                              X