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!

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

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.

This system worked well last semester, however it has recently developed issues with the Cyton system becoming disconnected/failing to reconnect with the computer. Usually, during recording, a message would appear on the screen saying “An error has occurred during data recording, close the GUI and start a new session.” Following closing the GUI, I can open a new GUI, but when I try to record data, I have high packet loss (greater than 80% loss). I also can’t record data for longer than about 5 minutes without data loss occurring.

Previously, I had issues with the Cyton failing to reconnect with the computer after the initial GUI session was closed. I would usually get a message of “Dongle found but no Cyton board could be located.” I think this issue was resolved by only opening LabRecorder after the LSL streams had been opened in the OpenBCI GUI and PsychoPy. This theoretically ensures the data streams are fully established before LabRecorder tries to start recording them. I also found resetting the dongle and Cyton board using the physical buttons located on them could fix this issue.

However, I still felt this issue was relevant to the conversation because it was also a new issue that didn’t occur last semester, and as such it may be related to the unresolved issues I described above. To solve the issue of packet loss and failure to remain connected, I have tried closing all python programs running in the background in hopes of terminating a previous instance of the GUI that may have remained active. I’ve also tried resetting the hardware using the physical buttons on them. Finally, I’ve tried restarting the computer itself, but I still experience the difficulty with the Cyton+daisy being able to remain connected and record for longer than 5 minutes. I also still experience the related packed loss issue with the data I can record.

Please let me know what I should do next to solve this problem.

Please point me in the right direction as soon as possible. This is urgent. Thank you so much!

Additionally, it shows 11 channels here, but I am using an 8-channel device. What are the other 3 channels?

Also, due to my computer system, the EEG data format is .bdf.

I am very sorry, as I am a beginner with EEG devices. This question may indeed be very basic, but it has been bothering me for a long time. Can anyone help me solve these problem? Thanks in advance!

I am currently confused about the polarity (sign) of the EEG signals from the Cyton board.

In the following forum post, it is mentioned that the signal polarity from Cyton is inverted:
https://openbci.com/forum/index.php?p=/discussion/comment/16393#Comment_16393

However, when I compare signals from:

• OpenBCI GUI
• my own Python application using pyOpenBCI
• my own Python application using BrainFlow (Python)
  the polarity appears to be consistent across all of them.

In the OpenBCI GUI, both positive and negative values are clearly displayed on the graph, and they match what I observe in my own applications.

So my question is:
Is the Cyton signal actually inverted at the hardware level, and the GUI compensates for it?
Or is the GUI simply displaying the raw signed values from the board as-is?

For reference, my electrode setup follows the official EEG setup documentation:
https://docs.openbci.com/GettingStarted/Biosensing-Setups/EEGSetup/

(Reference electrode connected to SRB2, BIAS connected as recommended.)

I would appreciate clarification on how polarity is handled internally.

Thank you in advance.

