iNavFlight
target: add CIPHERWINGF4 (STM32F405)
User description
🧩 Summary
Adds support for Cipherwing F4 — a custom STM32F405 flight-controller board derived from Omnibus F4, with a fully customized UART, ADC, and motor-timer map.
⚙️ Board Information
🧱 Folder Structure
📦 Build Information
✅ Hardware Verification
-
IMU detected (SPI1)
-
OSD & Blackbox operational (SPI3)
-
VBAT / RSSI ADC inputs functional
-
8 motor outputs verified (PWM + DSHOT)
-
LED strip on PB6 and beeper on PB4 tested
-
UART mapping validated (CRSF on UART1)
🧾 Notes
-
Only one IMU should be active at a time (shared SPI1 bus).
-
UART5 TX left unassigned to avoid conflict with SPI3 MOSI.
-
Current sensor input removed — VBAT and RSSI only.
🧰 Files Added
PR Type
Enhancement
Description
-
Adds support for Cipherwing F4 STM32F405 flight controller board
-
Implements custom UART, ADC, and motor-timer configuration
-
Defines 8-motor PWM outputs with LED strip support
-
Configures IMU, OSD, blackbox flash, and sensor interfaces
Diagram Walkthrough
flowchart LR
A["CIPHERWINGF4<br/>STM32F405RG"] --> B["8 Motor Outputs<br/>TIM1/3/4/8/12"]
A --> C["LED Strip<br/>TIM4 CH1 PB6"]
A --> D["Sensors<br/>IMU/MAG/BARO"]
A --> E["Interfaces<br/>6 UARTs SPI I2C"]
A --> F["Storage<br/>OSD MAX7456<br/>Blackbox M25P16"]
File Walkthrough
| Relevant files | |||||||
|---|---|---|---|---|---|---|---|
| Configuration changes |
|
PR Compliance Guide 🔍
All compliance sections have been disabled in the configurations.
![qodo-code-review[bot] avatar](https://avatars.githubusercontent.com/in/484649?v=4 "Published by a pub.dev verified publisher"){kind=small}
PR Code Suggestions ✨
Explore these optional code suggestions:
| Category | Suggestion | Impact |
| Possible issue |
Correct an invalid UART pin assignmentCorrect the src/main/target/CIPHERWINGF4/target.h [85-87]
Suggestion importance[1-10]: 9__ Why: The suggestion correctly identifies that | High |
Reassign LED pin to resolve conflictReassign src/main/target/CIPHERWINGF4/target.h [18]
Suggestion importance[1-10]: 8__ Why: The suggestion provides a valid solution to a complex pin conflict involving | Medium | |
| ||
Please note that new targets must follow the INAV New Hardware Policy
Have you been in contact with any developers?
Thanks for the automated suggestions 🙏 For this board, UART5 is intentionally RX-only — it’s used exclusively for SBUS/CRSF input. There is no TX pad on the PCB, and assigning one would create a hardware conflict (PC12 is already used for SPI3 MOSI for OSD + Flash). Therefore, UART5_TX is left as a dummy / unconnected assignment to maintain target consistency, and this is the expected behavior for the Cipherwing F4.
No change required — design verified and working as intended ✅
Please note that new targets must follow the INAV New Hardware Policy
Have you been in contact with any developers?
Thanks for the reminder about the INAV New Hardware Policy 🙏
The Cipherwing F4 (STM32F405) is part of an early testing phase for our upcoming product line. It’s not an official or mass-produced board yet — this PR is mainly to start early firmware validation and bring-up testing within INAV.
Key points: • The hardware is based on Omnibus F4 architecture, with a custom UART, ADC, and motor-timer map. • The board fully meets INAV’s technical requirements (IMU, baro, I²C, 512 KB+ flash, 128 KB RAM, etc.). • UART5 is RX-only by design; there is no TX pad on the PCB (PC12 is used by SPI3 MOSI for OSD + Flash). • All major peripherals (IMU, OSD, Flash, VBAT/RSSI, LEDs, buzzer, and motor outputs) are functional and tested.
This target is intended for internal and community testing only, not as an official commercial release at this stage.
Once the board reaches its stable revision, I’ll be happy to coordinate with INAV maintainers to provide documentation, samples, and request official inclusion.
Please proceed treating this PR as an unofficial / prototype target submission for evaluation and early feedback.
Thanks for the automated suggestions 🙏 For this board, UART5 is intentionally RX-only — it’s used exclusively for SBUS/CRSF input. There is no TX pad on the PCB, and assigning one would create a hardware conflict (PC12 is already used for SPI3 MOSI for OSD + Flash). Therefore, UART5_TX is left as a dummy / unconnected assignment to maintain target consistency, and this is the expected behavior for the Cipherwing F4.
No change required — design verified and working as intended ✅
IMHO, the RX UART should be a full UART. The only SBUS needs only the RX UART pad. All other protocols, which are more widely used, use RX and TX. The only thing I can think of where only a UART receiver pad is needed is ESC telemetry from a BLHeli32 ESC.
I really don't think the Omnibus F4 is a good FC to base a new FC on. It was limited when it was release years ago. It is even more limited now. UART wise, it's only half a UART better than an F411 based FC. Modern F405 based FCs have 4 or 5 full UARTs broken out. It would be better to start from the ground up with the design or look at more modern flight controllers for inspiration.
Thanks for the automated suggestions 🙏 For this board, UART5 is intentionally RX-only — it’s used exclusively for SBUS/CRSF input. There is no TX pad on the PCB, and assigning one would create a hardware conflict (PC12 is already used for SPI3 MOSI for OSD + Flash). Therefore, UART5_TX is left as a dummy / unconnected assignment to maintain target consistency, and this is the expected behavior for the Cipherwing F4.
No change required — design verified and working as intended ✅
IMHO, the RX UART should be a full UART. The only SBUS needs only the RX UART pad. All other protocols, which are more widely used, use RX and TX. The only thing I can think of where only a UART receiver pad is needed is ESC telemetry from a BLHeli32 ESC.
I really don't think the Omnibus F4 is a good FC to base a new FC on. It was limited when it was release years ago. It is even more limited now. UART wise, it's only half a UART better than an F411 based FC. Modern F405 based FCs have 4 or 5 full UARTs broken out. It would be better to start from the ground up with the design or look at more modern flight controllers for inspiration.
About the RX-only UART: I agree that most modern receiver protocols (CRSF/ELRS, MSP, telemetry) need full duplex. On this board those live on full UARTs. Only UART5 is intentionally RX-only for cases like SBUS (or optional BLHeli32 ESC telem). The board exposes multiple full UARTs on pads: • UART1 (RX/TX) – intended for CRSF/ELRS • UART2 (RX/TX) • UART3 (RX/TX) • UART4 (RX/TX) • UART6 (RX/TX) • UART5 – RX-only by design (no TX pad; PC12 is SPI3 MOSI for OSD/Flash)
So the target meets the policy requirement of ≥3 full UARTs; RX-only UART5 is just an extra dedicated SBUS/telemetry input.
About basing on Omnibus F4: Totally hear you—Omnibus F4 is dated. I reused its general layout for a prototype/bring-up because parts and reference designs are easy to source, but the pinout is fully customized (8 PWM, SPI3 OSD+Flash, I²C sensors, VBAT/RSSI, etc.). This PR is explicitly for early validation / community testing, not a production endorsement.
For the next hardware rev, I plan to: • keep 4–5 full UARTs broken out (minimum), • consider a more modern layout (or F7) for better IO headroom, • submit updated docs/schematics alongside samples if we pursue official inclusion.
If preferred, I’m happy to keep this as an unofficial/prototype target (e.g., CIPHERWINGF4-DEV) while we iterate. Thanks again for the guidance—open to any specific changes you’d like on the target to align better with INAV expectations.
OK, that's sounding pretty cool. It sounds like it is much different to the Omnibus F4 at this stage. So I would probably remove that association, as it just raises red flags. I immediately thought 2.5 UARTs and issues using UART 3 due to the I2C integration.
As this is still in development, and doesn't yet meet the new hardware policy (due to INAV developers not having test samples). I'm going to add the do not merge label. But this is just to put that on hold while the development is taking place. So don't see it as bad. It's just temporary while you guys carry on working on the FC 👍🏻
OK, that's sounding pretty cool. It sounds like it is much different to the Omnibus F4 at this stage. So I would probably remove that association, as it just raises red flags. I immediately thought 2.5 UARTs and issues using UART 3 due to the I2C integration.
As this is still in development, and doesn't yet meet the new hardware policy (due to INAV developers not having test samples). I'm going to add the
do not mergelabel. But this is just to put that on hold while the development is taking place. So don't see it as bad. It's just temporary while you guys carry on working on the FC 👍🏻
Thanks so much for the clarification and for keeping it open 🙏 Totally understand about the do not merge label — that makes complete sense while the hardware is still in its prototype stage.
I’ll remove the Omnibus F4 references in the next update and make the documentation clearly describe it as a stand-alone Cipherwing F4 design (since, as you said, the layout and peripherals have diverged significantly).
Over the next iteration, I’ll: • Add a proper board doc (docs/boards/CIPHERWINGF4.md) with the final pinout table and PCB photos • Prepare to share hardware samples with INAV devs once the test batch is finalized • Keep the PR updated for early firmware testing and community feedback
Thanks again for the feedback and for keeping the PR active — really appreciate the guidance! 🙌
merge label. But this is just to put that on hold
@MrD-RC Can you please verify the pcb
New version
Older version
I don't know what you mean by verify the PCB. I can look at it and offer some advice on the layout. But not much more than that. It certainly couldn't be merged just by looking at the PCB.
- What are the dimensions?
- Who is the target users (fixed-wing, multi-rotor, or general purpose)?
I don't know what you mean by verify the PCB. I can look at it and offer some advice on the layout. But not much more than that. It certainly couldn't be merged just by looking at the PCB.
- What are the dimensions?
- Who is the target users (fixed-wing, multi-rotor, or general purpose)?
Thanks for reviewing! The board dimensions are 50 mm × 42 mm. It’s designed as a general-purpose flight controller, suitable for both fixed-wing and multirotor platforms.
My first thoughts are that it is pretty large. For a standard board like this, you should be aiming for around 36mm square. I'd also aim to get all the pads that the pilots are soldering to around the outside edge in useful groups. So for all UARTs also have 5v and gnd, plus with one UART have I2C pads too. I'd go back to using through hole pads too. Then header pins or direct soldering can be used. I see there is one ADC broken out (RSSI). But it may be worth breaking out another. There is no current sensor on this FC, so an external one may be wanted. TBH, most RC links these day provide RSSI over the UART. So I would default the existing ADC to a different function. Perhaps a voltage ADC input, as this board can only handle up to 3S.
You could save a lot of space by removing the power and grounds for the servo outputs. I see this is a design taken over from Omnibus. The problem is that they were never good, as there was no separate 5V servo power rail that had enough current available. It was also only 5v, whereas most servos benefit from using 6v. Anyway, they always needed an external DC-DC to power the servos to be reliable. I see your board only has a 2A 5V rail, which powers all 5v peripherals. This really isn't enough to power servos too. For servos alone, you should be looking at a minimum of 4A when you have 6 outputs available.
Please don't take this as bad. I'm trying to be constructive.
Mr D. made some good points. The servo power rail was mentioned.
The Omnibus had three Schottky diodes on the servo rail, so it could be powered from the onboard BEC, from an external BEC, or USB. With no jumpers needed. I liked that option. It could run a couple small servos from the onboard BEC, or you could plug in an ESC with a BEC, and could test servos with just USB plugged in.
