Felipe Status Report for 10/18/26

What was done

This week, I was focused on the design report, covering the system architecture and project management plan. I documented the signal path from the visual stimuli and EEG electrodes through the ADS1299, ESP32-S3, and mobile application. This included SPI data acquisition, embedded filtering and CCA classification, confidence-based command rejection, and BLE transmission for spoken output.

For project management, I outlined the development schedule, team responsibilities, integration milestones, preliminary budget, and fabrication plans. I also documented technical risks and mitigation strategies for EEG signal quality, PCB issues, and classification performance, including potential fallback approaches.

Alongside the report, I worked on ESP32-S3 firmware for BLE communication with the mobile application and the SPI software interface with the ADS1299. This work focused on supporting wireless command transmission and establishing the communication routines needed for ADC configuration and EEG data acquisition.

I also finished gathering models for 3D Printing and should have a headset prototype by end of week.

Next Week

I plan on helping with the PCB and getting an MVP of the mobile app done.

Atharv Kashyap’s Status Report for 10/18/2026

Atharv Kashyap‘s Status Report for 10/18/2026

This week, the main focus was on getting my design report sections complete, accurate, and well-formatted on LaTeX. But outside of that, I also focused on validating the SSVEP classification pipeline I wrote last week in Python by using real EEG recordings from the Wang et al. dataset. I limited it as the dataset was way too big to accomodate on my device. I also prepared the decoder for deployment on the ESP32-S3. This included working on dataset integration, signal processing, testing, and the C++ implementation.

Previously, I had developed and tested our Python-based EEG decoder using synthetic signals. This week, I downloaded and integrated the Wang et al. (2017) SSVEP benchmark dataset to test whether the pipeline could classify the actual brain signals. To match what we want to achieve and also limit the size of the dataset to test the classification, I used recordings from three subjects (S1–S3), selecting the O1, Oz, O2, and POz channels to match our planned electrode configuration. The dataset contains recordings at 8, 12, and 15 Hz, which are close to our target frequencies. To achieve this I used Claude to write a benchmark walkthrough that checks each stage of the pipeline including but not limited to loading raw EEG, filtering, CCA classification, and final predictions.

The highlighted shows 2.5-second EEG window used for classification.

The peaks at the stimulus frequencies and their harmonics confirm that the recordings contain detectable SSVEP responses.

Then I also needed to test the digital signal processing and filtering. I tested the filtering pipeline on the real EEG recordings to verify that it removes unwanted noise without significantly altering the SSVEP signals. The pipeline uses a 0.5–45 Hz bandpass filter, with a configurable 60 Hz notch filter. The 12 Hz signal experienced only 0.02 dB attenuation.

The next step was to evaluate the complete classification pipeline using 54 real EEG trials across the three subjects. I chose this number because it is how much disk space I had left and it felt significant enough. With our four-channel configuration, the classifier correctly identified 52 out of 54 trials, thus being 96.3% accurate. I also used Claude to generated confusion matrices and correlation-score distributions to examine where the classifier made mistakes. Both incorrect predictions occurred on 15 Hz trials.

I also ran experiments to understand how different processing parameters affect classification accuracy. Specifically, I compared EEG window lengths, electrode configurations, and the number of harmonics used in CCA. This was the most fun part to tweak and observe what changed and how! Results showed that window length accuracy increased from approximately 85% at 1 second to 96.3% at 2.5 seconds, with marginal improvement at 3 seconds. But I can’t afford to spend too much time on the window due to our latency user requirements. I also found that using two harmonics improved accuracy compared with using only the fundamental frequency.

Once all this was done, the final porting to ESP32 remains. It is not yet complete and will be the focus of next week.

Schedule

The Python signal-processing and classification pipeline is implemented and has now been tested successfully on real EEG data. The next major milestone is running the decoder on the ESP32-S3. The C++ implementation is in the work, but the full firmware has not yet been compiled and tested on the microcontroller. Also, final calibration values discussed in previous report and will depend on recordings from our custom EEG acquisition hardware. In the meantime, I can continue firmware development and testing using prerecorded EEG data.

Deliverables for Next Week

For next week, I want to finalize and complete ESP32 firware integration, compile and flash the firmware, and test the decoder on the firmware with the practice EEG data to see if the data matched what I achieved this week. While this happens, I will also measure latency, processing time, and memory usage.

 

