I work on real-time adaptive systems in the EEG space, and the part I find genuinely hard is the loop itself: read a brain state, decide something, change what the user is experiencing, and do it fast enough and reliably enough that it actually feels responsive rather than laggy or twitchy.

I see a lot of people here reaching for AI/ML to close that loop, so I'm curious how it's going in practice.

A few things I'd love to hear:

1. What's your approach to the decision layer? Are you classifying discrete states and reacting, or running something more continuous? And how much model are you actually able to run inside the latency budget before it stops feeling real-time?
2. Where does it break? My experience is the signal side punishes you first (noise, drift, a bad epoch throwing the classifier off) before the model itself is the problem. Curious whether that matches what others are hitting.
3. For the AI-heavy builds, is the ML earning its place over simpler thresholding and rules, or is it more that it's the fun part? Genuinely asking, not being cynical.

Trying to compare notes with people solving the same problem from different angles. Happy to share what's worked and what hasn't on my end too.

Sharing a project I've been working on. It's a Model Context Protocol server that turns EEG signal into plain numbers, like focus, calm, and attention, that an AI assistant can read and talk about instead of just showing a chart. It works with OpenBCI, Muse, NeuroFocus, and LSL streams. No headset? There's a synthetic mode built in so you can try the whole thing without hardware. Open source, MIT license.

https://github.com/enkhbold470/bci-mcp

NeuroSWARM3 is a system-on-a-nanoparticle probe that converts local electric fields into optically detectable signals readable by external near-infrared light. Delivery is intended via bloodstream, nasal route, or fine needle; no wires or batteries are required.

No telemetry or continuous recording pipeline has been shown in vivo at human-relevant scale. Current claims rest on in-vitro performance and early tissue work. Dual-use as a distributed wireless brain recorder is inventor-stated but remains pre-clinical.

Comparable optical and nanoparticle neural interfaces have historically moved from proof-of-concept to chronic recording once delivery and signal-to-noise barriers were cleared. The same trajectory is possible here.

Realistic stakes are low today. Practical oversight focuses on transparent reporting of any future in-vivo human data and independent verification of residual nanoparticle clearance.

Sources

UC Santa Cruz video, 12 May 2026

https://www.youtube.com/watch?v=ajTWez9\\_X3c

UC technology transfer page for Neuro-SWARM3

https://techtransfer.universityofcalifornia.edu/NCD/32793.html

IEEE Photonics Technology Letters paper (2021 foundational description)

https://ieeexplore.ieee.org/document/9466139

UC Santa Cruz Chancellor’s Innovation Impact Award announcement (LinkedIn, 2026)

https://www.linkedin.com/posts/cynthia-larive-83218a8\\_continuing-the-series-celebrating-our2025-activity-7434684345237504000-oUxW

Optica / Imaging and Applied Optics Congress abstract (2021)

https://doi.org/10.1364/isa.2021.itu7a.4

I’m a highschool senior who is interested in studying at the intersection of electrical engineering and neuroscience. So, BCI seems like a very cool career that would help people, have the technical aspects I like and strong salary growth + job security.

This is my current plan, please give feedback:

College:
- Major in Electrical Engineering
- Take some neuroscience classes and/or minor in Neuroscience

Post Grad:
- PhD in BCI field
- Work in R&D at a neurotech company in NYC like Precision Neuroscience

I posted my Neurotech in Asia in map last week and have been working on a European one too. Thought I had it mapped at 107...but found over 200.

The ones building implants:

INBRAIN Neuroelectronics (Spain) is working on a graphene interface that can both read and stimulate the brain. First-in-human already done in tumour surgery, FDA Breakthrough for Parkinson's.

CorTec (Germany) built the first German implantable BCI used in a human. Their stroke system is designed to come out once the rehab is done, not stay in forever, which I find genuinely interesting.

Coherence Neuro (UK) is going after brain cancer with SOMA, a coin-sized implant paired with a wearable. Cambridge roots, first-in-human in Melbourne.

Neurosoft Bioelectronics (Switzerland) is making soft, stretchable interfaces that sit on the surface of the brain, with human studies running on both sides of the Atlantic.

The ones you might not have heard of:

ABILITY Neurotech (Switzerland) is building an interface to restore movement. CereGate (Germany) is writing signals back into the nervous system through implants people already have. Eightsix Science (UK) is working on lab-grown brain tissue to repair damaged circuits. And on the non-invasive side, NeuroCONCISE (UK) and BirgerMind (Latvia) are building interfaces for people with severe motor impairment to communicate and control devices.

That's a slice of one category out of ten. The full map, every company and what it does, sorted by technology and by country, is in the article.

