Progress Report/Engineering Project Journal for Nihar Mehta

Week 15:

Date Reported: 04/19/2024
Start Time: 10:00am
Work Time: 1 Hour
Today, we had our final demo at 10:30am, so I went in 30 minutes before to make sure that we were ready to demonstrate our functionality. Last night, when we were trying to get as much functionality working as possible, we were running the program through my laptop, so I sent the main file of our program to the workbench computer to use during our demonstration. However, when I tried to run the same program through the workbench computer I did not get the same result I was looking for. Thus, for the demonstration, I would just run the program through my laptop.

When the time came, we demonstrated whatever functionality we ended up being able to implement. We did not end up getting as much implemented as we would have liked in our final system. One of the big things that we missed was the functionality of two player consoles. This was due to incomplete progress on the USART communication as well as the fact that our LCDs burned our earlier in the week. As described before, we ended up going with a player vs. CPU model since we only had one functioning console. The results of the demonstration are shown in the two images before with notes on the project description and the PSDRs.



Date Reported: 04/18/2024
Start Time: 6:30pm
Work Time: 10 Hours
In the evening, we went in to lab to put in a final bit of work before our demonstration. The packaging for one of the consoles was ready. The project box insides and the overall package can be seen below.



The rest of the night, the plan was just to work on the software and get as much of the gameplay implemented as we could. First off, we started with attempting to get SPI working with spare LCDs that we had from our ECE 36200 kit. These are a bit different and not as big as the LCDs we had planned on using, but if we could get this figured out, it could be very good for our demonstration. We spent a good amount of time on this, comparing the data sheet for this LCD with the previous LCD and trying to figure out how to get SPI configured through CubeMX and with the HAL libraries. However, after a lot of trying things out, we decided to move on to finishing implementing a CPU version of the game with just LED outputs.

I finished the functionality between the keypad and LEDs earlier in the week, so now what was left to be implemented was what happens between player and CPU moves and at the end of the game.

The images below show the three main phases of the gameplay. The first image is what the player loads to. Their board will have randomly places ships (marked with green LEDs) and the upper enemy board will be blank with a green cursor (seen on the top left of the grid). The second image shows the middle of a game. The enemy grid can be seen with both red markers and yellow markers. Red markers indicate where the player hit a ship while the yellow markers indicate where a player missed a ship. Finally, the last screen shows the game win condition with all of the LEDs turning to green. If the player loses, the entire grid will turn to red.


Date Reported: 04/18/2024
Start Time: 11:00am
Work Time: 3 Hours
Today morning, we all wanted to meet to continue working on getting our project as integrated as possible. We still had some work to do on the physical packaging of the product. This involved both cutting out the right holes in the project box as well as assembling another LED matrix. The image below shows the LED matrix that I soldered together. It was a pretty simple component to solder, but just took some time due to the number of connections to be made. Once this second array was soldered together, we now had both of the arrays for one of the player consoles. I took some time to stick the arrays to the battleship board we were using for the packaging. I had to make sure they all fit with even spacing.


When we came to lab today, Derek mentioned that the second LCD that we had also stopped working. We unfortunately did not have any extra LCDs, which was a major issue since we need two in order to have two user consoles. After some deliberation, we decided that since the demonstration was tomorrow, we would have to continue with just one console. In order to accomplish this, we decided that it would be best to implement a CPU to play against the single player to at least make the game playable. This would replace the need for the second player console and while we won't get all of the points in our demo, we could at least demonstrate most of the functionality.

While the others were finishing up with the packaging of the product, I continued to work on the software for the program. I spent some time reformatting some of the code I implemented earlier so that it would be easier to use later on. For example, I converted the keypad functionality to functions that I could call on later if needed elsewhere in the code. I am going to be back in lab later in the day to get as much of the software working as possible before the demonstration tomorrow.


Date Reported: 04/17/2024
Start Time: 6:00pm
Work Time: 3 Hours
Today, I spent time doing work on the draft of our final senior design report. This report consisted of a team component and individual components for each team member. Essentially, this document is a reflection of the work accomplished over the semester, both as a team and individually. This included various aspects, such as defining the purpose of the product, constraints, a variety of global, public, societal factors, as well as a final status.

In terms of the individual portion, the goal was to describe individual contributions, new knowledge acquired, ethical responsibilities, etc.


