issues with mag and baro when i2c gps enabled

Question

issues with mag and baro when i2c gps enabled

estechnical opened this issue 9 years ago · 16 comments

On multiwii v2.5 board with 328p if I enable i2c gps and msp wp command set the magnetometer and barometer update erratically and show odd values. Everything works fine with i2c gps disabled.

Answer 1 · 2015-08-27T14:53:09.000Z

Are you able tot check each device adress is not overlapping!
Op 27 aug. 2015 15:16 schreef Ed Simmons notifications@github.com:On multiwii v2.5 board with 328p if I enable i2c gps and msp wp command set the magnetometer and barometer update erratically and show odd values. Everything works fine with i2c gps disabled.

—Reply to this email directly or view it on GitHub.

Answer 2 · 2015-08-27T15:12:18.000Z

Hi, thanks for quick reply, is there an obvious place to look for the sensor I2C addresses in the code or online?

Ed

Answer 3 · 2015-08-27T16:28:42.000Z

In the software under sensors lookup the type of your baro and mag there in the code i2c adres is present. Now you have to find the code for the GPS. The adres on your GPS device should match.
Op 27 aug. 2015 17:12 schreef Ed Simmons notifications@github.com:Hi, thanks for quick reply, is there an obvious place to look for the sensor I2C addresses in the code or online?

Ed

—Reply to this email directly or view it on GitHub.

Answer 4 · 2015-08-27T16:41:41.000Z

A bit more info, I'm using tI2C_GPS_Nav 2.2 and the issue seems to appear once a GPS fix has been acquired. As soon as this happens I get garbage readings or none at all on mag and baro.

Answer 5 · 2015-08-27T16:42:39.000Z

Also, I am using the default I2C addresses for the I2C GPS nav board firmware and have #define HK_MultiWii_SE_V2 in my config.h

Answer 6 · 2015-08-27T17:26:44.000Z

Hi,

I have looked for the I2C addresses of the GPS nav board (default of
0x20 & matching in the corresponding nav board firmware) and the
MAG_ADDRESS 0x1E, BMP085_ADDRESS 0x77, MPU6050_ADDRESS 0x68 and I have
nothing else on the I2C bus.

It seems like the main 328 is unstable when I have the #define I2C_GPS
enabled.

Running everything from my bench supply and testing things through I
noticed a couple of unexpected resets when I powered on my TX. Nothing
like this happens with the I2C_GPS disabled, even if I leave it attached
to the I2C bus.

Any other ideas?

Many thanks,
Ed

On 27/08/15 17:28, Fvk1960 wrote:

In the software under sensors lookup the type of your baro and mag
there in the code i2c adres is present. Now you have to find the code
for the GPS. The adres on your GPS device should match.
Op 27 aug. 2015 17:12 schreef Ed Simmons
notifications@github.com:Hi, thanks for quick reply, is there an
obvious place to look for the sensor I2C addresses in the code or online?

Ed

—Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#16 (comment).

Ed Simmons
ed@estechnical.co.uk
www.estechnical.co.uk

Answer 7 · 2015-08-27T17:54:35.000Z

Sorry no idea but you could try different multiwii versions from 2.1 till 2.4
Or check multiwii forum on i2c GPS
Good luck.
Op 27 aug. 2015 19:26 schreef Ed Simmons notifications@github.com:Hi,

I have looked for the I2C addresses of the GPS nav board (default of
0x20 & matching in the corresponding nav board firmware) and the
MAG_ADDRESS 0x1E, BMP085_ADDRESS 0x77, MPU6050_ADDRESS 0x68 and I have
nothing else on the I2C bus.

It seems like the main 328 is unstable when I have the #define I2C_GPS
enabled.

Running everything from my bench supply and testing things through I
noticed a couple of unexpected resets when I powered on my TX. Nothing
like this happens with the I2C_GPS disabled, even if I leave it attached
to the I2C bus.

Any other ideas?

Many thanks,
Ed

On 27/08/15 17:28, Fvk1960 wrote:

In the software under sensors lookup the type of your baro and mag
there in the code i2c adres is present. Now you have to find the code
for the GPS. The adres on your GPS device should match.
Op 27 aug. 2015 17:12 schreef Ed Simmons
notifications@github.com:Hi, thanks for quick reply, is there an
obvious place to look for the sensor I2C addresses in the code or online?

Ed

—Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#16 (comment).

Ed Simmons
ed@estechnical.co.uk
www.estechnical.co.uk

—Reply to this email directly or view it on GitHub.

Answer 8 · 2015-08-27T18:34:01.000Z

There is an topic on the forum but does not help very much but same problem appearance .
Topic connecting elements.all sensors gone Mad een adf GPS.
Secondly are both i2c on GPS and fc same voltage ie 5v versus 3.3v?
Thans all i can find on this.

