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

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

The app includes the ability to assess up to 17 more sites with a 4 channel. Community based norms and assessment of those sites is available in addition to the ClinicalQ.

There is also an app that has removed ClinicalQ data and relies on community based assessment.

As long as you can create EDF data files you can use this.

If anyone on the forum is using BioEra software I can provide you with a design that leads you through recording the ClinicalQ data gathering. I have a limited number of slots for this. If you do this you will receive a copy of the assessment for up to 17 sites at no charge

1. Subject hair/scalp is cleaned beforehand.
2. EEG cap is placed on the head.
3. Through each electrode opening, we use the syringe tip/needle carefully to move hair aside right beneath the hole that we see.
4. Conductive gel is then inserted through the opening into the electrode cavity until contact is made with the scalp (we ask the subject as of now if he feels the gel if he says yes we assume that the contact is made).
5. This is repeated for C3, Cz, C4, REF, and GND electrodes.

Now on the hardware settings button of the Open BCI GUI :

• SRB1 = ON
• SRB2 = OFF
• Bias = ON
• Input type = Normal
• Gain = 1x (i checked online and it is suggested to be 24x but i am not sure about it)

Reference/Ground placement:
Currently the cap’s built-in REF and GND positions are being used and they are on the scalp itself . We have not yet moved REF to the ear lobe or BIAS/GND to the forehead.

Current observations:

• We can clearly observe large jaw clench artifacts, especially on C3 and C4.
• Cz shows comparatively lower jaw artifact amplitude which i think is normal.
• However, eye blink and eye movement artifacts are not very clearly visible because it might be covered due to noise.
• In the OpenBCI GUI impedance/N-status check, we typically see around ~5000 kΩ impedance per channel even after all the gel application.

Our current analysis/suspicion:
We suspect the issue may be related to one or more of the following:

• REF/GND placement,

• using the top pins instead of bottom pins,

• very high impedance,

i think if the impedence can be brought down to an acceptable level the noise would itself reduce and we will be able to see the signals like eye blink and eye movements

2) EMG, using two input electrodes on +1 and -1, and the reference on G_D, placed on the proximal–distal forearm, with the reference on the elbow. I also used gel electrodes and snap cables.

3) EEG, using two input electrodes at Fp1 and Fp2, with reference on the earlobes, connected to REF and G_D. I used dry polymer Ag/AgCl electrodes (the ones available on the OpenBCI website), ear-clip reference electrodes, snap cables, and a headband to secure the reference electrodes.

However, when moving to the next step of recording signals from the primary motor cortex, I encountered a problem: a strange noise appears constantly on all four channels. After connecting two dry electrodes to +1 and +2, and the ear-clip electrodes to G_D and REF, the recording started showing a continuous periodic noise (so much so that at first I thought it was an ECG artifact). I tried changing several times the placement of both the recording electrodes (moving them to Fp) and the reference electrodes (placing two gel electrodes on the mastoids), but the noise never disappeared. The input impedances appeared to be within normal range, but what confused me the most is that even when only the reference electrodes are connected, and even when they are not attached to the body, the same periodic signal is still present in all recording conditions (I also tried ECG and EMG recordings, and the same issue appears).

What could this be due to? How can I fix it? Am I doing something wrong? I am also attaching pictures of both successful and failed recordings.

