# EEGwithRaspberryPI reads eight EEG channels off a PiEEG shield > EEGwithRaspberryPI is a small collection of C, C++ and Python scripts for pulling EEG data from a PiEEG shield on a Raspberry Pi, and it is explicitly not supported any more, with the live scripts moved to the PiEEG repository. Useful as a reference for the SPI-level read path and the signal filtering, less so as something to build on. **pieeg-club/EEGwithRaspberryPI** — Not supported. Measure 8 EEG channels with Shield PiEEG and RaspberryPi in C library - Repository: https://github.com/pieeg-club/EEGwithRaspberryPI - Stars: 946 · Forks: 90 - Language: Python - License: not declared - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/pieeg-club-eegwithraspberrypi ## The repository says outright that it is not supported The project description is blunt about its status: "Not supported. Measure 8 EEG channels with Shield PiEEG and RaspberryPi in C library". That line is the first thing a reader should weigh, and the README repeats the point in a different way. It lists the live software as PiEEG Server, links a Google Colab manual and a quick start PDF for the PiEEG hardware, and then states that the actual locations for the scripts will be in the PiEEG repository rather than here. So this repository is best understood as an earlier snapshot of the reference code, kept online for the historical code it contains. The last push was on 2026-07-19, the repository is not archived, and there are no GitHub releases, so there is no version history to consult and no tagged artefact to install. The licence field is listed as unknown, and there is no LICENSE file among the top-level entries, which is a separate practical problem from the support status and one you need to resolve before shipping anything derived from it. For a project in this state, the value is documentary. If you want to build a brain-computer interface on this hardware, read this code to understand the approach, then work from the maintained repositories the README names. ## Four ways to read the same data, from C to Python The top-level listing shows the same task implemented repeatedly, which tells you something about the audience. There is `1.1.Read_data.c`, `1.2.Read_data.cpp`, `1.3.Read_data.py` and `1.4.Save_data.py`, followed by `2.Data_filter.py` and a `3.Soft_Read_and_save_linux` entry. The numbering is the sequence: read the data, filter it, then read and save it in soft real time on Linux. The C and C++ versions exist because the SPI read path is the part where latency and timing matter, and a C implementation lets you sit close to the hardware. The Python versions exist because that is where the analysis lives. The C# and Python split mirrors a common embedded pattern: a low-level grabber that hands off to a scripting layer for filtering, plotting and storage. `1.4.Save_data.py` sits at the boundary, adding persistence to the read, and `3.Soft_Read_and_save_linux` is the version intended for running continuously on Linux, which is where the practical use of this hardware usually starts. The repository also carries a `Robot_control/` directory, a `GUI/` directory and a `service/` directory, so the ambitions go beyond signal acquisition into controlling something with the output and presenting it. What the repository does not contain is a package manifest or an install script for the code itself. The `requirements.txt` at the root is the dependency list for the Python side. ## The dependency list pins old versions of the EEG stack The `requirements.txt` file is a full environment freeze rather than a minimal list. Among the pinned entries are `brainflow==5.0.0`, `mne==0.23.4`, `neurokit2==0.1.4.1`, `pylsl==1.15.0`, `numpy==1.21.3`, `scipy` companions like `Bottleneck==1.3.2`, and `pandas==1.3.4`. The GUI and plotting side is covered by `pyqtgraph==0.12.2` and `matplotlib==3.0.2`, and the web service side by `Flask==1.0.2` and `aiohttp==3.7.4`. That set tells you what the code was built against. Brainflow, MNE, NeuroKit2 and PyLSL are the standard names in EEG and biosignal work, and having them pinned together suggests the scripts were written against a known-good combination rather than the latest releases. Installing them as pinned on a modern Python is likely to be painful, since these versions predate current CPython releases, and a Pillow or numpy build on a current system will fight the pins. These are the pins exactly as they appear in the `requirements.txt` file, and they are the quickest way to see which library the project expected to do which job. ```python brainflow==5.0.0 mne==0.23.4 neurokit2==0.1.4.1 pylsl==1.15.0 numpy==1.21.3 pandas==1.3.4 pyqtgraph==0.12.2 Flask==1.0.2 aiohttp==3.7.4 ``` For a reader deciding whether to reuse the environment, the practical move is to treat the pins as a specification of the era rather than a recipe. Build a fresh environment with the packages you actually need, and use the pinned list to work out which library does which job: acquisition through Brainflow or the direct SPI path, analysis through MNE and NeuroKit2, streaming through PyLSL, storage through pandas and NumPy. ## Electrical safety is the hard constraint, not the code The README spends a large part of its length on how not to electrocute yourself, and that is appropriate. The setup described is a shield connected to a Raspberry Pi powered by a 5V battery, with electrodes attached to a person, and the requirements are stated without hedging. The device must operate only from a 5V battery, and complete isolation from mains power is required. The README says the device must not be connected to any kind of mains power, via USB or otherwise. A monitor is involved too, and the rule there is that only a monitor powered by the Raspberry Pi should be used. Electrodes are positioned according to the International 10-20 system, and the wiring diagram between the Pi and the shield is published as an image in the repository. The project also states plainly that PiEEG is not a medical device, that it has not been certified by any government regulatory agency for use with the human body, and that you are fully responsible for your own decision to purchase and use it. The documentation points to a liability page for the power supply question. None of that is a reason to skip the project, but it changes what the code is for. This is a research and hobby bench tool for reading signals from a person, not something to put in front of a patient or attach to a clinical device, and no amount of Python quality changes that boundary. ## Signal test material shows what you are actually looking at The README includes a signal test section with the captures the project is judged by, and they are worth reading as a specification of the difficult cases rather than as marketing. There is an alpha in EEG signal capture, which is the band people usually look for because it shows up when a subject relaxes with eyes closed. There is a capture of artefacts, labelled as chewing and blinking in the EEG signal, which is the honest way to show that a muscle artefact and an eye movement produce large deflections in an EEG trace. An EMG signal image and an EKG signal image sit alongside them, showing that the same amplifier can pick up other bioelectrical signals. Those four cases together describe the real problem with consumer-grade EEG. The signal you want is smaller than the signal you do not want, and no amount of filtering recovers a channel that was contaminated at the electrode. A separate `2.Data_filter.py` and the `processing/` and `dataset/` directories show that filtering and offline analysis were part of the workflow rather than an afterthought, but the artefact capture in the README is the reason to read the processing code before trusting a filtered trace. The `datasheet/` directory and the reference to the ADS1299 in the project topics point at the amplifier chip the shield is built around, which is the first place to look for the input range and noise figures that bound what any of this code can extract. ## What lives beside the scripts, and where the project moved The supporting directories give a sense of the whole project rather than just the acquisition path. `Manual/` holds documentation, `Supplementary files/` holds figures including the general view and wiring images referenced from the README, and `dataset/` holds recorded data. `GUI/`, `Robot_control/` and `service/` show the three directions the work went: a desktop interface, control of an external device, and a network service. The `service/` directory and the pinned `Flask` and `aiohttp` versions fit with the PiEEG Server project the README names as the software, and the separate GitHub organization `pieeg-club` holds both this repository and the PiEEG one. The SDK is also documented in a video manual, and there is a start-up video linked from the README. For someone evaluating the whole ecosystem, the practical reading is that the moving parts are the PiEEG hardware, the scripts now in the PiEEG repository, and the PiEEG Server software, with this repository as the earlier generation of the code. The commercial side is also visible: PiEEG is sold through a partner shop, and the project publishes a citation to a 2021 conference paper on the Raspberry Pi shield for measuring EEG, with a DOI and an IEEE link. None of that changes the support status of this repository, but it does mean the hardware, the manufacturer and the current scripts all have a reachable home, unlike the code in this snapshot. ## Conclusion EEGwithRaspberryPI fits an engineer who already owns a PiEEG shield and wants to read the underlying scripts to understand how the SPI read, the filtering and the soft real-time loop are put together. It does not fit anyone looking for a maintained library, since the repository description says it is not supported and points to the PiEEG repository for the current script locations. Before using any of it, read the warnings section: the device must run from a 5V battery with full isolation from mains, and a monitor powered from the Raspberry Pi is required. If you are starting fresh, take the PiEEG repository and the PiEEG-server project instead of this one. ## FAQ ### How many EEG channels can the PiEEG shield measure with Raspberry Pi? The project description states that it measures 8 EEG channels using the PiEEG shield and a Raspberry Pi. The scripts in the repository read that data in C, C++ and Python. ### Is EEGwithRaspberryPI still maintained? The project description says it is not supported, and the README states that the actual locations for the scripts will be in the PiEEG repository. The last push to this repository was on 2026-07-19. ### What power supply is safe for the PiEEG shield? The README states the device must operate only from a 5V battery, that complete isolation from mains power is required, and that it must not be connected to mains power via USB or otherwise. Only a monitor powered by the Raspberry Pi should be used. ### Which Python packages do the EEGwithRaspberryPI scripts need? The `requirements.txt` file pins the environment, including `brainflow==5.0.0`, `mne==0.23.4`, `neurokit2==0.1.4.1`, `pylsl==1.15.0`, `numpy==1.21.3`, `pandas==1.3.4`, `pyqtgraph==0.12.2`, `Flask==1.0.2` and `aiohttp==3.7.4`. ### Is PiEEG a medical device? No. The README states that PiEEG is not a medical device and has not been certified by any government regulatory agency for use with the human body, and that you are fully responsible for your decision to purchase and use it. ## Sources - [Issues](https://github.com/pieeg-club/EEGwithRaspberryPI/issues) - [pieeg-club/EEGwithRaspberryPI on GitHub](https://github.com/pieeg-club/EEGwithRaspberryPI) - [README](https://github.com/pieeg-club/EEGwithRaspberryPI/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pieeg-club-eegwithraspberrypi