Openbci_gui: Markers sent from computer with "`n" (n=1..9) create important noise on the 16 channels

[tzvet]

This comes from #277 after a suggestion of @aj-ptw

Now there is another quite some big problem, sending Markers makes a huge
noise on ALL electrodes at marker onset. Any solution for this?"

First, on some trials there is no noise created. It looked a bit random but there were more trials with noise than without. See the two snapshots further below.

For sending the Markers, i first started the GUI and set all necessary things to get Markers "on", then started "Data stream", and then i used Octave with a simple "for loop" (it should work in Matlab too). Here the example code for the random timing between Markers:

txt_to_send = "echo -n '`8' > /dev/ttyUSB0";
t=nan(1,20); twait=0.5+rand(1,20); tic; for ii=1:20, system(txt_to_send); t(ii)=toc; WaitSecs(twait(ii)); end

I tested two Marker timings, one with fixed times every 1sec, then with the random time as in the example above. All had noise.

Operating System: lubuntu 16.04 + Octave + openBCI_GUI 3.2.0 standalone App

Type of OpenBCI board: cyton+daisy 16 channels + dongle

[tzvet]

Update: I was trying to check whether there are conditions where there are no noise created on the channels. But it seems ANY command from computer to cyton makes huge noise.
one can see it at press of "Start Data Stream" or at press of "Marker Mode On/Off" on the Marker Widget. I also tried few commands from terminal: /0, /4, ~~; they all made similar noise.

My opinion: it is the receiver on the cyton that makes this.

Important Note: in the two snapshots above, there is one trial where no noise was present, see the bottom pic between -2 and -1 seconds. I also saw other trials where Markers did not make noise. Thus there should be some solution.

[andrewjaykeller]

Thanks so much for explaining how you were using the markers! Very helpful. Ok so you are attempting to write to the serial port at the same time the OpenBCI GUI is using it and I would advise against that. That's what's causing your big spikes in a random but more times than not situation.

There is a UDP listener in the app that @gerrievanzyl put in that listens on port 51000 i believe and that's what you should send markers to. Or we can add code into OpenBCIHub to send the data to the board.

Thoughts?

[tzvet]

There is a UDP listener in the app that @gerrievanzyl put in that listens on
port 51000 i believe and that's what you should send markers to.

ok, i just read a little about the UDP protocol and found the place where the port 51000 is defined in the "Processing" version of the openBCI_GUI ... but that does not help me to know how to send in a simple way Markers to the board. Do you have some simple commands that do not mess around with the signal ? Would this UDP through port 51000 make the change and mess with signal ?

Or we can add code into OpenBCIHub to send the data to the board.

Ok, but i need an external program sending the Markers. I will retry the python binding (through LSL) and check whether this one makes also noise.

[andrewjaykeller]

Would this UDP through port 51000 make the change and mess with signal ?

No, the signal would not get distorted. You need to connect to port 51000 and send the markers, i assume one at a time.

Ok, but i need an external program sending the Markers. I will retry the python binding (through LSL) and check whether this one makes also noise.

I think you only need a small python script that generates your markers, or if you want we can pass through key presses when marker mode is active and send them in the right mannor. That might be best.

[tzvet]

