Posted on

Team Status Report for 10/11/2026

This week, we began the process of assembling our product/system, with Jeffrey and Matthew doing work on assembling the prototype wearable, and Haowen beginning development work with the ANT-B10 antenna array. Additionally, we all worked on the design review to finalize details of our planned implementation.

At this point, the most significant risks are pertaining to the accuracy of the measurements we will receive, as well as the timeline for our product. Both risks were accounted for in our planned implementation in our design report. Our accuracy can not be truly gauged until we can begin real-world testing, so we have invested in the development of the prototype wearable based on the same system to begin development early. The prototype development will also help our general timeline, as we can begin code development/system ingreation in parallel with the bringup of the PCB.

Since last week, the only major change ot our system design was the substitution of a Raspberry Pi 4 instead of an FPGA. This decision, which was elaborated in our design report, was conducted based on testing from this week. It does not represent a significant deviation from our timeline, as the code for the FPGA was not planned until later, so we can simply replace the FPGA programming to-do with programming the Pi. Pictured in the prototype wearable that Matthew and Jeffrey began assembly of.

 

Special Considerations:

 

Part A was written by Jeffrey Liu

Geographically, our product solution could have a global reach, as swimming is not a localized activity and is done at a high level throughout all continents. However, although nothing about our solution is local to the Pittsburgh area, some of our use case research was based on US specific information, such as NCAA guidance for practice duration and team size. That is not to say that it would negatively affect global users of our product, as our product could be applied well anywhere in the world, but the use case was catered towards U.S-specific guidelines. 

A larger impact may be found in the gap between those who are not technologically savvy and those who are. In our implementation, we are seeking to enable greater access to swimming metrics, aiding those who are less technologically savvy. In doing so, we are putting those with a medium technical proficiency on the same level of those with higher proficiency. However, in doing so, swimming teams with lower levels of technical proficiency may fall further behind, as they will not have access to information that more teams will now have access to. Similarly, this may negatively impact swimmers in teams or areas without the means to afford this solution. Although lower in cost than higher-end systems, the projected cost of our system (anchor + each wearable) may be beyond reach financially for certain teams

Part B was written by Matthew Kwee

Our project is designed to support a good team culture; we believe the system will improve the dynamic between coaches and swimmers during daily practices. Because coaches with stopwatches can only time one or two swimmers at any given moment, they can only realistically provide feedback to a handful of team members (usually the fastest swimmers), leaving other athletes with little feedback. By automatically tracking up to 50 swimmers at once, our system effectively performs the first, most tedious step of a coach’s analysis automatically, freeing up their time to focus on more detailed instruction. Slower, developing swimmers receive the same objective split times and stroke data as the top athletes, which we believe will foster a more inclusive and encouraging team environment.

The platform also should help athletes develop a better technical understanding of swimming. Having access to metrics like stroke rate, distance per stroke, and turn times will help driven swimmers understand how technique affects speed, allowing them to train smarter. However, continuous tracking can also cause stress if athletes feel they are constantly being watched and assessed. To prevent unnecessary performance anxiety and unhealthy peer comparison, the system includes privacy controls that lets teams turn off public leaderboards while allowing swimmers to see their personal improvement.

Part C was written by Haowen Huang

Our project is designed with both user safety and environmental impact in mind. It uses Bluetooth Low Energy to keep radio emissions low. The wearable tags are made with materials to help prevent skin irritation and keep unwanted materials out of the pool water.
To save energy, the system uses power-efficient firmware. This can extend battery life, reduce the need for replacements, and create less battery waste. Processing data locally also reduces the need to send information to remote servers.
The system also uses random delays between transmissions to reduce the chance of multiple tags sending signals at the same time. Its modular design makes it easier to repair or replace individual parts, such as wearable tags, base stations, and computing devices, without replacing the entire system. This helps the equipment last longer and reduces electronic waste.
Posted on

Jeffrey’s Status Report for 10/11/2026

Status Report for Oct 4-11

Accomplishments:

