Weekly Status Reports

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