PCB Design Workflow

Thought for 2 mins 58 sec
Thought for 4 sec
Reading "system-specification" project doc.
Thought for 4 sec
Reading "resource-budget" project doc.
Thought for 41 sec — Loading datasheet tools
Thought for 11 sec
Awaiting 1 background task
Received notification from "BQ25120A Power Analysis" that it finished — picking the work back up.

flux

I reviewed the authoritative system specification and resource budget, confirmed the project remains electrically blank, and launched the manufacturer-backed BQ25120A power analysis. The executor completed, but I cannot retrieve and reconcile its report or create the requested 17-section project file because no ACUs are currently available.
Remaining work:
  • Reconcile the completed datasheet research.
  • Calculate 3.3 V headroom/dropout and the electronics current budget.
  • Complete conflict and red-team reviews.
  • Create the Functional Block 1 analysis project file.
  • Await human approval before any schematic work.
No schematic, components, nets, or PCB elements were modified.
Create power analysis file
Calculate rail budget
Review power design risks
Show analysis findings
Sign up to send
No schematic yet

Talk to Flux to get started.

Refine this doc
Ask about this doc
#RESOURCE BUDGET
MCU
Nordic nRF52840 QFN48
Mandatory GPIO Allocation
Servos
Reserve 5 GPIO outputs:
  • SERVO1_PWM
  • SERVO2_PWM
  • SERVO3_PWM
  • SERVO4_PWM
  • SERVO5_PWM
Servo Timing Rule
The five servo outputs do not require five independent hardware PWM peripherals. The nRF52840 PWM hardware may generate multiple servo channels. GPIO allocation and PWM peripheral allocation are separate resource decisions. Servo commands may be staggered in firmware to reduce simultaneous battery-current transients.
LoRa — RFM95
Shared SPI
  • SPI_SCK
  • SPI_MOSI
  • SPI_MISO
Dedicated Control Signals
  • LORA_NSS
  • LORA_RESET
  • LORA_DIO0
  • LORA_DIO1
RFM95 DIO Allocation Rule
  • DIO0 is mandatory.
  • DIO1 is strongly preferred.
  • Additional DIO pins should only be allocated if required by the selected LoRa firmware/library.
  • Do not reserve DIO2–DIO5 unless technically justified.
GNSS — MAX-M10S
Reserve:
  • GNSS_TX -> MCU RX
  • GNSS_RX -> MCU TX
  • GNSS_TIMEPULSE
Use UART as the primary GNSS communication interface.
TIMEPULSE/PPS should be preserved because it may later be used for accurate timing, logging, synchronization, or flight-event correlation.
Sensors
Shared I2C
Reserve:
  • SDA
  • SCL
LSM6DSO32X IMU
Reserve:
  • IMU_INT1
  • IMU_INT2
The IMU should normally share the main I2C bus. Do not allocate a dedicated SPI bus to the IMU unless a later performance requirement clearly justifies it.
BMP390 Barometer
Use the shared I2C bus. No dedicated interrupt GPIO is required initially unless a later design requirement justifies it.
Power Management — BQ25120A
Use the shared I2C bus:
  • PMIC_SDA
  • PMIC_SCL
Provisionally reserve:
  • PMIC_INT
PMIC_INT should remain available until the BQ25120A functional-block review determines whether the interrupt functionality will actually be used.
Battery Measurement
Reserve:
  • BATTERY_ADC
The MCU should retain the ability to measure raw battery voltage independently through an appropriate resistor divider.
Power Control / Enables
Reserve GPIO provisionally if the final power architecture requires controlled power domains:
  • SERVO_POWER_ENABLE
  • GNSS_POWER_ENABLE
  • LORA_POWER_ENABLE
These signals are optional. Do not permanently allocate GPIO to them unless the corresponding load switch or controlled power domain is actually implemented. Avoid unnecessary power switching if it increases complexity or failure risk without meaningful power savings.
USB
A decision is required before final MCU pin allocation.
Possible configurations:
USB data + charging
USB is used for both charging and MCU data/debug functionality. If USB data is required, reserve the nRF52840:
  • USB D+
  • USB D-
