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
#SYSTEM SPECIFICATION
1. Project Purpose
This project is a compact, lightweight, low-power, high-reliability free-flight model aircraft timer, flight controller, and telemetry system.
The controller shall provide:
  • deterministic timed flight events
  • control of up to 5 servos
  • launch and flight-state detection
  • inertial measurement
  • barometric altitude measurement
  • GNSS position, speed, and time
  • Bluetooth Low Energy configuration and diagnostics
  • LoRa telemetry and recovery support
  • battery charging and supervision
  • optional flight-data logging
The complete system shall operate from a single 1S LiPo battery.
The design is intended for installation in a free-flight model aircraft, where reliability, weight, power consumption, PCB size, RF performance, and deterministic operation are critical.
2. Global Design Priorities
The design priorities, in order, are:
  1. Reliability
  2. Low weight
  3. Small PCB size
  4. Deterministic flight timing
  5. Low power consumption
  6. Robust power integrity
  7. Accurate sensor measurements
  8. Reliable GNSS and RF performance
  9. Manufacturability
  10. Debugging and development accessibility
Do not sacrifice reliability merely to save a very small amount of PCB area or weight.
Avoid unnecessary:
  • regulators
  • level shifters
  • connectors
  • LEDs
  • duplicate buses
  • duplicate pull-ups
  • decorative circuitry
  • unnecessary power-conversion stages
  • unnecessary GPIO consumption
Every component shall have a clear functional purpose.
3. System Architecture
The primary components are:

Table

FunctionComponent
Main MCU / BLENordic nRF52840 QFN48
Power managementTI BQ25120A
IMUST LSM6DSO32X
BarometerBosch BMP390
GNSSu-blox MAX-M10S
LoRaHopeRF RFM95W
ServosCHASERVO LV06
Optional storageW25Q32 or similar SPI NOR flash
Battery1S LiPo
The system shall be developed as separate functional blocks and integrated only after individual review.
4. Main Controller and Bluetooth
4.1 MCU
Use:
Nordic nRF52840, preferably QFN48
The MCU shall provide:
  • main flight-control logic
  • deterministic event scheduling
  • servo control
  • sensor acquisition
  • flight-state processing
  • BLE communication
  • GNSS communication
  • LoRa control
  • battery supervision
  • configuration storage
  • safety/emergency logic
  • optional flight-data logging
Wi-Fi is not required.
4.2 Bluetooth
Bluetooth Low Energy shall primarily support:
  • pre-flight configuration
  • timer programming
  • parameter adjustment
  • sensor diagnostics
  • battery checking
  • system diagnostics
  • firmware-development functions
  • possible retrieval of flight information
BLE activity must not compromise flight-critical timing.
4.3 MCU Support Circuitry
The MCU block shall include all required:
  • supply decoupling
  • regulator/DC-DC support components
  • HF clock circuitry
  • LF clock circuitry if used
  • SWD programming/debug interface
  • BLE RF matching
  • BLE antenna or antenna interface
  • appropriate test points
Follow Nordic reference designs and datasheet requirements.
Do not permanently allocate MCU GPIO before considering the requirements in RESOURCE_BUDGET.md.
5. Flight Timing Architecture
The system shall support multiple independent timed flight events.
Do not assume that each event requires an independent hardware timer.
Preferred architecture:
hardware timer/timebase + deterministic software event scheduler + hardware PWM/peripherals where appropriate
Flight-critical scheduling must remain deterministic while:
  • BLE is active
  • GNSS messages are received
  • LoRa communication occurs
  • sensors are sampled
  • data is logged
  • servo movements occur
Flight-critical tasks shall have priority over telemetry, logging, and user-interface functions.
The watchdog and failure-recovery strategy shall be considered during MCU design.
6. Servo System
6.1 Servo Configuration
Support:
maximum 5 servos
Servo 1 is mandatory.
Servos 2–5 are optional.
Preferred servo:
CHASERVO LV06
6.2 Servo Power
The servos shall operate directly from the raw 1S LiPo battery rail.
Do not add a servo boost converter.
Do not power the servos from the BQ25120A regulated buck output.
Servo power shall therefore be conceptually:
1S LiPo -> SERVO_VBAT -> servos
6.3 Servo Control
Provide five independent control signals:
  • SERVO1_PWM
  • SERVO2_PWM
  • SERVO3_PWM
  • SERVO4_PWM
  • SERVO5_PWM
