I need to decode communication between two devices, but I have no information about these devices. All I know is that four wires are needed (GND, VCC and two wires of communication). I suspect that it is I²C communication.

I'm trying to decode it with the oscilloscope decoding tool, but I'm not quite sure about it. I can not identify elements of I²C communication appropriately when I visually check the waveforms.

Looking at the waveforms I made the following assumptions, and maybe someone can help. These were my assumptions:

  1. Everything leads to believe that the clock is the blue signal and the data is the red signal.
  2. The clock seems to be inverted because its idle state is not at high level.
  3. I'm not sure if the data signal is also inverted, but it seems to be.

Are my assumptions correct?

In the last figure, the figure with the number 5 indicated in a circle, and there is a part of the signal. I can not identify the start, ack and stop bits. Can anyone identify these elements just looking at the figure?

Enter image description here Enter image description here

[Edited] Some people asked me about the devices that are in the communication. The communication is between a car key and a tool that I'm not allowed to say, but I'm trying to do a reverse engineering on it.

  • 1
    You have the start condition at the leftmost red (SDA) edge. It goes low while inverted blue (–SCL) is held low. After that, changes to red (SDA) seem to occur only when the inverted blue (–SCL) is high. That's valid I²C talk. – Janka Sep 28 at 17:40
  • 2
    @Janka, that's only valid I2C talk if you assume that SCL is inverted. There's no reason to assume that. – Annie Sep 28 at 18:06
  • 2
    @Janka, the OP listed that as an assumption. That assumption is based on the assumption that this is I2C. There are several reasons to believe this is not I2C--one of them being that the clock is idle low. – Annie Sep 28 at 18:14
  • 5
    @Daniel, would you be able to tell us what the two devices are? – Annie Sep 28 at 18:39
  • 2
    Perhaps instead of worrying about "what it is" you should think about "what it says". Figure out which edge(s) you need to sample. Get a logic analyzer, probably the streaming USB kind, and start writing a decoder which captures the scope of variability. Then start seeking patterns in the data. – Chris Stratton Oct 1 at 15:32

Given that there are only 8 clocks per byte (I2C requires a 9th clock for the ACK/NAK bit) and the clock idle state seems to be low, I would say that this is more likely a SPI (or SPI-like) interface.

Not sure about the extra clock width on the first bit of each byte, however.

  • 1
    On the other hand, that narrow pulse at the end of clock sequence looks a lot like NACK. Also what looks like idle low could be clock stretching, which is no longer allowed by spec but could be used by old slaves. The initial state on pictures (1) and (2) is actually high – Maple Sep 28 at 18:21
  • 1
    @Maple: I see your narrow data pulse, but I still fail to see the 9th clock pulse. The data pattern is perfectly consistent with certain SPI configurations of clock phase and clock polarity. – Dave Tweed Sep 28 at 18:23
  • 1
    That is true, I actually agree with you re clock. What is strange to me is inconsistent SDI/SDO (whatever it is) idle behavior at the ends of (1) – Maple Sep 28 at 18:30
  • 1
    @Maple Wouldn't I2C release the lines to idle high? – Selvek Sep 28 at 23:03
  • 1
    @Selvek Yes, and that is exactly what I see on picture (1) and beginning of picture (2). The rest of it, however, more consistent with SPI, as Dave pointed out. Well, aside from surprising first clock that looks like start bit. Hmm... start bit... could this be... – Maple Sep 28 at 23:54

My guess is that it's some company's homegrown "I2C-like" protocol. There were some of those back in the day when using I2C meant having to give money to Philips.

It appears to have an ACK (the short pulse on the data line prior to the clock stretch looks a lot like the data line getting passed from master to slave).

Oddly, it appears to transmit 7 bits at a time.

  • 1
    If it is proprietary version of the protocol it might use 7 or less bit communication just as well – Maple Sep 28 at 20:14
  • 6
    @Maple Yeah. I can picture an engineer saying, "How do we make this like I2C but just enough different that we don't have to pay royalties? Invert the clock and send 7 bits at a time." But I can only guess. – Annie Sep 28 at 20:28

I'll toss my hat into the ring...

If these are old devices you could be looking at some "bare minimum" 7-bit synchronous RS-232 variant:

  • That longer pulse in the beginning of each frame could be a start bit, and

  • The plateau in the clock signal at the very beginning could be return to 0 before going to negative "mark". (You did not provide voltage on screenshots, so I am guessing here).

  • 1
    Oooh, this is new to me. Does it have any ack? (Couldn't find one in my very brief Google search). If not, anything else that would explain the short pulse on the data line after the 8th clk? – Annie Sep 29 at 0:50
  • 1
    Not that I know of. And in any case, if this is indeed an old-fashioned serial, any communication in other direction would require separate wires. That pulse is too short to be anything significant. Most likely the driver resetting itself before next frame. All this is guessing, as you said yourself. Unless OP provides more details on the devices this is all we can do. – Maple Sep 29 at 1:05
  • @Maple , the communication is between a car key and a tool that I'm not allowed to say, but I'm trying to do reverse engineering on it. – Daniel Oct 1 at 12:58
  • RS232 is a standard for electrical levels, not for encoding data words – Chris Stratton Oct 1 at 15:30
  • @ChrisStratton Where did you find anything about encoding in my answer? All I am saying is that if the voltage levels correspond to RS232 and signals resemble synchronous serial then it most likely is not I2C – Maple Oct 1 at 15:52

According to my experience with I2C, I can use multi-meter device to check the clock by setting the device to measure the frequency (in hertz), so if it reads a steady value like 2k then it is I2C clock.

  • 2
    No, that's not a valid conclusion at all. Many things that are not I2C have steady clocks. In fact, I2C does not have a steady clock, but rather a bursty one. If your meter is counting over a period of time, it's actually going to be averaging active clocking with idle interludes - you'd need to measure the reciprocal of the width of a pulse, ideally on a scope where you can be sure that you are actually measuring what is intended. In contrast, some other schemes like I2S tend to have continuously running clocks. But clock frequency can only rule something out, not in. – Chris Stratton Oct 1 at 15:28

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.