Date Reported: 04/16/2024
Start Time: 5:30pm
Work Time: 2 Hours
Since earlier I was able to figure out a way to get the LEDs to at least light up on the PCB, I continued working on figure out why it would get stuck in a loop after one key press. Navigating to where the program would get stuck, I saw that it was after the PWM signal is sent and it is then waiting for a response indicating that the transfer is complete. The confusing thing with this is that if I use this same send function in the while loop of the main function, there are no errors with this. It is only when used through an interrupt that we never receive a response from the DMA. Thus, I tried to just comment out the code where it waits for a response and that ended up fixing the issue. I was now able to navigate left and right (as I was trying to before). It was a bit jumpy, so when I would press right or left, it would sometimes end up skipping an LED, but this was not a major issue.

Now, the next thing to do was implement the “up” and “down” functionality of the keypad. For the left and right functionality, I just had to increment/decrement the LED number by one to go either left or right. For up and down, I would have to increment/decrement by 10 based on how the grid was set up. This was just a minor change and was implemented pretty quickly. After this, the main edge case that I had to manage for the cursor was if you try to go past the boundaries of the LED grid. In this case, I just made it so that the cursor would wrap around to the other side. For example, if you are on the right most side of the grid and press right again, the cursor would go the left most LED in the same row. With this final bit of functionality, we are now able to navigate the entire grid with the keypad.

One more quick function I wanted to add was the ability to select a position to “hit” using the center button on the keypad. Essentially, this function checks if there is an enemy ship in the location and marks it based on the result. If there is a ship there the LED will be red and if there isn’t a ship there, the LED will be yellow.


Date Reported: 04/16/2024
Start Time: 10:30am
Work Time: 3 Hours
I went in during our usual ManLab time today to continue working on the project and integrating the components. Our demonstration is going to be on Friday, so there is not a lot of time left. I was able to get the keypad partially interfacing with the LEDs last time, but today I wanted to work on getting the LCD and LEDs working simultaneously. Currently, the LEDs and LCD are only able to work separately. Additionally, it seems that interfacing with LEDs is just not working on the PCB, which is why last time I switched over to my test breadboard to at least figure out the functionality. When I run the code on the PCB, the keypad and LCD work just fine and even though the LEDs are receiving power, they have no output. I tried a variety of combinations of the peripherals, to see if anything would work. Even if the keypad and LCD were both disabled, the LEDs still did not light up. It could be possible that the way the micro is configured, somehow writing to the LCD is always taking priority over sending the PWM signal.

Derek mentioned that one of the LCDs was not outputting and was likely fried, so I tried to use that and see if the way the LCD was connected to the PCB was causing issues. The way the working LCD is connected to the PCB is correct, since it is displaying correctly, but somewhere it may be conflicting with the LED output. I fiddled around with the pin connections and the LEDs lit up just once. I tried to see what pin configuration allowed for this. Somehow, connecting two of the data pins to VDD and VSS allowed the LEDs to turn on. No other combinations of the pins would work. This is definitely an odd situation and not an optimal solution to getting the LEDs to work. Later in the day, I plan on coming back to lab to implement the functionality of the keypad interfacing with the LEDs now that there is some way to have the LEDs light up.

Week 14:

Date Reported: 04/12/2024
Start Time: 6:00pm
Work Time: 3 Hours
Since I wasn't able to finish what I was working on last time, I went back to lab to continue working on the interfacing between the keypad and the LEDs. I started off by switching the timer for the LCD from TIM1 to TIM3. TIM1 was required for using the DMA to generate PWM for the LEDs and this required different parameters than for the LCD. TIM3 had theappropriate output needed for the LCD, so this shouldn't be an issue. One I adjusted all of the parameters for TIM3 and TIM1, I then tested the LCD code to make sure it was still functioning. As before, when the program started up, the LCD displayed the correct messages while running on TIM3 instead of TIM1.

Now, for implementing the LED output along with the rest of the system, I made sure the TIM1 parameters were correct and added the code I had from before to output from the LEDs. When I tried running this code, the LCD and keypad worked just fine, but there was no output from the LEDs. I tried messing around with parameters here and there to try to get them to turn on, but wasn't able to do so.

I switched gears over to my test breadboard to try to replicate the program with the test microcontroller I have been using. This required reformatting the code to work with the keypad pinouts that I had set up there (connected to different pins on the test micro compared to the PCB micro). I tried to set up a program where using the keypad, I could “traverse” left an right on the LED strip. The video below shows the result:


I have the “2” key set up was “shift left” and the “8” key set up as “shift right”. As seen in the video, when I press “8”, the green LED on the first spot on the strip shifts one to the left. However, when I tried to press either key after that there was no change in output. I saw that in the debugger, the code would get stuck in a loop waiting for the signal to indicate that the data has been sent through the DMA. This will be my goal to work out next time I get into lab.

