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

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.
Posted on

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

  • Work this week
    • This week I finished our second 3d printed housing.  I cut more lenses housings and 3d printed the part to attach to the PCB, and assembled and tested everything.  This housing works as well as the first, so mechanical work on the boards is done.
    • I discovered that the “low” power setting on one board is pretty high.  This seems to be causing some inconsistency in communications, as the receiver cannot always tell it is supposed to be low.
    • I worked with Anju and Roger to integrate the whole communication pipeline together.  We both ran tests using a mirror to reflect data back to a board and using both boards.  Reflecting data back worked well, but using both boards was difficult for some reason.  I am continuing to debug why.  We did this sending raw bytes, not data encoded in our actual format.
  • Schedule
    • We are still working on integration.  The comms pipeline has been integrated in its entirety, but it appears buggy, so there is still work to be done.  Once that is complete, we will move on to testing.
  • Deliverables
    • Next week, I will fix the laser on one board to have a lower “low” power setting to make communications more reliable.  I will also continue work on integration with Anju, and will make a test setup to hold the boards stable for easy testing.  I also plan on disabling the IR laser to prevent accidents, since we are not using it at all.
  • V&V/Testing
    • Have run:
      • I have used an oscilloscope to measure the rise and fall times of the signal powering on the lasers to ensure it is sufficiently fast for 6.25 Mbaud communication, which it is.
      • We have run a communication test at 6.25 Mbaud through the lasers, with USB and FTDI interface running quite a bit faster, to demonstrate that the hardware can support communication at our required speed.  Because we have one laser, not two, this requirement has doubled to 5.42 Mbaud, so we made sure to test above that speed.
      • I have done some hand testing with optical angular error.  It appears that this error must be significantly smaller than we were hoping for and set as our requirement.  I plan to do further work testing this once I have a test stand setup that makes it easier to hold the boards stable, and document more precisely what is required.
      • I have measured the current draw of our device and made sure that it draws below the USB-C spec of 3A when powered on 9V USB PD.
      • I have tested the board in a variety of lighting conditions (light, dark, different rooms, natural vs artificial) with ambient light filtering on and it consistently performs the same.  This verifies that it will work regardless of ambient light conditions.
    • Plan to run:
      • Measure the received data on digital line to FPGA when receiving 6.25 Mbaud data to ensure it is clean, and rise and fall times meet our spec.  Just because it appears to work does not mean this signal is clean.
      • Run a test of the full system with the full software stack running and verify speed meets our requirements.
      • Run a system stress test transmitting a large file while intermittently blocking the laser and verifying it still gets transmitted.
      • Test the boards at a distance of 1m to ensure data can be transmitted at that distance.
Posted on

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

  • Work this week
    • Integrated RAM use on the FPGA. Created a 1k FIFO using Quartus IP, and successfully integrated into the code. This fixed the error of not having enough logic components to compile the design on the FPGA, and instead using the embedded RAM on the chip.
    • Fixed a FSM logic bug that prevented the FPGA from transmitting 2 bytes in a row over the lasers.
    • Fixed timing issue for writes onto the FTDI chip. When testing with lasers, occasionally saw that the 6th bit in the byte was always a one. There was a logic error in the setup time that resulted in data not being held for an appropriate length before the write was asserted.
    • Finished writing code and loading all the files for demo. Created a board that can be configured to echo just using the FTDI chip and back, and another that transmits whatever it receives through the USB on the laser and writes back whatever it sees on the receiver back to the USB. Also attempted to test by turning the lasers completely off and on, board-to-board transmission (worked much more poorly then single board using mirrors), and turning ambient light filtering off (not work too well).
      • Attempting to fix the board-to-board by creating mounts for the PCB so that they are more stable.
    • Working through making the receiver more robust. Cleaned out logic, which may have made it slightly better. However, still occasionally see duplicates in numbers during laser transmission, which needs to be fixed/explained.
  • Schedule
    • Everything that we prepared for the demo we were able to show, although there are new issues such as the necessity of extremely precise alignments and receivers having errors that need to be addressed in the future. Everything is around 2 weeks behind schedule, as implementation is taking a longer time than planned.
  • Next Week
    • Attempt to make laser transmission code more robust. Currently seeing duplicates and wrong bits too regularly.
      • Potential solutions: Fix any bugs that exist, slow down transmission speed from 6.25MHz, change how the receiver is sampling, add real-life flaws onto simulation to attempt to get error, 3D printed mounts
    • Implement handshaking protocol.
    • Work with integration and start testing.
  • Testing/Verification
    • Unit Tests
      • Echo to test FPGA/FTDI/computer connection: Test that verifies the connection between FPGA to computer by computer writing/reading bytes, and the FPGA echoing that back through the FTDI.
        • Verified. Attempted to time, and realized that computer’s read function especially takes a long time to run, but the number of bytes read doesn’t affect speed.
      • Laser transmission test: Verifies that the whole pipeline from computer to FPGA to lasers work with single byte.
        • Verified. However, alignment changes results a lot, and multiple bytes become less stable.
      • Packet send test: NOT DONE. Send a full packet, and verify that it was received correctly on the other side. Should not load it onto the FPGA if the start sequence is not received properly.
    • FPGA Integration Tests
      • Stress Test: fill FTDI chip multiple times, see if it can process data appropriately
      • Speed Test: measure pin out speed with oscilloscope to verify laser transmission
      • Light Test: Try testing in different lighting environment to see that transmission works under reasonable room conditions
      • Distance Test: slowly move the boards away from each other. Adjust focus, and record the max distance bytes can be transmitted at.
Posted on

Team Status Report for 4/1/2023

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

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

  • Work This Week
    • Wrote an echo program that reads bytes on the FTDI, and writes them back so it can be tested with computer software. Some bug exists with the reading, but communication has been established and it was seen that correct bytes can actually be read and written from the chip from both directions.
    • Continued to debug the FSM. Transitioning over to building smaller modules.
    • Attempted to transmit data at 6.25 Mbaud through laser. Sent it over FPGA, and received correctly on the board! Some bugs about reading, but verified that a single bit width can be detected and read.
    • Attempted to compile the Echo, and realized that 512 bits couldn’t be declared. Because that was the intended size for packets, realized that this needs to use built-in embedded memory on the FPGA, and created an IP that may be integrated and used instead. This can hold kbytes of memory, which is more than sufficient for our application.
  • Schedule
    • We were successful in verifying that both sides (lasers and FTDI chip) work to and from the FPGA. Next steps include debugging and building a more robust system, as well as integrating it into the full system. Things are behind schedule, partly as integration requires different projects and modules, which slows progress of FPGA development because they are not as modular as software.
  • Next Week
    • Figure out a code to put on the FPGA board during the demo
    • Make the memory work for the FPGA.
    • Fix bug for read write on FTDI.