Inav: Massive error in i2c

[gendebeat]

I flash the latest 1.3 RC2 , because the earlier have a problem to detect the magnetometer (BMP280) on my naze. i think this issue may be corrected. but now
after 1 minute (aprox) the i2c error increase from 4 to a masive number (aprox +200 error per second) and Cycletime goes from 2000 to 11000. An of couse the FC freeze. thanks to all people who work to make inav/cleanfligth better

[digitalentity]

Sounds like a hardware error on the bus.

Please share details of your setup. What board, what sensors are connected? Do you have external compass connected to the board?

[digitalentity]

Looks like I2C timeout (#713, #720) it's not the only problem. I believe I2C driver requires a serious rewrite to properly handle all bus conditions. Or at least be simplified to the level of one used in F3. I'll look into it once I get INAV-1.3 released.

[gendebeat]

ok thanks, i had not seen the other entries. i believed that the problem with the magnetometer was already solved. im not a programer, sorry.
My board is a NAZE32 rev6a 10DOF: MPU6500 BMP280 and external HMC5883 (on board disable by cut)
Of course i try cleanfligth and fly good, and all sensor have very few i2c error.

[gendebeat]

Hello, im try the last release 1.3 and i have exactly the same problem. i2c error increase after 1 minute (or less). and the boad freeze because cycle time increase too. I think is not a hardware problem because with INAV 1.2.1 i have not this problem. I try CLEANFLIGTH and with the last release 1.14 i have this problem too. (earlier cleanfligth releases no problem),. i need to wait more time to try inav on my FC.. :(

[digitalentity]

@gendebeat this looks like hardware issue which current implementation is unable to cope with - looks like you're the only one having this problem.

I'm looking into making I2C driver more robust but that will take time.

[brumbad]

I confirm this with dof6/rev6a naze32 INAV-1.3, 1.2 and 1.2.1. Baro connected - gy-68 (BMP180). MC time to time startup correct, and in most case after short time become very slow with many i2c errors. This can lead to cpu consumption (600-700%) with cycle time about 16000-17000.

Baro connected to MC pin's with short (2-3cm) wire on board.

[digitalentity]

@gendebeat, @brumbad
Can you please test this hex https://www.dropbox.com/s/tc48euihxlugib0/inav_1.5.0_NAZE_a0207d0.hex?dl=0 ?

It has massive changes to i2c bus driver, maybe it will solve the issue for you.

[gendebeat]

@digitalentity
hello, this hex work correct!! i not flying, i wil try this weekend.
But now i can say that there some i2c error, but dont freeze. CPU load is allways at 2-3%. cycle time 2000
thanks!

[digitalentity]

@gendebeat if i2c error count increases over time it's an indication of unstable hardware. I wouldn't trust that setup. But still, good to know that a single bus glitch won't cause a crash with 100% probability.

[digitalentity]

I'm closing this issue now

[AvengerIl]

Can confirm the latest 1.6-rc2, and 1.5.1 still have this problem on spracing f3 acro (clone) with external hmc5883 gyro. (so does betaflight 3.1.5). i2c errors go through the roof, cpu usage to 900%.

[digitalentity]

@AvengerIl It's very likely faulty hardware. I2C code in 1.6 is reasonably robust - if it doesn't work - 99% possibility that there is something wrong with the hardware.

[AvengerIl]

@digitalentity FC or the ublox n7 gps with compass module more likely to be at fault? any external mags that are known to be good?

[Redshifft]

@AvengerIl you could go for a Naza gps then you won't require the I2C (mag and gps are encoded in one serial stream) and they work well in iNAV

[AvengerIl]

@Redshifft thanks... do have one of those lying around... I tried a F1 NAZE32 rev6b with the same i2c mag and it worked fine, does not lock up... must be the spracing f3 clone w/ osd causing the problem.

too many options, too many decisions... i really want 8khz and dshot running.. AND GPS..

[Redshifft]

I hear an F4 calling you ;)

[Waltec]

Using Omnibus F3 AIO and Neo 6m after a minute or two I get I2C errors and mag unhealthy warning. All works okay at reboot.

I'm troubled by the statement that it must be a hardware (mag) issue as I've tried two different GPS' with the same result, eventual failure (as indicated by Inaz or EZGUI) of mag on GPS module. These modules are known workers on APM 2.5 and 2.6 boards.

I saw this failure once in flight as I was setting up my copter. It just turned and augered in from low altitude.

Any chance for a rethink on the cause? Why would I2C be error free for more than a minute or and then start getting errors?

Hardware problems seems a bit too convenient but i'll admit, I'm far from an expert at these things.

Thoughts or further insight?

[mgaller]

@Waltec
I have the exact same problem with the same board and neo-m8n.
Did you found a solution?

[Waltec]

Not yet. I've been pointed in a couple of directions and I have my own theory. The one thing I tried was eliminating the overclocking of the I2C that someone suggested. That had no effect that I could tell.

Its been suggested that the mag should have 3.3v vs the 5v that my gps/mag module specifies but I've not explored that yet...I don't have a 3.3v source on the copter at present. Tough to wrap my head around that one as my module(s) call for 5v, and, they've worked fine on other FCs various APMs that is). I'll explore that at some point but I've not had any real time to get back to my bench.

My theory though is that (as I read somewhere) since the I2C bus shares resources with the UART3 (I think it's #3 is what I've read) there is some sort of data collision happening. I'm working from memory here so bear with me...

I think it was dronetrest.com that spells out this sharing issue specific to using ppm receivers (I'm using a knockoff Spektrum satellite receiver which connects via different pins than a standard ppm receiver but I'm guessing that qualifies). I'm guessing that the ppm data and the mag data "collide" on the shared resource and cause the I2C errors. Again on dronettest I think it is suggested to recompile the Inav firmware but doing so while uncommenting the "avoid_using _uart3" or somesuch statement. I'm a bit over my head on all this to begin with but recompiling is something I've not done before,so, I haven't tested this fix yet. Not sure if I will because recompiling is a whole new set of learning and as best I can tell requires a Linux setup which I don't have right now. Add to that that I'm wondering what problems you might be inviting by changing the firmware... why isn't Uart3 being "avoided" in the first place?

In looking at the Inav wiki I see that the Omnibus F3 AIO isn't in the fully supported category so I'm wondering if that's not a contributing factor on this issue.

I'll post back if I did pursue any of these fixes but for now I've opted to swap in an SP F3 board thinking it might be the quicker path to getting my copter back in the air again.

Not sure I've furthered the cause any but thanks for the question/response. Hopefully I've suggested something to go after if you are so inclined. If you do chose to tinker further, and something works or shows promise, I'd enjoy hearing about it!

Regards and Good Luck, Waltec

Sent from my iPhone

On Apr 20, 2017, at 2:53 AM, Michael Galler [e-mail] wrote:

@Waltec
I have the exact same problem with the same board and neo-m8n.
Did you found a solution?

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

[Waltec]

I forgot to mention that along with the 3.3v question on the mag that there is also a question regarding having too many pull up resistors...one on the FC and one on the gps/mag module. I'm not entirely clear but to my understanding the FC having a resistor built in is what's causing the voltage problem since the module has one too.

Sent from my iPhone

On Apr 20, 2017, at 2:53 AM, Michael Galler [e-mail] wrote:

@Waltec
I have the exact same problem with the same board and neo-m8n.
Did you found a solution?

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

[stronnag]

Strange, I have external mag on I2C (Beitian BN880 GPS) working OK on Omnibus F3 AIO. Using UART3 for serial RX, thusly:
serial 0 17 9600 38400 9600 38400 serial 1 2 19200 38400 0 115200 serial 2 64 115200 38400 0 115200
Tested on 1.6.1 / 1.6.3 (development) and 1.7.0-RC1).