Date Reported: 04/11/2024
Start Time: 6:00pm
Work Time: 3 Hours
I went in to lab today to continue working on integrating the peripherals. My goal now is to get the keypad, LCD, and LEDs working simultaneously. Getting the LCD to work continuously with the keypad inputs was an issue last time, so this time I was going to try to get the keypad outputting to the LEDs instead. Getting the keypad interrupts set up was done using this site as reference: 4x3 Keypad with STM32 Blue Pill using STM32CubeIDE. While we have done interrupts in the past, this guide helped in figuring out how to use CubeMX and the HAL libraries to do so.
The first issue that I ran into was that I was not able to get the keypad properly functioning on the working PCB without running the LCD initialization. This was quite confusing since these two functionality should be able to operate separately just fine. The keypad inputs displayed the correct outputs on our debugging LEDs when the LCD was also initialized, but if the initialization line was commented out, the keypad interrupts were no longer recognized. For the time being, I left the initialization there and started working to reformat the code to allow for the LCD and LEDs to run alongside each other. I realized that currently, the LCD was running on TIM1, but this timer was needed for the LEDs in order to utilize the DMA and PWM. Thus, I would have to switch the LCD over to TIM3 to free up TIM1. Unfortunately, my laptop ran out of battery before I could do so, so I will continue this next time.

Date Reported: 04/09/2024
Start Time: 9:30am
Work Time: 2.5 Hours
Today in ManLab, our first goal was to make sure we could get our third preliminary PSDR checked off. Last week we were able to get two of them, so it was important to get the third this week. The PSDR we wanted to get checked off was for our keypad interfacing, which was pretty straightforward. While we were waiting to speak with the course staff, I started looking into the issue I was having previously with one of our PCBs where I couldn't communicate with it through the ST-Link. It turns out that the problem with the PCB was that there were issues with the SWDIO and SWCLK pins on the ST-Link header. When not in use, one should be pulled high and one should be pulled low. However, it turns out that they were both being pulled high, indicating an issue in the connections somewhere. While we will continue to try debugging this PCB, we decided that since we have an extra board left we would assemble that so that we can continue working on integration.

When the course staff came around to our team, we discussed the main concerns we had at this point for our project. While we have components working separately, integrating all of them together is going to be a challenge. We can communicate with all of the peripherals (keypad, LCD, and LEDs) and we also have some of the software for the actual game logic. Additionally, we demonstrated our keypad interfacing in order to check off that preliminary PSDR. With this preliminary PSDR, the initial goal was to make it so that on each keypad press, the respective “key name” would display on the LCD display. For example, if the top left button on the keypad were pressed, it would display “To Left” on the display. This would work but only for the first button press. Afterwards, the program would get stuck and did not take new keypad inputs unless the micro was reset. Thus, we had to use our debugging LEDs to show the interfacing with our keypad.

Week 13:

Date Reported: 04/06/2024
Start Time: 11:00am
Work Time: 3 Hours
I went in to lab today to see if I could figure out anything new about the issue I had run into on Thursday with connecting to one of our PCBs. Before that, I wanted to get a video of the LED program I had for the preliminary checkoff, but ran into a new issue there. I plugged into the PCB that worked on Thursday and was able to send the program, however, I was not getting any output on the LEDs. This was very odd, since I had not made any modifications to the program and there was nothing changed with the PCB either. I have attached a video showing the LED program I used for the preliminary checkoff, but this is running off of my testing board, not the PCB.


After this, I went back to the PCB that I wasn't able to connect to through the ST-LINK and ran into the same issue as before (with the “init mode failed” error). I tried to double check the PCB assembly to the PCB that I can communicate with, but did not find any outstanding issues on that end. Additionally, I made sure that all of the various connections on the PCB were correct, including continuity to peripherals as well as the correct power on different aspects of the board. The micro was receiving 3V just fine while the other components received the 5V, as expected. So, from the power perspective everything seemed to be fine. Even the programming header looked like it was attached just fine. After all of this debugging I still was not able to resolve the issue on my own. I will need to get a second opinion from my team on this.

Until then, I just continued to work on my A11 assignment. While doing research on the environmental impact of PCBs, I came across the following articles: "The Environmental Impact of Circuit Board Assembly", and "Guide for Recycling Printed Circuit Boards". These gave a good overview of the sourcing of various components of circuit boards as well as some possible recycling methods for these various components.

Date Reported: 04/04/2024
Start Time: 6:00pm
Work Time: 3 Hours
Today, after lecture, I did some work on the individual assignment for the week, which is A11 - Ethical and Environmental Analysis. This week in lecture, we have talked about various ethical and environmental considerations that go into engineering projects. The goal with this assignment is to perform an analysis of the environmental impact of our project, as well as look into the ethical challenges that our team has to resolve in the process of bringing our design to the market.