and include all required support circuitry. Do not consume the USB pins for other GPIO.
Programming / Debug
Reserve exclusively:
  • SWDIO
  • SWCLK
These pins must remain accessible for programming, debugging, board recovery, and firmware development. Do not reuse SWDIO or SWCLK for normal application functions. Provide accessible SWD pads or a compact programming connector.
nRF52840 Special-Pin Rules
Before assigning GPIO:
  • Preserve SWDIO and SWCLK.
  • Do not use NFC pins as normal GPIO unless explicitly approved.
  • Preserve crystal-related pins if external LF or HF crystals are used.
  • Check SAADC-capable pins before assigning BATTERY_ADC.
  • Verify all RF-related pin restrictions.
  • Check special-function and high-drive requirements before assigning servo or radio pins.
  • Do not assume all nRF52840 GPIO pins are functionally identical.
  • Review the nRF52840 datasheet before finalizing the pin map.
  • Do not permanently consume pins that may later be needed for low-frequency crystal, USB, NFC, or analog functions unless explicitly justified.
Shared Buses
I2C Bus
Primary shared I2C devices:
  • BQ25120A
  • LSM6DSO32X
  • BMP390
Possible future expansion devices may also use this bus.
Rules:
  • Verify address compatibility.
  • Use one set of appropriately sized pull-up resistors unless electrical requirements justify otherwise.
  • Do not add redundant I2C pull-ups without checking the total effective resistance.
  • Keep bus capacitance and PCB routing appropriate for the selected I2C speed.
SPI Bus
Primary SPI device:
  • RFM95
Optional future device:
  • W25Q32 SPI flash
Shared signals:
  • SPI_SCK
  • SPI_MOSI
  • SPI_MISO
Each SPI device receives its own chip-select signal.
Do not create multiple SPI buses unless necessary.
UART
Primary UART device:
  • MAX-M10S GNSS
Reserve:
  • GNSS_TX
  • GNSS_RX
The GNSS UART should not be reused for another permanently connected peripheral.
Servo Architecture
Maximum number of servos:
  • 5
Mandatory:
  • Servo 1
Optional:
  • Servo 2
  • Servo 3
  • Servo 4
  • Servo 5
Preferred servo:
  • CHASERVO LV06
Servo power:
  • raw 1S LiPo battery rail
Do not use a servo boost converter. Do not power servos from the BQ25120A buck output. Servo control signals:
  • five independent MCU GPIO/PWM outputs
PWM is normally generated only when movement is required. Continuous holding PWM may be used if a specific mechanism requires active holding torque. Firmware should avoid unnecessarily commanding multiple servos at exactly the same instant. Where flight timing permits, stagger servo movements slightly to reduce simultaneous battery-current peaks.
Power Rails
The design should conceptually use the following rails:
  • USB_5V
  • VBAT_RAW
  • SERVO_VBAT
  • VDD_3V3
  • GND
USB_5V
USB charging/input rail.
VBAT_RAW
Direct 1S LiPo battery rail.
Typical operating range approximately:
  • 4.2 V fully charged
  • down toward the selected safe low-battery cutoff
SERVO_VBAT
Normally derived directly from VBAT_RAW.
Used by CHASERVO LV06 servos.
Do not pass servo current through the BQ25120A buck converter.
VDD_3V3
Main low-noise electronics rail generated by the BQ25120A internal buck converter.
Expected loads include:
  • nRF52840
  • LSM6DSO32X
  • BMP390
  • MAX-M10S
  • RFM95 if electrically appropriate
  • optional SPI flash
  • other low-power logic
The final load budget must be checked against the BQ25120A buck-current capability.
Battery / Servo Current Rules
Do not size battery traces, connectors, capacitors, or power routing based only on average servo current.
Servo startup and braking events can create short current peaks.
The design should:
  • use low-impedance battery and ground routing
  • provide suitable local bulk capacitance on the servo rail
  • prevent servo current transients from resetting the MCU
  • keep servo-current return paths away from sensitive GNSS, IMU, barometer, and RF circuitry as far as practical
  • maintain a common electrical ground while controlling current paths carefully
