kriswiner / MPU9250

Arduino sketches for MPU9250 9DoF with AHRS sensor fusion
1.03k stars 469 forks source link

Random values from accelerometer #148

Open tim77777 opened 7 years ago

tim77777 commented 7 years ago

Hi, I am wondering about intermittent random values I am getting from the MPU9250 accelerometer. The output always jumps around a little as expected, proportional to the bandwidth that I set. But I also get random high and low values anywhere from -10000's to +10000's. Perhaps there is a clue in the fact that there is often -256 (100000000)and +255 (011111111), also it is much worse on the X axis, though it does happen on all axes. This is my own implementation on a microchip part. I have tried slowing I2C, and inserting delays here and there, but it doesn't make any difference.

There has very very rarely been a random value from the Gyro, but the accelerometer, particularly the X axis (which is read first) spits regularly.

I have tried reading only the single low byte from the X axis and the random values are sometimes well about 255, which would not be possible from an 8 bit value, so I guess the problem is in my I2C routine or maybe even hardware related.

accele_bytes[0] = I2C_read_reg(MPU_ADDRESS, ACCEL_XOUT_L);

char I2C_read_reg(char cntl_add, char value) { char reg_value = 0;

    I2CStart();      
    I2CSend(cntl_add); // prepare to be read //D0
    I2CSend(value); // register to be read; 
    I2CRestart();
    I2CSend(cntl_add + 1); //read from previously sent register address  
    reg_value = I2CRead();
    I2CStop();

    return reg_value;

}

Any help would be appreciated.

kriswiner commented 7 years ago

Which MCU are you using?

I don't quite understand you readBytes function. Are you trying to read just two bytes?

Where are you composing the two bytes into an int16_t signed interger? i suspect the latter is your problem.

This is what I use for I2C:

// I2C read/write functions for the BMP280 sensors