The first part of the assignment involved analyzing the environmental impact of our product in the various stages of its lifecycle from manufacturing to disposal. For example, there are key environmental considerations for something like a PCB, which uses many hazardous materials during manufacturing and is hard to dispose of at the end of its life. As discussed during lecture, there are various acts and public policies that aim to reduce environmental impacts of electronic devices. One of the biggest concerns is that E-waste accumulates very quickly and is a type of waste that is very tough to recycle. There are key steps engineers can take to approach this issue, which are eliminate, reduce, reuse, and recycle. These steps will be a part of how I address environmental impact concerns arising from our project.

The second part of the assignment requires digging into the ethical challenges that come with our project. This aspect is a little less straightforward because while there are codes of ethics that engineers must follow, there are also subjective concerns when it comes to ethical dilemmas. Since our project is a simple board game with small electronic components, the main concern is just keeping users safe from harm from any of these components. This would include adding warning labels to avoid the device from being used in wet conditions where the electrical components could be shorted and cause electrical shocks to the users. The product failing is less of a concern, since it will just cause the game to stop working and not cause direct harm to the users. On the other hand, a product like the Ford Pinto, which was discussed during lecture, would have greater concern of harm to the users in the case of a failure.

Date Reported: 04/04/2024
Start Time: 9:30am
Work Time: 2 Hours
Since I wasn't able to get the preliminary PSDR checked off on Tuesday, I came in today to do so. I was getting the PCB connected to my computer and tried to run the program I had set up to show the LED interfacing, but when I tried to do so, I was running into the following errors:

I tried a couple more times, as well as tried power cycling the micro, but clearly there was an issue between the ST-Link and the microcontroller.
After this I tried to connect to the second PCB we have assembled and I was able to run the program just fine. This is definitely an issue we will have to address as soon as possible because we need to be able to program both of the PCBs. For now, though, I just needed one PCB to get the preliminary PSDR checked off. I called Joe over to show him the program I had set up to show the interfacing between the micro and the LEDs and was able to get the preliminary PSDR checked off. I forgot to get a video of the LED's operation, so I will have to do that next time I go in. It was just a simple program that had all of the LED's red by default and they would each flicker green in sequence.

Date Reported: 04/02/2024
Start Time: 9:30am
I was not in ManLab today morning, as I woke up ill. I was prepared to get our LED preliminary PSDR checked off, but will have to do that when I come in next.

Week 12:

Date Reported: 03/29/2024
Start Time: 3:40pm
Work Time: 3 Hours
Today, I went in to lab to continue working on PCB assembly. Derek double checked my PCB and realized that I had put the microcontroller on the wrong way. I made a mistake in determining which pin was pin 1, so the microcontroller is currently oriented 90 degrees off. In order to fix this, I requested assistance from Joe on the best way to remove the chip. He showed me how to use the ChipQuik to melt all of the solder and slide the microcontroller off the board. From here, I could have attached the new microcontroller to the same PCB, but I decided to just start on a new one since we have a couple of extra PCBs. I realized that the LD117 chip that I had attached on the previous board was the incorrect one (meant for 5V output rather than 3.3V), so I thought it would just be better to start from scratch and save the old PCB as backup later on.
From here, I followed the same process to assembly the PCB as I did last time (from the power system, to the microcontroller system, to the peripherals). These components that I soldered on seemed to come out cleaner, since I had already done this process once. This time, I made it one step further and attached the programming header, as well as the reset switch and the resistors needed for the keypad. Having these components attached will at least allow us to talk with the final microcontroller. My next steps will be to communicate with this micro, as well as finish attaching the peripheral components to the PCB. The image below shows the front side of the new PCB.


Date Reported: 03/26/2024
Start Time: 9:30am
Work Time: 2.5 Hours
In ManLab today, we started by discussing our power situation. We have the system read on the PCB, but need to find a compatible power bank that will have enough output. This proved to be somewhat challenging due to the high current requirement from the LEDs. During our talk with the course staff, we showed the progress we had made with the PCBs. We talked about our big concern about the fact that we still have a lot of software development to do. After this, one of my goals was to fix the issues I have been having with the communication with the LEDs. I asked Tyson for assistance with this and through various debugging attempts, there were a few minor changes that we made to the program I was testing with. This seemed to improve the stability issue I was having with the LED output somewhat, but there is still more refining I need to do to completely fix the issue.

