Category: Team Status Reports

• Risks
  • The USB driver crashes when reading occasionally.  This happens frequently enough to prevent us from transmitting large files.  We are not sure why this happens yet.  We plan to look into this bug and hopefully find what is happening.  If we do not figure it out, we will try to have the code try to reload the USB Device repeatedly if it happens.  Updates to fpga code seems to stop this from happening.  We can now send large files without this ever happening.
  • The software sometimes goes into a deadlock when both receiver and transmitter has data on its TX buffer. The timing and acknowledgements is hard to get right, but we may make some assumptions to make this work.
• Design Changes
  • No design changes this week
• Updated Schedule
  • We are on schedule to finish the final deliverables (poster, report, and video).  We still need to run our system stress test which will be done soon.
•  Progress
  • We have nearly completed our poster, which only needs a final review before submission.
• Unit Tests
  • Laser Speed Test
    • Use FPGA to transmit set signal over lasers. Measure the receiver inputs into the FPGA using an oscilloscope
    • Results: Measured clean 6.25Mbps with proper focus
    • Findings: The fall time was much slower than the rise time, especially when the receiver was getting too much focus (up to 120ns). This made it important that the focus is adjustable and set correctly, and slower transmission speed more desirable than faster.
  • Power Test
    • Measured power draw with all components on.
    • Results: 0.223A draw from 9V power supply
    • The USB-PD can support up to 9V for 3A, which easily passes our criteria.
  • Ambient Light Test
    • Laser transmission tested in multiple rooms, to ensure that most room settings are fine for transmission.
    • Results: The laser worked similarly and properly under all room conditions.
  • USB Speed Test
    • Ensure that USB can transmit to our PCB that would meet the use-case transmission requirement
    • Findings: The baud rate set at 7 Mbps is working, which passes the test.
  • Angular Error Test
    • At 1m, measure the largest laser focus that transmits properly.
    • Results: Calculating the angle of error based on the target size, we found that the angular error can be +/- 0.13 degrees in minor direction, and +/- 0.32 degrees in major direction.
    • Findings: The focus that would make this system work had a much smaller target than we originally anticipated, since the receivers produced much less current than calculated based on the datasheet. We lowered our use-case requirements to adjust for this. In addition, we added handshaking between each packet to make sure that packets aren’t continuously transmitted even when the aim is off.
  • Error Correction Test
    • Tested Hamming code error by injecting 1-bit and 2-bit errors.
    • Results: The test passed, with the software correcting 1-bit errors and reporting that there were errors for 2-bit errors.
  • FPGA Communication Test
    • Had the transmitter FPGA receive data over USB, send it to the receiver, and the receiver checks for the start sequence and begins to write the data into the FTDI chip after receiving a full 1kB. Timed this using counters in FPGA. Not use lasers, and communicate by connecting receiver/transmitter FPGA via jumper cables.
    • Results: For a given transmission speed (6.25Mbps), data sent 97 percent of the time, with other 3 being taken up by FPGA processing (6.06Mbps of throughput), that will be even more amortized if more packets are sent. Pass requirements.
• Integration Testing
  • Device Speed Test (without USB)
    • Time the FPGA transmission of usable data from the moment it arrives at the FTDI chip to the moment the receiver FPGA attempts to write to it.
    • Results: 2.21 Mbps of usable data observed at 4.47 Mbps of transmission. This is after taking away the overhead put on from UART (8 data bits / 10 bits), Hamming (11 data bits / 16 bits), and protocol overhead (packet starter and packet tag).
  • System Speed Test (with USB)
    • Timed transmission of one packet to another using a laptop
    • Results: Observed ~2 Mbps of usable data, meeting the adjusted 1 Mbps required.
  • File Send Test
    • From close distance, send a small (< 128kB) file from one device to another.
    • Results: Packets delivered properly and reconstructed!
  • System Stress Test
    • Put full system together, and send one large file (19MB) to the other at a distance of 1m.
    • Result: File sent correctly!

• Risks
  • We discovered that when sending a large number of 1’s in a row, ambient light filtering kicks in and starts flipping them to be 0s.  This means that we cannot send most files.  To mitigate this risk, we have two proposed design changes as described in the next section.  Both ideas seem to pass preliminary testing.
  • The USB driver crashes when reading occasionally.  This happens frequently enough to prevent us from transmitting large files.  We are not sure why this happens yet.  We plan to look into this bug and hopefully find what is happening.  If we do not figure it out, we will try to have the code try to reload the USB Device repeatedly if it happens.
  • The software sometimes goes into a deadlock when both receiver and transmitter has data on its TX buffer. The timing and acknowledgements is hard to get right, but we may make some assumptions to make this work.