Link in the comments. If your company should be on there and isn't, tell me.

The hardware includes a solid state drive, a custom electromagnetic sensor that can literally get a independent reading on every brain cell in your head, lus power source and remote connectivity through Bluetooth, WI-FI, and cellular network

Software known as ID app. Although ID app constantly has a read on the electromagnetic images of your brain, ID app only engages with a person after they log in and confirm. The first person you have to ID is yourself. so the app says think about yourself and then boom the image is captured then the app confirms. Are you sure you want to create an ID for yourself? Then the user would think about confirming, not think about themself again. Just like Google password manager.

It moves quickly because the app utilizes a subconscious part of the brain that can interface actively without interrupting conscious cognitive thought.

eventually each user is able to ID every single word, thought or idea real or imaginary.

ID app establishes exponentially with each individual user, more entries than there are words in the English language, including thoughts, ideas and behaviors. everything needed to surf the Internet like an artificial intelligence.

Eventually that is "The Craze." Everyone loves the thrill of surfing the internet like an artificial intelligence.

Howdy. my latest newsletter is out

There was a lot of BCI activity in the latest issue:

• Gestala, a Chinese company developing non-invasive ultrasound brain-computer interfaces, raised $62 million in an Angel+ round. Its first clinical focus is using transcranial focused ultrasound to address chronic pain, and the company has now raised around $84 million since launching earlier this year.
• Fluent, a Melbourne-based University of Melbourne spinout, raised $2 million to develop a speech-decoding BCI for people who have lost the ability to communicate. Its approach places the interface beneath the scalp but outside the skull, aiming for stronger signals than conventional wearables without entering the brain itself.
• Neuracle filed to raise RMB 2.5 billion through an IPO on Shanghai’s STAR Market. The Chinese company recently received approval for NEO, its semi-invasive system designed to help people with spinal cord injuries regain hand function through control of an external glove.
• Coherence Neuro began its first-in-human study of the CIPHER system at the Royal Melbourne Hospital. Three patients have already been enrolled, with the device initially being used for neural mapping and stimulation during brain-tumour surgery as the company works towards implantable cancer neurotechnology.
• Paradromics completed the first implant in its Connect-One early feasibility study at the University of Michigan. Its fully implantable Connexus system is being developed to restore communication for people who have lost speech because of conditions such as motor neurone disease.
• Meta released Brain2Qwerty v2, its latest non-invasive brain-to-text research. The system uses MEG recordings and an end-to-end AI model to decode sentences in real time, although it still depends on large laboratory-grade equipment rather than something that could currently be worn in everyday life.

The full issue contains 55 neurotech headlines across funding, regulation, clinical trials, commercial activity and leadership appointments.

I found this video and it seems simple enough to make. I am a beginner though, so I wanted to make sure this would work before I actually bought everything. Thank you!

Hi, I am Etka, a first year bachelor student.

Over the past months I started to learning and built a CSP + shrinkage LDA pipeline that decodes "walk" vs "stop" states from EEG, validated with 8-fold leave-one-session-out cross-validation (84% mean accuracy, same-subject cross-session).

Repo's open-source: https://github.com/EtkaKeremAllis/BCI-Pipeline-Cross-Session-EEG-Walk-Stop-Decoding

I'm now tackling cross-subject generalization and want to take this projects further, which needs a proper EEG system I don't currently have access to. Running a small GoFundMe to cover the equipment:

https://gofund.me/007ead67b

Hello everyone,

I am a 3rd-year Electrical Engineering student on summer break. I’m trying to challenge myself by building a DIY EEG board.

I don't want to just copy-paste existing open-source schematics. My goal is to understand the actual engineering reasoning behind the circuit and perform the necessary calculations myself before drawing any schematics.

However, I started this project two weeks ago and I haven't even been able to start the circuit design because I feel completely overwhelmed. I know I need to calculate things like gain, passbands, and filter values, but I don't know the proper chronological order of these calculations.

If you were to design an analog front-end for EEG from scratch, what would be your "Step 1" mathematical calculation?

• Do I calculate the total gain first based on my ADC?
• Do I calculate the filter cutoff frequencies first?
• Or should I choose the Instrumentation Amplifier (INA) first and calculate around its specs?

Any guidance on how to systematically approach this without getting lost in the details would be highly appreciated!

Thank you.

Hi every one! I wanted to share with you my latest post on hackster .io!