Date Reported: 03/25/2024
Start Time: 4:30pm
Work Time: 2 Hours
Today, Derek and I went in to lab to start assembling our PCB. I first started with the power system on the PCB. This included the barrel jack connector for power input, the low voltage regulator to drop down the voltage to 3.3V for the microcontroller system, and associated discrete components. I had already practiced with a couple of components last week, but it still took a little bit of time to get going with the soldering. The front and back of soldered power system can be seen below.

Once that was done, I tested the system by inputting power through a wall connector that supplied 5V. We saw that the heartbeat LED turned on as it should, so this system seemed to be working correctly. After this, I moved on to the microcontroller subsystem on the PCB. This system included the microcontroller, a silicon oscillator, decoupling capacitors, and other discrete components as needed. The results can be seen in the images below (left image is the front side of the PCB and right image is the back side (under the micro)).

Soldering the various discrete components went pretty smoothly. Getting the microcontroller on took a bit more effort. I approached this using the drag soldering method. This worked out for the most part, but I ended up with a couple of solder bridges on each side of the microcontroller. This took a bit of time to resolve, but with enough flux, I was able to get rid of the bridges. The image below shows the full front side of the PCB.

Week 11:

Date Reported: 03/21/2024
Start Time: 5:40pm
Work Time: 1 Hour
After lecture today, I went to lab to spend some time practicing surface mount soldering before attempting on our PCB. Before starting on a spare PCB, I reviewed two of the videos linked on Brightspace: one for drag soldering and another for other components (specifically resistors). One of the key things stated in both of the videos was the use of a good amount of flux on the pads. This should make it really easy to attach the various components. The first components I practiced on was a couple of resistors, which can be seen below.

I attached one side of the resistor first in order to keep it in place and then added a little bit of solder to the other side. I think it turned out decent, but I could have used a little less solder. The second type of component I practiced on was an IC. I tried to use the drag soldering technique for this and the result can be seen below.

The chip looks slightly crooked, but it looks like it attached well. As long as I had a good amount of flux, the solder flowed quite easily and I was able to drag across the pins. After this, I practiced on a similar chip that had smaller pins that were more densely packed. The process for this component was the same as for the previous chip. The result can be seen below.

This one turned our more evenly than the last chip. I used less solder to make sure there was just enough for each pin without the solder balling up. As long as we have two people working on the PCB at once, it should be pretty straightforward to put the PCB together. Over the weekend, I plan to continue working on the interfacing to get some demonstrations ready for the preliminary PSDR checkoffs.

Date Reported: 03/19/2024
Start Time: 9:30am
Work Time: 2 Hours
Today in ManLab, our PCB was delivered to our bench. The front and back sides for the PCB can be seen below.

A quick visual inspection of the PCB didn't reveal any issues, so the next big goal would be to get all of the components together that would be soldered onto the PCB. We were the first team to speak with the course staff today and discussed how much work was left in our project. We still need to finalize some of our interfaces between the microcontroller and the peripherals. Additionally, now that we have the PCB, we will need to get the components attached to the board. In order to house the PCB and peripherals to the Battleship board, we also need to order a project box with correct dimensions. This will basically house the PCB, the matrix keypad, and the LCB, while the LEDs will reside externally (on the actual Battleship game board). I found a possible box on Amazon (link here) seen below.

Derek and I plan to get at least one board put together by next ManLab, hopefully tomorrow. We don't currently have the barrel jack connector we need for power, so we may need to wait to get one in order to follow the suggested order of assembly for the PCB as defined in lecture. This process lists the power supply connection as the first step. Before that, I will try to practice on some test components so our PCB’s soldering goes smoothly.

Week 10:

I did not get to work on the project over the break.

Week 9:

Date Reported: 03/07/2024
Start Time: 6:00pm
Work Time: 1 Hour
After learning about important soldering techniques during the lecture today, I reviewed some of the videos that were posted for good soldering videos. While I have some experience with soldering in the past, it has mostly been wire to wire connections, or soldering a wire onto a pad (for example, with the WS2812B LED strip). Technique I believe is going to be most useful when soldering components to our PCB will be drag soldering. I have attempted to solder an IC onto a PCB a couple of times in the past, but it has not turned out great since I was attempting to do single pins individually with very little flux. Drag soldering seems to be an extremely efficient way of attaching components with a large number of pins, such as the microprocessor chips.

Date Reported: 03/06/2024
Start Time: 5:00pm
Work Time: 1 Hour
Yesterday, I wasn't able to go in to ManLab since I was feeling ill. Today, in the evening I reviewed the feedback that we received during our midterm design review. The following is the quantitative results from the responses:

