Alexis’s Status Report for 3/8

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

This week I help set up the infrastructure for 6 blocks where I soldered the battery case to the adapters and added on wires for GND, TX, and RX for the LCD to pogo pin. We received the rest of the items so I was able able to cut pref boards and solder all the pogo pin pairs onto their respective boards. In addition, I was able to laser cut the LCD opening at the top of the block as well as the pogo pin and USB-C charging port at the bottom. I first experimented with card board and did it on one block after creating the cuts on ink scape software that is compatible with the rabbit laser cutters in tech spark. From that experience I was able to extrapolate the best settings for the acrylic cubes that we had. For now based on how long it took to manufacture just a row of blocks I feel that a PCB is not needed at the moment and so I am focusing my efforts on other things such as CAD for the grid and for the holder of the components inside the block. On the software side, we discussed handshaking signals and functions that would be used / called between game controller and embedded controller to ensure that we are all on the same page as we are developing.

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

I am currently on schedule with my progress! There is an added need for a 3D printed holder of components in the blocks but that will be accounted for with the time that was originally allocated for the PCB constrution.

What deliverables do you hope to complete in the next week?

I hope to finish laser cutting the rest of the blocks this week, come up with a CAD for the holder of components inside each block, and I would establish a full working row with the submit button in conjunction.

Alexis’s Status Report for 2/22

What did you personally accomplish this week on the project? Give files or
photos that demonstrate your progress. Prove to the reader that you put sufficient
effort into the project over the course of the week (12+ hours).

This week I worked on the hardware, prototyping, and communications. I manually soldered the pogo pins onto cut pref boards as the pins were too small to fit on a standard bread board. This was done for just two blocks I then wanted to test the continuity of the pins and wires connected to it so at first I did a simple test with a multi-meter and later on I tested through the UART TX and RX line. I also created a cardboard 3″x3″x3″ with cutouts for the pogo pins, the standard LCD that we had available, and on/off switch for battery. From this cardboard prototype we were able to determine that all the parts we initially planned for would all fit. I also put together the power system and tested it by plugging the micro-usb b into the port of the Rpi to which it was able to turn on. With the initial layout going according to our original plan we felt that we could now order all the remaining parts to build all of the 8 blocks that we need for MVP. We bought acrylic boxes that are 3″x3″x3″ and we got a rough weight of what the blocks feel like and we are on track to meet our dimension and weight design requirements. On the software side, I was able to set up UART between Rpi and the Rpi pico via the pogo pin connection. I did a simple test of sending and receiving a message that is printed onto the console while Wen Hui added more logic to it for a proper protocol. Though I haven’t measured the exact latency we found that it was fairly fast and which I meets our design requirements as well. I am currently working on using the new LCD that we received from wave share on Friday and interfacing with the LCD library.

Is your progress on schedule or behind? If you are behind, what actions will be
taken to catch up to the project schedule?

My progress is on schedule. This week was a good determination of whether we needed the PCBs for the blocks and we settled on a plan that I would create a PCB that is on “hold”. After manually building 2 blocks and timing it, we will determine if we need to place the order for these or if we have enough time to just manufacture each ourselves. We will also look into PCB milling at Techspark. But as of right now we are on track!

What deliverables do you hope to complete in the next week?
The deliverables that I have for next week is to get a full E2E of 2 blocks communicating with the Rpi via the multiplexer and laser cut all of the blocks for the ports and slots that we need as well as the battery holders. It would be ideal to get 1 full row working as well. I will work on interfacing with the LCDs on each block and the design for the PCB. I will also produce a CAD for the grid and assemble it when we can ensure everything will fit based on the row we produce.

Alexis’s Status Report for 2/15

This week I worked on the Design Review Slides, making tables to compare the different communication protocols and microcontrollers that we looked at which ultimately helped us decide on what we wanted to move forward with. I also help to quantify our tests and draw connections to our requirements so that we can better measure our success. I also updated some of the diagrams in the solution approach and the power block diagram to reflect the components that we are going to be prototyping with. As for the Rpi, I helped Wen Hui boot up the OS and set up Real VNC viewer. Also, I made CAD models of our proposed block and planned where we will need to make cut outs for the ports and switch of the battery. I also helped order parts this week and acquire some scrap materials to help us make an initial prototype for next week. Also, I went to Techspark to solder jumper cables onto our battery holders, buttons, and header pins on row LCD to make prototyping easier.