Five servo outputs do not imply five independent hardware timers or PWM peripherals.
PWM may be generated only when servo movement or holding is required.
Continuous holding PWM is optional and mechanism-dependent.
6.4 Servo Transients
The servos are expected to be lightly mechanically loaded, but the design must tolerate short startup, movement, and braking current peaks.
Do not size:
  • battery traces
  • connectors
  • ground paths
  • capacitors
based solely on average servo current.
Where flight operation permits, firmware may slightly stagger simultaneous servo movements to reduce peak battery current.
The servo rail shall include appropriate local bulk decoupling.
Servo-current paths shall not disturb:
  • MCU
  • IMU
  • barometer
  • GNSS
  • BLE
  • LoRa
Optional global servo-power switching may be evaluated, but should only be implemented if it produces a meaningful benefit without introducing unnecessary complexity or failure modes.
7. Power Management
7.1 Battery
Primary power source:
1S LiPo
Conceptual rails:
  • USB_5V
  • VBAT_RAW
  • SERVO_VBAT
  • VDD_3V3
  • GND
7.2 PMIC
Use:
TI BQ25120A
The BQ25120A shall provide, where appropriate:
  • 1S LiPo charging
  • USB 5 V charging input
  • power-path management
  • integrated buck regulation
  • battery monitoring
  • battery-temperature monitoring
  • low-power modes
  • I2C configuration/status
7.3 Electronics Rail
Target regulated electronics voltage:
approximately 3.3 V
The exact value must be verified against:
  • BQ25120A operating limitations across the intended 1S LiPo discharge range
  • nRF52840 requirements
  • LSM6DSO32X requirements
  • BMP390 requirements
  • MAX-M10S requirements
  • RFM95 requirements
  • optional flash requirements
Do not assume 3.3 V is valid under every battery condition without verification.
7.4 Servo Rail
SERVO_VBAT shall normally be directly derived from VBAT_RAW.
Servo current must not pass through the BQ25120A buck regulator.
7.5 Battery Monitoring
Do not use MAX17048.
Use:
  • BQ25120A monitoring capabilities
  • independent nRF52840 SAADC battery measurement where practical
An appropriate resistor divider may connect VBAT_RAW to an SAADC-capable MCU input.
Minimize continuous divider current.
A switched divider may be considered only if its benefit justifies the added complexity.
Battery information may be used for:
  • pre-flight battery check
  • BLE display
  • telemetry
  • low-battery warning
  • launch inhibition
  • flight logging
Use conservative low-battery thresholds.
7.6 Battery Temperature
Implement battery-temperature monitoring if appropriate according to the BQ25120A reference design and selected battery configuration.
7.7 Power Integrity
Sensitive electronics and high-current servo power distribution shall be organized to minimize interaction.
The design must tolerate:
  • servo current transients
  • RFM95 TX transients
  • GNSS startup current
  • simultaneous digital activity
without MCU reset or unstable sensor/RF operation.
8. IMU
Use:
ST LSM6DSO32X
Primary interface:
I2C
Connect:
  • I2C_SDA
  • I2C_SCL
  • IMU_INT1
  • IMU_INT2
The IMU shall support functions including:
  • launch detection
  • acceleration measurement
  • angular-rate measurement
  • orientation/attitude estimation
  • flight-state detection
  • emergency/safety logic
  • flight analysis
Use embedded IMU capabilities such as FIFO, wake-up detection, and interrupts where useful.
Do not use a dedicated SPI interface unless testing demonstrates a genuine requirement.
Placement should minimize:
  • electrical noise
  • PCB mechanical stress
  • thermal influence
  • unwanted vibration coupling
9. Barometric Sensor
Use:
Bosch BMP390
Primary interface:
shared I2C
The sensor shall support:
  • relative altitude
  • climb detection
  • descent detection
  • vertical-speed estimation
  • flight-state determination
  • flight-data logging
No dedicated interrupt GPIO is initially required unless later justified.
9.1 Mechanical Requirements
Barometer performance depends heavily on mechanical installation.
The pressure port shall not be directly exposed to:
  • high-speed airflow
  • aerodynamic suction
  • contamination
  • servo-generated pressure disturbances
  • obstruction
Consider appropriate:
  • venting
  • protective foam
  • static-pressure chamber
Keep the barometer reasonably separated from significant heat sources.
10. GNSS
Use:
u-blox MAX-M10S
Primary interface:
UART
Required signals:
  • GNSS_TX -> MCU RX
  • GNSS_RX -> MCU TX
  • GNSS_TIMEPULSE
