home Home library_books Notes style Projects photos Photos Table Of Contents Why choose an F7 flight controller? OmnibusF7 Build Pinouts RX OSD Configuration AnyFC F7 Related Articles Asguard AIO NOX Flight Controller 180mm Build HobbyKing Quanum V2 Pro Goggles FPV Camera Comparison Go FPV Latency Testing Configuring the HK-T6A for a Flight Simulator Betaflight 3.2 and F7 Flight Controllers Nt 48

As of Jul 31, 2017, 2:26 PM PDT, Betaflight 3.2 is in the Release Candidate stage and with this release, F7 flight controllers have arrived. While an F7 MCU is not entirely necessary, not yet anyway, having a very fast and very capable MCU is future proof. I expect some of the most exciting new performance features in Betaflight will target the F7 MCU. This article is an overview of the current F7 landscape.

That is a photo of an early OmnibusF7 prototype with 2, user selectable, gyros: MPU6000 and ICM-20608-G

As of this writing, there are 8 F7 targets in the Betaflight source code:

ALIENFLIGHTNGF7
ANYFCF7
CLRACINGF7
FURYF7
MATEKF722
NUCLEOF7
NUCLEOF722
OMNIBUSF7

The only 2 that I've got my hands on so far are the OmnibusF7 and AnyFCF7. I hope to add more to this article over time.

Why choose an F7 flight controller?

Compared to the F4 flight controllers, which run at 180 MHz, the F7 runs at 216MHz.

More important than clock speed, the F7's "superscalar pipeline and DSP capabilities" put it ahead of the F4. Ok, sounds cool, but what are "superscalar pipeline" and "DSP capabilities."

DSP stands for digital signal processing, which includes special commands for Multiple ACcumulate (MAC) and Single Instruction Multiple Data (SIMD) instructions. These special instructions let the Betaflight devs write algorithms like Finite Impulse Response (FIR) and Infinite Impulse Response (IIR) more efficiently, making overall execution speed faster, even with the same 216MHz clock.

As for the "superscalar pipeline", the STM documentation describes it well:

The Cortex®-M7 features a 6/7-stage superscalar pipeline with a branch prediction and dual
issue instructions. The branch prediction feature allows the resolution of branches to
anticipate the next branch and therefore decrease the cycle number consumed by loops
from 4 and 3 cycles down to 1 cycle per loop. The dual instruction feature allows the core to
execute two instructions simultaneously and usually no matter of their order, to increase
instruction throughput.

Branch prediction attempts to improve the processor's instruction pipeline, e.g. what it's going to do next, and the dual issue instruction feature allows some instructions to be run in parallel.

These are all really great new processor features, but without developers to use them, they're pointless. Luckily, we have awesome Betaflight developers using them! One example of a new feature implemented in Betaflight for the F7 processor is Blckmn's code to enable the F7 flash cache features.

You'll also see some F7 flight controllers with the F745 and others with the F722. Both of these F7 processors share the same features listed above. The F745 has the option for a bit more flash memory and a little more RAM. This translates to a little more storage space on the processor for features (flash) and a little more room for memory as code executes (RAM).

In practical terms, either the F745 or the F722 is a good choice.

OmnibusF7

If you don't know the history of the Omnibus, the OmnibusF7 is the latest iteration in a series of flight controllers with an integrated OSD based on the MAX7456 (AB7456 actually, but I digress). The original Omnibus (F3) was the first widely available flight controller with an integrated OSD. Airbot designed the Omnibus hardware and Evgeny of SirinFPV and I did the first version of the OSD code in Betaflight and the Betaflight configurator.

As for the initial F7 code, thanks to Sambas for all his hard work. It's so awesome that he even open sources all his hardware work. Check out the original post or send a donation here.

Since this is all bleeding edge, there are still a few bugs to get ironed out, but I've been flying my OmnibusF7 prototype rig fine on the latest code from Github for a few months now.

I've been running the MPU6000 on this giant 280 quad. Tested out the ICM-20608-G gyro and it runs fine as well

Build

F7 MCUs run a little hot sometimes. It's not a bad idea to put a heatsink on it.

The 280mm quad build looks like this. I'm testing out the Runcam Owl Plus, a FrSky XM+ and tiny 5.8G transmitter

It uses Airbot BumpBee ESCs and motors. You might have noticed the single board computer underneath the OmnibusF7. This is not used at the moment, but will eventually provide onboard, multicore, application layer processing power :)

All the parts are 3d printed

Pinouts

Here are the pinouts:

It has 2 gyros, which are user selectable: an MPU-6000 and ICM-20608-G. The MPU-6000 is ultra reliable and low noise, but this is a last generation gyro and cannot be sampled at 32khz. The ICM-20608-G gyro can run at 32khz, but it is far less proven than the MPU-6000. It is also more susceptible to noise than the MPU-6000.

Using the Betaflight Configurator CLI, select the MPU-6000 gyro with the command:

set gyro_to_use = 0

Or for the ICM-20608-G

set gyro_to_use = 1

RX

Here's how an SBUS RX, I'm using the Frsky XM+ (and buzzer) should be wired:

OSD

As with all OmnibusF7 flight controllers, this one includes the Betaflight OSD.

Configuration

The VBAT ADC (battery detection) pin isn't activated by default, so you'll want to run set battery_meter = ADC to turn on the VBAT pin.

Here's my configuration, you can paste it into the CLI: https://gist.github.com/nathantsoi/12dc0a1dd4377775ace87a2b4f6680c5

AnyFC F7

I haven't built a quad with Sambas' original design, the AnyFC F7 yet, but I'm excited to build one.

Hope this was helpful. If so, feel free to checkout my YouTube channel, get updates when a new article is posted by following on Feedly and read the the other guides at nathan.vertile.com/blog