Author: kjnewman

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