Answer 9 · 2015-08-27T22:04:13.000Z

Thanks for more info...

I have checked everything is on the same voltage I2c bus.

I've managed to narrow it down a bit... the problem occurs only when 5
or more satellites are in the gps data! As soon as this happens the mag
and baro data is useless but the accel and gyro data remains ok.

The cycle time becomes hugely erratic when the GPS fix is >5 satellites
too...

At least this gives something to look for.

Thanks,
Ed

On 27/08/15 19:34, Fvk1960 wrote:

There is an topic on the forum but does not help very much but same
problem appearance .
Topic connecting elements.all sensors gone Mad een adf GPS.
Secondly are both i2c on GPS and fc same voltage ie 5v versus 3.3v?
Thans all i can find on this.

—
Reply to this email directly or view it on GitHub
#16 (comment).

Ed Simmons
ed@estechnical.co.uk
www.estechnical.co.uk

Answer 10 · 2015-08-27T22:51:17.000Z

I've found out that the 328p hasn't got enough memory for the following to all be enabled at once:

#define I2C_GPS
#define USE_MSP_WP
#define VBAT
#define POWERMETER_HARD

even though it compiles (with a warning about low memory).

As an experiment in finding out how close to the boundary this was in terms of memory, I changed:

unsigned char axis;
uint32_t dist;        //temp variable to store dist to copter
int32_t  dir;         //temp variable to store dir to copter

at the top of GPS_Compute() to be static and the problem with sensors existed immediately after flashing the board. I put this back how it was...

I reduced the memory footprint of the power metering:

#define PSENSOR_SMOOTH 8           // len of averaging vector for smoothing the PSENSOR readings; should be power of 2; set to 1 to disable
#define VBAT_SMOOTH 8              // len of averaging vector for smoothing the VBAT readings; should be power of 2; set to 1 to disable

and now it runs fine with a gps fix and doesn't reset when I power on my TX.

Is there any code I should be checking if I want to fly to waypoints? Will I need to check this doesn't cause crazy sensors too?

I checked I could select GPS hold and GPS home ok, this seems to work but I'm not flying right now.

Thanks :)
Ed

Answer 11 · 2015-09-10T15:27:42.000Z

Hi,

I have tried a couple of flights since this issue appeared resolved, but I still don't trust the firmware that is compiled for the 328 if the i2c gps is enabled...

For some reason today my quad suddenly engaged GPS home mode when I was flying in Horizon mode (as if it thought it was outside the FENCE DISTANCE parameter) when hovering a few meters from me and I lost control and crashed. I was connected via bluetooth to the quad and EZgui announced the mode change.

I compiled the firmware from this github repo for atmega 328p using arduino 1.6.4.

My config file has QUADX, HK_MultiWii_SE_V2, failsafe, I2C gps, standard RC setup. Nothing much to note... it compiles and flies well in Horizon mode. I have now seen about 5 'incidents' which can only be described as something else taking over and driving for a while. I don't think that the firmware built by this combination of things is trustworthy.

Can anyone comment on this? Have you got this combination to work?

Thanks!

Answer 12 · 2015-09-11T12:04:07.000Z

Hi Matthias,

Very interesting... if you want to discuss this any more I also have a forum thread here:
http://www.multiwii.com/forum/viewtopic.php?f=18&t=6709

Your issue (given the different hardware we have) doesn't sound like the same issue I was having, unless you're also running very low on memory.

Is it possible that your GPS location is wrong/moving in such a way that the FENCE DISTANCE is exceeded? Does your copter arm OK then switch into the GPS home mode?

The more I hear the more I am intrigued by this weird problem!

Answer 13 · 2015-09-11T12:16:50.000Z

I was referring to the RAM, not program memory... 328p has 1k and 2560 is 8k. seems unlikely that it is memory... does your GPS indicate a stable lat & lon?

Answer 14 · 2015-09-11T18:25:05.000Z

Have you tried clearing the eeprom and reloading the firmware + config?

Does cycle time remain roughly constant and have you ever seen the controller reset or brown-out?

Answer 15 · 2015-09-12T09:32:11.000Z

From what I can tell, when the mode changes spontaneously it is due to something modifying the contents of uint8_t rcOptions[CHECKBOXITEMS];

This is a serious bug if this is occurring - in my case I think this was happening because I was running out of ram and the heap/stack corruption that results.

In your case....???? I have no idea. Please can you share your config.h file so I can take a look?

Thanks,
Ed

Answer 16 · 2015-09-13T21:26:04.000Z

Ok, thanks, I'll take a proper look soon...

Can you share a screenshot of your configuration in the GUI? Also, what is the radio setup like? You have a 3pos switch or similar as an Aux I assume?

Thanks,
Ed