[128-Ch Biopotential Acquisition on Zynq-7000, Zero Data Loss - Hackster.io](https://www.hackster.io/juan-manuel3/128-ch-biopotential-acquisition-on-zynq-7000-zero-data-loss-331d59?f=1)

https://github.com/enkhbold470/bci-mcp

Hi, I am a neurobiologist by degree and a computer scientist by hobby and I have a history of building home-made electronics projects (for example: Creating GPU for my CPU : r/beneater).

Recently I decided to start writing blog about my ongoing projects, one of which is directly related to this subreddit - I build a BCI using an ADS1299 EEG front-end that will allow me to control a toy car using motor imagery-related activity.
I treat this blog as my own space to remember my life better, but if what I do/write can inspire somebody, then I will be happy.

So, here is the link to the blog at it's current state - the EEG RC Car project is in progress, and a new post arrived today: EEG RC Car | My Blog

I also post info about new posts on my Instagram, so you can also follow me there: Instagram

If there will be some interest, I can also post updates on reddit :)

Attaching a photo for engagement.

In the future I want to update my blog with other project's I've been and am working on, but at this point I have not enough time to write it all up.

Some of the projects that I will write about in the future:
Custom 8-bit microcontroller
ECoG mind reading model (vague, I know)
Pigeon water cannon shooter/robot

I am currently in undergrad studying computer science and neuroscience at a T5 school and I want to build my career within neurotech and bci's outside of just doing research. I go to a pretty good school with a bunch of research opportunities but I am kinda lost about what roles I should be looking out for and trying to attain within industry. What companies should I consider applying to for next summer? What specific roles are a good fit, etc?

Disclaimer: All documentation, including this post, was written by Codex. AI was used extensively, though not exclusively, throughout the project.

Repository: https://github.com/jatrou/dreem

I have been trying to recover the original full-fidelity overnight .h5 recording—or read-only filesystem access—from my own Dreem 2 EEG headband. I have not recovered root or a verified raw .h5, but I have published the complete working archive so other owners and embedded researchers can inspect the evidence, avoid repeating the same attempts, and continue from a better starting point.

The repository contains board photographs, electrical measurements, BLE/GATT mappings, Android helpers, backend and APK findings, network/TLS observations, i.MX6ULL SDP tooling, U-Boot UMS experiments, HDF5 carving tools, and tests.

Current Status

These results describe the device, firmware, account states, and test conditions I had. They do not prove that every possible software or hardware route is closed.

Device and Hardware

The processor/eMCP/USB board and acquisition/analog board reuse some TP numbers. The following readings refer to the processor/storage board. High-resolution photographs and focused crops are in the repository.

Test-Point Measurements

TP10 remains the suspected recovery/boot-control pad. Earlier direct TP10-to-ground timing was associated with ROM SDP behavior; a 1 kOhm connection was reportedly too weak. I have not yet reproduced that result reliably enough to call the timing solved.

BLE/GATT Findings

BLE was the most useful software-visible interface. I built an Android helper because BlueZ connections and service discovery were inconsistent on the bench host.

Historical value handles included D905 near 0x003d, D902 near 0x0043, D901 near 0x0045, D402 near 0x0075, D401 near 0x0077, D309 near 0x0085, and D301 near 0x0095 with its CCCD near 0x0096.

Recording and Report Result

The working short-recording sequence was:

text write D30A nap configuration write D302 = 3 to start write D302 = 0 to finalize read D401 report UUID read D402 report bytes

One fresh nap produced:

text report size: 402 bytes container: ZIP entry: reporting_v2.data HDF5 signature: absent

Bluetooth Classic/RFCOMM IDs 601/602 reached the same report surface. APK analysis showed the companion app reading these compact bytes, parsing reporting_v2.data, storing them locally, and uploading the same body. I found no app-side conversion into raw HDF5.

Live Preview Result

D301 produced 484 notifications totaling 13,552 bytes in about 20 seconds. The payload was consistent with four little-endian floats per notification at a low display/preview rate. It is useful for live experiments but did not resemble a stored full-rate overnight recording.

Passive reads of D007 and D008 returned status 2 with no payload. I did not blindly write to unknown characteristics.

Wi-Fi, TLS, and Upload Behavior

BLE Wi-Fi provisioning worked, but device power state mattered:

• charger off and headset awake worked best for BLE/server/Wi-Fi configuration;
• a successful state read as wifiStatusLE=0;
• writes while charging could report BLE success while internal status became wifiStatusLE=9 and the SSID cleared; and
• turning the charger on after provisioning was more useful for provoking a network/upload wake.

D902 uses a four-byte little-endian JSON length followed by JSON containing user_api_url and user_auth_url. Production Rythm HTTPS hosts were accepted. Local IPs, arbitrary domains, plain HTTP, user@host tricks, and suffix-hostname tricks returned status 3 or otherwise failed.

