I ve got the same problem on three Omnibus F3:
I've try this three Fc with clean/betaflight and no one have this problem, only with iNavFlight...
Actually the setup are just the FCs connected to ESC + 2xServo + D4RII and configured as wing.
Same problem with the FC solo...
I've try with Ubuntu and windows, same problem on connecting...
Anyone has got this issue?
Do you flash with full erase? Which firmware version?
Firmware version: 1.7.2, Full chip erased was ticked, but when i start the flash it start directly with the flash and seems that does not perform the erase...
Maybe i can try to download the .HEX and flash it with Betaflight configurator...

Edit.
I've downloaded the .hex file and flashed from Betaflight configurator, but problem still the same...
Try doing this without "full chip erase". My Omnibus F3 is flashing without any problems so I kind of suspect hardware problems
Might be hardware problem. My OBF3 flashed fine.
Thanks for the support
I've also try without the "full chip erase" flag, and the strange is that if the button/flag is OFF, then before the flash the Configurator perform an erase...
by the way, i think that this is not an hardware problem because with Cleanflight or Betaflight the problem does not exist...
I can flash the FC, boot up, configure it and move servo and ESC...
get a new cable possibly its also your usb port is worn try a diffrent one..... also reload the drivers
Hi,
Have solved the problem yet ?
I got the same behavior.
Not solved yet...
I'm still having 3 Omnibus F3 AIO with the same problem...
I've switched to an old Flip32 for my plane...until i find a solution...
my suggestion toss the omnibus line.. infact toss everything that is a clone seems china cloned all these fc... the naza32 has a original made by one dude yes its old but it had standareds like dji etc.. china has no standards they ship out trash and hope it works and hope you dont return it...
trouble is everything now is made in china not one company you really need or use is american everything is assembled in mexico or italy or china etc... and the brands that are 100% in the usa read off the 100 companies there something like slippers or towels lol stuff you dont use much electronics and other things are always copied and oursourced i gave up on mine.. why not worth it anymore
to many driver issues with inav to much hardware porblems.. i use old tech naza m board... of course hacked lol but other than that 3dr roboitcs is the only one that has quality control so what 2 whole companies outta lots.. the rest are companies that dont care....like eachine they make horrible copters
I agree...
but with two of my Omnibus F3 where i've try to install iNav without success, has got more than 300 hour of flight in a 4copter with betaflight...
So my opinion is that in this case there is not a hardware failure on this FC...
its a software issue too and firmware.. see the firmware was copied from clean flight and reworked to add this stuff in.. the drivers were created for these boards.. by a unknown person...
with dji you know where its coming from with 3dr its open source but 1 guy takes suggestions and implements them then tests them... and the flight controllers are made in house.. with these omnibus things and everything after the naza boards its just gone down hill and when you mention the firmware is bad or something wrong you are meet with scorn i opened a ticket on the firmware with my issues no hlep what so ever an di got berated and talked down to like how dare i come here to ask for help .. yea very condescending tone from most of them... so im done with this board and the whole inav thing it just does not work. maybe if they had boards that were made by one source and accelerators and gyros officially made not just slapped and and reprogrammed to look like originals yes china takes chips and re flashes them somehow and uses lasers to mark products as genuine but there not... theres a issue with cell phone batteries simlar thing in the china district so yea no standards at all anymore.... thats why im going back to dji and 3drs flight controllers sure ill pay 200 plus dollars but its worth it i have a micro pixhawk now in my 150 size frame perfect flying off the bat.. with mission planner.. the inav software is a jumble fuck lol
@LucaBertuolo my Omnibus F3 board that came directly from Airbot works without any issue - flashing, configuring and using on a quad.
Chinese cloned boards are of random quality and ofter have random differenced from original ones at hardware level. Do you have anything connected to the board? If you have anything connected to UART1 (GPS, receiver etc) - they may confuse the STM32's built-in bootloader when trying to flash the board.
I might have found the solution, lots of people from from one FPV FB group had the same issue, they say the solution is to power LED's from PDB, not from the FC.
Will report tomorrow.
@locutus40 your comments are irrelevant to the topic. If you want to brag about DJI, INAV, 3DR, quality etc - please go to RCG. GitHub is for tracking and discussing issues, not musing about good old days where there was only NAZA.
@locutus40 I think that now this discussion is too "off-issue"...
If you are going back to dji/3dr, good for you...
I believe in a project that can born and grow with a community...and supported by donation and help from users...
I'm one of that people that not only buy a FC in an official store, but then also give a donation to that team that work on the software/firmware...
by the way...
@digitalentity No devices was connected to UART1 during the test...
@LucaBertuolo then it's really odd. So, to summarize - when you power the board from lipo battery - the board is cycling through reboots, right? Do the LEDs blink when it reboots? Can you record LEDs blinking?
It could easily that GYRO/ACC is not detected by iNAV. We should see it immediately from the blinking pattern.
It could easily that GYRO/ACC is not detected by iNAV. We should see it immediately from the blinking pattern.
That's my idea as well. On Omnibus F3 board OSD chip shares the same bus as gyro, might be initialization order issue. We've changed the OSD/Gyro init order in 1.7.3, @LucaBertuolo can you try flashing the 1.7.3 and see if the issue is still present.
@locutus40 I've deleted your comment to keep discussion clean and on topic. Please don't post irrelevant and offending comments, otherwise I'll be forced to ban you off this issue tracker.
love it how a moderator deletes free speech and clean speech learn what clean and dirty speech is.. cursing is dirty talking is not.... this is a nazi forum im done with it.. be glad i dont report you to github for all your condecending tones on both forums.... i came here with a issue and you guys treated me poorly... good day dont talk to me again..
@digitalentity I had 3 aliexpress OMNIBUS F3 clones. Not a single issue with 1.7.2 and I have one in my hands freshly flashed with 1.7.3 . All good.
SPI should be pretty robust compared to I2C
@locutus40 for the record: I consider comparing to nazi's and monkeys quite offending. Also, this is not a forum where you can brag, this is an issue tracker where particualr issues are discussed. Off-topic comments are tolerated here, but there is a limit to everything.
@giacomo892 it's about chip-select lines. Both MAX7456 and MPU6000 gyro share the same bus on Omnibus F3. If they both try to drive the bus - result is bad. If one of devices' chip-select line is floating they might both end up driving the bus at the same time.
@digitalentity @giacomo892
I've made a video for you...this time the FC will be visible from iNav configurator until i reboot it...
This FC come from a UK store, so it's different from the previous Omnibus that i've use when i've start this issue...but the problem still the same...
Edit:
I'm removing the MAX7456 from the board, then i will tell you the result
Edit2:
Without the MAX7456 the board boot up correctly and i can finally connect it with the Chrome configurator!
Unfortunately...i need the OSD in my setup...
I will investigate on the chip-select pin of the MAX7456, and also in the 3.3 voltage regulator...
in fact, without the MAX7456 the 3.3 voltage regulator heats up much less, i will check if it was going in thermal protection and the board reboot for this problem...
although with cleanflight it had no this problem...
@LucaBertuolo thanks. Looks like it's the MAX7456 messing up with gyro initialization. Fix pending.
@digitalentity
I've check and it's not a power issue, with an external power supply for 3.3 it do the same problem...
If you need some other info, i can send you a check of the two CS pin (MAX7456 and Gyro) captured wit the DSO...
I will do all you tell to me;)
@LucaBertuolo can you flash the attached firmware with full erase and see if it boots consistently for you.
Note, that you won't be able to configure it using current Configurator - we're making changes here and there.
@digitalentity
Flashed, seems it boot correctly :)
I've also try to connect/disconnect the usb power ten times, and always boot correctly...
Also in the Configurator it show the OSD enabled.
The Omnibus stop rebooting, and i'm able to connect it with the Configurator:

Cool! I'm closing the issue then. Fix will be included in next release - I'm planning to publish a RC1 of version 1.8 some time next week.
To keep track of the fix - https://github.com/iNavFlight/inav/pull/2275 has fixed the issue.