I2C connected to the J3 (SCL / SDA),[not J22 (PWM7/8)]

[mgaller]

@Waltec Thanks to you i found the problem. The problem is the shared UART3, i dont use ppm but i use motor 5 and 6 and they are using the shared pins from UART3. If i switch from hexacopter to quadcopter the problem does not happen anymore. If i renable hexacopter problem occurs after 1 minute.

But i did not found any solution yet.

[mgaller]

@stronnag Big thanks for your hint with I2C connected to J3 instead of J22. No more I2C errors.
But really weird that the relocated pins are "broken" and the original still working.
@Waltec i had to swap SCL and SDA wires before soldering to J3.

[Waltec]

Great insight. Honestly, I tried those connections at one point and couldn't get it to work. User error I'm sure.

Sent from my iPhone

On Apr 20, 2017, at 2:27 PM, Michael Galler [e-mail] wrote:

@stronnag Big thanks for your hint with I2C connected to J3 instead of J22. I dont get any I2C errors anymore.
@Waltec i had to swap SCL and SDA bevor soldering to J3.

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

[Waltec]

Thanks for the feedback.

Tried last night with two different gps modules. M6n ublox. Gps would show up blue in status bar but magnetometer remained red. Swapped wires in case pins were wrong but no joy.

I didn't have much time so couldn't research myself but...

