Project Journal for Zachary Bellucci
=============== Week 15: =================
Entry 2: -----------------------------------------------------------------
Date: April 23rdStart Time: 11:00am
Duration: 24.00 hours
I was in lab for 24 hours straight minus a team McDonalds break and was awake for like 31 hours or something so this journal is going to suck but oh well. No I did not do 24 hours worth of work, but I was in lab with at least one team member for the entire duration so I am writing this log for my total amount of time. I haven't been a fan of "active journaling" at all this semester (despite trying to do it every meeting) as it ruins any and all momentum I have while working and doing it for this long would have made me brain dead so this is everything you get...
-------------------------------------
Showing up to lab today, I found Luke working on finishing our packaging now that we had acquired the top piece of our board from the machine shop. I got to work helping him screw in the top piece to our box walls, making it a nice 27"x27" box with an open bottom so we could still have access to everything we need to finish working on our project.
I then finished working on my individual section of the ABET draft report, as it was due tonight and I know we are going to be here for a while.
Experimenting with python tkinter module, I want to create a Start screen popup for Grid Wars. This will give the game a default start state that the user can choose when to begin the game by pressing a button. Using art that Luke made, I was able to create a popup window with the background as the image and then code in a clickable button that will quit the popup when pressed (closing the popup will then show the actual game). Here is a Tkinter basic understanding and this was the final product of our Start screen:
Python Tkinter
Next on the agenda, we need to attach all our PCBs and additional components to the underside of our gameboard to consider it as final packaging. Luke and Owen had previously glued in the IR PCBs, so now I am gluing in the motherboard, voltage divider board, and the SBC.
I'm not entirely sure what happened here, but we had to change the game logic code for how the cards were being displayed on the screen. Michael and I talked about and wrote out the coordinate system for how the cards would be displayed last week and had it all working, but I guess something changed between then and now or it was the way the sensors were wired up or something and the coordinate system needed to be changed. I tried to help figure this all out for a long time, figuring out the changing of the GPIO ordering in the esp code, trying to refer back to what we did last week, but it was to no use. This went on for like 2-3 hours until it was eventually solved.
Following this, Luke and I decided to make an end game screen showing which player won and which player lost. This followed a similar method to the start screen, but this time it had to be adjustable to which player won the game. Using art the Luke made, I was able to make this popup screen that changes based on the winning player:
The rest of our short team meeting was pretty much working on the game logic code and trying to get it functional enough for our project demo that was at 10:30am. Through hard work and dedication (especially by Michael, but from everyone overall) the project was done well enough for our demo and we were able to secure all 5 of our PSDR checks plus a stretch PSDR. We lost some points from stuff in our functional description that we decided against adding to our game, but the bonus from the stretch makes up for that.
Entry 1: -----------------------------------------------------------------
Date: April 22ndStart Time: 12:00pm
Duration: 2.00 hours
Today I spent my time working on the ABET draft report. I worked on part of the team section and my individual section. This draft will be filled out, reviewed, and returned for editing. Then, it will be filed and reported to the School's Senior Design Committee, Curriculum Committee, and ABET Review Committee, and will be used to help show that the ABET Outcomes are being met for both the Electrical Engineering and Computer Engineering undergraduate degree programs.
In this document, I wrote about my own contributions to the project, how I used learned knowledge, how I learned new knowledge, my ethical and professional responsiblities, and how our team's product could have impact in various contexts.
These IEEE standards were important to keep in mind throughout our project's design:
IEEE Code of Ethics
IEEE Code of Conduct
=============== Week 14: =================
Entry 5: -----------------------------------------------------------------
Date: April 18thStart Time: 12:00pm
Duration: 2.00 hours
Went down to the machine shop but it seemed to be closed, guess I can't check on our packaging quite yet. In other news, Owen ordered some cables for our IR pcbs, so now I can help with hooking up the connections from the daughterboards to the motherboard.
I went back to check at the machine shop now that some time has passed and they are now open. I asked the guy there about the progress for our packaging. They have the holes cut out on the board, but the middle section that needs to hold the screen is still not finished. I asked for a timeline, and he said mid-week next week. This is likely too late for us, since our team's demo is scheduled on Thursday 10:00am. This means if it comes down to it, we just bite the bullet and lay the screen on top without a grand cutout.
Running into some issues with the voltage output of our IR sensors to the ESP32, we are going to attempt to use a level shifter for 5V to 3.3V. The level shifter we were given is the cyt 1076 but we were struggling to find some proper documentation for it. These are some of the websites I tried to help us get an understanding:
https://www.sparkfun.com/sparkfun-logic-level-converter-bi-directional.html
https://cdn.sparkfun.com/datasheets/BreakoutBoards/BSS138.pdf
https://www.sparkfun.com/sparkfun-level-shifter-8-channel-txs0108e.html
https://learn.sparkfun.com/tutorials/bi-directional-logic-level-converter-hookup-guide/all
Entry 4: -----------------------------------------------------------------
Date: April 17thStart Time: 12:00pm
Duration: 2.00 hours
Yesterday, Luke finished putting together 3 sides of our box packaging. Today, I am helping him put the final side on. Two of the sides are slightly raised (left and right sides imaged below), but this allows the 27"x27" top board to fix nicely between them while still resting over the top and bottom sides.
Worked with Michael on software logic for displaying cards on the grid. Each 2x2 section is a group and each IR sensor is also tracked, so they are stored as (group, sensor). I drew up a sketch to help us visualize the coordinate logic. In the image below, the bottom left group is group 0 and each slot contains 2 sensors.
Now with this figured out, we can choose the specific location on the display that we want to place cards.
Entry 3: -----------------------------------------------------------------
Date: April 16thStart Time: 12:00pm
Duration: 2.50 hours
Today in ManLab, I signed our team up for the Spark Challenge and scheduled our time slot for the final project demo.
During our manager meeting, I showed off our newly finished decks of cards and we showed that our team has gotten the required 3 PSDRs checked off. We talked about packaging, which Luke has started on for the borders of our box while the people in the machine shop work on the top board.
The rest of time in lab today, I worked with Luke to assemble the box borders for our packaging.
Entry 2: -----------------------------------------------------------------
Date: April 14thStart Time: 12:00pm
Duration: 4.50 hours
Luke got the cardstock printed and cut out, so now we have 2 decks of 18 cards each. Luke and I will be putting RFID stickers on each card, then I will code in the unique IDs for each one. This will allow us to scan a card, search for its ID through a lookup table, and determine the specific stats of the scanned card.
Luke and I want to further improve the card design, as the ones we printed came out with some strange clipping thanks to the lovely microsoft word. This time, we want to add a design to the back of the card, similar to how other trading card games have theirs. For this, Luke had an idea to have the design with a logo in the middle as a separate print, then we can tape/glue the backs onto the cards to hide the rfid stickers.
To progress the software, I first want to add all the card images and make it to where when a specific rfid sticker is scanned, the corresponding card image will display in the game window. To do this, I scanned 36 different rfid stickers, got their IDs, then assigned a different ID to each card.
These IDs are used to search through a lookup table which stores the unique stats of each card that will later be referenced during gameplay. The IDs are also used in a separate lookup table to reference the path to the image so the card can be displayed in the window
Using this code, a card can be scanned, displayed, and the stats can be shown, allowing us to get another PSDR checked off.
Finally for today, Luke and I are going to assemble the cards. We are putting the rfid stickers on the back of a card, then gluing the image side with the logo side. Here is the set of both decks fully assembled:
In this meeting, I worked on card creation and the software that goes with it to get our PSDR for getting the stats of a card when scanning it. To make the cards, I stuck RFID stickers to the back design half, then glued the image side on. This was done for each card. For the software, I scanned the RFID stickers and wrote down all the unique ID values then stored them in the templates I had made earlier. This let me scan a card and get the specific card stats, contributing to the project progress by allowing us to get a PSDR checked off. Next, our team needs to sign up for the Spark Challenge, sign up for our final project demo time, and continue on game logic software.
Entry 1: -----------------------------------------------------------------
Date: April 14thStart Time: 12:00pm
Duration: 5.00 hours
I soldered on the remaining capacitors to the esp32 board as well as the switches connected to it. Today our team wants to actually get our PSDR checked off for reading RFID to the ESP32 through SPI.
Luke and I are still working on the card design as well. We want enough unique cards with a variety of cost/power/health so the gameplay isn't too static. In total Luke and I have made 18 unique cards with doubles so each player has the same deck.
I am still trying to make advancements on the software side. I want to be able to read in a bitstream that corresponds to a card's unique ID value. Then, based on the ID of the card, I want to be able to get the specific stats for the card that can be played on the board.
Owen soldered on the connectors to the motherboard, so now I can hook up the esp32 and test our PSDR. I have tested reading data from the RFID to the esp32 via SPI and it works, so our team got a second PSDR checked off.
Michael then helped me update the game logic code using one of the functions he had from his esp32 code. This function allows the code to read the RFID information through SPI, meaning I can tell the unique IDs of the tags being scanned on the sensor. This will let me differentiate each card from one another and help our team work towards another PSDR.
In this meeting, I worked on physical card creation for our game and software towards one of our PSDRs. For making the physical cards, a word document was used to create 2.5"x3.5" card grids which could be filled in with an image, stats, and flavor text. For software, since I couldn't read the specific IDs yet, I make templates for each individual card including a temp ID and the specific card stats. From these, I learned that microsoft word sucks and I hate software. These tasks contribute to the project by giving us the physical playing cards needed for a person to play the game and the game logic to make the cards work. Next, I will get the ID values for the RFID stickers we are using and assign/apply them to the cards.
=============== Week 13: =================
Entry 3: -----------------------------------------------------------------
Date: April 11thStart Time: 12:00pm
Duration: 2.50 hours
Today was just Luke and I in lab. We started by going down to the machine shop to answer some questions and confusions that they had for our design. It turned out that the physical drawing our team gave them had the wrong dimensions, while the SolidWorks model our team also sent had the correct ones. They weren't positive which was the correct version, so Luke and I confirmed that the model had the right dimensions. Now with the dimensions confirmed, the packaging should gain some significant progress very soon.
When returning from the machine shop, I wanted to hot plate solder our other esp32 onto a new board since the last one didn’t go great. While letting the hot plate process play out, I stayed to watch and move the pcb on the plate while Luke went to WALC to check if we can print cardstock to make our playing cards.
Luke found we are able to print cardstock, so we are working on a word doc with all the cards we want to get printed out. Each card has a name, mana cost, picture, text blurb, health points, and attack points. This is more of a design process rather than a technical one, but is still important for the creation of our game.
Finishing the hot plate soldering and letting the pcb cool down, I took it up to the ECE shop to get it x-rayed and check the soldered connections. This time looked much better than the last one with every pin being soldered and no bridged connections.
With this new and improved pcb, our team should run into no problems getting our PSDR's checked off. Michael has tested the software on the devboard and has confirmed that it is functional, so the final step is to apply it to the actual pcb. This is our largest goal for the next meeting and I will try to make a large improvement to the game logic code.
Entry 2: -----------------------------------------------------------------
Date: April 9thStart Time: 12:30pm
Duration: 2.0 hours
Today I want to check the connections on our esp32 and solder on the needed components for it to run so I can finally hook up the rfid sensor and uart to get another PSDR checked off. I also want to check in on our packaging to see if there any progress from our last meeting.
Owen and I went up to the ECE shop to use the x-ray machine where we were able to check the connections of the esp32. This was the result from the machine:
Some of the connections look unsoldered, but these should just be ground pins if I understand the orientation correctly. There is also 2 pins that are bridged, which is bad, but I might be able to get around it by removing the connection and manually wiring it. Basically, I want to avoid having to re-do the hot plate soldering, as that would require us to first desolder the buck regulator and everything else to do it once again.
Luke also went down to the machine shop to check in on our packaging and was told to come back on Friday due to some confusions. As for game logic software, I need to create the state machine for the game, which I have now created a rough skeleton of:
Next I am going to solder our back-up esp32 onto a new motherboard. This will let us get our PSDR checkoffs without having to desolder the original motherboard and do everything from scratch. I also want to work on the card design for our game, as I believe our packaging should be done somewhat soon.
Entry 1: -----------------------------------------------------------------
Date: April 8thStart Time: 12:00pm
Duration: 3.0 hours
Want to start by checking the connections on the buck regulator and esp32 I hot-plated last time. Owen, and I went up to the ECE shop to try and use the x-ray machine to check the solder connections, but they said there wasn’t a manager and I would have to come back tomorrow around 12:30. I don't want to wait to do this, so I are manually checking the pin connections of the buck. After checking with a multimeter, they all seem fine and I am going to better solder the resistors and caps onto the board. When this is done, our team can finally get a PSDR checkoff if all functionality goes to plan.
Luke and I are theorizing the game logic software and deciding on how we will initialize each card. I think they can either be their own individual classes or I can somehow create them when they are scanned. So far, I have made a player class and a card class that will be used to track the stats of both players and cards in play.
I referenced this website to try and gain an understanding of how to start this process:
Creating a State Machine in Python
So far, this is how I believe I want to set up the classes and card identification:
Owen has finished soldering on the surface mount components, we tested the regulator with 12V from the power supply and read 5V on the multimeter. Then soldered on the barrel jack and plugged in a wall transformer to get the same output. This let us finally check off our first PSDR.
Next our team wants to get checked off on our PSDR that is based on our esp32, which Michael believes is ready as long as the esp32 functions on the motherboard.
=============== Week 12: =================
Entry 4: -----------------------------------------------------------------
Date: April 4thStart Time: 12:30pm
Duration: 3.0 hours
When I came in to lab today Luke was trying to put solder paste on the motherboard for the esp32 and the buck regulator using the stencil but was having difficulties. I helped spread the paste while he held down the stencil and this worked much better than his individual attempts. It's a somewhat difficult process to get right, so we did this a couple times… washing, drying, pasting again, repeat.
We took a break from this and Luke and I went down to the machine shop to get verification on our packaging from Chuck Harrington, great guy with lots of cool stories btw. He opened our .dwg (drawing) file on his computer and explained to us that since our design is so large (27"x27"), it wouldn't be able to be made in one part on the router machine they have in the shop so different approaches would need to be made for them to design it. He said we can come back either next Wednesday or Thursday to check on the progress.
When he verified our packaging, we came back upstairs to work on the soldering again, still running into pasting issues but we're determined to get it right.
Eventually we got a spread that looked good enough, so Luke placed the esp32, buck, and resistors/caps down on the board so we could take it over to the hot plate to have them soldered on the board. This process took some time: 10 minutes to heat up, 10 minutes on one of the heat pads, 10 minutes on the next, 10 more minutes on the next (moving over to these pads create a gradual change in temperature), then finally at least 10 minutes for cooling down. Now with the board off the hot plate, we can do a continuity check on the pins to make sure all the connections are good and consistent.
Before & After:
With these parts finally soldered on the motherboard, we can test them individually and check off some PSDRs. Finally getting this done, I'll be trying to work more on the game logic software to check off another PSDR.
Entry 3: -----------------------------------------------------------------
Date: April 3rdStart Time: 12:30pm
Duration: 1.0 hours
Today I was in lab (from ~12:00-4:30pm) mostly working on stuff for other classes, but was here as a helping hand for whatever was needed. I mostly helped with getting the measurements and dimensions of our screen for the cutout we need in our packaging design, both with Luke's SolidWorks model and Owen's physical sketch as requested by the people in the machine shop.
The SolidWorks model will be sent to the machine shop and we can get verification if our design is suitable or not.
Entry 2: -----------------------------------------------------------------
Date: April 2ndStart Time: 12:30pm
Duration: 2.50 hours
Today there are several goals for our team to work on that I will be going back and forth between. We are working on the packaging on our design, where Luke is creating a SolidWorks model with the accurate dimensions so we can send it down to the machine shop and have them make the cuts. I will also begin setting up my coding environment so I can begin work on the game logic portion of our project.
We are still waiting on orders for IR sensors and capacitors, but we did receive the RFID stickers that we will apply to each card we create to give them unique identifiers.
I've been sitting here with Luke trying to help figure out SolidWorks. We're trying to make the area for the cutout of the screen on the top layer of the box, but every time we update the dimensions of the screen cutout, it changes the dimensions of the rest of the board too. Luke found a fix for this by adding anchor points and locking down the edges of the shape.
While setting up my coding environment, I'm trying to follow in Michael's steps that he left commented in his original setup of the code. I'm trying to install pygame using "python3 -m pip install -U pygame==2.6.0" but I'm getting a metadata generation failed error that I don't know how to fix. A simple google search is unhelpful and I hate software with a burning passion.
Next time, I will need to find a work-around for this error so I can figure out coding the game logic. We will also need to finalize our packaging design and get it checked by the people in the machine shop. Once packaging is complete, our team can swap to the more software focused side of our project and check off some PSDRs.
Entry 1: -----------------------------------------------------------------
Date: March 29thStart Time: 10:30pm
Duration: 1.75 hours
Worked on and finished Legal Analysis (A9) assignment. I had more to work on and some revisions to make from working on it yesterday so I spent this time finalizing.
Patents Analyzed:
Virtual Game Console
Physical-Virtual Game Board
Smart-Card Holder
=============== Week 11: =================
Entry 2: -----------------------------------------------------------------
Date: March 28thStart Time: 11:45am
Duration: 5.50 hours
My goal today is to work on my individual Legal and Regulatory Analysis (A9). What I need to do is analyze our project and determine which regulatory certifications we will require if we were to sell on market. Next, I will analyze similar patents and check for potential infringements that may need to be managed. Today, I also want to check our LCD screen functionality.
I started today by cleaning up some of our workstation: clearing out trash, organizing components, and trying to keep an area for clear desk space (it's not likely this will last, but it makes it easier for me to work in).
For our buck regulator, we need 100uF 1206 capacitors for the Cout decouplers. Luke checked and found that the highest value available in the lab was 47uF, so we have ordered some on our own (not through the procurement office) so we can get them asap and start soldering the power system on our motherboard.
I hooked up the LCD screen to a Raspberry Pi 4 with the micro-hdmi and usb. I powered the backlight of the screen and the Pi, which turned on the screen to its boot process. This confirms that the screen functions, although we didn't supply the Pi with an SD card, so it had no operating system to run on.
Owen has been soldering the IR sensors and the 1206 resistors, so I helped him clean off any remaining residues.
Since we ran out of IR sensors to solder and we're waiting on the order for them, I asked Owen to show me how to do a basic through-hole solder (on the through-hole resistor below) and a surface mount solder (on the 1206 resistor in the R6 slot) so I can help later when the orders arrive.
He also showed me how to desolder with the wick, which I did partially on the through-hole resistor above.
The rest of my time today I have been working on the Legal Analysis. The next thing we need to begin is our project's packaging. We will go down to the machine shop and get advice on how we should approach our design.
Entry 1: -----------------------------------------------------------------
Date: March 26thStart Time: 12:30pm
Duration: 2.50 hours
We have received our PCBs over break. I am doing a visual inspection of the daughterboards and checking for any discrepancies and defects. A large majoirty of them look good, one of them had what looked like some sort of curved slice through it, so we set it aside and plan to use it as a practice board if we need to.
We also received our switches, so we verified that they work with our PCB.
After finishing the visual inspection, I am performing continuity checks on each board to look for any potential direct shorts between power and ground pads. Finishing my checks, I'm handing some of them off to Owen where he is beginning soldering the IR sensors into them.
We had our manager meeting where we showed out PCBs and discussed the assembly. The first thing to do is the power. Making sure this works is crucial to testing the other components that will be assembled on the board. After this, the next to add is the ESP32. We will assemble the board in order from most complex component to least complex to try and ensure a smooth testing process. We also discussed means of our packaging design. This is going to be somewhat difficult, as our surface is roughly 4 sq. ft. We were advised to look into going to Bechtel for getting the wood necessary for our packaging.
Post meeting, I am ordering more TCRT5000 IR sensors and RFID sticker tags that function with the RC522:
TCRT5000 IR Sensors For Ordering
RFID Sticker Tags
=============== Week 9: =================
Entry 1: -----------------------------------------------------------------
Date: March 12thStart Time: 12:30pm
Duration: 2.0 hours
Today we need to make modifications to our PCBs to match the feedback we were given during our design review, then we need to find a manufacturer to send our gerber files to and order our PCBs.
I went to the ECE shop and checked if they had the specific push buttons that we are using for the reset and boot switches. They did not have them, so I am making another order request for the specific component we are using.
Switch Button For Ordering
I'm looking through pcbshopper to find a supplier for our PCBs. I manually put in all the dimensions and features of our design on the website and it has shown me many suppliers with varying prices. Previously, we used PCBWay to check our price, which came out to about $50 for 5 of our motherboard PCB. There are cheaper options, but they may be less reliable.
From our Midterm Design Review, these are things we need to modify on our PCB:
1. Have more stitching vias. (completed)
2. Connect to a bigger ground plane for thermal dissipation. (? - the ground plane covers the whole pcb)
3. Add another mounting hole to the IR sensors PCBs. (completed)
4. Bring out the GND from Pi. (completed)
5. Put values on decoupling capacitors. (completed)
6. Make the vias bigger for flywiring (15 mils) {use global settings). (completed)
7. Put more ESD protection. (added Zener diode to push button, completed)
8. Extend the pads out (completed)
During our Manager Meeting, we were also told to swap the SPI and UART connections. They have to cross one another, so we had the SPI trace via to the backside and come back up. SPI is a higher speed though, so it is better to not cross thru vias. We have now made the UART connection go through the vias to cross the direct SPI connection.
Imaged below, M1 is the SPI connection now going directly to the ESP32, J9 is the UART connection now using vias to cross to the ESP32
Updating buck converter on PCB to look more similar to datasheet with power planes and stitching vias per Dr. Walter's advice.
The next step is to email the teaching staff our project archive. This will allow the staff to review our design, let us change anything else once more, then let us finally order our PCB's before spring break.
=============== Week 8: =================
Entry 3: -----------------------------------------------------------------
Date: March 6thStart Time: 12:30am
Duration: 2.0 hours
Working on and finishing up portions of midterm design review presentation
Project Overview Ex.:
Major Components Ex. (One slide per major components):
Entry 2: -----------------------------------------------------------------
Date: March 5thStart Time: 12:00pm
Duration: 3.0 hours
Today we need to make a project journal showing our pcb layouts and schematics for the motherboard and the daughterboard. We essentially need to finalize everything required before our Midterm Design Review, so this also includes adding all datasheets, resources, and general documentation to our team website. We will need to do a physical footprint verification, follow the rest of the PCB verification checklist, and finish our slides on PowerPoint for the presentation.
Updated References tab, adding all necessary files and documents to website (up-to-date project reports, major component documentation and resources).
Luke finished the pcb layout last night. I am going through the pcb verification checklist with him and manually double checking everything, two sets of eyes are better than one.
Here we did the physical footprint verification:
After going through the checklist, we believe our design passes the checks, at least where relevant. The rest of our meeting we will spend working on the presentation slides. We assigned specific slides to each member based on what they have worked on so far. I will be doing project overview, the major components, and the packaging design. The next step is to finish these slides, then we will do some practice runs before our real presentation.
Entry 1: -----------------------------------------------------------------
Date: March 3rdStart Time: 12:00pm
Duration: 6.0 hours
Still working on finishing our PCB layout, I'm still helping Luke figure out placing all of our components and getting all of the traces set up. These will all be done in our PCB KiCad project.
So far, we've learned how to add a ground plane to the pcb. This will give a common place for all ground connections to go to, and by adding vias we can connect them all together.
We've been trying to figure out the layout for our buck converter, but the one in the datasheet differs from the schematic in the same datasheet. There are 12 components in the schematic, but only 10 in the layout. We've researched some and found that the layout is inaccurate, so we are just going off our intuition.
Buck Converter Datasheet
Now we are working on making the connections with the ESP32 microcontroller. Most of our connections are straight to the IR matrix, so the microcontroller will be placed closest to the IR connections.
In between figuring out the pcb layout, I've been messing around with the dimensions of our board on PCBWay to get a price check and manage our budget. I found out that with a 4 layer board (this is what we will be ordering) that there is some sort of soft price cap when the dimensions reach 4x4". At 3.9x3.9", our board would be $46.67, but at 4x4" it doubles to $93.66. This might be something to keep in mind when designing our pcb if we don't need the extra space. No reason to waste our budget if we don't have to, it'd be better to have these funds as an emergency if we needed to buy new components.
Working on making the traces between components, I am watching out over Luke for any potential problems while he draws the connections. These could include traces too close to one another, drawing acute angles between components, checking for current chokes, and making sure vias are wide enough for the current going through them and also allowing for flywiring.
We're running into an issue where the Vin and Vout pins of the buck converter won't connect to a trace. They show an error from the DRC when trying to draw from them, but we don't fully understand what the error is and how to fix it. I found through researching online that there is a setting that allows DRC violations, but we don't know if this should be used.
Discovered that the issue was that the polygon on the footprint had no net name, and the actual pad was separate from the polygon which was blocking the connection to the pad (imaged above: essentially the number was separate from the shape it's in). We found online that you can use CTRL + E in the footprint editor to combine the polygon with the layered pad. This solved our problem and we can now make the trace connections.
In this meeting, I worked on the PCB layout in KiCad with Luke. We focused on component placements and trace setup. We dealt with difficulties in our buck converter layout, we connected the ESP32 ports, and I reviewed and tracked our team's budget. From this, I learned that not all datasheets are entirely accurate. I also learned a lot more about KiCad today through our troubleshooting and designing. Fixing the issues with our PCB layout and tracings were crucial to our project progress and will allow us to continue working. The cost considerations I discovered will help us better manage our budget. In the next meeting, we will need to prepare for our Midterm Design Review by doing the PCB verification checklist and adding all relevant information to our website.
=============== Week 7: =================
Entry 4: -----------------------------------------------------------------
Date: February 28thStart Time: 11:45am
Duration: 4.0 hours
Today I want to help Luke in any way I can so we can finalize a PCB layout and verify it with the physical components we already have. On my own in downtime, I will be updating our team website to include up-to-date documents and references.
I've added the remainder of our assignments to the website, they are now available as browser pdfs (except bill of materials).
Working with Luke, our schematics still need decoupling capacitors, ESD protection, and debugging LEDs. The main components for using these are the ESP32, the push button, and the buck converter. I've spent time looking through the datasheets to help verify pin outputs and where we need to add all these extra systems.
Very long overdue, I'm adding any websites, datasheets, and resources we've used to the references tab on the website. We've had all of our links in a rather unorganized google doc, so I've sifted through everything we had linked and have transferred any important/relevant information we're still using. I also learned some basic html formatting to create a more organized references list.
Owen and I went down to the machine shop to get a reference of the machines we can use when building our frame for the game board. We grabbed a sheet of scrap wood and I have drawn a rough reference for a segment of our board and how we want to design the cutouts and placements (the dots in the card areas below represent where the cutouts for the IR sensors will be).
Our LCD screen showed up and it is unharmed :)
I sent in the packing slip, as instructed.
Owen and I also wanted a reference for the size of the hole for the IR sensors to peak through. We used a 1/4" drill bit to drill the hole, but we still aren't positive on how functional the sensors will be through this. This is something we will test and change in the future, but for now we will focus on finishing PCB design and presentation for next week.
Entry 3: -----------------------------------------------------------------
Date: February 27thStart Time: 1:00pm
Duration: 1.5 hours
I showed up to lab by myself today and one of our orders has shown up. This order was from Digikey including:
Arcade Push Button
ESP32-PICO-MINI-02
Buck Converter
Barrel Connector
I went through the ordered parts then emailed the packing slip as per the instructions I was given after initially ordering.
I'm reading through all the Midterm Design Review instructions and guidelines to begin working on our presentation. Reading through these beforehand will help me gain an understanding of everything that needs to be included in our presentation and will provide a great template to start out with. It will also help me focus on the structure of our presentation; splitting up slides, not having too many words per line, including ample figures.
I've set up the powerpoint template and added all group members for collaborative editing. Throughout the rest of this week and the weekend, we will all be working on this presentation to be fully prepared for our design review.
Entry 2: -----------------------------------------------------------------
Date: February 26thStart Time: 12:30
Duration: 2.25 hours
I'm working with Luke on schematic verification. There are some components getting errors during the ERC. These mainly consist of the connections for the SW port and AGND on the buck convertor (Later found out that these errors aren't crucial since they're based on the import of the footprint, so everything was set up correctly).
Owen and I are researching the push button to try and find the amount of voltage and current draw it will use. The datasheet doesn't have hardly any information, so now we are hooking the switch up to the power supply and multimeter to read the output. The switch is functional and can output the 3.3V we need while drawing a very low amount of current when running through a resistor.
During our manager meeting, these were some things brought up that we still need to include in our schematics:
○ Make RFID a connector rather than chip
○ Mounting holes
○ Decoupling caps in microcontroller
○ Electrostatic protection on outside push button
○ Expressif idf instead of thonny on microcontroller (not industry standard, can use micropython on raspberry pi)
Entry 1: -----------------------------------------------------------------
Date: February 25thStart Time: 9:30pm
Duration: 0.50 hours
Updated speaker stretch PSDR to a software goal (will make our implementation much simpler).
Added both stretch PSDRs to our functional description explaining how we would implement each if the time allows it.
=============== Week 6: =================
Entry 3: -----------------------------------------------------------------
Date: February 21stStart Time: 11:15pm
Duration: 3.75 hours
Luke is working on finishing up schematics for the different components of our designs. I'm working on finishing order requests for the different components we need shipped, then I'd like to begin working on a frame for our game board.
I have filled out and sent purchase requests to the Procurement Office for the following parts: 13.3" LCD screen from Amazon (~$170). ESP32, Buck Converter, Push button, and barrel connector from Digikey (~$30).
Set up small test circuit of 4 IR sensors in series. This will be the layout on our PCB's, so we are testing optimal resistances to reduce the amount of wiring required later. We tried 62, 100, 220, 100k Ohms but we did not find the correct values we were looking for (voltage drop of 1.25V), so we will come back to this later and continue. It will probably just be easier to do that math.
At the end of lab on Wednesday, we were told that our ESP32 board we were using was not allowed in the final design, as it is a devboard. We weren't aware that what we were using wasn't allowed, so that gave us some shock and we had to spend some time researching the ESP32 chip itself. I helped Luke with trying to understand connections on our schematics. We spent time reading through datasheets to find connections and check for suitability between devices. We now have to figure out how to set up a UART connection with our ESP32 for communication, as that was included functionality of the devboard that we no longer have access to.
ESP32 Chip:
ESP32-Pico-Mini-02 Datasheet
I did not get to working on the frame for our game board today. Owen and I planned to make a start on this, so we will begin analyzing our dimensions and gathering materials to construct a physical frame very soon. Talking to Michael, he has mentioned that he may need more help working on software, so I may take some tasks off his shoulder in this coming week.
Entry 2: -----------------------------------------------------------------
Date: February 19thStart Time: 12:30am
Duration: 2.0 hours
We have several goals for our lab today. We want to begin on our schematics, which Luke has started working on. We want to finalize our ideas for our PCB design and layout regarding our IR matrix. We want to begin ordering parts including our screen and potentially wood for our game board.
Began discussion of ordering PCB and other components. We want to do 1x2 matrix of IR sensors per card slot. This will mean we will have 12 small PCB's consisting of two 1x2 matrices for the total IR matrix (reference below), then we will have our main PCB having our RFID, ESP32, and SBC. This will make wiring our matrix a much simpler process while not making the PCB's too expensive.
I have begun filling out the order forms for our parts. I filled out a form for the LCD screen, have not submitted yet, I'd like to get it checked before I submit this and future ones. We had our manager meeting. We need to add our stretch PSDR's to our functional description still. We were told about some different options regarding our PCB designs and how we power our IR matrix. Rather than constantly powering our matrix, we could instead follow the 362 matrix method where we just power cycle through each row and column. Regarding PCB design, we should focus less on price and more on easy assembly. If we get IR sensors surface mounted, may be cheaper and save assembly time. These are a lot of things for us to consider and think about, so we may make some adjustments to our original plans if we see fit.
Entry 1: -----------------------------------------------------------------
Date: February 15thStart Time: 7:00pm
Duration: 4.0 hours
• Working on and finishing Mechanical Overview
• Working on and finishing Bill of Materials
=============== Week 5: =================
Entry 3: -----------------------------------------------------------------
Date: February 12thStart Time: 10:45am
Duration: 3.75 hours
The goal of this meeting is to make any last minute adjustments to Functional Description before ManLab, we now believe it's detailed enough and explains enough of the functionality. We also want to flush out the IR matrix so that we can move on to other functionality such as the RFID sensor (which Michael has been working on) and the power system.
I'm creating a diagram of our game board in draw.io to add as a visual for our functional description, as it may be somewhat difficult to create a vision based on words alone.
Working on the IR matrix, we have decided to swap to PMOS transistors. Luke mentioned that these transistors work more efficiently in use cases such as ours, so we made the transition. Luke wired up 2 columns of sensors (image below). It now successfully allows voltage outputs based on the applied gate voltage. When the gate voltage is being powered above the threshold of 3.3V, the outputs are 0V. When the gate is unpowered, the gate source is -5V and the sensors read a voltage of 5V that drop to 0V when covered from the light.
12:30, ManLab begins. Our goals today are to work on the Bill of Materials, as well as continue functionality with the IR matrix and RFID sensor.
We listed some project components in the Bill of Materials, although we are still researching some components such as our DC-DC buck converter and a new Raspberry Pi.
Next came our team meeting with the professor and TA's. We got good feedback from our new functional description and our PSDRs. We need to add our stretch functionality to our functional description (though make it clearly separated from the base design), and change mentions of a specific Raspberry Pi to a SBC as to not cause grading issues for us down the line if our specific Pi doesn't work.
Now that we have a functioning IR matrix, we will begin working on flushing out the RFID sensor, start a major part of our software design, and begin researching to create our power system.
Entry 2: -----------------------------------------------------------------
Date: February 11thStart Time: 12:15pm
Duration: 2.25 hours
The goal today is to finish the Functional Description for our project. We will collaborate together to layout each functionality that needs to be in the design, then write in detail an explanation for each functionality.
Luke put his Electrical Overview into the website and I added the Component Analysis.
I added stretch PSDR's to our website, they now include card animations on the LCD and a team designed speaker. (These might be slightly modified later)
Working on the IR matrix, Owen had set up a demonstration using a NMOS transistor to gate our GPIO inputs across rows. Running 5V through the source, 3.3V through the gate, the output voltage can be read from the IR sensor. Next, we will wire multiple a row of sensors together, then try columns.
Working back on the functional description, we wrote down all of the game rules and all of the different phases in a player turn. These entail things such as player health, mana economy, card types, card interactions, etc.
I setup the documents for the team Bill of Materials (A7) and my individual Mechanical Overview (A6). I will begin working on the mechanical overview within the next day and collaborate with the bill of materials throughout the week.
Entry 1: -----------------------------------------------------------------
Date: February 8thStart Time: 7:30pm
Duration: 3.0 hours
Spent individually working on my part for Component Analysis. I analyzed our RFID sensor (RC522) and spent time researching and reading about how it compares to a similar sensor (PN532).
RC522 Datasheet
PN532 Datasheet
I also wrote the introduction paragraph briefly explaining each component (LCD Screen, microcontroller, RFID sensor, IR sensor) and their roles in our project. Once everyone finished their individual sections, I read through the assignment and made grammar/punctuation changes.
=============== Week 4: =================
Entry 1: -----------------------------------------------------------------
Date: February 6thStart Time: 12:00pm
Duration: 4.0 hours
This meeting, Owen and I want to finalize an LCD display and begin the Component Analysis (A5) while Luke works on the Electrical Overview. Owen and I have begun looking for a suitable touchscreen to fill the space on our game board. Our maximum size ranges roughly from 6" in height to 20" in length. We may have to increase the dimensions of our board slightly by around 1" in height to have an improved touchscreen display.
Potential LCD Display (12.1"): Raspberry Pi TFT Display
LCD Datasheet
I added some more references to the website. We now have links to our Raspberry Pi datasheet and a website explaining how to interface RFID to the ESP32 (won't include links here because they're on the website).
Owen found a display that fits our dimensions and functions with the Raspberry Pi (13.1" Capacitive Touch Screen LCD). Pictured below is a rough scale of our board with the display in the center. This one slightly differs from the other ones we looked at though, as it requires 12V to power the backlight of the screen compared to most of the other options using 5V. This will require us to change our power transformer to 12V, then buck down to 5V for the Raspberry Pi, then buck down again to 3.3V for the ESP32.
We realized that the Raspberry Pi can supply the required voltage for the ESP32 since the ESP32 is a feather board. This means the ESP32 will feather the 5V down to 3.3V, so we no longer need a second buck.
I've made decisions on which components we want to analyze for A5. We had different options for our LCD display, microcontroller, RFID sensor, IR sensor. We also discussed different options for building our game board, such as wood vs. 3D printing.
We've started research on our buck regulator. We need one that converts 12V down to 5V. Our LCD screen of choice requires 1A to power, so this will also be a requirement.
New LCD Wiki
Michael and I plugged in a keyboard into the Raspberry Pi to connect it to the internet, but there is no network option in the config so we are doing research to try and set up the wifi. For now, we just hooked it up using Ethernet. Michael and I ran a wget to install thonny on the Raspberry Pi, but we are struggling to get the actual installation to run.
Owen and I searched the cabinet for a push button to use as our end phase interaction. We grabbed a large green circular button. :)
This meeting, Owen and I researched for and found a suitable LCD Display for our game board, I added some more links to our website, and we have began to look into designing our buck regulator. On top of this, Michael and I have begun experimenting with running software on the Raspberry Pi and he has began learning pygame. Next we need to finish our Component Analysis, order our LCD display, and focus on how we want to design our PCB.
Entry 2: -----------------------------------------------------------------
Date: February 5thStart Time: 12:30pm
Duration: 2.0 hours
Today was ManLab #4. From the starting meeting, main goals for me this lab are to work on updating our functional description and to add links to our website. Some of the main things that need to be included in the function description include:
○ What is the design physically (wood, 3d print)
○ What will it look like
○ How will the UI look
○ How does the software work
○ How does the hardware work
○ What is the purpose
○ How is it all powered
Website needs to have all of our links. I didn't know how to add the documents, but I saw the file destination when hovering over the spots on the website. I had to add a docs and a refs folder to link the destinations. I added our current completed assignments (A0-A3) to the documents section, they are available now as .docx downloads. This will make it easy for everyone to download if we need to re-reference a past design option. Next I'm adding all of our current datasheets and pinouts to the references section of the website. I added ESP32 documentation and pinout, the IR sensor datasheet, and the RFID sensor datasheet. (won't add links here because they are on website)
We had our meeting with the professor and the TA's, functional description still needs to be updated and a slight modification needs to be made for PSDR #1. We changed it from modifying wall power to modifying 12V from a DC transformer and bucking down to 5V to supply the Raspberry Pi. Also discussed potential PCB design, we need to figure out how we want to lay out our IR matrix. Will they all be on a single PCB, or will we have multiple? This is something we will need to figure out later.
I realized it'd be easier to open the assignments on the website in browser rather than a download, so I converted them from .docx to .pdf for ease of use. I also connected the Source in the navbar to our newly made Github.
This lab I learned how to add our documents and references to our website and modified one of our PSDR's. The documentation will be updated regularly as we finalize our components and find new sources on how to use everything. Keeping the website updated will make it much easier for everyone in the group to find and revisit resources. Next we need to work on the Component Analysis (A5) and finalize our functional description.
Entry 1: -----------------------------------------------------------------
Date: February 4thStart Time: 3:30pm
Duration: 1.0 hours
I met up with Michael today and he has set up a Github repository and a Jira. He familiarized me with everything he setup, then helped me get the Github setup. I created an ssh key on my personal laptop and synced the Github repository to give me access for our project. I've always struggled with understanding and setting up Github, so Michael helped me learn the step by step process. This will allow me to edit code and other files remotely, as well as create new repositories in the future if necessary.
=============== Week 3: =================
Entry 4: -----------------------------------------------------------------
Date: January 30thStart Time: 12:00pm
Duration: 4.00 hours
This meeting was held to help our team figure out our hardware components and to work on the software overview. Owen and I researched for the datasheet of the current RFID sensor we planned to use, but found very limited information and non-official instruction manuals. This led us to ordering a new RFID sensor, the RC522, in which we found an accurate datasheet including all pinouts and relevant code for reading data. The datasheet is linked below.
RFID-RC522 Datasheet
We learned that this new RFID sensor has a larger range than our original one, which could lead to a negative impact on our card readings, so we may plan to return to the original one if we can find more accurate documentation on it.
Luke and I continued some testing on the IR sensor. We measured the current flow and voltage changes under different lighting conditions, then compared them to the documentation in the datasheet to ensure we understand how the sensor functions when working with multiple active sensors in the future.
A majority of the rest of this meeting was spent discussing the state diagram and phase actions with Michael to help him fill out the software overview. Our game states follow that similar to Magic the Gathering, which Michael hasn't played before, so we explained the basic orderings and concepts to him and plan to play a short game of Magic in the near future to help visualize the game states and card rules. At the end of our meeting, I made a 27"x26" cardboard cutout based on Owen's measurements to reference the dimensions of our game board so we could get a feel of how big our design will be. This will help us determine if we need to make changes to our initial layout and could impact the accessibility of our design. In the future, we will work on configuring our LCD touchscreen. With this, we can take its measurements into account for our final layout.
Entry 3: -----------------------------------------------------------------
Date: January 29thStart Time: 12:30pm
Duration: 2.00 hours
Today was ManLab #3. Luke gathered a couple IR Sensors for us to start learning how to use. We found the datasheet for the sensors we plan on using, then began testing one. Wiring up the sensor using 1.25V and 60mA from the power supply, we were able to get voltage readings based on the amount of light being received from the IR sensor. This helps set up our baseline for these sensors. We will later wire up multiple at a time to create a representation of how our card slots will work.
IR Sensor Datasheet
Next we had our team meeting with the instructor and our TA's. We were told to update our PSDR's to be more specific and to update our function description to include all hardware and software components of our design. Discussing with the team, I updated PSDR 1 & 3 to fit a more specific description based on the components we plan to use.
As a show-me-a-thing, I used the IR sensor we wired (see image below), as well as a mock up cardboard cover to show the voltage fluctuation depending on whether or not the sensor is receiving light or not. We will expand upon this in the future to include more sensors working together to determine card states.
Following our team meeting with the instructor, we discussed our game logic in more specifics. We finalized our phase order (P1 land placement, P1 attack phase, P2 defense phase) and some more specifics for the game. We landed on a mana system that is based on the current turn number. Each player starts with 1 mana on turn 1, then 2 mana on turn 2, etc. As for the attack phase, we decided that creature cards being place will not be able to attack on the same turn. This led to the case that if there are no cards available to attack, the phase will be skipped. In future meetings, we will iron out this gameplay loop and working on card interactions such as attacking.
Entry 2: -----------------------------------------------------------------
Date: January 28thStart Time: 5:20pm
Duration: 0.75 hours
Shorter team meeting after lecture to discuss software design in order to brainstorm for the Software Overview. Here we discussed game logic and the overall gameplay loop for our game. Referring to the image below, the top half includes our discussion of topics to go into the Sofware Overview. This included game phases, player health, card position/state, and possibly graphics. The bottom half includes our discussion of the gameplay loop where we decided on the order of phases for each player on their respective turns. This will help us in the future, as we can now focus more on how cards interact with one another with a set order of events.
Entry 1: -----------------------------------------------------------------
Date: January 25thStart Time: 8:00pm
Duration: 1.5 hours
Finished expected usage case and other constraints sections of Function Specification assignment (A2) in shared document and collaborated with tending to any grammatical or logical errors.
=============== Week 2: =================
Entry 2: -----------------------------------------------------------------
Date: January 23rdStart Time: 12:00pm
Duration: 4.5 hours
Today we met up with the goal of working on our Functional Specification assignment and to finalize the style of game we wanted to create. For the assignment, I chose to fill out Expected Usage Case section of the document and thinking about what kind of constraints our project may have for the Other Constraints section. I discussed with the team about how weather conditions may impact our design and whether lighting (being in a too bright or too dark room) would affect the IR sensors we wanted to use. A large portion of this meeting was spent brainstorming game logic and planning designs for our game board. We discussed different types of game style. One style was derived from a game called Marvel Snap where there are 3 total lanes and individual cards have power and skills. The player with the most power in a lane wins that lane, and winning 2/3 lanes wins the game after a set amount of turns. The other style we discussed involves a more interactive play-style through a style similar of Magic the Gathering. This would involve individual cards having health and damage, and the game having set phases to play cards or attack/defend. This is the way we wanted to create our game, as it proves to be more interactive and complex for the players.
I filled out multiple component checkout forms and we acquired RFID tags, and RFID sensor, an LCD touchscreen, and a Raspberry Pi 3. These will be the start to help begin prototyping and learning how to use all of these components.
Another discussion was had to decide which type of IR sensor we want to use and how it will work in our design. This will be used to check card position (location) and card activation (turning/tapping). We plan to use a system similar to that of the ECE362 keypad grid lab. In our next meeting, we plan to experiment with the components we acquired and begin designing a prototype. I also plan to go through the tutorials for KiCad within the coming week, as Luke did so earlier this week.
Entry 1: -----------------------------------------------------------------
Date: January 22ndStart Time: 12:30pm
Duration: 2.0 hours
Today was ManLab #2. For about the first hour of lab, We ran into some troubles with our team website. We had issues where changes to the html files either wouldn't work or they wouldn't show up modified on the team website for certain people. We were informed that this may have been a caching issue and opening the team website in an incognito browser would fix the problem. This did resolve the issue. Getting our team website figured out for the last time, we started working on the Functional Specification assignment. While reading through the assignment and getting to understand it, we were approached for a team meeting. In this meeting, the major thing we were informed to do was to update our PSDR's to be more specific. This will help us finalize our ideas and keep streamlined on our design. This led to the end of lab, so we will work on our Functional Specification in the next meeting.
=============== Week 1: =================
Entry 3: -----------------------------------------------------------------
Date: January 17thStart Time: 12:00pm
Duration: 2.0 hours
Today we met up with the purpose of completing our Final Project Proposal. We used a shared google docs to allow everyone to actively edit the proposal simultaneously. I filled out my team member expertise and we finalized our team roles. We collectively assigned the homework assignment responsibilities and researched for an estimated budget of our project. Finally, we attempted to finalize our PSDR's. To do this we tried to follow a similar format to that of the examples provided on Brightspace. Throughout working on the proposal, we came up with a new name for our game -- Grid Wars. We also discussed and brainstormed game logic ideas such as damage/health systems and what the win conditions could be such as personal player health or board wiping. In our next meeting, we plan to finalize our game logic and choose a specific win condition so we can begin prototyping.
Entry 2: -----------------------------------------------------------------
Date: January 16thStart Time: 5:25pm
Duration: 0.50 hours
We had a short meeting after lecture to finish setting up the team website and get everyone mapped to the network drive to be able to edit the html files on their personal devices. Luke and Owen were able to map the network drives without issue, but Michael and I were running into troubles. Michael later discovered that we could map the network as a folder, which fixed our issue and allowed me to have access to the team website. This will let me edit my personal journal and help keep the continuity of our team website.
Entry 1: -----------------------------------------------------------------
Date: January 15thStart Time: 12:30pm
Duration: 2.0 hours
This was the first ManLab of the semester, so today was spent as more of an introduction to the lab as opposed to working on our actual project. We had a team interview with the TA's where we explained our team's project idea so they could choose which teams they wanted to mentor. Once the interview was over, we had a tour of the lab where we were shown all of the available resources to help us in completing our designs. This helped me learn where to go for finding any potential components I may need for our prototype. Post-tour, Luke and Michael began setting up the team website while Owen and I brainstormed ideas in regards to how we wanted to scan in the cards in our design. We discussed between using QR codes, an overview camera system with image processing, and RFID tags with a scanner. We originally wanted to go with RFID, but we thought it was best to get an opinion from out TA mentor.