This week, with progress finally being made with our PCBs, I worked on updating our touch control interface and tests from the interim demo to be compatible with the final hardware. I also helped Matt S with soldering the final surface-mounted components on the remaining PCB boards. The tests that I developed have yet to be used with the hardware as I need Matt K’s updated code, which he is also updating to match our new environment, to be fully working so that we can check how physical inputs translate to touch controls on the OS. We are currently in the process of debugging our work so that we can proceed with physical testing on the final hardware, and we are aiming to have this done by Monday. With the conclusion of the week I am well on schedule, and overall things have been ramping up recently since we are finally back on track after receiving the decoders. Next week, I will work with Matt K in squashing our final bugs so that we can start testing to not only check the robustness of the software and hardware, but to also record relevant data to compare against the requirements we set in our design review. We will start by testing physical input along one dimension, which we already have the hardware ready for. This is essentially a scaled up version of our interim demo tests. Once the second axis is ready, we will test touch controls along both axes, which would be a major milestone as this will give us the capability to interact with any point along the 2-dimensional space of the screen.
Team Status Report for 4/16
This week, we mainly focused on soldering the new PCBs and hardware testing. Darwin and Matt K worked on scaling up the software to work with the larger frame. There was also work done with regard to improving single-finger gestures. As for the hardware, we are slightly ahead of schedule as the short edges are ready to go without any hacking necessary. We hope to have the same success with the long edges in the coming week.
Next week, we would like to have the frame fully connected so that we can begin testing the software with it. If there are single-bit errors in the top and bottom frames like there were with the side frames, that shouldn’t be much of an issue, as we should still be able to test certain aspects of the code, such as how we are doing with latency and refresh rate.
Thanks to the work we put in this week, we find ourselves about a half-week ahead of schedule going forward.
Matthew Shen’s Status Report for 4/16
This week, I made some very significant progress on the hardware side. Since we finally got the decoders, we were finally able to start testing our design as it will be in its final form. To begin, I wrote an Arduino script that could sweep through the entire left/right diode arrays. While testing, I came across a single bit error, where it appeared as though a photodiode was always receiving light, even when blocked. That is, instead of the anode dropping from 5V to 0V, it would only drop to 3.4V for some reason, which was not enough to force the mux input low. I tried resoldering and replacing its 210k resistor to no avail. Then, I tried replacing the photodiode, after which nothing changed. So, I decided to replace the multiplexer, as that was my last guess as to what could be wrong. This proved to be the issue, as the new mux worked seamlessly.
Another thing I did was start soldering the long (top/bottom) edges of the frame with Darwin. This process is almost complete; all that is left to be done is to solder the photodiodes into the top. As for next week, I will modify my Arduino script to test the top and bottom. Using this script, I will do some hardware debugging. If all the components and circuits work, there may be some time to start integrating the hardware with the screen control, as Matt K has been working on the Python code to transfer the data. In sum, I am at least on schedule. Depending on the functionality of the components on the top/bottom PCBs, I might be ahead of schedule by the end of the coming week.
Matthew Kuczynski’s Status Report for 4/16
This week was difficult for me because I had COVID, so I was unable to meet with my group and did not feel good Monday – Wednesday. However, I was able to make significant progress on the software at the end of the week. My primary goal was to finish the Arduino script, which I accomplished, however it has not yet been tested due to some issues with PCB that existed until about an hour ago. Additionally, I wrote the new Python serial script, so the arrays of photodiode values can be communicated to the Python side. Previously, we had decided that the photodiode values should be communicated as a set of bit-encoded integers rather than a string to improve speed. Since the maximum integer size is a 32-bit long, three were needed since we have a 56 by 31 array (two with 28 for the top and one with 31 for the right). I also developed a protocol to know which values is being sent, which is to send either a -1, -2, or -3 before each value based on which of the three longs it represents. Since we never use all 32 bits for our longs, these negative values should never appear as the encoded photodiode values. Overall, I believe that I will be able to finish the testing in time, so I think that I am on schedule as long as I put enough work in this week and there are no more major hardware issues. Next week, I will debug my Arduino script, the Python serial code, and then work on multi-finger functionality.
Darwin Torres’ Status Report for 4/10
This past week, I helped the team in preparing our interim demo. The integration of subsystems B and C has been going well so far, so Matt and I designed some visual tests to showcase in the demo. Unfortunately, our decoders have not arrived, so subsystem A has yet to arrrive, but we were able to perform some initial “physical” testing with a breadboarded circuit. This allowed us to test our code that sends signals to the LEDs and processes signals from the photodiodes. Tests were successful, and we were able to set up a simple demo showcasing how interacting with the LEDs results in onscreen manipulation through emulated touch inputs. It was good to know that my code had integrated well with Matt’s. There are still a few bugs and problems present, most notably with the precision of our setup, but it will be hard to measure this accurately until we have the PCB completed. In terms of my software-related tasks, I am on schedule. Unfortunately, we have delays with the hardware, but we should be up to speed soon. Next week, Matt and I will work together in debugging our code. Once the decoders arrive, we will work together in completing the PCB so we can test subsystem A and get it ready for integration with our software. If I have extra time, I will start investigating multi-finger functionality within Windows.
Matthew Kuczynski’s Status Report for 4/10
This week I worked on preparing for our demo, so I worked with Darwin and finished writing some test scripts could should that our two subsystems could work together. Additionally, I worked with both Matt and Darwin to write a test that went through all three subsystems, which was demonstrated at our demo. These tests revealed flaws in my subsystem, so I also spent a significant amount of time debugging the code that I had already written. Once we had our demo working, I worked on the Arduino script for LED control and photodiode readings. Overall, I feel like I am on schedule since we made significant progress with the integration this week, however, we need the decoders to arrive or I will quickly fall behind. The biggest thing that I have left involves physical testing, which requires the hardware subsystem to be fully functioning. Next week, I plan to finish the Arduino script for LED control and photodiode readings. If the decoders come in, I will also begin physical testing, otherwise I will begin to work on multi-finger functionality.
Team Status Report for 4/10
This week, much of our focus was on the project demo. While we are still awaiting the decoders for our PCBs, we were able to make use of the test breadboard from earlier in the semester. On the software side, we developed a script to showcase touches on this breadboard to create clicks on the screen. While this was a good way to give an idea of how our project works, this week we must try to finish the functionality of single-finger gestures by using state logic to distinguish between clicks and finger slides. We should also try to minimize glitches that occur from LEDs being blocked for only brief moments in time. On the hardware side for the coming week, all we can do is hope that the decoders finally come in. If they do not, we will likely need to start hacking through-hole versions of the decoders onto the board so we can start debugging appropriately, especially since we have started eating into our slack time.
Matthew Shen’s Status Report for 4/10
We are still waiting on our decoders, which are concerningly behind schedule. This week, for our project demo, I reconfigured the breadboard prototype that we used for early-stage testing. We decided to come up with a quick script that could showcase the entire stack of our project, from hardware to serial communication to screen control. The hardware we used only features 7 LEDs, so we drastically upscaled the distance between touches on the screen from the distance on the LEDs. But for our final implementation, we hope to have a 1:1 ratio between the LED separation and how they map to screen touches. We are on schedule to finish in time, although we have slightly less slack time now. This coming week, if the decoders still don’t come in, I may place another order on a different website, or worst case, start trying to hack the correct decoders (which we have, but are through-hole components) onto the SMD pads.
Darwin Torres’ Status Report for 4/2
With the PCB and components finally in our hands, I worked with the team in soldering components onto the PCB. Unfortunately, progress has been slowed due to a mixup with decoders, but other than that, we are starting to look good on the hardware aside. In addition to this, I continued working with Matt on the Arduino-Python integration. Our preliminary communications tests have been successful, and we are now focusing on creating a simulated test suite that mimics physical input. Once we have the hardware setup and integrated with the Arduino, we plan on updating this test suite to take in real inputs from the hardware. Other than the one setback we have due to having to order new decoders, I feel that I am on track. Any progress lost due to the decoders will be made up with the slack time we have. Next week, I will continue to help my team in finishing the PCBs and setting up our interim demo. Matt and I will continue our “virtual” testing and bug squashing as we wait for the hardware to be ready.
Team Status Report for 4/2
This week the PCBs finally came in, and we performed a lot of team work since we worked together on soldering the components. However, one issue came up, which is that the wrong decoders had been ordered, so we are now waiting for the new ones to come in so that we can finish assembling the PCBs. The most significant risk right now is the arrival time of the decoders since we cannot move forward with physical testing until these arrive. One mitigation plan that was developed this week was to create more advanced software tests that can simulate physical data. This should help the debugging process once the physical testing begins, and this is important since the physical testing is probably the most time consuming component remaining. No changes were made to the design of the system this week. As far as the schedule, as long as the decoders come in soon, nothing should change. As long as they are delayed, everything else will be pushed back, and the new software testing will fill the gap.