It seems that the average score for each of the different components in our presentation was consistently around 4.50. There were a good number of recommendations on improving the PCB design that was presented, since there were a few key errors in the layout. One of the big errors that was pointed out was that most of the header pins on the layout were too large. Thus, they were taking up too much space on the board and would not be the correct size for the pins on the components. We plan to address these issues before we submit the final PCB order.

Week 8:

Date Reported: 02/28/2024
Start Time: 3:30pm
Work Time: 2 hours
Today, we met before our midterm design review to finalize the presentation and make sure everyone was prepared. I mainly worked on finalizing the electrical schematic and PCB slides. I made sure that the reviewers would be able to get a good view of the overall schematic as well as see the individual sections of the schematic by presenting different components based on their functionality in the system. At around 4:10pm, we got ready and headed over to our design review that would last from 4:30pm to 5:30pm.

Date Reported: 02/27/2024
Start Time: 6:00pm
Work Time: 2 hours
Since I wasn't able to meet with my team in the morning today, since I had my peer reviews at that time, I did some work on the presentation in the evening. I created slides for the different major components of our system and detailed some specs and alternatives to the devices we ended up choosing for our design. Additionally, I added an updated functional block diagram of our project's system into our presentation, which can be seen below. I added more information about the power system involved in our project, which was missing in the previous diagram we had. Our midterm design review is tomorrow, so we will have to keep working on finishing up the presentation.

Date Reported: 02/27/2024
Start Time: 9:30am
Work Time: 2 hours
Today, I had my two midterm design reviews. The first team I was supposed to review was Team 19, whose project is an NES hardware emulator. However, since this was the first day of midterm design reviews, the staff was running into issues with the AV system. By the time the issues were fixed, it was time for the second team, so the first team's presentation was moved to the next day. The second team I reviewed was Team 6, whose project was “BeaconCapture”. It was a pretty interesting concept where a drone is designed to follow a beacon at a certain distance defined by the user. The project has three main components: the drone, the puck-shaped beacon, and a handheld controller. It seems that this team has made good progress on their project in both prototyping, as well as software. Additionally, the PCB layout for each of the three components were well detailed in the presentation.

Week 7:

Date Reported: 02/23/2024
Start Time: 6:00pm
Work Time: 2 hours
Today, after the lecture, I started looking into the instructions and presentation layout for the midterm design review presentation. The main concern before our midterm presentation will be finalizing our PCB. While we have good progress on this end, there is still important work to be done in order to be ready for the presentation.

I started working on the initial slides of the presentation, including getting a presentation slide and adding some of our major components to the slides with details and comparisons.

Date Reported: 02/20/2024
Start Time: 9:30am
Work Time: 2 hours
At the beginning of ManLab, we met with the course staff to receive feedback on our PCB schematic. There were a few key recommendations made, such as modifying the decoupling capacitor setup, fixing our external clock design, adding pull-down resistors to keypad, etc.

Last week, I fixed the issues that I was having with the PWM timer on the microcontroller. At the start of the lab today when I powered up and plugged in the WS2812B strip into the microcontroller, I was able to get the output that can be seen in the image below.

While the expected output was a pattern of red, green, blue (repeated over the 11 LEDs), the actual output on the LEDs was quite inconsistent and was flickering. I tried to debug the issue by setting all of the LEDs on the strip to just blue, but even then, there was inconsistency in the output. In order to find a possible solution, I did some searching online and came across the following forum post with an issue that seemed to be similar: WS2812B LED flickering, not a power issue. One of the solutions I found on this forum was to connect a resistor between the GPIO output and the data input to the LED strip. I tried to insert a 470Ω resistor in this manner, but had the same issue as before. A second solution that I saw was to add a capacitor on the power supply into the LEDs between the positive and ground lines. However, this also did not seem to fix the issue. After this testing, I am thinking that the issue is probably with the actual PWM signal that I am sending into the LED strip, either with the duty cycle being incorrect or the frequency being off. This will be what I will try to figure out the next time I work with the LED strip.

Week 6:

Date Reported: 02/16/2024
Start Time: 5:00pm
Work Time: 3 hours
I wasn't able to finish fixing the issue with the PWM signal's timing during the last meeting, so today, that was my goal. The tutorial I was using ("Interface WS2812 with STM32") followed the “HSE” path during the clock configuration, which can be seen in the image below.

During my setup however, I had to use a different timer path in order to get the same 800 kHz needed for the PWM signal on the WS2812 LEDs. I proceeded with the setup of the micro, again following the tutorial to make sure that everything was correct.

Essentially, this program utilizes an array of the appropriate size that gets sent to the LED strip through a PWM signal through the DMA. This array size is determined based on the requirements of the WS2812B protocol that utilizes 24 bits per led (with 8 bits per the 3 colors). Thus, in the case of the strip I was using with 11 LEDs, the array would have a size of 264 with an extra 50 bits that act as a reset code.

