Posted on

Roger Lacson’s Status Report for 4/29/2023

  • Personal Accomplishments
    • I coded a separate acknowledgment protocol for sending the start packet as well as the error queue packets. Originally for sending the start packet (containing the number of packets, the length of the final packet, and the name of the file to be sent), I would have the transmitter loop on writing to and then reading from the FTDI. Reading was done to receive an acknowledge message from the receiver. We deemed that the looping of writing on every iteration was unnecessary, so the code was adjusted to only write once at the beginning, and then only specifically write again if an error message was received.
    • I am trying to code out a protocol that handles drops when the transmission is interrupted (e.g. when someone’s hand blocks the laser). This is difficult because I am unsure of how the receiver will handle partially received packets. Additionally, I don’t know what bytes the receiver will read if transmission restarts after unblocking the laser. Furthermore, because we pause every 128 packets to send the updated error queue, I have to case on whether or not another complete packet is received that needs to be decoded (and every packet that was missed has to be added to the error queue) and case on if up to the 128th packet is read, and then distinguish this case so that it can add all error queue packets up to this point to the error queue to be retransmitted.
    • I tried thinking about the error messages that KJ shared with me. However, the documentation is bad, and furthermore, if the only solution is to loop on closing the FTDI connection and re-open, the coding logistics are difficult and require planning.
  •  Schedule
    • My code is in a good enough state to demo by transmitting moderately-sized (<~25 MB)  packets. Should I be unable to complete the code I described above, the code is still functional enough to display a proof-of-concept-style presentation. In this regard, my progress is on schedule for demo day. I will, however, do my best to improve upon the current implementation to hopefully improve performance for demo day.
  • Deliverables
    • Code for transmission drops
    • Code for handling FTDI disconnect errors
    • Report and poster presentation contributions
Posted on

Anju Ito’s Status Report for 4/29/2023

  • Work this week
    • Work on most of the Final Poster. Create diagrams and contents.
    • Start creating and writing the final report, copying from the design report and starting to document changes.
    • Help with and keep up with the software testing happen, although FPGA code has not been touched for software to debug.
    • Final presentations during class.
  • Schedule
    • We are on track with the schedule. What remains are mostly final documentation work for the demo and report, as well as fine tuning for me. Software bugs has mostly been sorted out.
  • Next Week
    • Finalize final poster, and create final report/design. Most of the technical design has been done last week, so what remains are the final documentation, and potentially testing different communication speeds/minor encoding to get the last speed boost out.
Posted on

KJ Newman’s Status Report for 4/29/2023

  • Work this week
    • This week I worked on debugging the usb driver.  I located a document which specifies what the error codes that ftdi functions return mean.  I then added a lot of debugging code to print these codes in human readable form anytime there is any error.  It seems that some fpga code changes have mostly gotten rid of errors while operating.  However, setting baud rates above 7 Mbps still has issues.  I printed the error code when this happens, and it is FT_IO_ERROR, which is ill documented.  I believe that some baud rates cannot be achieved with the clock dividers on the chip.  However, these are not documented anywhere.  Therefore, we are likely to stick to 7 Mbps.
    • I worked on our poster this week.  Anju had already started the poster but it was difficult to edit, so I made a new copy and copied all information over.  I also spent a while trying to make sure the text in images would not need to be rescaled because that was making it blurry and poor quality.  The poster is pretty much done now.  As a team, we will look at it together.
  • Schedule
    • We are on schedule.  I only have work on the report, poster, and video remaining.  We also need to do the system stress test.
  • Deliverables
    • Next week, I will be finishing up on the poster and working on the report.  I will also run the full system stress test.
Posted on

Team Status Report for 4/29/2023

  • 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!
Posted on

Roger Lacson’s Status Report 4/22/2023

  • Personal Accomplishments
    • I finished encoding the entire sender and receiver protocol. This includes transmitting and acknowledging a start sequence, sending packets, implementing an error queue to handle hamming decoding errors, and resending erroring packets
    • Upon the first full integration, I did not account for my algorithm having an error for either the initiation sequence or the error notification packets. This led to segmentation faults, because my hamming decode returns NULL upon a failed version of these specific packets.
    • I adjusted my implementation to only proceed when the hamming decide returns a legitimate data sequence
    • This however led to another bug where if the singular acknowledgement sequence is missed for either the start sequence or the error resend request sequences, both sides stall. I will fix this in the coming week
    • Upon full integration at the end of the week, we were able to send full files! We sent images, with the largest files we were capable of sending being some hundreds of kilobytes. However, due to the boards being somewhat finicky, larger packets increase what seem to be a random probability of read errors, leading to larger files being more finicky to send
    • All in all, we are at least able to transmit data using my protocol.
  •  Schedule
    • In terms of my code, it is in almost as good a place is at can be. I will make the changes made above, which shouldn’t take longer than a day of work, and in terms of my own schedule, I am caught up.
  • Deliverables
    1. Adjusting my code to better handle the stalling when an acknowledge fails to receive. While the fix won’t entirely eliminate the acknowledgement problem (this is an impossible problem in computer science), it should maximize the probability that data is transferred.
    2. Possibly find a workaround for when the board crashes. I could possibly make the board force close and force reopen again, and retransmit packets. However if the logistics are too difficult, especially with final demos coming up, I can at least write pseudo code that could adjust the code for a potential fix.
    3. Better documentation for my code.
