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

Haowen’s Weekly Status Report for Week 7

Accomplishments

This week, I focused on setting up the development environment and checking the ANT-B10. I installed the nRF Connect SDK (v2.6+) and the required toolchain dependencies. I also spent time fixing local path and driver issues to get the environment working properly.

After receiving the u-blox ANT-B10 antenna array, I checked the board for any visible damage and powered it on through USB to make sure it was working. I also reviewed the datasheet to locate the SWD and UART pins for future connections. Finally, I ran basic checks to confirm that the development tools could compile and flash test programs successfully. I spent around 12 hours on SDK setup, troubleshooting, reading documentation, and initial hardware checks.

Schedule Status

On schedule. Since the material hasn’t arrived yet, this week was mainly spent getting the development environment ready and checking the board. This should make it easier to move on to wiring and communication tests next week.

Next Week’s Deliverables

  1. Connect the external SWD programmer and USB-to-TTL adapter to the ANT-B10 board and check whether it produces stable serial output.
  2. Establish UART communication at 115200 baud and test basic AT commands to confirm that the ANT-B10 responds correctly.
  3. Set up the nRF-based tag to broadcast BLE packets at 20 Hz with Constant Tone Extension (CTE).
  4. Configure the ANT-B10 to scan for and receive CTE packets from the tag.
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

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

Haowen’s Weekly Status Report for Week 6

Accomplishment

Focused on getting our basic development environment set up and making sure the physical boards work. Installed VS Code, nRF Connect SDK (v2.6+), and toolchain dependencies, spending a good chunk of time troubleshooting local path issues and drivers. Unboxed the u-blox ANT-B10 antenna array and RPi Pico WH, checked the boards for any physical defects, and powered them up via USB to confirm power LEDs were solid. Cross-referenced the ANT-B10 datasheet to identify the SWD and UART pin headers for future wiring. Ended the week by running a basic LED blink / Hello World sanity check on the boards to ensure neither came dead-on-arrival (DOA) and our local toolchains can compile binaries properly. Spent around 12 hours total across SDK setup, troubleshooting environment paths, reading datasheets, and initial board verification.

Schedule Status

On schedule. Materials arrived mid-week, so keeping this week focused on environment setup and basic check sets us up smoothly without rushing into complex wiring.

Next week’s deliverables

  1. Wire up the external SWD programmer and USB-TTL adapter to the ANT-B10 bare board and confirm stable serial log output.

  2. Set up the RPi Pico WH to broadcast 20 Hz BLE packets with CTE (Constant Tone Extension).

  3. Flash the Nordic direction_finding RX sample to the ANT-B10 and check for raw angle output over UART.

Posted on

Matthew Kwee – Status Report for 10/3

This week, I worked on the design presentation slides with my team and compared IMUs for our product. I decided on the ST LSM6DSOX ($5.30 at the time of writing) for its low power requirements, which draws only 0.5mA (~1.7mW @ 3.3V) in high-performance mode (many comparable IMUs draw around 1-3mA). One downside is that it outputs raw acceleration/gyroscopic/temperature data, likely requiring us to process it into real-world values on the compute unit.

Two alternatives I rejected were the Bosch BNO085/086 and the ST LSM6DS3TR-C.

– The Bosch BNO085/086 was designed specifically for use in wearable devices and calculates acceleration and quaternions on-chip, but its relatively high power draw (10-15mA) made it too costly for our device’s limited battery life to utilize. While not directly useful, the temperature data from the ST LSM6DSOX will allow us to optimize the thickness of the wearable’s casing if overheating ever becomes a problem.

– The ST LSM6DS3TR-C is a simpler, cheaper chip that can carry out many of the functions that the ST LSM6DSOX can, and would definitely work as our device’s IMU. However, it draws significantly more power, and its measurements are noisier. As such, I decided that the ST LSM6DSOX for our IMU.

For our prototype, we will be ordering the IMU on a breakout board. While buying them separately would save about $7 on our budget, I am not confident in my surface-mount soldering ability – failure might require us to purchase a second or third chip. The prototype does not have the strict size limitations of the final wearable (for which we will order the full PCB assembled by a manufacturer), as it will be used primarily to collect data. Comfort is secondary with the prototype; as long as it can be strapped to one’s forearm, its size is acceptable.

I am not behind schedule, but will work to ensure I do not fall behind.

By next week, I hope to have the webapp’s history tracker implemented.

In two weeks, I would like to have the device prototype completed so that we can gather motion data for use in the compute station.

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

Haowen’s Weekly Status Report (Week 5)

Executive Summary

This week, I conducted in-depth feasibility research on our BLE 5.1/5.2 Angle of Arrival (AoA) tracking pipeline, clarified the system data flow across team roles, and validated the hardware stack integration plan for our incoming components.

By offloading raw microwave-frequency switching and phase demodulation directly to dedicated silicon, we confirmed a low-complexity architecture that avoids sub-nanosecond FPGA timing constraints while delivering reliable angle metrics.

Key Accomplishments This Week