According to the first comment here (https://openbci.com/forum/index.php?p=/discussion/3101/psychopy-brainflow-and-markers-resolved), the 3 AUX channels of the Cyton board can be used to record trigger and marker. The Cyton documentation (https://docs.openbci.com/Cyton/CytonExternal/) mentions 5 General Purpose Input and Output pins and explains how triggers can be manually sent from a physical push on the board.

I would like these triggers to be sent from Psychopy. I tried to follow this tutorial: https://psychopy.org/hardware/serialPortInstr.html#sending-triggers-via-a-serial-port

But I am not sure which port address I should use, nor how to find the port address for the Cyton AUX pins. More specifically, the port name is dev/ttyUSB1, but I cannot find its address. Running

setserial -g /dev/ttyUSB[01]

yields

/dev/ttyUSB1, UART: unknown, Port: 0x0000, IRQ: 0

And whichever address value I try in “Port” in the “Basic” properties of serialPort in Psychopy yields the following error:

raise SerialException(msg.errno, "could not open port {}: {}".format(self._port, msg))
serial.serialutil.SerialException: [Errno 2] could not open port 0x0000: [Errno 2] No such file or directory: '0x0000'
######## Experiment ended with exit code 1 [pid:215199] ########

My OS is Ubuntu 24.04. Any help is appreciated. Thanks!

With the networking widget, you can send Time Series, FFT, EMG, Band Power, Accel/Aux, and Pulse data. The Accel/Aux option allows you to send Accelerometer, Analog Read, or Digital Read data.

I am especially interested in the Digital Read data and in streaming times at which the push button on the Cyton board is pressed (cf. the OpenBCI GUI Networking Guide: https://docs.google.com/document/d/e/2PACX-1vR_4DXPTh1nuiOwWKwIZN3NkGP3kRwpP4Hu6fQmy3jRAOaydOuEI1jket6V4V6PG4yIG15H1N7oFfdV/pub).
However, only the following streams are available in the menu of the Networking widget (see also image):

• Focus
• EMGJoystick
• AVGBandPower
• TimeSeriesFilt
• TimeSeriesRaw
• EMG

(i.e. no option to choose Accel/Aux as it is shown in the documentation). This is the case for all protocols (LSL, UDP, OSC, Serial, although I am working with LSL) and even when the required widgets are activated. I'm working with the Cyton board and OpenBCI GUI v6.0.0 on Ubuntu 24. Thanks!

Setup

Hardware

• 1 × Cyton + Daisy board for EEG
• 1 × Cyton board for ECG
• Subject: Same person for EEG and ECG simultaneously
• Computers: Two separate Windows 10 computers (one per Cyton)
• Software: OpenBCI GUI with FTDI drivers installed

Radio configuration

• Each Cyton paired with its own USB dongle
• One system communicating on channel 10, the other on channel 20

Physical setup

• Computers are ~1 m apart, in the same room
• Each Cyton board is <2 m from its corresponding dongle

Electrodes / grounding

• EEG: Gel cap, GND electrode on scalp (Cyton + Daisy)
• ECG: GND electrode placed on the right hip (Cyton)

Power

• Both computers must be connected to mains power (recordings are too long for battery operation)

Issues encountered

1. Severe packet loss when both devices are connected, especially once electrodes are attached to the body.

   • Packet loss increases significantly compared to when boards are not connected to the subject.
   • Packet loss also appears when pressing the PROG button to generate a trigger (following this guide:
     https://docs.openbci.com/Cyton/CytonExternal/).

2. Occasional inability to start recording, even though sessions appear to start correctly in both OpenBCI GUIs.

   • The GUI reports “No signal received for 5 seconds.”

3. After stopping a recording, it is impossible to start a new one without completely restarting the setup.

   • We must close the GUI, reopen it, and redo channel selection and pairing.

4. Intermittent signal dropouts during recording, with the GUI again reporting “No signal received for 5 seconds,” even though nothing in the setup has changed.

5. Radio channel pairing issues:

   • At one point, one Cyton became stuck on channel 10 and its dongle on channel 20.
   • We were unable to re-pair the original Cyton–dongle pair (channel 10).
   • We tried auto-scan, unplugging the dongle, powering off the Cyton, closing the GUI, and restarting the entire pairing procedure (with the other Cyton powered off), but without success.

What we have tried / considered

1. Reducing distance between Cyton boards and dongles

• Bringing the boards very close to their dongles (<30 cm) significantly reduces packet loss and makes channel selection easier.

• We are considering using a USB extension cable for the dongles, as suggested in this thread:
  https://openbci.com/forum/index.php?p=/discussion/3216/packet-loss-with-cyton-mounted-on-head-resolved

• However, this raises a conceptual question: what is the intended benefit of wireless communication if the board needs to be this close to the dongle to function reliably?

2. Following the official multiple-Cyton procedure

• We carefully followed the instructions here:
  https://docs.openbci.com/Cyton/CytonRadioChannel/

• Unfortunately, this does not work reliably. Often we need to repeat the procedure multiple times, sometimes taking more than 20 minutes to get both devices working.

• According to the documentation, it should be possible to run up to 25 Cytons simultaneously. We are struggling to get even two to work consistently.
• Are there specific radio channels that should be preferred or avoided?

3. Clarification about “one pair at a time”

• The documentation states: “This procedure must be done one pair at a time.”

• Our understanding is:

  1. Pair and start a session with the first Cyton and its dongle
  2. Then pair and start a session with the second Cyton and its dongle

• Is this interpretation correct, or is a different sequence recommended?

Thank you very much in advance for your help and insights.

I’m experiencing an issue using a cEEGrid 16-channel system on a Windows laptop. Initially, all 16 channels work correctly. However, after a couple of minutes, the second half of the channels (channels 9–16) stop streaming and no longer appear.

I tried turning the device off and back on, but channels 9–16 remain missing.

Interestingly, when I test the same setup on a MacBook (on different days), all 16 channels work fine, even after more than 1 hour of continuous streaming.

Has anyone experienced a similar issue? Could this be related to the Windows OS, or possibly the use of a USB extension cable on the Windows laptop?

I plan to use this cEEGrid together with fNIRS, so I want to make sure everything is working properly before running real participants.

Thank you in advance for any suggestions or insights.

I assembled an EEG setup for the first time and I found quite a lot of line noise (50 Hz) unless I use the notch filter on the GUI. This seems to me quite odd, as the ADS1299 should have a fairly good CMRR, so I started digging into the schematics and have a couple of questions.
Regarding the feedback loop for the Bias pin of the Cyton Board: on the datasheet of the ADS1299 (and the evaluation board), there is a low-pass filter formed between BiasOut and BiasInv

whereas on the Cyton board, that filter is missing. There is, however, a filter formed by R5 and C16; what is the purpose of the latter? Just limiting the current? If so, why was the low-pass filter of the evaluation board avoided?

Thanks,
Federico

The problem appears already at step 6 for the very first channel—calling config_board("z{i}00Z") throws the exception above.
Could someone explain what I’m doing wrong or what I should change to avoid this decoding error?
Thanks in advance!

Recording Details

• Duration: ~5 hours (304 minutes)
• Board: Cyton Daisy
• File format: BrainFlow CSV
• Total packets received: 2,281,491
• Board: Cyton-Daisy

Cyton Daisy Packet ID System

Important context: The Cyton Daisy labels packets from 0 to 254, skipping odd numbers (0, 2, 4, 6, ..., 252, 254), then wrapping back to 0. This gives us 128 unique packet IDs per loop.

The Problem

I'm analyzing packet loss in my recording and found patterns that could be interpreted as either bugs in packet ID labeling OR real packet loss. I need help determining which.

Pattern #1: Duplicate Packet ID + Skipped ID

• Pattern: The same packet ID appears twice in a row, and the expected next ID is skipped

• Example: Received IDs 136, 136, 140 but expected 136, 138, 140

  • Packet ID 136 appears twice
  • Packet ID 138 is completely missing

• If this is real packet loss: Packets with duplicate IDs represent actual lost data (127 packets lost per wraparound)

• If this is a bug: The board failed to increment packet IDs correctly, but the data itself is present with wrong labels (minimal actual data loss)

Pattern #2: Backwards Packet

• Pattern: Packet ID decreases instead of increasing

• Example: Received IDs 120, 118 but expected 120, 122

  • After packet 120, the next should be 122
  • Instead received 118 (going backwards by 2)

• If this is real packet loss: 126 packets lost in a wraparound (120 → 122 → ... → 254 → 0 → ... → 118)

• If this is a bug: The board sent packets out of order or mislabeled them, but the data is present

Two Interpretations

Interpretation A: It's a Bug

• Packet IDs got scrambled/mislabeled
• Data exists but labels are wrong
• Evidence: Bimodal distribution, clustered with other bugs

Interpretation B: Real Packet Loss

• Hardware correctly reports wraparound (120→122→...→254→0→...→118)
• Actually lost 126 or 127 packets in transmission

Key Evidence

The reason it doesn't seem likely that these are real packet losses is because of the distribution of packet loss in my 5 hours of data.

Distribution of Packets Lost Per Packet Gap:

1-23 packets lost: 1454 gaps ██████████████████████████████████████████████████
24-99 packets lost:    6 gaps
100-125 packets lost:  148 gaps █████
126 packets lost (backwards pattern):  109 gaps ████
127 packets lost (duplicate/wraparound):  885 gaps ██████████████████████████████

This gap in distribution (24-99 range) suggests the 100-127 losses aren't natural wireless interference, but rather a bug in the packet ID labeling. If these were real packet losses, I'd expect to see the number of gaps taper off as the number of packets lost increases.

Timeline shows extreme clustering:
This could be a cluster of bugs, but it could also be a cluster of packet loss so it's not particularly informative but I thought I'd share it anyways.

• All three suspicious patterns (127, 126, and 100-125 packet losses) explode simultaneously at 3.3 hours

• The 198-204 minute window contains:

  • 652 gaps with 127 packets lost (duplicates)
  • 108 gaps with 126 packets lost (backwards)
  • 147 gaps with 100-125 packets lost

• Outside this window, packet loss is minimal and normal (1-23 packets lost)

Timeline Visualization:

      Time    127 (dup)   126 (back)      100-125 Visualization
--------------------------------------------------------------------------------
      0-6m            3            0            0 D
    24-30m           15            0            0 D
  ...
  192-198m           25            1            0 D B               <-- First backwards
  198-204m          652          108          147 DDD BBB SSS       <-- MASSIVE CLUSTER
  204-210m            1            0            0 D
  ...

Legend: D = 127 packet loss (duplicate), B = 126 packet loss (backwards), S = 100-125 packet loss

Questions for the Community

1. Is this a known OpenBCI bug? Has anyone seen backwards packet IDs or duplicate IDs?

2. How can I definitively tell the difference between real packet loss and packet ID bugs?

3. Should I assume packets are always delivered in
   sequential order, or could backwards jumps (120 →
   118), duplicates (120 → 120), and large gaps
   indicate out-of-order delivery or mislabeled packet IDs?

4. Is there a standard method for detecting accurate packet loss with
   OpenBCI/BrainFlow? Am I using the right approach (packet ID
   sequence analysis), or is there additional metadata I should be checking?

Impact on My Data

I'm using this EEG data for AI sleep stage classification. This will be used on live streamed data to score sleep in real time, though I'm testing it on recorded data. If the backwards patterns and duplicates are losses, I need to understand what amount of samples were lost to create accurate 30 second epochs. If this is a bug, it changes the amount of samples lost.

Any insights appreciated!

$ head -n 20 2024-09-13-21-24-32.brainflow.csv | cut -f 23
1726259073.024538
1726259073.024589
1726259073.024616  <-- 0.0027ms gap from previous here
1726259073.024641 
1726259073.024665
1726259073.024690
1726259073.024713
1726259073.024737
1726259073.024762
1726259073.024786
1726259073.024810
1726259073.024834
1726259073.024859
1726259073.024883
1726259073.024907
1726259073.085258  <-- ~60 millisecond jump here
1726259073.085329
1726259073.085353
1726259073.085378
1726259073.085402

I'm recording on a Raspberry Pi 5, from the dongle.

I've read through all the forum answers I could find, such as
https://openbci.com/forum/index.php?p=/discussion/1328/csv-data-files-contain-only-bursts-of-data-not-continous-streaming
https://openbci.com/forum/index.php?p=/discussion/2329/how-steady-is-cytons-sampling-rate-resolved

I've learnt from this that the Cyton itself should be outputting at something very close to a steady 250Hz (maybe with a small amount of fixed drift). So the buffering I'm seeing is probably introduced in some part of the stack between the dongle and the Brainflow.

Does anyone have any best practices for how to handle this? Should I be trying to recalculate estimated real timestamps based on the expected sample rate (which will be challenging, as the whole reason I'm doing this timestamp analysis is because I want to handle dropout periods where the Cyton couldn't communicate with the dongle). Are there any driver tweaks people can recommend? Should I be using the FTDI driver?

I understand that the OpenBCI GUI computes these values from the raw EEG stream (via FFT/PSD) using Brainflow, but I’d like to confirm the exact processing steps you use (e.g., window length, overlap, windowing function, normalization, etc.).

Would you be able to share or point me to the portion of the source code where the FFT and band power calculations are implemented? Having this reference would help me align my analysis with the GUI outputs for validation.

Thank you for your time and for all the amazing work you do to support the neurotech community.

**@wjcroft @retiutut **