My name is Rahela and am currently conducting doctoral research on how employees perceive wearable Brain-Computer Interface (BCI) technologies in the workplace, and I would love your input. I`d be grateful if you could take 10–15 minutes to complete my anonymous survey. There are no right or wrong answers, your honest perspective is what matters most. All responses are completely anonymous and voluntary. The survey explores employee attitudes toward wearable BCI devices at work, expectations and concerns regarding emerging workplace technologies, and how these innovations may shape the future of work.

Take the Survey here: https://1ka.arnes.si/a/0c999ab2

There are no direct material benefits for participants. However, your contribution will directly support the development of the first empirically validated guidelines for the ethically responsible implementation of BCI technology in organizations. Every response makes a real difference to my research.

Should you have any questions, please do not hesitate to contact me.
Thank you sincerely for your time and valuable contribution to this research.
Rahela

Disclaimer:
This research is conducted solely for academic purposes as part of a self-funded doctoral study. The study is entirely independent and has no affiliation with, sponsorship from, or representation of any current or previous employer. All analyses, interpretations, and conclusions are exclusively those of the researcher.

I am exploring the possibility of using OpenBCI cEEGrid together with Cyton + Daisy for advanced neurophysiological studies involving:

• jaw jerk reflexes
• trigeminal dynamics
• silent period analysis
• jaw clenching activity
• peri-auricular EMG activity
• multimodal electrophysiology

I would like to better understand the practical capabilities and limitations of cEEGrid in this context.

More specifically:

1. Has cEEGrid ever been used for:

• jaw muscle activity
• trigeminal reflex studies
• peri-auricular EMG
• jaw clenching detection
• facial or masticatory muscle recordings

2. What is the practical frequency bandwidth of cEEGrid when used with Cyton/Daisy?

3. Is the signal quality sufficient for short-latency reflex-related activity?

4. Can cEEGrid be combined simultaneously with:

• standard surface EMG
• external trigger systems
• piezoelectric reflex hammer synchronization
• electrical stimulation paradigms

5. Are there known limitations regarding:

• muscle artifacts
• stimulation artifacts
• temporal precision
• synchronization

6. Has anyone attempted multimodal acquisition combining:

• ear-centered EEG
• facial EMG
• trigeminal reflex timing
• jaw activity

Thank you very much.

I am evaluating Cyton + Daisy for advanced neurophysiological EMG reflex studies.

My setup would involve:

• piezoelectric reflex hammer (trigger input)
• external electrical stimulator
• jaw jerk reflex recordings
• silent period analysis
• paired stimulation paradigms
• recovery cycle studies

I already found documentation about external trigger INPUT through GPIO pins.

My main question is about TRIGGER OUTPUT.

Can Cyton generate a deterministic hardware TTL trigger OUTPUT capable of synchronizing an external electrical stimulator with millisecond precision?

More specifically:

1. Can Cyton send hardware trigger pulses (TTL) to external devices?

2. Is trigger output timing deterministic and stable enough for reflex latency studies?

3. What is the expected trigger output jitter/latency?

4. Can trigger input and trigger output operate simultaneously during acquisition?

5. Has anyone used Cyton for:

• trigeminal reflex studies
• jaw jerk recordings
• silent period paradigms
• paired pulse stimulation
• recovery cycle studies

Thank you very much.

I then soldered everything together and the board was ready for chapter two.
The next big challenge was to flash the firmwares, but with a lot of research in the forum and on google plus a lot of patience it was finally possible. Here the final result!

I have a bit of packet loss (2-4%) I think due to the thickness of the board and the length of the copper-wire-vias but it works super fine for me…
I also built some active electrodes but I’ll probably make another post dedicated to that.
The next journey will be to build an uploaded/modern version of the Cyton (plus integrated daisy) since the technology used by OpenBCI was good 10-15 years ago but it’s now pretty obsolete and one of the most important component (the RFD22301) is not in production anymore and a pretty old technology. So I hope that I can give you some news soon.
Thanks for reading

I'm Mariana, a Information System undergrad from Brazil, and I'm building a DIY EEG headset from scratch for my thesis. I'm a complete beginner in hardware, but I've been studying every component carefully before purchasing anything.

Here's the architecture I'm planning:

• Ag/AgCl electrodes at Fp1, Fp2, F3, F4 (10-20 system)
• Passive RC filters at the input — anti-aliasing and RF protection
• ADS1299 as the analog front-end — internal PGA, 24-bit, 8 channels
• LiPo battery for isolated power supply (no wall power on the headset side)
• Optical isolator on the SPI data channel — to physically separate the headset from the ESP32
• ESP32 for Bluetooth transmission to PC
• BrainFlow for data streaming

Before I buy anything, I have a few questions:

1. Does this architecture make sense for a functional EEG headset?
2. Is the optical isolator on the SPI channel the right approach, or is there a better way to handle isolation?
3. Any components I should swap or add?
4. What are the most common mistakes beginners make at this stage?

Any feedback is hugely appreciated. Thank you!

We are currently looking for OpenBCI users interested in making money selling their neural data and will be conducting a pilot study this summer. If you're interested, please feel free to reach out here or at my email ucabmk5@ucl.ac.uk. If you're not interested, feel free to leave some feedback and let me know why : )

I'm looking to buy a used Cyton + Daisy
Biosensing Board (16-channels).

About the project: I'm the founder of
StrokeRehabOS Inc., developing a multimodal
EEG + sEMG platform for post-stroke motor
rehabilitation. Currently initiating a clinical
data collection pilot (n=40-80 stroke patients)
in preparation for an NIH SBIR Phase I
application (September 2026).

Preprint: doi.org/10.21203/rs.3.rs-9450294/v1

Requirements:

• Cyton + Daisy (16ch) together
• USB dongle included
• All 16 channels functional

Budget: ~$800 shipped to US address (Delaware).

Happy to request impedance test video before
purchase. Please reply here or PM me.

Thank you!
Gregory Bulannikov
StrokeRehabOS Inc.

These wrist mounted sleep trackers really aren't very good. EEG is the best.

I think some kind of adhesive electrodes with a light, small data logger would be the best idea. I mean when you are tossing around with your head on a pillow, any kind of low cost headware is probably going to get messed up.

Any hot tips on suitable amplifiers, data loggers, electrodes, analysis software? I'm willing to hack stuff together etc. and indeed really wish these scientists publishing these articles would share their source code. The world is a bit nuts, the road to getting promising technology/techniques out there is ridiculous. There are various products that claim they can do this stuff but they are never ready to roll, and probably never will be. We do it like this or it doesn't get done, basically.

• I'm guessing they're dry electrodes but as its stated nowhere on the product page would like to confirm it.
• Is there anywhere I could get the exact dimensions of the electrodes as I need to design the hardware around them?
• I was thinking about connecting them to the pcb via pogo pins as all of the snap cables ive found have the cable horizontally. Is there any other "recommened" way of connecting them with a PCB that will sit right above them?

Thanks