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.
Matthew Kuczynski’s Status Report for 4/2
With the PCBs finally coming in, I spent the beginning of the week with my team soldering the components onto the boards in TechSpark. This involved placing the stencil onto each board, spreading solder paste onto each stencil/board, manually placing each component, and placing the boards in the oven. Later, Darwin and I tested the communication from the Arduino, through my subsystem, to the VM that he is testing on, which worked successfully. Then, we began designing a series of tests that will allow us to test the detection algorithms and touch functionality. The idea of theses tests is that rather than getting physical data (since this is still not ready), we will randomly generate realistic data that can be detected, categorized, and sent to the touch functionality. I feel that I am on track, and although the delay on the decoders shipping has shifted the schedule back a bit, our slack time should allow me to still finish on time. Next week, I plan to finish these tests and debug the software with Darwin, and to work on the soldering once the decoders come in.
Matthew Shen’s Status Report for 4/3/22
This week was dedicated to PCB construction. Unfortunately, our progress was slowed since I ordered the wrong decoders for our PCB. However, with regards to what was successful, our PCB header pins line up perfectly, so when we solder them in, the frame should be perfectly rectangular. Additionally, when a test was run with the wrong decoders (active low instead of active high), the logic seemed correct in that all of the LEDs that were expected to be on were off and vice-versa. This suggests that once we receive the correct decoders, the particular frame we tested should work as expected. Another thing that went well was the soldering process in general. All of our components fit perfectly on their pads, and the stencil-oven combination has worked flawlessly. This coming week, we hope to get the new decoders on Monday so that we can get at least one pair of edges working for our demo on Wednesday. If that pair of edges functions appropriately, we may try to have the whole frame up and running by Wednesday. My task for this week will mainly be soldering and hardware debugging. We are still on schedule to finish in time.
Matthew Shen’s Status Report for 3/26
Towards the end of this past week, we finally received the parts for the PCB and the PCBs with stencils themselves. One of the tasks I did this week involved running tests to estimate the appropriate resistance needed to be put in series with the LEDs in order to run 100mA current through each diode. When I placed the order, I had ordered a resistor with a quarter the ohmage as the one used in the unit tests with just one LED at a time (since we are illuminating up to 4 100mA diodes at a time). Then, I ordered a couple of resistors with +/- 1.5 Ohms in case the PCB traces introduce more wire resistance than in our tests. Since we only have a couple of these high-power resistors to place, it shouldn’t be too much of a problem to desolder the resistor if it is too resistive or not enough. Additionally, while the LEDs we use are rated for 100mA of constant current, they can theoretically safely handle 1A of current so long as they are pulsed (which is our mode of operation). So, we should be able to run our diodes comfortably with all this in mind. Next week, we will begin soldering and frame assembly. I believe this puts us right on schedule to finish our project in time.
Darwin Torres’ Status Report for 3/26
This past week, Matt K and I commenced the integration between the Arduino data processing and Python Screen control interface. Time has been spent understanding how to communicate between the Arduino and our Python interface via USB, which would allow us to send touch control requests to the OS directly from the Arduino. We have a plan outlined and have commenced simple tests for communicating touch type and position. As we wait for the hardware subsystem to be completed, testing will consist of creating dummy coordinates on the Arduino and sending certain commands to the OS through the Python interface. To confirm that the observed output is accurate, we compare with touch control requests sent from a local Python test script. Next week, I will get together with the others to solder the components onto our PCB and hopefully start testing our hardware subsystem. With the slack time we have and the progress I have made, I feel that I am on track with the schedule.
Matthew Kuczynski’s Status Report for 3/26
This week, my main focus was to continue the software integration. As I continued to combine my software with Darwin’s, I realized that some major decisions about the overall software design needed to be made. Therefore, much of the work that I did this week involved overall planning and design of the project’s software system. The biggest question was how exactly a touch event would be communicated to the screen control software. In the end, I chose to design a system where after subsystem B detects the touch type and position, both an event type and screen position are communicated to subsystem C. Most of the time, the event type will be “no touch”, in which case the position can be ignored. Overall, I think that I am on track to finish my parts with some slack time built in, and the fact that the PCB + components came in means that we can move forward as a team. Next week, my focus will shift to the soldering that needs to be done with the PCBs, and there may be a chance to do some physical testing near the end of the week depending on how the soldering goes.
Team Status Report for 3/26
This past week, we have continued integration between subsystems B (Arduino data processing) and C (Python Screen Control Interface). This will allow us to send touch control requests to the OS from the Arduino via USB. Integration between subsystems A and B will begin on a later date, as we still need to finish the PCB and frame. We have been held back on the arrival of our components, but fortunately we finally have them on our hands and are eager to start getting our hardware subsystem ready. Next week, we plan on starting the assembly of subsystem A by dedicating our time to PCB soldering and finalizing frame design, potentially also starting frame construction. Given the slack time we gave ourselves, and our ability to shift focus on the software as we waited for parts, we feel we are currently on schedule with our tasks.
Darwin Torres’ Status Report for 3/19/2022
This week, I continued testing for the screen control interface. These tests have all been through software, emulating requests via python scripts. Once we have an initial frame set up, we can start testing directly with physical user input. While we wait for parts to come in, software integration is starting to commence, as Matt’s Arduino subsystem starts to join with the Python touch-control interface. This would allow us to start testing the sending of requests from the Arduino via USB. In the coming weeks, I will help with the PCB once our parts arrive, and until then I will be able to allocate most of my time to further testing, which should hopefully result in a smoother integration experience and less debugging once we are able to conduct our physical tests. On the software side, I feel that I am on schedule, though on the PCB I am a bit behind, but this is because we are still waiting for parts. Overall, this isn’t an issue as I am able to put more time into tweaking my scripts as I mentioned before.