Author: rlacson

• 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

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

• Personal Accomplishments
  • I was able to finish the hamming encoding updates and was able to present these updates at demo day. In terms of structure, Anju and I decided on sending 1024 bytes per packet. Out of these 1024 bytes, 4 are for start bytes, 4 are for the tag ID, and I have now decided to have 1008 bytes to send 693 bytes-worth of data (with the remaining 1024 – 4 -4 – 1008 = 8 bytes of data as padding). The 1008 bytes will consist of 504 2-byte hamming encoded bits. Each 2-byte portion has 11 bits-worth of the raw data that are hamming encoded to 16 bits. I modularized my code, starting with bit manipulation functions (get_ith_bit and set_ith_bit), then the (16,11) hamming encoding function, a function that would take 693 bytes of raw data and hamming encode it into a 1008 byte data packet, and then a function to read a file and then hamming encode all the data. Similarly for the receiver, I added a (16,11) hamming decoder and error corrector/detector, and a full-data decoder.
  • I created a test suite for my code. I tested each function individually from the lower-level code (bit manipulation) to the higher-level functions that code/decode entire files. To test the higher-level functions, I encoded files in a directory and decoded them, writing the result to a new file. I use diff to check if the files are equivalent. I then proceed to inject the hamming encoded bytes of files with one-bit errors and decode them to see if the one-bit error correction works properly. I then inject another error which should lead to the file being added into the error queue. I had all this working and verified on demo day.
  • I also wrote a simple script to send and receive bytes via laser using the D2XX library for demo day. This code was able to read and write bytes properly on demo day, although the laser itself needed precise alignment to have them work. There is an issue that when there is a read error, the chip does not continue to receive instructions from my laptop, which I need to figure out.
• Schedule
  • I am currently still behind schedule according to the original plan, although I should still be able to complete the entire interface code by the end of this week to begin full integration once the board has been properly set and the FPGA is ready. I will aim to finish coding the entire sending and receiving codebase to program the boards to properly send or receive at any given time.
• Deliverables
  • Code to properly control the FTDI/FPGA regarding implementing the protocol, sending/receiving data, and coding/decoding data.
  • Testing with the hardware and debugging my code/hardware setup based on performance (I do not have many means to test my code other than directly with the hardware).

• Personal Accomplishments
  • I was finally able to interface properly with the FTDI chip and FPGA board using an echo program to write bytes to the FPGA. Instead of interfacing through a VCP, we will be using the D2XX library. It seems that read times are slow relative to write times, so this issue needs to be addressed. However, I can now begin to write the full software pipeline for the sender/receiver path. Pictures of the echo and timing are below.
  • 
  • Anju and I also updated the protocol as the read speeds would slow down the transmission time, and we would like to minimize reads as much as possible. We will return to a previous protocol where all packets will be sent at once, and an error queue will be created with packets that did not pass Hamming decoding and inspection. I will need to implement a priority queue to properly reconstruct packets. Instead of doing these in parallel however, because we will only have one green laser per device, due to the IR laser being rendered unusable, we will not parallelize the processes of the sender sending packets and the receiver requesting errored packets. We will instead wait until all packets are sent, and then re-request all packets from the error queue.
  • Additionally, we will increase the tag ID to 4 bytes to avoid the complication we had before of modular arithmetic when packets reached the highest representable byte number (We do not expect a file to be of size 2^42 Bytes or 4.4 TB which would be the size needed to cause tag ID modular arithmetic).
  • We will also increase packet sizes to 1 kB (1024 Bytes) to speed up delivery. This will mean that I have to update my Hamming encoding code for an increased number of Hamming bits.
• Schedule
  • My schedule is behind now due to all the discoveries and limitations encountered. With that being said, with demo day approaching on Wednesday, I will focus all my attention to write out all this software and test with hardware now that many design choices have been finalized. I don’t expect too many more curveballs, so I can fully commit to the current design ideas. I plan to have a fully functioning Hamming encoding demonstration for Wednesday, and possibly the pipeline to send bytes from one device to another via laser provided that Anju can finish her script for controlling the FPGA.