GNSS shall provide:
  • aircraft position
  • speed
  • ground track
  • GNSS altitude
  • accurate time
  • recovery information
  • telemetry information
  • flight logging data
TIMEPULSE/PPS shall be retained because it may later support:
  • accurate synchronization
  • event correlation
  • telemetry timestamps
  • sensor-log synchronization
10.1 GNSS Power
Provide clean, properly decoupled power.
Consider GNSS startup/transient current requirements.
10.2 GNSS RF
Follow u-blox antenna and RF-layout recommendations.
GNSS circuitry and antenna routing should be separated from:
  • servo-current paths
  • switching nodes
  • inductors
  • LoRa RF circuitry
  • BLE RF circuitry
  • noisy high-speed digital signals
For early prototypes, an external GNSS antenna connection may be preferred if it reduces RF-layout risk.
11. LoRa Telemetry
Use:
HopeRF RFM95W
The module approach is intentionally preferred for the first PCB revision to reduce RF-design complexity.
Primary interface:
SPI
Shared:
  • SPI_SCK
  • SPI_MOSI
  • SPI_MISO
Dedicated:
  • LORA_NSS
  • LORA_RESET
  • LORA_DIO0
  • LORA_DIO1
DIO0 is mandatory.
DIO1 is strongly preferred.
Do not allocate additional DIO pins unless required by the selected firmware/library.
LoRa may support:
  • telemetry
  • aircraft tracking
  • recovery
  • flight status
  • diagnostic information
Provide appropriate local supply decoupling.
The supply must tolerate transmitter-current transients.
Follow RFM95/HopeRF recommendations for RF routing and antenna connection.
12. Optional Flight-Data Storage
Optional:
W25Q32 or similar SPI NOR flash
Potential logged information:
  • timestamps
  • flight-state transitions
  • IMU data
  • barometric altitude
  • vertical speed
  • GNSS data
  • battery voltage
  • servo commands
  • LoRa events
  • emergency events
  • debugging information
Use the shared SPI bus where practical.
External flash requires its own chip-select GPIO.
Do not add external flash if MCU internal storage is sufficient or if the cost in size, weight, power, or GPIO is not justified.
13. Communication Buses
13.1 I2C
Expected devices:
  • BQ25120A
  • LSM6DSO32X
  • BMP390
Use shared:
  • I2C_SDA
  • I2C_SCL
Verify all device addresses.
Use one appropriate set of pull-ups unless otherwise electrically required.
Avoid redundant pull-ups.
13.2 SPI
Expected:
  • RFM95
  • optional W25Q32
Share:
  • SPI_SCK
  • SPI_MOSI
  • SPI_MISO
Provide independent chip selects.
Do not create additional SPI buses without justification.
13.3 UART
Primary UART:
MAX-M10S
Reserve GNSS TX/RX exclusively unless later architecture proves sharing is safe and necessary.
14. Programming and Debug
Provide:
  • SWDIO
  • SWCLK
  • GND
  • appropriate voltage/reference connection
SWDIO and SWCLK shall remain available for:
  • programming
  • debugging
  • firmware recovery
Compact pads suitable for pogo pins are preferred over a large connector.
15. USB Strategy
USB shall provide at minimum:
5 V charging input
USB data is optional.
Two possible configurations:
Option A — Charging Only
USB provides 5 V to the charging/power-management circuitry.
nRF52840 USB data functionality is not used.
Option B — Charging + Data
USB additionally connects to the nRF52840 for data/debug functionality.
If selected, reserve the required USB pins and support circuitry.
This decision must be finalized before completing the MCU pin allocation.
Do not allocate USB-capable/special-purpose pins without considering this requirement.
16. Expansion
Target:
at least 3 genuinely usable spare GPIO
after mandatory resources are allocated.
Where practical, provide compact access to:
  • I2C
  • UART
  • spare GPIO
  • VDD_3V3
  • GND
Prefer test pads over large connectors where appropriate.
17. RF System
The final system potentially contains three independent RF systems:
  1. BLE — 2.4 GHz
  2. GNSS — L1-band reception
  3. LoRa — sub-GHz
PCB placement must consider interaction between them.
General principles:
  • separate antennas where practical
  • keep RF feed lines short
  • follow controlled-impedance requirements
  • avoid switching nodes near antennas
  • avoid high-current servo routing near RF sections
  • keep noisy digital lines away from sensitive GNSS RF paths
  • follow each manufacturer's RF reference design