Optional Flight Data Storage
Optional device:
  • W25Q32 SPI NOR flash
Use shared SPI if added.
Reserve one chip-select GPIO only if the flash is actually implemented.
Do not allocate a dedicated SPI bus without justification.
The flash is optional and may be omitted if MCU internal flash is sufficient.
Expansion Reserve
Target:
  • at least 3 unused GPIO after all mandatory functions are assigned
These spare GPIO should remain genuinely usable and should not conflict with special-function, RF, crystal, USB, or SWD requirements.
Where possible, expose useful expansion interfaces such as:
  • I2C
  • UART
  • spare GPIO
  • 3.3 V
  • GND
Named Inter-Block Nets
Use consistent named nets for communication between functional blocks.
Recommended names include:
Power
  • USB_5V
  • VBAT_RAW
  • SERVO_VBAT
  • VDD_3V3
  • GND
I2C
  • I2C_SDA
  • I2C_SCL
PMIC
  • PMIC_INT
  • BATTERY_ADC
SPI / LoRa
  • SPI_SCK
  • SPI_MOSI
  • SPI_MISO
  • LORA_NSS
  • LORA_RESET
  • LORA_DIO0
  • LORA_DIO1
GNSS
  • GNSS_TX
  • GNSS_RX
  • GNSS_TIMEPULSE
IMU
  • IMU_INT1
  • IMU_INT2
Servos
  • SERVO1_PWM
  • SERVO2_PWM
  • SERVO3_PWM
  • SERVO4_PWM
  • SERVO5_PWM
Optional Power Control
  • SERVO_POWER_ENABLE
  • GNSS_POWER_ENABLE
  • LORA_POWER_ENABLE
Resource Allocation Rules
  1. Never allocate a reserved GPIO to another function without explicitly flagging the conflict.
  2. Prefer shared I2C and SPI buses instead of creating unnecessary additional buses.
  3. Do not consume GPIO for decorative LEDs unless sufficient spare GPIO remains.
  4. Preserve SWD access at all times.
  5. Servo GPIO must support reliable PWM generation.
  6. GPIO allocation and peripheral allocation are separate design decisions.
  7. Do not assume that five servo outputs require five hardware timers.
  8. Do not allocate optional features before mandatory flight-control resources are secured.
  9. Update this resource budget whenever a pin is permanently allocated.
  10. Before finalizing the MCU block, produce a complete nRF52840 pin-allocation table.
  11. Every assigned MCU pin must be checked against the nRF52840 datasheet.
  12. Preserve at least 3 spare GPIO if physically possible.
  13. Do not add duplicate regulators, level shifters, buses, pull-ups, or support circuits unless technically necessary.
  14. Future functional blocks must use the named nets and existing shared buses wherever practical.
  15. If a new requirement conflicts with this resource budget, explicitly flag the conflict before modifying the architecture.
  16. Manufacturer datasheets and reference designs take precedence over assumptions generated by AI tools.
  17. Do not silently change the system architecture to resolve a pin or peripheral conflict.
  18. If an interface requirement is uncertain, preserve the resource until the corresponding functional block has been reviewed.
Functional Block Sequence
The system should be designed and reviewed in this order:
  1. Power Management — BQ25120A / battery / charging / power rails
  2. MCU / BLE — nRF52840 / clocks / RF / SWD
  3. Sensors — LSM6DSO32X + BMP390
  4. GNSS — MAX-M10S
  5. LoRa — RFM95
  6. Servo outputs and servo power distribution
  7. Optional flash and expansion
  8. Final top-level integration
For every functional block:
  • consider the requirements of all future blocks
  • implement only the current block
  • preserve resources required by later blocks
  • use clearly named inter-block nets
  • verify against the manufacturer reference design
  • identify unresolved assumptions
  • flag architectural conflicts before making changes
  • do not silently modify previously reviewed blocks
