Describe the measurement. Develop the application. Review the results.
A measurement idea is rarely just one piece of code. It can involve real-time signal processing, software to control the hardware and an interface to display the results. Turning those pieces into a usable instrument means making them work together, not simply generating each one in isolation.
Red Pitaya Copilot helps develop that application around a description of what you want to measure. Our vector lock-in amplifier example shows the approach in practice: a natural-language engineering request becomes the starting point for an FPGA-based application, supporting software and a live dashboard.
Begin by describing the result you need. Name your Red Pitaya board, the signal you want to measure, its expected voltage and frequency range, and how you want to view or save the results. A useful starting request might be:
“Help me build a vector lock-in amplifier that measures a periodic signal’s amplitude and phase relative to a reference and displays the results in a live dashboard.”
Then make the requirements specific enough to test. Define the reference source, operating frequency, required response time and acceptable measurement error. Explain whether you need a browser interface, remote access or saved measurements. These details turn an attractive demonstration into a project with a clear purpose.
You do not have to settle every implementation detail in the first request. Start with a small, well-defined measurement and refine it as you learn. Clear requirements make it easier to judge each revision and avoid adding complexity before the basic application works.
A lock-in amplifier measures the component of a signal that is coherent with a reference. In a vector implementation, in-phase and quadrature components provide the information needed to calculate amplitude and phase. Filtering narrows the measurement bandwidth, helping separate a periodic signal from broadband noise.
That makes a lock-in a useful example of an instrument that needs more than a plotting script. The signal-processing path, adjustable parameters, data readout and presentation must agree about what is being measured and how the numbers are scaled.
In our example, the Copilot workflow brought together custom FPGA logic, a register interface, an embedded service, an API and a live dashboard. The project also included documentation, tests and a deployment package. The result illustrates application development across the instrument, rather than stopping at a standalone code snippet.
Each layer has a distinct job. The FPGA handles the real-time processing. Registers expose settings and results to software. The embedded service communicates with the hardware, while the API and dashboard make the instrument accessible to the user.
The important part is consistency between those layers. A register value needs the correct interpretation; a displayed amplitude needs clear units; an adjustable filter needs a defined effect on response time. Keeping those relationships explicit makes the application easier to test, modify and maintain.
Ask for explanations alongside implementation changes. When a parameter is added, request its units, allowed range, default value and expected behaviour. When a result is displayed, check how it is calculated and whether any calibration or scaling is applied.
For FPGA development, Copilot works with existing Red Pitaya projects and runs builds through terminal commands and Tcl scripts. A compatible AMD Vivado installation is required on your development computer. AI assistance does not replace the FPGA toolchain or remove the need to build a design for the correct target board.
Start from a project appropriate for your hardware and keep the project configuration consistent as you make changes. Review the proposed modifications, build the design and inspect the reports before deployment. Pay attention to timing, resource use and any changes to interfaces shared with the software.
Keep a known working version so you can compare revisions and recover when an experiment does not behave as intended. Treat generated changes as engineering changes: understand their purpose, test their effect and record the result.
A successful build is an important milestone, but it is not proof of measurement accuracy. Simulation checks the model and test cases you provide; timing analysis checks implementation constraints. Neither replaces validation of the complete signal path on the board.
Start with a known test signal and safe input levels. For the lock-in example, vary amplitude, frequency and phase deliberately and compare the displayed results with your expectations. Check the effect of filtering and allow the output to settle before interpreting a reading. Include input range and termination in the test setup.
When something is wrong, give Copilot the actual evidence: the relevant code, build message, measured waveform or mismatch between expected and observed behaviour. Refine one part at a time, then repeat the test. A convincing dashboard alone does not establish that the measurement is correct.
Red Pitaya Copilot is still in development, and generated results may require refinement. Review, adjust and retest the software, FPGA design and instrument settings until the application performs as intended.
Use Copilot to develop the application around your measurement goal, while keeping engineering review and verification at every step.
No. Copilot assists with application development and code generation, but a compatible AMD Vivado installation and standard FPGA design toolchain are still required to build designs for your target board.
Start by describing the measurement clearly—specifying your Red Pitaya board, the signal type, expected voltage and frequency ranges, and desired outputs (such as a live browser dashboard or saved data files).
A successful build confirms that your code compiles and meets timing constraints, but it does not guarantee measurement accuracy. You must test the physical signal path on the board using known reference signals, proper input ranges, and correct terminations.