Posted on

Matthew Shen’s Status Report for 4/23

This week, I finalized the hardware. In the picture below, the frame and the Arduino can be seen along with the laptop to be used for the demo. At the moment, we have simply taped the frame onto the screen.

More specifically, I had to work on the long edges this week to complete the frame, as the short edges were tested last week. Unfortunately, after we had already soldered all of our components to the long LED frame, I discovered during testing that JLCPCB had misprinted our board (seen under the microscope below. Fortunately, although there appears to be overlap in the image, there was no short between the wires, so all that was needed was a grueling process of hacking jumper wires between the disconnected nodes. In total, 3 traces needed repair.

There should be 6 equally-spaced, parallel traces. Observe bottom-left for error.

 

I am now officially ahead of schedule, as all of the hardware debugging has been completed. I can now dedicate my focus to helping on the software end. I will mainly work on optimization going forward, as there are several pieces of the code that I know could be accelerated using bit arithmetic. I also may figure out a better way of securing the frame to the laptop than with just tape.

Posted on

Team Status Report for 4/23

This week, we connected all edges of the frame and spent most of our time debugging the hardware and software, as well as collecting data for measuring our performance against our use-case requirements. Beginning with the hardware, one issue we encountered was a misprint in the bottom PCBs. We were able to hack around this by soldering wires onto the board to fix the broken connection. Before we started testing our software with the frame, Matt S conducted some final debugging and checks to make sure there were no issues with the hardware.

Once the hardware was ok to go, we attached the frame to Matt S’ laptop and began testing of Matt K’s updated Arduino code, which controls the LED/Photodiode pairs and sends data about which pairs are activated to the python backend via USB serial. We encountered some bugs, but eventually after some squashing we were able to confirm that the control signals and output data were correct.

Afterwards, once we confirmed the Arduino subsystem was well-integrated with the hardware, we began our first true test of our entire system through a python script that used the data sent over by the Arduino to calculate coordinates and send commands to Darwin’s updated Touch Control subsystem. At first, a few bugs had came about due to a small miscommunication about the updated interface, but we were able to quickly fix them. Once we were passed that, we finally got our first glimpse at Touch TrackIR in action! Physical finger taps, holds, and drags on the screen were successfully translated to the expected touch inputs in the OS. We were able to click on links, close tabs, move windows, and scroll through webpages. The smoothness of the experience is acceptable, but we still feel there is room for improvement.  For example, we can reduce latency by increasing baud rate, removing print statements, and by simplifying the structure of the data that is being used in our coordinate calculations to eliminate unnecessary loops.

Overall, thanks to the progress this week, we put ourselves perfectly on schedule. Next week, we plan on constructing a cover for our PCB frame and adding support for double taps to allow us to perform “right clicks”.

Posted on

Matthew Kuczynski’s Status Report for 4/23

This week we worked on integrating our subsystems, so much of my work involved testing the Arduino and Python serial code that I had finished last week and debugging it. Previously, I had not been able to test my code because the PCB wasn’t finished, so this week I was able to get it working properly. Then, I worked on getting the testing metrics for our requirements so that they could be reported in the final presentation. Since we have our MVP working, I am definitely on track. Next week, I will now work on adding additional features to our project like multi-finger functionality and improving the speed of the single touch function.

Posted on

Darwin Torres’ Status Report for 4/16

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.

Posted on

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.

Posted on

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.

Posted on

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.

Posted on

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.

Posted on

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.

Posted on

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.