• Design Changes
  • Because of the series of 1’s bug that changes the threshold for the ambient light, we need to change our design.  The two options are to turn off ambient light filtering or change data encoding on FPGA.  We have demonstrated that both ideas work through testing, although the system still sometimes crashes with ambient light filtering off.  With the new encoding on the FPGA (keeping light filtering on), it works extremely well with no errors/crashes.  The current plan is to use that for our final design.
  • Each packet will have a handshaking before starting transmission. This design change was made to avoid the computer needing to resend the packet as much as possible, since the computer to FPGA speed seems to be the bottleneck for our project.
  • The error queue/acknowledge is sent from the receiver every 128 packets. This was originally after every packet, but through the use of software drivers we found the read operation to be extremely slow compared to everything else, which led to this change.
  • We will either use 4.17 Mbps or 6.25 Mbps speed for our transmission, which we found to work through testing. Originally, this was planned to be slower.
  • We will be using a 11-16 bit Hamming encoding instead of the whole packet. We found that bit-flips are common within a byte, so this would ensure that more can be caught, even though it will eat in to the amount of usable data sent. In addition, the packet size got much bigger than the original 64 bytes planned.
• Updated Schedule
  • Our integration and debugging has slid behind schedule, and we are cutting into slack. However, we managed to get the whole system integrated and mostly working. We also performed multiple tests, and the tasks left are refining, making design trade-offs, and documentation. We will continue work on debugging while preparing for our final report and demo.
•  Progress
  • We sent complete files through the whole protocol!  Everything works at least somewhat, and we are now onto debugging rather than implementation.  We have sent a file as large as 19 MB without any issues.
  • Performed various tests (distance, lightings, different speeds, timing each)

Transmission of Image from one computer to another!

• Risks
  • Communication between boards seems a lot more unstable than reflecting back to a single board.  It is not clear why, but this may be due to aiming the laser needing to be very precise.  We may need to reduce our requirement of aiming accuracy needed for the lasers to work.
  • The receiver on the FPGA were encountering issues when tested by itself, which may be due to not using the PCB board. Currently, we are seeing duplicates, and the FPGA code may still have concurrency bugs that can be fixed to make receiving more accurate.
• Design Changes
  • We realized it is pointless to include 2 lenses if we are only using one laser, so now each lens housing only holds a lens above the IR laser.
  • The header sequence for each packet will now be 4 bytes instead of 1 for increased reliability.
  • The packets will now be sent continuously (not waiting for a feedback) from the transmitter, and the receiver at the end will send back all the tags that are missed at the very end so that they can be resent.
  • The tag ID byte length was changed from 1 to 4 bytes, so that we will never encounter a wrap around, making software easier to implement with relatively low cost in terms of packet size.
  • The packet size will increase from the originally planned 64 bytes into  kbytes. This decision was made because we figured out that the FPGA embedded memory that allows us to store that many bytes, and the C read/write functions were slower than expected, so batch operations can help lower the time needed per byte.
• Updated Schedule
  • We will continue working on integration for the next week and beyond as more subsystems are ready to work together.
•  Progress
  • We sent data from one laptop to another through the laser!  This was raw data, but it was a very big step to demonstrate that the entire pipeline works.
  • We completed the second lens and lens holder assembly, so now both boards have complete mechanical setups.

• Risks
  • IR seems to use incompatible photodiodes and receivers.  We do not have a way to fix this, so we will just not use it.  This was always a risk, and a big part of the reason we made sure to have multiple lasers was in case one did not work.
• Design Changes
  • We are now using a usb power/data splitter for our usb cable.  This allows us to use a usb pd source, like a wall charger, for power, combined with usb 2.0 data from a laptop.  The board combines them into one cable for use on our board.
  • We are now only using the green laser.  IR hardware does not work, but green does.  The green also appears potentially fast enough to meet our requirements on its own.
  • The charge pumps are creating very large radiated emissions onto our photodiode traces.  To deal with this, we are using only the charge pump which is further away from the green photodiode.  This is far enough to not introduce noise onto the line.  This is done with some resistors attached on top of the board, and the regular charge pump DNP’d.
• Updated Schedule
  • We will continue working on integration for the next week and beyond as more subsystems are ready to work together.
•  Progress
  • The power splitter board came in, was reworked, and successfully delivered both power/data to the PCB. This splits the USB-C line from the PCB into power and data outlet, which can be connected separately to a power supply and a computer.
  • The data path from FPGA to laser back to the FPGA was successfully verified at a speed of 6.25 Mbaud, even over just 1 laser!
    • 
  • The board hardware is seemingly complete!
    • 

• Risks
  • This week we fixed several risks, including low laser power and the FTDI power chip not working.  However, we also added several more:
  • One is that Macs do not support our usb power plan.  We need to find a new power solution.  We plan on researching available usb splitters and powered usb hubs that may fit our needs.  Worst case, we can either hand splice a wire to separate power and data or we can use a power supply separate from USB.  However, we plan on looking into better alternatives than that.
  • Another risk is that the comparators do not work.  Our original comparators for our receivers do not work as well as the datasheet suggests, and therefore our circuit does not create enough overdrive voltage for them to have digital outputs.  To mitigate this, we purchased 2 different new comparator chip models that should perform better.  They are the same footprint and will work perfectly if the datasheets are correct.  If they both end up not working, we can wire in a breadboard with more analog circuits to fix this.  However, that would greatly limit our max communication speed, so we are trying new comparators first.
  • Simulation on the FPGA had difficulties running due to subtle syntax differences. The biggest of these were debugged, but the ability to easily verify it might be time-consuming in the future.