1. Is there a way, cli statement maybe, to determine if mag is on the bus and communicating?

2. I'm recalling that when mag shows red I can't do a calibration (board was actually showing calibration complete which seemed strange) but I didn't check to see if the option was available. Perhaps I need to view the sensors tab and then go back to the calibration tab to see if the calibration process "resets".?

I'm expecting that when the mag is working (communicating at least) it at least goes blue in the status bar similar to what the gps does...could be wrong on that.

One thing that has me thinking I'm confused there is that I can never get a solo mag module to register on the status bar either. I have a couple of those lying around and whenever I connect them I don't see evidence that the board sees them. Complicating this is the fact that the mag module doesn't have a status light that I can see.

If anyone has any thoughts on this just let me know.

Regards

Sent from my iPhone

On Apr 20, 2017, at 2:27 PM, Michael Galler [e-mail] wrote:

@stronnag Big thanks for your hint with I2C connected to J3 instead of J22. I dont get any I2C errors anymore.
@Waltec i had to swap SCL and SDA bevor soldering to J3.

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

[peakhunt]

I am having the same issue with 1.6.1 on my chinese clone SPRacing F3. With cleanflight, although there are some i2c erros but not this much. So I downgraded iNav to 1.4 and the count stops increasing. Let me take a look at the source code on the coming weekend although I am new to this source code.

[Waltec]

That would be great. You mention the SP F3 where I'm having the problem too but I also have it on a F3 Omnibus AIO. Both boards get runaway I2c errors on 1.6.1. On the Omnibus others are able to use the dedicated sda scl pins for the mag but I can't get those to work.

Between the two board I probably have 6 controllers from various sources that I can't use. That I can have some success by downgrading makes me wonder about the latest code but again, I'm out of my depth there.

Sent from my iPhone

On Apr 28, 2017, at 2:53 AM, Hawk Kim [e-mail] wrote:

I am having the same issue with 1.6.1 on my chinese clone SPRacing F3. With cleanflight, although there are some i2c erros but not this much. So I downgraded iNav to 1.4 and the count stops increasing. Let me take a look at the source code on the coming weekend although I am new to this source code.

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

[peakhunt]

just replaced bus_i2c_stm32f30x.c in 1.6.1 tag with the same file in 1.4 tag, built a new image and flashed it. It looks like it's just working fine at least in iNav Configurator. I am not seeing any i2c error or unusable iNav Configurator due to excessive i2c error. I'm suspecting there is definitely something wrong with bus_i2c_stm32f30x.c since 1.5 release since this excessive i2c error occurs from 1.5 release in my experience.

[Waltec]

Pretty interesting. Given the breadth of boards that I'm having problems with it implies a firmware problem but this is unfamiliar territory for me.

Sent from my iPhone

On Apr 28, 2017, at 8:00 AM, Hawk Kim [e-mail] wrote:

just replaced bus_i2c_stm32f30x.c in 1.6.1 tag with the same file in 1.4 tag, built a new image and flashed it. It looks like it's just working fine at least in iNav Configurator. I am not seeing any i2c error or unusable iNav Configurator due to excessive i2c error. I'm suspecting there is definitely something wrong with bus_i2c_stm32f30x.c since 1.5 release since this excessive i2c error occurs from 1.5 release in my experience.

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

[digitalentity]

SPRacingF3 from China running 1.7.0 for 5 hours straight. No issues.

[digitalentity]

For troubleshooting this I need either a failing board or a recording of SCL and SDA done with a logic probe at the moment of failure.

[peakhunt]

just a quick update.
cut down the I2C clock from 400 KHz to 200 KHz and it looks like it's working. CPU load is around 4%. No errors so far.
At 300 KHz, it doesn't work.
At 100 Khz, it works but CPU load goes wayward like 70%.
Now I am pretty sure this is a PCB issue. you know, impedance differs from one pcb to another.
And No idea why i2c driver in 1.4 tag works. Maybe later.

This is the I2C_STANDARD_TIMING in bus_i2c_stm32f30x.c I am using.

define I2C_STANDARD_TIMING 0xA010031A

Just happy I don't have to throw away my precious chinese clone lol. Is it gonna fly?

[peakhunt]

did a short test flight in the morning with 200 KHz I2C clock.
altitude hold worked near perfect.
in gps hold, my quad kept circling although my magnetometer looks quite okay. maybe there are some configurations I missed.
Anyway for those who are suffering from the same issue, here is a 1.6.1 with 200KHz I2C clock. Use it at your own risk!!!

[Waltec]

Konstantin,