In order to test the functionality of this code on the LED strip, I modified the output to display a pattern of red, green, blue alternating per LED on the strip. Upon plugging in the LEDs, I was able to get an output, but it was quite inconsistent and there was a lot of flickering. This will be my goal to fix next time.

Date Reported: 02/13/2024
Start Time: 9:30am
Work Time: 3 hours
Today in ManLab, I continued to work on the LED interfacing. Last time, I thought that I was having troubles with the communication between the CubeIDE and my microcontroller. However, after further looking into the problem, I realized that the issue was with the way I had set up the timer for the PWM signal. Before continuing with this, we met with the course staff to talk about our current progress. We are definitely behind on both the PCB and prototyping process and since the midterm design reviews are coming up in the next couple weeks, we need to make sure that we get all of the parts we will need and get the PCB design set.
After meeting with the course staff, I worked on resolving issues we were having with ordering the keypad we were looking to get. The one we found to fit our needs the best was only available on a couple of websites. It turns out that the one that would ship to our location ("Abra Electronics") has a $45 minimum on placing orders and the keypads would not reach that amount. Thus, we considered ordering other components from this site, such as a battery pack, in order to meet that requirement.
Today I wasn't able to fix the PWM issue I was having, so I will work to fix that issue next time I come back to the lab.

Week 5:

Date Reported: 02/09/2024
Start Time: 4:00pm
Work Time: 3 hours
Today, I went in to lab for a few hours to figure out the LED interfacing. The tutorial I have been looking at is pretty in depth, but it uses the CubeIDE to show the process of interfacing the LEDs. I had installed this during ManLab earlier in the week, so I would just have to spend a little time learning the different functions in the IDE. Before starting on that, I had to solder on leads to the small strip of LEDs we have. This took longer than expected because I was having trouble getting the solder to stick to the pads on the LED strip. After this, I proceeded with the tutorial and went through the process of setting up the timers and pins that I would need. Upon completing this, I tried to run the program on the microcontroller, but started running into issues with the communication.

Date Reported: 02/08/2024
Start Time: 6:00pm
Work Time: 1 hours
After the lecture today, I started some work on a PCB schematic. Since I had gone through the tutorial for KiCad, I wanted to see if I could put something together to resemble the system that we would be using. Mainly, I wanted to figure out what sorts of parts were available in the library for components such as the LCDs and keypads that we have in our design.

Date Reported: 02/06/2024
Start Time: 9:30am
Work Time: 3 hours
Today, during ManLab, the first goal was to finalize our description and PSDRs on our team website. This is the week where we are expected to have these locked down, so we quickly discussed some updates to be made and finished that task. After having finalized the description and PSDRs, we included a couple of stretch PSDRs and functionality that we would attempt to complete depending on the project’s status later in the semester. These include one hardware PSDR of designing an audio amplifier and one software PSDR that involves implementing more advanced game functionality such as different modes and mechanics. During our meeting with the lab staff, the instructors recommended looking into CubeMX, which is a newer IDE than the System Workbench IDE that was used in ECE 36200. This would require some extra time put into learning the new IDE, so we aimed to use System Workbench. We ran into an issue with System Workbench where it was not recognizing the standard peripheral library, which took a long time to debug and fix. Essentially, the issue was that we needed to download version 1.5 rather than 1.6 because the development studio was not recognizing the newer library.

Week 4:

Date Reported: 02/03/2024
Start Time: 6:00pm
Work Time: 2 hours
I continued to work on the A4 and A5 documents. The key considerations for the electrical overview include the operating frequencies, power requirements, electrical loading, types of interfaces, data rates, etc. I generated the following system block diagram to show the system's input and output communication:


Date Reported: 02/02/2024
Start Time: 5:00pm
Work Time: 1 hours
Today, I started working on our “A5 – Component Analysis” document, as well as the “A4 – Electrical Overview” individual report. For the component analysis, I detailed the main options that were considered for the keypad in the game’s system and the reasoning behind our final decision.

