1200 microvolt transients in SD card recordings ?

[wjcroft]

Was there ever any response or investigation, prompted by this research paper, comparing Cyton with a lab grade instrument? This is generally 'good' press for Cyton. But very 'bad' in one aspect. Mentioning @andrewjaykeller @conorrussomanno @produceconsumerobot .

https://www.researchgate.net/publication/328652867_An_EEG_Experimental_Study_Evaluating_the_Performance_of_Texas_Instruments_ADS1299

This paper was given featured exposure on a Community page post in November,

https://openbci.com/community/an-eeg-experimental-study-evaluating-the-performance-of-texas-instruments-ads1299/

They found these 1200uV spikes in SD card recordings. And removed them with their pre-processing.

This has to be some glitch in the SD card recording or decoding of the hex files. If these 1200 uV pulses were occurring in the normal over the air data streams, users would be screaming.

[wjcroft]

Note this statement in section 2.2.1 of the paper:

"For evaluation of the ADS1299, a prototype system was built using OpenBCI (OpenBCI, New York, NY, USA) V3-32 board along with a V3 Daisy module for supporting up to 16 channels, a 4N25 optocoupler, and required connectors. The firmware of the OpenBCI board was modified from version 3.0.0 (refer to supplementary files). The data were saved on the onboard SD card. The sampling rate was set at 250 Hz and programmable gain (PGA) at 24, as these settings result in minimum peak-to-peak input referred noise."

So... I'm unclear why they modified the firmware. I'll email the primary author and inquire. I suppose it's also possible that the 1200 uV glitches could be related to the SD card they were using. Wish they had contacted someone at OpenBCI before publishing this.

[wjcroft]

Firmware mods (git diff) are shown in this pdf. Received this from the correspondence author, Usman Rashid. This is the "supplementary material" that accompanied publication in the journal Sensors.

sensors-18-03721-s001.pdf

Below is the email reply I received from Usman,

---

Dear William The ResearchGate copy of the paper is a pre-print and that’s why the link does not work. We are replacing it with the published copy. Please find attached the supplementary file you mentioned.

As you may note the only change in firmware is to save the data to the SD card and an external cue signal. The cue signal was not used in this study.

I might agree with you that these glitches do not occur in streaming as using the same board earlier with pilot work we did not observe these glitches. But at that time data was collected in one session from three participants. We used bluetooth streaming at that time.

From the manuscript, discussion section: "This problem most likely originated from the way data were stored on the SD card using the OpenBCI board, as the error was also found in the raw data file before conversion from hexadecimal values. "

This was our most plausible explanation at that time. But you are right, we should have also considered using different SD cards to see if the problem persists.

Thank you very much for your email. When I find time, I will try to conduct these experiments on the same board and will post the results to you and to the OpenBCI Forum.

Cheers Usman R.

[wjcroft]

I've asked Usman to post here one of the hex files containing the glitches. The bit pattern of the glitch might give some clues.

[GallVp]

I was able to identify three recurring bit patterns from 11 out 132 files that I inspected. These patterns are: F00000, C00000, 800000. For C00000 and 800000 example blobs are attached. blob_C00000.txt blob_80000.txt

Details of the SD Card: Manufacturer: Verbatim Size: 16 GB Type info: micro SD, 1; HC I Class: 10

Under our current Ethics guidelines I cannot upload raw data files. Please let me know if any other information is required.

[wjcroft]

Usman, thanks very much for providing these examples of the glitches. Our hardware / firmware team is looking this over carefully, to see how these originated. And where to fix the issue. Our initial opinion is that your class 10 Verbatum SD card was not the failure point.

Best regards,

[wjcroft]

Usman, can you mention when you purchased your Cyton? That might give us some idea of the firmware and hardware level. You can see the firmware level in two ways:

(1) current OpenBCI_GUI will display the Cyton mainboard firmware level. After starting the GUI, select Cyton, serial port, then click on your COM port. After pressing "Start System", DON'T press "Start Data Stream" just yet. If you look on the bottom of the GUI window, you will see the Cyton firmware level displayed.

(2) It's also possible to see the Cyton firmware level, by connecting a serial port terminal emulator to the Cyton dongle COM port, and typing a '?'. Baud rate is 115200, this is set in the terminal emulator.

Knowing the approximate purchase date and reported firmware level will help us.

[wjcroft]

Ah, ok, rereading your paper, you state there that "The firmware of the OpenBCI board was modified from version 3.0.0 (refer to supplementary files)."

Did you manually upgrade your 2.x Cyton to 3.0.0 (plus your mods?) Because I'm not sure OpenBCI was shipping new orders with the 3.0.0 firmware immediately. I see a 3.0.0 came out in September 2017, then 3.1.0 in October 2017. It wasn't until March 2018 that 3.1.1 came out.

https://github.com/OpenBCI/OpenBCI_32bit_Library/releases

[GallVp]

I do not remember upgrading the board. The board was shipped on Sep. 23, 2016. This means that I must have upgraded the board myself later. Probably, I must have checked out the latest stable release from Github to apply the modification (git diff report in supplemental file) and uploaded the code to the Cyton board.

[wjcroft]

Usman, thanks. Yes, understand. You mention: "Probably, I must have checked out the latest stable release from Github to apply the modification..." And of course the conundrum here is that 3.0.0 from September 2017 was just the start of the 3.x series.

We're looking now to see if any SD card related firmware changed in that interim since Sep 2017. We'll be replicating some long SD card sessions in the lab with the latest 3.1.2 to see what we discover.

Do you remember how long of sessions lengths you recorded on your SD card when you encountered the glitches? Your paper mentioned about 10,000 samples between glitches. So that would be about 40 seconds, not very long to wait. Did you notice any difference in the SD card recording session length and glitch occurrence? So it seems likely we would find these even on a short 5 minute SD session.

[GallVp]

Figure 1 (from the paper and in the first comment in this post) can be used to estimate the average time for a recording session around 5 to 10 minutes. The data in Figure 1 is 8 minutes long. Some files had multiple glitches.