Inav 1.6 working external compass disappears Omnibus F3 AIO

[Waltec]

My working setup (decent position hold and altitude hold) loses the magnetometer after about 5 minutes powered up. Symbol goes red but found through configuration brings it back temporarily.

External m6n gps module with mag Omnibus F3 AIO S500 frame Magnetometer at least an inch from any power lines

I do see a small number of i2c errors on the inav dashboard but when they are there the mag is still working.

Any thoughts or recommendations on how to troubleshoot?

[WaspFPV]

Same issue here. Omnibus F3 with Beitian BN880 (ublox m8n + hmc5883) Compass would get stuck reporting a specific heading. (checked it in telemetry. Heading would respond to gyro, but always fall back to a specific heading when held still)

Disabling i2c_overclock fixed it for me. Configurator showed 1 i2c error on startup with i2c_overclock on. No i2c errors with i2c_overclock off.

[Waltec]

I'm not new to copters but regarding the bowels of the programming/setup I'm at the early part of the learning curve. Is it a short enough explanation that you can tell me how you sorted that out?

Sent from my iPhone

On Apr 10, 2017, at 11:59 AM, André notifications@github.com wrote:

Same issue here. Omnibus F3 with Beitian BN880 (ublox m8n + hmc5883) Disabling i2c_overclock fixed it for me.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[diode121]

Tried disabling i2c_overclock, still no luck. Any more ideas?

[Waltec]

Personally no. Just to frustrate myself further I went to a sp f3 deluxe board to see if things went smoother there. On 1.6.1 the mag and barometer don't show up right after firmware install. If you configure them in the settings the I2c errors start stacking up and the cpu load goes over 700 or so.

When I went back to 1.5, I think it was, the board then showed mag and baro as you would expect at first boot up after firmware install.

I'm getting the idea that i2c had been somehow "broken" (I'm not a developer, far from it) in recent releases.

I'm beginning to think that inav, while I very much appreciate and admire the developers' efforts, doesn't have sufficient numbers of people coding to support what they're trying to achieve on such a wide breadth of boards. I'd pitch in if I could but I have zero coding skills.

I'm very much hoping I'll be proven wrong but for now I'm going to be a little more "wait and see" rather than "go do" on inav. I've been too long on the bench with marginal results vs my APMs.

Sent from my iPhone

On Apr 23, 2017, at 8:07 AM, diode121 notifications@github.com wrote:

Tried disabling i2c_overclock, still no luck. Any more ideas?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[stronnag]

I would say we don't have enough testers (and I mean people prepared to do rigorous, repeatable testing) on the development branch, across the mass of supported boards.

OTOH, I2C mag works perfectly and reliably on the three boards I test regularly against development (SPRF3, SPRF3EVO, Omnibus F3 AIO), and when they don't work it's my mechanical / electrical error rather than code e.g. https://vimeo.com/214399416. The firmware compensates for my bad connector very well.

[Waltec]

Stronnag at al,

I'm not sure if you found my comment to be critical but it wasn't meant to be. If there is a human resource constraint I was suggesting it as more of a fact rather than a choice someone is making.

If I can help as an avid tinkerer, practiced but still novice systems guy, non existent coder I'm happy to help where demands a 5 year old and 8 year old "allow".

Interesting issue with my sp f3 deluxe boards, the one I got from Banggood sees the mag and baro as expected in 1.6.1. The two I just received from aliexpress are the ones that only seem to work on 1.5.

Its not clear to me that there are "OE" sp f3 deluxe boards available to buy so BG and AE are my sources at present... Not sure is that disqualifies me or not. 😬

Sent from my iPhone

On Apr 23, 2017, at 2:42 PM, stronnag notifications@github.com wrote:

I would say we don't have enough testers (and I mean people prepared to do rigorous, repeatable testing) on the development branch, across the mass of supported boards.