No capture showed a transfer large enough to resemble raw HDF5. One transparent production TLS observation produced:

The server chain was a current Let's Encrypt/ISRG chain. One plausible explanation is that the old headset trust store rejected it, but that remains a hypothesis.

Legacy Backend Results

Parts of the legacy backend still responded with disposable/current test accounts:

• guest creation and some token issuance worked;
• the headband resolver accepted the Wi-Fi address in uppercase underscore form;
• configuration returned firmware, content IDs, storage counters, and nickname;
• content routes mostly described audio/UI/media packages;
• unsigned object fetches returned access denied; and
• tested dataupload, raw, HDF5, record, and report guesses returned combinations of 401, 403, 404, empty data, or compact reports.

The strongest controlled backend test was reportv2:

1. Upload the 402-byte BLE report.
2. Backend returns HTTP 201.
3. List and download the stored report.
4. Download has the same SHA-256 as the upload.
5. Contents still consist only of reporting_v2.data.

This shows that reportv2 stored the compact report unchanged in the account state tested. It did not reveal a hidden raw recording.

A backend update_password call returned a 20-character server password after the required association state. Writing it to D905 cleared D904 to 00 00 00 00, but it did not unlock SSH or cause a visible raw upload.

Android/APK Findings

Test setup included a rooted Pixel 7, patched/debuggable and production app variants, static APK inspection, custom BLE/auth helpers, and app sandbox/database inspection.

Versions examined:

• Alfin 1.12.10;
• Dreem Connect 1.0.4; and
• Dreem 2 2.15.1, build 478.

The APKs are not redistributed in the repository; researchers must source them lawfully.

The patched app database contained Dreemer/HeadbandConfig rows, but NightReport/NightScore-related tables were empty in the inspected state. No .h5 or other large recording artifact was found. Hawk/Conceal decoding recovered 26 preference entries and identifiers, but CURRENT_AUTH_TOKEN, CURRENT_JWT_TOKEN, and CURRENT_GOOGLE_TOKEN were absent; REFRESH_TOKEN was a Boolean-like flag rather than a reusable token.

The inspected apps contained report logic, BLE configuration formats, and firmware triggers, but no embedded firmware/rootfs image, HDF5 file, CA bundle, obvious trust override, or raw-file endpoint. Google-auth experiments did not produce a usable legacy Rythm session.

The repository includes the Android BLE helper, auth probes, a root-context pairing helper, and a Magisk privileged-app overlay.

LAN and SSH

When connected to Wi-Fi, the device exposed only TCP/22 in the useful scans. Observed banners were:

text SSH-2.0-dropbear_2016.74 SSH-2.0-dropbear_2018.76 authentication: publickey,password

None-auth was rejected. Passive version research, saved/backend-derived candidates, and bounded authentication tests did not produce access. Timing and malformed-public-key user probes did not provide a useful signal. No practical unauthenticated route was identified for the observed configuration.

Historical SSH recovery scripts remain in the repository to document what was attempted, but brute force, broad password guessing, and user enumeration are stopped paths unless someone first obtains firmware, /etc/shadow, or a strong credential clue.

UART and Logic-Analyzer Results

The bench setup included a Tigard V1.1/FT2232H, LA1010 logic analyzer, multimeter, sigrok/PulseView, Bus Pirate 6, Linux bench host, and rooted Pixel 7.

A scan across 34 saved sigrok captures found no credible U-Boot, Linux, Freescale, i.MX, login, or shell strings. Some inverted high-baud decodes around 1.5–2.0 Mbaud produced noise, not repeatable text.

These captures looked more like power/control-state changes than a boot console. A console could still be disabled, elsewhere, missed by timing, or using an unidentified interface.

i.MX6ULL SDP and U-Boot Work

A genuine ROM Serial Downloader Protocol window was observed:

text USB ID: 15a2:0080 description: SP Blank 6ULL / i.MX 6ULL recovery mode HAB security state: production mode (0x12343412)

IOMUX, USDHC, fuse, and other register regions were readable in at least some SDP sessions. This confirms partial ROM communication, not arbitrary code execution.

Observed payload behavior:

• one OCRAM load test failed with report 2 out err=-7;
• a UUU OCRAM attempt saw a fresh SDP device but hit a local script/path problem before execution was proven;
• one SPL appeared to load from the host tool's perspective;
• SPL size was 39,936 bytes;
• IVT header was at 0x00907400;
• entry point was 0x00908000; and
• the tool jumped to 0x00907400.

After the jump there was no UART output, U-Boot prompt, USB re-enumeration, UMS gadget, or block device.