• Design Changes
  • We will need some new part to fix our usb power delivery issue.  This is not yet determined, but will likely be something between our board and the laptop.
  • We changed how we will be 3d printing the lens housing.  Rather than 3d printing threads or a hole for self tapping, we will cut the metal housing we have down to a small size since it has threads that fit our lens already.  Then, we just need to 3d print a circular hole for the housing to sit in, which requires much less precise work.
  • We plan on removing the sequence tag ID, once we verify that all of the packets can be performed in-time synchronously. This will be dependent on the speed that the computer can read data off the FTDI, verify the Hamming code, and send data back.
• Updated Schedule
  • The actual 3d print and assembly of our lens housing has been pushed to next week due to issues with the board that came up this week.
  • Board testing continues to be extended as we encounter unexpected issues with the boards.
  • FPGA testing will continue on next week, waiting for software and hardware to work before integration.
•  Progress
  • The board powered over 9V USB PD by configuring the EEPROM connected  to the FTDI chip:
    • 
  • Currently debugging, but a full FSM and datapath for the FPGA was designed and programmed.
  • Higher power laser output was produced that can be read better by receivers.

• Risks
  • The IR receiver on one board appears to be floating.  This is not a huge risk because it is likely a poorly soldered part, but there is a risk that there is something big wrong.  We will be looking into this next week to determine exactly what is wrong.
  • We tried to do a quick test of the receiver, which did not work. This is most likely due to poor setup, but it may require figuring out how the ambient light filtering works, and how best to aim the boards to each other in order to test accurately, which may take some time and work.
• Design Changes
  • Our USB connector did not fit properly on our board, so we needed to bend pins and not attach all pins in order to get it connected.  This ultimately resulted in some power and ground pins not being connected as planned.  This is not expected to cause any issues but does mean that our board supports less current going through the connector now.
  • When writing the FPGA program, we’re slightly split on whether to make it so that both lasers must receive at the same time and transmit at the same time. If we do this, it would add integrity because there is a much smaller likelihood that both would turn on accidentally at the same time, and make handling the protocol easier. However, it would also make it so that testing is difficult. Right now, the decision is that it will only handle simultaneous receiving/transmission, and the code will be modified slightly so that testing can be done with just one.
• Updated Schedule
  • We did not do any 3d printing this week due to the assembly process taking longer than expected.  This will now happen next week.
  • The implementation of the FPGA got slightly overlapped with board integration, and some of the code development would be shifted to testing using the actual PCB.
•  Progress
  • Boards complete!
    • 
  • FPGA code written and tested for the laser and receiver module. The FSM that handles the actual protocol behavior is written on the receiver side, but not yet tested.
  • FPGA and board integrated, and ensured that GPIO pins control the appropriate circuitry.

• Risks
  • With the complete PCB design, we removed some of the planned backup plans since they were not feasible.  The big one is that we were planning on leaving some extra DNP pads for more green photodiodes in case our photodiodes are not strong enough.  However, there is slightly more risk now since we had to remove this to make layout work.
  • We noticed that the FPGA board lists some pins as clock pins.  The Datasheet does not describe what this means.  This is 2 pins from the FTDI chip and the 2 IR laser controlling pins.  If this ends up being an issue, we can accommodate it by using an interface with the FTDI chip that does not use those pins (fast serial) and by testing that the IR laser pins operate at high enough speed.
• Design Changes
  • Our PCB will be much smaller than the FPGA board rather than a copy of it.  This is because the parts fit on a much smaller footprint, and making it smaller makes buttons and LEDs on the FPGA board accessible, and it will be easier to make sure the boards fit together.
• Updated Schedule
  • In terms of schedule, software developments (Roger) were impacted by inability to develop software for hardware that had not been fully finalized. We have instead begun working on sender implementation as well as a preliminary UI interface to input text files for sending in order to be productive within the schedule constraints.
  • No changes have been made to the hardware schedule as the PCB and part orders went out on time
•  Progress
  • PCB design is complete!  Our PCB and all components for it have been ordered and should arrive by the time we return from spring break.
    • 
  • Sender implementation for the bitwise hamming encoding of files has been implemented
  • We completed our design report paper
• New Tools
  • We will need to learn to use FT_PROG to program the EEPROM to save settings for our FTDI chip
  • We will need to experimentally identify the best way to view the infrared laser for debugging and testing.  We currently plan on using the front-facing camera from our phones, as they typically do not have IR-cut filters.  However, this may not work.  In that case, we will need to learn to use an IR camera to measure it.

• Risks
  • 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.

• Risks
  • 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
  • High speed digital design
  • Optoelectronics
• Photos
  • Testing laser diode power and beam width:
    • 
  • Budget:
    • 

• Risks
  • FPGA availability
    • 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.
• Photos
  • Starting to set up FGPA to test out compilation