Inav: No external mag detection on NAZE32 Rev6 7DOF

[jstremmler]

When I install iNav 1.2.0 stable on a Naze Rev6 7DOF, ( e.g. this one: https://www.aliexpress.com/item/New-Arrival-REV6-NAZE32-7DF-Flight-Controller-For-RC-Multirotors-Baseflight-Configurator/32596170179.html?spm=2114.01010208.3.1.23mz9A&ws_ab_test=searchweb201556_0,searchweb201602_1_10065_10068_112_10069_110_111_10017_109_108_10060_10061_10062_10057_10056_10055_10037_10054_301_10033_10059_10032_10058_10073_10070_10052_10053_10050_10051,searchweb201603_3&btsid=a1c262fc-710c-4580-8969-2101bcbb86b0 ) which has a barometer BMP 280 but no magnetometer installed an external magnetometer sitting in my GPS is no longer recognized.

Is there any reason why the external mag is not shown anymore?

My own compiled NAZE.hex file (RC4) from 08.28.2016 shows my external magnetometer HMC5883 correctly.....

[DzikuVx]

OK, looks like we have a problem with HMC5883 on Naze target. Looks like this is the same as #578

[pegaz666]

Try powering it from a different power rail - on one board I had simmilar issues and connecting it to 3.3v rail instead of 5v solved the problem. Probably there is some issues in timing?

[jstremmler]

Ok, I used my laboratory power supply, adjusted it to exactly 3.3V,connected it to the motor connectorsof the NAZE32 so that the NAZE was booted up with 3.3V.

Next I plugged in the USB plug from my PC and started the iNav configurator.

And again there was no magnetometer shown.

Again status showed 2 i2C errors :+1:

status

System Uptime: 43 seconds, Voltage: 0 * 0.1V (3S battery - OK), System load: 0.02
CPU Clock=72MHz, GYRO=MPU6500, ACC=MPU6500, BARO=BMP280
Cycle Time: 2005, I2C Errors: 2, config size: 1668

with the iNav version from 08.28.2016 I got no i2C errors and the magnetometer is detected and works!
So it seems like this bug of detecting an external HMC5883 has been introduced after 08.28.2016.

[stronnag]

See also #578, #586. Reverting https://github.com/iNavFlight/inav/commit/0f63bc68575f3ff03e5db5819f8e815545b334ea would be interesting. It was introduced late in the release cycle with little regression testing.

[DzikuVx]

My Flip32 (Naze32 clone) (with 0f63bc6 ) detects internal HMC5883l , testing continues

[DzikuVx]

External HMC5883l connected to Flip32 in INAV 1.2.0 is also detected without problems.
Anybody else can run those tests? @jstremmler can you revert 0f63bc6 and try then?

[Ralf-W]

No issue with my Afroflight Naze32 Rev6 and Beitian BN880 GPS:
2016-09-12 @ 21:38:31 -- Flight controller info, identifier: INAV, version: 1.2.0
2016-09-12 @ 21:38:31 -- Running firmware released on: Sep 7 2016 11:26:35
2016-09-12 @ 21:38:31 -- Board: AFNA, version: 2
version
INAV/NAZE 1.2.0 Sep 7 2016 / 11:26:35 (6cc415a)
status
System Uptime: 171 seconds, Voltage: 0 * 0.1V (3S battery - OK), System load: 0.03
CPU Clock=72MHz, GYRO=MPU6500, ACC=MPU6500, BARO=BMP280, MAG=HMC5883
Cycle Time: 2000, I2C Errors: 1, config size: 1668
bootlog
Time Evt Parameters
0: 0
0: 1
500: 19 (0, 0, 0, 0)
500: 19 (1, 0, 1, 3)
500: 19 (2, 0, 2, 3)
500: 19 (3, 1, 2, 2)
500: 19 (4, 2, 2, 2)
500: 19 (5, 3, 2, 2)
500: 19 (6, 4, 2, 2)
500: 19 (7, 5, 2, 2)
500: 19 (8, 6, 2, 2)
500: 18 (9, 6, 2, 1)
500: 18 (10, 6, 2, 1)
500: 2
551: 3
1087: 9 (7, 0, 0, 0)
1548: 10 (8, 0, 0, 0)
1600: 11 (4, 0, 0, 0)
1600: 12 (2, 0, 0, 0)
3259: 13 (0, 0, 0, 0)
3259: 4
3759: 5
3810: 8

[anbello]

My flip32 with inav 1.2 detects internal HMC5883l without problems but my naze32 rev6 from banggood has problems with inav 1.2 and internal HMC5883l as explained in #578

[jflyper]

Just a hunch.

1. set i2c_highspeed = off
2. USE_I2C_PULLUP in target.h

EDIT:
There were no USE_I2C_PULLUP for F1 targets...

[DzikuVx]

@anbello @jflyper might have a clue here. Could you try attaching pullups to SCL and SDA lines and verify if that helped?
4.7kOhm should be enough

[Snowboard-Nut]

(just signed up on Github to post this, forgive me if I am not following proper technical grammar/jargon or procedures to contribute to this issue. I just simply wanted to get my name in the hat as another person who has this problem and the behavior i've personally noticed.)

iNav Naze 1.2 Final:
My FC is actually a Dragonfly 32 w/ baro+mag. I physically removed the mag chip because my GPS puck has a HMC5883 mag in it. I then installed a BMP280 baro sensor into the GPS puck and tapped that BMP280's SDA/SCL/pwr/gnd lines right into the GPS puck's main harness internally so the puck is an all-in-one GPS/Baro/Mag. It has worked flawlessly since April.

Last night I upgraded to 1.2 Final from 1.2rc2 and now my Mag in the GPS puck won't work if I have BARO_HARDWARE = 4 (BMP280) using the baro i installed in the GPS puck. BUT, if i change to BARO_HARDWARE = 0 (FC onboard baro) then the mag in the GPS puck (HMC5883) works fine....

In regards to this problem, and in the spirit of trying to decipher typical Github procedure and understand that iNav is essentially built on top of Cleanflight, the fact that i'm seeing other people with this same type of issue with the newest Cleanflight is it safe to assume that the core Cleanflight code used in iNav 1.2rc2 is older than the core Cleanflight code used in iNav 1.2 Final and thus the problem stems from the newer core Cleanflight code?

[jflyper]

@Snowboard-Nut

FYI,
BARO_HARDWARE=0 does not mean on-board baro; it is another way of saying "Whatever found first". For NAZE (I believe you are using this target), INAV-1.2 (release) code probes baros in this order: BMP085, MS5611, then BMP280.

Some questions for clarification.

(1) I assume your on-boad baro is MS5611, correct?
(2) Are you using any break out board for the external BMP280?
(3) Can you tell us how you are wiring other pins of the external BMP280; especially the VDDIO and SDO pins.
(4) Does your external BMP280 work with BARO_HARDWARE=4?
(5) Does your internal baro work with BARO_HARDEARE=0?
(6) It will be very helpful if you can attach result of CLI bootlog command for two cases under INAV-1.2 (Release).

In regards to this problem, and in the spirit of trying to decipher typical Github procedure and understand that iNav is essentially built on top of Cleanflight, the fact that i'm seeing other people with this same type of issue with the newest Cleanflight is it safe to assume that the core Cleanflight code used in iNav 1.2rc2 is older than the core Cleanflight code used in iNav 1.2 Final and thus the problem stems from the newer core Cleanflight code?

Changes in CF does not automagically change things in iNav. How did you know CF users having the same issue?

[jflyper]

465 Increase GPIO speed to 50MHz for I2C pins

May be non-related. Just a reminder.

[Snowboard-Nut]

@jflyper

BARO_HARDWARE=0 does not mean on-board baro; it is another way of saying "Whatever found first".

This screenshot is what led me to believe that baro_hardware = 0 would cause the firmware to default to the particular target's default expected mag chip normally found onboard, which in the case of a Naze is HMC5883 so on the I2C bus it should have seen my mag in the GPS puck that is connected via I2C considering the onboard HMC5883 is physically "removed" from the FC. My HMC5883 integrated into the current GPS puck has worked perfect for months running everything iNav 1.2RC2 and previous back to 1.1.

on a side-note; I tried all 7 values for baro_hardware with same failure each time. More answer's coming to your other questions...

[jflyper]

@Snowboard-Nut
I'm afraid the document is out dated...

[anbello]

@DzikuVx I tried with pullups on i2c lines and it works: on my naze32 rev6 (clone from banggood) without pullups on several reboot I have near half times internal mag detected and the other half not detected, with pullups always detected. I have to specify that with iNav 1.1 I have no such problems.
Another thing that I don't understand is that even when the mag is detected I have: "I2C error: 1".

[bk79]

On spf3evo i constantly have 3 i2c errors on all the others i have 1 (pf3
deluxe and sparky)

Il 17/set/2016 14:55, "Andrea Belloni" [email protected] ha
scritto:

@DzikuVx https://github.com/DzikuVx I tried with pullups on i2c lines
and it works: on my naze32 rev6 (clone from banggood) without pullups on
several reboot I have near half times internal mag detected and the other
half not detected, with pullups always detected. I have to specify that
with iNav 1.1 I have no such problems.
Another thing that I don't understand is that even when the mag is
detected I have: "I2C error: 1".

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/iNavFlight/inav/issues/594#issuecomment-247767949,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALSWipwXTRWam0nYg7qjfAZAuqXdOxxVks5qq-M5gaJpZM4J6NXY
.

[jflyper]

@anbello Thanks for the report. Can you give us the value of the pull-ups you gave?

[jflyper]

@anbello @bk79
I2C errors could be ignored if they remain small; they are generated during the process of probing the I2C bus for possible device and ending up with timeouts.

Slow, but periodic error could be generated by turning on feature DISPLAY without connecting an appropriate OLED display.

However, errors that rises very rapidly, in hundreds per second, or sporadic errors should be noted.

[anbello]

@jflyper 4.7K on both scl and sda

[jflyper]

@anbello Thanks.
Do you have a DMM? It's great if you can measure the DC resistances across SDA/SCL and 3V3 (if you can find it) when the board is powered down.

[anbello]

I read 2K across sda and scl, 16k across sda/scl and gnd, infinite across sda/scl and 3V3/5V

[jflyper]

@anbello That's strange. You pulled up SDA and SCL to 3V3 with 4K7, so the SDA-GND and SCL-GND should be less than or equal to 4K7.

P.S. No need to measure SCL-SDA nor SCL-GND nor SDA-GND. I am curious about the total pull-up resistance for SCL and SDA.

[anbello]

ah OK I measured without the pullups ...
anyway they goes from 5V to sda/scl and WITH the pullups I measure 2K71 across sda/scl and 5V

[jflyper]

@anbello You pulled those up to 5V!?

[anbello]

@jflyper yes, now I understand I should have done up to 3V3
I will do as soon as I have some spare time

OT: anyway first time with GPS and POSHOLD no bad
https://youtu.be/ifZHPg9tOvY

[Snowboard-Nut]

@jflyper

Some questions for clarification.

(1) I assume your on-boad baro is MS5611, correct?

Correct.

(2) Are you using any break out board for the external BMP280?

The BMP280 sits on it's own breakout board that it came on. it is this one on eBay:
http://www.ebay.com/itm/GY-BMP280-3-3-High-Precision-Atmospheric-Pressure-Sensor-Module-for-Arduino-/351599340026

(3) Can you tell us how you are wiring other pins of the external BMP280; especially the VDDIO and SDO pins.

I have only 4 wires connected at the BMP280 breakout pads; VCC, GND, SCL, SDA. The BMP280 is installed discreetly inside my GPS puck. I simply used thin magnet wire and connected these 4 connections directly to the GPS puck's internal connector where it's cable plugs into the GPS's circuit board. Has worked great for months. The entire puck is being powered from the FC's 3v3 rail.

(4) Does your external BMP280 work with BARO_HARDWARE=4?

Yes.

(5) Does your internal baro work with BARO_HARDEARE=0?

Yes the FC's internal baro works with this. Although I can't use this as a work-around to this problem because my Dragonfly was from a bad batch that had filtering problems on the onboard MS5611 and has an infinite rise once powered on.

(6) It will be very helpful if you can attach result of CLI bootlog command for two cases under INAV-1.2 (Release).

Screenshot with BARO_HARDWARE = 0: (I2C Errors = 0)

Screenshot with BARO_HARDWARE = 4: (I2C Errors = 2)

How did you know CF users having the same issue?

As I was exploring Github>Inav>Issues I thought I saw reference to a Cleanflight Issue involving this problem while trying to locate it again to post here for reference, I think it was actually this; https://github.com/iNavFlight/inav/issues/552
so I believe I was mistaken while trying to learn to navigate Github and at this time I can find no Issues about this with Cleanflight.

[Snowboard-Nut]

One additional observation I've made is;

I have 2 identical GPS pucks, one I modified with the internal BMP280, and a stock one.

When I use the stock GPS puck the HMC5883 mag in the GPS puck works with either setting of BARO_HARDWARE = 4 or 0.

When I use my Modified GPS/BMP280 baro puck then the whole previously mentioned problem exists.

So it seems that simply setting the firmware for one baro option or the other isn't the problem, it is strictly when there actually is a BMP280 connected and attempted to be initialised/read in conjunction with a HMC5883 mag.

My Modified GPS puck has worked flawlessly through several versions of iNav up to and including 1.2rc2. I did not try other Release Candidates after rc2, I jumped straight to 1.2 Final Release.

[jflyper]

@Snowboard-Nut

Thanks for the additional info. I'll look into it.

One (or two) more thing. If you have a DMM, can you measure the DC resistance between SDA/SCL and 3V3 with everything connected? You can power the system off. Nice if you can do this for modded and un-modded puck.

[Snowboard-Nut]

Let me see what I can do, the BMP280 breakout had to be physically sanded down to fit inside the puck's plastic case halves which was tricky to sand it just right to keep traces intact for VCC/GND/SDA/SCL. And then the small enamel coated magnet wire I smoothered in hot glue to keep them suspended from any other contact. So you would like me to measure resistance with no power applied, from SCL>3v3 pad AND SDA>3v3 pad, correct?

[jflyper]

@Snowboard-Nut
You can hook this up to FC, and measure the resistance between VCC and SDA or SCL at the break out.

Oh, wait... Can you measure the resistance between GND and SDO pin at BMP280 also?

[Snowboard-Nut]

Getting to the limits of my Multimeter skills here. What scale should I measure on? Choices are 2000k, 200k, 20k, 2000, 200. Also, I assume that once I set the scale, i touch the leads and note that number then do my measurement and subtract that noted value from my measured value, correct?

[bk79]

20k

Il 17/set/2016 21:30, "Snowboard_Nut" [email protected] ha scritto:

Getting to the limits of my Multimeter skills here. What scale should I
measure on? Choices are 2000k, 200k, 20k, 2000, 200.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/iNavFlight/inav/issues/594#issuecomment-247801676,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALSWigX8-ppTreEHNc4Yi_tJx78WiXCGks5qrD_PgaJpZM4J6NXY
.

[Snowboard-Nut]

_I took the modified puck as pictured above with no cable connected nor power for these following readings:_
SDO > GND = 9.83@20k scale
VCC > SCL = 0@20k scale
VCC > SDA = 0@20k scale

_Then connected Cable to GPS board and FC with No Power applied:_
SDO > GND = 9.87@20k scale
VCC > SCL = .77@20k scale
VCC > SDA = .77@20k scale

I did not apply 3v3 power due to worrying about feeding voltage into my cheapo meter while in Resistance setting....

Hope this is helpful, please advise if there is more input I can give for this Issue.

[bk79]

Go to 2k scale

Il 17/set/2016 21:46, "Snowboard_Nut" [email protected] ha scritto:

i took the modified puck as pictured above with _no cable connected nor
power_ for these following readings:
SDO > GND = 9.83@20k scale
VCC > SCL = 0@20k scale
VCC > SDA = 0@20k scale

Cable connected to GPS board and FC with No Power applied:
SDO > GND = 9.87@20k scale
VCC > SCL = .77@20k scale
VCC > SDA = .77@20k scale

I did not apply 3v3 power due to worrying about feeding voltage into my
cheapo meter while in Resistance setting....

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/iNavFlight/inav/issues/594#issuecomment-247802807,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALSWivDaOYPAJISIhTu4bOjffeAB07YFks5qrEOQgaJpZM4J6NXY
.

[Snowboard-Nut]

Cable connected from GPS to FC, No Power applied:
SDO > GND = no reading@2000 scale
VCC > SCL = 773@2000 scale
VCC > SDA = 773@2000 scale

[Snowboard-Nut]

The SDO > Ground i'm measuring is at the breakout pads downstream of resistors. I'm not measuring at the pins of the BMP280 chip itself if that matters. In fact, all these measurements were made at the breakout's solder pads, not the the chip itself.

[bk79]

Looks like using internal pull up resistor...so when it's off depends on
how charged are mosfet inside stm32

[Snowboard-Nut]

Tasks show excessive baro refresh rates when a BMP280 is used.

With BARO_HARDWARE = 4 (BMP280 baro working, HMC5883 ,mag not recognized)

With BARO_HARDWARE = 0 (MS5611 baro working, HMC5883 mag working)

[bk79]

I would prefer ms5611...less noisy...

[Snowboard-Nut]

As well I would too, but as previously mentioned, my MS5611 baro on my Dragonfly from MRM back in 2014 had bad filtering and a constantly rising altitude value. My onboard MS5611 baro is absolutely worthless to me and at the time I decided to integrate a baro into the GPS puck I simply thought the BMP280's breakout boards that were easily available was the best fit for my integration idea.

[Snowboard-Nut]

In a breif, easy to understand explanation, does it appear that this overall issue of HMC5883 mags not being detected when a BMP280 baro is used is the result of the BMP280 baro driver taking so many resources that the HMC5883 mag detection basically gets swamped/ignored due to the excessive refresh cycles of the BMP280?

[martinbudden]

@Snowboard-Nut ,

I think this should fix the BMP280 baro problem: PR https://github.com/iNavFlight/inav/pull/612

Can you try it out?

I think you are probably right, if he BMP280 hogs the processor then the HMC5883 won't get a look in.

[Snowboard-Nut]

I would love to contribute and help, but i'm new to Github interaction and up until now I have only looked at the wiki section for iNav. I only signed up on here so I could interact with this Issue being discussed. I feel I am in over my head as I have never compiled custom firmware... Closest to compiling I have been is MWOSD compiling for my MinimOSD. If someone wants to help walk me through this, that's great and I will follow whatever steps, but I feel this environment is for more technical dev's than I am.

[Snowboard-Nut]

If someone wants to compile a hex and post it I will gladly try it.

[martinbudden]

Here's a hex file to try out.

inav_1.2.1_NAZE.hex.zip

[jflyper]

@Snowboard-Nut

You can try the martinbudden's hex, but in case it doesn't work, I want to give you something else to do based on your last measurements.

I did not apply 3v3 power due to worrying about feeding voltage into my cheapo meter while in Resistance setting....

It's okay, nice thinking!

SDO > GND = 9.83@20k scale
SDO > GND = 9.87@20k scale

These are okay...

I took the modified puck as pictured above with no cable connected nor power for these following readings:
VCC > SCL = 0@20k scale
VCC > SDA = 0@20k scale

This is still strange. I was expecting 5K~10K range value, because of the 10K on the BOB and additional pull-ups I see around the MAG chip.

Then connected Cable to GPS board and FC with No Power applied:
VCC > SCL = .77@20k scale
VCC > SDA = .77@20k scale

Then I believe these are too small (too strong). These are results of distributed pull-up resistors here and there. I seriously doubt that STM32 nor BMP280 can pull this down to 0V quickly enough.

You should adjust these by removing excess pull-up resistors, but you have to know where and what are the values of these resistors are.

As can be identified from the pic, there are at least:

(a) 10K on the BOB.
(b) Unknown value on the original (un-modded) puck (some are adjacent to the MAG chip)
This, you can measure using the un-modded puck you have.

(a) and (b) must add up to the un-connected value of the modded puck. If they don't, measurements are incorrect. (Try again.)

BTW, how long is your puck cable?

[Snowboard-Nut]

@martinbudden
I tried your hex. After flashing all I did was set BARO_HARDWARE = 4 and then STATUS to verify that BMP280 and HMC5883 were both properly detected. They were.

I then DISCONNECTED and CONNECT again. Both sensor's still detected.

Then I DISCONNECTED and unplugged USB cable to FC. And then reattached USB cable and CONNECT again and then the HMC5883 was gone again.

I repeated this above scenario twice with identical results. Seems the HMC5883 detection can't survive a hard reset of the FC while BMP280 is detected.

I checked TASKS and processor load was only a couple % so your hex did do something in regards to that.

[Snowboard-Nut]

@jflyper

After not much sleep I decided to read over everything up to this point. In this comment I made a few posts back:

I took the modified puck as pictured above with no cable connected nor power for these following readings:
SDO > GND = 9.83@20k scale
VCC > SCL = 0@20k scale
VCC > SDA = 0@20k scale

It got me thinking that I may have used 0 badly in the sense of resistance. I think in my mind I wrote 0 but should have said Open or No Reading. So to make sure I just did this test again and got different results using a different meter than before.

Current results for the modified puck with no cable connected nor power for these following readings:
SDO > GND = 9.77@20k scale
VCC > SCL = 5.78@20k scale
VCC > SDA = 5.77@20k scale

Current results using a different meter for the modified puck with cable connected to FC and no power results are the same as previous readings from earlier today:
Then connected Cable to GPS board and FC with No Power applied:
VCC > SCL = .76@20k scale
VCC > SDA = .76@20k scale

puck cable is about 10.5inches(26.5cm)

Keep in mind this modified puck has worked perfectly with 1.2rc2 and earlier versions.

[Snowboard-Nut]

Just now flashed back to 1.2rc2 and both the BMP280 and HMC5883 are detected and working again.

I then tried 1.2rc3 and the HMC5883 disappeared again.

Clearly 1.2rc2 was the last version that choosing BMP280 baro didn't cause a problem with HMC5883 mag.

BUT, on 1.2rc2 the BMP280 does show the excessive refresh rate (4200hz) but this setup flew fine for me previously so I will stick with it until a fix is found. Feel free to let me know if there is anything else I can test/check for you guys.

[jflyper]

497 !?

[anbello]

@jflyper now I have the pullups correctly done to 3V3, the pullups resistors are 4K62 and across SDA/SCL and 3V3 I measured 2K72

[anbello]

@jflyper ... and with this setup I have the internal mag (HMC5883) always detected

[Ralf-W]

@jflyper - Yes, I think, with #497 you found the key to close this issue!
With my setup, "set mag_hardware = 0" does work (Naze Rev 6 with onboard Baro BMP280 plus Beitian BN880 GPS with HMC5883).
With "set mag_hardware = 6", my compass is no longer recognized!
With "set mag_hardware = 2", my compass is recognized again!
Also, with "set mag_hardware = 0", my compass is recognized again!

[jflyper]

@anbello
Cool, and thanks for reporting!

[jflyper]

@Snowboard-Nut
Thanks for the re-measurement.

VCC > SCL = 5.78@20k scale
VCC > SDA = 5.77@20k scale

This makes much more sense. It looks like pull-up for your MAG is around 15K.

VCC > SCL = .76@20k scale
VCC > SDA = .76@20k scale

I still believe this is too strong, but since you have a working example, I will just shut up ;)

[jflyper]

@Ralf-W

With my setup, "set mag_hardware = 0" does work (Naze Rev 6 with onboard Baro BMP280 plus Beitian BN880 GPS with HMC5883).
With "set mag_hardware = 6", my compass is no longer recognized!
With "set mag_hardware = 2", my compass is recognized again!
Also, with "set mag_hardware = 0", my compass is recognized again!

I think this is what has been intended with the PR, isn't it?

[Snowboard-Nut]

@jflyper

497 !?

Experimented with MAG_HARDWARE settings in multiple combinations before even posting on here. Sad to say it does not help my issue at all. I've been bouncing all over from 1.2rc2, 1.2rc3, 1.2release and the same problem is repeatable every time and clearly started with rc3 upwards.

[jflyper]

@Snowboard-Nut
This is a hex for NAZE target at 00c9155, corresponding to #497.
I really don't think this is the one, but we can at least semi-bisect the RC2~RC3 range.

http://pastebin.com/PsZhX0fB

[Snowboard-Nut]

Works fine. I performed several hard Resets and it continued to work.

Advise if you need other builds tested.

[jflyper]

@Snowboard-Nut

Bisecting ...

inav_1.2.0_NAZE_de24cd0.hex

@Everybody else

Sorry for cluttering.

[Snowboard-Nut]

Working fine. Once again I did several hard Resets and all looks good.

[jflyper]

@Snowboard-Nut

inav_1.2.0_NAZE_b91d37e.hex

[Snowboard-Nut]

@jflyper

[jflyper]

@Snowboard-Nut

inav_1.2.0_NAZE_ 7e8ef5d.hex

[digitalentity]

Thanks for trying to track this down!

[Snowboard-Nut]

@jflyper @digitalentity

Bingo! As soon as SET BARO_HARDWARE = 4 is set the HMC5883 vanishes...

[jflyper]

@Snowboard-Nut

Help me pin point the precise location.

inav_1.2.0_NAZE_da48582.hex

[Snowboard-Nut]

@jflyper @digitalentity
My pleasure to contribute to the project!
HMC5883 vanishes as soon as BARO_HARDWARE = 4 is invoked.

[jflyper]

@Snowboard-Nut

This should be the last one.

inav_1.2.0_NAZE_f15440e.hex

[Snowboard-Nut]

@jflyper
Hold on. Disregard. flashed wrong firmware but on da48582 I am getting abnormal baro fluctuations:

[Snowboard-Nut]

@jflyper
Your f15440e.hex is actually da48582. Please check.

EDIT: the first copy of da48582 mag did not work.
your hex labeled as f15440e actually shows as da48582 in CLI Version but it worked?! and the last one is where i noticed the above baro fluctuations.
Screen shot of da48582 named as f15440e:

and here is the mislabeled version fully loaded with my CLI settings to check for other interactions:

[jflyper]

@Snowboard-Nut

Wow. Hang on ... How about this?

inav_1.2.0_NAZE_f15440e_revised.hex

[Snowboard-Nut]

@jflyper
Flashed and first thing i did was CLI Version and it shows da48582, should I continue my tests?

[jflyper]

@Snowboard-Nut
Deep apologies... Let me check what's going on on my side (will test the version with my naze).

Hmm... it boots with f15440e. Must be a stale copy buffer.

Okay, I confirmed it's f15440e with my naze.

inav_1.2.0_NAZE_f15440e_revised2.hex

[Snowboard-Nut]

@jflyper
HMC5883 working with BMP280. Baro sensor graph shows expected fluctuations (+/- .5 ft).
My complete CLI setup was imported and shows no other unexpected interactions.

Great working with you, anything else you need feel free to ask anytime.

[jflyper]

@Snowboard-Nut
Was my pleasure hunting with you.

@Folks
So, it was hunted down to da48582 (#515).
Only concern is that I had to tweak to build this one was to disable USE_FLASHFS and USE_FLASH_M25P16 to make some room (-4 bytes short!), but I don't think it matters.

[Snowboard-Nut]

@jflyper
Correction- Baro sensor graph showed expected behavior at the time I posted the last message. After going back into the Baro sensor graph a couple minutes later I see this now:

I am in a very controlled environment and this is most definitely abnormal behavior for the BMP280. Hmm

EDIT:
And yet I go to the Baro sensor graph again after this last reply and now I see this which is normal for me...

[Snowboard-Nut]

@jflyper
I am definitely getting Baro fluctuations every so often of 10ft+ that are Definitely Not normal where I am testing at. Any thought on this?

[bk79]

Faulty sensor?

[Snowboard-Nut]

@bk79 @jflyper
Definitely not faulty. Just flashed back to my trusty old 1.2rc2 and I have the baro behavior I've seen for months with previous iNav versions of about .25ft deviation. The last experimental build definitely has an influence on baro reading... I've been letting the graph run for several minutes on both versions and there is clearly a problem.
Here is 1.2rc2 baro sensor graph just now:

[martinbudden]

@Snowboard-Nut , presumably the experimental build did not have the baro fix I made. Are you getting baro problems with builds than include the baro fix?

[Snowboard-Nut]

@martinbudden
Not sure when your fix was implemented, but 1.2rc2 and previous show a great graph but the last 2 experimentals have shown huge random fluctuations of over 10 feet. I am in a sealed house, no AC or Heat kicking on and off, and No Wind outside, girlfriend asleep, and no doors or windows open.... I am in very well known environment for baro testing.... Was your fix included in 1.2rc2? I have flown 1.2rc2 since it came out and have watched graphs several times and I never see a deviation greater that 1 foot in extreme wind, and .5 foot while general flying on a calm day.

[jflyper]

@martinbudden
I think Snowboard-Nut is running f15440e (#517).
Next patch da48582 (#515) introduces the BARO-MAG detect woes.

@Snowboard-Nut
In your spare time, would you go back to experimental builds and find out when the fluctuation was introduced?

[martinbudden]

Well, I'm pretty sure the experimental builds didn't have the baro fix in them, so I'm not too worried about that. I've attached the latest build, can you test that for baro issues. And just for reference could you also do MAG test and show: tasks, bootlog, baro and mag hardware. Thanks.
inav_1.2.1_NAZE.hex.zip

[Snowboard-Nut]

Interesting observation using the last experimantal by jflyper:
If I simply flash and ONLY set BARO_HARDWARE=4 then the baro readings swing mildly acceptable of what I'm used to. But when I merge my CLI settings into it, much larger and aggressive deviation swings occur. Not sure if this is critical or not regarding the matter at hand.

@martinbudden
Will test and report....

[martinbudden]

@jflyper , @Snowboard-Nut , thanks for doing the bisect to track this down. Trouble is that PR https://github.com/iNavFlight/inav/pull/515 is the one that checks for proper initialisation of the compass. So I'm going to have to read the spec sheet again and do some thinking before I can come up with a fix.

[stronnag]

What is in your settings that might affect this, for example loop time and gyro sync?

[Snowboard-Nut]

@stronnag Im wondering this same thing too. loop and gyro are default:
`# mixer
mixer CUSTOM
mmix reset
mmix 0 1.000 -1.000 0.765 -1.000
mmix 1 1.000 -1.000 -0.765 1.000
mmix 2 1.000 1.000 0.765 1.000
mmix 3 1.000 1.000 -0.765 -1.000
smix reset

feature

feature -RX_PPM
feature -VBAT
feature -INFLIGHT_ACC_CAL
feature -RX_SERIAL
feature -MOTOR_STOP
feature -SERVO_TILT
feature -SOFTSERIAL
feature -GPS
feature -FAILSAFE
feature -SONAR
feature -TELEMETRY
feature -CURRENT_METER
feature -3D
feature -RX_PARALLEL_PWM
feature -RX_MSP
feature -RSSI_ADC
feature -LED_STRIP
feature -DISPLAY
feature -ONESHOT125
feature -BLACKBOX
feature -CHANNEL_FORWARDING
feature -TRANSPONDER
feature -AIRMODE
feature -SUPEREXPO
feature -VTX
feature -RX_NRF24
feature -SOFTSPI
feature RX_PPM
feature VBAT
feature MOTOR_STOP
feature SOFTSERIAL
feature GPS
feature FAILSAFE
feature TELEMETRY
feature ONESHOT125

beeper

beeper GYRO_CALIBRATED
beeper RX_LOST
beeper RX_LOST_LANDING
beeper DISARMING
beeper ARMING
beeper ARMING_GPS_FIX
beeper BAT_CRIT_LOW
beeper BAT_LOW
beeper GPS_STATUS
beeper RX_SET
beeper ACC_CALIBRATION
beeper ACC_CALIBRATION_FAIL
beeper READY_BEEP
beeper MULTI_BEEPS
beeper DISARM_REPEAT
beeper ARMED
beeper SYSTEM_INIT
beeper ON_USB

map

map AETR1234

serial

serial 0 1 115200 38400 0 115200
serial 1 2 115200 115200 0 115200
serial 30 4 115200 38400 19200 115200
serial 31 1 19200 38400 0 115200

set looptime = 2000
set i2c_overclock = OFF
set gyro_sync = OFF
set gyro_sync_denom = 2
set mid_rc = 1500
set min_check = 1100
set max_check = 1900
set rssi_channel = 8
set rssi_scale = 30
set rssi_ppm_invert = OFF
set rc_smoothing = ON
set input_filtering_mode = OFF
set min_throttle = 1150
set max_throttle = 1850
set min_command = 1000
set servo_center_pulse = 1500
set 3d_deadband_low = 1406
set 3d_deadband_high = 1514
set 3d_neutral = 1460
set 3d_deadband_throttle = 1000
set motor_pwm_rate = 400
set servo_pwm_rate = 50
set disarm_kill_switch = OFF
set auto_disarm_delay = 5
set small_angle = 25
set reboot_character = 82
set gps_provider = UBLOX
set gps_sbas_mode = AUTO
set gps_dyn_model = AIR_1G
set gps_auto_config = ON
set gps_auto_baud = ON
set inav_accz_unarmedcal = ON
set inav_use_gps_velned = ON
set inav_gps_delay = 200
set inav_gps_min_sats = 6
set inav_w_z_baro_p = 0.350
set inav_w_z_gps_p = 0.200
set inav_w_z_gps_v = 0.500
set inav_w_xy_gps_p = 1.000
set inav_w_xy_gps_v = 2.000
set inav_w_z_res_v = 0.500
set inav_w_xy_res_v = 0.500
set inav_w_acc_bias = 0.010
set inav_max_eph_epv = 1000.000
set inav_baro_epv = 100.000
set nav_disarm_on_landing = OFF
set nav_use_midthr_for_althold = OFF
set nav_extra_arming_safety = ON
set nav_user_control_mode = CRUISE
set nav_position_timeout = 5
set nav_wp_radius = 100
set nav_max_speed = 450
set nav_max_climb_rate = 140
set nav_manual_speed = 500
set nav_manual_climb_rate = 200
set nav_landing_speed = 200
set nav_land_slowdown_minalt = 500
set nav_land_slowdown_maxalt = 2000
set nav_emerg_landing_speed = 500
set nav_min_rth_distance = 500
set nav_rth_tail_first = OFF
set nav_rth_alt_mode = CURRENT
set nav_rth_altitude = 1000
set nav_mc_bank_angle = 30
set nav_mc_hover_thr = 1500
set nav_mc_auto_disarm_delay = 2000
set nav_fw_cruise_thr = 1400
set nav_fw_min_thr = 1200
set nav_fw_max_thr = 1700
set nav_fw_bank_angle = 20
set nav_fw_climb_angle = 20
set nav_fw_dive_angle = 15
set nav_fw_pitch2thr = 10
set nav_fw_roll2pitch = 75
set nav_fw_loiter_radius = 5000
set serialrx_provider = SPEK1024
set spektrum_sat_bind = 0
set telemetry_switch = OFF
set telemetry_inversion = ON
set frsky_default_lattitude = 0.000
set frsky_default_longitude = 0.000
set frsky_coordinates_format = 0
set frsky_unit = IMPERIAL
set frsky_vfas_precision = 0
set hott_alarm_sound_interval = 5
set battery_capacity = 0
set vbat_scale = 110
set vbat_max_cell_voltage = 43
set vbat_min_cell_voltage = 33
set vbat_warning_cell_voltage = 35
set current_meter_scale = 400
set current_meter_offset = 0
set multiwii_current_meter_output = OFF
set current_meter_type = ADC
set align_gyro = DEFAULT
set align_acc = DEFAULT
set align_mag = CW270FLIP
set align_board_roll = 0
set align_board_pitch = 0
set align_board_yaw = 0
set gyro_lpf = 42HZ
set moron_threshold = 32
set imu_dcm_kp = 2500
set imu_dcm_ki = 50
set imu_dcm_kp_mag = 10000
set imu_dcm_ki_mag = 0
set pos_hold_deadband = 20
set alt_hold_deadband = 75
set yaw_motor_direction = 1
set yaw_jump_prevention_limit = 200
set tri_unarmed_servo = ON
set servo_lowpass_freq = 400
set servo_lowpass_enable = OFF
set failsafe_delay = 10
set failsafe_off_delay = 200
set failsafe_throttle = 1000
set failsafe_kill_switch = OFF
set failsafe_throttle_low_delay = 100
set failsafe_procedure = RTH
set rx_min_usec = 885
set rx_max_usec = 2115
set acc_hardware = 0
set baro_use_median_filter = ON
set baro_hardware = 4
set mag_hardware = 0
set blackbox_rate_num = 1
set blackbox_rate_denom = 1
set blackbox_device = SERIAL
set magzero_x = 6
set magzero_y = -68
set magzero_z = 539
set acczero_x = 15
set acczero_y = 36
set acczero_z = -167
set accgain_x = 4080
set accgain_y = 4063
set accgain_z = 4062

rxfail

rxfail 0 a
rxfail 1 a
rxfail 2 a
rxfail 3 h
rxfail 4 h
rxfail 5 h
rxfail 6 h
rxfail 7 h
rxfail 8 h
rxfail 9 h
rxfail 10 h
rxfail 11 h
rxfail 12 h
rxfail 13 h
rxfail 14 h
rxfail 15 h
rxfail 16 h
rxfail 17 h

dump profile

profile

profile 0

aux

aux 0 0 0 1500 2100
aux 1 1 1 900 2100
aux 2 3 1 1300 1650
aux 3 10 1 1300 1650
aux 4 24 1 1650 2100
aux 5 23 2 1500 2100
aux 6 0 0 900 900
aux 7 0 0 900 900
aux 8 0 0 900 900
aux 9 0 0 900 900
aux 10 0 0 900 900
aux 11 0 0 900 900
aux 12 0 0 900 900
aux 13 0 0 900 900
aux 14 0 0 900 900
aux 15 0 0 900 900
aux 16 0 0 900 900
aux 17 0 0 900 900
aux 18 0 0 900 900
aux 19 0 0 900 900

adjrange

adjrange 0 0 0 900 900 0 0
adjrange 1 0 0 900 900 0 0
adjrange 2 0 0 900 900 0 0
adjrange 3 0 0 900 900 0 0
adjrange 4 0 0 900 900 0 0
adjrange 5 0 0 900 900 0 0
adjrange 6 0 0 900 900 0 0
adjrange 7 0 0 900 900 0 0
adjrange 8 0 0 900 900 0 0
adjrange 9 0 0 900 900 0 0
adjrange 10 0 0 900 900 0 0
adjrange 11 0 0 900 900 0 0

rxrange

rxrange 0 1000 2000
rxrange 1 1000 2000
rxrange 2 1000 2000
rxrange 3 1000 2000

servo

servo 0 1000 2000 1500 90 90 100 -1
servo 1 1000 2000 1500 90 90 100 -1
servo 2 1000 2000 1500 90 90 100 -1
servo 3 1000 2000 1500 90 90 100 -1
servo 4 1000 2000 1500 90 90 100 -1
servo 5 1000 2000 1500 90 90 100 -1
servo 6 1000 2000 1500 90 90 100 -1
servo 7 1000 2000 1500 90 90 100 -1

set nav_alt_p = 50
set nav_alt_i = 0
set nav_alt_d = 0
set nav_vel_p = 100
set nav_vel_i = 50
set nav_vel_d = 10
set nav_pos_p = 65
set nav_pos_i = 120
set nav_pos_d = 10
set nav_posr_p = 180
set nav_posr_i = 15
set nav_posr_d = 100
set nav_navr_p = 10
set nav_navr_i = 5
set nav_navr_d = 8
set deadband = 5
set yaw_deadband = 5
set throttle_tilt_comp_str = 0
set flaperon_throw_offset = 250
set flaperon_throw_inverted = OFF
set mode_range_logic_operator = OR
set default_rate_profile = 0
set gimbal_mode = NORMAL
set mag_declination = 140
set mag_hold_rate_limit = 40
set p_pitch = 36
set i_pitch = 26
set d_pitch = 23
set p_roll = 36
set i_roll = 26
set d_roll = 23
set p_yaw = 85
set i_yaw = 45
set d_yaw = 0
set p_level = 20
set i_level = 15
set d_level = 75
set max_angle_inclination_rll = 300
set max_angle_inclination_pit = 300
set gyro_soft_lpf_hz = 60
set acc_soft_lpf_hz = 15
set dterm_lpf_hz = 40
set yaw_lpf_hz = 30
set yaw_p_limit = 300
set iterm_ignore_threshold = 200
set yaw_iterm_ignore_threshold = 50
set rate_accel_limit_roll_pitch = 0
set rate_accel_limit_yaw = 10000

dump rates

rateprofile

rateprofile 0

set rc_expo = 70
set rc_yaw_expo = 20
set thr_mid = 50
set thr_expo = 65
set roll_rate = 20
set pitch_rate = 20
set yaw_rate = 20
set tpa_rate = 0
set tpa_breakpoint = 1500
`

[Snowboard-Nut]

@martinbudden
Here is the data you requested. I flashed your firmware and simply SET BARO_HARDWARE = 4 and then derived these results (baro results are what I expect and am used to seeing):

version

INAV/NAZE 1.2.1 Sep 19 2016 / 09:12:26 (8b895b2)

tasks

Task list rate/hz max/us avg/us maxload avgload total/ms
0 - SYSTEM 9 6 0 0.5% 0.5% 15
1 - GYRO/PID 498 1335 1187 66.9% 59.6% 219135
2 - SERIAL 100 615 2 6.6% 0.5% 589
3 - BEEPER 98 9 0 0.5% 0.5% 61
4 - BATTERY 49 19 0 0.5% 0.5% 160
5 - RX 49 172 141 1.3% 1.1% 3058
7 - COMPASS 9 229 198 0.7% 0.6% 831
8 - BARO 41 230 135 1.4% 1.0% 2323
Total (excluding SERIAL) 71.8% 63.8%

bootlog

Time Evt Parameters
0: 0
0: 1
500: 19 (0, 0, 0, 0)
500: 19 (1, 1, 0, 2)
500: 19 (2, 2, 0, 2)
500: 19 (3, 3, 0, 2)
500: 19 (4, 4, 0, 2)
500: 19 (5, 5, 0, 2)
500: 19 (6, 6, 0, 2)
500: 18 (7, 6, 0, 1)
500: 18 (8, 6, 0, 1)
500: 18 (9, 6, 0, 1)
500: 18 (10, 6, 0, 1)
500: 2
636: 9 (2, 0, 0, 0)
752: 10 (3, 0, 0, 0)
773: 11 (4, 0, 0, 0)
774: 12 (2, 0, 0, 0)
2432: 13 (0, 0, 0, 0)
2432: 4
2933: 8

get baro_hardware

baro_hardware = 4
Allowed range: 0 - 5

get mag_hardware

mag_hardware = 0
Allowed range: 0 - 7

[Snowboard-Nut]

@martinbudden
This after I merge my CLI settings into your build. The CLI basically just enables GPS, FrSky Inverted Telem, Softserial. Baro reading definitely goes into fluctuation again with a massive 10ft+ swing on the baro:

INAV/NAZE 1.2.1 Sep 19 2016 / 09:12:26 (8b895b2)

tasks

Task list rate/hz max/us avg/us maxload avgload total/ms
0 - SYSTEM 9 11 0 0.5% 0.5% 8
1 - GYRO/PID 499 1538 1366 77.2% 68.6% 117358
2 - SERIAL 98 910 2 9.4% 0.5% 382
3 - BEEPER 99 9 0 0.5% 0.5% 29
4 - BATTERY 49 22 0 0.6% 0.5% 77
5 - RX 49 192 161 1.4% 1.2% 1573
6 - GPS 24 473 76 1.6% 0.6% 416
7 - COMPASS 9 232 201 0.7% 0.6% 388
8 - BARO 41 232 137 1.4% 1.0% 1085
10 - TELEMETRY 249 129 3 3.7% 0.5% 212
Total (excluding SERIAL) 87.6% 74.0%

bootlog

Time Evt Parameters
0: 0
0: 1
500: 19 (0, 0, 0, 0)
500: 19 (1, 1, 0, 2)
500: 19 (2, 2, 0, 2)
500: 19 (3, 3, 0, 2)
500: 19 (4, 4, 0, 2)
500: 19 (5, 5, 0, 2)
500: 19 (6, 6, 0, 2)
500: 18 (7, 6, 0, 3)
500: 18 (8, 6, 0, 3)
500: 18 (9, 6, 0, 3)
500: 18 (10, 6, 0, 3)
500: 2
636: 9 (2, 0, 0, 0)
752: 10 (3, 0, 0, 0)
773: 11 (4, 0, 0, 0)
774: 12 (2, 0, 0, 0)
2432: 13 (0, 0, 0, 0)
2432: 4
2983: 5
3033: 7
3033: 8

get baro_hardware

baro_hardware = 4
Allowed range: 0 - 5

get mag_hardware

mag_hardware = 0
Allowed range: 0 - 7

[Snowboard-Nut]

Does this have anything to do with the high refresh rate of the BMP280? For example, when my CLI merge activates softserial, GPS, and Telem perhaps the baro filter is impacted from lack of processing power?

[martinbudden]

It could be a processing power issue. What do you have attached to softserial, and what happens when you switch off softserial?

[Snowboard-Nut]

@martinbudden
softserial is FrSky Inverted Telem @ 19.2 and Bluetooth MSP @ 19.2

Neither of which is active NOR POWERED while doing all this testing via USB hard line to Naze. Do you feel it's worth trying to disable just softserial considering it's not being utilized during this testing session?

[martinbudden]

I think it's worth disabling it, just to see if it makes a difference. Just to get as much data about the problem as possible.

[Snowboard-Nut]

@martinbudden
This baro graph is with softserial disabled. The graph has smoothed somewhat without a massive 10ft+ swing, but still very notchy and not near as smooth as the first graph I posted before my CLI merge, It would seem to me that by disabling softserial that it lowered CPU cycles slighty which in return slightly improved the baro response to a smoother curve with less aggressive random swings but it still is nowhere near as smooth a curve as the first sample graph I showed you that was after I simply flashed your build and SET BARO_HARDWARE = 4.

In my mind(pure sleep-deprived delirious speculation) , it seems the STM32 is being taxed too hard after such things as softserial, gps, telem, oneshot are enabled and therefore starving the baro filtering. But I also think the high refresh rate of the BMP280 is absorbing more precious cycles then needed..... after all just look at the baro refresh rate versus the oh-so critical gyro refresh rate....

[jflyper]

@martinbudden @digitalentity
Have you took a look at this? cleanflight/cleanflight:#2310

Aren't I2CErrors values we are looking at in above screen shots only reflects fatal bus errors that needs bus banging and restarting, and not counting minor errors such as slave addressing NAKs?

[giacomo892]

I can confirm that my HMC5883 on NAZE target is detected and used for some minutes and then it is simply detached without any error.

[jflyper]

@giacomo892
Can you elaborate how it is "detached"?
No more movements in 3D model, absence in cli status, that kind of thing.

[giacomo892]

@jflyper Sure! I startup my "custom made" Naze board with MPU6050+BMP180+HMC5883L connected the same I2C bus (there is no difference if I attach the mag to the auxiliary I2C bus pins of the MPU6050 since they are configured in bypass mode. ).

What happens is that sometimes after some time the MAG green light in the configurator shutoff and I suppose that from that time the heading is only calculated based on the gyro readings.

The heading still precise (and poiting the right direction since it had the mag reference before) for some time but then start to drift as expected.

ps: does someone even considered to use the MPU6050 secondary bus the let MPU6050 reading the mag? It worked much better than directly connecting the mag the main i2c bus

[jflyper]

@giacomo892 Thanks!

[jstremmler]

Ok finally I applied revert 0f63bc6 with iNav 1.2.1 and it works! Here is my status and bootlog:

[digitalentity]

@jstremmler what did your log look like before the revert?

[jstremmler]

@digitalentity: Here ist the status and bootlog right after flashing downloaded iNAV 1.2.1. NAZE.hex file from github:

[digitalentity]

@jstremmler very interesting. Looks like 0f63bc68575f3ff03e5db5819f8e815545b334ea has nothing to do with the issue. It's mag detection that fails and that commit has nothing to do with detection - it only affects MAG init. Something to think about. Can you also try the latest "development" branch?

[stronnag]

Ho hum, development: https://github.com/iNavFlight/inav/pull/624#event-797558017. Interesting to see what happens here.

[jflyper]

@stronnag
Yeah, I mentioned it. But it only shows correct number of I2CErrors...

[digitalentity]

I think it's somehow related to busy-loop delays in I2C driver. We need to change them to use proper timings instead of arbitrary empty loops that might be optimised out by the compiler.

[jstremmler]

I just cloned the iNav.git file again because I had modified files compass_hmc5883l.c, logging_codes.h and logging.c before. Next I compiled NAZE.hex again and flashed the firmware.... And it worked as well:

So now I have a downloaded NAZE.hex file from github which doesn't detect the magnetometer correctly and a self-compiled one from the actual development which works..... Do we have an explanation??

[stronnag]

And which compiler version are you using?

[jstremmler]

I wrote before: cygwin64, latest version......

[stronnag]

which helps no one .... the actual compiler version please.

arm-none-eabi-gcc --version

[jstremmler]

Version is CYGWIN64 (2.874) Have a look here: https://www.cygwin.com/ and here : https://cygwin.com/ml/cygwin/2016-06/msg00064.html

[jflyper]

When I was investigating the cleanflight/cleanflight#2310, timings for normal cycles were okay, but I became aware of cleanflight/cleanflight#2272 also.

And, was there a build environment change recently? I was forced to download 5.4 toolchain.

[stronnag]

You can use whatever tool chain you like, e.g arm-none-eabi-gcc 6.2.0 works well for me; that was what I was (futility) attempting to determine, as arm-none-eabi-gcc 5.x has not generated good results for me.

[jstremmler]

So, as up to now we have no explanation, let me do a speculation:

Can this be an issue of different compilers by which we produce the hex code???

[digitalentity]

Actually yes. Build 1.2.1 was by my mistake compiled using gcc-5.4.1 which might explain the ill behaviour.

[digitalentity]

@jstremmler can you check the latest development branch? We've made a fix to I2C driver

[digitalentity]

I'm closing this. We don't hear about mag problems for a while now. Feel free to re-open if issue persists.

[nipunnawanjana1]

it work for me https://youtu.be/9Es1NzxLyWE