Posted on

Anju Ito’s Status Report for 4/22/2023

  • Work this week
    • Finalize laser transmitter/receiver and FTDI interface
      • All inputs go through 2 flip flops to avoid metastability
      • Better timing for all I/O devices
    • Implement handshaking
      • Handshaking occurs before every packet send now
      • Series of 0xAA sent by transmitter. Receiver responds with 0x10
    • Implement packet sending/receiving
      • Sender: send bytes in 1kB chunks. Handshakes before each one.
      • Receiver: receives bytes. If receive < 128kB after handshaking, will pad out the bits with all 1’s
    • Use 128kB buffer on receiver/transmitter
      • If more than 1kB sent/received, FPGA has capability to store that.
      • Created to accommodate for slow USB transmission.
    • Create Manchester/Duty-cycle like encoding for FPGA
      • Made the last half of each bit a 0. We found out during testing that the ambient light filtering would adjust to the laser light level if we were transmitting a lot of 1’s in a row. In order to mitigate this, we made half of each bit a 0, and sample on the first half.
    • FPGA Cycle Counter
      • Added debugging counters to report how many clock cycles packets stay on the FPGA.
      • Measured from the point that the transmitter FPGA saw data on the FTDI chip until the receiver FPGA received and put the data onto FTDI chip.
    • Debugged a lot of FPGA code using setup where FTDI code was connected to the FPGA, and laser receiver/transmitter connected via jumpers to each other.
  • Schedule
    • We are cutting into slack, but the core part of the project is done. We have moved onto integration and testing. In terms of work, this has transformed into adding/getting rid of debugging features for testing and design trade-offs. We have successfully transmitted a large file (19MB) over lasers, and reached MVP!
  • Next Week
    • Continue working on integration. See the best methods of transitions and talk about design decisions at full-scale level. Refine.
    • Work on design report/poster/presentation.

FPGA setup used for debugging

Posted on

Team Status Report for 4/22/2023

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

Posted on

KJ Newman’s Status Report for 4/22/2023

  • Work this week
    • This week I spent a lot of time working on software.  The code was not complete for integration, so I both debugged and added features to get it to the point where it could be tested along with the rest of the project.  This included splitting up and reconstructing files, fixing the way boards are identified to use individual names (Black and White, to match their 3d printed parts), increasing usb speed, and much more.  The software is now in a state where it works and it can deal with packets with errors, but if there are errors in protocol packets that do not contain any file data, it sometimes fails.
    • I worked on integration a lot this week.  Early in the week, I fully integrated hardware and FPGA firmware with Anju, and demonstrated transmitting data at various speeds at various distances between two boards.  This fulfilled our testing for hardware for the most part, and it worked very fast!
    • During integration, I discovered that when a large number of 1’s are send consecutively, the ambient light filtering loop kicks in and thinks it is ambient light, since the parts we use are designed for laser rangefinders, not communications.  To fix this for now, we have disabled ambient light filtering, and the system works.  However, we are testing a new way of encoding data where the first half of a bit is data and the second half is 0 to prevent this from happening.  This may allow us to keep the light filtering on.  I have found experimentally that ambient light filtering is not necessary in most cases, since the board is not facing high intensity green light.  Based on preliminary testing, this approach works very well!  It limits our speed to 4.167 Mbaud over lasers, but it has zero errors!
    • I finished our slides this week, which includes having data for most of our tests, and a video demonstrating that we can send files!
  • Schedule
    • We are still working on integration.  The whole system is now together, and we are working on debugging issues for the next week or two until the demo.
  • Deliverables
    • Next week, I will continue working on integration and fixing issues.  I will work with Anju to finally select whether we will turn off ambient light filtering or change data encoding to allow filtering to stay.  I will also work with Roger on debugging the usb driver, since it fails when reading sometimes, preventing us from transmitting large files.

Posted on

Team Status Report for 4/8/2023

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