One of the major tasks I worked on this week was to reevaluate our team’s decision to use an FPGA, based on feedback from the design review presentation as well as additional research. To get more information, I ran a C testbench on the Linux core of the Ultra96, simulating the workload using mock data. The results showed that the Ultra96 was able to produce a low enough latency to where we don’t need to utilize an FPGA. To further solidify the decision, I also created a testbench and ran it on the Raspberry Pico, which was also able to perform our workload with a low enough latency. The results from the testbench and the prototype device are pictured. 

Additionally, some parts for the wearable prototype arrived, so I was able to work with Matthew to start assembling the wearable prototype. We have successfully connected the Pico with the power shim and the battery, so we are just waiting on some other components like the transceiver to arrive.

Additional work went into writing the design review document, which included doing further research to expand on our requirements and solution approach as well as the writing involved to document our project. Specifically, that included researching some of the last few small parts/connectors involved on our system to have a complete bill of materials. 

My progress is on schedule. Next week I hope to get the prototype wearable completely assembled, and possibly begin writing the firmware for it.

Posted on

Jeffrey’s Status Report for 10/3/2026

This week I made progress in various areas. Earlier in the week (mainly Sunday) I worked on polishing my presentation for the design review, including adding visuals to the slides, reducing/simplifying the text on the slides,  and practicing the presentation multiple times. I also made progress towards the development of the wearable prototype, which was one of my focuses this week. I finalized the decision of the charging shim to connect to the prototype board, and I received the Pico from Matthew that will power the prototype. I also finalized some other small components need for power conversion between the FPGA and ANT array. Some other components for the prototype including the wireless transceiver and the IMU have not yet arrived, so I was limited in making further progress. However, I believe those parts have been finalized/ordered by other members and should be in soon. Additionally, I received the power adapter for the FPGA, so I was able to power the FPGA and enable the Linux core to communicate with my laptop, which took some troubleshooting. But I now have the ability to communicate and send files to the Linux core via SSH. Lastly, based off of feedback from the design presentation on Wednesday, I decided to investigate more on the design decision to use an FPGA versus traditional computer. Conceptual research has given me mixed results, so I plan on benchmarking to get concrete numbers about the latency of each. I will write a C benchmark that will perform the tasks required of the FPGA, and run it on the FPGA’s ARM core. I will then compare the latency to that I get using simulated data on SystemVerilog code running on the FPGA. I am currently in the process of writing/debugging the C test suite for the ARM Core. This task has taken precedence, since I want to make a final decision for the design document.

 

 

In terms of timeline, I completed my task of 100% finalizing the prototype parts I’m responsible for. They will be ordered either Sunday or Saturday, pending some coordination for the DigiKey order. I was not able to test the FPGA-Pico connection, since the transceiver has not arrived yet. I hope to be able to do that next week. Next week I also hope to connect the modules of the prototype if the parts arrive, and finish my benchmarking of the C code versus SystemVerilog on the FPGA’s core and fabric.

Posted on

Jeffrey’s Status Report for 9/26/2026

This week, most of my effort went into researching, specifying, and validating our design details. Prior to this week, our design and implementation still had a lot of details up in the air, such as how our wearable device would be implemented and what components we were going to use. I conducted extensive research this week to determine specific parts, communication protocols, and organization of our system down to the component level to get a much better understanding of the specifics of our implementation. I also tried to make sure all the different parts were mutually compatible. Details I researched/validated include:

  • Decision to develop both a prototype wearable using off-the-shelf modules and a custom PCB for our final project. 
  • Choice to use a Raspberry Pico for prototype wearable versus Arduino due to better specifications (buffer storage, RAM) for our use case.
  • Choice of Pimoroni MCP73831 to handle power to prototype device
  • Choice of 3.7V 400mAh JST-PH LiPo battery to power prototype device.
  • Choice of Seeed XIAO RP2040 Plus as compute on PCB final product.
  • Choice to use 502025/502030 3.7V LiFePo battery on final product.
  • Worked with Haowen to advise about networking component choice regarding compatibility with Pico/FPGA.

For all these design choices, I researched the tradeoffs of the exact components, considered alternatives, made sure they could integrate well with the rest of the components, and found in-stock listings.

