connecting to multiple MPUs, is there any alternative to using a multiplexer?

[MitalPattani]

Hey Kris, i wanted to get readings from two MPUs but since there is only one mag address the solutions i could find was using a multiplexer. Is there any other way? Should i consider using SPI interface??

[Jan-Jelle]

you have the option of 2 adresses right? if AD0 is high or low the adres is 0x68 or 0x69. i suppose you can connect 2 mpu's on the I2C bus like that.

Verzonden vanaf mijn Samsung Galaxy-smartphone.

-------- Oorspronkelijk bericht -------- Van: MitalPattani notifications@github.com Datum: 25-03-18 18:01 (GMT+01:00) Aan: kriswiner/MPU9250 MPU9250@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Onderwerp: [kriswiner/MPU9250] connecting to multiple MPUs, is there any alternative to using a multiplexer? (#250)

Hey Kris, i wanted to get readings from two MPUs but since there is only one mag address the solutions i could find was using a multiplexer. Is there any other way? Should i consider using SPI interface??

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/kriswiner/MPU9250/issues/250, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AjlUp5wZw9syi_lYbFrS-zkK8gF2ckg0ks5th78-gaJpZM4S6MXw.

[kriswiner]

Yes, exactly. You do have the problem that the mag has the same I2C address 0x0C for both of the MPU9250s but one solution to this without the multiplexer is:

disable passthough mode for 0x69 enable passthrough mode for 0x68 read mag data from 0x0C

disable passthrough mode for 0x68 enable pass through mode for 0x69 read mag data from 0x0C

and repeat.

Clunky but this can work.

On Sun, Mar 25, 2018 at 10:00 AM, Jan-Jelle notifications@github.com wrote:

you have the option of 2 adresses right? if AD0 is high or low the adres is 0x68 or 0x69. i suppose you can connect 2 mpu's on the I2C bus like that.

Verzonden vanaf mijn Samsung Galaxy-smartphone.

-------- Oorspronkelijk bericht -------- Van: MitalPattani notifications@github.com Datum: 25-03-18 18:01 (GMT+01:00) Aan: kriswiner/MPU9250 MPU9250@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Onderwerp: [kriswiner/MPU9250] connecting to multiple MPUs, is there any alternative to using a multiplexer? (#250)

Hey Kris, i wanted to get readings from two MPUs but since there is only one mag address the solutions i could find was using a multiplexer. Is there any other way? Should i consider using SPI interface??

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/ kriswiner/MPU9250/issues/250, or mute the threadhttps://github.com/ notifications/unsubscribe-auth/AjlUp5wZw9syi_lYbFrS-zkK8gF2ckg0ks5th78- gaJpZM4S6MXw.

— 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/250#issuecomment-375985710, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qiH8RD8ZioRU1YySpqpn9eLlBTd8ks5th805gaJpZM4S6MXw .

[MitalPattani]

how clunky exactly? I mean I need to use it for human motion sensing...also what microcontroller would you suggest ? i am using UNO, should i use teensy or any other controller?

[kriswiner]

If you hope to perfrom sensor fusion on the sensor data I would use an MCU with an FPU, like this one:

https://www.tindie.com/products/TleraCorp/ladybug-stm32l432-development-board/

or this one:

https://www.tindie.com/products/TleraCorp/dragonfly-stm32l47696-development-board/.

It might be difficult to get optimal perfromance using this method but you will just have to try it to see how bad it is for your application.

[MitalPattani]

Hey I got the pass through mode correctly, it does correctly bypass the first sensor but i can't get any sensor reading from the second sensor! Also even on i2c scan i can't read the second sensor even after turning ado high i get the address as 0x68 only.

[kriswiner]

You should be able to set the ADO pins and see both devices 0x68 and 0x69 on the bust at the same time. if not there is something worng with your code and/or hardware...

On Thu, Apr 5, 2018 at 12:57 PM, MitalPattani notifications@github.com wrote:

Reopened #250 https://github.com/kriswiner/MPU9250/issues/250.

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

[MitalPattani]

define ADO 1 // changed this in the library and pulled the ADO pin high on the board

void setup() { Wire.begin(); Serial.begin(9600); pinMode(intPin, INPUT); pinMode(buttonState, OUTPUT); digitalWrite(buttonState, HIGH); IMU.MPU9250SelfTest(IMU.SelfTest);

IMU.calibrateMPU9250(IMU.gyroBias, IMU.accelBias); IMU.initMPU9250(); IMU.initAK8963(IMU.magCalibration); delay(1000); I2Cscan(); }

void loop() {

// if (x==true) // { writeByte(MPU9250ADDRESS_1, INT_PIN_CFG, 0x12); writeByte(MPU9250ADDRESS_2, INT_PIN_CFG, 0x10); // } // else{ // writeByte(MPU9250ADDRESS_1, INT_PIN_CFG, 0x10); // writeByte(MPU9250ADDRESS_2, INT_PIN_CFG, 0x12);
// } // x=!x;

IMU.readAccelData(IMU.accelCount); IMU.getAres();

IMU.ax = (float)IMU.accelCount[0]IMU.aRes; // - accelBias[0]; IMU.ay = (float)IMU.accelCount[1]IMU.aRes; // - accelBias[1]; IMU.az = (float)IMU.accelCount[2]*IMU.aRes; // - accelBias[2];

IMU.readGyroData(IMU.gyroCount); // Read the x/y/z adc values IMU.getGres();

// Calculate the gyro value into actual degrees per second // This depends on scale being set IMU.gx = (float)IMU.gyroCount[0]IMU.gRes; IMU.gy = (float)IMU.gyroCount[1]IMU.gRes; IMU.gz = (float)IMU.gyroCount[2]*IMU.gRes;

IMU.readMagData(IMU.magCount); // Read the x/y/z adc values IMU.getMres(); // User environmental x-axis correction in milliGauss, should be // automatically calculated IMU.magbias[0] = +470.; // User environmental x-axis correction in milliGauss TODO axis?? IMU.magbias[1] = +120.; // User environmental x-axis correction in milliGauss IMU.magbias[2] = +125.;

// Calculate the magnetometer values in milliGauss
// Include factory calibration per data sheet and user environmental
// corrections
// Get actual magnetometer value, this depends on scale being set

IMU.mx = (float)IMU.magCount[0]IMU.mResIMU.magCalibration[0] - IMU.magbias[0]; IMU.my = (float)IMU.magCount[1]IMU.mResIMU.magCalibration[1] - IMU.magbias[1]; IMU.mz = (float)IMU.magCount[2]IMU.mResIMU.magCalibration[2] - IMU.magbias[2];

IMU.updateTime();

MahonyQuaternionUpdate(IMU.ax, IMU.ay, IMU.az, IMU.gxDEG_TO_RAD, IMU.gyDEG_TO_RAD, IMU.gz*DEG_TO_RAD, IMU.my, IMU.mx, IMU.mz, IMU.deltat);

IMU.yaw = atan2(2.0f ((getQ()+1) (getQ()+2) + getQ() (getQ()+3)), getQ() getQ() + (getQ()+1) *(getQ()+1)

• (getQ()+2) (getQ()+2) - (getQ()+3) (getQ()+3)); IMU.pitch = -asin(2.0f ((getQ()+1) (getQ()+3) - getQ() (getQ()+2))); IMU.roll = atan2(2.0f (getQ() (getQ()+1) + (getQ()+2) (getQ()+3)), getQ() getQ() - (getQ()+1) (getQ()+1)

• (getQ()+2) (getQ()+2) + (getQ()+3) (getQ()+3)); IMU.pitch = RAD_TO_DEG; IMU.yaw = RAD_TO_DEG;

  IMU.yaw -= 8.5; IMU.roll *= RAD_TO_DEG;

  IMU.yaw -= a; IMU.pitch -= b; IMU.roll -= c; // IMU.mx -= x; // IMU.my -= y; // IMU.mz -= z; IMU.delt_t = millis() - IMU.count;

  if(IMU.delt_t>500) { Serial.print(IMU.ax); Serial.print(", "); Serial.print(IMU.ay); Serial.print(", "); Serial.println(IMU.az);
  }

[MitalPattani]

that's the basic code haven't changed much in the library, I can read data from both sensors individually perfectly well! do i need to pullup the auxillary I2C as well?

[kriswiner]

I can't debug your code for you. Try to simply scan the I2C bus, you should see 0x68 and 0x69. Until you do you are wasting your time.

On Thu, Apr 5, 2018 at 1:13 PM, MitalPattani notifications@github.com wrote:

that's the basic code haven't changed much in the library, I can read data from both sensors individually perfectly well! do i need to pullup the auxillary I2C as well?

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

[MitalPattani]

hey, so apparently my on board jumper did not connect properly earlier hence, I couldn't select the ADO pin state correctly, now I soldered it correctly but when i pull the ADO pin high i get no reading at all and the device is not detected on the bus either,any ideas on why this is happening? Did i damage the sensor?

[kriswiner]

Maybe another assembly error?

On Fri, Apr 13, 2018 at 5:39 AM, MitalPattani notifications@github.com wrote:

hey, so apparently my on board jumper did not connect properly earlier hence, I couldn't select the ADO pin state correctly, now I soldered it correctly but when i pull the ADO pin high i get no reading at all and the device is not detected on the bus either,any ideas on why this is happening? Did i damage the sensor?

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

[MitalPattani]

Hardware: ADO --> VDD SDA-->A4(pullup 4.7K) SCL --> A5(pullup 4.7K) VDD--> 3.3V GND-->GND Software--> normal I2C scan from Arduino Playground

It's pretty basic, i don't see any assembly errors possible It works perfectly fine if i disconnect ADO, but instantly stops when i reconnect it.

[MitalPattani]

I got both 0X69 and 0x68 to work in by pass mode but i am getting one same reading from both the IMUs from both sensors. My Question is, when i configure the 0x68 to 0x12, does that also disable the magnetometer? Also do i need to intialize or caliberate both ICs in each loop or each time the device is powered?

void loop() {
digitalWrite(buttonState, HIGH); if (x==true) { writeByte(MPU9250ADDRESS_1, INT_PIN_CFG, 0x12); writeByte(MPU9250ADDRESS_2, INT_PIN_CFG, 0x10); } else{ writeByte(MPU9250ADDRESS_1, INT_PIN_CFG, 0x10); writeByte(MPU9250ADDRESS_2, INT_PIN_CFG, 0x12);
} x=!x;

[MitalPattani]

should I use SPI instead?

[kriswiner]

You might try adding delays...this must work.

I assume you tried to separately get data from the devices, does that work?

On Tue, Apr 17, 2018 at 3:19 AM, MitalPattani notifications@github.com wrote:

should I use SPI instead?

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

[MitalPattani]

I did that ,it worked, but only when the ado is 0, when ado is 1 it gives who_am_i as 0×FF and wrong readings

[kriswiner]

Well, then how will you ever read the second device??

When ADO of one device is 0, the device address is 0x68, when the ADO is 1, the device address is 0x69.

You should be able to toggle the ADO for any MPU9250 device and see the address change from 0x68 to 0x69.

For two M<PU9250 devcies on the same I2C bus, setting one device to ADO = 0 and the other to ADO = 1 should allow both devices, 0x68 and 0x69 to be seen in an I2C scan. If not, then you need to fix your hardware setup until this can be done.

On Tue, Apr 17, 2018 at 11:29 AM, MitalPattani notifications@github.com wrote:

I did that ,it worked, but only when the ado is 0, when ado is 1 it gives who_am_i as 0×FF and wrong readings

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

[MitalPattani]

Okay I think I didn't explain this properly, I have two ICs working perfectly well. I configured one as 0×69 and other as 0×68. I discovered both on i2c scan. Than I read them independently again I got a constant 0.13 reading on 0×69 accelerometer and who_am_i as 0×FF. I looked through other threads and you suggested to enable bypass. I did that and I put i2c scan in both if and else loops, I get all 0×68, 0×69, 0×0C in one scan and only 0×68 in the other. Also, the readings are same for both loops and they are garbage

[kriswiner]

OK, forget about the mag for a minute. Create a very simple sketch that just scans the I2C bud and reads the WHO_AM_I registers.

If you set one MPU9250 to ADO = 0 and one to ADO = 1 via hardware (I mean connect the first ADO to ground and the second ADO to 3V3) can you see both 0x68 and 0x69 on the I2C bus?

Can you now read the WHO_AM_I registers from the device at 0x68 and 0x69?

Until you can do both, forget about the other parts of the code.

On Tue, Apr 17, 2018 at 12:10 PM, MitalPattani notifications@github.com wrote:

Okay I think I didn't explain this properly, I have two ICs working perfectly well. I configured one as 0×69 and other as 0×68. I discovered both on i2c scan. Than I read them independently again I got a constant 0.13 reading on 0×69 accelerometer and who_am_i as 0×FF. I looked through other threads and you suggested to enable bypass. I did that and I put i2c scan in both if and else loops, I get all 0×68, 0×69, 0×0C in one scan and only 0×68 in the other. Also, the readings are same for both loops and they are garbage

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

[MitalPattani]

Yes I could I am getting the both the devices on the bus in the i2c scan and who_ am_I registers on both the devices are working just fine but the readings are the same! It's like it's reading from the same device!! And I am sorry late reply, got caught up with college. thanks again!

[kriswiner]

OK, now set up a simple sketch with the following in the setup (in pseudocode);

write(0x68, disablepassthru mode); write(0x69, disablepassthru mode); delay(1);

read(0x68, WHO_AM_I); print(WHO_AM_I); write(0x68, INT_CFG, enablepassthru mode); delay(1); read(0x0C, fuzeROM); print(fuzeROM); write(0x68, INT_CFG, disablepassthru mode);

read(0x69, WHO_AM_I); print(WHO_AM_I); write(0x69, INT_CFG, enablepassthru mode); delay(1); read(0x0C, fuzeROM); print(fuzeROM); write(0x69, INT_CFG, disablepassthru mode);

you should see different fuze ROM values for each of the two magnetometers. Keep increasing the delays until you do. Then you will lknow what sort of delay is required. Then move the last two parts into the loop and see if you can toggle between the mags.

On Sat, Apr 21, 2018 at 5:12 AM, MitalPattani notifications@github.com wrote:

Yes I could I am getting the both the devices on the bus in the i2c scan and who_ am_I registers on both the devices are working just fine but the readings are the same! It's like it's reading from the same device!! And I am sorry late reply, got caught up with college. thanks again!

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

[MitalPattani]

This is working with 1 seconds delay!

[kriswiner]

1 second is rather long, is this the shortest delay that can work?

On Sat, Apr 21, 2018 at 1:58 PM, MitalPattani notifications@github.com wrote:

This is working with 1 seconds delay!

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

[MitalPattani]

Sorry,It works with couple of microsecond also I made some coding error I didn't see first but the thing is when I try and read the mags actually or even the accelerometer for that matter I still read only 1 of them! I tried to simple enable one and disable the other and it reads 68 but doesn't read the values for 69!

[kriswiner]

I don't understand now, does it work or not?

I am just asking if you can read the fuse ROM now, can you read both sets of numbers? Can you read both sets of numbers with 1 us delay? 10 us delay or what?

forget about the rest...

On Sat, Apr 21, 2018 at 4:30 PM, MitalPattani notifications@github.com wrote:

Sorry,It works with couple of microsecond also I made some coding error I didn't see first but the thing is when I try and read the mags actually or even the accelerometer for that matter I still read only 1 of them! I tried to simple enable one and disable the other and it reads 68 but doesn't read the values for 69!

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

[MitalPattani]

I can read both sets in 2us of delay!

[kriswiner]

If you are sure you are reading both mags (getting different fuse ROM values), then the next step is to try to read the mag data from both. No reason now that this shouldn;t work with a few us delay.

On Sun, Apr 22, 2018 at 12:46 AM, MitalPattani notifications@github.com wrote:

I can read both sets in 2us of delay!

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

[stuermer6020]

Hi! Im also trying to get this to work and cant quit figure out why it doesnt work propely. I veryfied that I read the right magnetometer and the raw data from both sensors seems good. When i eneable sensor fusion i get almost the same values for both MPUs. Im guessing that it must be a error in my code but i cant seem to find it.... `void loop() {

for(int i=0;i<2;i++){
  uint8_t rawData;
  if(i==0){MPU9250_ADDRESS=0x69;}
  else {MPU9250_ADDRESS=0x68;}

  writeByte(MPU9250_ADDRESS, INT_PIN_CFG, 0x22);   
  delay(1); 
  readBytes(0x0C,AK8963_ASAX,3,&rawData); Serial.println(rawData);

// If intPin goes high, all data registers have new data if (readByte(MPU9250_ADDRESS, INT_STATUS) & 0x01) { // On interrupt, check if data ready interrupt readAccelData(accelCount); // Read the x/y/z adc values getAres();

// Now we'll calculate the accleration value into actual g's
ax = (float)accelCount[0]*aRes; // - accelBias[0];  // get actual g value, this depends on scale being set
ay = (float)accelCount[1]*aRes; // - accelBias[1];   
az = (float)accelCount[2]*aRes; // - accelBias[2];  

readGyroData(gyroCount);  // Read the x/y/z adc values
getGres();

// Calculate the gyro value into actual degrees per second
gx = (float)gyroCount[0]*gRes;  // get actual gyro value, this depends on scale being set
gy = (float)gyroCount[1]*gRes;  
gz = (float)gyroCount[2]*gRes;   

readMagData(magCount);  // Read the x/y/z adc values
getMres();
magbias[0] = +470.;  // User environmental x-axis correction in milliGauss, should be automatically calculated
magbias[1] = +120.;  // User environmental x-axis correction in milliGauss
magbias[2] = +125.;  // User environmental x-axis correction in milliGauss

// Calculate the magnetometer values in milliGauss
// Include factory calibration per data sheet and user environmental corrections
mx = (float)magCount[0]*mRes*magCalibration[0] - magbias[0];  // get actual magnetometer value, this depends on scale being set
my = (float)magCount[1]*mRes*magCalibration[1] - magbias[1];  
mz = (float)magCount[2]*mRes*magCalibration[2] - magbias[2];   

}

MahonyQuaternionUpdate(ax, ay, az, gxPI/180.0f, gyPI/180.0f, gz*PI/180.0f, my, mx, mz)

count = millis();
digitalWrite(myLed, !digitalRead(myLed));  // toggle led
}
}

// Serial print and/or display at 0.5 s rate independent of data rates
delt_t = millis() - count;
if (delt_t > 500 && last != MPU9250_ADDRESS) { // update LCD once per half-second independent of read rate
   last=MPU9250_ADDRESS;

yaw   = atan2(2.0f * (q[1] * q[2] + q[0] * q[3]), q[0] * q[0] + q[1] * q[1] - q[2] * q[2] - q[3] * q[3]);   
pitch = -asin(2.0f * (q[1] * q[3] - q[0] * q[2]));
roll  = atan2(2.0f * (q[0] * q[1] + q[2] * q[3]), q[0] * q[0] - q[1] * q[1] - q[2] * q[2] + q[3] * q[3]);
pitch *= 180.0f / PI;
yaw   *= 180.0f / PI; 
yaw   -= 3,5; // Declination at Danville, California is 13 degrees 48 minutes and 47 seconds on 2014-04-04
roll  *= 180.0f / PI;

if(SerialDebug) {
Serial.println(pitch, 2);
}

count = millis(); 
sumCount = 0;
sum = 0;    
}
}

  writeByte(MPU9250_ADDRESS, INT_PIN_CFG, 0x20); 

} }`

[kriswiner]

Sorry, I can't debug your code...

On Sat, May 5, 2018 at 3:27 PM, stuermer6020 notifications@github.com wrote:

Hi! Im also trying to get this to work and cant quit figure out why it doesnt work propely. I veryfied that I read the right magnetometer and the raw data from both sensors seems good. When i eneable sensor fusion i get almost the same values for both MPUs. Im guessing that it must be a error in my code but i cant seem to find it.... `void loop() {

for(int i=0;i<2;i++){ uint8_t rawData; if(i==0){MPU9250_ADDRESS=0x69;} else {MPU9250_ADDRESS=0x68;}

writeByte(MPU9250_ADDRESS, INT_PIN_CFG, 0x22); delay(1); readBytes(0x0C,AK8963_ASAX,3,&rawData); Serial.println(rawData);

// If intPin goes high, all data registers have new data if (readByte(MPU9250_ADDRESS, INT_STATUS) & 0x01) { // On interrupt, check if data ready interrupt readAccelData(accelCount); // Read the x/y/z adc values getAres();

// Now we'll calculate the accleration value into actual g's ax = (float)accelCount[0]aRes; // - accelBias[0]; // get actual g value, this depends on scale being set ay = (float)accelCount[1]aRes; // - accelBias[1]; az = (float)accelCount[2]*aRes; // - accelBias[2];

readGyroData(gyroCount); // Read the x/y/z adc values getGres();

// Calculate the gyro value into actual degrees per second gx = (float)gyroCount[0]gRes; // get actual gyro value, this depends on scale being set gy = (float)gyroCount[1]gRes; gz = (float)gyroCount[2]*gRes;

readMagData(magCount); // Read the x/y/z adc values getMres(); magbias[0] = +470.; // User environmental x-axis correction in milliGauss, should be automatically calculated magbias[1] = +120.; // User environmental x-axis correction in milliGauss magbias[2] = +125.; // User environmental x-axis correction in milliGauss

// Calculate the magnetometer values in milliGauss // Include factory calibration per data sheet and user environmental corrections mx = (float)magCount[0]mResmagCalibration[0] - magbias[0]; // get actual magnetometer value, this depends on scale being set my = (float)magCount[1]mResmagCalibration[1] - magbias[1]; mz = (float)magCount[2]mResmagCalibration[2] - magbias[2];

}

MahonyQuaternionUpdate(ax, ay, az, gxPI/180.0f, gyPI/180.0f, gz*PI/180.0f, my, mx, mz)

count = millis(); digitalWrite(myLed, !digitalRead(myLed)); // toggle led } }

// Serial print and/or display at 0.5 s rate independent of data rates delt_t = millis() - count; if (delt_t > 500 && last != MPU9250_ADDRESS) { // update LCD once per half-second independent of read rate last=MPU9250_ADDRESS;

yaw = atan2(2.0f (q[1] q[2] + q[0] q[3]), q[0] q[0] + q[1] q[1] - q[2] q[2] - q[3] q[3]); pitch = -asin(2.0f (q[1] q[3] - q[0] q[2])); roll = atan2(2.0f (q[0] q[1] + q[2] q[3]), q[0] q[0] - q[1] q[1] - q[2] q[2] + q[3] q[3]); pitch = 180.0f / PI; yaw = 180.0f / PI; yaw -= 3,5; // Declination at Danville, California is 13 degrees 48 minutes and 47 seconds on 2014-04-04 roll = 180.0f / PI;

if(SerialDebug) { Serial.println(pitch, 2); }

// With these settings the filter is updating at a ~145 Hz rate using the Madgwick scheme and // >200 Hz using the Mahony scheme even though the display refreshes at only 2 Hz. // The filter update rate is determined mostly by the mathematical steps in the respective algorithms, // the processor speed (8 MHz for the 3.3V Pro Mini), and the magnetometer ODR: // an ODR of 10 Hz for the magnetometer produce the above rates, maximum magnetometer ODR of 100 Hz produces // filter update rates of 36 - 145 and ~38 Hz for the Madgwick and Mahony schemes, respectively. // This is presumably because the magnetometer read takes longer than the gyro or accelerometer reads. // This filter update rate should be fast enough to maintain accurate platform orientation for // stabilization control of a fast-moving robot or quadcopter. Compare to the update rate of 200 Hz // produced by the on-board Digital Motion Processor of Invensense's MPU6050 6 DoF and MPU9150 9DoF sensors. // The 3.3 V 8 MHz Pro Mini is doing pretty well!

count = millis(); sumCount = 0; sum = 0; } }

writeByte(MPU9250_ADDRESS, INT_PIN_CFG, 0x20);

} }`

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

[stuermer6020]

I understand that. Im just thinking that im probably missing something abvious...

[kriswiner]

I would make sure that you are reading both sensors properly, then be aware that you will also need two different instantiations of the fusion filter and quaternion array, etc unless your intent is to somehow average the two sensor data streams to get one quaternion. If so I don;t understand why you'd bother...

On Sat, May 5, 2018 at 4:00 PM, stuermer6020 notifications@github.com wrote:

I understand that. Im just thinking that im probably missing something abvious...

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

[stuermer6020]

Thats probably the solution at the moment im using the the same quaternion array.... thank you haha

[stuermer6020]

Thanks for your help got it working now. Any hints on how to get more stable angles when moving the sensor around. I already did a quick calibration of the magnetometer.

[kriswiner]

Proper calibration of all three sensors?

On Sat, May 5, 2018 at 5:48 PM, stuermer6020 notifications@github.com wrote:

Thanks for your help got it working now. Any hints on how to get more stable angles when moving the sensor around. I already did a quick calibration of the magnetometer.

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

[stuermer6020]

I calibrate the gyro and acc with the sensors laying flat and the move the gyro around. Both with adapted function from your code. Will see if i can improve this. Thanks for your time!

[kriswiner]

Definitely need to calibrate the mag properlu for any chance at accurate heading.

https://github.com/kriswiner/MPU6050/wiki/Simple-and-Effective-Magnetometer-Calibration

On Sat, May 5, 2018 at 6:02 PM, stuermer6020 notifications@github.com wrote:

I calibrate the gyro and acc with the sensors laying flat and the move the gyro around. Both with adapted function from your code. Will see if i can improve this. Thanks for your time!

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

[stuermer6020]

I only need pitch,but it should be as stable as possible when accelerated quickly

[kriswiner]

Then use MPU6050, MPU6500, don't need a mag then.

On Sat, May 5, 2018 at 6:15 PM, stuermer6020 notifications@github.com wrote:

I only need pitch,but it should be as stable as possible when accelerated quickly

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