Hi all, issues with I2C. For testing purposes I am trying to just get sensible accelerometer data from a MPU6050. Four wire connection. A5, A4, +5v and Gnd. Can anyone throw any light on why this code yields perfectly sensible data on the R3 and nonsense on the R4?
#include<Wire.h>
const int camIMU = 0x68;
float roll, pitch;
float timeStamp;
void setup() {
Wire.begin(); //Initialize
Wire.beginTransmission(camIMU); //Start communication
Wire.write(0x6B); //Talk to the register 6B
Wire.write(0); //Make the reset (place a 0 into the 6B register)
Wire.endTransmission(true); //End the transmission
Serial.begin(115200);
Serial.println("Ready");
Wait(1000);
}
void loop() {
timeStamp = micros();
getRoll();
Serial.print(roll);
Serial.print(" ");
Serial.println(pitch);
Wait(200);
// Serial.println(micros() - timeStamp);
}
void getRoll() {
float aX, aY, aZ;
Wire.beginTransmission(camIMU); //read the sensor data
Wire.write(0x3B);
Wire.endTransmission(false);
Wire.requestFrom(camIMU, 6, true); //get six bytes accelerometer data
aX = Wire.read() << 8 | Wire.read();
aY = Wire.read() << 8 | Wire.read();
aZ = Wire.read() << 8 | Wire.read();
roll = atan2(aY , aZ) * 180.0 / PI;
pitch = atan2(-aX , sqrt(aY * aY + aZ * aZ)) * 180.0 / PI;
}
void Wait(int gap){
unsigned long markMillis = millis();
while (millis() < markMillis + gap) {}
}
It might relate to a difference in physical implementation that's not shown in your post.
I.e. please show:
a schematic diagram of both setups
Photos that show the actual wiring on both setups
Furthermore, can you please be more specific on what 'nonsense' constitutes? What output does the sketch produce on the R3? What's the output that you get on the R4?
As this relates to an I2C issue, part of the troubleshooting process is generally to run an I2C detection sketch to see if the I2C device is indeed recognized correctly. Have you confirmed that this happens on the R4 board as well?
The first batch is while the 6050 is level and then the other two are with it tilted (approximately) 30 degrees one way then the other. Note not only the weird values but also the wild fluctuations.
Maybe this is a little risky w.r.t. how the compiler optimizes this code. How about breaking it down so that you know for sure that both read()'s are done in the order you want them to be done.
I did not test this snippet; it's just offered to illustrate what I mean by 'breaking it down'. Note that the code is formulated in a bit of a 'pedantic'/'for dummies' kind of way, which in part will definitely be unnecessary, but as you'll understand this is done to enforce a predictable order of execution.
As before, please show how they're different. It's impossible for others to spot a possible pattern if the observations are missing.
Also, it may help to make your sketch display the raw data before converting to float. Any bit-wise corruptions would be easier to spot this way. I'd make it print both the hex (or dec) values and bin values to Serial.
Do you have a different I2C device that you can test with the R4 board? Doesn't matter much which it is; just something that allows you to pull some data from it so you can see if anything gets corrupted.
Have you tried adding pullups (e.g. 3k3 or 4k7) to the I2C lines? It's possible that the R3 board juuuust works with the available pullups on your sensor board, but that the R4 struggles. Keep in mind it's a different type of controller and differences in robustness of I2C performance under marginal conditions can be expected.
You're overlooking the possibility that there's a pattern that you're overlooking but someone else does recognize. For instance, I do see the start of a pattern in the data you've already posted, but the lack of good data to work with precludes from following that trail.
The whole point of asking others for help is that they may be able to make more of the information available to you than you yourself are.
I accept that criticism however in order to discern anything one really needs quite a lot of data. Not the tiny fragments I posted. Let me try those other two possibilities and if they fail I will log a decent amount of data and send it as a file.
Right at the moment it is month end and if I don't get a tax return in they are going to carry me off in chains so I will revert as soon as I can. Hopefully tomorrow.
A small dataset is better than no dataset. What you posted before is already quite nice, but it would be nicer to have the integer values. If you included the same amount of data for the code variations you tried (see #10), I think it should be possible to spot a pattern if there's any obvious pattern going on. No need to go overboard with hundreds of tuples per set.
Be careful, the I2C on the Qwiic connector is 3.3v, do not connect to a 5v device.
It should return either the number of bytes requested, or (if I recall correctly) zero if there was an error communicating with the device. The requested number of bytes is read in, regardless of how many are actually sent.