My progress is slightly behind schedule according to our initial gantt chart because we need all the parts to come in before we decide if we actually need a PCB or not. For now I am just modeling where things will go and am planning out what the inside of the block will look like so that maybe we can just 3D print holders for all our components if a PCB is not necessary. I am shifting my focus into preparing as much parts as I can so that we could easily merge things together for prototyping a block.

My deliverables for next week is to create a mock on the block in its entirety with a plan for where each component will lie in the block. I also will work on establishing the UART protocol between the Rpi and Rpi pico as well as get the 2 row LCDs working so that we can display the proper category and flash it with a particular color. After getting all the parts I’ll also decide if a PCB is needed or not. If it is needed I will research the etching machines that are down in techspark for faster PCB development.

Team Status Report for 2/15

This week we mainly took on creating the Design Review slides. For the Design Review slides, we discussed and created the game flow logic in which we made FSMs and flow diagrams to explain our process in more detail. The more high level flow diagrams were created for the slides and the more detailed ones will be reserved for the Design Review document. We researched many different components and discussed them largely, coming up with the design requirements for Connexus. We also looked into timing and clarified our testing strategy so that we could better measure our success in meeting our requirements.

We ordered our 1st batch of parts and the most significant risk at this point was obtaining parts that would create a functional block as well as meet our dimension and weight requirements. This risk is being managed by ordering our parts in batches and buying enough to build 2 blocks to ensure that all the components that we selected will work well together. We will move fast with initial developments and use the built in slack time if necessary in the event that we need to order different parts. Also, one of the LCDs that we initially put out an order for was on the banned list of vendors and this helped narrow down our options of microcontrollers. The initial order of LCD included an already integrated LCD with ESP32 and at a fairly low cost for the abundant features we could implement like touch screen once we reach MVP. However, due to that ban, we decided to go back to a low-level and just buy components that are readily available to avoid a back and forth on that component we originally wanted. Now we have narrowed the microcontroller to an Rpi Pico which was the one we wanted to do in the proposal so our plans haven’t exactly strayed far. We then found an LCD that perfectly aligns with the Rpi Pico which would reduce wiring and allow for more compact layout when we place it in the cube. This option was also cheaper which allows us more wiggle room with budget when we have completed the MVP and want to move onto having all 16 blocks.

Our schedule has updated as we ordered parts slightly later than we had wanted to and we were also waiting for them. While waiting for parts CAD models can only be made to mock the system, but we felt that the actual building/assembling of the block and grid should wait until all the components are in and we confirm that their sizes are as true as their documentation says. We shifted the focus to flushing out the web app and doing as much as we can there as we wait for parts. The website has most of the pages setup and also functionality for uploading custom words. In addition, we are looking into various Rpi libraries that would help with development. Since we borrowed the Rpi 5, we immediately were able to use it so we just booted the OS and set up a remote virtual machine through Real VNC viewer so that we could all access the Rpi with ease. We soldered jumper cables onto some of our parts to help with prototyping when all the parts we need to make an initial block come in. For next week we will focus on establishing our communication protocol and also test that connect through the pogo pins that we bought. We will also swap out the temporary API calls from the free dictionary API to the Merriam-Webster API once we are able to register our App with them. Also we will build 2 blocks out of cardboard to get the initial dimensions before we decide on ordering acrylic cubes as well as a fake grid slot holder to connect blocks to the main Rpi.

Website Interim Demo

Part A written by Alexis Duong
Connexus is enjoyable instead of being frustrating as many novice players and English Language Learners (ELL) might feel while playing NYT Connections. It not only engages a user’s mind but it offers a physical interaction that would entice the user’s sense of touch and sight that is not offered with Connections. We hope that Connexus can be fun to play with and boost a person’s mood so that they leave the experience more happy and satisfied than when they started. Connexus ensures safety through electrical isolation of our circuitry and the user. The grid will contain some electrical components in a separate layer inside the hollowed out part of the grid so that electrical components are not exposed to the user and are insulated in that manner. The blocks themselves will be easy to hold and the user will only have access to the charging port as well as an on/off switch for the blocks so that they can de-power the system if they sense any hazards. We want the users to feel safe while playing the game and will therefore make sure that all electrical hazards are accounted for so that the user can focus on just having fun. In terms of welfare, Connexus is a game that sparks mental and physical engagement that is educational for the user and it can be a break from staring at a screen all the time as most people tend to do these days. NYT Connections is online and having to stare at blocks on a screen while you are thinking of a solution isn’t particularly the best as this can cause further eye strain for the users. Connexus helps to remind people to take a break from their screens and enjoy playing a game in real-life!