Felipe Perotti’s Status Report for 10/03/2026

Progress This Week

This week I was focused on the communication protocols we will use for transmission between the ADC and the ESP32 as well as from the ESP32 to the final end point device.

This week I focused on the communication protocols that will support data transmission between the ADS1299 ADC and the ESP32, as well as between the ESP32 signal-processing board and the final endpoint device.

Initial findings indicate that the system should be treated as two separate communication links. The ADS1299-to-ESP32 connection requires a deterministic, low-latency interface—most likely SPI—with careful synchronization using the data-ready signal. This link must preserve sample timing and prevent data loss during continuous EEG acquisition.

The ESP32-to-endpoint connection will require a balance between latency, bandwidth, range, power consumption, and reliability. Candidate interfaces include Bluetooth Low Energy, Wi-Fi, or a wired UART/USB connection, depending on the final endpoint requirements. Regardless of the selected technology, the transmitted data should include packet framing, sequence numbers, timestamps, signal samples, status information, and error checking.

The main communication risks identified so far are packet loss, timing jitter, synchronization errors, and increased latency. These factors could affect the quality and real-time performance of the BCI system. The next step is to benchmark the candidate protocols using end-to-end latency, packet-loss rate, throughput, and system resource usage as the primary evaluation criteria.

I also began 3D Printing the headset but have yet to find good files for spring mechanisms to keep tension  between electrodes and head. Will report further next week.

Next Week

For next week I plan on finishing the needs for the headset and to start identifying the low level software we’ll need for communication.

Schedule

I am on schedule.

Atharv Kashyap’s Status Report for 10/03/2026

Atharv Kashyap‘s Status Report for 10/03/2026

This week I moved from planning the signal-processing pipeline to building it. I implemented the first Python version of the SynapSys decoder, including bandpass/notch filtering, CCA, three-command classification, and rejection logic. I kept the main parameters configurable so we can easily change things like sample rate, window length, harmonics, and thresholds once we start testing with our own hardware. The next step for next week will be converting this to C/C++ using tools like Claude so that it runs on the ESP32 as well as testing on real datasets to make sure all parts are working (this was only tested this week with synthetic data).

For now, the classifier compares the EEG against 8.57, 12, and 15 Hz references and gives each one a CCA score. The highest score is the predicted command. I also added confidence and winner-vs-runner-up margin checks so the system can eventually reject unclear inputs instead of always forcing a YES, NO, or HELP result. This is exactly what we documented for our design report and what Theodora presented last week. I have not chosen the final thresholds yet because these need to be determined from our own calibration recordings.

Here is a screenshot of the repository:

I (using Claude) also wrote automated tests for all the different coding stages. Right now, 193 tests pass with no failures. These cover the reference signals, filtering, CCA calculations, classification/rejection logic, synthetic EEG generation, metrics, and data loading.

Before moving to real EEG, I tested everything using synthetic data where I already knew the correct answer. I generated fake EEG containing 8.57, 12, or 15 Hz signals, then added noise, drift, 60 Hz interference, and differences between channels. For example, a synthetic 12 Hz trial should produce the largest CCA correlation for the 12 Hz reference rather than 8.57 or 15 Hz. There was no noise in these data points so obviously I expected a big spike and strong correlation scores. This was just to test if the processing worked. I repeated this for all three commands.

Example CCA output:

I cannot upload thet tests.csv files due to security reasons on WordPress blocking me.

For clean signals, the correct CCA reference clearly gives the highest score for all three commands as expected.

I then added much more noise and also tested pure noise, off-target signals, and ambiguous mixtures. The correct reference still tended to score highest for valid trials, but the scores became closer together as the inputs got worse. This was useful because it showed exactly why we need rejection logic instead of just picking the largest score every time.

Python is being used as our reference implementation and analysis environment, while the final filtering, CCA, and rejection logic will run in C/C++ on the ESP32-S3.

Schedule

I am on track right now. Next week is going to be busy because we also need to finish the design report and get the PCB ready to send out.

Deliverables for Next Week

Finalize and send out the PCB design (will help with layout and BOM finalization), test CCA against Wang et al. SSVEP dataset and once it works, port the Python to C/C++ for the ESP32 and finish my parts for the design report.