Carnegie Mellon ECE Capstone, Spring 2022. Members: Matthew Shen, Matthew Kuczynski, Darwin Torres Romero
This week, we worked mainly on optimizing the software. I mainly worked on trying to better align the LEDs on the hardware side as there were some instances of misalignment randomly appearing. Next week, I plan to take an oscilloscope to each LED to ensure they each exceed the VIL of the muxes. I will also be working to finish our poster and demo video this week.
We are on schedule as we have completed MVP and are working towards our reach goals now.
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.
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.
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.
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.
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.
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.
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.
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.
Over the past week, our team has focused on finishing the PCB and software testing. We are falling a little behind schedule on the software side since we still do not have a working concept of the Arudino and Screen Control integration. As we wait for the PCB this week, this should be our main task. Additionally, since the PCB is taking a lot longer than advertised, we are a week behind on our soldering plan. Fortunately, our Gantt chart has ample slack time to work with for our current standing. Our updated schedule will have all of our plans shifted back by a week with the above tasks inserted into this upcoming week.
Over the past couple of weeks, I have focused on finalizing and ordering the PCB. A lot of the PCB work involved designing a way to connect all of our PCBs electrically and mechanically. We intend to kill two birds with one stone by using through-hole connector pins to act as a way to fasten the boards together, while also passing signals from the Arduino along to the top and left edges. Since we have at most 2 tries getting the PCBs right, I spent a significant deal of time verifying the dimensions of these so that we should only have to worry about electrical problems if another iteration is necessary. We are still awaiting the board, but I also have yet to place an order for the through-hole components.
I also purchased solder paste as we have updated our PCB assembly plan to use a PCB stencil and oven to place our components onto the board. I feel like we are on schedule, although the PCB’s arrival will dictate our schedule going forward.