With all these design choices further considered, I now feel I have a much better understanding of the direction of our project. That was further solidified by my work on the content of our design review, including with the rough-sketch diagrams that are adapted for our slides. In preparing for the design review, I was led to really think through our complete design and do further research where necessary to confirm the soundness of our design decisions.

My progress on the schedule is not behind per se, but my role for the short term I feel is adapted a bit. Upon further research, the FPGA element may be better left for later while the implementation of the wearable prototype is taking more precedence. I took receipt of the physical FPGA, but the power supply is not in yet, so I can’t do much work in that department. That is why I took on work in researching the wearable prototype design, while Matthew is going to begin development on the wearable PCB.

In the next week, I hope to have all the parts I’m responsible for 100% confirmed and ordered. I am most of the way now, but some final compatibility/organizational checks with the rest of the team are in order before committing to the purchases. Depending on how soon parts arrive, I hope to be able to test a rudimentary communication between the FPGA and the networking module attached to the Pico. 

Posted on

Team Status Report for 9/19/2026

At this point, the most significant risks we foresee pertain to how quickly we can finalize some of the additional choices in our design, such as whether the wearable will utilize a microcontroller vs PCB and the components on the wearable such as the IMU, the voltage the devices will operate at, and the exact frequency band.

To manage these risks, we have assigned different areas of further research into the commercially available microcontrollers and components, and the optimal frequency to transmit at. In case our microcontroller/PCB decision ends up needing to be changed, we will still be able to test out components such as the radio transmitter on off the shelf components we have (Arduino).

We have not made any changes to the design of our system yet, as we are still working to finalize some of the final pieces of our initial design. No changes to our schedule have occurred.

 

Posted on

Jeffrey’s Status Report for 9/19/2026

Accomplishments:

My accomplishments this week were in the preparation of our proposal slides, as well as individual research into the FPGA aspects of our project. Prior to Monday, I worked on synthesizing the details and feedback we received on our abstract, identifying potential gaps in our abstract, and researching further specifics to build on and quantify our use case/requirements/implementation. That enabled my contributions towards my sections of the slide deck. After Monday, I continued doing research and gathering data to finalize the FPGA selection. I did extensive research into FPGA options; particularly the options provided by the 18-500 parts inventory. Based on factors like the included FPGA, large onboard memory, and support with AMD Vivado, I decided on the Ultra96-V2 as the best FPGA for our purpose, and I have finalized that decision by submitting the order form. Since we have a top candidate for the wireless transmitter, I also have done further research into the packet structure and have a preliminary plan. Some of the finer details such as bit endianness can change later on, but in general I have a plan for the components of the packet, given the 32 byte constraint of the transmitter.

 

Progress:

My progress is mostly on schedule, as my main focus for this week was researching the FPGA design tradeoffs and finalizing the FPGA selection as well as finalizing the packet format. Both are mostly completed (the packet format may change to adapt to technical challenges later on, but we have a plan for now). 

 

Deliverables: 

My task for the next week is to establish a data link from the radio module to the FPGA. The goal is just a simple data link to show that the flow of data is being recognized, without any complicated packet handling yet. I will need to work with Haowen on that part, as the wireless transmitter falls under her scope too. In doing so, I will also see some of the technical challenges we might face later on, which will help guide further research as well as help adjust the timeline if needed.

Posted on

Matthew Kwee – Status Report for 9/19

This week, I worked on the project proposal presentation slides with my teammates and began drafting the specifications for the web-app: historical data, the dashboard, and other insights. The web-app must be optimized for a mobile device (tablet/smartphone) since a swim coach can’t be expected to carry a PC while monitoring swimmers. Because the coach’s attention will be focused primarily on the team, the website’s UI should be simple to understand and use, allowing easy navigation and handling for minimal distraction.

In the coming week, I will be implementing the base web-app and determining the wearable device’s ideal dimensions. Our initial concept is a watch-like device that can be worn around the wrist – like all other aspects of this project, we want to design it such that its users can forget about it and focus on their primary goal: training. Additionally, I plan on researching and comparing the necessary components for the wearable with my team as we settle on a design for the prototypes.