1. Architecture Research & Technical Feasibility

  • Silicon-Level AoA Offloading: Researched the Nordic nRF5340 + u-blox ANT-B10 hardware pipeline. Confirmed that the nRF5340 Network Core executes CTE (Constant Tone Extension) I/Q sampling natively in silicon via Nordic’s direction_finding_connectionless_rx SDK module, outputting processed scalar angles over UART rather than raw high-frequency RF vectors.
  • Comparative Trade-off Analysis: Evaluated alternative approaches (e.g., direct FPGA RF sampling and UWB). Concluded that 2.4 GHz BLE AoA using our off-the-shelf kit provides the optimal balance of power, cost, and reduced timing complexity for a water/poolside environment.

2. System Data Flow & Team Alignment

  • Wearable vs. Base Station Setup: Clarified the hardware topology across Signal, Hardware, and Software sub-teams:
    • Wearable Tag (Swimmer): A lightweight transmitter (Pico + BLE radio emitting standard CTE frames) with no heavy compute overhead.
    • Base Station (Poolside): Fixed u-blox ANT-B10 8-antenna array connected to the nRF5340-DK, streaming angle scalars over a 3-wire hardware UART link (TX, RX, GND) at 115200 baud to the processing core.
  • Multipath Noise Strategy: Designed a two-stage embedded filtering pipeline (Median Filter for splash outlier removal + Moving Average for trajectory smoothing) to mitigate surface water reflections.

3. Development Setup Preparation

  • Unboxed arriving hardware components (nRF5340-DK, u-blox ANT-B10, Pico WH) and prepped the nRF Connect SDK environment for VS Code.

Next Week’s Goals (Planned Tasks)

  1. Hardware Benchmarking & “Hello World” Test: Assemble the ANT-B10 board onto the nRF5340-DK, flash the official SDK sample code, and verify raw Azimuth/Elevation scalar outputs via a serial terminal during walking tests.
  2. UART Pipeline Integration: Wire the nRF5340-DK to the Pico WH over hardware UART and establish basic packet receiving logic.
  3. Draft UART Packet Protocol: Define the binary/JSON payload structure for streaming filtered coordinates downstream to the Software team’s dashboard.
Posted on

Matthew Kwee – Status Report for 9/26

This week, I started coding the webapp (GitHub link), as per our ideal schedule. Brainstorming the site specifications took longer than I expected, but I was able to make decent progress in setting up the relevant architecture/libraries and building the UI.

This project is intended to provide a low-cost, low-config web and telemetry application that ingests positioning and inertial data from swimmer wearables and poolside compute, extracts biomechanical and split metrics in real time, and presents actionable data to coaches standing on a wet pool deck via standard consumer tablets.

When considering how the site should function, I took into account:

 

  • Wet-Deck Ergonomics and Water Splashes:

Water droplets, wet hands, and poolside humidity can cause unexpected inputs on mobile touchscreens. To mitigate this issue, I constructed a mobile-friendly UI with large, easy-to-find buttons. Additionally, I implemented a “lock” function that disables all screen inputs while keeping data live, unlocked only by a deliberate 2-second press-and-hold gesture.

 

  • Direct Sunlight and Outdoor Visibility:

Standard dark interfaces or subtle gray text are completely washed out by glare and midday sun at outdoor pools. I added an alternate Outdoor High-Contrast Mode with a monochrome light palette and thick solid black borders to maximize visibility, while allowing users to choose between it and a lower-contrast Indoor Mode.

 

Display Sleeping after inactivity:

Many tablets will automatically sleep after a few minutes of inactivity – coaches cannot be expected to repeatedly tap the screen to keep it awake. Fortunately, modern browsers provide a Screen Wake-Lock API that keeps tablet displays awake indefinitely while active – I added a toggle that enables/disables this API.

 

Wireless Jitter and Out-of-Order Sensor Packets:

RF signals around water tend to reflect or scatter, causing packets to arrive out of chronological order or duplicate unpredictably. While the physical poolside central compute unit will deal with the interference when receiving data from the wearable devices, we cannot guarantee that the packets it broadcasts for the web-app will not also be distorted. As such, a stream-level Jitter Buffer was added to the ingestion pipeline to reorder packets by sequence ID, discard duplicates, and smoothly flush packets to the analytics engine.

 

  • Inaccurate Splits on “Soft-Touch” Finishes:

When tired, swimmers may finish a set with a gentle glide rather than a violent slap against the wall – as such, the wearable device may not be able to determine when the swimmer completes the lap. To address this, I implemented a Timestamp Backtracking Algorithm to scan through recent position and velocity history once a wall dwell is verified, finding when speed drops below 0.2m/s (value subject to change).

 

Rapid Staging and Hardware Swaps:

Coaches will only have a few minutes before practice to assign wearable devices to their swimmers, and must have the ability to switch out tags for any reason (malfunctioning, low battery, swimmer leaving practice early, etc.) so a 3-Tap Pairing Workflow (tag -> swimmer -> lane) and a 1-Tap Swap Tag Menu were implemented, allowing a coach to quickly assign a name to a tag, or re-assign a tag mid-session.

 

(Apologies for the poor image quality; WordPress has a 2MB file size limit)

AI was consulted for the site’s frontend, especially the stylesheet and UI, since I have little experience in UI design.

While the website still needs more work, I plan to take a break from software development next week to focus on the wearable device; we need to finish a prototype wearable and start gathering real data before we can test the compute unit and webapp.