void writeByte(uint8_t address, uint8_t subAddress, uint8_t data) { Wire.beginTransmission(address); // Initialize the Tx buffer Wire.write(subAddress); // Put slave register address in Tx buffer Wire.write(data); // Put data in Tx buffer Wire.endTransmission(); // Send the Tx buffer }

uint8_t readByte(uint8_t address, uint8_t subAddress) { uint8_t data; // data will store the register data Wire.beginTransmission(address); // Initialize the Tx buffer Wire.write(subAddress); // Put slave register address in Tx buffer Wire.endTransmission(false); // Send the Tx buffer, but send a restart to keep connection alive Wire.requestFrom(address, 1); // Read one byte from slave register address data = Wire.read(); // Fill Rx buffer with result return data; // Return data read from slave register }

void readBytes(uint8_t address, uint8_t subAddress, uint8_t count, uint8_t

  • dest) { Wire.beginTransmission(address); // Initialize the Tx buffer Wire.write(subAddress); // Put slave register address in Tx buffer Wire.endTransmission(false); // Send the Tx buffer, but send a restart to keep connection alive uint8_t i = 0; Wire.requestFrom(address, count); // Read bytes from slave register address while (Wire.available()) { dest[i++] = Wire.read(); } // Put read results in the Rx buffer

}

On Wed, May 17, 2017 at 2:10 PM, tim77777 notifications@github.com wrote:

Hi, I am wondering about intermittent random values I am getting from the MPU9250 accelerometer. The output always jumps around a little as expected, proportional to the bandwidth that I set. But I also get random high and low values anywhere from -10000's to +10000's. Perhaps there is a clue in the fact that there is often -256 (100000000)and +255 (011111111), also it is much worse on the X axis, though it does happen on all axes. This is my own implementation on a microchip part. I have tried slowing I2C, and inserting delays here and there, but it doesn't make any difference.

There has very very rarely been a random value from the Gyro, but the accelerometer, particularly the X axis (which is read first) spits regularly.

I have tried reading only the single low byte from the X axis and the random values are sometimes well about 255, which would not be possible from an 8 bit value, so I guess the problem is in my I2C routine or maybe even hardware related.

accele_bytes[0] = I2C_read_reg(MPU_ADDRESS, ACCEL_XOUT_L);

char I2C_read_reg(char cntl_add, char value) { char reg_value = 0;

I2CStart();
I2CSend(cntl_add); // prepare to be read //D0
I2CSend(value); // register to be read;
I2CRestart();
I2CSend(cntl_add + 1); //read from previously sent register address
reg_value = I2CRead();
I2CStop();

return reg_value;

}

Any help would be appreciated.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/148, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qtbs_c1EuT8sF0uT1NFNF7MCHXqpks5r62JCgaJpZM4NecXm .

tim77777 commented 7 years ago

Hi,

Using a PIC1618325

My I2C routine sends the device address, then the register address, then reads the single byte of data at that address.

In trying to working out the problem, I had cut my code down so that only the lower byte of the X axis was being read. And I get good data, with occasional spits of high and low values.

And that is the problem. I say “spit” because it is like a clean flow of water with occasional spits of water coming out of that clean flow, at different heights.

However, your comments spurred me to have another look and it seems I was dealing with two problems as I am transmitting the data via RF to another system, and something in that system is spitting high values. Now, I have taken the RF out of the equation, and I am reading the data directly on the system housing the MPU9250, here is what I am experiencing, perhaps it is normal.

Filtering anywhere quicker than10.2Hz, produces a regular spit of random data with the highest being +255 (11111111) and the lowest being -256 (100000000).

I combine the low and high data bytes like so

raw_acc_x = (int)((highByte << 8) | lowByte);

From: Kris Winer [mailto:notifications@github.com] Sent: Thursday, May 18, 2017 7:50 AM To: kriswiner/MPU9250 Cc: tim77777; Author Subject: Re: [kriswiner/MPU9250] Random values from accelerometer (#148)

Which MCU are you using?

I don't quite understand you readBytes function. Are you trying to read just two bytes?

Where are you composing the two bytes into an int16_t signed interger? i suspect the latter is your problem.

This is what I use for I2C:

// I2C read/write functions for the BMP280 sensors

void writeByte(uint8_t address, uint8_t subAddress, uint8_t data) { Wire.beginTransmission(address); // Initialize the Tx buffer Wire.write(subAddress); // Put slave register address in Tx buffer Wire.write(data); // Put data in Tx buffer Wire.endTransmission(); // Send the Tx buffer }

uint8_t readByte(uint8_t address, uint8_t subAddress) { uint8_t data; // data will store the register data Wire.beginTransmission(address); // Initialize the Tx buffer Wire.write(subAddress); // Put slave register address in Tx buffer Wire.endTransmission(false); // Send the Tx buffer, but send a restart to keep connection alive Wire.requestFrom(address, 1); // Read one byte from slave register address data = Wire.read(); // Fill Rx buffer with result return data; // Return data read from slave register }

void readBytes(uint8_t address, uint8_t subAddress, uint8_t count, uint8_t

  • dest) { Wire.beginTransmission(address); // Initialize the Tx buffer Wire.write(subAddress); // Put slave register address in Tx buffer Wire.endTransmission(false); // Send the Tx buffer, but send a restart to keep connection alive uint8_t i = 0; Wire.requestFrom(address, count); // Read bytes from slave register address while (Wire.available()) { dest[i++] = Wire.read(); } // Put read results in the Rx buffer

}

On Wed, May 17, 2017 at 2:10 PM, tim77777 notifications@github.com wrote:

Hi, I am wondering about intermittent random values I am getting from the MPU9250 accelerometer. The output always jumps around a little as expected, proportional to the bandwidth that I set. But I also get random high and low values anywhere from -10000's to +10000's. Perhaps there is a clue in the fact that there is often -256 (100000000)and +255 (011111111), also it is much worse on the X axis, though it does happen on all axes. This is my own implementation on a microchip part. I have tried slowing I2C, and inserting delays here and there, but it doesn't make any difference.

There has very very rarely been a random value from the Gyro, but the accelerometer, particularly the X axis (which is read first) spits regularly.

I have tried reading only the single low byte from the X axis and the random values are sometimes well about 255, which would not be possible from an 8 bit value, so I guess the problem is in my I2C routine or maybe even hardware related.

accele_bytes[0] = I2C_read_reg(MPU_ADDRESS, ACCEL_XOUT_L);

char I2C_read_reg(char cntl_add, char value) { char reg_value = 0;

I2CStart(); I2CSend(cntl_add); // prepare to be read //D0 I2CSend(value); // register to be read; I2CRestart(); I2CSend(cntl_add + 1); //read from previously sent register address reg_value = I2CRead(); I2CStop();

return reg_value;

}

Any help would be appreciated.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/148, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qtbs_c1EuT8sF0uT1NFNF7MCHXqpks5r62JCgaJpZM4NecXm .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302241696 , or mute the thread https://github.com/notifications/unsubscribe-auth/AXcUIYARa_PfRINKri1jTvfu4OzLb9Euks5r62uZgaJpZM4NecXm .Image removed by sender.

kriswiner commented 7 years ago

int is ambiguous and might or might not work on your system, I have never used a PIC before. I would recommned, even if not necessary:

int16_t raw_acc_x = (int16_t) (((int16_t) highByte << 8) | lowByte);

It's unusual to see 255 and -255, not impossible, but this is what you might expect if the connection is temporarily lost. Check your connections. Can you read any other I2C sensor using this I2C function call and get reasonable data?

On Wed, May 17, 2017 at 5:08 PM, tim77777 notifications@github.com wrote:

Hi,

Using a PIC1618325

My I2C routine sends the device address, then the register address, then reads the single byte of data at that address.

In trying to working out the problem, I had cut my code down so that only the lower byte of the X axis was being read. And I get good data, with occasional spits of high and low values.

And that is the problem. I say “spit” because it is like a clean flow of water with occasional spits of water coming out of that clean flow, at different heights.

However, your comments spurred me to have another look and it seems I was dealing with two problems as I am transmitting the data via RF to another system, and something in that system is spitting high values. Now, I have taken the RF out of the equation, and I am reading the data directly on the system housing the MPU9250, here is what I am experiencing, perhaps it is normal.

Filtering anywhere quicker than10.2Hz, produces a regular spit of random data with the highest being +255 (11111111) and the lowest being -256 (100000000).

I combine the low and high data bytes like so

raw_acc_x = (int)((highByte << 8) | lowByte);

From: Kris Winer [mailto:notifications@github.com] Sent: Thursday, May 18, 2017 7:50 AM To: kriswiner/MPU9250 Cc: tim77777; Author Subject: Re: [kriswiner/MPU9250] Random values from accelerometer (#148)

Which MCU are you using?

I don't quite understand you readBytes function. Are you trying to read just two bytes?

Where are you composing the two bytes into an int16_t signed interger? i suspect the latter is your problem.

This is what I use for I2C:

// I2C read/write functions for the BMP280 sensors

void writeByte(uint8_t address, uint8_t subAddress, uint8_t data) { Wire.beginTransmission(address); // Initialize the Tx buffer Wire.write(subAddress); // Put slave register address in Tx buffer Wire.write(data); // Put data in Tx buffer Wire.endTransmission(); // Send the Tx buffer }

uint8_t readByte(uint8_t address, uint8_t subAddress) { uint8_t data; // data will store the register data Wire.beginTransmission(address); // Initialize the Tx buffer Wire.write(subAddress); // Put slave register address in Tx buffer Wire.endTransmission(false); // Send the Tx buffer, but send a restart to keep connection alive Wire.requestFrom(address, 1); // Read one byte from slave register address data = Wire.read(); // Fill Rx buffer with result return data; // Return data read from slave register }

void readBytes(uint8_t address, uint8_t subAddress, uint8_t count, uint8_t

  • dest) { Wire.beginTransmission(address); // Initialize the Tx buffer Wire.write(subAddress); // Put slave register address in Tx buffer Wire.endTransmission(false); // Send the Tx buffer, but send a restart to keep connection alive uint8_t i = 0; Wire.requestFrom(address, count); // Read bytes from slave register address while (Wire.available()) { dest[i++] = Wire.read(); } // Put read results in the Rx buffer

}

On Wed, May 17, 2017 at 2:10 PM, tim77777 notifications@github.com wrote:

Hi, I am wondering about intermittent random values I am getting from the MPU9250 accelerometer. The output always jumps around a little as expected, proportional to the bandwidth that I set. But I also get random high and low values anywhere from -10000's to +10000's. Perhaps there is a clue in the fact that there is often -256 (100000000)and +255 (011111111), also it is much worse on the X axis, though it does happen on all axes. This is my own implementation on a microchip part. I have tried slowing I2C, and inserting delays here and there, but it doesn't make any difference.

There has very very rarely been a random value from the Gyro, but the accelerometer, particularly the X axis (which is read first) spits regularly.

I have tried reading only the single low byte from the X axis and the random values are sometimes well about 255, which would not be possible from an 8 bit value, so I guess the problem is in my I2C routine or maybe even hardware related.

accele_bytes[0] = I2C_read_reg(MPU_ADDRESS, ACCEL_XOUT_L);

char I2C_read_reg(char cntl_add, char value) { char reg_value = 0;

I2CStart(); I2CSend(cntl_add); // prepare to be read //D0 I2CSend(value); // register to be read; I2CRestart(); I2CSend(cntl_add + 1); //read from previously sent register address reg_value = I2CRead(); I2CStop();

return reg_value;

}

Any help would be appreciated.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/148, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qtbs_ c1EuT8sF0uT1NFNF7MCHXqpks5r62JCgaJpZM4NecXm .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302241696> , or mute the thread https://github.com/notifications/unsubscribe- auth/AXcUIYARa_PfRINKri1jTvfu4OzLb9Euks5r62uZgaJpZM4NecXm .Image removed by sender.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302264594, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1quD9TR0TYkUYN-zaQFYmABL4IcmEks5r64vigaJpZM4NecXm .

tim77777 commented 7 years ago

I see. Thanks. I’ve looked into it further. This is complicated, so strap yourself in J

I guess it is the I2C functions or maybe the way I am reading the MPU9250.

On closer examination I have found that it is when acceleration is close to zero on any axis, is when the issue is most noticeable.

This is because it is jumping about up and down 3 or 4 bits, as expected with no filtering, and so it is crossing between positive and negative acceleration regularly.

This mean the sensor is outputting something like +1, + 3, -9, +5, - 6, -2, +7 etc

Being two complement the binary equivalents are something like 00000000 00000001, 00000000 00000011, 11111111 11110111, 00000000 00000101 etc

So it seems that somewhere along the way the upper and lower bytes are sometimes being mixed up, and so I am getting regular highs and lows of

+255 and -256

00000000 11111111, 11111111 00000000

On close examination I can see this is happening on all accelerometer axes and all gyro outputs, and it is also happening all through the scale not just at close to zero acceleration position.

It’s just not as obvious at other positions because the lower / upper byte difference is not so great.

Also it is worst with no filtering, and non-existent with maximum filtering because the output is not jumping around much and hence is not crossing between positive and negative acceleration.

I’ve looked into the I2C routine and it seems good, but I’ll keep looking into it.

I have minimized things with the MPU9250 so only the high byte and then the low byte of the X axis are being read, then that is shifted into an integer, over and over again. No other sensor outputs are being read, the FIFO is not enabled, and no calibration has been done. It is at 16G but does the same thing at 2G.

Do you have any ideas about things I might be able to experiment with to zero in on the issue.

Regards

Tim.

From: Kris Winer [mailto:notifications@github.com] Sent: Thursday, May 18, 2017 10:14 AM To: kriswiner/MPU9250 Cc: tim77777; Author Subject: Re: [kriswiner/MPU9250] Random values from accelerometer (#148)

int is ambiguous and might or might not work on your system, I have never used a PIC before. I would recommned, even if not necessary:

int16_t raw_acc_x = (int16_t) (((int16_t) highByte << 8) | lowByte);

It's unusual to see 255 and -255, not impossible, but this is what you might expect if the connection is temporarily lost. Check your connections. Can you read any other I2C sensor using this I2C function call and get reasonable data?

On Wed, May 17, 2017 at 5:08 PM, tim77777 notifications@github.com wrote:

Hi,

Using a PIC1618325

My I2C routine sends the device address, then the register address, then reads the single byte of data at that address.

In trying to working out the problem, I had cut my code down so that only the lower byte of the X axis was being read. And I get good data, with occasional spits of high and low values.

And that is the problem. I say “spit” because it is like a clean flow of water with occasional spits of water coming out of that clean flow, at different heights.

However, your comments spurred me to have another look and it seems I was dealing with two problems as I am transmitting the data via RF to another system, and something in that system is spitting high values. Now, I have taken the RF out of the equation, and I am reading the data directly on the system housing the MPU9250, here is what I am experiencing, perhaps it is normal.

Filtering anywhere quicker than10.2Hz, produces a regular spit of random data with the highest being +255 (11111111) and the lowest being -256 (100000000).

I combine the low and high data bytes like so

raw_acc_x = (int)((highByte << 8) | lowByte);

From: Kris Winer [mailto:notifications@github.com] Sent: Thursday, May 18, 2017 7:50 AM To: kriswiner/MPU9250 Cc: tim77777; Author Subject: Re: [kriswiner/MPU9250] Random values from accelerometer (#148)

Which MCU are you using?

I don't quite understand you readBytes function. Are you trying to read just two bytes?

Where are you composing the two bytes into an int16_t signed interger? i suspect the latter is your problem.

This is what I use for I2C:

// I2C read/write functions for the BMP280 sensors

void writeByte(uint8_t address, uint8_t subAddress, uint8_t data) { Wire.beginTransmission(address); // Initialize the Tx buffer Wire.write(subAddress); // Put slave register address in Tx buffer Wire.write(data); // Put data in Tx buffer Wire.endTransmission(); // Send the Tx buffer }

uint8_t readByte(uint8_t address, uint8_t subAddress) { uint8_t data; // data will store the register data Wire.beginTransmission(address); // Initialize the Tx buffer Wire.write(subAddress); // Put slave register address in Tx buffer Wire.endTransmission(false); // Send the Tx buffer, but send a restart to keep connection alive Wire.requestFrom(address, 1); // Read one byte from slave register address data = Wire.read(); // Fill Rx buffer with result return data; // Return data read from slave register }

void readBytes(uint8_t address, uint8_t subAddress, uint8_t count, uint8_t

  • dest) { Wire.beginTransmission(address); // Initialize the Tx buffer Wire.write(subAddress); // Put slave register address in Tx buffer Wire.endTransmission(false); // Send the Tx buffer, but send a restart to keep connection alive uint8_t i = 0; Wire.requestFrom(address, count); // Read bytes from slave register address while (Wire.available()) { dest[i++] = Wire.read(); } // Put read results in the Rx buffer

}

On Wed, May 17, 2017 at 2:10 PM, tim77777 notifications@github.com wrote:

Hi, I am wondering about intermittent random values I am getting from the MPU9250 accelerometer. The output always jumps around a little as expected, proportional to the bandwidth that I set. But I also get random high and low values anywhere from -10000's to +10000's. Perhaps there is a clue in the fact that there is often -256 (100000000)and +255 (011111111), also it is much worse on the X axis, though it does happen on all axes. This is my own implementation on a microchip part. I have tried slowing I2C, and inserting delays here and there, but it doesn't make any difference.

There has very very rarely been a random value from the Gyro, but the accelerometer, particularly the X axis (which is read first) spits regularly.

I have tried reading only the single low byte from the X axis and the random values are sometimes well about 255, which would not be possible from an 8 bit value, so I guess the problem is in my I2C routine or maybe even hardware related.

accele_bytes[0] = I2C_read_reg(MPU_ADDRESS, ACCEL_XOUT_L);

char I2C_read_reg(char cntl_add, char value) { char reg_value = 0;

I2CStart(); I2CSend(cntl_add); // prepare to be read //D0 I2CSend(value); // register to be read; I2CRestart(); I2CSend(cntl_add + 1); //read from previously sent register address reg_value = I2CRead(); I2CStop();

return reg_value;

}

Any help would be appreciated.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/148, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qtbs_ c1EuT8sF0uT1NFNF7MCHXqpks5r62JCgaJpZM4NecXm .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302241696> , or mute the thread https://github.com/notifications/unsubscribe- auth/AXcUIYARa_PfRINKri1jTvfu4OzLb9Euks5r62uZgaJpZM4NecXm .Image removed by sender.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302264594, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1quD9TR0TYkUYN-zaQFYmABL4IcmEks5r64vigaJpZM4NecXm .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302265459 , or mute the thread https://github.com/notifications/unsubscribe-auth/AXcUIdV-xl2-dnzpMi_XEd41kxHdZdzGks5r641cgaJpZM4NecXm .Description: Image removed by sender.

kriswiner commented 7 years ago

I have never seen anything like this. I would recommend that you read all accel and gyro data at once with a burst read. You might be reading individual bytes from different data samples and causing the strange results. But don't know.

On Fri, May 19, 2017 at 4:56 AM, tim77777 notifications@github.com wrote:

I see. Thanks. I’ve looked into it further. This is complicated, so strap yourself in J

I guess it is the I2C functions or maybe the way I am reading the MPU9250.

On closer examination I have found that it is when acceleration is close to zero on any axis, is when the issue is most noticeable.

This is because it is jumping about up and down 3 or 4 bits, as expected with no filtering, and so it is crossing between positive and negative acceleration regularly.

This mean the sensor is outputting something like +1, + 3, -9, +5, - 6, -2, +7 etc

Being two complement the binary equivalents are something like 00000000 00000001, 00000000 00000011, 11111111 11110111, 00000000 00000101 etc

So it seems that somewhere along the way the upper and lower bytes are sometimes being mixed up, and so I am getting regular highs and lows of

+255 and -256

00000000 11111111, 11111111 00000000

On close examination I can see this is happening on all accelerometer axes and all gyro outputs, and it is also happening all through the scale not just at close to zero acceleration position.

It’s just not as obvious at other positions because the lower / upper byte difference is not so great.

Also it is worst with no filtering, and non-existent with maximum filtering because the output is not jumping around much and hence is not crossing between positive and negative acceleration.

I’ve looked into the I2C routine and it seems good, but I’ll keep looking into it.

I have minimized things with the MPU9250 so only the high byte and then the low byte of the X axis are being read, then that is shifted into an integer, over and over again. No other sensor outputs are being read, the FIFO is not enabled, and no calibration has been done. It is at 16G but does the same thing at 2G.

Do you have any ideas about things I might be able to experiment with to zero in on the issue.

Regards

Tim.

From: Kris Winer [mailto:notifications@github.com] Sent: Thursday, May 18, 2017 10:14 AM

To: kriswiner/MPU9250 Cc: tim77777; Author Subject: Re: [kriswiner/MPU9250] Random values from accelerometer (#148)

int is ambiguous and might or might not work on your system, I have never used a PIC before. I would recommned, even if not necessary:

int16_t raw_acc_x = (int16_t) (((int16_t) highByte << 8) | lowByte);

It's unusual to see 255 and -255, not impossible, but this is what you might expect if the connection is temporarily lost. Check your connections. Can you read any other I2C sensor using this I2C function call and get reasonable data?

On Wed, May 17, 2017 at 5:08 PM, tim77777 notifications@github.com wrote:

Hi,

Using a PIC1618325

My I2C routine sends the device address, then the register address, then reads the single byte of data at that address.

In trying to working out the problem, I had cut my code down so that only the lower byte of the X axis was being read. And I get good data, with occasional spits of high and low values.

And that is the problem. I say “spit” because it is like a clean flow of water with occasional spits of water coming out of that clean flow, at different heights.

However, your comments spurred me to have another look and it seems I was dealing with two problems as I am transmitting the data via RF to another system, and something in that system is spitting high values. Now, I have taken the RF out of the equation, and I am reading the data directly on the system housing the MPU9250, here is what I am experiencing, perhaps it is normal.

Filtering anywhere quicker than10.2Hz, produces a regular spit of random data with the highest being +255 (11111111) and the lowest being -256 (100000000).

I combine the low and high data bytes like so

raw_acc_x = (int)((highByte << 8) | lowByte);

From: Kris Winer [mailto:notifications@github.com] Sent: Thursday, May 18, 2017 7:50 AM To: kriswiner/MPU9250 Cc: tim77777; Author Subject: Re: [kriswiner/MPU9250] Random values from accelerometer (#148)

Which MCU are you using?

I don't quite understand you readBytes function. Are you trying to read just two bytes?

Where are you composing the two bytes into an int16_t signed interger? i suspect the latter is your problem.

This is what I use for I2C:

// I2C read/write functions for the BMP280 sensors

void writeByte(uint8_t address, uint8_t subAddress, uint8_t data) { Wire.beginTransmission(address); // Initialize the Tx buffer Wire.write(subAddress); // Put slave register address in Tx buffer Wire.write(data); // Put data in Tx buffer Wire.endTransmission(); // Send the Tx buffer }

uint8_t readByte(uint8_t address, uint8_t subAddress) { uint8_t data; // data will store the register data Wire.beginTransmission(address); // Initialize the Tx buffer Wire.write(subAddress); // Put slave register address in Tx buffer Wire.endTransmission(false); // Send the Tx buffer, but send a restart to keep connection alive Wire.requestFrom(address, 1); // Read one byte from slave register address data = Wire.read(); // Fill Rx buffer with result return data; // Return data read from slave register }

void readBytes(uint8_t address, uint8_t subAddress, uint8_t count, uint8_t

  • dest) { Wire.beginTransmission(address); // Initialize the Tx buffer Wire.write(subAddress); // Put slave register address in Tx buffer Wire.endTransmission(false); // Send the Tx buffer, but send a restart to keep connection alive uint8_t i = 0; Wire.requestFrom(address, count); // Read bytes from slave register address while (Wire.available()) { dest[i++] = Wire.read(); } // Put read results in the Rx buffer

}

On Wed, May 17, 2017 at 2:10 PM, tim77777 notifications@github.com wrote:

Hi, I am wondering about intermittent random values I am getting from the MPU9250 accelerometer. The output always jumps around a little as expected, proportional to the bandwidth that I set. But I also get random high and low values anywhere from -10000's to +10000's. Perhaps there is a clue in the fact that there is often -256 (100000000)and +255 (011111111), also it is much worse on the X axis, though it does happen on all axes. This is my own implementation on a microchip part. I have tried slowing I2C, and inserting delays here and there, but it doesn't make any difference.

There has very very rarely been a random value from the Gyro, but the accelerometer, particularly the X axis (which is read first) spits regularly.

I have tried reading only the single low byte from the X axis and the random values are sometimes well about 255, which would not be possible from an 8 bit value, so I guess the problem is in my I2C routine or maybe even hardware related.

accele_bytes[0] = I2C_read_reg(MPU_ADDRESS, ACCEL_XOUT_L);

char I2C_read_reg(char cntl_add, char value) { char reg_value = 0;

I2CStart(); I2CSend(cntl_add); // prepare to be read //D0 I2CSend(value); // register to be read; I2CRestart(); I2CSend(cntl_add + 1); //read from previously sent register address reg_value = I2CRead(); I2CStop();

return reg_value;

}

Any help would be appreciated.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/148, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qtbs_ c1EuT8sF0uT1NFNF7MCHXqpks5r62JCgaJpZM4NecXm .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302241696> , or mute the thread https://github.com/notifications/unsubscribe- auth/AXcUIYARa_PfRINKri1jTvfu4OzLb9Euks5r62uZgaJpZM4NecXm .Image removed by sender.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302264594 , or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1quD9TR0TYkUYN- zaQFYmABL4IcmEks5r64vigaJpZM4NecXm .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302265459> , or mute the thread https://github.com/notifications/unsubscribe- auth/AXcUIdV-xl2-dnzpMi_XEd41kxHdZdzGks5r641cgaJpZM4NecXm .Description: Image removed by sender.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302683781, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1quhS3tnJx-5gTAT7T_OALMIr9iTUks5r7YOKgaJpZM4NecXm .

tim77777 commented 7 years ago

Fair enough. Regarding burst read, looking at the data sheet it seems that burst read can only be done on the same register address.

Burst transmit automatically increments the address written to, but burst read does not. At least that is what the product specification seems to say.

So, when you say try burst read, are you referring to using the FIFO?

Regards

Tim

From: Kris Winer [mailto:notifications@github.com] Sent: Saturday, May 20, 2017 1:12 AM To: kriswiner/MPU9250 Cc: tim77777; Author Subject: Re: [kriswiner/MPU9250] Random values from accelerometer (#148)

I have never seen anything like this. I would recommend that you read all accel and gyro data at once with a burst read. You might be reading individual bytes from different data samples and causing the strange results. But don't know.

On Fri, May 19, 2017 at 4:56 AM, tim77777 notifications@github.com wrote:

I see. Thanks. I’ve looked into it further. This is complicated, so strap yourself in J

I guess it is the I2C functions or maybe the way I am reading the MPU9250.

On closer examination I have found that it is when acceleration is close to zero on any axis, is when the issue is most noticeable.

This is because it is jumping about up and down 3 or 4 bits, as expected with no filtering, and so it is crossing between positive and negative acceleration regularly.

This mean the sensor is outputting something like +1, + 3, -9, +5, - 6, -2, +7 etc

Being two complement the binary equivalents are something like 00000000 00000001, 00000000 00000011, 11111111 11110111, 00000000 00000101 etc

So it seems that somewhere along the way the upper and lower bytes are sometimes being mixed up, and so I am getting regular highs and lows of

+255 and -256

00000000 11111111, 11111111 00000000

On close examination I can see this is happening on all accelerometer axes and all gyro outputs, and it is also happening all through the scale not just at close to zero acceleration position.

It’s just not as obvious at other positions because the lower / upper byte difference is not so great.

Also it is worst with no filtering, and non-existent with maximum filtering because the output is not jumping around much and hence is not crossing between positive and negative acceleration.

I’ve looked into the I2C routine and it seems good, but I’ll keep looking into it.

I have minimized things with the MPU9250 so only the high byte and then the low byte of the X axis are being read, then that is shifted into an integer, over and over again. No other sensor outputs are being read, the FIFO is not enabled, and no calibration has been done. It is at 16G but does the same thing at 2G.

Do you have any ideas about things I might be able to experiment with to zero in on the issue.

Regards

Tim.

From: Kris Winer [mailto:notifications@github.com] Sent: Thursday, May 18, 2017 10:14 AM

To: kriswiner/MPU9250 Cc: tim77777; Author Subject: Re: [kriswiner/MPU9250] Random values from accelerometer (#148)

int is ambiguous and might or might not work on your system, I have never used a PIC before. I would recommned, even if not necessary:

int16_t raw_acc_x = (int16_t) (((int16_t) highByte << 8) | lowByte);

It's unusual to see 255 and -255, not impossible, but this is what you might expect if the connection is temporarily lost. Check your connections. Can you read any other I2C sensor using this I2C function call and get reasonable data?

On Wed, May 17, 2017 at 5:08 PM, tim77777 notifications@github.com wrote:

Hi,

Using a PIC1618325

My I2C routine sends the device address, then the register address, then reads the single byte of data at that address.

In trying to working out the problem, I had cut my code down so that only the lower byte of the X axis was being read. And I get good data, with occasional spits of high and low values.

And that is the problem. I say “spit” because it is like a clean flow of water with occasional spits of water coming out of that clean flow, at different heights.

However, your comments spurred me to have another look and it seems I was dealing with two problems as I am transmitting the data via RF to another system, and something in that system is spitting high values. Now, I have taken the RF out of the equation, and I am reading the data directly on the system housing the MPU9250, here is what I am experiencing, perhaps it is normal.

Filtering anywhere quicker than10.2Hz, produces a regular spit of random data with the highest being +255 (11111111) and the lowest being -256 (100000000).

I combine the low and high data bytes like so

raw_acc_x = (int)((highByte << 8) | lowByte);

From: Kris Winer [mailto:notifications@github.com] Sent: Thursday, May 18, 2017 7:50 AM To: kriswiner/MPU9250 Cc: tim77777; Author Subject: Re: [kriswiner/MPU9250] Random values from accelerometer (#148)

Which MCU are you using?

I don't quite understand you readBytes function. Are you trying to read just two bytes?

Where are you composing the two bytes into an int16_t signed interger? i suspect the latter is your problem.

This is what I use for I2C:

// I2C read/write functions for the BMP280 sensors

void writeByte(uint8_t address, uint8_t subAddress, uint8_t data) { Wire.beginTransmission(address); // Initialize the Tx buffer Wire.write(subAddress); // Put slave register address in Tx buffer Wire.write(data); // Put data in Tx buffer Wire.endTransmission(); // Send the Tx buffer }

uint8_t readByte(uint8_t address, uint8_t subAddress) { uint8_t data; // data will store the register data Wire.beginTransmission(address); // Initialize the Tx buffer Wire.write(subAddress); // Put slave register address in Tx buffer Wire.endTransmission(false); // Send the Tx buffer, but send a restart to keep connection alive Wire.requestFrom(address, 1); // Read one byte from slave register address data = Wire.read(); // Fill Rx buffer with result return data; // Return data read from slave register }

void readBytes(uint8_t address, uint8_t subAddress, uint8_t count, uint8_t

  • dest) { Wire.beginTransmission(address); // Initialize the Tx buffer Wire.write(subAddress); // Put slave register address in Tx buffer Wire.endTransmission(false); // Send the Tx buffer, but send a restart to keep connection alive uint8_t i = 0; Wire.requestFrom(address, count); // Read bytes from slave register address while (Wire.available()) { dest[i++] = Wire.read(); } // Put read results in the Rx buffer

}

On Wed, May 17, 2017 at 2:10 PM, tim77777 notifications@github.com wrote:

Hi, I am wondering about intermittent random values I am getting from the MPU9250 accelerometer. The output always jumps around a little as expected, proportional to the bandwidth that I set. But I also get random high and low values anywhere from -10000's to +10000's. Perhaps there is a clue in the fact that there is often -256 (100000000)and +255 (011111111), also it is much worse on the X axis, though it does happen on all axes. This is my own implementation on a microchip part. I have tried slowing I2C, and inserting delays here and there, but it doesn't make any difference.

There has very very rarely been a random value from the Gyro, but the accelerometer, particularly the X axis (which is read first) spits regularly.

I have tried reading only the single low byte from the X axis and the random values are sometimes well about 255, which would not be possible from an 8 bit value, so I guess the problem is in my I2C routine or maybe even hardware related.

accele_bytes[0] = I2C_read_reg(MPU_ADDRESS, ACCEL_XOUT_L);

char I2C_read_reg(char cntl_add, char value) { char reg_value = 0;

I2CStart(); I2CSend(cntl_add); // prepare to be read //D0 I2CSend(value); // register to be read; I2CRestart(); I2CSend(cntl_add + 1); //read from previously sent register address reg_value = I2CRead(); I2CStop();

return reg_value;

}

Any help would be appreciated.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/148, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGY1qtbs_ https://github.com/notifications/unsubscribe-auth/AGY1qtbs_%0b c1EuT8sF0uT1NFNF7MCHXqpks5r62JCgaJpZM4NecXm> .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302241696> , or mute the thread <https://github.com/notifications/unsubscribe- https://github.com/notifications/unsubscribe-%0b auth/AXcUIYARa_PfRINKri1jTvfu4OzLb9Euks5r62uZgaJpZM4NecXm> .Image removed by sender.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302264594 https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302264594 , or mute the thread <https://github.com/notifications/unsubscribe-auth/AGY1quD9TR0TYkUYN- https://github.com/notifications/unsubscribe-auth/AGY1quD9TR0TYkUYN-%0b zaQFYmABL4IcmEks5r64vigaJpZM4NecXm> .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302265459> , or mute the thread <https://github.com/notifications/unsubscribe- https://github.com/notifications/unsubscribe-%0b auth/AXcUIdV-xl2-dnzpMi_XEd41kxHdZdzGks5r641cgaJpZM4NecXm> .Description: Image removed by sender.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302683781, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1quhS3tnJx-5gTAT7T_OALMIr9iTUks5r7YOKgaJpZM4NecXm .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302729743 , or mute the thread https://github.com/notifications/unsubscribe-auth/AXcUIa3z8FCQOxo2HaaXCDv6i_w402Hnks5r7bFCgaJpZM4NecXm . https://github.com/notifications/beacon/AXcUIT33VkhxHZIHFFgcvILz2iSVxP5Eks5r7bFCgaJpZM4NecXm.gif

kriswiner commented 7 years ago

No.

Start at the first register and read all 14 bytes. Like this:

void readMPU9250Data(int16_t * destination) { uint8_t rawData[14]; // x/y/z accel register data stored here readBytes(MPU9250_ADDRESS, ACCEL_XOUT_H, 14, &rawData[0]); // Read the 14 raw data registers into data array destination[0] = ((int16_t)rawData[0] << 8) | rawData[1] ; // Turn the MSB and LSB into a signed 16-bit value destination[1] = ((int16_t)rawData[2] << 8) | rawData[3] ; destination[2] = ((int16_t)rawData[4] << 8) | rawData[5] ; destination[3] = ((int16_t)rawData[6] << 8) | rawData[7] ; destination[4] = ((int16_t)rawData[8] << 8) | rawData[9] ; destination[5] = ((int16_t)rawData[10] << 8) | rawData[11] ; destination[6] = ((int16_t)rawData[12] << 8) | rawData[13] ;

}

On Fri, May 19, 2017 at 5:58 PM, tim77777 notifications@github.com wrote:

Fair enough. Regarding burst read, looking at the data sheet it seems that burst read can only be done on the same register address.

Burst transmit automatically increments the address written to, but burst read does not. At least that is what the product specification seems to say.

So, when you say try burst read, are you referring to using the FIFO?

Regards

Tim

From: Kris Winer [mailto:notifications@github.com] Sent: Saturday, May 20, 2017 1:12 AM

To: kriswiner/MPU9250 Cc: tim77777; Author Subject: Re: [kriswiner/MPU9250] Random values from accelerometer (#148)

I have never seen anything like this. I would recommend that you read all accel and gyro data at once with a burst read. You might be reading individual bytes from different data samples and causing the strange results. But don't know.

On Fri, May 19, 2017 at 4:56 AM, tim77777 notifications@github.com wrote:

I see. Thanks. I’ve looked into it further. This is complicated, so strap yourself in J

I guess it is the I2C functions or maybe the way I am reading the MPU9250.

On closer examination I have found that it is when acceleration is close to zero on any axis, is when the issue is most noticeable.

This is because it is jumping about up and down 3 or 4 bits, as expected with no filtering, and so it is crossing between positive and negative acceleration regularly.

This mean the sensor is outputting something like +1, + 3, -9, +5, - 6, -2, +7 etc

Being two complement the binary equivalents are something like 00000000 00000001, 00000000 00000011, 11111111 11110111, 00000000 00000101 etc

So it seems that somewhere along the way the upper and lower bytes are sometimes being mixed up, and so I am getting regular highs and lows of

+255 and -256

00000000 11111111, 11111111 00000000

On close examination I can see this is happening on all accelerometer axes and all gyro outputs, and it is also happening all through the scale not just at close to zero acceleration position.

It’s just not as obvious at other positions because the lower / upper byte difference is not so great.

Also it is worst with no filtering, and non-existent with maximum filtering because the output is not jumping around much and hence is not crossing between positive and negative acceleration.

I’ve looked into the I2C routine and it seems good, but I’ll keep looking into it.

I have minimized things with the MPU9250 so only the high byte and then the low byte of the X axis are being read, then that is shifted into an integer, over and over again. No other sensor outputs are being read, the FIFO is not enabled, and no calibration has been done. It is at 16G but does the same thing at 2G.

Do you have any ideas about things I might be able to experiment with to zero in on the issue.

Regards

Tim.

From: Kris Winer [mailto:notifications@github.com] Sent: Thursday, May 18, 2017 10:14 AM

To: kriswiner/MPU9250 Cc: tim77777; Author Subject: Re: [kriswiner/MPU9250] Random values from accelerometer (#148)

int is ambiguous and might or might not work on your system, I have never used a PIC before. I would recommned, even if not necessary:

int16_t raw_acc_x = (int16_t) (((int16_t) highByte << 8) | lowByte);

It's unusual to see 255 and -255, not impossible, but this is what you might expect if the connection is temporarily lost. Check your connections. Can you read any other I2C sensor using this I2C function call and get reasonable data?

On Wed, May 17, 2017 at 5:08 PM, tim77777 notifications@github.com wrote:

Hi,

Using a PIC1618325

My I2C routine sends the device address, then the register address, then reads the single byte of data at that address.

In trying to working out the problem, I had cut my code down so that only the lower byte of the X axis was being read. And I get good data, with occasional spits of high and low values.

And that is the problem. I say “spit” because it is like a clean flow of water with occasional spits of water coming out of that clean flow, at different heights.

However, your comments spurred me to have another look and it seems I was dealing with two problems as I am transmitting the data via RF to another system, and something in that system is spitting high values. Now, I have taken the RF out of the equation, and I am reading the data directly on the system housing the MPU9250, here is what I am experiencing, perhaps it is normal.

Filtering anywhere quicker than10.2Hz, produces a regular spit of random data with the highest being +255 (11111111) and the lowest being -256 (100000000).

I combine the low and high data bytes like so

raw_acc_x = (int)((highByte << 8) | lowByte);

From: Kris Winer [mailto:notifications@github.com] Sent: Thursday, May 18, 2017 7:50 AM To: kriswiner/MPU9250 Cc: tim77777; Author Subject: Re: [kriswiner/MPU9250] Random values from accelerometer (#148)

Which MCU are you using?

I don't quite understand you readBytes function. Are you trying to read just two bytes?

Where are you composing the two bytes into an int16_t signed interger? i suspect the latter is your problem.

This is what I use for I2C:

// I2C read/write functions for the BMP280 sensors

void writeByte(uint8_t address, uint8_t subAddress, uint8_t data) { Wire.beginTransmission(address); // Initialize the Tx buffer Wire.write(subAddress); // Put slave register address in Tx buffer Wire.write(data); // Put data in Tx buffer Wire.endTransmission(); // Send the Tx buffer }

uint8_t readByte(uint8_t address, uint8_t subAddress) { uint8_t data; // data will store the register data Wire.beginTransmission(address); // Initialize the Tx buffer Wire.write(subAddress); // Put slave register address in Tx buffer Wire.endTransmission(false); // Send the Tx buffer, but send a restart to keep connection alive Wire.requestFrom(address, 1); // Read one byte from slave register address data = Wire.read(); // Fill Rx buffer with result return data; // Return data read from slave register }

void readBytes(uint8_t address, uint8_t subAddress, uint8_t count, uint8_t

  • dest) { Wire.beginTransmission(address); // Initialize the Tx buffer Wire.write(subAddress); // Put slave register address in Tx buffer Wire.endTransmission(false); // Send the Tx buffer, but send a restart to keep connection alive uint8_t i = 0; Wire.requestFrom(address, count); // Read bytes from slave register address while (Wire.available()) { dest[i++] = Wire.read(); } // Put read results in the Rx buffer

}

On Wed, May 17, 2017 at 2:10 PM, tim77777 notifications@github.com wrote:

Hi, I am wondering about intermittent random values I am getting from the MPU9250 accelerometer. The output always jumps around a little as expected, proportional to the bandwidth that I set. But I also get random high and low values anywhere from -10000's to +10000's. Perhaps there is a clue in the fact that there is often -256 (100000000)and +255 (011111111), also it is much worse on the X axis, though it does happen on all axes. This is my own implementation on a microchip part. I have tried slowing I2C, and inserting delays here and there, but it doesn't make any difference.

There has very very rarely been a random value from the Gyro, but the accelerometer, particularly the X axis (which is read first) spits regularly.

I have tried reading only the single low byte from the X axis and the random values are sometimes well about 255, which would not be possible from an 8 bit value, so I guess the problem is in my I2C routine or maybe even hardware related.

accele_bytes[0] = I2C_read_reg(MPU_ADDRESS, ACCEL_XOUT_L);

char I2C_read_reg(char cntl_add, char value) { char reg_value = 0;

I2CStart(); I2CSend(cntl_add); // prepare to be read //D0 I2CSend(value); // register to be read; I2CRestart(); I2CSend(cntl_add + 1); //read from previously sent register address reg_value = I2CRead(); I2CStop();

return reg_value;

}

Any help would be appreciated.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/148, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGY1qtbs_ < https://github.com/notifications/unsubscribe-auth/AGY1qtbs_%0b> c1EuT8sF0uT1NFNF7MCHXqpks5r62JCgaJpZM4NecXm> .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302241696

,

or mute the thread <https://github.com/notifications/unsubscribe- < https://github.com/notifications/unsubscribe-%0b> auth/AXcUIYARa_PfRINKri1jTvfu4OzLb9Euks5r62uZgaJpZM4NecXm> .Image removed by sender.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/kriswiner/MPU9250/issues/148# issuecomment-302264594 <https://github.com/kriswiner/MPU9250/issues/148# issuecomment-302264594 > , or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1quD9TR0TYkUYN- <https://github.com/notifications/unsubscribe-auth/AGY1quD9TR0TYkUYN-%0b zaQFYmABL4IcmEks5r64vigaJpZM4NecXm> .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302265459> , or mute the thread <https://github.com/notifications/unsubscribe- < https://github.com/notifications/unsubscribe-%0b> auth/AXcUIdV-xl2-dnzpMi_XEd41kxHdZdzGks5r641cgaJpZM4NecXm> .Description: Image removed by sender.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302683781 , or mute the thread https://github.com/notifications/unsubscribe- auth/AGY1quhS3tnJx-5gTAT7T_OALMIr9iTUks5r7YOKgaJpZM4NecXm .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302729743> , or mute the thread https://github.com/notifications/unsubscribe-auth/ AXcUIa3z8FCQOxo2HaaXCDv6i_w402Hnks5r7bFCgaJpZM4NecXm . < https://github.com/notifications/beacon/AXcUIT33VkhxHZIHFFgcvILz2iSVxP 5Eks5r7bFCgaJpZM4NecXm.gif>

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302840492, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1ql5C3cz1CspMKnx-LVIa6BqmrRObks5r7jrHgaJpZM4NecXm .

tim77777 commented 7 years ago

Ok, found the problem. Faulty human.

Staring me in the face so many times. I looked at the burst read example on pg 35 of the product specification so many times, and never noticed I had not included the ACK in the sequence.

I think I had assumed the ACK was somehow auto-generated.

Anyway, job done, on with the spurious RF activity now. Thanks for your time, it was helpful to talk it through as who knows how long it would have taken me to start looking at a burst read option.

Before I fixed it, I had setup the FIFO for the same purpose of multi-byte reads, and it seemed to do the job. So, what’s the pro’s and con’s of using the FIFO versus Burst read?

Regards

Tim

From: Kris Winer [mailto:notifications@github.com] Sent: Saturday, May 20, 2017 11:01 AM To: kriswiner/MPU9250 Cc: tim77777; Author Subject: Re: [kriswiner/MPU9250] Random values from accelerometer (#148)

No.

Start at the first register and read all 14 bytes. Like this:

void readMPU9250Data(int16_t * destination) { uint8_t rawData[14]; // x/y/z accel register data stored here readBytes(MPU9250_ADDRESS, ACCEL_XOUT_H, 14, &rawData[0]); // Read the 14 raw data registers into data array destination[0] = ((int16_t)rawData[0] << 8) | rawData[1] ; // Turn the MSB and LSB into a signed 16-bit value destination[1] = ((int16_t)rawData[2] << 8) | rawData[3] ; destination[2] = ((int16_t)rawData[4] << 8) | rawData[5] ; destination[3] = ((int16_t)rawData[6] << 8) | rawData[7] ; destination[4] = ((int16_t)rawData[8] << 8) | rawData[9] ; destination[5] = ((int16_t)rawData[10] << 8) | rawData[11] ; destination[6] = ((int16_t)rawData[12] << 8) | rawData[13] ;

}

On Fri, May 19, 2017 at 5:58 PM, tim77777 notifications@github.com wrote:

Fair enough. Regarding burst read, looking at the data sheet it seems that burst read can only be done on the same register address.

Burst transmit automatically increments the address written to, but burst read does not. At least that is what the product specification seems to say.

So, when you say try burst read, are you referring to using the FIFO?

Regards

Tim

From: Kris Winer [mailto:notifications@github.com] Sent: Saturday, May 20, 2017 1:12 AM

To: kriswiner/MPU9250 Cc: tim77777; Author Subject: Re: [kriswiner/MPU9250] Random values from accelerometer (#148)

I have never seen anything like this. I would recommend that you read all accel and gyro data at once with a burst read. You might be reading individual bytes from different data samples and causing the strange results. But don't know.

On Fri, May 19, 2017 at 4:56 AM, tim77777 notifications@github.com wrote:

I see. Thanks. I’ve looked into it further. This is complicated, so strap yourself in J

I guess it is the I2C functions or maybe the way I am reading the MPU9250.

On closer examination I have found that it is when acceleration is close to zero on any axis, is when the issue is most noticeable.

This is because it is jumping about up and down 3 or 4 bits, as expected with no filtering, and so it is crossing between positive and negative acceleration regularly.

This mean the sensor is outputting something like +1, + 3, -9, +5, - 6, -2, +7 etc

Being two complement the binary equivalents are something like 00000000 00000001, 00000000 00000011, 11111111 11110111, 00000000 00000101 etc

So it seems that somewhere along the way the upper and lower bytes are sometimes being mixed up, and so I am getting regular highs and lows of

+255 and -256

00000000 11111111, 11111111 00000000

On close examination I can see this is happening on all accelerometer axes and all gyro outputs, and it is also happening all through the scale not just at close to zero acceleration position.

It’s just not as obvious at other positions because the lower / upper byte difference is not so great.

Also it is worst with no filtering, and non-existent with maximum filtering because the output is not jumping around much and hence is not crossing between positive and negative acceleration.

I’ve looked into the I2C routine and it seems good, but I’ll keep looking into it.

I have minimized things with the MPU9250 so only the high byte and then the low byte of the X axis are being read, then that is shifted into an integer, over and over again. No other sensor outputs are being read, the FIFO is not enabled, and no calibration has been done. It is at 16G but does the same thing at 2G.

Do you have any ideas about things I might be able to experiment with to zero in on the issue.

Regards

Tim.

From: Kris Winer [mailto:notifications@github.com] Sent: Thursday, May 18, 2017 10:14 AM

To: kriswiner/MPU9250 Cc: tim77777; Author Subject: Re: [kriswiner/MPU9250] Random values from accelerometer (#148)

int is ambiguous and might or might not work on your system, I have never used a PIC before. I would recommned, even if not necessary:

int16_t raw_acc_x = (int16_t) (((int16_t) highByte << 8) | lowByte);

It's unusual to see 255 and -255, not impossible, but this is what you might expect if the connection is temporarily lost. Check your connections. Can you read any other I2C sensor using this I2C function call and get reasonable data?

On Wed, May 17, 2017 at 5:08 PM, tim77777 notifications@github.com wrote:

Hi,

Using a PIC1618325

My I2C routine sends the device address, then the register address, then reads the single byte of data at that address.

In trying to working out the problem, I had cut my code down so that only the lower byte of the X axis was being read. And I get good data, with occasional spits of high and low values.

And that is the problem. I say “spit” because it is like a clean flow of water with occasional spits of water coming out of that clean flow, at different heights.

However, your comments spurred me to have another look and it seems I was dealing with two problems as I am transmitting the data via RF to another system, and something in that system is spitting high values. Now, I have taken the RF out of the equation, and I am reading the data directly on the system housing the MPU9250, here is what I am experiencing, perhaps it is normal.

Filtering anywhere quicker than10.2Hz, produces a regular spit of random data with the highest being +255 (11111111) and the lowest being -256 (100000000).

I combine the low and high data bytes like so

raw_acc_x = (int)((highByte << 8) | lowByte);

From: Kris Winer [mailto:notifications@github.com] Sent: Thursday, May 18, 2017 7:50 AM To: kriswiner/MPU9250 Cc: tim77777; Author Subject: Re: [kriswiner/MPU9250] Random values from accelerometer (#148)

Which MCU are you using?

I don't quite understand you readBytes function. Are you trying to read just two bytes?

Where are you composing the two bytes into an int16_t signed interger? i suspect the latter is your problem.

This is what I use for I2C:

// I2C read/write functions for the BMP280 sensors

void writeByte(uint8_t address, uint8_t subAddress, uint8_t data) { Wire.beginTransmission(address); // Initialize the Tx buffer Wire.write(subAddress); // Put slave register address in Tx buffer Wire.write(data); // Put data in Tx buffer Wire.endTransmission(); // Send the Tx buffer }

uint8_t readByte(uint8_t address, uint8_t subAddress) { uint8_t data; // data will store the register data Wire.beginTransmission(address); // Initialize the Tx buffer Wire.write(subAddress); // Put slave register address in Tx buffer Wire.endTransmission(false); // Send the Tx buffer, but send a restart to keep connection alive Wire.requestFrom(address, 1); // Read one byte from slave register address data = Wire.read(); // Fill Rx buffer with result return data; // Return data read from slave register }

void readBytes(uint8_t address, uint8_t subAddress, uint8_t count, uint8_t

  • dest) { Wire.beginTransmission(address); // Initialize the Tx buffer Wire.write(subAddress); // Put slave register address in Tx buffer Wire.endTransmission(false); // Send the Tx buffer, but send a restart to keep connection alive uint8_t i = 0; Wire.requestFrom(address, count); // Read bytes from slave register address while (Wire.available()) { dest[i++] = Wire.read(); } // Put read results in the Rx buffer

}

On Wed, May 17, 2017 at 2:10 PM, tim77777 notifications@github.com wrote:

Hi, I am wondering about intermittent random values I am getting from the MPU9250 accelerometer. The output always jumps around a little as expected, proportional to the bandwidth that I set. But I also get random high and low values anywhere from -10000's to +10000's. Perhaps there is a clue in the fact that there is often -256 (100000000)and +255 (011111111), also it is much worse on the X axis, though it does happen on all axes. This is my own implementation on a microchip part. I have tried slowing I2C, and inserting delays here and there, but it doesn't make any difference.

There has very very rarely been a random value from the Gyro, but the accelerometer, particularly the X axis (which is read first) spits regularly.

I have tried reading only the single low byte from the X axis and the random values are sometimes well about 255, which would not be possible from an 8 bit value, so I guess the problem is in my I2C routine or maybe even hardware related.

accele_bytes[0] = I2C_read_reg(MPU_ADDRESS, ACCEL_XOUT_L);

char I2C_read_reg(char cntl_add, char value) { char reg_value = 0;

I2CStart(); I2CSend(cntl_add); // prepare to be read //D0 I2CSend(value); // register to be read; I2CRestart(); I2CSend(cntl_add + 1); //read from previously sent register address reg_value = I2CRead(); I2CStop();

return reg_value;

}

Any help would be appreciated.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/148, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGY1qtbs_ < https://github.com/notifications/unsubscribe-auth/AGY1qtbs_%0b> c1EuT8sF0uT1NFNF7MCHXqpks5r62JCgaJpZM4NecXm> .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302241696

,

or mute the thread <https://github.com/notifications/unsubscribe- < https://github.com/notifications/unsubscribe-%0b> auth/AXcUIYARa_PfRINKri1jTvfu4OzLb9Euks5r62uZgaJpZM4NecXm> .Image removed by sender.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/kriswiner/MPU9250/issues/148# issuecomment-302264594 <https://github.com/kriswiner/MPU9250/issues/148# issuecomment-302264594 > , or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1quD9TR0TYkUYN- <https://github.com/notifications/unsubscribe-auth/AGY1quD9TR0TYkUYN-%0b zaQFYmABL4IcmEks5r64vigaJpZM4NecXm> .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302265459> , or mute the thread <https://github.com/notifications/unsubscribe- < https://github.com/notifications/unsubscribe-%0b> auth/AXcUIdV-xl2-dnzpMi_XEd41kxHdZdzGks5r641cgaJpZM4NecXm> .Description: Image removed by sender.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302683781 , or mute the thread https://github.com/notifications/unsubscribe- auth/AGY1quhS3tnJx-5gTAT7T_OALMIr9iTUks5r7YOKgaJpZM4NecXm .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302729743> , or mute the thread https://github.com/notifications/unsubscribe-auth/ AXcUIa3z8FCQOxo2HaaXCDv6i_w402Hnks5r7bFCgaJpZM4NecXm . < https://github.com/notifications/beacon/AXcUIT33VkhxHZIHFFgcvILz2iSVxP 5Eks5r7bFCgaJpZM4NecXm.gif>

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302840492, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1ql5C3cz1CspMKnx-LVIa6BqmrRObks5r7jrHgaJpZM4NecXm .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302840680 , or mute the thread https://github.com/notifications/unsubscribe-auth/AXcUIQfnh9xTp54MuzwDi2EG0duthussks5r7jtjgaJpZM4NecXm .Description: Image removed by sender.

kriswiner commented 7 years ago

Only advantage in using the FIFO is you could set it up to also read the mag. I prefer just reading directly from the registers on interrupt.

On Fri, May 19, 2017 at 10:29 PM, tim77777 notifications@github.com wrote:

Ok, found the problem. Faulty human.

Staring me in the face so many times. I looked at the burst read example on pg 35 of the product specification so many times, and never noticed I had not included the ACK in the sequence.

I think I had assumed the ACK was somehow auto-generated.

Anyway, job done, on with the spurious RF activity now. Thanks for your time, it was helpful to talk it through as who knows how long it would have taken me to start looking at a burst read option.

Before I fixed it, I had setup the FIFO for the same purpose of multi-byte reads, and it seemed to do the job. So, what’s the pro’s and con’s of using the FIFO versus Burst read?

Regards

Tim

From: Kris Winer [mailto:notifications@github.com] Sent: Saturday, May 20, 2017 11:01 AM

To: kriswiner/MPU9250 Cc: tim77777; Author Subject: Re: [kriswiner/MPU9250] Random values from accelerometer (#148)

No.

Start at the first register and read all 14 bytes. Like this:

void readMPU9250Data(int16_t * destination) { uint8_t rawData[14]; // x/y/z accel register data stored here readBytes(MPU9250_ADDRESS, ACCEL_XOUT_H, 14, &rawData[0]); // Read the 14 raw data registers into data array destination[0] = ((int16_t)rawData[0] << 8) | rawData[1] ; // Turn the MSB and LSB into a signed 16-bit value destination[1] = ((int16_t)rawData[2] << 8) | rawData[3] ; destination[2] = ((int16_t)rawData[4] << 8) | rawData[5] ; destination[3] = ((int16_t)rawData[6] << 8) | rawData[7] ; destination[4] = ((int16_t)rawData[8] << 8) | rawData[9] ; destination[5] = ((int16_t)rawData[10] << 8) | rawData[11] ; destination[6] = ((int16_t)rawData[12] << 8) | rawData[13] ;

}

On Fri, May 19, 2017 at 5:58 PM, tim77777 notifications@github.com wrote:

Fair enough. Regarding burst read, looking at the data sheet it seems that burst read can only be done on the same register address.

Burst transmit automatically increments the address written to, but burst read does not. At least that is what the product specification seems to say.

So, when you say try burst read, are you referring to using the FIFO?

Regards

Tim

From: Kris Winer [mailto:notifications@github.com] Sent: Saturday, May 20, 2017 1:12 AM

To: kriswiner/MPU9250 Cc: tim77777; Author Subject: Re: [kriswiner/MPU9250] Random values from accelerometer (#148)

I have never seen anything like this. I would recommend that you read all accel and gyro data at once with a burst read. You might be reading individual bytes from different data samples and causing the strange results. But don't know.

On Fri, May 19, 2017 at 4:56 AM, tim77777 notifications@github.com wrote:

I see. Thanks. I’ve looked into it further. This is complicated, so strap yourself in J

I guess it is the I2C functions or maybe the way I am reading the MPU9250.

On closer examination I have found that it is when acceleration is close to zero on any axis, is when the issue is most noticeable.

This is because it is jumping about up and down 3 or 4 bits, as expected with no filtering, and so it is crossing between positive and negative acceleration regularly.

This mean the sensor is outputting something like +1, + 3, -9, +5, - 6, -2, +7 etc

Being two complement the binary equivalents are something like 00000000 00000001, 00000000 00000011, 11111111 11110111, 00000000 00000101 etc

So it seems that somewhere along the way the upper and lower bytes are sometimes being mixed up, and so I am getting regular highs and lows of

+255 and -256

00000000 11111111, 11111111 00000000

On close examination I can see this is happening on all accelerometer axes and all gyro outputs, and it is also happening all through the scale not just at close to zero acceleration position.

It’s just not as obvious at other positions because the lower / upper byte difference is not so great.

Also it is worst with no filtering, and non-existent with maximum filtering because the output is not jumping around much and hence is not crossing between positive and negative acceleration.

I’ve looked into the I2C routine and it seems good, but I’ll keep looking into it.

I have minimized things with the MPU9250 so only the high byte and then the low byte of the X axis are being read, then that is shifted into an integer, over and over again. No other sensor outputs are being read, the FIFO is not enabled, and no calibration has been done. It is at 16G but does the same thing at 2G.

Do you have any ideas about things I might be able to experiment with to zero in on the issue.

Regards

Tim.

From: Kris Winer [mailto:notifications@github.com] Sent: Thursday, May 18, 2017 10:14 AM

To: kriswiner/MPU9250 Cc: tim77777; Author Subject: Re: [kriswiner/MPU9250] Random values from accelerometer (#148)

int is ambiguous and might or might not work on your system, I have never used a PIC before. I would recommned, even if not necessary:

int16_t raw_acc_x = (int16_t) (((int16_t) highByte << 8) | lowByte);

It's unusual to see 255 and -255, not impossible, but this is what you might expect if the connection is temporarily lost. Check your connections. Can you read any other I2C sensor using this I2C function call and get reasonable data?

On Wed, May 17, 2017 at 5:08 PM, tim77777 notifications@github.com wrote:

Hi,

Using a PIC1618325

My I2C routine sends the device address, then the register address, then reads the single byte of data at that address.

In trying to working out the problem, I had cut my code down so that only the lower byte of the X axis was being read. And I get good data, with occasional spits of high and low values.

And that is the problem. I say “spit” because it is like a clean flow of water with occasional spits of water coming out of that clean flow, at different heights.

However, your comments spurred me to have another look and it seems I was dealing with two problems as I am transmitting the data via RF to another system, and something in that system is spitting high values. Now, I have taken the RF out of the equation, and I am reading the data directly on the system housing the MPU9250, here is what I am experiencing, perhaps it is normal.

Filtering anywhere quicker than10.2Hz, produces a regular spit of random data with the highest being +255 (11111111) and the lowest being -256 (100000000).

I combine the low and high data bytes like so

raw_acc_x = (int)((highByte << 8) | lowByte);

From: Kris Winer [mailto:notifications@github.com] Sent: Thursday, May 18, 2017 7:50 AM To: kriswiner/MPU9250 Cc: tim77777; Author Subject: Re: [kriswiner/MPU9250] Random values from accelerometer (#148)

Which MCU are you using?

I don't quite understand you readBytes function. Are you trying to read just two bytes?

Where are you composing the two bytes into an int16_t signed interger? i suspect the latter is your problem.

This is what I use for I2C:

// I2C read/write functions for the BMP280 sensors

void writeByte(uint8_t address, uint8_t subAddress, uint8_t data) { Wire.beginTransmission(address); // Initialize the Tx buffer Wire.write(subAddress); // Put slave register address in Tx buffer Wire.write(data); // Put data in Tx buffer Wire.endTransmission(); // Send the Tx buffer }

uint8_t readByte(uint8_t address, uint8_t subAddress) { uint8_t data; // data will store the register data Wire.beginTransmission(address); // Initialize the Tx buffer Wire.write(subAddress); // Put slave register address in Tx buffer Wire.endTransmission(false); // Send the Tx buffer, but send a restart to keep connection alive Wire.requestFrom(address, 1); // Read one byte from slave register address data = Wire.read(); // Fill Rx buffer with result return data; // Return data read from slave register }

void readBytes(uint8_t address, uint8_t subAddress, uint8_t count, uint8_t

  • dest) { Wire.beginTransmission(address); // Initialize the Tx buffer Wire.write(subAddress); // Put slave register address in Tx buffer Wire.endTransmission(false); // Send the Tx buffer, but send a restart to keep connection alive uint8_t i = 0; Wire.requestFrom(address, count); // Read bytes from slave register address while (Wire.available()) { dest[i++] = Wire.read(); } // Put read results in the Rx buffer

}

On Wed, May 17, 2017 at 2:10 PM, tim77777 notifications@github.com wrote:

Hi, I am wondering about intermittent random values I am getting from the MPU9250 accelerometer. The output always jumps around a little as expected, proportional to the bandwidth that I set. But I also get random high and low values anywhere from -10000's to +10000's. Perhaps there is a clue in the fact that there is often -256 (100000000)and +255 (011111111), also it is much worse on the X axis, though it does happen on all axes. This is my own implementation on a microchip part. I have tried slowing I2C, and inserting delays here and there, but it doesn't make any difference.

There has very very rarely been a random value from the Gyro, but the accelerometer, particularly the X axis (which is read first) spits regularly.

I have tried reading only the single low byte from the X axis and the random values are sometimes well about 255, which would not be possible from an 8 bit value, so I guess the problem is in my I2C routine or maybe even hardware related.

accele_bytes[0] = I2C_read_reg(MPU_ADDRESS, ACCEL_XOUT_L);

char I2C_read_reg(char cntl_add, char value) { char reg_value = 0;

I2CStart(); I2CSend(cntl_add); // prepare to be read //D0 I2CSend(value); // register to be read; I2CRestart(); I2CSend(cntl_add + 1); //read from previously sent register address reg_value = I2CRead(); I2CStop();

return reg_value;

}

Any help would be appreciated.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/148, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGY1qtbs_ < https://github.com/notifications/unsubscribe-auth/AGY1qtbs_%0b> c1EuT8sF0uT1NFNF7MCHXqpks5r62JCgaJpZM4NecXm> .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU9250/issues/148# issuecomment-302241696

,

or mute the thread <https://github.com/notifications/unsubscribe- < https://github.com/notifications/unsubscribe-%0b> auth/AXcUIYARa_PfRINKri1jTvfu4OzLb9Euks5r62uZgaJpZM4NecXm> .Image removed by sender.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/kriswiner/MPU9250/issues/148# issuecomment-302264594 <https://github.com/kriswiner/MPU9250/issues/148#

issuecomment-302264594 >

, or mute the thread <https://github.com/notifications/unsubscribe- auth/AGY1quD9TR0TYkUYN- <https://github.com/notifications/unsubscribe-auth/AGY1quD9TR0TYkUYN-%0b

zaQFYmABL4IcmEks5r64vigaJpZM4NecXm>

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302265459

,

or mute the thread <https://github.com/notifications/unsubscribe- < https://github.com/notifications/unsubscribe-%0b> auth/AXcUIdV-xl2-dnzpMi_XEd41kxHdZdzGks5r641cgaJpZM4NecXm> .Description: Image removed by sender.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/kriswiner/MPU9250/issues/148# issuecomment-302683781 , or mute the thread https://github.com/notifications/unsubscribe- auth/AGY1quhS3tnJx-5gTAT7T_OALMIr9iTUks5r7YOKgaJpZM4NecXm .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302729743> , or mute the thread https://github.com/notifications/unsubscribe-auth/ AXcUIa3z8FCQOxo2HaaXCDv6i_w402Hnks5r7bFCgaJpZM4NecXm . < https://github.com/notifications/beacon/AXcUIT33VkhxHZIHFFgcvILz2iSVxP 5Eks5r7bFCgaJpZM4NecXm.gif>

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302840492 , or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1ql5C3cz1CspMKnx- LVIa6BqmrRObks5r7jrHgaJpZM4NecXm .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302840680> , or mute the thread https://github.com/notifications/unsubscribe-auth/ AXcUIQfnh9xTp54MuzwDi2EG0duthussks5r7jtjgaJpZM4NecXm .Description: Image removed by sender.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/148#issuecomment-302852151, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qqky-eOLscXP3Ufqjc6FkLglN8qRks5r7nolgaJpZM4NecXm .

bwilliams-97 commented 5 years ago

Hi Tim,

Can you remember how you went about solving this? When you say you forgot about the ack, what did you mean?

Many thanks.

kriswiner commented 5 years ago

What is the issue?

On Sun, Jan 6, 2019 at 11:01 AM bwilliams-97 notifications@github.com wrote:

Hi Tim,

Can you remember how you went about solving this? When you say you forgot about the ack, what did you mean?

Many thanks.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/148#issuecomment-451765565, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1quL92IK5R5gvWAJjHTFT4ttxYt7-ks5vAkf3gaJpZM4NecXm .

bwilliams-97 commented 5 years ago

I'm having a similar issue - getting random readings from the accelerometer. I've checked most things on forums I've found (I2C communications are working ok - I can write to and read from the power management registers, with the expected results). I'm a little lost as to what the issue could be. The LSBs are generally constant over X, Y and Z, but the MSBs vary hugely across the full scale range.

kriswiner commented 5 years ago

Looks at the 6 raw bytes coming out of the accel data registers. Do these correspond to the values you are reading? Most of these kind of issues are due to byte conversion to int16_t signed integers.

On Sun, Jan 6, 2019 at 11:49 AM bwilliams-97 notifications@github.com wrote:

I'm having a similar issue - getting random readings from the accelerometer. I've checked most things on forums I've found (I2C communications are working ok - I can write to and read from the power management registers, with the expected results). I'm a little lost as to what the issue could be.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/148#issuecomment-451769201, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qt08aLHnDQxFEjN0bOtU3yZR7mCYks5vAlNLgaJpZM4NecXm .

bwilliams-97 commented 5 years ago

The conversion is correct, it's the raw bytes that are weird. There is some correlation over time - an example is the X raw MSB, which gave these outputs sequentially: 24, 04, 64, F0, 50, 10, 0C, 3C, 1C.

Based on this it could be that I'm reading faster than the values are updated, so the update isn't quite working. That seems very unlikely though.

kriswiner commented 5 years ago

Don't know what to tell you, if your I2C API is working correctly maybe the MPU9250 breakout you are using is broken.

On Sun, Jan 6, 2019 at 11:57 AM bwilliams-97 notifications@github.com wrote:

The conversion is correct, it's the raw bytes that are weird. There is some correlation over time - an example is the X raw MSB, which gave these outputs sequentially: 24, 04, 64, F0, 50, 10, 0C, 3C, 1C

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/148#issuecomment-451769788, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qmdKYT7bAtAMpRdqYETMTdtSBy2mks5vAlUogaJpZM4NecXm .

bwilliams-97 commented 5 years ago

That's what I thought, so I bought another sensor and it showed the same issue...it must be something buried in my comms, I'll have a root through.

Many thanks for your help though!

kriswiner commented 5 years ago

Yes, likely an I2C issue. Which MCU are you using?

On Sun, Jan 6, 2019 at 12:08 PM bwilliams-97 notifications@github.com wrote:

That's what I thought, so I bought another sensor and it showed the same issue...it must be something buried in my comms, I'll have a root through.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/148#issuecomment-451770524, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qvKmjYtudv9Ey0BXT_Tl6SlvWA42ks5vAlexgaJpZM4NecXm .

bwilliams-97 commented 5 years ago

The MCU6050. One option I thought was that I'm not correctly getting it out of sleep mode. When I read from register 6B to check it comes back as 01 so should be set right. If the device were in sleep mode would it simply not communicate, or could it spew a seemingly random output?

kriswiner commented 5 years ago

I am asking what microcontroller you are using, what is an MCU6050?

On Sun, Jan 6, 2019 at 12:20 PM bwilliams-97 notifications@github.com wrote:

The MCU6050. One option I thought was that I'm not correctly getting it out of sleep mode. When I read from register 6B to check it comes back as 01 so should be set right. If the device were in sleep mode would it simply not communicate, or could it spew a seemingly random output?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/148#issuecomment-451771461, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qgQ0Ct_7ZWZ4R00vGegY5pjrEK1tks5vAlqFgaJpZM4NecXm .

bwilliams-97 commented 5 years ago

Typo (sorry), been a long day...IMU is MPU6050 and MCU is the FRDM KL03 development board.

kriswiner commented 5 years ago

Well, what is it then, a Teensy, raspberry pi or some other wierd concoction?

On Sun, Jan 6, 2019 at 12:24 PM bwilliams-97 notifications@github.com wrote:

Typo, been a long day...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/148#issuecomment-451771709, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qharQyYJvT8lVUhG-o9xQXa601QQks5vAltngaJpZM4NecXm .

bwilliams-97 commented 5 years ago

Neither of those unfortunately - probably best described as a weird concoction. Something along the lines of this...https://www.nxp.com/docs/en/data-sheet/KL03P24M48SF0.pdf

kriswiner commented 5 years ago

Ouch!

This is the problem, not the sensor...

Maybe try one of these https://www.tindie.com/products/TleraCorp/ladybug-stm32l432-development-board/ ?

On Sun, Jan 6, 2019 at 12:28 PM bwilliams-97 notifications@github.com wrote:

Neither of those unfortunately - probably best described as a weird concoction. Something along the lines of this... https://www.nxp.com/docs/en/data-sheet/KL03P24M48SF0.pdf

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/148#issuecomment-451772016, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qkYyiKmw4ByeZ8Rl0wMsoKzaq9BNks5vAlxQgaJpZM4NecXm .

bwilliams-97 commented 5 years ago

Ahh I wish - it's for an embedded systems course, so those aren't allowed!

tim77777 commented 5 years ago

Leaving the ACK out, meant that I did not include it in the Burst read sequence. On page 36 of the datasheet for the MPU6050, the burst read sequence is specified as Start > Address+write bit > Register Address > Start > Address + read bit > Acknowledge > Negative Acknowledge > Stop

I had not included the 'Acknowledge' bit, and so things were not working correctly.

[CODE] void read_MPU_9250(void) {
I2CStart(); I2CSend(MPU_ADDRESS); //cntl_add); // prepare to be read //D0 I2CSend(ACCEL_XOUT_H); // register to start reading at; routine auto increments register address I2CRestart(); I2CSend((0x68<<1) + 1); //MPU_ADDRESS + 1); //cntl_add + 1); //read from previously sent register address
accele_bytes[1] = I2CRead(); I2CAck(); accele_bytes[0] = I2CRead(); I2CAck(); accele_bytes[3] = I2CRead(); I2CAck(); accele_bytes[2] = I2CRead(); I2CAck(); accele_bytes[5] = I2CRead(); I2CAck(); accele_bytes[4] = I2CRead(); I2CAck(); temperature_bytes[1] = I2CRead(); I2CAck(); temperature_bytes[0] = I2CRead(); I2CAck(); gyro_bytes[1] = I2CRead(); I2CAck(); gyro_bytes[0] = I2CRead(); I2CAck(); gyro_bytes[3] = I2CRead(); I2CAck(); gyro_bytes[2] = I2CRead(); I2CAck(); gyro_bytes[5] = I2CRead(); I2CAck(); gyro_bytes[4] = I2CRead(); I2CNak(); I2CStop();

}

[/CODE]

kriswiner commented 5 years ago

This is uber-clunky. Why can;t you write a proper i2C API to read all of the bytes in one operation?

On Sun, Jan 6, 2019 at 1:20 PM tim77777 notifications@github.com wrote:

Leaving the ACK out, meant that I did not include it in the Burst read sequence. On page 36 of the datasheet for the MPU6050, the burst read sequence is specified as Start > Address+write bit > Register Address > Start > Address + read bit

Acknowledge > Negative Acknowledge > Stop

I had not included the 'Acknowledge' bit, and so things were not working correctly.

[CODE] void read_MPU_9250(void) { I2CStart(); I2CSend(MPU_ADDRESS); //cntl_add); // prepare to be read //D0 I2CSend(ACCEL_XOUT_H); // register to start reading at; routine auto increments register address I2CRestart(); I2CSend((0x68<<1) + 1); //MPU_ADDRESS + 1); //cntl_add + 1); //read from previously sent register address accele_bytes[1] = I2CRead(); I2CAck(); accele_bytes[0] = I2CRead(); I2CAck(); accele_bytes[3] = I2CRead(); I2CAck(); accele_bytes[2] = I2CRead(); I2CAck(); accele_bytes[5] = I2CRead(); I2CAck(); accele_bytes[4] = I2CRead(); I2CAck(); temperature_bytes[1] = I2CRead(); I2CAck(); temperature_bytes[0] = I2CRead(); I2CAck(); gyro_bytes[1] = I2CRead(); I2CAck(); gyro_bytes[0] = I2CRead(); I2CAck(); gyro_bytes[3] = I2CRead(); I2CAck(); gyro_bytes[2] = I2CRead(); I2CAck(); gyro_bytes[5] = I2CRead(); I2CAck(); gyro_bytes[4] = I2CRead(); I2CNak(); I2CStop();

}

[/CODE]

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/148#issuecomment-451775909, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qtG02J7Gwt2hQSBHWT6bhhSBIoiDks5vAmiUgaJpZM4NecXm .