Do not rely on generic RF-layout assumptions where manufacturer recommendations exist.
18. PCB Layout Considerations
The PCB shall be optimized for aircraft use.
Pay particular attention to:
  • battery-current paths
  • servo-current paths
  • ground return paths
  • regulator switching nodes
  • GNSS sensitivity
  • BLE antenna clearance
  • LoRa antenna clearance
  • IMU placement
  • barometer pressure exposure
  • decoupling capacitor placement
  • test/programming accessibility
High-current and noisy circuits should be physically organized separately from sensitive sensing/RF sections while maintaining a correct common-ground strategy.
Do not split ground planes arbitrarily. Control current paths through layout rather than creating poorly justified ground-plane fragmentation.
19. Functional Block Development Sequence
Block 1 — Power Management
  • BQ25120A
  • USB input
  • LiPo connection
  • charging
  • battery temperature
  • regulated electronics rail
  • battery measurement
  • raw servo rail
Block 2 — MCU / BLE
  • nRF52840
  • clocks
  • decoupling
  • regulator support
  • SWD
  • BLE RF
  • antenna
  • complete preliminary pin allocation
Block 3 — Sensors
  • LSM6DSO32X
  • BMP390
  • I2C
  • sensor interrupts
Block 4 — GNSS
  • MAX-M10S
  • UART
  • TIMEPULSE
  • GNSS power
  • antenna/interface
Block 5 — LoRa
  • RFM95
  • SPI
  • control/interrupt signals
  • power
  • antenna/interface
Block 6 — Servo System
  • five control outputs
  • servo connectors/pads
  • raw battery distribution
  • bulk capacitance
  • optional power control if justified
Block 7 — Optional Storage / Expansion
  • W25Q32 if justified
  • expansion signals
  • test points
Block 8 — Final Integration
  • complete pin-map verification
  • power-budget review
  • bus review
  • RF review
  • timing-resource review
  • schematic ERC
  • final Red-Team review
20. Functional Block Design Rule
For every block:
Consider the complete system, but implement only the current block.
Before making schematic changes:
  1. Review the relevant manufacturer datasheet.
  2. Review manufacturer reference designs/application notes.
  3. Determine required support components.
  4. Identify interfaces to existing and future blocks.
  5. Check RESOURCE_BUDGET.md.
  6. Identify unresolved assumptions.
  7. Identify potential conflicts.
  8. Present important architectural consequences for review.
While implementing:
  • use consistent named nets
  • preserve resources required by future blocks
  • avoid unnecessary GPIO consumption
  • avoid duplicate circuitry
  • avoid silently modifying previously reviewed blocks
After implementing:
  1. Compare against manufacturer reference circuits.
  2. Verify component values.
  3. Verify pin numbers and package variants.
  4. Verify voltage/current limits.
  5. Verify interfaces.
  6. Update resource allocation where appropriate.
  7. Flag remaining uncertainties.
21. Resource Management
RESOURCE_BUDGET.md is the authoritative project resource-allocation document.
It defines:
  • mandatory GPIO requirements
  • shared buses
  • dedicated control signals
  • SWD reservation
  • optional resource reservations
  • expansion reserve
  • pin-allocation rules
Before permanently assigning any MCU pin, check the resource budget.
Do not resolve resource conflicts silently.
22. Final MCU Pin Allocation
Before the MCU block is considered complete, create a complete nRF52840 pin-allocation table.
The table shall include:
  • physical package pin
  • nRF GPIO designation
  • assigned signal
  • peripheral
  • functional block
  • mandatory/optional status
  • analog capability where relevant
  • special restrictions
  • notes
The allocation must explicitly account for:
  • SERVO1_PWM
  • SERVO2_PWM
  • SERVO3_PWM
  • SERVO4_PWM
  • SERVO5_PWM
  • SPI_SCK
  • SPI_MOSI
  • SPI_MISO
  • LORA_NSS
  • LORA_RESET
  • LORA_DIO0
  • LORA_DIO1
  • GNSS_TX
  • GNSS_RX
  • GNSS_TIMEPULSE
  • I2C_SDA
  • I2C_SCL
  • IMU_INT1
  • IMU_INT2
  • PMIC_INT if used
  • BATTERY_ADC
  • SWDIO
  • SWCLK
  • USB pins if used
  • crystal pins
  • NFC pins
  • RF-related restrictions
  • at least 3 spare GPIO where practical
