Although I do think the naming/marketing is a bit misleading, the Binary F10, nevertheless, is an interesting new flight controller. It is faster than any other existing FC on the market because it can run 32K PID loop at the lowest CPU utilization.
Want to know more about the basics of mini quad flight controller?
Where to Buy?
Discontinued.
What’s Special About the Strix Binary F10 FC?
First of all, I have to make it clear that there is no such thing as “F10 chip”. So you might be wondering, what are they talking about?
Well, the Strix Binary F10 flight controller has two processors, an F7 and an F3, hence the names “Binary” = two processors, and “F10” = F7+F3.
F10 is just a ‘clever’ name they came up with, people, F10 chip doesn’t exist!
For more info about processor in flight controllers, see my article on the differences between F1, F3, F4 and F7.
Like a standard flight controller, it runs a normal flight software on the main F7 processor, such as Butterflight or Betaflight. The difference is that it offloads the gyro filtering with an F3 chip, leaving the F7 with more resources to do other things.
This technology is called “IMU-F system”, developed by HelioRC. When you flash Betaflight or Butterflight on a board with this feature, it will remove all the software gyro filtering, as it’s all done by the dedicated F3 chip.
The Strix Binary F10 is equipped with an ICM20601 Gyro, and you could run 32K/32K looptime on it with fairly low CPU utilization.
Other existing F4, or even F7 flight controllers are beginning to struggle to run fast looptime due to the increasing amount of filtering and features added in every new version.
Most recently I’ve been flying the CL Racing F7, and with my normal config I could only use 16K looptime without maxing out CPU utilization. As far as I know, it might get worse in Betaflight 4.0.
That’s where the Strix Binary F10 comes in, it’s more future proofing if you care about running the fastest looptime possible. If you don’t care, and happy with just 8K/8K, then it might be less appealing to you.
Another big selling point of this FC would be the “secret” gyro filtering system using a dedicated F3 chip. I still can’t comment on its performance yet as I will have to do more intensive testing and comparison.
What’s the Additional F3 Actually Doing?
We don’t know because it’s close source. It’s really a mystery what it’s doing and if it’s any better or worse than the existing software filters in Betaflight.
The F3 processor is loaded with HelioRC’s “IMU-F System” – a proprietary gyro filtering algorithm.
All we know is that the IMU-F system filters/processes the information coming out of the gyro, and then pass on the filtered gyro data to the main processor for PID calculations.
This leaves more processing power to the flight controller for running other stuff.
Layout and Build Quality
The Binary F10 is built on a creamy blue PCB, and comes with purple rubber grommets for soft mounting. The layout is pretty logical, and it’s optimized for 4in1 ESC by using header connector. Note that the RX4 pin in the 4in1 ESC header is for ESC telemetry.
There are four extruded solder pads at the corners which are the ESC signals and grounds, so it should be easy to use with separate ESC’s as well. If you don’t use them, and if they get in the way when mounting in the frame, I think it’s possible to just snap them off with a wire cutter (extremely carefully).
Unfortunately, I noticed there is some residue on the solder pads (enlarge images to see), and I recommend cleaning them with rubbing alcohol before soldering. Maybe that’s because the sample i received is an early test board? Anyway It’s not a deal breaker.
The F10 claims to have dedicated SBUS and SmartPort pads, something unnecessary in my opinion when it comes to an F7 FC, since all the UART’s can handle ‘inverted’ signals. Just makes it confusing for new comers if they aren’t Frsky users, and think they can’t use these pads?
Solder pads are only available on the top side of the board, there is nothing on the bottom.
Binary F10 FC Specifications
You can use it with Butterflight right now. I’ve been told that Betaflight and iNav will soon support it too, but there is no exact deadline.
The Binary F10 is basically an upgraded Helio Spring, from F4 to F7 as the main processor. Features and spec are similar:
- Processors: STM32F722
- IMU: ICM20601 Gyro with F3 filtering system
- Supports Betaflight OSD
- BEC: 3.3V & 5V/2.5A
- 5 UART’s
- 4 Motor Outputs
- Input Voltage: up to 6S
- Supports Camera Control via OSD pin
- Dimensions: 40x36mm including motor tabs
It comes only with a cable to connect to a 4in1 ESC, no other accessories.
A very low profile board, the grommets are short and fit normal nylon standoffs without problem.
Here is the pinout diagram to help you with the wiring.
Testing
At the moment only Butterflight supports it. I want to try it with Betaflight so I will wait. My goal is to compare it to another F7 FC with the same gyro, and it makes sense to use the same FC firmware. It’s more fair to keep the number of variables to a minimum. I am truly curious about whether the “Helio IMU-F System” is actually making an positive impact or not to flight performance.
14 comments
EmuFlight supports this FC: https://github.com/emuflight/EmuFlight
Pilots are welcome to use any IMUF binary they prefer, whether by EmuOrg or HelioRC — pilots choice. “Latest” version does not mean better. Latest means “different”. Pilots should use whatever binary works for them, even HelioRC’s if preferred.
EmuFlight IMUF binaries: https://github.com/emuflight/imu-f/releases
HelioRC IMUF binaries: https://github.com/heliorc/imuf-release-dev
EmuFllight IMUF-Flasher Tool: https://github.com/emuflight/Nemesis/releases/tag/imuf-flasher-0.1.0
This is an old article but still it’s very good one with valuable information and good comments, so I want to put mine too…I got one Helios Sprint V2 and another AIO, the AIO broke before actually able to fly. The V2 still is alive, I used for some time and the main difference I was able to notice (using Betaflight firmware 3.5.1 or 3.5.2 with ODIN 107) was smoother flight than my other F.Controllers, all of them with BF same version. The helio with all default settings except for my rates.
Recently I added Emuflight to my old Helio Spring V2, and even with the latest Emuflight 0.3.x and previous versions still was able to fly smooth but something on the feeling is not the same, I never used for anything more than 8/8 kHz, I remember originally they recommended not to go over 16/16 or so.
Now is easy to agree with the comment about not need for 32khz, but initially when 32khz came out many of us bought the idea, but even at that initial time, the 32khz never worked better for me, generally I have more noise and hotter motors when loop times are over 4/4, there are some good FC that I don’t see difference from 4/4 and 8/8 loops.
I personally like the idea of having a dedicated F3 to handle the gyro filtering and pass the signal to the main processor ( any F405 is more than enough as main processor), so far to me that FC architecture works better than any F7 or H7, I would like to see the current Betaflight 4.2 supporting flight controller with IMUF systems.
Was there any testing done with this one? Kinda curious to see how it went and if iNav or BetaFlight works properly.
it’s not been supported by Betaflight, so i have yet to test it.
Nothing special here really. FC just has an on-board IMU. Any off-the-shelf IMU could be used with any FC, but they are expensive (aka old technology monopolized by the defense industry). Note the MPU6000 and ICM20689 both have an embedded F3 CPU called the Digital Motion Processor (DMP). However, its throughput is only about 100hz which is not sufficient for a multi-rotor stabilization. The ICM20602 ddoe snot have the DMP and is half the price and technically a better sensor too.
I really just cant find myself getting on board with closed source solutions in this hobby. Its a neat approach to getting 32k loops, but leaves a bit to be desired on the software side.
You mention it has i2c ports, where are they?
I have the same question.
It doesn’t have i2c, but SPI.
neither Inav or Betaflight will actively support any thing helio does thanks to its nasty behaviour towards both projects when they brought up the issue of GPL violations so any so called BF or Inav that you might get for the board will not be what you think it is.. the bf 3.5 port that is currently out there for the old spring has a number of features turned off at the software level so its quite deceptive to the user as the cli and the GUI both appear to have the disabled functions working…
the only people pushing any kind of 32k sampling pretty much want your money.. the control frequency range that is control motion in a quad is 0-30hz.. the prop wash frequency is 30-90hz.. every thing else above that is junk. so why do you want a gyro sampling at a rate where it pulls in a huge amount of noise above those frequencies ? also the motors are the slowest part of the equation and running the pid loop at 32k simiply means the FC is re calculating the same information over and over again waiting for the motors to actually react.. right now no one has written any thing for a mini quad that actually comes even close to requiring the HP that the f7 chips have and the small gains in processing speed of the PID loop do not out weigh the extra work needed to clean all of the junk noise out of the higher sample rate.. you won’t find any data what so every to back up all the marking claims been made about f7 Fc’s… its a number hype train and in this cause more isn’t better
You mentioned that FlightOne will be supported in the future. I think it was a mistake as I believe it’s RaceFlightOne which will be supported. RaceFlightOne is not the same as FlightOne)
I thought FlightOne is Raceflight or the other way around… I don’t know… anyway I removed it all together to avoid any confusions.
“Note that there is no dedicated ESC telemetry pin in the 4in1 ESC header.”
Isn’t that what the RX4 pin is on the 4-in-1 header?
oops, you are right :)