Add BETAFPVG473_V3 #928
Merged
Add BETAFPVG473_V3 #928
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
WalkthroughAdds a new board configuration header Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Areas to inspect closely:
Possibly related PRs
Suggested reviewers
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
haslinghuis
requested changes
Oct 17, 2025
Co-authored-by: Mark Haslinghuis <[email protected]>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Co-authored-by: Mark Haslinghuis <[email protected]>
haslinghuis
approved these changes
Oct 20, 2025
ot0tot
reviewed
Oct 22, 2025
Co-authored-by: ot0tot <[email protected]>
haslinghuis
reviewed
Nov 2, 2025
Member
|
@liyouluo can you check the buzzer works ? had a spate of boards where it hasn't been checked and they don't work |
Contributor
Author
We have conducted tests, and the current configuration is for active buzzers. To use a passive buzzer, you need to supplement the Timer and beeper_frequency configurations. For example, for BETAPPVG473 (V1/V2/V3), you can enter:
for BETAPPVH725, you can enter:
Of course, users can also change the sound by setting the beeper_frequency. |
sugaarK
approved these changes
Nov 17, 2025
ot0tot
requested changes
Dec 3, 2025
Contributor
ot0tot
left a comment
ot0tot
left a comment
There was a problem hiding this comment.
- We do not recommend the BMI270, it is slow and inaccurate.
- The BMI270 has a different orientation and will require a different target.
Contributor
Author
BMI270 support has been removed. |
Contributor
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
configs/BETAFPVG473_V3/config.h (1)
88-115: Serial/I2C instances, beeper, and PINIO1 configuration are coherent; consider documenting PINIO1 behavior
MSP_DISPLAYPORT_UARTusesSERIAL_PORT_UART4underUSE_OSD_HD, whileSERIALRX_UARTusesSERIAL_PORT_USART1orSERIAL_PORT_USART3depending on SBUS vs CRSF. These identifiers align with the validSERIAL_PORT_USARTx/SERIAL_PORT_UART4naming from the Betaflight codebase, and match the UART pin defines. Based on learnings, this avoids invalid identifiers likeSERIAL_PORT_UART3.BARO_I2C_INSTANCEandMAG_I2C_INSTANCEare bothI2CDEV_1, which matches the single I2C bus defined (I2C1_SCL_PIN/I2C1_SDA_PIN).PINIO1_PINis defined alongsidePINIO1_BOXandPINIO1_CONFIG, satisfying the requirement that each PINIOx_BOX/CONFIG has a corresponding PINIOx_PIN. Based on learnings, this is mandatory for valid PINIO usage.BEEPER_PINonPA8withBEEPER_INVERTEDmatches the buzzer discussions in the PR and is consistent with an active buzzer configuration.Given the prior reviewer discussion about
PINIO1_CONFIGand the 9V BEC behavior, you might optionally add a brief comment explaining whyPINIO1_CONFIGis intentionally1(non‑inverted) for this board, to prevent future confusion. For example:-#define PINIO1_BOX 40 -#define PINIO1_CONFIG 1 -#define BOX_USER1_NAME "VTX PWR" +// PINIO1 drives the 9V BEC enable; keep CONFIG = 1 (non‑inverted) to match +// the schematic behaviour (CONFIG = 129 would invert the logic and break VTX PWR). +#define PINIO1_BOX 40 +#define PINIO1_CONFIG 1 +#define BOX_USER1_NAME "VTX PWR"Otherwise, this section looks solid.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
configs/BETAFPVG473_V3/config.h(1 hunks)
🧰 Additional context used
🧠 Learnings (23)
📓 Common learnings
Learnt from: haslinghuis
Repo: betaflight/config PR: 835
File: configs/HDZERO_HALO_MPU6000/config.h:44-56
Timestamp: 2025-07-14T16:16:56.822Z
Learning: For Betaflight board configurations of boards already in production, pin assignments in config.h files reflect the actual hardware design and cannot be changed, even if they present potential conflicts with debug interfaces. The configuration must match the physical board layout, not ideal software design preferences.
Learnt from: ot0tot
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-07-03T04:33:57.480Z
Learning: Always verify that the `BOARD_NAME` define in config.h files exactly matches the directory name where the config file is located. For example, if the config file is in configs/AXISFLYINGF7AIO/config.h, then the BOARD_NAME should be defined as "AXISFLYINGF7AIO". This ensures proper board identification and configuration loading in Betaflight.
Learnt from: ot0tot
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-07-03T04:33:57.480Z
Learning: Always verify that the BOARD_NAME define in each config.h matches the directory name it resides in (e.g., configs/AXISFLYINGF7AIO/config.h must have #define BOARD_NAME AXISFLYINGF7AIO). This check is required for all Betaflight board configuration reviews.
Learnt from: haslinghuis
Repo: betaflight/config PR: 879
File: configs/AIRBOTSUPERF4V2/config.h:42-45
Timestamp: 2025-08-22T17:08:23.283Z
Learning: In Betaflight board configurations, OSD feature flags like USE_OSD_SD (analog/MAX7456) and USE_OSD_HD (digital/MSP DisplayPort) are typically defined at build time by the build system, not in the individual board config.h files. Board configs can conditionally define OSD-related settings based on these build-time flags.
Learnt from: haslinghuis
Repo: betaflight/config PR: 792
File: configs/BEEROTORF4/config.h:30-30
Timestamp: 2025-05-28T15:42:05.402Z
Learning: The DEFAULT_GYRO_ENABLED macro with both gyros enabled (GYRO_MASK(0) | GYRO_MASK(1)) should only be added to board configurations that have DEFAULT_GYRO_TO_USE set to GYRO_CONFIG_USE_GYRO_BOTH. Boards without this setting should only get the GYRO_COUNT definition to specify the number of available gyros.
Learnt from: haslinghuis
Repo: betaflight/config PR: 792
File: configs/BEEROTORF4/config.h:30-30
Timestamp: 2025-05-28T15:42:05.402Z
Learning: The DEFAULT_GYRO_ENABLED macro with both gyros enabled (GYRO_MASK(0) | GYRO_MASK(1)) should only be added to board configurations that have DEFAULT_GYRO_TO_USE set to GYRO_CONFIG_USE_GYRO_BOTH. Boards without this setting should only get the GYRO_COUNT definition.
Learnt from: haslinghuis
Repo: betaflight/config PR: 656
File: configs/IFLIGHT_F745_AIO/config.h:31-35
Timestamp: 2025-07-28T16:44:59.686Z
Learning: In Betaflight board configurations, when a board design uses the same physical gyro socket but different sensor variants across production batches (e.g., MPU6000 in older batches, ICM42688P in newer batches), the correct approach is to enable both sensor drivers (USE_GYRO_SPI_MPU6000 and USE_GYRO_SPI_ICM42688P) in the same configuration. This allows runtime auto-detection of which sensor is actually present without requiring separate board configurations for each hardware variant.
Learnt from: haslinghuis
Repo: betaflight/config PR: 822
File: configs/AXISFLYINGH7MINI/config.h:29-37
Timestamp: 2025-06-23T18:43:31.746Z
Learning: In Betaflight configuration files, feature enablement macros like USE_MAG are build options that can be controlled at compile time, while hardware instance definitions like MAG_I2C_INSTANCE are predefined in board configurations to assist with hardware mapping when those features are enabled at build time.
📚 Learning: 2025-07-14T16:16:56.822Z
Learnt from: haslinghuis
Repo: betaflight/config PR: 835
File: configs/HDZERO_HALO_MPU6000/config.h:44-56
Timestamp: 2025-07-14T16:16:56.822Z
Learning: For Betaflight board configurations of boards already in production, pin assignments in config.h files reflect the actual hardware design and cannot be changed, even if they present potential conflicts with debug interfaces. The configuration must match the physical board layout, not ideal software design preferences.
Applied to files:
configs/BETAFPVG473_V3/config.h
📚 Learning: 2025-07-03T04:33:57.480Z
Learnt from: ot0tot
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-07-03T04:33:57.480Z
Learning: Always verify that the BOARD_NAME define in each config.h matches the directory name it resides in (e.g., configs/AXISFLYINGF7AIO/config.h must have #define BOARD_NAME AXISFLYINGF7AIO). This check is required for all Betaflight board configuration reviews.
Applied to files:
configs/BETAFPVG473_V3/config.h
📚 Learning: 2025-08-22T17:08:23.283Z
Learnt from: haslinghuis
Repo: betaflight/config PR: 879
File: configs/AIRBOTSUPERF4V2/config.h:42-45
Timestamp: 2025-08-22T17:08:23.283Z
Learning: In Betaflight board configurations, OSD feature flags like USE_OSD_SD (analog/MAX7456) and USE_OSD_HD (digital/MSP DisplayPort) are typically defined at build time by the build system, not in the individual board config.h files. Board configs can conditionally define OSD-related settings based on these build-time flags.
Applied to files:
configs/BETAFPVG473_V3/config.h
📚 Learning: 2025-06-23T18:43:31.746Z
Learnt from: haslinghuis
Repo: betaflight/config PR: 822
File: configs/AXISFLYINGH7MINI/config.h:29-37
Timestamp: 2025-06-23T18:43:31.746Z
Learning: In Betaflight configuration files, feature enablement macros like USE_MAG are build options that can be controlled at compile time, while hardware instance definitions like MAG_I2C_INSTANCE are predefined in board configurations to assist with hardware mapping when those features are enabled at build time.
Applied to files:
configs/BETAFPVG473_V3/config.h
📚 Learning: 2025-07-03T04:33:57.480Z
Learnt from: ot0tot
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-07-03T04:33:57.480Z
Learning: Always verify that the `BOARD_NAME` define in config.h files exactly matches the directory name where the config file is located. For example, if the config file is in configs/AXISFLYINGF7AIO/config.h, then the BOARD_NAME should be defined as "AXISFLYINGF7AIO". This ensures proper board identification and configuration loading in Betaflight.
Applied to files:
configs/BETAFPVG473_V3/config.h
📚 Learning: 2025-07-03T15:17:30.040Z
Learnt from: haslinghuis
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-07-03T15:17:30.040Z
Learning: In Betaflight configurations, when a target name suggests dual IMUs (like JHEF7DUAL) but specific hardware variants only have one gyro available, the preferred solution is to use DEFAULT_GYRO_TO_USE macro to specify which gyro to use by default rather than pruning gyro defines or creating redundant configurations. This approach maintains compatibility when the same target is used by multiple hardware variants from the same manufacturer.
Applied to files:
configs/BETAFPVG473_V3/config.h
📚 Learning: 2025-08-10T14:08:56.662Z
Learnt from: blckmn
Repo: betaflight/config PR: 851
File: configs/HELLBENDER_0001/config.h:45-46
Timestamp: 2025-08-10T14:08:56.662Z
Learning: In Betaflight, USE_LED_STRIP is a cloud build option that enables/disables the LED strip feature at build time. Individual target config files (configs/*/config.h) only need to define LED_STRIP_PIN as a default pin assignment - they should not define USE_LED_STRIP themselves. The feature enablement is handled externally through the cloud build system, not through preprocessor directives in the config files.
Applied to files:
configs/BETAFPVG473_V3/config.h
📚 Learning: 2025-09-26T16:32:46.694Z
Learnt from: osirisinferi
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-09-26T16:32:46.694Z
Learning: When reviewing hardware configuration files like Betaflight configs, always check for pin assignment conflicts by verifying that no physical pins (like PB10, PB11, etc.) are assigned to multiple peripheral functions simultaneously.
Applied to files:
configs/BETAFPVG473_V3/config.h
📚 Learning: 2025-07-23T13:43:50.456Z
Learnt from: ot0tot
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-07-23T13:43:50.456Z
Learning: For Betaflight board configuration reviews, always verify that serial port defines (like ESC_SENSOR_UART, MSP_UART, GPS_UART, etc.) use valid SERIAL_PORT identifiers that match those defined in the Betaflight codebase at src/main/io/serial.h. Common valid identifiers include SERIAL_PORT_USART1, SERIAL_PORT_USART2, SERIAL_PORT_USART3, SERIAL_PORT_UART4, SERIAL_PORT_UART5, etc. Invalid identifiers like SERIAL_PORT_UART3 (should be SERIAL_PORT_USART3) will cause build failures.
Applied to files:
configs/BETAFPVG473_V3/config.h
📚 Learning: 2025-12-03T20:45:27.870Z
Learnt from: osirisinferi
Repo: betaflight/config PR: 972
File: configs/AXISFLYING_H743PRO/config.h:0-0
Timestamp: 2025-12-03T20:45:27.870Z
Learning: In Betaflight board configurations, always verify that TIMER_PIN_MAP entries do not use the same pin macro name multiple times. Each physical pin should appear only once in the TIMER_PIN_MAP definitions. For example, GYRO_1_CLKIN_PIN and GYRO_2_CLKIN_PIN should each appear exactly once, not have GYRO_1_CLKIN_PIN appear twice. This is a blocking issue that must be resolved before approval.
Applied to files:
configs/BETAFPVG473_V3/config.h
📚 Learning: 2025-06-02T16:16:20.197Z
Learnt from: haslinghuis
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-06-02T16:16:20.197Z
Learning: In STM32F405-based flight controller configurations, timer pin mappings must be carefully analyzed for DMA stream conflicts, especially between motor timers, LED strip timers, and SPI DMA assignments. Changes to TIMER_PIN_MAPPING should include verification that all required peripherals (motors, LED strip, blackbox SPI) can coexist without DMA conflicts.
Applied to files:
configs/BETAFPVG473_V3/config.h
📚 Learning: 2025-07-14T15:41:14.364Z
Learnt from: ot0tot
Repo: betaflight/config PR: 834
File: configs/RADIOLINKF405/config.h:79-88
Timestamp: 2025-07-14T15:41:14.364Z
Learning: In STM32F405 configurations, PB1 typically maps to TIM3_CH4 and PC9 typically maps to TIM8_CH4. These are different timers and do not share DMA resources, so there is no conflict when both pins are used simultaneously (e.g., PB1 for LED_STRIP and PC9 for MOTOR4).
Applied to files:
configs/BETAFPVG473_V3/config.h
📚 Learning: 2025-05-31T17:01:39.423Z
Learnt from: haslinghuis
Repo: betaflight/config PR: 798
File: configs/FURYF4OSD/config.h:88-88
Timestamp: 2025-05-31T17:01:39.423Z
Learning: For STM32F4xx platforms, PB1 pin timer definitions are:
1 = DEF_TIM(TIM1, CH3N, PB1, 0, 0)
2 = DEF_TIM(TIM3, CH4, PB1, 0, 0)
3 = DEF_TIM(TIM8, CH3N, PB1, 0, 0)
Timer instance 2 (TIM3, CH4) is the correct mapping for PB1 motor control on STM32F4xx platforms as defined in src/platform/STM32/timer_stm32f4xx.c
Applied to files:
configs/BETAFPVG473_V3/config.h
📚 Learning: 2025-08-28T20:45:36.652Z
Learnt from: haslinghuis
Repo: betaflight/config PR: 888
File: configs/ZEX_ATHENA_MINI/config.h:0-0
Timestamp: 2025-08-28T20:45:36.652Z
Learning: In STM32H743 Betaflight configurations, PA15 maps to TIM2_CH1 (timer index 2) as defined in timer_stm32h7xx.c. When used for GYRO_CLKIN functionality, it's recommended to use the macro name GYRO_1_CLKIN_PIN in TIMER_PIN_MAPPING for consistency with other pin definitions.
Applied to files:
configs/BETAFPVG473_V3/config.h
📚 Learning: 2025-08-28T20:45:36.652Z
Learnt from: haslinghuis
Repo: betaflight/config PR: 888
File: configs/ZEX_ATHENA_MINI/config.h:0-0
Timestamp: 2025-08-28T20:45:36.652Z
Learning: In STM32H743 Betaflight configurations, PB0 can use multiple timer options including TIM1_CH2N, TIM3_CH3, and TIM8_CH2N as defined in timer_stm32h7xx.c. For CAMERA_CONTROL_PIN assignments, TIM3_CH3 (timer index 3) is the appropriate choice.
Applied to files:
configs/BETAFPVG473_V3/config.h
📚 Learning: 2025-09-01T19:58:52.049Z
Learnt from: haslinghuis
Repo: betaflight/config PR: 881
File: configs/GEPRC_TAKER_H743MINI/config.h:86-99
Timestamp: 2025-09-01T19:58:52.049Z
Learning: For STM32H743 PB0 in Betaflight, there are three timer options: TIM1_CH2N, TIM3_CH3, and TIM8_CH2N. Only TIM3_CH3 (timer index 2) is suitable for GYRO_CLKIN as the other two are complementary (N) channels. This is confirmed in timer_stm32h7xx.c.
Applied to files:
configs/BETAFPVG473_V3/config.h
📚 Learning: 2025-09-01T19:58:52.049Z
Learnt from: haslinghuis
Repo: betaflight/config PR: 881
File: configs/GEPRC_TAKER_H743MINI/config.h:86-99
Timestamp: 2025-09-01T19:58:52.049Z
Learning: For STM32H743 in Betaflight, PB0 has multiple timer options but only timer index 2 provides a non-complementary output suitable for GYRO_CLKIN functionality. The other timer options for PB0 are N channels (complementary outputs) which are not appropriate for CLKIN usage.
Applied to files:
configs/BETAFPVG473_V3/config.h
📚 Learning: 2025-06-23T18:44:59.162Z
Learnt from: haslinghuis
Repo: betaflight/config PR: 822
File: configs/AXISFLYINGH7MINI/config.h:121-129
Timestamp: 2025-06-23T18:44:59.162Z
Learning: In Betaflight configuration files, USE_OSD_HD and USE_MAX7456 are for different OSD systems: USE_MAX7456 enables the MAX7456 analog OSD chip, while USE_OSD_HD enables HD/digital OSD via MSP. MSP_DISPLAYPORT_UART should be guarded by USE_OSD_HD, not USE_MAX7456, as they serve different OSD implementations.
Applied to files:
configs/BETAFPVG473_V3/config.h
📚 Learning: 2025-05-28T15:45:15.608Z
Learnt from: haslinghuis
Repo: betaflight/config PR: 792
File: configs/MERAKRCF722/config.h:32-32
Timestamp: 2025-05-28T15:45:15.608Z
Learning: The presence of GYRO_2_SPI_INSTANCE definition in a board config does not necessarily mean the board uses dual gyros. Some boards have GYRO_2_SPI_INSTANCE defined but it's not actually used, so they should not receive GYRO_COUNT or other dual-gyro related definitions. Only boards that actually utilize dual gyros should get these definitions.
Applied to files:
configs/BETAFPVG473_V3/config.h
📚 Learning: 2025-12-03T20:50:01.360Z
Learnt from: osirisinferi
Repo: betaflight/config PR: 972
File: configs/AXISFLYING_H743PRO/config.h:98-98
Timestamp: 2025-12-03T20:50:01.360Z
Learning: In Betaflight board configurations, if PINIOx_BOX or PINIOx_CONFIG defines are present in a config.h file, the corresponding PINIOx_PIN define must also be present to specify the actual pin assignment. Each PINIO instance requires a pin definition before it can be configured or assigned to a box.
Applied to files:
configs/BETAFPVG473_V3/config.h
📚 Learning: 2025-07-14T15:38:06.837Z
Learnt from: ot0tot
Repo: betaflight/config PR: 834
File: configs/RADIOLINKF405/config.h:52-53
Timestamp: 2025-07-14T15:38:06.837Z
Learning: In Betaflight flight controller configurations, it's common and intentional for UART2_RX_PIN and RX_PPM_PIN to share the same GPIO pin (like PA3) because they represent mutually exclusive receiver input protocols. The pin can be configured for either serial receiver input (UART2) or PPM input, but not both simultaneously. This is a standard design pattern in flight controller hardware.
Applied to files:
configs/BETAFPVG473_V3/config.h
📚 Learning: 2025-08-20T02:54:58.596Z
Learnt from: ot0tot
Repo: betaflight/config PR: 872
File: configs/HGLRCH743/config.h:82-83
Timestamp: 2025-08-20T02:54:58.596Z
Learning: For Betaflight board configuration reviews, the definitive source for validating UART pin assignments is the serial_uart_{platform}.c file in the Betaflight codebase (e.g., serial_uart_stm32h7xx.c for STM32H7xx platforms), not generic MCU datasheets. These files contain the exact pin mappings that Betaflight supports for each UART peripheral.
Applied to files:
configs/BETAFPVG473_V3/config.h
🔇 Additional comments (2)
configs/BETAFPVG473_V3/config.h (2)
24-40: Target MCU, board name, and feature set look consistent
FC_TARGET_MCU STM32G47Xmatches the G473‑based target implied by the board name.BOARD_NAME BETAFPVG473_V3matches the directory nameBETAFPVG473_V3as required for Betaflight targets.- Sensor/flash/OSD/baro flags (
USE_ACC/GYRO,USE_ACC/GYRO_SPI_ICM42688P,USE_FLASH_M25P16,USE_MAX7456,USE_BARO_*,USE_GYRO_CLKIN) follow the usual pattern and align with having a single SPI IMU, onboard flash, MAX7456, and I2C baro.No changes requested here.
41-83: GPIO and timer mappings are self‑consistent; no pin conflicts detected
- Each GPIO macro (
BEEPER_PIN, motors, LED strip, UARTs, I2C, LEDs, SPI, ADC, PINIO1, flash/OSD/gyro pins) is assigned to a unique MCU pin; there are no conflicting reuse cases beyond standard patterns, satisfying the “no double‑use of a physical pin” guidance. Based on learnings, this is important for avoiding subtle hardware conflicts.TIMER_PIN_MAPPINGuses onlyLED_STRIP_PIN,MOTOR1_PIN–MOTOR4_PIN, andGYRO_1_CLKIN_PIN, and each of those pin macros appears exactly once in the mapping, matching the latest reviewer suggestion and the requirement that each pin be used once in the timer map.This block looks good as‑is.
ot0tot
approved these changes
Dec 4, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi.
The schematic has been reviewed in Discord.
please check the config.
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.