27 karma · joined January 3, 2026
With regards to higher channel count, yes I was thinking about this however it will likely not be released for a few months or longer. The firmware/software rules change a lot when you start daisy chaining the ADC so dev time takes long and I need to reincorporate back into these software ecosystems. Hardware config is also a bit different.
Regarding licensing, sorry about the confusion between my repo init and the docs. I have updated the repo to clarify the distinction: Firmware & Software: MIT License. I want people to build whatever they want on top of the stack. Hardware Schematics: CC-BY-NC-SA (Non-Commercial). Why the split? Since I am a solo bootstrapper, I need to protect the hardware from low-effort commercial clones while I get the business off the ground. But I strongly believe in "Source Available" schematics so researchers and engineers can debug, learn, and modify their own units, hence the CC-BY-NC-SA choice for the board files.
Why start fresh? It was an architecture decision. The Cyton uses a PIC32 + RFduino stack. I wanted to handle everything natively on the ESP32 for high-bandwidth WiFi streaming, which required a ground-up redesign. I also wanted to add onboard LiPo charging and the ability to experiment with different filter topologies. Building it from scratch helped me uncover a lot of subtle design constraints that aren't obvious until you dig into the layout.
Because the ESP32 is so fast, I was driving the SPI lines without adequate delay between bytes during configuration. The ADS1299 would technically "communicate" but then behave crazily during data acquisition. I had to go back to the datasheet's SPI timing diagrams and strictly enforce the timing constraints in firmware to get it stable. I wish SPI was a more strictly defined standard
2. The Bias/Noise Implementation: While we both use the same high-end ADC (TI ADS1299), I implemented the Bias (Drive Right Leg) differently. I designed a true closed-loop feedback system. By actively driving the inverted common-mode signal back into the body, the board follows the TI spec aggressively for helping cancel out 60Hz mains hum
Regarding the analog front-end: The current version keeps the inputs flexible (firmware configurable) for different montages. However, I’ve found that most researchers just stick to a single standard montage configuration. Because the Cyton tries to be a "jack of all trades" for every possible montage, it compromises on physical filtering. For future revisions, I plan to trade some of that flexibility for dedicated common-mode and differential hardware filtering to lower the noise floor even further. I already had this on a previous revision prototype but decided to take not out for simplified testing. I'd like to add it back in to a future revision after some more prototype testing.
3. Connectivity: I’m using the ESP32 to stream over WiFi rather than a proprietary USB dongle. Ive been trying to get BLE SW working as well but noticed MAC drivers aren't the most friendly to my implementation.
To answer your question: My primary goal right now is simply reliable, high fidelity data collection. However, I think neurofeedback is a fascinating application. I’ve been interested in eventually mixing this tech with tACS in a closed loop control system to train the brain to enter specific mental states.
Regarding the MonolithEEG, it's wild to look back at that tech. It is a shame it was limited to 2 channels at 10 bit resolution, but it was a pioneer. With the ADS1299, we are now getting 24 bit resolution across 8 channels. That difference in dynamic range makes a huge difference, especially for precision applications like SSVEP where the noise floor really matters.
https://www.cnx-software.com/2025/12/26/cerelog-esp-eeg-a-lo...
And here
https://www.hackster.io/news/this-open-source-eeg-board-brin...