FPGA Data Acquisition and Control

The primary objective of this project is to explore the implement of modular and extendable data acquisitions and control for laser interferometer systems by using low end, off the shelf FPGA boards.

=Problem Definition= As lasers have gotten smaller and cheaper, they are ending up in scientific laboratories and fields that are not specialized in laser optics. In order for sensitive, scientific instruments to give valid results, the lasers need to be controlled to remove the impact of thermal, electrical, and mechanical noise. Our goal is to produce an inexpensive, modular, and expandable solution for data acquisition from a laser and to control this laser system. This will lower the cost of entry for less specialized labs and independent researchers, helping promote the use of optical instruments in a wide range of scientific fields.

Background
For this project, we will be using a Red Pitaya Board that uses a Zynq 7010 System on a Chip (SoC). This will be the main location for the data acquisition and control loop. We also need to understand what a laser interferometer does and how we will be using it. Another important aspect of this project is the Pound-Drever-Hall control loop that will be used to control the entire system, from the laser to the data acquisition.

Deliverables
The deliverables for this project are as follows:

1. Be able to demonstrate two Red Pitaya boards communicating back and forth.

2. Be able to demonstrate the acquisition of data and the storing this data

3. Be able to gather input data from a laser

4. Be able to demonstrate the usage of a Pound-Drever-Hall control loop

5. Be able to use the Pound-Drever-Hall loop to control the laser

Specifications
Basic Considerations:

1. Modular design that will allow multiple implementations across multiple platforms.

2. 2 Analog-To-Digital Converter Inputs and 1 Analog-To-Digital Converter Output

3. High Speed Data Sampling -- Fastest Attainable

=Design Considerations= Some things we will need to consider is how we will get multiple boards to communicate, how we will gather data and store that information, and how we will be able to create a control loop. Firstly, we will be looking into how to synchronize two boards. We can use logic functions inside the boards itself, or move some resistors on the boards so that we can use an outside clock source that all data acquisition can use this clock. To store the data acquired, we can use multiple different output sources. We can store it on the FPGA itself, output a binary file, output to a spreadsheet, or output to some python script (or other language) so we can create a visual representation of the data. When creating a control loop, we will need to go through the process of making multiple block diagrams using the specific part specs given. We will need to keep in mind what each part can handle and what it's limits are. Some other things we will need to keep into consideration the input voltage and current. We need to make sure that they aren't too high due to the potential of 'burning up' the FPGA or too low causing incomplete or inaccurate readings. To do this, we will potentially be using a separate heating mechanisms for additional control and temperature measurements. With this, we will need some sort of interface to control the thermal unit.

=Project Learning=

The learning for this project was done around a period of about 4 weeks. In these four weeks, we spent hours looking through a variety of academic journals and scientific articles. Much of our learning was spent investigating on whether or not other teams have been successful in data acquisition using FPGAs and what sort of benefits comes with using FPGAs versus other boards. The one suggested by our client to use was a board known as the Red Pitaya. The Red Pitaya has ben used in data acquisition platforms before twice by two separate teams. Those teams were able to get their board working successfully and so with the glaring evidence that this is a viable solution as well as the extensive product comparison sheet, we decided to run with it.

There was still a lot of learning we had to do as far as what sort of technical problems we would run into (Interfacing, voltage matching, etc.) as well as how to get it to do what we want it to (Software and firmware manipulation). Alexis luckily is familiar with Verilog (Most likely the language we will all be using) so she will give us a crash course on not only how to write in Verilog but also how to use Vivado (The IDE we will use for our board). We are all familiar with python and there exists a Red Pitaya Github that we can pull python examples off of to then manipulate and make it work with our platform. Choosing to go with the Red Pitaya and committing to it is important for us right now to stay on schedule.

All the project learning that has been done so far has been through reading papers and other source. These papers are stored in the following google drive folder:

https://drive.google.com/drive/folders/16vyaEGdfl7epmlNNZf9rPNHG0yYrHRFh

=Final Design=

=Validation= This section hold our teams overall plan to validate all portions of our design followed by the testing procedures for how we validated each step of our design process.

Test Procedures
=Team Members=

=Additional Documentation=

This section involves any additional URL's and files that we used to design, implement, and test our projects. This includes our Project Schedule, which takes breaks into account, our Meeting Agenda and Minutes for every week, presentations done, and more.

Project Schedule:



Meeting Agenda and Minutes:

https://drive.google.com/drive/folders/1N3VZ4ltA2Oxs-BCvWhRuyVUYpKuJwwT_

Presentations:

Preliminary Design Review: https://docs.google.com/presentation/d/1qNgygZmloFiA3YAT-jaoAQharKtmmwr0DuBmAPOwm5c/edit

Snapshot 2 Presentation: https://docs.google.com/presentation/d/1L0RskYqV3tdFSKYgVyYwhOr91OsjQqlO01ixB0C7K3Y/edit#slide=id.p