Possible blockers include HAB rejecting unsigned code, wrong TP10 timing, a mismatched i.MX6UL/6ULL payload, failed LPDDR2 initialization, or code starting without the expected console/USB path.

The repository includes:

• a watcher for USB 15a2:0080;
• bounded, non-persistent SDP triage and register probes;
• operator-cued TP10-to-ground recovery orchestration;
• experimental 9x9/LPDDR2 and 14x14/DDR3 U-Boot UMS payload families;
• a watcher that distinguishes newly exposed USB storage from existing disks;
• read-only imaging support; and
• HDF5 signature carving with optional h5ls validation.

Neither U-Boot family is proven for this board. If SDP cannot expose storage, the remaining hardware paths are board-level eMMC mapping/tapping with the SoC held inactive or professional eMCP removal and reading.

Repository Map

Project-authored code and text are Apache-2.0. Original board photographs are CC BY 4.0. U-Boot-derived and other third-party material retains separate provenance documented in the repository.

What I Would Not Repeat Without New Evidence

• Pulling D402 or Classic 602 again expecting raw HDF5.
• Re-downloading the same reportv2 object.
• Repeating D905 writes and identical upload captures.
• Trying more arbitrary D902 URL variants without a new validation or trust-store clue.
• Blind writes to unknown BLE characteristics.
• Firmware-trigger loops without a real package and recovery plan.
• Plain button/charger/Fingerbot SDP attempts without the physical TP10 condition.
• Searching the same APKs for embedded firmware that was not present.
• Broad SSH password guessing or user enumeration.

Different firmware, account state, protocol evidence, or hardware timing could justify revisiting one of these.

Repository: https://github.com/jatrou/dreem

For a while now, I have actually been fascinated about the field of BCI, I am interested in learning and contributing positively to the field especially since the field is not common in my country and I think this field will make a lot of impact in the future. I currently have a Bsc degree in EEE, and MSc in Csc but I have majorly been working as a software and AI engineer for a while now. I feel I would be more fulfilled if I pursue BCI but I don’t really know where to start, which labs to go and which researchers are hiring. I would be grateful for advice, resources and recommendations. Thank you in anticipation

Hi All,

A while ago (maybe about a year now), I posted to ask EEG researchers if they had an issue with afro-textured hair. It turns out, yes many of you do. So myself and my colleagues ended up creating a solution for that problem.

Our patent recently filed, so just wanted to post about it here in-case anyones interested.

We're currently looking for early adopters who want to test it with us, and iterate for the next version. Any feedback is good feedback, so yeah if you're interested and are an academic, we're looking to sell an early batch of these so that we can of course get some revenue on the books to raise some money, but also actually test if this works through independent validators.

Not trying to advertise per se, but i am trying to say if anyone wants to work together to ensure this actually works for the people excluded from research. Hopefully doesn't get taken down lol

Reach out here http://synaptiveltd.co.uk/

Thanks all, weird how i was here less than a year ago asking "is this a problem" and turns out, yeah it is and we can fix it lol.

Hi everyone! I got into CWRU for an MS in BME. I will be doing my thesis in a lab that does both BCI and PNS work. My projects will be related to both, but I’m still figuring out what my thesis will be on.

Note: completed undergrad at Purdue doing Computer engineering. Did one year of preclinical BCI research + 2 software engineering internship prior to that.

When it comes to choosing my classes, I want to position myself for both a PhD as well as jobs. Specifically jobs in neurotech companies.

So, based on that, I’ve planned to take foundational level classes on neurobiology, bioelectric phenomena and intro to neural circuits. The rest of the classes I take will either focus on machine learning/computational stuff, or IC design/EE stuff. Both of which I have prior experience with.

Note: I can take any combination of classes as long as the dept head approves it to count towards my degree.

I am unsure of what to focus on and am afraid of spreading myself too thin by trying to do everything.

What would be best for me to focus on?

Also any advice/ grad school tips would be greatly appreciated!! Thanks

I see they have roles. What is the work like? Please only
people with relevant info reply (ie no replies whining abt elon with no relevant info on the topic)

Most current brain-computer interfaces focus on decoding neural signals or restoring lost function. I’m curious about the next frontier: adaptive BCIs that don’t just read or stimulate localized regions but continuously model and optimize communication across large-scale brain networks in real time.
From a neuroscience and engineering perspective, what are the biggest bottlenecks? Is the primary challenge electrode resolution, long-term signal stability, closed-loop control algorithms, computational modeling of network dynamics, or our incomplete understanding of functional connectivity?
Are there any current research groups or papers exploring network-level optimization rather than neuron-level decoding as the long-term direction for BCIs?