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.

 

 

 

 

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

Haowen’s Weekly Status Report (Week 4)

Accomplishments

  • Reviewed the finalized NRF24L01+ wireless module datasheet and documentation to identify power, RF, and integration requirements.
  • Researched antenna placement and enclosure thickness guidelines to inform the wireless enclosure design.
  • Identified key power and RF considerations, including the 3.3V supply requirement, power stabilization, RF channel matching, and Wi-Fi interference avoidance.

Progress / Next Steps

  • Finalized the wireless module selection and established baseline electrical/RF requirements.
  • Use the identified antenna and enclosure constraints to evaluate candidate enclosure materials and dimensions.
  • Next, prototype the wireless module in the proposed enclosure and validate communication reliability and range.

Deliverables

  • Documented NRF24L01+ module specifications and integration requirements.
  • Compiled preliminary antenna placement and enclosure design guidelines.
  • Established initial wireless design constraints:
    • Supply voltage: 3.3V
    • Power stabilization: 10 µF capacitor across VCC and GND
    • RF configuration: Matching channels between transmitter and receiver
    • Interference: Avoid RF channels 2–4 due to overlap with common Wi-Fi bands
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.