Did anyone reply to you on this?

Once finished you'd return the board(s)? Are you looking for sp f3 and omnibus f3 aio? I've not looked...what country are you in?

Thanks,

Eric

Sent from my iPhone

On Apr 29, 2017, at 12:25 AM, Konstantin Sharlaimov [e-mail] wrote:

For troubleshooting this I need either a failing board or a recording of SCL and SDA done with a logic probe at the moment of failure.

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

[digitalentity]

@Waltec I'm in Russia. One russian guy is willing to send me his SPRacingF3 for investigation. I will gladly return the boards, but I have to warn you - the boards might not survive (I'll also be looking at hardware quality issues). What country are you in? I want to make sure that shipping the board back and forth won't cost more than a new board :smile:

[Waltec]

I'm in the US.  If I got a logic probe, could a novice give you useful information?

  From: Konstantin Sharlaimov <[email protected]>

To: iNavFlight/inav [e-mail]
Cc: Waltec [e-mail]; Mention [e-mail]
Sent: Sunday, April 30, 2017 7:43 AM
Subject: Re: [iNavFlight/inav] Massive error in i2c (#724)

@Waltec I'm in Russia. One russian guy is willing to send me his SPRacingF3 for investigation. I will gladly return the boards, but I have to warn you - the boards might not survive (I'll also be looking at hardware quality issues). What country are you in? I want to make sure that shipping the board back and forth won't cost more than a new board 😄 —
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[Waltec]

I loaded this 200 khz i2c fix on my sp f3 board that wasn't showing either the mag or the barometer.  At boot up it immediately showed both.  Should be able to test fly later today.

  From: Hawk Kim <[email protected]>

