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.
Matthew Shen’s Status Report for 3/19
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.
Matthew Kuczynski’s Status Report for 3/19
This past week, I began working on the finger detection algorithms, which were explained in some depth in the design review report. This is somewhat difficult without being able to physically test, so this is mostly a framework for now. Additionally, I began integrating my portion of the software with Darwin’s, which is combining subsystems B & C from the report. Next week, I plan to work on the frame design and continue the integration of the two software systems. Additionally, I will work with the rest of the team on the PCB when it arrives, which should be soon. The majority of the work that I still need to contribute individually on this project involves tuning the detection algorithms through physical testing. So far, I feel that I am on schedule, but I will need the PCB to complete most of the work that still needs to be done.
Design Review Documents
Gantt Chart Update 3/5/22
Darwin Torres’ Status Report for 2/26/2022
This week, I made additional changes to the screen control interface. Previously, the main functionality that was added was the ability to send a request to the OS to emulate a touch tap. That is, given a pair of (x,y) coordinates, we emulate a finger pressing down and then immediately lifting up. However, these two steps are actually separate events that are sent to the OS – finger down, finger up – we just combined them into one quick event. If an extended period of time passes before “finger up”, Windows applications can register this as a finger hold. Thus, changes had to made so that we can support these touch-specific gestures. This was done by updating the interface to support three requests to the OS: finger down, finger up, and update position. The “update position” allows us to change the position of the finger while it is down, simulating a drag. These requests have been tested using a test script in python and result in successful calls individually, however the drag mechanism still needs to be ironed out. Overall, everything is going according to schedule, and I hope to conduct more testing in the coming weeks as we move on to integration between the hardware, Arduino, and Windows. Once integrated, we can conduct better tests as we will be able to use our fingers to directly interact with the UI. Unfortunately, current tests do not tell us much about usability as everything is simulated without physical interaction, so I am excited about these future steps.
Team Status Report for 2/26/22
Our biggest goal right now is to finish all of the PCB development and order the PCBs before spring break so that we can begin soldering and testing with the actual PCB once classes resume. If this is not completed before break, it is going to cost us about two weeks, so we are considering this the biggest risk to our project right now. We plan to have all three group members working on this task next week to ensure that it is completed.
Overall, no major changes have been made to the design. If anything, the biggest change is the choice to move away from the pyFirmata library for the Arduino-Python interface and to the serial library. This change was necessary due to the fact that each photodiode needed 10ms to be read, which will be far too slow for MVP goal. Moving forward, we will test different baud rates with the serial library to see how fast the system can perform.
Right now, the schedule remains the same since we are keeping up with the tasks on our Gantt chart. Overall, we feel that we have been making good progress and our project is on task to be completed successfully.
Matthew Kuczynski’s Status Report for 2/26/22
This week I continued my progress with the Python-Arduino interface and worked on routing the PCBs. Last week, I learned that the pyFirmata interface that we intended to use would not be fast enough to loop over all of the LEDs, so I spent a large portion of this work exploring alternative options. Eventually, I discovered that uploading the code that loops over the select line values to the Arduino is unsurprisingly much faster than using pyFirmata. In order to read the values from the Arduino, I developed a script using the Python serial library that did string parsing to get the digital values and the select value. The PCB routing task proved to be tough due to width of the PCB, and the Auto-router was unable to complete the task on its own. While some of the PCBs have been completed, the task remains ongoing. Overall, I think that I am on schedule since I am keeping up with the tasks in the Gantt chart. Next week, I plan to continue working on PCB layout and the breadboard-Arduino integration.
Matthew Shen’s Status Report for 2/26/22
This week, I laid out another PCB for the frame. Additionally, I ran some more thorough tests to determine the rise and fall times of the photodiode sensors. Some updates to our circuit were also made to try to optimize it for speed. Since the photodiodes are attached to very large resistors, (now 200 kOhm down from 300 kOhm) the time constants are actually non-negligible. With the 200 kOhm resistors along with the 370 pF input capacitance of the MOSFET buffers and 18 pF for the photodiode capacitance, this equates to a time constant of 77.6 microseconds. Realistically, if we were to use a MOSFET buffer stage for our final implementation, the input capacitance wouldn’t need to be nearly this large, but since these FETs were all I had on hand, I needed to make do with them. When tested under the scope, it seemed like the rise and fall times were actually closer to 72 us, but it was useful to see that the hand calculations were very much in the ballpark of reality.
As for changes to our circuit, we have opted to remove the MOSFET buffer stage. After talking to Dr. Fedder about the issue mentioned in last week’s status report, we realized that the muxes were likely designed with NPN transistors, which was an accidental purchase on my part. I ordered CMOS multiplexers this week, which should allow us to feed the anodes of the photodiodes directly into the mux inputs. Another enormous benefit is that the input capacitance of these CMOS muxes is around only 10 pF. Assuming the continued consistency of my hand calculations, this would equate to a time constant of around 5.6 us. What this means is that a single sweep for the entire array of LEDs/photodiodes could theoretically take just 170 us. That means it will take less time to sweep the photodiodes than it will take to send that data to the computer over USB-serial, which is great news for our design requirements.
In the coming week, I hope to have our PCBs ready to order with the hope that they will arrive by the end of spring break. I will also test our updated circuit plan when the muxes arrive.
Darwin Torres’ Status Report for 2/19/22
This week, I continued with developing the screen control interface. Originally, we were going to register taps detected with our sensors as mouse clicks using one of the libraries mentioned last week. However, we found that we can instead send touch control requests using Microsoft’s Win32 C++ API. We are still using Python, but taking advantage of the builtin ctypes library to create wrappers that directly call the Win32 C++ functions. The provided methods for touch manipulation support not only single taps, but also drag and multi-touch gestures, unlike the cursor-control libraries we were looking at before. This makes it more intuitive to add support beyond single-contact touches. I developed a simple interface for emulating a tap at a pair of (x,y) coordinates and testing found that the tap was successful and perceivably instantaneous. Libraries such as PyAutoGUI can take up to hundreds of milliseconds to complete a single mouse-click which would hurt the user experience. Using this new method, a touch was registered in less than a millisecond, giving us more room to work with on the hardware side as we work toward a goal of an overall response time of less than ~150ms. Overall, I am ahead of schedule, giving me time to test out simulating drag and learn more about the additional capabilities of the API. Next week, I will help in starting the breadboard/Arduino integration, while also possibly being able to start the Windows integration early in our schedule.