Mixing
Is this communication I2C?
Clash Royale CLAN TAG#URR8PPP
up vote
3
down vote
favorite
I need to decode a 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 an i2c 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 i2c communication appropriately when I visually check the waveforms.
 Looking at the waveforms I made the following assumptions, 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, it seems to be
 Are my assumptions correct?
 In the last figure, the figure with the number 5 indicated in a circle, 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?
i2c communication
asked 1 hour ago
Daniel
1268
 |Â
show 1 more comment
up vote
3
down vote
favorite
I need to decode a 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 an i2c 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 i2c communication appropriately when I visually check the waveforms.
 Looking at the waveforms I made the following assumptions, 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, it seems to be
 Are my assumptions correct?
 In the last figure, the figure with the number 5 indicated in a circle, 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?
i2c communication
asked 1 hour ago
Daniel
1268
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
1 hour ago
@Janka, that's only valid I2C talk if you assume that SCL is inverted. There's no reason to assume that.
– Annie
46 mins ago
The OP wrote exactly that.
– Janka
45 mins ago
@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
38 mins ago
1
@Daniel, would you be able to tell us what the two devices are?
– Annie
13 mins ago
 |Â
show 1 more comment
up vote
3
down vote
favorite
up vote
3
down vote
favorite
I need to decode a 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 an i2c 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 i2c communication appropriately when I visually check the waveforms.
 Looking at the waveforms I made the following assumptions, 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, it seems to be
 Are my assumptions correct?
 In the last figure, the figure with the number 5 indicated in a circle, 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?
i2c communication
asked 1 hour ago
Daniel
1268
I need to decode a 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 an i2c 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 i2c communication appropriately when I visually check the waveforms.
 Looking at the waveforms I made the following assumptions, 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, it seems to be
 Are my assumptions correct?
 In the last figure, the figure with the number 5 indicated in a circle, 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?
i2c communication
i2c communication
asked 1 hour ago
Daniel
1268
asked 1 hour ago
Daniel
1268
asked 1 hour ago
Daniel
1268
asked 1 hour ago
Daniel
1268
asked 1 hour ago
Daniel
1268
1268
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
1 hour ago
@Janka, that's only valid I2C talk if you assume that SCL is inverted. There's no reason to assume that.
– Annie
46 mins ago
The OP wrote exactly that.
– Janka
45 mins ago
@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
38 mins ago
1
@Daniel, would you be able to tell us what the two devices are?
– Annie
13 mins ago
 |Â
show 1 more comment
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
1 hour ago
@Janka, that's only valid I2C talk if you assume that SCL is inverted. There's no reason to assume that.
– Annie
46 mins ago
The OP wrote exactly that.
– Janka
45 mins ago
@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
38 mins ago
1
@Daniel, would you be able to tell us what the two devices are?
– Annie
13 mins ago
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
1 hour ago
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
1 hour ago
@Janka, that's only valid I2C talk if you assume that SCL is inverted. There's no reason to assume that.
– Annie
46 mins ago
@Janka, that's only valid I2C talk if you assume that SCL is inverted. There's no reason to assume that.
– Annie
46 mins ago
The OP wrote exactly that.
– Janka
45 mins ago
The OP wrote exactly that.
– Janka
45 mins ago
@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
38 mins ago
@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
38 mins ago
1
1
@Daniel, would you be able to tell us what the two devices are?
– Annie
13 mins ago
@Daniel, would you be able to tell us what the two devices are?
– Annie
13 mins ago
 |Â
show 1 more comment
2 Answers
2
active
oldest
votes
up vote
3
down vote
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.
answered 58 mins ago
Dave Tweed♦
110k9132236
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
31 mins ago
@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♦
29 mins ago
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
21 mins ago
add a comment |Â
up vote
1
down vote
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.
answered 19 mins ago
Annie
2998
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
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.
answered 58 mins ago
Dave Tweed♦
110k9132236
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
31 mins ago
@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♦
29 mins ago
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
21 mins ago
add a comment |Â
up vote
3
down vote
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.
answered 58 mins ago
Dave Tweed♦
110k9132236
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
31 mins ago
@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♦
29 mins ago
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
21 mins ago
add a comment |Â
up vote
3
down vote
up vote
3
down vote
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.
answered 58 mins ago
Dave Tweed♦
110k9132236
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.
answered 58 mins ago
Dave Tweed♦
110k9132236
answered 58 mins ago
Dave Tweed♦
110k9132236
answered 58 mins ago
Dave Tweed♦
110k9132236
answered 58 mins ago
Dave Tweed♦
110k9132236
110k9132236
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
31 mins ago
@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♦
29 mins ago
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
21 mins ago
add a comment |Â
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
31 mins ago
@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♦
29 mins ago
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
21 mins ago
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
31 mins ago
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
31 mins ago
@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♦
29 mins ago
@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♦
29 mins ago
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
21 mins ago
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
21 mins ago
add a comment |Â
up vote
1
down vote
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.
answered 19 mins ago
Annie
2998
add a comment |Â
up vote
1
down vote
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.
answered 19 mins ago
Annie
2998
add a comment |Â
up vote
1
down vote
up vote
1
down vote
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.
answered 19 mins ago
Annie
2998
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.
answered 19 mins ago
Annie
2998
answered 19 mins ago
Annie
2998
answered 19 mins ago
Annie
2998
answered 19 mins ago
Annie
2998
2998
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f398441%2fis-this-communication-i2c%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
1 hour ago
@Janka, that's only valid I2C talk if you assume that SCL is inverted. There's no reason to assume that.
– Annie
46 mins ago
The OP wrote exactly that.
– Janka
45 mins ago
@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
38 mins ago
1
@Daniel, would you be able to tell us what the two devices are?
– Annie
13 mins ago