• Deliverables for Next Week
  • Readjust my Hamming encoding code for the different packet design and increased size.
  • New test cases
  • Begin fully implementing software that integrates library code Iinto sender and receiver- code for the device.

What I did

I worked with Anju and contacts in ECE who have more experience with embedded systems in an attempt to program the EEPROM to control the power draw and VCP and  FIFO modality of the FTDI chip. I had difficulties understanding the data sheet and relied heavily on my friends and Anju. Anju and KJ were ultimately able to program the EEPROM settings for power draw.

I wrote test cases for my hamming encoding code and have debugged various portions of my code.

I have begun thinking about implementing a script that takes in user input to start detecting, sending, or otherwise waiting idly. I have a simple main function that takes in a 0 or 1 for now to indicate send or receive. I hope to develop a more sophisticated system for setting modality.

 

Schedule

My Schedule was slightly delayed by my inability to understand interfacing with the hardware. I hope to test further this week to understand how to send signals to the device and have code for next week. I hope to work heavily this week attempting testing USB C communication to make up for my delay.

 

Deliverables

I hope to have a rough working system that interfaces with the PCB to flash lasers upon signaling and receive laser signals upon signaling. At the very least, I hope to understand the pipeline for signaling between my computer and the device.

 

• Personal Accomplishments
  • I have finished implementing background software for processes not involving hardware, consisting of sender and receiver libraries for processing information.
  • Anju and I collaborated on updates that should simplify the protocol. Before, we were going to concurrently send packets, decode on the receiver side, have the receiver signal for resending packets upon hamming error (which would involve a receiver side error queue and a sender side cache), and final reconstruction revolving around tags (involving a priority queue on the receiver side). We have since simplified this procedure. We will now only send packets one at a time until it passes both UART checks and hamming encoding checks in software. This will save us the trouble of trying to interrupt flow processes based on errors that might occur, and guarantees that on the receiver side, all information received and stored will be correct (based on the limitations of hamming encoding) and present. This also removes complications such as caching packets in the case of error on the sender side, and the priority queue on the receiver side. Additionally, the entire file size will be sent up front so appropriately sized memory can be allocated upfront on the receiver side. This has significantly decluttered and streamlined my code and should hopefully minimally compromise on time, if at all.
  • I completed steps 1 and 2 for the Ethics Assignment
• Schedule
  • My schedule is mostly on track now. I would like to write more test cases to double-check that my code is functioning properly. I can now proceed to work with KJ on programming an EEPROM and VCP with the hardware being completed this week.
• Deliverables for Next Week
  • More test cases for current code
  • Code that demonstrates a basic understanding of interfacing with the hardware (EEPROM and VCP code)
  • Begin fully implementing software that integrates the library code I have written into sender and receiver code for the device.

• Personal Accomplishments
  • I have begun implementing the software to process files and bitwise hamming encode them. The progress I have made on my code is screenshotted below.
  • I have decided to use a somewhat less space-efficient method for caching old packages (in case errors occur and packages need to be resent) in favor of speed and ease of understanding.
  • I wrote my part of the design report. Doing this in parallel with implementation hindered my implementation progress, but I hope to have sender and receiver library code finished by the end of the week following break.
• Schedule
  • My schedule has been adjusted. We were hoping to have hardware fully finalized before break so I could begin implementing software to implement with our devices, but we only finalized the device right before the break. As such, I moved onto other coding challenges to maintain the timeline, namely, the implementation for the software processing of packets from the sender side, as well as writing pseudocode and adjusting it for the receiver side.
• Deliverables for Next Week
  • I plan to have full implementations for the sender and receiver codes, separate from the hardware interfacing itself. This should prepare me to tackle challenges related to hardware in the following week, namely, VCP implementation and EEPROM programming, both of which, I do not have experience with and will need time.
  • Well-documented and thorough testing of my implementations and helper functions