The biggest remaining hardware risk is that the FTDI circuit is incorrect. If it is, we will be unable to communicate with the FPGA board through it, and we will not be able to draw 9V from the USB connection. Our mitigation plan for this was to model the circuit as much as possible on a manufacturer created reference design, and to ensure we will be able to make the project even if it fails. This will be done by communicating with the FPGA board through its native USB or through an external UART-USB adapter, and powering our board with a 9V power supply connected separately. This will allow the project to function even if the USB plan does not work.
Design Changes
The lasers have been shifted to both be powered off of 9V rather than IR being 5V for consistency and ease of debugging.
We added a 3.3V LDO to our custom board powered directly from 9V rather than relying on the one on the FPGA board powered by 5V. This is because the FTDI chip requires a 3.3V power supply, and since USB defaults to 5V, the FPGA board will be supplied 5V minus the dropout voltage of our LDO, which is about 1. We cannot guarantee that we will get the 3.3V back from that board that the FTDI chip needs in order to operate (and request 9V), so we need to have a way to get 3.3V reliable from the usb power regardless of voltage.
We connected all interface pins from the FTDI chip to the FPGA GPIO so that we can decide to switch interfaces later, rather than being locked in to the one we pick before ordering the PCB.
Updated Schedule
We have no major schedule updates. We were able to test our lenses ahead of time, so no longer need to do that next week.
Progress
Our schematic is complete! Full schematic is located here and is 6 pages.. Below is the front sheet showing interfaces between different subsystems.
The laser beam focus was one of our concerns, as we tested the beams last week and it was very wide angle. We tested out the laser again this week using empty laser housing that we ordered, and the beam was focused very well.
Before:
After:
Team Dynamics
There hasn’t been team issues working on our project.
We have shifted some assignments so that each person has work to do. Initially, we weren’t sure if we would have signals aspects in our projects, because we considered the use of DSP to clean out the signals that we get. However, because we realized that there were complications using the ADC (sample rate), etc. we have decided to use comparators instead. If we were to implement this, Roger would have dealt with the signals. Instead, we moved some of the EEPROM configuration to his task. In addition, due to communication protocol difficulties that we might face, we also shifted the Hamming encoding/decoding to him as well.
There was also a need for 3D printing that didn’t occur to us in the beginning. This has been taken on by KJ, since it would probably be easiest for him to interface with the PCB, and there will be more software/programming implementation for the rest of the team later on.
This week, I completed the schematic for our custom PCB. This included adding as many backup plans to the board as possible so it will still work even if I made some mistakes and some parts do not work as expected. I also had the schematic reviewed by both of my teammates and several other people to verify that I did not make any mistakes. This included doing calculations to ensure that the board will meet all timing requirements and finding an example board using our FTDI chip, since it is fairly complicated.
I completed our budget this week. This included specifying the exact BOM of the board, as well as figuring out how much extra of each part to order, and how best to acquire passive components. We are buying all parts we need, and purchasing as much as we can on multiples of 10 and 100 to get discounts. This means that our order of passives costs $0.01 more than buying enough for 2 boards, and it has over 100 more extra parts. The budget also includes all of our prototyping parts, 3d printing, shipping, a stencil, and everything else we will spend on. We will have $80 left over for anything that comes up later.
Schedule
My work is on schedule. I wanted to complete the schematic this week, and I had it done early in the week. We also tested the lens this week, which is ahead of schedule. I am confident we will be able to order parts and the PCB before Spring break, as I have a week for layout.
Deliverables
I hope to complete our layout for our pcb in the next week. This way we can order it next week and have it in hand when we return from Spring break.
Presented the design review for our team on Wednesday.
Worked on slides and practices beforehand.
Thought further about FPGA implementation, especially with regards to the interface between the FTDI chip.
For the FTDI chip, I had some concerns about using a single fast serial data that splits into 2 serial data complicating timing. As a backup plan and knowing options, I looked into potential other modes that the FTDI chip supports, and found the asynchronous FIFO mode. This was the only other option that seemed reasonable to use, as others supplied a 60MHz clock (faster than the FPGA onboard and will probably not go through the GPIO pins smoothly). I plan on attempting to implement the FPGA with the fast serial, but as a backup go into FIFO if there are timing issues that become difficult to smooth out. In addition, if speed of the fast serial becomes a bottleneck, this can also potentially allow for a much faster interface between the FTDI buffer data and the FPGA.
Thought through a little more of the block diagram and overall implementation, especially before the hardware arrives.
My plan is to have a rough implementation of the FTDI side, since some aspects are difficult to predict without the actual hardware in hand. I plan on working and refining more of the actual laser side since that can be read with the oscilloscopes through the GPIO headers to verify actions.
Helped focus the laser to verify that the laser beam angles can be fixed.
Overall schedule
I think that this week’s primary focus became the design review for the first few days. Although it’s not very far off schedule, I think that I could have worked on a more detailed implementation of the FPGA, which I plan on doing next week instead.
Goal for next week
Have an implementation of the laser side, and a rough idea of how the interface would be handled on the FTDI side on the FPGA.
Designed data transmission protocol with Anju (see image below)
Ironed out overall system communication between devices with Anju and KJ (See diagram below)
Began exploring UART and USB implementation information. I have chosen to implement the program in C/C++ to create a virtual COM port and communicate between FTDI and FPGA through UART
I worked with Anju and KJ to choose an FTDI chip as software implementation difficulty is impacted by this choice
We discussed options on how to narrow the green laser beam as KJ demonstrated that the beam width was too large
We decided to find a laser pointer and separate its lens to attach onto the already acquired laser that matches our specs
Schedule
My work is on schedule. While I wasn’t able to write pseudocode as I would have hoped for from last week, the protocol had to be ironed out to consider changes in hardware as well as address speed concerns. Up front, I still have less actionable tasks compared to Anju and KJ who have hardware considerations that need to be ironed out before I can begin formally coding. However, the planning stages are still on track to have code written before break, and I hope to produce pseudocode this week.
Deliverables for next week
I hope to produce pseudocode for this week to make up for last week
I would like to actively test COM port communication between laptops. Even, if the implementation is different between FTDI and my laptop, I don’t have direct experience with this, and would like to understand the implementation better
One risk is that the PCB will not be capable of the speeds we want. We do not have tremendous experience with high speed routing, so it is possible that the layout will cause issues.
We will mitigate this by doing a lot of research into high speed routing before doing layout work. Additionally, we will keep high speed traces very short.
Component availability between early stage of design and component ordering
We plan on ordering components as soon as schematic work is done to mitigate this. Additionally, we are ordering some extremely low availability components already.
Design Changes
We switched to using a FTDI to Fast Serial chip because the FIFO chips output a 60 MHz clock, which will cause issues both due to parasitic capacitance and inductance and the FPGA clock only being 50 MHz. This allows us to run the clock between FPGA and FTDI chip from 183 Hz to 12 MHz.
We switched to powering the board over USB Power Delivery. This allows us to request a voltage and receive it from the laptop over USB (in our case 9V). This removes the need for a boost converter on the board.
We will now power the FPGA board through the custom PCB, as this can be done with a diode reverse protecting the board.
We switched to a different IR laser diode because the prior one had a very odd configuration internally between its internal laser diode and photodiode that made it difficult to power.
We switched FPGA boards. We had acquired the wrong one (DE10) and switched to DE0-CV.
We will now use laser lenses that are threaded. This will enable us to screw the lens in and out to change focus without needing to create a new 3d printed housing for every focal length change, which should reduce the number of 3d prints we need to only 1.
We switched to using a custom UART-based protocol instead of SPI over the lasers. This is because we did math and determined that the SPI clock line would only help at higher baudrates than our system will be capable of, so we are better off doubling speed by using 2 parallel uart transmit lines.
Schedule Changes
We shifted Roger to working on the USB interface first and UI later, because the UI can be simple and is not difficult to implement, but USB could prove challenging.
We added testing lenses and 3d printing a holder to our schedule because it was missing before
Principles of Engineering, Science, and Mathematics
Tested speed of FPGA I/O pins from the Dev board to see how fast communication can go from custom PCB to the FPGA
Measured that 12.5MHz clock can cleanly be measured from the GPIO pins. From this, we decided that using an FPGA dev board was sufficient and a better option than a microcontroller. Faster speeds yielded questionable results, although there is a possibility that the oscilloscope probes couldn’t measure as fast. We can safely rely on using the 12.5MHz clock (i.e. 25 Mbps) communication for our project.
FPGA Spec
50MHz clock
3.3V active high from GPIO pins
Detailed measurements:
4.15MHz from FPGA, measured with an oscilloscope at 500MS/s sampling:
Worked with Roger and KJ to come up with communication protocol.
We weighed the different options between a SPI-based and a UART-based protocol, and concluded that we will use a UART-based protocol for LaserDrop, as this would yield better results after evaluating it while thinking about sampling speed from FPGA, circuit response, etc.
Decided on the packet properties of the laser communication (start sequence, packet ID, data, Hamming encoding, packet size)
Decided which aspects of our project (CPU, FPGA, circuits, COTS IC) would handle which part of the protocol
Came up with an error handling mechanism for lost packets
Came up with a handshaking mechanism for beginning/end of instantiating a communication
Designed the FPGA block diagram that would handle this communication.
Overall FSM and block diagram that will interface with the FTDI chip and PCB circuitry.
Worked on the design review presentation with the whole group.
Schedule
My work is on schedule. My goal last week was to test whether the FPGA dev board or the microcontroller would be able to support the communication, which I was able to do. Due to the success of how fast the signals came across from the FPGA board, we concluded that a microcontroller would be unnecessary and we can go forth with a custom PCB that would interface with the FPGA.
Goal for next week
Practice and present the design review during class.
Address the feedback/concerns that we receive during the design review from the advisors, faculty, and classmates
Refine and come up with a detailed FSM/block diagram of the whole system
Principles/Courses Used
18-240, 18-341: In these classes, I learned how to use and design the FPGA boards (Altera DE0-CV), which I used to think about how the FPGA will interface with the FTDI chip and PCB circuits and handle the protocol that we designed. In addition, protocols such as the Hamming encoding and USB were explored in these classes that helped when we were coming up with the communication protocol. In addition, I wrote simple SystemVerilog code to test out the FPGA speeds, which I will heavily use later on in this project as well.
18-349: Embedded Systems taught about various protocols such as SPI, UART, and I2C that we thought through while coming up with our custom protocol. In addition, 18-100 and Manchester encoding, etc. were another features that we thought about when thinking about the communication protcol.
MoonRanger (16-861/16-865: Space Robotics): Gave me hands-on experience with communication protocols (UART, etc.) that helped during protocol design. In addition, I learned and often used oscilloscopes and other tools, which made it easy for me to figure out the FPGA speeds.
I spent this week designing our pcb and selecting every active component. This took a very long time because our application is very niche, so few parts exist that meet all of our requirements, and we need to have all the pieces fit together. This led to changing the design many times and reading datasheets for practically every part available for the some components, like laser diodes, photodiodes, and transimpedance amplifiers. This resulted in a now complete architecture and component selection that just needs to be filled in with passive component values to create a complete schematic. We do not expect to need to purchase passive components, as we have access to them from labs.
I worked with Anju and Roger to design our communication protocol. They were in charge of this, but I expressed some opinions and made sure their design is compatible with my PCB design.
I also worked with Anju and Roger to pick which FTDI chip to use for USB, since they have software requirements as well as the hardware requirements of the subsystem. After switching between many options, we finally settled on one.
I completed a budget for us. I ordered laser lenses for testing and factored in pcb fabrication and 3d printing cost to find how much our current plan will cost. We will have about $50 of buffer to handle anything we need to buy later on. This could go up with more selective buying extra parts than just buying 4 BOMs.
I tested the green laser diode to verify it works exactly as expected, and it does. I also tested the other components we bought early for testing, and found that none of them do what we want. This is very valuable because through this, I have learned how the optical components work and how they must be used in designs, so our final design will be well informed.
Schedule
My work is on schedule. I wanted to test parts this week, which I was able to do last week. This week, I got ahead on creating a complete design of the PCB and selected every part, which should make me continue to be a bit ahead next week, when I am expecting to create a complete schematic. While I do not have the schematic yet, I have a complete enough design that the schematic will be pretty quick.
Deliverables
I hope to complete our schematic for our pcb in the next week. I also hope to test our newly purchased lenses with Anju when they arrive to make sure we will be able to use them.
Principles Used This Week
Circuits:
I used principles from 18220: Electronic Devices and Analog Circuits for designing our circuits. However, most of the knowledge I have about circuits comes from my work outside regular classes working on Moonranger, a lunar rover research project (16861: Space Robotics, 16865: Space Robotics Development, 16597: Robotics Reading and Research). I also have learned principles of analog design from prior internships.
Protocol Design:
I used some principles from 18240: Structure and Design of Digital Systems and 18349: Introduction to Embedded Systems to help with designing the protocol this week, as I used FPGA knowledge and knowledge of existing protocols used in embedded systems. My knowledge that helped with this also comes primarily from research outside class as well, as I have written a lot of embedded code for research and for internships.
Optics:
I have no familiarity with optics and optical circuits. I learned about optical circuits, how they work, and common designs through a lot of online research reading datasheets, reference designs, and guides on creating various optical circuits and communication systems. I mostly learned from fiber optic and time-of-flight laser system designs.
What did I personally accomplish this week on the project?:
Began researching encoding patterns for transmission via laser
Hamming Code could be used to reach the specification presented in our slides (2-bit error detection, 1-bit error correction)
Duplicate Code could handle error correction but would make messages bulky and it’s too inefficient
Checksum may not be best due to collisions and lack of utility for the amount of resources it would require
Began looking into how ambient light would create noise and what issues to be aware of
In stable light environments, we just need to adjust the baseline levels of background and adjust thresholds
Unstable light environments (i.e. flicking a light on and off) may cause problems due to continuous need to readjust thresholds
Not a commonly discussed topic. This requires further research.
However, this should not be too much of a problem considering most environments have stable lighting and if there is any dimming (e.g. due to ambient sunlight) the change is gradual enough that it can be detected and corrected for
Is your progress on schedule or behind?
My progress is on track in accordance with the schedule. It is somewhat difficult to progress from a software perspective while we are still ironing out component details. However, using the information that I have, I can hopefully mitigate work further down the line.
What deliverables do you hope to complete in the next week?
Pseudocode for data reading and decoding
Signal Processing background information for fluctuating light levels
I will also monitor how KJ and Anju implement hardware to adjust how my implementation requirements adjust
FPGA chips were difficult to find, so we plan to switch to using a separate FPGA dev board or a microcontroller
Dev board may have latency issues because high-speed communication will need to be sent back and forth over wires to a separate PCB
Microcontroller speed/data transmission also has a latency issue, because it’s slower than FPGA
MCU speed: with the MSP430 that we’ve used before, 25MHz is the fastest option.
We could also use 2 microcontrollers to mitigate the speed issue, and use 1 per laser
Plan: test out both the microcontroller and FPGA dev board in a separate setting to choose which option
Component availability between early stage of design and component ordering
Some components are low stock. We will order components once we are confident we will be using rather than ordering once our pcb design is released
Lasers may not meet speed requirements
If not all components that we selected work, we will swap to a single laser setup using the one that works. We are confident that green will work because it has specs for modulation frequency, but the IR laser does not. We plan on testing this next week.
Design Changes
Change to FPGA
As described above, we were unable to find a FPGA to put on our custom PCB, so we will need to either use a FPGA dev board or MSP430 microcontroller.
Not using sinusoidal modulation
We will instead send a square signal over the laser. This is because fiber optic laser drivers do this as well, so there is no commercially available IC to modulate a sinusoid with enough current to power our laser.
Not use fiber optic laser driver
After creating a partial schematic and selecting support components for fiber optic drivers, it became clear that our application has a large number of changes required to manufacturer suggestions in order to work. Our project will be easier and more likely to succeed if we just create the driver circuits discretely rather than using a modified fiber optic driver circuit.
Switch to 2 lasers: IR and green
We found that blue lasers are very expensive and there is only one with a low enough power rating for us, and it is most likely too slow. As a result, we switched to 2 lasers. Changing red to IR makes the gap in wavelength larger, so we can use commercially available photodiodes that only receive light at certain wavelengths to filter out the other color.
Considering adding a higher voltage power supply
The green laser has a forward voltage over 5V. We are concerned about the effect that a boost converter will have on signal integrity, and do not consider our power supply to be the important part of our system.
Our project includes considerations for safety and security
Safety: The lasers must be of low enough power to not injure the eyes of users and bystanders
Security: Our use case concerns itself with the secure transfer of private information. This method should ensure the private and secure transmission of data with minimal chance for remote interception.
Schedule Changes
Because we are unsure if we’re using FPGA now, Anju will test out and set up environments for microcontrollers and FPGA to test out the parts for next week.
I worked with Anju on picking an FPGA and finding a development board to get her started on writing Verilog before the final PCB is designed and assembled. I looked at some microcontrollers as potential options since she could not find an fpga for us to put on a custom board, and worked with her to determine how to test if using an FPGA dev board will be fast enough.
I specced and ordered lasers and photodiodes to evaluate their performance with high frequency modulation to make sure they are fast enough for our needs. We are ordering a green laser and blue photodiode, and an IR laser and photodiode. The photodiodes have poor performance at the wavelengths of the other laser, since green and IR are far apart. This way, we do not need to do any filtering ourselves to pick out each color laser.
I began considering fiber optic laser drivers for use for driving our free space lasers. They do not meet our design requirements, so I began making a schematic to see if one could still be used with modification to manufacturer recommended support circuitry. It ended up having a lot of potential problems, so we probably will not go this route, and will use discrete circuits to drive the laser. Between doing calculations for component values on my own and TI’s responses to my questions about their drivers, it seems that it might not work once we have the final boards in hand, which is too big a risk for us to take.
I began designing a circuit to drive the laser with discrete components. This is probably what we will end up using.
Schedule
My work is on schedule. I wanted to buy the lasers and photodiodes this week to test their performance at high frequency, which I did. I got a bit further into schematic work this week than I expected as well.
The lack of FPGA chips available means that we have not selected a processor yet, which could put us behind schedule soon. Our fallback plan is to use an MSP430, because Anju and I are familiar with the software and I am familiar with hardware and confident I can make a board with one quickly.
Deliverables
In the next week, I hope to have a complete schematic of the transmitter, and an idea of some part selection for the receiver. I also hope to have come to a decision with Anju about what our processor will be, and a plan with Roger about how to verify that the board will work at our speed.
