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

Team Status Report for 10/3

Overall Summary:

This week, we delivered our design review presentation and focused on component selection, toolchain configuration, and prototyping our initial development hardware. We verified the functionality of our core dev boards (u-blox ANT-B10, Raspberry Pi Pico WH, and FPGA), established communication with the FPGA’s Linux core via SSH, and finalized key wearable components, such as selecting the low-power ST LSM6DSOX IMU on a breakout board to de-risk prototype assembly. We also set up our Nordic direction-finding software environment. Our project is on schedule for fabricating the prototype next week to gather data.

Key Progress

Design Presentation:

Haowen + Matthew: Assisted in writing the Design Presentation slide deck.

Jeffrey: Wrote and delivered the Design Presentation on Wednesday.

Signals:

Haowen: Unboxed and verified the u-blox ANT-B10 antenna array, mapped SWD and UART pin headers, and configured the nRF Connect SDK environment to prepare for flashing the direction-finding firmware and testing 20 Hz BLE Constant Tone Extension (CTE) packet broadcasts from the Pico WH.

Software:

Matthew: Maintained development trajectory for the web platform’s upcoming historical data portal, setting up infrastructure for serving performance insights to users.

Jeffrey: Established SSH access to the FPGA’s Linux environment and began implementing a C benchmark suite on the ARM core to evaluate processing latency against FPGA SystemVerilog logic.

Hardware:

Matthew: Evaluated multiple IMUs and selected the ST LSM6DSOX 6-axis chip for its ultra-low power consumption (~0.5 mA) and decently low output error.

Jeffrey: Validated basic power and GPIO operation across all received microcontroller boards.

New Risks + Mitigation: Dead Reckoning Drift vs Angle of Arrival Inaccuracy

Tracking swimmer position down the lane relies on combining wearable IMU dead reckoning with Bluetooth Angle of Arrival (AoA) direction finding at the poolside base station. However, both modalities face compounding error sources. Dead reckoning suffers from exponential integration drift within seconds of forward swimming, while AoA suffers from signals reflecting off the water’s surface, and periodic signal loss when the wearable is submerged

We plan to manage these issues through a combination of the two systems:

1. Swimmers should be physically restricted to linear lanes, and cannot deviate from a 1D line by more than 1.5m. Rather than solving for 2D/3D positions, we will project AoA angle rays directly onto the swimmer’s known 1D lane vector.
2. The continuous IMU dead reckoning model will be updated periodically whenever the wearable surfaces and transmits a valid AoA packet.
3. Zero-Velocity Reset: Every time the IMU detects an impulse from a swimmer pushing off the wall, their spatial position and velocity will be hard-reset to the known physical pool boundary, clearing all accumulated dead-reckoning drift every lap.

 

No significant changes to the schedule were made at this point in time.

Posted on

Team Status Report for Week 5

Executive Summary

This week, we locked down our hardware choices, set up the web dashboard UI, and validated our BLE 5.1 Angle of Arrival (AoA) pipeline. Offloading RF processing to Nordic silicon avoids complex FPGA timing work. Next week, we’ll focus on assembling the wearable prototype to collect real telemetry data.

Key Progress

  • Signal (Haowen): Confirmed the nRF5340 Network Core handles BLE CTE sampling in hardware, outputting clean angle scalars over UART (115200 baud). Designed a 2-stage filter (Median + Moving Average) to handle water surface multipath. Unboxed the nRF5340-DK, ANT-B10, and Pico WH, and prepped the nRF SDK in VS Code.
  • Software (Matthew): Set up the web app repo and built a poolside-friendly UI featuring an Outdoor High-Contrast mode, a 2-second touch-lock screen, and Wake-Lock API integration. Added a stream-level Jitter Buffer for out-of-order packets and built a 3-tap tag pairing menu.
  • Hardware (Jeffrey): Established a two-phase wearable strategy (off-the-shelf prototype -> custom PCB). Selected Raspberry Pi Pico + Pimoroni MCP73831 for the prototype and XIAO RP2040 Plus + LiFePO4 battery for the final PCB. Created architecture diagrams for the design review.

