Announcement

Collapse
No announcement yet.

what serial data protocol is this??

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

  • what serial data protocol is this??

    I have a 2006 scion TC and I'm trying to determine what serial link protocol is used to let the keyless entry receiver communicate with the Integrated relay. It's not CAN BUS because the two data wires coming out of the keyless entry receiver are not differential (two data wires, one power and one ground). Also the baud rate is only 2.4k and that's too slow for CAN BUS standard.

    I'm not doing anything illegal btw. I'm trying to develop a circuit that will detect when I press the lock/unlock button on my key fob.

    Here are the captures from my oscilloscope:

    data stream


    zoomed


    zoomed

  • #2
    It might be easier to monitor the locking solenoid.

    I'd expect 2.5V or 5V carrier. I don't think it's any common protocol though. You might need a PIC to decode it. The wierd thing is the different size pulses. They should be about the same as the sync bit, or double at most to be understandable. Are you sure the other wire is ground and not a latch signal?

    Comment


    • #3
      Can't offer any help right now, but I like the thought of your circuit! I'd just tap into the other side of the relay, but I'm sure you have a very good reason for decoding the signal. Love it! Good luck!
      2001 Mustang Convertible Worklog
      Indigo Custom Frontend (Flash/Delphi)
      Blog

      Qube v1.3 Now Available at the mp3Car Store!!!!!!
      The simplest IO controller you'll ever use!

      Comment


      • #4
        Originally posted by Curiosity View Post
        It might be easier to monitor the locking solenoid.

        I'd expect 2.5V or 5V carrier. I don't think it's any common protocol though. You might need a PIC to decode it. The wierd thing is the different size pulses. They should be about the same as the sync bit, or double at most to be understandable. Are you sure the other wire is ground and not a latch signal?
        I don't want to monitor the locking solenoid, because I want to distinguish between a remote unlock and when a person presses the unlock button from inside the car.

        The keyless entry receiver module has four wires: Power, ground, RDA and PGA. Maybe the name of the wire will give you a clue as to what protocol communication the module uses. The scope captures above is from the RDA wire. I also scoped the PGA wire and it also had serial data activity. I don't know what a latch signal is or what it looks like...

        Different size pulses??? I don't get it. All the pulses (a bit) are about .42ms

        Comment


        • #5
          Fair warning typically the serial coms between the security module and the ECU use a rotating cypher. Can you grab a cap now and one after cycling things a few times to compare if it changed?
          openMobile - An open source C# Front End (why choose openMobile?)
          - Always Recruiting Developers -
          Like what you see? Donations are always welcome

          Comment


          • #6
            Oh yeah, forgot about that. They all use some sort of code-hopping now for security reasons. I would just tap into the locking solenoid and the one side of the button... isolate with a diode maybe so you can tell where the signal is coming from...
            2001 Mustang Convertible Worklog
            Indigo Custom Frontend (Flash/Delphi)
            Blog

            Qube v1.3 Now Available at the mp3Car Store!!!!!!
            The simplest IO controller you'll ever use!

            Comment


            • #7
              Originally posted by justchat_1 View Post
              Fair warning typically the serial coms between the security module and the ECU use a rotating cypher. Can you grab a cap now and one after cycling things a few times to compare if it changed?
              The waveform doesn't seem to change. Is it possible that code hopping is done within the keyless entry receiver module? I think the module just sends a door unlock cmd to the integrated relay to unlock the door.

              Comment


              • #8
                Code hopping is all done at the RF level. This should be after decoding, so it should be the same.

                RDA/SDA reminds me of RS422. There are 2 lines, but forgot how it works.

                A latch signal allows the speed to be unknown. Basically, a transition from low to high means read a bit. It's used in character LCDs, NES controllers, and lots of other devices.

                But anyway, all you really need to do is wait while high for low transition, fast loop until it goes high again, then set up a timed read for a number of loops, process the data, and go back to the wait. For each button press you should get a different value as long as the timing is close enough to be reliable.

                Comment


                • #9
                  It's using transition coding. It ain't "bits".

                  Comment


                  • #10
                    Ok, so how would you store transitions in data form?

                    Comment


                    • #11
                      Manually? Find the unit (smallest timing) and decode.

                      Is that what you mean?

                      Comment


                      • #12
                        No. What I mean is the transition is a logical 0 or 1 (i.e. a bit of information). The transition space may be either a 00/01 as a mark space or it could be simply bits at a specific timing after the sync. Either way there are only a few commands and reading them at a specific timing will yield a result of maybe 8-16 bits that differ by command and should always be the same for the same command.

                        Comment


                        • #13
                          The transmission of a set piece of data will be one of two variations - ie, the original or its compliment. IE a command isn't always the same, it has 2 versions.

                          Whether 0 or 1 is part of your decode.... You probably start from some sync signal but otherwise its much the same... assume the keying; assume a 1 or 0; decode appropriately & search for matches. 8, 16, parity etc - that's the decode....
                          (The skilled can tell whether 8 or 16 bits and what keying used. About all I can probably do now is how many bits and whether sync or parity for 8 bits LOL!)

                          Comment


                          • #14
                            We're just using 0 or 1 to represent the off or on signal in this situation (the data as voltage). Yes, it's inverted because the carrier is high (on = 1 normally, but off = 1 is easier to understand). The sync bit denotes the timing. The rest follows. I can't really tell how many bits because I don't know if that first pic was 1 or 2 button presses, but having all the button data and comparing would help. We're also only getting half the information since there's a second data line, so there's a lot of guessing.

                            Comment


                            • #15
                              LOL! Yes - it's called decoding.

                              It seems obvious that high is idle in this system.

                              Next decision - what coding is used..... wikibooks: Communication Systems/Line Codes??


                              (Sometimes if it's an ECU system (not PIC), ECU reverse coding is easier - but auto systems aren't sophisticated nor encoded to that extent. Even in-house/proprietry protocols are usually easier to crack.)

                              Good luck!

                              Comment

                              Working...
                              X