Do not assume all nRF52840 GPIO are equivalent.
23. AI Design and Verification Rules
AI-generated circuitry shall be treated as a design proposal, not automatically as a verified design.
For every block verify:
  • exact component
  • exact package
  • exact pinout
  • supply voltage
  • absolute maximum ratings
  • recommended operating conditions
  • current requirements
  • required decoupling
  • pull-ups/pull-downs
  • inductor values
  • capacitor values
  • resistor values
  • power sequencing
  • logic-level compatibility
  • I2C addresses
  • RF circuitry
  • clock circuitry
  • antenna requirements
  • PCB-layout requirements
Do not invent component values when the manufacturer provides recommended/reference values.
Do not silently substitute components.
Do not silently change package variants.
Do not silently alter the architecture to simplify schematic generation.
If information is uncertain, flag it for human review instead of guessing.
24. Design Authority
When requirements conflict, use the following priority:
  1. Manufacturer datasheet
  2. Manufacturer reference design/application notes
  3. Verified electrical and safety requirements
  4. This SYSTEM_SPEC.md
  5. RESOURCE_BUDGET.md
  6. Established and reviewed project decisions
  7. AI-generated recommendations
If an apparent manufacturer recommendation conflicts with another system requirement, flag the conflict rather than silently changing the design.
25. Red-Team Requirements
At the end of each functional block, actively search for failure modes.
At minimum consider:
  • brownout/reset
  • incorrect power sequencing
  • battery depletion
  • servo current transients
  • RF interference
  • GNSS interference
  • I2C lockup
  • SPI contention
  • GPIO conflicts
  • wrong logic levels
  • startup pin states
  • unpowered-peripheral backfeeding
  • sensor failure
  • MCU watchdog/reset behavior
  • open/short connector conditions
  • assembly errors
  • missing pull resistors
  • wrong component package
  • component availability
  • thermal effects
  • mechanical vibration
  • barometer airflow errors
Do not merely confirm that the proposed design appears correct.
Actively attempt to identify how it could fail.
26. Final Design Objective
The final PCB shall integrate:
nRF52840 + BQ25120A + LSM6DSO32X + BMP390 + MAX-M10S + RFM95 + up to 5 CHASERVO LV06 servos
with optional external SPI flash.
The complete system shall operate from:
one 1S LiPo battery
The raw battery shall directly supply the LV06 servo rail.
The BQ25120A shall provide charging, power management, battery supervision, and the regulated electronics supply.
The nRF52840 shall provide flight timing, BLE, servo control, sensor processing, GNSS processing, LoRa control, battery supervision, and safety logic.
The final design should be sufficiently small and lightweight for competitive free-flight use while prioritizing reliability and deterministic flight operation over unnecessary features.
Each functional block shall be designed, verified, Red-Teamed, and reviewed before integration into the complete system.

  • 1. Project Purpose

  • 2. Global Design Priorities

  • 3. System Architecture

  • 4. Main Controller and Bluetooth

  • 4.1 MCU

  • 4.2 Bluetooth

  • 4.3 MCU Support Circuitry

  • 5. Flight Timing Architecture

  • 6. Servo System

  • 6.1 Servo Configuration

  • 6.2 Servo Power

  • 6.3 Servo Control

  • 6.4 Servo Transients

  • 7. Power Management

  • 7.1 Battery

  • 7.2 PMIC

  • 7.3 Electronics Rail

  • 7.4 Servo Rail

  • 7.5 Battery Monitoring

  • 7.6 Battery Temperature

  • 7.7 Power Integrity

  • 8. IMU

  • 9. Barometric Sensor

  • 9.1 Mechanical Requirements

  • 10. GNSS

  • 10.1 GNSS Power

  • 10.2 GNSS RF

  • 11. LoRa Telemetry

  • 12. Optional Flight-Data Storage

  • 13. Communication Buses

  • 13.1 I2C

  • 13.2 SPI

  • 13.3 UART

  • 14. Programming and Debug

  • 15. USB Strategy

  • Option A — Charging Only

  • Option B — Charging + Data

  • 16. Expansion

  • 17. RF System

  • 18. PCB Layout Considerations

  • 19. Functional Block Development Sequence

  • Block 1 — Power Management

  • Block 2 — MCU / BLE

  • Block 3 — Sensors

  • Block 4 — GNSS

  • Block 5 — LoRa

  • Block 6 — Servo System

  • Block 7 — Optional Storage / Expansion

  • Block 8 — Final Integration

  • 20. Functional Block Design Rule

  • 21. Resource Management

  • 22. Final MCU Pin Allocation

  • 23. AI Design and Verification Rules

  • 24. Design Authority

  • 25. Red-Team Requirements

  • 26. Final Design Objective

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