To: iNavFlight/inav [e-mail]
Cc: Waltec [e-mail]; Mention [e-mail]
Sent: Saturday, April 29, 2017 9:57 PM
Subject: Re: [iNavFlight/inav] Massive error in i2c (#724)

did a short test flight in the morning with 200 KHz I2C clock.
altitude hold worked near perfect.
in gps hold, my quad kept circling although my magnetometer looks quite okay. maybe there are some configurations I missed.
Anyway for those who are suffering from the same issue, here is a 1.6.1 with 200KHz I2C clock. Use it at your own risk!!!—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[brat002]

One more set of props were breaked after new try to fly in air my
QR400+SPRacing F3 1.6.1. Controller is just stuck. This never was happened
before with 1.3 firmware.
Something really is wrong with new firmwares.

2017-04-30 18:07 GMT+03:00 Waltec [e-mail]:

I loaded this 200 khz i2c fix on my sp f3 board that wasn't showing either
the mag or the barometer. At boot up it immediately showed both. Should
be able to test fly later today.

From: Hawk Kim [e-mail]
To: iNavFlight/inav [e-mail]
Cc: Waltec [e-mail]; Mention [e-mail]
Sent: Saturday, April 29, 2017 9:57 PM
Subject: Re: [iNavFlight/inav] Massive error in i2c (#724)

did a short test flight in the morning with 200 KHz I2C clock.
altitude hold worked near perfect.
in gps hold, my quad kept circling although my magnetometer looks quite
okay. maybe there are some configurations I missed.
Anyway for those who are suffering from the same issue, here is a 1.6.1
with 200KHz I2C clock. Use it at your own risk!!!—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

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

[digitalentity]

@brat002 please consider sending your faulty FC to me for debugging. Once again - there is absolutely NO issues with genuine SPRacingF3 boards and with many Chinese clones as well. If I can't reproduce the issue I obviously can't troubleshoot it, can I?

[brooksymike]

I've just upgraded my SP Racing F3 EVO to a better GPS with external mag (HMC5883) and thought I'd add my experiences. Been having the same problem with the I2C errors which start to happen after about 1 minute and the mag then shows as unavailable.
I tried to upgrade the firmware as detailed above but it says the firmware is corrupt. Maybe this is because my board is an EVO rather than a normal SP Racing F3?
I'm not experienced in messing about with FC firmware so not sure how to go in and change the I2C clock manually. Maybe this fix wouldn't even apply to me as I've got a different board?
Any thoughts appreciated?

[peakhunt]

yes it is only for SPRACINGF3 not for EVO. If you really wanna take the risk, I just uploaded 1.7.0 RC version with 200 KHz I2C clock speed for EVO here.

By the way I just switched to 1.7.0 RC version to sort out my position hold problem. Please share your experience so I can sort out my position hold problem.

[brooksymike]

I've just tried to install that firmware but I'm getting the same "firmware appears to be corrupt" message as I did with the normal SP racing F3 firmware.
I did earlier successfully upload the standard version of 1.7.0 I found "inav_1.7.0_SPRACINGF3EVO.hex" (and I also tried version I found "inav_1.7.0_SPRACINGF3EVO_1SS.hex"). Don't know what the difference is but on both it still has the mag issue.
Since posting the above I have also found this thread which gives info about powering from 3.3V and using pull up resistors:
https://github.com/iNavFlight/inav/issues/1583
I have not tried this as I've only just found it so should probably go and give that a go.

[peakhunt]

hmmm honestly I have no idea what's going on.
can you post a first hundreds bytes of the firmware file? You can just open it with notepad.

[brat002]

@digitalentity it is possible. Write me your address: [email protected]

[brooksymike]

I think I've done something stupid whilst trying to download. The Notepad file is full of rubbish compared to the other .hex files I downloaded. See at the bottom.
I left clicked to download in Chrome like I normally would for any file but it just took me to the raw data, so I right slicked "Save target as:"
Take it I need to left click and copy and paste into a notepad file. I've not downloaded anything from Github directly before (as I've just joined). Maybe I'm missing something.

"LC317" class="blob-code blob-code-inner js-file-line">:1013A80000F10E06AB88B38007464FF00109002014




:1013B800DFF8248198F81A30012B44460DD002D367




:1013C800022B1ED024E0424B1B7823B93846022159




:1013D80001221CF047FB012328E0FFF7A7FF40BBD1




:1013E80038466946FFF7B2FF9DF8003008B19B0701




:1013F80013D1002388F81A30B9F1000F0BD09946A1

[brooksymike]

Ok just got the modified EVO firmware installed. Problem with mag is still there but it is not consistently failing in the same length of time. At first power on it failed very quickly. Maybe 10 seconds. Rebooted it and this time it stayed good for at least a few minutes before I rebooted again. A few more times has revealed that it takes varying amounts of time to fail.
Next I think I'll try powering the GPS / Mag with 3.3V and see if I can find any 1k resistors.

[brooksymike]

Just noticed that shortly after the compass fails and the I2C errors start counting up, the barometer starts jumping around all over the place. Don't particularly know what this means...............

[peakhunt]

how long is the cable for the external compass?

[brooksymike]

It's about 30cm. I've got the compass up on a vertical mount to keep it away from the other components.

[brooksymike]

Ok I managed to find some resistors of around 1K and I connected them between SCL and SDA and 3.3V as detailed in https://github.com/iNavFlight/inav/issues/1583.
I also supplied the GPS with 3.3V. This looks like it's worked for me. I then tried connecting the GPS power to +5v instead of 3.3V and it also works.
I haven't changed back to the normal firmware so I don't know if that's doing something as well but I don't have time to do that now. I also haven't tested it properly as all the connections were temporary so I can't fly it yet, but I will do.
So for me at least it (appears so far) as though the pull up resistors are my problem rather that firmware issues. More testing required though.

[digitalentity]

@brooksymike I've took my (working) Chinese cloned SPRacingF3 and measured pull-up resistors found on board - they are 1K. So it's possible that some cloned boards have actually random resistors which is causing issues.

[Waltec]

Konstantin,

Can you post a picture or description of where/how you did this? I'm not getting a clear picture of whether I should be adding resistors or removing them but I would like to be able to identify them.

Sent from my iPhone

On May 2, 2017, at 7:56 AM, Konstantin Sharlaimov [e-mail] wrote:

@brooksymike I've took my (working) Chinese cloned SPRacingF3 and measured pull-up resistors found on board - they are 1K. So it's possible that some cloned boards have actually random resistors which is causing issues.

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

[peakhunt]

I measured mine too and 1K pull-up was there.

[brat002]

But why 1.3 version has worked fine?

[brooksymike]

Ok my issue has not gone. It appeared to be ok when connected to my Android phone (EZ-GUI) but now I'm connected to iNav the problems are still there, but different. I'm getting different things depending on which firmware I use. Some firmware greys out the "Calibrate Magnetometer". On others it will calibrate but the heading is wrong. On another the heading continually drifted.
Today I took the top off the quad and laid the mag down. It was only then that I noticed that the board appears to be still using the internal compass rather than the external (even though the FC is set to HMC5883). The internal compass is reported as the AK8963 so I thought that I wouldn't need to cut traces to get the external one to work.
I really have no clue what to do next.
Any thoughts?

[Waltec]

How about disconnecting the external mag and testing with only internal. At least that way you've taken one potential conflict source out of if the equation.

Also, are you positive the internal compass is "active". You've probably seen this but to be sure, I've been tripped up in the past when I've mistaken gyro swings for compass indications.

Sent from my iPhone

On May 2, 2017, at 5:27 PM, brooksymike [e-mail] wrote:

Ok my issue has not gone. It appeared to be ok when connected to my Android phone (EZ-GUI) but now I'm connected to iNav the problems are still there, but different. I'm getting different things depending on which firmware I use. Some firmware greys out the "Calibrate Magnetometer". On others it will calibrate but the heading is wrong. On another the heading continually drifted.
Today I took the top off the quad and laid the mag down. It was only then that I noticed that the board appears to be still using the internal compass rather than the external (even though the FC is set to HMC5883). The internal compass is reported as the AK8963 so I thought that I wouldn't need to cut traces to get the external one to work.
I really have no clue what to do next.
Any thoughts?

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

[peakhunt]

@brat002,
not sure this is relevant for you but to sum it up,

as far as I2C error is concerned, in my experience so far,
my presumed ( oh yeah I got hell lot of stuffs to talk about this from my pcb manufacturing experience but next time) faulty chinse SP Racing F3 clone works just fine up to 1.4.
And there was a major rewrite on I2C bus driver since 1.5 and my clone stops working with default 400 Khz I2C clock speed.

So far, after I reduced the clock speed to 200 Khz, everything has been working fine although I am trying to sort out my toilet bowling issue ( I am narrowing it down to gps auto config issue but darn.... I broke one of my esc trying to wrap it with aluminum foil... so gotta wait a month for a new chinese one). I have never seen any I2C error for a week and all the blackbox log data looks just okay.

[Waltec]

peakhunt.

I used your firmware with the i2c clock change and while my mag, gps and baro all seemed to work I also got erratic gps hold performance and seemingly limited to non existent altitude hold performance.

Basically my quad would vaguely hover while drifting off ten or fifteen feet and then snapping back in the opposite direction as if the gps just noticed it had let the copter drift way out of position.

At that point I had pretty much run out of weekend and patience so choose to put the quad away.

I'm sure I'll get reinvigorated at some point but right now I'm considering admitting defeat and putting my apm 2.5 back in to do some mission flying.

I'm thinking that your modified firmware is the right path but that I've not got my copter set up properly. That being said, my F3 boards have never flown out of the box on inav like others say theirs have. The latter makes me wonder if these boards just have a ton of variability in their quality and we're all chasing similar issues that have different causes.

[peakhunt]

@Waltec,
agree with you to some level.
In my case altitude hold works pretty well after I put a small foam on top of barometer.
When it comes to magnetometer, I am seeing about 30 degree deviation when I run the motors so I tried to shield the magnetometer and other components with some aluminum foil as suggested in the internet to no avail, which led me to one broken esc. I even changed location of my fc for minumum magnetic interference. Nothing worked so far.

From my pcb experience, I can say that chinese clones are cheap for a reason. Many times if you don't pay particular attention to some pcb traces during pcb manufacturing, you cannot achieve the full speed. Once this occurs in a massive manufacturing, we usually end up reducing clock speed since we can't just throw away tens of thousands of pcbs manufactured. Often times what worked perfectly on my dev platform suddenly stops working in manufacturing environment. As an engineer I've seen this so many times.

[brooksymike]

Regarding whether the FC is using the internal compass or not, I removed the external Gps/mag from the quad and rotated it whilst leaving the quad still. The heading did not change. Then I moved the quad and it does change. I believe the qyro measures rorational force but doesn't know which direction it's pointing so presumed that what I was seeing was the internal compass still being active?
I'm thinking I will try and revert to the internal compass to check that works ok.

[Waltec]

I've not tried this but I expect it would work...grab a magnet that has reasonable strength (I suppose you could use a spare motor) and move it around the flight controller while you again have the gps module of to the side. I'm expecting you'll see compass movements that will verify the internal composed is active. Also do this to the gps module/puck to verify that mag is active ad well.

If you get swings on both when they're connected to the FC then of course there's your answer... Each mag is feeding the flight controller.

One other thing I'd try to verify is the orientation of the mag on the gps puck...you probably know this but they're not all the same. Often my mag chips are inverted and rotated 180 degrees which can be VERY confusing to sort out.

[brooksymike]

Ok I'll try this. Thanks for the suggestions.
One question though - is it possible to have both the internal and external mags active (and working) at the same time?

[Waltec]

Do you mean working well together and giving a better or more reliable mag reading or do you mean both operating at the same time sending data to the flight controller?

I'm not qualified to answer the first option but my guess would be that the the software doesn't know how to handle two inputs at the same time. If youre asking the latter t think doing the magnet experiment will tell you if both mag chips are sending signals when you have the god puck connected. Hope that helps.

[brooksymike]

I meant whether the flight controller would be able to cope with two inputs at the same time, which I think it would not. When you select which compass you are using, I have read that you can connect the external and that somehow the FC can ignore the internal one even though it is still connected (only if the ext and internal compasses are different).
This doesn't seem to be what's happening to me but I'll do further testing with a magnet.
One thing I noticed tonight (after I disconnected external compass and selected correct internal compass), was that the compass was greyed out and wouldn't allow me to calibrate. Tried some different versions of firmware but it still failed but in different ways.
More testing required! Might give up and try a different FC soon!
Thanks for the suggestions.

[Tops76]

I had the exact same probleme on my BG Omnibus F3 AIO clone.
To resolve this issu I just added 1k pull up resistor on the SDA and SCL line (on the ublox 8 GPS).

[Waltec]

Is a pull up resistor a special type of resistor or is it a standard resistor put in place in a certain way to deliver the "pull up" function?

If you can take a photo of the installation and maybe provide a link to a resistor I can order in the U.S. I can probably sort the rest out myself.

All I know of resistors is to follow directions such as, "solder an x ohm resistor in line with x led to ensure the correct voltage."

So...any newbie direction you can provide would be much appreciated.

Sent from my iPhone

On May 25, 2017, at 12:56 PM, Tops76 [e-mail] wrote:

I had the exact same probleme on my BG Omnibus F3 AIO clone.
To resolve this issu I just added 1k pull up resistor on the SDA and SCL line (on the ublox 8 GPS).

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

[DzikuVx]

It;s a normal resistor. But I would not use 1kOhm. That is pretty low value. I'd begin with 4.7kOhm pullups

[Waltec]

Thx.

Sent from my iPhone

On May 25, 2017, at 3:31 PM, Paweł Spychalski [e-mail] wrote:

It;s a normal resistor. But I would not use 1kOhm. That is pretty low value. I'd begin with 4.7kOhm pullups

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

[Tops76]

Yes just a normal resistor. To calculate the right pull up resistor for I2C fast mode on 3v3 you can check this documentation : I2C Bus Pullup Resistor Calculation

_For Fast-mode I2C communication with the following parameters, calculate the pullup resistor value.
Cb = 200 pF, VCC = 3.3 V..._
Check page 4
_Therefore, we can select any available resistor value between 966.667 Ω and 1.77 kΩ. The value of the
pullup resistor can be selected based on the trade-off for the power consumption and speed._

[DzikuVx]

@Tops76 this is lowest possible pullup resistance that is still inside toleration of devices.

[Tops76]

@DzikuVx Yes. With this value I had 0 I2C error during a 4h test but I will try a bigger value like 1k5 just to be safe. But I think 4k7 is to high for fast-mode and 3v3.

[DzikuVx]

PLease remember, that there already are pullups on FC. To overall resistance will be lower than that

[Tops76]

You are right ! I will check thanks.

[brooksymike]

I'm sorry to say I've given up (with gps on this fc). I'll still use the quad but not as a gps build. I bought an APM 2.8 and a whole new frame (F450) and I'm in the middle of building this now.
When I tested with the sp racing with pull up resistors it appeared to work but then started doing random things again.
I've since confirmed the gps is definitely working as it works on the apm.

[Waltec]

Can't say I blame you. Was debating whether to bother with the pull up bit. I've a Pixhawk clone coming in the mail today. That is where I was landing. The whole debate about clone vs OEM boards was bugging me. In truth I think they all originate in China and even the "approved" vendors' boards got bad reviews.

If I try the pull up fix I'll post results here. Not a high priority though.

Sent from my iPhone

On May 26, 2017, at 12:11 PM, brooksymike [e-mail] wrote:

I'm sorry to say I've given up (with gps on this fc). I'll still use the quad but not as a gps build. I bought an APM 2.8 and a whole new frame (F450) and I'm in the middle of building this now.
When I tested with the sp racing with pull up resistors it appeared to work but then started doing random things again.
I've since confirmed the gps is definitely working as it works on the apm.

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

[digitalentity]

@brooksymike "working" doesn't necessarily mean "working reliably". APM has no hardware failure detection whatsoever, so you may find yourself in a very unplesant situation one day with that GPS module regardless of flight controller and firmware. I'd start RMA on that GPS module of yours.

I've found HMC5883 to be the most problematic compass sensor. MAG3110 is my current design choice - unfortunately they are not widely used...

[GTorreil]

I'm using MAG3110 as well, as an external compass on SP3 clone. Surprisingly, it works flawlessly , unlike the original on-board magnetometer (I completely removed it). 400KHz i2c is ok with this sensor.

[peakhunt]

okies. it's been so long. got a new ESC from china and had a chance to test. Moved my faulty flight controller away from PDB. I2C is still running at 200 KHz. Worked almost perfectly. Sometimes due to EMI on compass my quad was kinda circling in roughly 1 meter radius but mostly almost stayed still. Pretty much happy with it now.

Also I got another chinese SP Racing F3. This time I paid 6 dollars more for the embedded OSD. Just flashed iNav 1.7 and I2C is running at full speed with no error. Guess paying 5 bucks more pays off.

Cheers!

[almln]

Hi all. Like @Tops76 got the same problem with aliexpress Ublox NEO-M8N gps with integrated compass. There were a lot of i2c errors on my FC (F4 omnibus V3 pro clone). After i soldered pull-up 1K resistors to SCL-SDA wires all things go right. Cheers!

[VictorBucha]

After removing internal mag from my spracing f3 deluxe I have also been flooded by I2c errors with Ublox 8. I nothiced that in quadro mode there were no errors but when I changed to hexa - board got stuck with 600% CPU load. resistors did not help
On inav 1.4 no errors but this version seem to neglect errors

[VictorBucha]

So I spent a hell of nights testing my Ublox8. I checked whether our Chinese geniuses missed SDA for SCL and I found out that on new Sp Racing F3 Acro it does not work unless downgrared to 1.4 as well. Without 1K pullup resistors it won't work even with Arduino. but with pullups everything goes fine with Arduino but not with Acro or Deluxe (you remember I desoldered compass out of it). So It is Not a hardware problem to some extent, I mean resistors, but Inav lacks some Mag drivers or whatever. Clean/Beta Flights recognise mag even without pullup. So I will go for APM or Naza.
Ublox 7m was perfect on Inav 1.7.0- 1.7.1 but my F450 lost one prop and fall from about 100m. thanks for staying by.

[digitalentity]

Those haunted by I2C errors - you may want to have a look at https://github.com/iNavFlight/inav/pull/1934.

There are great many cloned compass/baro sensors that don't work on 400kHz bus but work perfectly good on 200kHz.

[VictorBucha]

Thanks.Hardly useful for me. I have no idea how to do that to give it a try.

[digitalentity]

@VictorBucha I can build you a firmware to test if you want to give it a shot.

[VictorBucha]

Sure, thanks a lot. Will try and respond.On Jul 31, 2017 8:56 AM, Konstantin Sharlaimov [e-mail] wrote:@VictorBucha I can build you a firmware to test if you want to give it a shot.

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

[digitalentity]

inav_1.7.3_SPRACINGF3_14c76111a1fd251c46e00fb0ed2814fb168c1e0d.zip
@VictorBucha here's the hex. There's a new CLI parameter i2c_speed (defaults to 400KHZ). Try setting it to 200KHZ.

[VictorBucha]

AAAaaaaaaaaaaaand now it works@200KHZ!!!!. Acro with BMP085 and HMS5883+UBLOX NEO8m with pullup 1kOhm resistors - works.
Deluxe with desoldered HMS5883 fails to see the onboard baro but sees BMP085. Great job, @digitalentity !!!
I think this freq change option should be added into standard firmware and wiki.
Image of GPS module attached for convenience

[digitalentity]

@VictorBucha thanks for testing! Code will be added to next release - this is indeed a very useful option.

[VictorBucha]

Gave further testing: no need to power the UBLOX neo8m from 3,3 V if I2C pulled up- it shows no errors if powered from 5V

[JonasCz]

@digitalentity Could you also make a build with the i2c speed CLI parameter for Omnibus F3 for me to test ?

I have a similar problem - external mag (HMC5883) works for a few minutes, then lots of i2c errors, and it goes red in the configurator. The magnetometer works fine on a different FC.

I'll try adding pullup resistors, but I'd also like to try changing the i2c speed if that doesn't work.

[JonasCz]

Adding 3.3k pullup resistors seems to have worked - so I'll probably stick with that, and won't need to try reducing the i2c speed.

Now just need to figure out why it toiletbowls, even though the only change is new FC...

Thanks all for making inav awesome !

[whakru]

у меня была подобная проблема, изменил i2c_speed на 200
и подпаял резисторы 1к на шину i2c
Контроллер F722
Теперь все работает =)
Спасибо вам)