UPDATE: i succeed to have an external time marker (photodiode) as input to D11. Made a test and all works fine, out of the problem of conversion (see #296 , where i added this issue too). Will try code Time stamps with computer generated markers sent to the cyton this week.
Thx for the help !

[gerrievanzyl]

Just got back in town. Will write up better instructions tomorrow.

On Mon, Dec 18, 2017 at 5:02 AM, tzvet [e-mail] wrote:

UPDATE: i succeed to have an external time marker (photodiode) as input to
D11. Made a test and all works fine, out of the problem of conversion (see

296 https://github.com/OpenBCI/OpenBCI_GUI/issues/296 , where i added

this issue too). Will try code Time stamps with computer generated markers
sent to the cyton this week.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/OpenBCI/OpenBCI_GUI/issues/297#issuecomment-352314235,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOSh_5aaftJFvjLqwpzatBuE8TQomm4Bks5tBdW1gaJpZM4Q_3EH
.

[gerrievanzyl]

Sorry for the delay in answering, I was in a remote part of South Africa with very spotty connectivity.

The "chirps" you see are repeatable, however it is not noise but rather an artifact of the 50/60Hz notch filter running in the GUI.

These "chirps" are not recorded on the SD card, but they are recorded in the saved GUI file

What seems to be happening is as follows:

• When the marker is sent over the BLE serial connection it often results in a missed packet (if you run the app in the Processing IDE you can see the missed packets)
• When the notch filters are active this missed packet results in the 'Chirp' artifact you see (if you turn off the notch filter you will see the artifacts are no longer there)
• If you look at the data on the SD card there are no problems.

When using wifi (and when the connection is not dropping packets) the maker mode does not cause these "chirps" it is problem caused by the BLE dropping packets when a marker is received and by the notch filters reacting to this blip.

Notch filters are typically very problematic when there are discontinuities in the data - as this shows.

If anyone can look at the BLE serial code and try to find out why this happens it would be really helpful. We have tried a number of solutions (like timing the marker to be sent during the pauses between each sample from the Cyton), but is more advanced than my "pay grade"

[gerrievanzyl]

@tzvet My daughter modified the SNAP presentation software written by Christian Kothe from SCCN. https://github.com/sccn/SNAP

I will ask her to put it on github if that would help you. It is very simple and easy to use with very little python experience.

One note of caution though. It is unclear what the the delay and the jitter of the markers are. This mechanism is probably not the best for ERP studies which require millisecond precision. It his however really useful for motor imagery studies where the precise timing of the marker is not totally necessary.

• The photodiode mechanism is great for accurate timing, but it does not easily support recording the nature of the stimulus.
• The UDP makers are great to include the nature of the stimulus but not so good on the timing (for ERP studies at least)

The ultimate solution would probably be a combination of the photodiode (for the timing) and a marker value (though UDP or similar) to enable a richer set of makers with precise timing.

[tzvet]

Hello ! I am back to work on the Mark IV and EEG recording. Sorry also for my own long delay :)

@gerrievanzyl : That is really great ! Exactly what i needed ! SD card recordings are free of artifacts and i can send my "hand made" time stamp.

Thanks a lot for all the detailed explanations, it makes sense.

My own impression, as a small advanced user, is that the dongle connection and received data on the computer is far from satisfactory for any research level work, at least with my requirements of min. sampling freq. of 250 Hz. This is why the SD card files are very important.

Concerning the timing issues: Yes, i knew i first will have to check the accuracy of the time stamps. i will take a look to test how precise it is in the near future, or to do some redundant stamps for cross-checking.

To summarize: THANKS A LOT ! I think this "Issue" can be safely closed. computer generated time markers can be send with the command as described above... :)

In the meantime, last month i also setup the external photosensor time stamps. It works but has some systematic artifacts in the SD card recording about which I would need some feedback. It needs a separate issue than the one here.

[gerrievanzyl]

@tzvet Do you have tools to read the RAW SD card files into your software? I know someone who has written python scripts to read the OBCI_nnn.TXT files and to parse them into arrays while doing some error checking and clean up. Let me know if you need them.

[tzvet]

@gerrievanzyl : no, don't have. i use the standalone GUI-app to convert to csv. then i can load it in octave. But the scripts will be very welcome because i want to make a standalone octave script for directly reading the HEX files. These python examples should ease a lot my work. Thx. they could be useful also for others.

[arduinosphere]

@tzvet What photodiode hardware are you using? I'm very close to an ERP-worthy setup but need to confirm latency accuracy.

[tzvet]

@tzvet What photodiode hardware are you using? I'm very close to an ERP-worthy setup but need to confirm latency accuracy.

@arduinosphere : Sorry for this 3 months delay... :( did not look here for long.
In case this might help, you or others, for the moment i do not suggest using the "photodiode" system, unless you check that this input signal does not mess up with your other electrode signals (see #308 for my own problem). What i currently use is sending markers from command line with simple text commands, as described at the beginning.