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...

A while back, I got frustrated with the state of accessible BCI hardware. Research gear was wildly unaffordable. So, I spent a ton of time designing a custom board, software and firmware to bridge that gap. I call it the Cerelog ESP-EEG. It is open-source (Firmware + Schematics), and I designed it specifically to fix the signal integrity issues found in most DIY hardware.

I believe in sharing the work. You can find the Schematics, Firmware, and Software setup on the GitHub repo: GITHUB LINK: https://github.com/Cerelog-ESP-EEG/ESP-EEG

For those who don't want to deal with BGA soldering or sourcing components, I do have assembled units available: https://www.cerelog.com/eeg_researchers.html

The major features: Forked/modified OpenBCI GUI Compatibility as well as Brainflow API, and LSL Compatibility. I know a lot of us rely on the OpenBCI GUI for visualization because it just works. I didn't want to reinvent the wheel, so I ensured this board supports it natively.

It works out of the box: I maintain a forked modified version of the GUI that connects to the board via LSL (Lab Streaming Layer). Zero coding required: You can visualize FFTs, Spectrograms, and EMG widgets immediately without writing a single line of Python.

The "active bias" (why my signal is cleaner): The TI ADS1299 is the gold standard for EEG, but many dev boards implement it incorrectly. They often leave the Bias feedback loop "open" (passive), which makes them terrible at rejecting 60Hz mains hum. I simply followed the datasheet: I implemented a True Closed-Loop Active Bias (Drive Right Leg).

How it works: It measures the common-mode signal, inverts it, and actively drives it back into the body. The result: Cleaner data

Tech stack:

  ADC: TI ADS1299 (24-bit, 8-channel).

  MCU: ESP32 Chosen to handle high-speed SPI and WiFi/USB streaming

  Software: BrainFlow support (Python, C++, Java, C#) for those who want to build custom ML pipelines, LSL support, and forked version of OpenBCI GUI support

SAFETY NOTE: I strongly recommend running this on a LiPo battery via WiFi. If you must use USB, please use a laptop running on battery power, not plugged into the wall.

Comments URL: https://news.ycombinator.com/item?id=46502051

Points: 54

# Comments: 21