Announcement

Collapse
No announcement yet.

Sending multi frame messages with ELM over CAN

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

  • Sending multi frame messages with ELM over CAN

    Hiya,

    I've been trying to figure out how to send multi-frame CAN messages. The ELM does a good job of receiving multi-frame without any setup, but it doesn't seem to be as easy to send messages.

    From what I could gather reading the docs, to send multi-frame reqs, you need to disable auto can formatting and manually put in the PCI bytes for each data frame. After trying this method out, I get a Flow Control response back from the ECU after sending my First Frame, but for Consecutive Frames, I just get 'NO DATA'.

    Code:
    at z
    at e0
    at s0
    at sp0
    at at1
    at dp
    at sh 7e0
    at caf0
    
    To ELM 		
    10 0A 01 05 05 05 05 05
    
    From ELM 	        
    7E8 8 30 00 00 00 00 00 00 00
    
    To ELM 		
    21 05 05 05 05 00 00 00
    
    From ELM 	       
    NO DATA
    Does anyone have any suggestions?

    -Preet
    Check out my Frontend project!
    http://prismaticproject.weebly.com/blog.html

  • #2
    Hi preet,

    What means, all your "05"?
    The multi-frame is limited to 6 PIDs by the standard.

    You should try to send (with default configuration) 01 05 05 05 05 05 05. ELM will automatically send a request (on 2 frames, FF and 1 CF)

    Hope that will help you!
    www.outilsobdfacile.com

    Comment


    • #3
      Hi remus,

      I'm using '0x05' just as a test parameter. In an actual application they'd all be different PID requests.

      Why would the ELM send the request:
      01 05 05 05 05 05 05

      As 2 frames over CAN? It should fit within a single frame. There are 7 data bytes, and the remaining byte (PCI byte) would be used to indicate its a single frame, with 7 bytes of data:

      7E0 8 { 07[PCI byte] 01 05 05 05 05 05 05 }

      The 8 byte data payload is in curly brackets... this just requires a single frame, no?

      You're right in that sending 01 05 05 05 05 05 05 with defaults works, but I think this is because the request is sent as a single frame.


      Preet
      Last edited by preet; 05-29-2011, 01:34 PM.
      Check out my Frontend project!
      http://prismaticproject.weebly.com/blog.html

      Comment


      • #4
        Preet,

        Are you sending the commands by hand?

        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


        • #5
          Preet,
          You're right, "01 05 05 05 05 05 05" will send a single frame. What I would say, that your initial request is not valid from OBD2 point of view.
          There is a problem, even you request is not relevant you should have a 7F response

          There is a timing for the CF, so yes do you send it by hand?
          www.outilsobdfacile.com

          Comment


          • #6
            Hey,

            Thank you for the replies. I was initially entering in the commands manually but I'm now doing it with a program. Unfortunately I still have the same problem.

            I've attached my timestamped i/o (hh:mm:ss:ms)

            Transmit:
            Code:
            19:07:49.314:	AT Z
            19:07:50.109:	AT E0
            19:07:50.117:	AT S0
            19:07:50.125:	AT SP 0
            19:07:50.133:	AT AT1
            19:07:50.141:	01 0D
            19:07:50.573:	AT DP
            19:07:50.586:	AT CAF0
            19:07:50.593:	AT SH 7E0
            19:07:50.600:	10 09 01 05 05 05 05 05
            19:07:50.817:	21 05 05 05 05 00 00 00
            Receive:
            Code:
            19:07:49.314:	
            19:07:50.109:	ELM327 v1.4 >
            19:07:50.112:	AT E0
            19:07:50.117:	OK >
            19:07:50.125:	OK >
            19:07:50.133:	OK >
            19:07:50.141:	OK >
            19:07:50.149:	SEAR
            19:07:50.152:	CH
            19:07:50.157:	ING...
            19:07:50.368:	410D00
            19:07:50.573:	>
            19:07:50.581:	AUTO, ISO 15765-4 (CAN 11/500
            19:07:50.585:	) >
            19:07:50.592:	OK >
            19:07:50.600:	OK >
            19:07:50.616:	3000000000000000
            19:07:50.816:	>
            19:07:51.025:	NO DATA >
            Regards,

            Preet
            Check out my Frontend project!
            http://prismaticproject.weebly.com/blog.html

            Comment


            • #7
              Hey,

              I had to push down the default waiting time on the ELM (AT ST) to something below 100ms for it to work. I still got NO DATA's with a lowered waiting time with standard OBD requests, I'm guessing this is because of what remus mentioned (6 pids max per request). It worked when I sent other kinds of requests though.

              Thanks to both of you for the help!
              Check out my Frontend project!
              http://prismaticproject.weebly.com/blog.html

              Comment


              • #8
                Originally posted by preet View Post
                Hey,

                I had to push down the default waiting time on the ELM (AT ST) to something below 100ms for it to work.
                Another way would be to specify the number of expected responses, like this:

                01 0c 1

                This would get you the prompt as soon as you got a single message from the ECU.

                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


                • #9
                  Hey Vitaliy,

                  Unfortunately I couldn't specify the expected responses like that. The ELM doesn't seem to let me input more than 8 bytes. So for example if I tried to input:

                  10 09 01 05 05 05 05 05 1

                  The ELM would respond:

                  ? >


                  01 0c 1 works as its less than 8 bytes and returns as you'd expect. Is there a work around for my case?

                  * Also I want to clarify one thing. When you specify a number after the request, you're specifying the number of data frames the ELM expects to receive right? NOT number of bytes.

                  Regards,

                  -Preet
                  Check out my Frontend project!
                  http://prismaticproject.weebly.com/blog.html

                  Comment


                  • #10
                    Originally posted by preet View Post
                    Hey Vitaliy,

                    Unfortunately I couldn't specify the expected responses like that. The ELM doesn't seem to let me input more than 8 bytes. So for example if I tried to input:

                    10 09 01 05 05 05 05 05 1

                    The ELM would respond:

                    ? >


                    01 0c 1 works as its less than 8 bytes and returns as you'd expect. Is there a work around for my case?
                    ATAL (allow long messages).

                    * Also I want to clarify one thing. When you specify a number after the request, you're specifying the number of data frames the ELM expects to receive right? NOT number of bytes
                    Correct.
                    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


                    • #11
                      Originally posted by Vitaliy View Post
                      01 0c 1

                      This would get you the prompt as soon as you got a single message from the ECU.
                      What do you mean by this. How do you get a specific prompt or what do you look for? Does this require specialized communication software (dll)? I'm talking to my ECU through my program and simply retrieving strings after I request info through my comport. It would be great if I could get a specific prompt to retrieve the specific info.

                      Comment


                      • #12
                        Hyperterm is how you see or send commands or any other terminal program. you are just communicating with the com port. Hope this helps and that I am not way off base. SNO

                        Comment


                        • #13
                          Oh, he was talking about actually watching transmit and receive communication through a program designed to watch. I thought he was talking about the ability for the obd to specifically notify you that it sent the info, or the info is available...like an event notification. Thanks for clearing up.

                          Comment

                          Working...
                          X