Date Reported: 01/30/2024
Start Time: 9:30am
Work Time: 2 hours
During our ManLab meeting for the week, the first goal was to update our project description and PSDRs. The requirements we defined were all valid but needed to be updated with more specific information about specific interface used between devices. For example, in our PSDR with the interface between the microcontroller and the LCD, we specifically defined SPI to be the protocol to be used. These were all quick changes, so after discussing them I went ahead and updated the team website with the updated information. My next goal was to continue researching the WS2812 LEDs we are going to use. The main concern with the 4 grids of LEDs in our design is how to power them. Our goal is to use a battery pack to power the entire system, but with such a large number of LEDs it is tough to do so. The following article gave a good overview for powering LED strip lights: “Powering LED Strip Lights With Battery”. During my search I also came across the following Arduino forum posts related to powering and controlling the LEDs: “Battery for WS2812b” and “Multiplexing/Smart addressing LED strips to reduce power consumption?”. One idea that Derek mentioned was to divide the 10x10 grid of LEDs into 10 rows and control them through a multiplexer. However, after reading the forum post related to multiplexing the strips, I learned that the WS2812b LEDs don't refresh very fast, so multiplexing may not work. A better solution I found was that if we just consistently run the LED grids at 50% brightness, that would significantly improve the power consumption. This kind of solution would work out better. At the end of the lab we met with the course staff. We received further feedback on the PSDR wording and need to explicitly state the interface between the microcontroller and each component in the requirements. We also changed one of our PSDRs. We made our audio PSDR a stretch goal and instead are going to have the interface between the two microcontrollers as a PSDR. Finally, Dr. Walter suggested using a rechargeable portable power bank like what is used for phones to power our system. This could be the best solution to power all of the LEDs.

Date Reported: 01/29/2024
Start Time: 6:00pm
Work Time: 2 hours
In order to prepare for designing our PCB for our project, I went through a KiCAD tutorial to familiarize myself with PCB layout as well as learn tool itself. I used the following tutorial to learn more about KiCAD: Getting Started with KiCad Version 6 : Beginner's Tutorial to Schematic and PCB Design. This tutorial went through two pain tools in KiCad: the schematic editor and the PCB editor. First, I went through the tutorial on the schematic editor to refresh myself on the different shortcuts and tools in the editor. The following schematic of a 555-flasher circuit was the result:
After finishing with the schematic editor, the tutorial went through how to convert this new schematic into a PCB layout. The following are images of the PCB layout and a 3D render of the PCB:

Week 3:

Date Reported: 01/26/2024
Start Time: 3:00pm
Work Time: 1.75 hours
Today, we had a full team meeting to finalize some of the parts that we are planning to order. I found a potential 3x3 keypad that would work well for our design. The keypad is designed to plug directly into an Arduino board, but it should work with other chips as well. This keypad also has an interface for an attachable LCD, which could come in handy if the LCD we use is compatible. We also found a strip of reasonably priced LEDs on Amazon that could work for prototyping.
Date Reported: 01/25/2024
Start Time: 5:45pm
Work Time: 1.25 hours
Continued working on the LCD and keypad setup. Updated my team member page.
Date Reported: 01/23/2024
Start Time: 6:00pm
Work Time: 1 hours
There was no ManLab today, so I did some work from home in the evening. Since some of the components we are going to use are similar to those in our ECE 36200 kit, I started setting up the LCD and keypad with the STM32 development board.

Week 2:

Date Reported: 01/19/2024
Start Time: 2:30pm
Work Time: 1.50 hours
Project team meeting to further work on the functionality of the game and the functional specification assignment. One of the key decisions that was made was to have two “consoles” with a microcontroller in each to make sure that both players of the game would be able to simultaneously setup their ships on the game board. We discussed using a microcontroller within the STM32 family since we all had experience with that and it seems to have what is required for our project. The following is an image of a whiteboard that we used to get our ideas down.
Date Reported: 01/16/2024
Start Time: 9:30am
Work Time: 2 hours
During this ManLab session, the main goal was to work on the functional specification assignment and determine specifics of our battleship game. We discussed the main components we wanted our game to have, which would help finalize the main electrical components that would be necessary, such as LCDs for output and keypads for input.

Week 1:

Date Reported: 01/12/2024
Start Time: 2:30pm
Work Time: 1 hour
We had a meeting to work on our final project proposal. We wrote a description of our project and determined the five PDSRs (project specific design requirements) that we would satisfy in our project. We also decided the homework assignment responsibilities for the reports in this project. I will be responsible for the A4-Electrical Overview and the A11-Ethical/Environmental Analysis. I also worked on figuring out an estimated budget for our project. We looked up the various parts that we think we will need for our battleship game to find the most accurate pricing. Finally, I finished my team member expertise section in the final project proposal.
Date Reported: 01/09/2024
Start Time: 9:30am
Work Time: 2 hours
In the first ManLab for the semester, we completed some initial set up tasks. I set up a network drive on my computer in order to have access to our website files and got myself familiar with the layout of the website template given to us. I also started to contribute to the final project proposal assignment. We chose our roles for this project and I will be the electrical lead for this project.