Part B written by Wen Hui Leng
Connexus is based on NYT Connections which is an American English word game. To perform well in the game, players would require an extensive knowledge of vocabulary to understand the double meaning of words and also be familiar with American cultural references to understand the context in which some of the words might be used. Our game, Connexus, targets novice players and English Language Learners. We aim to make the word game more accessible by having a virtual companion that provides hints and assistance to the player in solving the puzzle. These hints are in terms of word definitions and clarifications on American cultural references. Having the virtual companion would allow these players who might initially feel discouraged when playing NYT Connections to have the ability to learn more about the meaning behind the words and solve the puzzle as well. This ultimately makes the word game a lot more inclusive and accessible to players from all backgrounds. Additionally, we also aim to include a custom word upload feature on the virtual companion. If the actual NYT connections are too difficult, ELLs would still be able to utilize our game by uploading their own words. This would allow ELLs to utilize this engaging game to learn new vocabulary in English in a fun and interactive way. Having physical blocks that players can interact with is also more engaging and fun, hence targeting certain users who might have low attention spans or are tactile-based learners. This will allow them to enjoy playing Connections as much as those who play the online version of the game.

Part C written by Nicole Feng
Connexus is marketed towards novice NYT Connections players and English Language Learners (ELL) as a game that is more interactive and less frustrating to play than the current NYT Connections game. Thus, novices and ELLs would be the main audience purchasing or consuming our product. English is the number one language that people learn on DuoLingo, and is taught as a second language in many countries as it is widely considered the current global language. Our product is a tool that makes learning English more fun as it is wrapped up in a physical game that users can play, so we anticipate Connexus being able to satisfy the need for engaging English-learning tools. Additionally, the parts used to make Connexus are common electrical components (LCD displays, batteries, microcontrollers, etc.) and manufacturing materials (acrylic, wood, etc.). Acquiring these parts to manufacture our product shouldn’t really pose a problem since they are widely available and relatively inexpensive, so producing and distributing Connexus would be very doable and would contribute to the economic sectors related to electrical consumer goods.

Alexis’ Status Report for 2/8

This week, I helped finalize several key aspects of our project. After researching LCD options, I identified models with integrated ESP32 (IC) that perfectly suit our needs and offer enhanced functionality. I contributed to developing the narrative for our project proposals and conducted comprehensive research on required components. We have decided to order the LCDs before the actual blocks and prototype with cardboard or similar so that we can determine the final dimensions after everything is put together. I made a trip to techspark to ask about the possibility of laser cutting slots in our pre-made acrylic blocks. I asked about the possibility of drilling too for more complex areas. We devised a plan to be able to do this without too much drilling. I also submitted a borrow request for the Raspberry Pi 5 and picked it up from the receiving office.

Additionally, I explored the possibility of implementing a rechargeable circuit system. The concept involved using a power path IC with a LiPo battery for power management, where the blocks would charge when connected to the grid and switch to battery power when disconnected, ensuring uninterrupted power supply. However, I ultimately decided against this approach as of right now due to the complexity of the circuitry and the time it would take to prototyping and testing. Given our timeline constraints and the need for reliable power delivery, I believe that sticking with a known, absolute power supply solution with the 9V batteries would be best and so I found all the necessary components to make this happen.

Diagram of Power on block

I am on schedule with all of my tasks. Next week I hope to finish selecting the LCD, order all of our preliminary parts, start a PCB (if we decide this is still necessary as this will depend on what LCD + MCU on the block we are getting), and finish the CAD of the blocks and grid maybe even create a mock model out of cardboard for our blocks and use an LCD I already have to get the rows working.