Final MCU Pin-Allocation Requirement
Before the MCU/BLE block is considered complete, create a full nRF52840 pin-allocation table containing at minimum:
  • physical MCU pin
  • GPIO name
  • assigned function
  • hardware peripheral
  • functional block
  • mandatory or optional status
  • analog capability if relevant
  • special-pin restrictions
  • notes
The pin map must explicitly show:
  • all 5 servo outputs
  • RFM95 SPI and control signals
  • MAX-M10S UART and TIMEPULSE
  • shared I2C
  • IMU INT1 and INT2
  • PMIC interrupt if used
  • BATTERY_ADC
  • SWDIO
  • SWCLK
  • USB pins if used
  • crystal pins if used
  • NFC pins and their status
  • all remaining spare GPIO
The final pin map must demonstrate that the complete system can be implemented without unresolved GPIO conflicts.

  • MCU

  • Mandatory GPIO Allocation

  • Servos

  • Servo Timing Rule

  • LoRa — RFM95

  • Shared SPI

  • Dedicated Control Signals

  • RFM95 DIO Allocation Rule

  • GNSS — MAX-M10S

  • Sensors

  • Shared I2C

  • LSM6DSO32X IMU

  • BMP390 Barometer

  • Power Management — BQ25120A

  • Battery Measurement

  • Power Control / Enables

  • USB

  • USB data + charging

  • Programming / Debug

  • nRF52840 Special-Pin Rules

  • Shared Buses

  • I2C Bus

  • SPI Bus

  • UART

  • Servo Architecture

  • Power Rails

  • USB_5V

  • VBAT_RAW

  • SERVO_VBAT

  • VDD_3V3

  • Battery / Servo Current Rules

  • Optional Flight Data Storage

  • Expansion Reserve

  • Named Inter-Block Nets

  • Power

  • I2C

  • PMIC

  • SPI / LoRa

  • GNSS

  • IMU

  • Servos

  • Optional Power Control

  • Resource Allocation Rules

  • Functional Block Sequence

  • Final MCU Pin-Allocation Requirement

Documents

Assets

No assets added.

Free Flight lightweight timer

Free Flight lightweight timer thumbnail
Compact, lightweight, low-power, high-reliability free-flight model aircraft timer, flight controller, and telemetry system powered by a single 1S LiPo battery.
The system is based on:
  • Nordic nRF52840 QFN48 — main MCU, flight timing, BLE, servo control and system management
  • TI BQ25120A — 1S LiPo charging, power-path management, battery monitoring and regulated electronics supply
  • ST LSM6DSO32X — IMU for launch detection, motion sensing and flight-state detection
  • Bosch BMP390 — barometric altitude and vertical-speed measurement
  • u-blox MAX-M10S — GNSS using UART and TIMEPULSE/PPS
  • HopeRF RFM95W — LoRa telemetry using SPI
  • Up to 5 CHASERVO LV06 servos, powered directly from the raw 1S LiPo rail
  • Optional SPI flash for flight-data logging
The system shall provide deterministic flight-event timing, five servo-control outputs, BLE configuration, GNSS positioning, LoRa telemetry, motion/flight-state detection, barometric altitude measurement and battery supervision.
Primary design priorities are:
Reliability → low weight → small PCB size → deterministic timing → low power consumption → power integrity → sensor accuracy → RF/GNSS performance → manufacturability.
High-current servo power must be kept electrically separate from the sensitive regulated electronics rail while maintaining a common ground. Servo-current transients must not reset or disturb the MCU, sensors, GNSS or radios.
The design shall be developed and reviewed as separate functional blocks:
Power → MCU/BLE → Sensors → GNSS → LoRa → Servos → Optional Storage/Expansion → Final Integration
Always consider the complete system, but implement only the currently requested functional block.
Use SYSTEM_SPEC.md for the complete technical requirements and architecture.
Use RESOURCE_BUDGET.md as the authoritative source for GPIO, bus, peripheral and interface reservations.
Manufacturer datasheets and reference designs take precedence over AI assumptions. Flag uncertainties or conflicts for review rather than guessing or silently changing the architecture.

Properties

Properties describe core aspects of the project.

Pricing & Availability

See prices from popular manufacturers for your project.

Controls