Every hardware engineer has a version of this story: the board logic was straightforward, but the support work around symbols, footprints, and checks took longer than the actual design.
For this PIR sensor module, we ran CopperPilot end to end in KiCad with the same rigor we use on larger boards: datasheet-first pin validation, net-by-net checking, and a clean handoff to fabrication files.
The point is not that a PIR sensor is complex. The point is that routine tasks should stop consuming expert engineering time, so teams can focus on architecture, constraints, and product decisions that actually move performance and schedule.
CopperPilot now understands skills more deliberately, with a server-owned Skill Manifest that helps route workflows naturally. This release also introduces explicit chat modes, slash-selectable workflows, local skill discovery, and more resilient streaming.
What’s New
Added a server-owned Skill Manifest that describes available workflows, required inputs, outputs, categories, and slash tokens.
Added support for local project skills in .copperpilot/skills/<skill-id>/SKILL.md, including validation and diagnostics for incomplete entries.
Introduced explicit plan, agent, and ask chat modes with slash-selectable workflow skills and mode-aware UI.
Bug Fixes and Improvements
Improved chat streaming with typed stream parts, richer reasoning and status rendering, resume and progress handling, and ordered tool requests.
Added safer recovery paths when streaming errors occur.
Refreshes effective manifests before chat and suggestions so routing uses the latest available skill context.
For any questions or feedback, you can reach out to us at support@copperpilot.ai
CopperPilot now includes a compact KiCad overlay chat that stays in sync with your main session, so you can ask questions without leaving your schematic. The release also refreshes the website, adds usage analytics, and improves suggestion and billing flows.
What’s New
Added a floating CopperPilot pill for KiCad that expands into mini chat when KiCad is in the foreground.
Added support for reading binary project files such as images and PDFs.
Launched a redesigned website with a fresh landing page, pricing, and usage analytics dashboard.
Bug Fixes and Improvements
Made chat sends feel snappier with faster responses and more reliable streaming.
Improved suggestion chip loading speed.
Polished billing, logout, and team setup flows.
For any questions or feedback, you can reach out to us at support@copperpilot.ai
CopperPilot gets a full desktop redesign with multiple chat tabs, a built-in code editor, richer rendering, and automatic CAD tool detection. On the web, Claude Sonnet 4.6 is now the default model and the public docs, blog, and changelog are live.
What’s New
Redesigned the desktop app with multiple chat tabs and a built-in code editor with syntax highlighting.
Added richer response rendering, including LaTeX math and interactive Mermaid diagrams.
Added automatic detection for KiCad and Altium projects.
Launched the public docs, blog, and changelog, and made Claude Sonnet 4.6 the default model on web.
Bug Fixes and Improvements
Improved chat reconnect behavior and streaming reliability.
Added inline tool activity so you can see what the AI is doing while it works.
Enabled team admins to manage billing from the web app.
For any questions or feedback, you can reach out to us at support@copperpilot.ai
Git integration lets CopperPilot reason about firmware alongside your hardware artifacts. That matters because bring-up bugs are often cross-domain: a pin mapping in code does not match the schematic, or a driver assumes a regulator comes up in the wrong order.
Connect the repository you use for firmware—PlatformIO, bare-metal, or a monorepo with hardware docs. CopperPilot uses the integration to answer questions about recent commits, module boundaries, and likely regression points when a board revision lands.
Start with a narrow scope: one repo, one board, one branch. Ask the copilot to summarize initialization order, peripheral mappings, and test entry points. That map becomes the backbone for later debugging sessions.
Use the video below as a supporting walkthrough for connecting GitHub and navigating the first successful sync.
Once connected, make Git part of your review ritual. Before approving a board spin, ask what firmware assumptions still depend on the old pinout. Before merging a driver refactor, ask which schematic nets are implicitly coupled to the changed code.
The integration is most valuable when the team agrees on naming and checkpoint discipline. Good commit messages and tagged releases give the copilot anchors that survive personnel changes.
If you hit permission issues, verify the repo scope and try a read-only integration first. You can broaden access after the workflow proves useful on a single project.
Previously, we developed firmware for this camera using an ESP32-S3 Xiao in the Arduino
IDE. In this demo, we migrate that same project to PlatformIO with CopperPilot, moving
from the original setup to a cleaner build workflow.
Migration Planning
Once CopperPilot is pointed at the project, we explain that the camera firmware was
originally built on the ESP32-S3 Xiao using Arduino IDE and is now being migrated to
PlatformIO. CopperPilot creates a clear plan and asks for access to connect with
PlatformIO. After a quick “Allow,” it inspects the current codebase, identifies
required versions and libraries, and returns with a structured migration strategy.
Execution Strategy
The plan details how the project will be restructured, which files and modules are needed,
and where file renaming is required. CopperPilot also provides a practical checklist so the
build phase is predictable and complete. Once approved, CopperPilot executes the plan step
by step.
Build and Upload Validation
After migration, CopperPilot reports successful completion and calls out faster incremental
builds as a key outcome. We then connect the device to the laptop and ask CopperPilot to
upload the firmware. It performs a quick network sanity check to confirm we are on the same
Wi-Fi and then shares URLs to validate that the camera stream is running correctly on the
PlatformIO build.
Generated Artifacts
During migration, CopperPilot creates and organizes the essential project files, including main.cpp, httpserver.h, and camera pin definitions, so the
PlatformIO project is ready for iteration and deployment.
Key Takeaways
CopperPilot can migrate ESP32-S3 camera firmware from Arduino IDE to PlatformIO.
It creates a concrete migration plan with module/file changes and build checklist items.
It validates upload readiness and provides URLs to confirm the camera feed is operational.
It delivers a cleaner structure and faster incremental builds for ongoing development.
This demo shows writing firmware for a Smart Camera project with CopperPilot. CopperPilot
can handle firmware for many embedded targets—AVR-GCC for the Teensy, ESP-IDF for the ESP,
STM32CubeIDE for the STM—but here we use the Arduino IDE. The camera is based on the Xiao
ESP32-S3, and we ask CopperPilot to craft firmware for a basic camera stream.
Setup
Direct CopperPilot to the main INO code and point it to your config.h file.
Instruct CopperPilot to write modular code and develop a makefile. Use the Arduino CLI to
compile and upload the code. With everything set, you can let CopperPilot run.
What CopperPilot Builds
CopperPilot analyzes the existing bare-bones codebase and creates files for Camera Pins,
Camera Init, WiFi Manager, and the HTTP Server. This setup exposes your API endpoints and
adds logging so you can see the device’s IP address. CopperPilot then seeks approval to
compile; with a quick “Allow,” it proceeds. It compiles the firmware and refines it
through iterations until it succeeds, then reports back that the camera is active and
provides the URLs.
Clicking a URL gives you a live camera stream. There’s also a capture
endpoint that lets you grab a single frame.
Documentation
Ask CopperPilot to document your discoveries in a README. CopperPilot creates a README
that details all the resolutions and even provides a makefile, so your project is
well-documented.
Benchmarking
To document the device’s frame rate across all resolutions, assign CopperPilot the
task of benchmarking using the laptop to cURL the web server. CopperPilot first tweaks the
firmware so clients can modify the resolution—from QVGA to UXGA, all options become
available as API endpoints. It then develops a benchmark script. After you give the green
light, it runs the script and outputs fps-results.json. Ask CopperPilot to
document its insights from that file into an fps markdown; it generates a report with a
table of all resolutions and their frame rates for the device.
Key Takeaways
CopperPilot can write modular firmware and generate a makefile for compile and upload with Arduino CLI.
It builds camera, WiFi, and HTTP server modules and exposes API endpoints with logging.
It can generate README documentation and, with your approval, run benchmarks and produce fps reports.
CopperPilot can run a full engineering loop inside LTspice, not just answer circuit
questions. In this workflow, it designs a Sallen-Key low-pass filter, runs simulation,
iterates values to meet updated specs, and validates stability with technical evidence.
Overview
Starting from a concrete task, CopperPilot generates the LTspice netlist, runs batch AC
analysis, parses the raw results, and reports Bode magnitude and phase behavior. The first
pass lands near 482 Hz, consistent with the initial RC choices.
Engineering Loop
When requirements change to target 500 Hz with minimal edits, CopperPilot keeps capacitor
values fixed at 10 nF, recalculates resistor values to 31.83 kOhm, updates the netlist, and
reruns simulation. The rerun confirms the natural frequency is approximately 500 Hz, closing
the loop with measured results instead of static recommendations.
Stability Analysis
CopperPilot extends beyond tuning by generating pole-zero analysis and interpreting phase
margin and stability in context. It explains the pole location in the left half-plane and
provides stability reasoning tied to the Sallen-Key topology and op-amp behavior.
Key Takeaways
Requirement to simulation loop is automated: netlist generation, batch run, parsing, and reporting.
Specification updates are implemented directly in the netlist and revalidated through rerun data.
Stability interpretation includes pole-zero evidence and phase-margin reasoning, not just pass/fail output.
Learn how to use CopperPilot to upgrade automotive-grade hardware to meet aviation certification
standards. This tutorial demonstrates how to evaluate components against DO-160 standards and find
compliant alternatives using CopperPilot’s research and comparison capabilities.
Overview
Aviation certification requires hardware to meet stringent standards defined by tests such as
DO-160 issued by RTCA. This tutorial walks through the process of converting automotive-grade
components to aviation-grade by evaluating them against certification requirements and finding
compliant alternatives.
Project Context: TSAL (Tractive System Active Light)
The Tractive System Active Light (TSAL) is a safety device commonly used in Formula Competition
electric vehicles. It monitors high voltage systems and provides visual feedback:
Receives battery tap set input through a voltage divider circuit
Uses a comparator to monitor voltage levels
Activates an optocoupler when voltage exceeds 60 volts
Triggers a flashing red LED to indicate high voltage status
Provides clear visual indication when high voltage is engaged or disengaged
Understanding the Circuit
The TSAL circuit consists of several key components working together:
Voltage Divider: Scales down the input voltage for measurement
Comparator: Detects when voltage exceeds the 60V threshold
Optocoupler (U3): Provides electrical isolation between high and low voltage sides
LED Indicator: Visual feedback system that flashes when activated
Step-by-Step Compliance Upgrade Process
Step 1: Request Initial Compliance Review
Start by asking CopperPilot to review your component against aviation standards. Reference
the specific component (e.g., @U3 for the optocoupler) and provide context about
the design’s purpose and current application.
Example prompt: “This is a TSAL from a Formula Competition EV. Please review @U3 (optocoupler)
for DO-160 compliance and provide a table outlining the requirements.”
Step 2: Analyze Compliance Report
CopperPilot will search the internet, read relevant datasheets and standards documentation,
and return with a comprehensive compliance table showing:
Standard Requirements: What DO-160 requires for each parameter
Current Component Specs: How your existing component performs
Compliance Status: Whether requirements are met or not
Gap Analysis: Areas where the component falls short
Step 3: Identify Non-Compliant Areas
Common areas where automotive-grade components may not meet aviation standards include:
Leakage Current: Maximum allowable current leakage in isolation
Current Transfer Ratio (CTR): Efficiency of signal transfer through the optocoupler
MTBF (Mean Time Between Failures): Reliability measure critical for aviation safety
Temperature Range: Operational temperature extremes
Voltage Ratings: Maximum voltage handling capabilities
Step 4: Request Alternative Component Survey
Once non-compliance is identified, ask CopperPilot to find suitable alternatives. Be specific
about your requirements:
DO-160 compliance requirements
Form factor compatibility (e.g., DIP6 package for drop-in replacement)
Electrical specifications (voltage ranges, current ranges)
Operating conditions (temperature ranges)
Step 5: Review Comparative Analysis
CopperPilot conducts an extensive survey and returns with detailed comparison tables:
Table 1: Component Specifications
Comprehensive technical comparison including:
Temperature operating ranges
Voltage ranges (input and output)
Current ranges and CTR specifications
Footprint and package type (ensuring drop-in compatibility)
Isolation voltage ratings
Response time characteristics
Table 2: Recommendations
CopperPilot’s ranked recommendations showing:
Best candidate components for aviation compliance
Compliance status for each DO-160 requirement
Pros and cons of each alternative
Availability and sourcing information
Cost considerations
Step 6: Make Informed Decision
Using CopperPilot’s analysis, you can confidently select a replacement component that:
Alternative Sourcing: Finds compliant replacements with compatible footprints
Time Savings: Reduces weeks of manual research to minutes
Risk Reduction: Ensures no critical compliance factors are overlooked
Documentation: Provides detailed tables and citations for certification records
Applications Beyond Aviation
This same process can be applied to other certification standards:
Automotive: AEC-Q100/Q200 standards
Medical: IEC 60601 compliance
Industrial: IEC 61010 safety requirements
Military: MIL-STD specifications
Space: NASA standards and requirements
Best Practices
Start compliance review early in the design process
Be specific about certification standards and requirements
Consider form factor compatibility for easier retrofits
Review all CopperPilot citations to verify compliance claims
Evaluate multiple component alternatives before making final selection
Document the compliance analysis process for certification records
Consider supply chain stability for aviation-grade components
CopperPilot’s ability to understand certification requirements, analyze component specifications
against standards, and find compliant alternatives makes it an invaluable tool for upgrading
designs to meet stringent aviation and other industry-specific certification requirements.
Learn how to leverage CopperPilot to hunt for component errata, datasheet warnings, and
design gotchas that could derail your project in the lab. This tutorial demonstrates how
to conduct a deep dive on critical components before layout, catching issues that are often
buried deep in datasheets and application notes.
Overview
Design bugs and component errata can be expensive—both in time and money. Critical details
are often hidden on page 17 of a 24-page datasheet, in obscure application notes, or in
errata documents you didn’t know existed. By the time you discover these issues in the lab,
you may have already committed to a layout or even manufactured boards.
CopperPilot helps you catch these landmines before layout by automatically searching
datasheets, errata documents, and application notes, then presenting you with a prioritized
list of potential issues with severity rankings and recommended mitigations.
Use Case: Jetson Nano Baseboard Design
In this tutorial, we’re designing a Jetson Nano baseboard and reviewing U6—the main 5-volt
power rail. This is a synchronous buck converter that takes 9-36V input and provides 5V
output at 8 amps. Before committing to layout, we need to identify any critical issues that
could cause problems during testing or certification.
Step-by-Step Process
Step 1: Reference the Component
Start by referencing the specific component you want to analyze. In this case, we use @U6 to reference the buck converter.
Step 2: Request Deep Dive Analysis
Ask CopperPilot to conduct a comprehensive analysis of the component. Be specific about
what you’re looking for and provide context about your design:
Example prompt: “Run a deep dive on @U6—find me the errata, the app note warnings, anything
that’ll bite us in the lab. What are the risks for this Jetson board specifically?”
Step 3: CopperPilot Conducts Research
CopperPilot automatically:
Searches the web for official errata documents
Analyzes the complete datasheet (not just the first few pages)
Reviews application notes and design guides
Identifies potential issues specific to your application
Ranks findings by severity
Suggests mitigations for each issue
Step 4: Review the Findings Table
CopperPilot presents a comprehensive table with severity rankings and mitigations. The table
includes both formal errata (if any exist) and critical design considerations that could
impact your specific application.
Example Issues Discovered
1. Separate VCIN Supply Requirement (Critical)
The Issue: At 9-volt input (the low end of the spec), a separate VCIN
supply is necessary, otherwise the chip won’t start. This critical detail is buried on page
3 of a 24-page datasheet.
Impact: Without this supply, your board simply won’t power up at lower
input voltages. This could completely block testing and require a board respin.
Mitigation: Ensure VCIN is properly supplied when operating near the
minimum input voltage range.
2. Subharmonic Oscillation with Ceramic Capacitors (High)
The Issue: When using ceramic output capacitors, the converter can
experience subharmonic oscillation under certain conditions, particularly at full load.
Impact: This is a classic issue that surfaces during lab testing at full
load, often derailing project schedules. Oscillation can cause voltage ripple, noise, and
potential system instability.
Mitigation: Follow application note guidelines for capacitor selection and
compensation network design when using ceramic capacitors.
3. Soft-Start Capacitor Warning (High)
The Issue: The schematic shows a soft-start capacitor configuration.
Without proper soft-start, you’ll experience inrush current spikes that trigger overcurrent
protection every time the system powers up.
Impact: The board may fail to power up reliably, causing intermittent
startup failures that are difficult to debug.
Mitigation: Ensure the soft-start capacitor value is correctly sized per
datasheet recommendations.
4. Switching Frequency Variation at Light Load (Medium)
The Issue: At very light loads (under 100 mA), the switching frequency can
drop below 100 kHz. If Ultrasonic mode is disabled, it can approach the audible range of
20 kHz.
Impact: This can cause increased EMI and potential issues during FCC
certification. It may also create audible noise in quiet environments.
Mitigation: Enable Ultrasonic mode or ensure minimum load conditions meet
the specified range. Plan for EMI testing with light-load conditions.
What Makes This Powerful
Deep Datasheet Analysis: CopperPilot doesn’t just skim the highlights—it
reads through entire datasheets to find issues on page 17 that you might have missed
Context-Aware: Findings are specific to your application (Jetson board,
voltage ranges, load conditions)
Severity Ranking: Issues are prioritized so you know what to fix first
Actionable Mitigations: Each issue comes with recommended fixes, not just
problem identification
Time Savings: A comprehensive design review in 2 minutes instead of hours
of manual datasheet reading
Pre-Layout Catch: Find issues before committing to layout, preventing
costly board respins
Types of Issues CopperPilot Can Catch
Formal Errata: Official bug lists and silicon issues
Application Note Warnings: Critical design considerations from app notes
Datasheet Gotchas: Obscure requirements buried in documentation
Operating Condition Edge Cases: Issues at minimum/maximum specs
Component Interaction Issues: Problems that arise with specific passive
component choices
Startup/Shutdown Behavior: Power sequencing and inrush current issues
High-Speed Interfaces: Signal integrity requirements, termination gotchas
CopperPilot transforms design review from a time-consuming manual process into an automated,
comprehensive analysis that catches critical issues before they become expensive problems.
It’s like having an experienced hardware engineer review every component’s documentation and
flag potential issues—in minutes, not hours.
