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