• 3D printed my own Mark III headset with the electrode holders and whatnot
• used normal regular jumper cables
• used comfort combs from the store (link)
• screwed on my own nuts and screws

Here's what I see on the OpenBCI GUI when I used my own 8-channel montage - one is with 50+60Hz filter and the other is without:


How do I know if my headset is working properly? I am very perplexed by the straight lines after filtering. Thank you in advance everyone!

Dry comb electrodes are assembled on Medium 3-D printed cap. Headset print is rough and imperfect up close (printed by students at Uni), but reliable. Can be unassembled and shipped with or without cap.

Contains

• 8-Channel Cyton + 8-Channel Daisy
• Dongle
• 16 Dry Comb Electrodes plus extras
• Over 150 Foam Solid Gel Electrodes for EMG/ECG & storage case
• 1 rechargeable lithium battery & Adafruit USB charger
• Original holder for AA batteries
• Y-splitter
• Ear clips
• Clear board case
• 10 snap electrode cables
• Glass model head not included
  Contact me at candace@insidetheskin.com
  
  
  
  
  
  
  

Lot includes:

Cyton 8 channel board
USB dongle
9 electrodes (6 wired into home made head gear, plus three extra electrodes)
One set of electrode ear clips
home made head gear (not research grade, but it works for fun experiments
battery holder,
USB cable with Cyton size power plug (to run off external battery or wall charger)
original boxes and sticker

What came out:

• sEMG voiced → silent transfers (small but above the permutation null).
• EEG spoken → imagined does not, on Nieto or FEIS.
• Imagined speech collapses across days (Nieto: within-session 34%, leave-one-session-out at chance).
• Same-trial splits fake a transfer effect (FEIS 8.7%, p = 0.0002) that temporal-block splits remove (6.4%, chance). Same classifier, only difference is temporal proximity.

Repo with code, tables and feature caches (MIT, DOI on Zenodo):
https://github.com/gilbertoluporini-create/imagined-speech-baselines

Would love to hear from anyone with Ultracortex / dry-electrode experience on electrode repeatability across sessions. That is now the first gate of the project, before any decoding.

Greeting! I am a composer from Taiwan.

I would like to share my recent project that I have been working since 2025. This project focuses on the interaction between AI music improvisation (based on Somax2 of Max/MSP) and EEG (using Ultracortex). Here is the short demo of my work:

In this experiment, EEG signals are captured through the headset and used to estimate different mental and affective states, including arousal/valence and concentration. The EEG data are first sonified in Max/MSP, transforming brain activity into sound. These resulting sounds then interact with the parameters of Somax2 in real time, creating a continuous musical dialogue between brain activity, sound, and machine improvisation.

I have been experimenting with an Affective State widget for the OpenBCI GUI (v6.0.0-beta.1) and would really appreciate some feedback from the community! As I am not from coding background, so I created Arousal/Valence detection widget with help of Claude and ChatGPT to see if this is possible to work out...I have attached the photo of the widget in this post! [] (https://openbci.com/forum/uploads/editor/1r/hx9zyd3h6cbq.png "")

This project started out as an intense curiosity and has been a tremendous amount of fun. This is not a professional project. I did this for fun. I have no real idea as to whether it is valuable to anyone. The project is called PRAYCG. It is an exploratory psychophysiology protocol and software stack for testing whether naturalistic narrative stimuli produce measurable EEG/autonomic state trajectories beyond low-level sensory entrainment and beyond analytic task demand.

This is not a clinical tool, not a diagnostic system, and not a claim that OpenBCI can prove consciousness, memory biology, or any metaphysical theory. It is best understood as an open-source methods workbench for stimulus preparation, acquisition logistics, timing/QC, and exploratory analysis.

What the protocol does
The core design is a three-arm naturalistic viewing protocol:

Phase-scrambled sensory control
The source video is scrambled so recognizable story/faces/narrative meaning are damaged while low-level audiovisual structure is partially preserved. This is meant to ask: “Is the response just light, sound, motion, cuts, rhythm, cue timing, or audiovisual energy?”
Target narrative
The intact narrative is watched naturally. This asks: “What happens when the story is allowed to land?”
Contextual Override
The same intact narrative is watched again, but with an analytic task, usually an upper-right number-cue running-sum task. Target and Override use the same cue-embedded video; only the instructions differ. This asks: “What changes when the participant is measuring/extracting rather than receiving?”

Current hardware stack
My current setup uses:
OpenBCI Cyton + Daisy
OpenBCI gelfree/gelless cap workflow
BrainFlow/LSL EEG stream
LabRecorder XDF recording
ALS-PT19 or similar light sensor for physical screen timing
Polar H10 R-R intervals
Vernier respiration belt
optional Faraday/shielded enclosure setup(see the box section on github)
PRAYCG2.0 protocol runner with structured event logs and self-report/confound reports

What the software release includes
The repository contains or will contain:
MediaPrep + StimulusFingerprint
prepares Target, Override, and phase-scrambled Control videos
embeds cue schedules
generates stimulus-side QC and exogenous regressors
supports predeclared anchor files for event-locked analysis

PRAYCG2.0 Protocol Runner
loads Control, Target, Override, cue schedule, and anchor file
logs structured events
includes pre-run display/audio calibration
includes branch-level self-report and confound reports
includes final reflection baseline
supports override task reporting
BrainFlow / ALS / LSL tools
OpenBCI streaming helpers
ALS/PT19 timing-sensor support
LabRecorder workflow documentation
stream checklist and timing-QC workflow
Master Comprehensive Analysis Suite
time-resolved feature extraction
artifact scoring
stimulus-regressor residualization
MRED/A-MRED endpoint-compression modules
MRED-Peak vs MRED-Resolution
DGA / Decoder Gate Availability
NUPI / Narrative Update Polarity Index
visualization tools
offline plain-English report generator
Documentation
full end-to-end SOP from media procurement to analysis
hardware- how to build a faraday cage for eeg studies
formula/module explanation report
Main analysis idea

The current primary analysis direction is called MRED: Meaning Recognition / Encoding Dissociation.
In plain language, MRED asks whether the system can distinguish:
immediate recognition of meaningful material, versus
delayed integration, after-state, or regulatory carryover.

The compressed endpoint layer currently separates:

MRED-Peak: acute anchor-locked recognition + delayed integration
MRED-Resolution: slower reflective/regulatory recovery after the stimulus
A-MRED: anchor-locked MRED candidate that must pass condition, artifact, and QC gates

I am not treating gamma as a “meaning biomarker.” Lower-gamma/high-frequency features are treated as artifact-sensitive candidate work-signal proxies. The pipeline tries to penalize or flag muscle activity, eye/forehead artifact, cue burden, sensory drive, respiration, confounds, and exogenous stimulus timing.

Why I am posting here
I am looking for critique from people who know OpenBCI, EEG acquisition, artifact handling, and LSL better than I do.

The areas where I most want feedback are:

OpenBCI Cyton + Daisy acquisition reliability
gelfree/gelless cap best practices
BrainFlow configuration
LSL stream naming and synchronization
LabRecorder setup and XDF recording workflow
ALS/PT19 photodiode/light-sensor timing validation
whether my start-pulse design should be longer or barcode-like
artifact control for gamma-band claims
EOG/EMG channel additions
jaw/forehead/eye artifact separation
respiration and HRV integration
whether the analysis suite is overbuilt and how it should be simplified
how to make the public GitHub repository easier for other OpenBCI users to run

Current limitations
The project is exploratory and self-run so far. Several pilot runs revealed exactly the kinds of issues that need better engineering:
timing-pulse detection needing a better physical ALS holder
BrainFlow/OpenBCI effective sample-rate variability
cue visibility/legibility issues in some stimuli
gamma-band artifact vulnerability
the need for EOG/EMG
the need for cleaner locked-anchor and timing workflows

I am not presenting pilot outputs as confirmatory. The point of the current release is to expose the machinery and invite technical critique before treating anything as strong evidence.

Links
GitHub repository:
https://github.com/hbanks87/praycg-open

Here is a list of the fun ideas/theories that I have come up with as a result of running this protocol. The following are not proven claims. They are the current working hypotheses made visible by the protocol,
software, and pilot failures/successes:

1. Meaning recognition and meaning integration can dissociate. A subject can recognize meaningful geometry without showing clean delayed integration under current proxies.
2. Peak-like meaning and resolution-like meaning appear to have different physiological shapes. Some events strike sharply; others settle slowly into afterglow.
3. Analytic extraction does not simply erase meaning. It can reroute, delay, tax, or alter the route by which
   meaning is accessed.
4. Sensory clarity and emotional impact are separable. Clearer semantic access can occur in one branch while stronger emotional absorption occurs in another.
5. Meaning requires access conditions. Sensory access, prior state-space, personal relevance, autonomic
   availability, low task burden, and low confound load all matter.
6. Baseline2 may be one of the most important windows for integration, but it is cumulative and cannot be attributed to Target alone without stronger design.
7. The phase-scrambled Control remains essential because sensory entrainment and meaning integration are not the same construct.
8. The suite is increasingly a theory of availability: whether a living system is available to decode, receive, and be changed by meaning.

Again, this is not a claim of proof. It is an open-source exploratory pipeline, and I am sharing it because I want the engineering and analysis assumptions challenged.

Thank you for taking the time to read this and have a wonderful day,
Hoyt

My specific questions are listed below:
1. Role of BIAS: I understand that the BIAS pin is used for noise cancellation, but could you explain in detail how it works?
2. Ground (SRB): How does the SRB function within the EEG system?
3. BIAS and SRB Relationship: What is the relationship between BIAS and SRB in the signal processing of EEG, ECG, and EMG?
4. Channel Implementation: I have experimented with combinations using BIAS and SRB with the active channels of the Cyton board. Could you explain how the 8 channels are implemented in terms of signal acquisition?
5. EMG Electrode Placement:Why must EMG active electrodes be connected in the “up and down” method to represent the potential difference of the muscle?
5.1. Why can’t we use the same top-channel method as in EEG?
6. Simultaneous Recording:Is it possible to perform simultaneous EEG and EMG recordings without interference?
7. Cross talk: While recording the EEG the EMG cross talk was occurring and during the measurement of EMG the ECG cross talk was occurring, why? to understand this please explain the circuit connections.

Thank you
Best regards,
Raghul Jayaprakash R

I'm Aaron, an independent maker/builder — sole developer of NeuralInducer.org, an open-source, non-commercial project exploring neural entrainment through light, sound, and vibration (Arduino-based devices).

I want to be honest upfront: I don't have EEG data yet. What I have is consistent subjective feedback from myself and several family members who use the devices regularly — reports of relaxation, easier sleep onset, and a "settling" feeling during the alpha protocol. That's it. No clinical claims, no "proof" — just a device that seems to do something, and a builder who wants to know if it actually induces measurable brain activity.

If anyone here has a Muse, OpenBCI, or similar setup and is curious to test it and look at the EEG, I'd love the feedback — good or bad. I can share build files, firmware, and full protocol details. Everything is open-source (CC BY-NC).

If you want to dig deeper, the full project — including the scientific background and research papers behind each protocol — is documented at neuralinducer.org.

If you're in the US and interested in testing the physical device itself rather than replicating it, I currently have two NeuroSync ALPHA units built (firmware v6.x — includes vibration/beep, Modo D) ready to send out — happy to work out the details with whoever's interested.

I'd genuinely appreciate any help with this project — whether it's testing, feedback, or just pointing out where I might be wrong.

Happy to answer questions here — my written English is decent, please bear with me if I take a bit to reply.

https://neuralinducer.org/

I am looking to sell my complete 16-channel OpenBCI setup (Cyton + Daisy + All-in-One EEG Cap Bundle).

I originally got this for a project that ended up changing direction. As a result, the equipment has been barely used and is in pristine, so I'm letting the whole bundle go for $1,800 OBO (Or Best Offer) (which is well below the ~$3.5k retail price) to move it quickly.

The equipment is in "like new" condition and has been very well taken care of.
Here is what’s included in the lot:

• Cyton 8-channel board + Daisy 8-channel module (attached)
• OpenBCI USB Bluetooth Dongle
• Complete EEG Electrode Cap (pre-wired)
• All standard adapter cables
• Bonus: I'm including a hard-shell tactical carrying case, a gel syringe, and a cleaning brush.

I have attached some pictures so you can see the condition.

Logistics: I am located in San Diego (CA). If you are local (e.g., around UCSD), I would love to meet up for a safe, in-person cash or Zelle transaction. If you are further away, I am happy to ship it via USPS/UPS Priority (we can figure out shipping costs in DMs).

Feel free to send me a direct message if you are interested or have any questions!

I would like to ask for help troubleshooting my Cyton setup. I have been wondering about this problem for a long time: why do the FFT plot and time-series signals from my EEG channels look almost identical across channels?

Current Setup

I am using:

• OpenBCI Cyton Board
• Ultracortex Mark III headwear
• OpenBCI GUI
• New electrodes and ear clip from Florida Research Instruments

I recently purchased new electrodes and a new ear clip from Florida Research Instruments to replace the old accessories, which were around 10 years old. I replaced six electrodes with the new ones.

Electrode Placement

My current electrode setup is:

• N1P: Oz
• N2P: O1
• N3P: O2
• N4P: Not connected
• N5P: Not connected
• N6P: Pz
• N7P: P7
• N8P: P8

In the OpenBCI GUI, I deactivated N4P and N5P because they are not connected.

Main Problem

When I look at the OpenBCI GUI, the time-series signals and the FFT plots seem almost identical across the active channels.

This makes me unsure whether I am recording real EEG activity from each electrode position, or whether there is a problem in the hardware, reference/ground connection, ear clip, or Cyton board itself.

Ear Clip Check

I read in some other forum posts that similar problems can be related to an ear clip or reference/ground issue.

However, I recently bought a new ear clip, so I am not sure if the ear clip is still the source of the problem. I also measured it using a digital multimeter, and the resistance was around 0.2 ohm, so the continuity seems good.

My Questions

If the FFT and time-series signals look almost identical across channels, what is the most likely cause?
Any guidance for troubleshooting this would be very helpful.

Thank you very much.

So I built edfcore, an open-source, zero-dependency TypeScript library for reading EDF-family biosignal recordings directly in browser and Node.js applications.

Install:

npm install edfcore

It supports EDF, EDF+, BDF, and BDF+ and exposes signal samples, channel metadata, sampling information, physical units, annotations, and recording timelines programmatically.

A few parts of the format ended up being much stranger than I expected.

EDF doesn't actually have one global sampling rate. Every signal can contain a different number of samples per data record, meaning EEG at 256 Hz can coexist with a much slower physiological channel in the same recording.

EDF+ annotations are also encoded through a special signal channel rather than being ordinary metadata.

BioSemi BDF adds another issue: its samples are signed 24-bit integers. JavaScript provides convenient readers for 16-bit and 32-bit integers, but not 24-bit values, so those samples have to be reconstructed manually.

The reason I separated edfcore into its own package is that I don't want every browser EEG viewer, BCI application, or Node-based research tool to have to implement these details independently.

GitHub:
https://github.com/tayal-sarthak/edfcore

Documentation:
https://edfcore.vercel.app/

npm:
https://www.npmjs.com/package/edfcore

I also maintain edf2csv, a separate command-line tool for researchers who simply want EDF/BDF recordings converted into accessible CSV files:
https://github.com/tayal-sarthak/edf2csv

Both projects are MIT licensed.

I'd especially love feedback from anyone building browser-based EEG/BCI tools or anyone with unusual EDF/BDF recordings that would be useful for testing.

Thank you!

• 21 real-time neural feature modalities in both sensor and source space
• Real-time single-trial decoding (CSP + any scikit-learn classifier)
• Adaptive feedback protocols: z-score, threshold, percentile, staircase, operant/RL-based, sham, multi-band, and cross-session transfer
• Online artifact-correction methods: ASR, adaptive LMS, GEDAI, ORICA, real-time Maxwell/SSS filtering for MEG
• Live visualization windows: Raw signal, NF feedback curves, epoch overlays, scalp topographies, 3D brain activity, TFR heatmaps, …
• External feedback output via OSC (Max/MSP, SuperCollider) and LSL outlets (PsychoPy, OpenViBE, BCI2000)
• BIDS-compatible session saving
• Full CLI

Use cases it’s built for: neurofeedback research, real-time BCI/motor-imagery decoding, and any closed-loop paradigm needing live feature extraction + adaptive feedback + artifact correction in one place.

Any feedback, issues, feature request, or contributions, especially from anyone doing real-time work who can stress-test it against their own hardware/paradigms are welcome!

Thanks!
Payam

An additional question if anyone could answer it, where might I find a good site to buy EEG caps at 3 different sizes (large, medium, small) that would be compatible with these electrodes. Something like this cap I found on amazon:

https://www.amazon.com/Meditation-Tracking-Relaxation-Elasticity-Comfortable/dp/B0GT3SR576/

Hello OpenBCI community,

I would like to ask for help troubleshooting an old Cyton Board with Cyton Radio USB Dongle / RFduino.

I am using an Ultramark III system with a Cyton Board and Cyton Radio dongle. This equipment was purchased for our laboratory before 2018 by my late friend. I am now trying to use it again for my research.

Background

The last time I successfully used this system was around July 2018. At that time, I believe I was using OpenBCI GUI v3.4.0 on Windows. If I remember correctly, there were two executable files: OpenBCI Hub.exe and OpenBCI.exe.

At that time, the software and hardware worked well, and I was able to record EEG data.

However, in 2026, when I tried to use the system again, I could not connect to the Cyton Board and could not record any data.

Main Problem

The OpenBCI GUI can detect the Cyton Radio USB dongle, but it cannot connect to the Cyton Board.

The main warning/error message is:

[WARN]: Found a Cyton dongle, but could not connect to the board. Auto-Scanning now...
CytonAutoConnect: Error reading from Serial/COM port
[ERROR]: Unable to connect to Cyton. Please check hardware and power source.

Complete Console Log

Console Log Started at Local Time: 2026-05-30_10-39-37
Screen Resolution: 1680 X 1050
High-DPI Screen Detected: true
Operating System and Version: Mac - 26.5
MacOS Details: MacOS Catalina
JVM Version: 17.0.6
Welcome to the Processing-based OpenBCI GUI!
For more information, please visit: https://docs.openbci.com/Software/OpenBCISoftware/GUIDocs/
OpenBCI_GUI::Setup: GUI v6 Sample Data exists in Documents folder.
Settings: LogFileMaxDuration = 60 minutes
OpenBCI_GUI::Settings: Found and loaded existing GUI-wide Settings from file.
ControlP5 2.3.6 infos, comments, questions at https://github.com/retiutut/controlp5
TopNav: Internet Connection Successful
Local Version: v6.0.0-beta.1, Latest Version: v6.0.0-beta.1
GUI is up to date!
Unpacking to: /Users/nugrohobudi/Library/Caches/JNA/temp/libGanglionLib.dylib
Unpacking to: /Users/nugrohobudi/Library/Caches/JNA/temp/libneurosdk-shared.dylib
Unpacking to: /Users/nugrohobudi/Library/Caches/JNA/temp/libsimpleble-c.dylib
Unpacking to: /Users/nugrohobudi/Library/Caches/JNA/temp/libMuseLib.dylib
Unpacking to: /Users/nugrohobudi/Library/Caches/JNA/temp/libBrainBitLib.dylib
Unpacking to: /Users/nugrohobudi/Library/Caches/JNA/temp/libBoardController.dylib
BrainFlow Version: 5.10.0
OpenBCI_GUI: AuditoryFeedback: Loading Audio...
OpenBCI_GUI: AuditoryFeedback: Done Loading Audio!
CP: Playback History Size = 2
OpenBCI_GUI::Setup: Setup is complete!
sourceList: click! 
OpenBCI_GUI: Channel count set to 8
ControlPanel: Found Cyton Dongle on COM port: /dev/cu.usbserial-DB00MEQK

-------------------------------------------------
ControlPanel: Attempting to Auto-Connect to Cyton
-------------------------------------------------

ControlPanel: Found Cyton Dongle on COM port: /dev/cu.usbserial-DB00MEQK
CytonAutoConnect: Error reading from Serial/COM port
[WARN]: Found a Cyton dongle, but could not connect to the board. Auto-Scanning now...
CytonAutoConnect: Error reading from Serial/COM port
...
CytonAutoConnect: Error reading from Serial/COM port
[ERROR]: Unable to connect to Cyton. Please check hardware and power source.
SHUTDOWN HOOK

What I Have Tried

I have already tried the following:

1. MacBook Air M1

   • macOS 26.5
   • OpenBCI GUI v6.0.0-beta.1
   • Cyton Radio dongle connected using two different USB-C adapters

2. Windows 10 22H2

   • FTDI driver updated through Windows Update
   • OpenBCI GUI v6.0.0-beta.1
   • Cyton Radio dongle connected directly to the USB port

3. Windows 10 22H2 with older OpenBCI GUI

   • FTDI driver updated through Windows Update
   • OpenBCI GUI v3.4.0
   • Cyton Radio dongle connected directly to the USB port

4. Firmware check attempt using terminal program

   • I tried using a terminal emulator program on Windows 10:
     https://sites.google.com/site/terminalbpp/

   • I read in the forum that sending the ? character through a terminal emulator may show the firmware version.

   • However, I am not sure whether I did it correctly, or whether this method applies to both the Cyton Board and the Cyton Radio dongle.

5. Changed COM port number in Windows Device Manager

   • I changed the Cyton Radio dongle COM port number from COM7 to COM10.
   • I tried connecting again in OpenBCI GUI after changing the COM port.
   • The problem still remained, and the GUI still could not connect to the Cyton Board.

Procedure I Used in Each Test

For all tests, I used the following procedure:

1. Open OpenBCI GUI.
2. Connect the Cyton Radio USB dongle.
3. Set the Cyton Radio dongle switch to GPIO_6.
4. Turn on the battery to power the Cyton Board.
5. Set the Cyton Board switch to PC.
6. Use a fresh battery.
   • I checked the battery voltage using a multimeter, and it showed around 6.1 V.
7. In OpenBCI GUI:
   • Select System Control Panel
   • Select Cyton (Live)
   • Select Serial from Dongle
   • Tried both Auto Connect and Manual connection.

Firmware Information

From my previous post in this forum around 2018 , I found that my Cyton firmware version was identified as:

Firmware version: 1.0.0

I have not updated or flashed the firmware yet, because I do not want to damage the board or dongle before understanding the problem clearly.

My Main Question

Could the old firmware version 1.0.0 be the source of this connection problem?

More specifically:

1. Is Cyton firmware v1.0.0 still compatible with current OpenBCI GUI versions, such as v6.0.0-beta.1?

2. How can I safely check the current firmware version of:

   • the Cyton Board
   • the Cyton Radio USB Dongle / RFduino

Any recommended troubleshooting sequence before attempting firmware updates would be very helpful.

Thank you very much.

Best Regards,
nug

RFduino compile variables

-------------------------

name=RFduino Boards
compiler.path={runtime.ide.path}/hardware/tools/gcc-arm-none-eabi-4.8.3-2014q1/bin/
compiler.c.cmd=arm-none-eabi-gcc
compiler.c.flags=-c -g -Os -w -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -Dprintf=iprintf
compiler.c.elf.cmd=arm-none-eabi-g++
compiler.c.elf.flags=-Os -Wl,--gc-sections
compiler.S.flags=-c -g -assembler-with-cpp
compiler.cpp.cmd=arm-none-eabi-g++
compiler.cpp.flags=-c -g -Os -w -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -Dprintf=iprintf
compiler.ar.cmd=arm-none-eabi-ar
compiler.ar.flags=rcs
compiler.objcopy.cmd=arm-none-eabi-objcopy
compiler.objcopy.eep.flags=-O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0
compiler.elf2hex.flags=-O ihex
compiler.elf2hex.cmd=arm-none-eabi-objcopy
compiler.ldflags=
compiler.size.cmd=arm-none-eabi-size
size.script.path={runtime.platform.path}/tools
size.script.cmd=size
size.script.cmd.windows=size.bat
compiler.define=-DARDUINO=

this can be overriden in boards.txt

build.extra_flags=

RFduino compile patterns

------------------------

Compile c files

recipe.c.o.pattern="{compiler.path}{compiler.c.cmd}" {compiler.c.flags} -mcpu={build.mcu} -DF_CPU={build.f_cpu} -D{software}={runtime.ide.version} {build.extra_flags} {includes} {build.variant_system_include} "{source_file}" -o "{object_file}"

Compile c++ files

recipe.cpp.o.pattern="{compiler.path}{compiler.cpp.cmd}" {compiler.cpp.flags} -mcpu={build.mcu} -DF_CPU={build.f_cpu} -D{software}={runtime.ide.version} {build.extra_flags} {includes} {build.variant_system_include} "{source_file}" -o "{object_file}"

Create archives

recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} "{build.path}/{archive_file}" "{object_file}"

Combine gc-sections, archives, and objects

recipe.c.combine.pattern="{compiler.path}{compiler.c.elf.cmd}" {compiler.c.elf.flags} -mcpu={build.mcu} {build.extra_flags} "-T{build.variant.path}/{build.ldscript}" "-Wl,-Map,{build.path}/{build.project_name}.map" -o "{build.path}/{build.project_name}.elf" "-L{build.path}" -lm -lgcc -Wl,--cref -Wl,--check-sections -Wl,--gc-sections -Wl,--entry=Reset_Handler -Wl,--unresolved-symbols=report-all -Wl,--warn-common -Wl,--warn-section-align -Wl,--warn-unresolved-symbols -Wl,--start-group {object_files} "{build.variant.path}/{build.variant_system_lib}" "{build.variant.path}/libRFduino.a" "{build.variant.path}/libRFduinoBLE.a" "{build.variant.path}/libRFduinoGZLL.a" "{archive_file_path}" -Wl,--end-group

Create eeprom

recipe.objcopy.eep.pattern=

Create hex

recipe.objcopy.hex.pattern="{compiler.path}{compiler.elf2hex.cmd}" {compiler.elf2hex.flags} "{build.path}/{build.project_name}.elf" "{build.path}/{build.project_name}.hex"

Compute size

recipe.size.pattern="{compiler.path}{compiler.size.cmd}" -A "{build.path}/{build.project_name}.elf"
recipe.size.regex=^(?:.text|.data|.rodata|.ARM.exidx)\s+([0-9]+).*
recipe.size.regex.data=^(?:.data|.bss|.noinit)\s+([0-9]+).*
recipe.size.regex.eeprom=^(?:.eeprom)\s+([0-9]+).*

RFduino Uploader tools

----------------------

tools.RFDLoader.cmd=RFDLoader
tools.RFDLoader.cmd.windows=RFDLoader.exe
tools.RFDLoader.upload.params.verbose=
tools.RFDLoader.upload.params.quiet=
tools.RFDLoader.path={runtime.platform.path}
tools.RFDLoader.upload.pattern="{path}/{cmd}" -q {serial.port} "{build.path}/{build.project_name}.hex"

The next step was to modify the RFduinoGZLL.h because I always got the error 'class RFduinoGZLLClass' has no member named 'channel' while compiling the sketch. To fix this issue add, at the very end of the script (under the line "extern RFduinoGZLLClass RFduinoGZLL;" ) extern int RFduinoGZLL_channel;
After this editing, I´ve followed the required steps to programm the Radios that you can find here https://docs.openbci.com/Cyton/CytonRadios/ and everything worked out perfectly, so that now the dongle and the cyton board are communicating.

If you have some questions feel free to ask
Happy tinkering

I applied a 1 Hz high-pass filter, but the data still shows a very large proportion of high-amplitude values. Overall, about 55% of samples have absolute values greater than 100 µV, which seems too high for usable EEG.

My question is: how to process or clean this dataset, since standard filtering does not seem sufficient?

1. Channel data screenshot:
   

2. Percent of samples with |amplitude| > 100 µV per channel:
   

3. Additional channel statistics:
   

Thank you so much for your guidance!

https://github.com/PJHkorea/consciousness-auto-rotation-artificial-neural-bypass/blob/main/fluxmesh_hybrid_test_core.h

This project focuses on implementing a real-time signal detection and noise acceleration core engine tailored for 64-bit native embedded environments. By completely eliminating heavy multidimensional matrix operations and partial differential equations (PDEs), we achieved high efficiency.

Standard hardware architectures are heavily limited during high-frequency, real-time processing because of electrical noise and sensor dropouts. Our engine solves this at the software level using a low-cost, grid-array-based chip topology. Instead of relying on expensive single-board computers, we use a grid of low-cost microcontrollers that only talk to their immediate neighbors (North, South, East, and West). Imagine a dense, chessboard-like hardware layout made of ultra-small, cheap MCU chips. This setup guarantees deterministic execution timing and provides incredible fault tolerance.

1. Achieving 0% Cache Misses via Flat Scalar RegistersTo hit a strict 1 kHz deterministic loop timing, we completely ditched multi-dimensional arrays (float[][]) and pointer chasing. Instead, all algorithms are fully flattened down to the scalar register level (p00, p11). This allows the native 64-bit FPU to directly map the registers and execute them in a single clock cycle

2. Branchless State Rotation (Zero-Jitter 'if' Processing)We completely eliminated conditional statements (if statements) from the core execution path to prevent CPU pipeline flushes. Noise mitigation is smoothly handled through a Layer 1 vertical state rotation mechanism, which effectively notch-filters high-energy noise using continuous rotation.

3. Real-Time Scaling using Padé [1/1] Rational ApproximantCalling heavy transcendental functions like exp() inside a high-frequency loop is a major timing risk for embedded CPUs. Our engine swaps this out for a Padé rational approximant, turning the exponential curve into a simple arithmetic equation. This drastically cuts down the computing cost needed for continuous mapping.

4. Derivative-Free Mesh Bypass (Autonomous Fault Isolation)If a specific node suffers from non-stop, extreme noise or physical dropouts, Layer 1 automatically triggers local apoptosis and broadcasts an isolation signal to its neighbors. Instead of recalculating heavy PDEs across the whole grid, the engine applies a cross-axis negative sign (-) coupling to adjacent outputs. This clever math trick sparks a spontaneous clockwise vorticity (Curl), smoothly routing the signal flow diagonally around the dead zone until the faulty node bounces back to a stable state.