Risks & Mitigations

  • Shipping & Power Supply Delays: FPGA power supply is delayed -> Mitigated by using off-the-shelf Pico WH and nRF5340-DK boards to assemble the wearable prototype first.
  • Water Surface Reflections: Splashes cause signal jitter -> Mitigated via Median filtering on compute and a Jitter Buffer on the web app.

Considerations

Part A was written by Jeffrey Liu:

We don’t expect our product to have too much of a direct impact on public health, safety, and welfare. One could make the argument that since exercise is good for health, by making a device that improves the swimming experience and improves coaches’ ability to train swimmers, that there will be a broad benefit to public health by encouraging more people to exercise and stay healthy. Swimming is also an important survival skill in certain areas, so encouraging swimming may help public health in that regard. With regards to safety, our main concern with our project is that there is no safety hazard to the users. In our case, the primary safety consideration would be that the wearable device needs to have a battery. With that in mind, our battery choice of a LiFePo battery is among the safest lithium-ion battery chemistries that is available and we will keep battery safety in mind when designing the surround circuitry. Additionally, the material we will make sure is skin-safe in water, as it will be worn for prolonged times. Our project is probably least applicable to welfare, as swimming training/guidance is not a basic provision that people need to survive.

Part B is written by Matthew Kwee:

Our platform addresses technological and socioeconomic disparities across competitive swimming. Swimming has a well-documented resource divide: elite collegiate programs and affluent private clubs can afford multi-thousand-dollar camera rigs, underwater timing gates, and dedicated biomechanics staff, while municipal clubs and public high schools rely solely on hand-held stopwatches and visual estimates. By delivering accessible, low-cost tracking, our project democratizes sports analytics. This lowers the barrier to data-driven coaching for underfunded teams, fostering greater competitive equity across different socioeconomic communities.

Our system also meaningfully alters coach-athlete dynamics. In a typical practice with 20 to 30 swimmers circling in crowded lanes, a coach can realistically only focus their stopwatch and feedback on one or two athletes at a time. This naturally leads to unintentional disparities in attention and may result in perceived bias. By providing simultaneous, automated metrics across all lanes, coaches can distribute attention and constructive feedback much more equitably, building a fairer and more supportive team training environment.

We must also consider the social and psychological impact of continuous performance surveillance on young athletes. In high-pressure sports environments, constant metric tracking and public leaderboards can sometimes foster unhealthy peer comparison, burnout, or anxiety. To protect team culture and swimmer well-being, we will design the software around configurable privacy controls. Coaches can decide whether performance data is shared openly on a team board to foster healthy camaraderie, or kept private between the individual swimmer and the coaches to focus purely on personal development.

Part C is written by Haowen Huang:

For our project, economic considerations directly shaped our choice of hardware, aiming to deliver high-precision tracking without the prohibitive price tag of existing solutions. By using commercial off-the-shelf components (Nordic nRF5340, u-blox ANT-B10 array, and Raspberry Pi Pico), we avoided the heavy development and production costs of custom ASICs or sub-nanosecond FPGA hardware. This keeps both our prototyping expenses and eventual unit manufacturing costs low. Our system also fills a major cost gap in sports analytics. Existing swimmer-tracking tech usually relies on optical camera rigs or underwater timing systems that cost thousands of dollars, putting them out of reach for most high school programs or local swim clubs. Using BLE 5.1/5.2 Angle of Arrival lets us deliver real-time spatial data at a fraction of the hardware cost, making data-driven coaching accessible to smaller teams with tighter budgets. Finally, long-term maintenance costs are kept low through a modular design. The wearable tag uses an energy-efficient microcontroller and a rechargeable battery to extend hardware lifespan. Because individual tags are cheap and easy to swap out, a damaged or depleted tag can be replaced on the spot without replacing or reconfiguring the poolside base station.

Next Week’s Goals

  1. Signal (Haowen): Flash the nRF5340 SDK Rx sample, verify raw angle output over UART, and wire it to the Pico WH.
  2. Software (Matthew): Pause web development temporarily to assist Jeffrey with physical wearable assembly and data logging setup.
  3. Hardware (Jeffrey): Place orders for verified prototype/PCB parts and assemble the initial wearable prototype once parts arrive.
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.