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" notifications@github.com 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" notifications@github.com 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" notifications@github.com 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.