OTOH, I2C mag works perfectly and reliably on the three boards I test regularly against development (SPRF3, SPRF3EVO, Omnibus F3 AIO), and when they don't work it's my mechanical / electrical error rather than code e.g. https://vimeo.com/214399416. The firmware compensates for my bad connector very well.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[stronnag]

Not at all; my view is that there are sufficient developers (at least for core functions), but insufficient testers, particularly with the raft of platforms we support. As you infer, this plethora of boards is made worse by the variable quality of some of the clones. That I2C works perfectly on one board doesn't mean there are not problems on a clone, where it's not just the board layout that is cloned, but possibly some of sensors as well.

[digitalentity]

HMC5883 and HMC5983 compass sensors are EOL, currently most chips out there are cloned and of random quality. Quality issue is worsened with total absence of QA for boards coming from China. It's a lottery - exactly the same setup may work for one person and randomly fail for the other. This has nothing to do with firmware - INAV does it best trying to recover from I2C failures but in most cases its impossible.

I strongly recommend buying the boards and other components from trusted sources - preferrably official manufacturers/sellers. Slightly higher price pays back quite soon.

[digitalentity]

Regarding some setups "working" in INAV-1.5.x: the fact that sensor is detected doesn't necessary mean that it functions properly. Compass is most frequent source of fly-aways in pos-hold, failed RTH etc, that's why in INAV 1.6 we introduced hardware failure detection.

I can't say for everybody, but I would prefer sensor malfunction being detected and accounted for rather than go unnoticed and cause issues when failing sensor is needed.

[Waltec]

I don't disagree at all with your comments but here's what I reminded myself of when looked again at buying from authorized sources:

-All out of stock

-Roughly 3x pricing vs Banggood (SPs website looks to have them in stock)

-Horrible reviews of the board on one authorized U.S. source that I've used in the past.

Seeing this sort of variability on other boards I've purchased in the past and especially watching 3dr's convoluted success and ultimate exit (failure?) I've been left with the impression that OE or authorized sellers look to be having as much success getting a quality product as I have. That is to say limited/spotty.

It leaves me with the question, if I'm going to spend 3x to get a good board, exactly which board do I choose and where do I get it?

I'm coming to the conclusion that the marketers of the official boards have only marginally more control over the quality that the manufacturers that actually produce the board deliver than say a major retailer (really store front) like Banggood.

I'm probably fostering an argument which is not my intention. I guess what I'm saying is that the more I try to diy myself a reliable, autonomous flight copter by exploring, tinkering and spending, the broker I get with limited success

I'm not quite to the point I spend $1,500 with DJI to get there but I'm pretty discouraged.

If anyone can tell me the right board, software and board source to get reliable and autonomous, I've got another $150 to invest. Point me there and I'll give it another shot!

Seriously, I'm not agitating.... I need guidance.

Sent from my iPhone

On Apr 24, 2017, at 1:18 AM, Konstantin Sharlaimov notifications@github.com wrote:

Regarding some setups "working" in INAV-1.5.x: the fact that sensor is detected doesn't necessary mean that it functions properly. Compass is most frequent source of fly-aways in pos-hold, failed RTH etc, that's why in INAV 1.6 we introduced hardware failure detection.

I can't say for everybody, but I would prefer sensor malfunction being detected and accounted for rather than go unnoticed and cause issues when failing sensor is needed.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[digitalentity]

Yes, I myself ran into quality issues with most boards out there lately. The only boards of reasonable quality I have received lately originate either from DIY-style makers who don't have websites to advertize or sell hardware or companies that sponsor INAV development - CarbonBird and Airbot.

Boards that come from Banggood or Aliexpress are of random quality - I have several from same seller purchased at different times - some fly perfectly fine, some were DoA, some glitch randomly.

In general I recommend boards that have gyro/accel (and if possible, baro) on SPI bus. If you can't manage to get I2C compass up and running - you can use DJI NAZA GPS - it only needs one UART and transfers all data via serial link.

[DzikuVx]

Sine no new facts appeared in last 2 months and clearly this is a poor hardware quality issue, I'm closing this one. If any new data appears, feel free to reopen