Difference in recording time in dataset and displayed time in GUI? [resolved]
ianbhak
South Korea
I have an issue when the recording time stored in the actual data is different from the time shown in the OpenBCI_GUI. I noticed this cases several times but don't understand how it happened. Is there any way to solve the problem?!
**OpenBCI_GUI version: 4.2,
file format: BDF
BDF Files saved: 240sec
OpenBCI_GUI displayed: 400sec
Comments
Ian, please try GUI v5. v4 is no longer recommended.
William
Gotcha- thanks for the quick reply!
I still have same issues. The cpu usage of OpenBCI_GUI was near 40-50 percent during the experiment. Is this a common case?
Hi Ian,
So by "same issues", your red boxes are referring to the time differences between the BDF recording length and the total seconds shown at the bottom left of the GUI in seconds. I assume you are now using GUI v5, as suggested. Mentioning Richard @retiutut.
BOTH of your screenshots, first and this second, show considerable noise on all channels. I don't know what your electrode / headset setup is there. But the same noise present on all channels, usually indicates a bad reference lead connection. Because reference is shared with all channels.
Finally, do the recording and screen times in seconds, AGREE, when you use the default CSV text file format? So this issue is only happening with BDF recordings?
William
Could be caused by severe packet loss and maybe low-battery...
A new packet loss widget is coming to GUI 5.0.1, and was just merged. This may provide some insights.
For now, can @ianbhak please share an accompanying Console Log file from a session where this issue happens? The full console log may already be reporting packet loss... let's see please!
Take Care,
RW
Delay occurs regardless of file format.
I will try to use four AA batteries. I used two battery packs. (3.7v 500mAh) on the previous experiments.
It is too hard for me to reduce noise by using dry EEG experimental equipment.
I couldn't reduce the noise while setting up Ultracortex Mark IV on sweaty subjects. (sometimes I noticed the range from 300uV to 10,000uV. failed.)
Since it's pretty hot and humid here in Korea, so I decided to go with EEG Cap to have high quality datas.
I'm not sure exactly what sweat correlates with wet experiments, but the results of the experimental data are not bad.
Anyway, I still have the same issue on delay. The most suspicious part is the delay seen when the noise increases.
I've attached the logs and shared some video links I recorded.
First Example
2020-08-21_18-23-31 (7min 43sec)
|| INITIALIZING SYSTEM ||
Channel count set to 16
InitSettings: Saving Default Settings to file!
SessionSettings: 3 active widgets saved!
[SUCCESS]: Session started!
[DEFAULT]: Data stream started.
OpenBCI_GUI: openNewLogFile: opened BDF output file: /Users/jaewanpark/Documents/OpenBCI_GUI/Recordings/OpenBCI-BDF-2020-08-21_18-23-31.bdf
Brainflow start streaming
TopNav: Layout Dropdown Opened
Layout [2] selected.
[DEFAULT]: Layout [2] selected.
New widget [4] selected for container...
Your cursor is in Accelerometer
[DEFAULT]: Data stream stopped.
Brainflow stop streaming
OpenBCI_GUI: mouseReleased: screen has been resized...
OpenBCI_GUI: mousePressed: clicked in CP box
OpenBCI_GUI: mousePressed: clicked in CP box
[INFO]: Learn how to use this application and more at openbci.github.io/Documentation/
openBCI_GUI: haltSystem: Halting system for reconfiguration of settings...
Brainflow stop streaming
Already stopped streaming, do nothing
SessionSettings: 4 active widgets saved!
Closed the temp data file. Now opening a new file.
closeFile: Started...
closeFile: Made file
writeHeader: Writing 503 Seconds of Data to BDF
closeFile: Wrote header
writeData: started...
closeFile: Data written. Closing new BDF+ file.
closeFile: wrote data
closeFile: BDF+ temporary file deleted.
[DEFAULT]: BDF+ file has been made.
CP: Playback History Size = 2
ControlPanel: Attempting to Auto-Connect to Cyton
ControlPanel: Found Cyton Dongle on COM port: /dev/cu.usbserial-DM01MSF5
Cyton AutoConnect Button: get_channel
[DEFAULT]: Attempting to open Serial/COM port: /dev/cu.usbserial-DM01MSF5
Radios_Config: connect_to_portName: Attempting to open serial port: /dev/cu.usbserial-DM01MSF5
Radios_Config: connect_to_portName: Port is open!
Radios_Config: Success: Host and Device on Channel num
[SUCCESS]: Successfully connected to Cyton using /dev/cu.usbserial-DM01MSF5
[DEFAULT]: Attempting to Start Session...
initButtonPressed: Calling initSystem() after next draw()
OpenBCI_GUI: Start session. Calling initSystem().
Second Example
2020-08-21_18-39-12 (9min:25sec)
|| INITIALIZING SYSTEM ||
Channel count set to 16
InitSettings: Saving Default Settings to file!
SessionSettings: 3 active widgets saved!
[SUCCESS]: Session started!
[DEFAULT]: Data stream started.
OpenBCI_GUI: openNewLogFile: opened BDF output file: /Users/jaewanpark/Documents/OpenBCI_GUI/Recordings/OpenBCI-BDF-2020-08-21_18-39-12.bdf
Brainflow start streaming
New widget [5] selected for container...
Your cursor is in Accelerometer
TopNav: Layout Dropdown Opened
Layout [2] selected.
[DEFAULT]: Layout [2] selected.
New widget [4] selected for container...
Your cursor is in Accelerometer
[DEFAULT]: Data stream stopped.
Brainflow stop streaming
OpenBCI_GUI: mousePressed: clicked in CP box
OpenBCI_GUI: mousePressed: clicked in CP box
[INFO]: Learn how to use this application and more at openbci.github.io/Documentation/
openBCI_GUI: haltSystem: Halting system for reconfiguration of settings...
Brainflow stop streaming
Already stopped streaming, do nothing
SessionSettings: 4 active widgets saved!
Closed the temp data file. Now opening a new file.
closeFile: Started...
closeFile: Made file
writeHeader: Writing 595 Seconds of Data to BDF
closeFile: Wrote header
writeData: started...
closeFile: Data written. Closing new BDF+ file.
closeFile: wrote data
closeFile: BDF+ temporary file deleted.
[DEFAULT]: BDF+ file has been made.
CP: Playback History Size = 2
I sincerely appreciate your support and am hoping to find a way to solve these problems.
Thanks
Best,
Ian
Wow this is a lot of data! I still think the seconds saved vs time of recording may be different because of packet loss. I will share this information with the software team!
Software team is working on this!
Hi @ianbhak,
I have a different question to you. In your GUI, all voltages are showing almost same value , around 55 micro volt. But in my case, most of the time the values are very different. Can you please tell me how this happened? Like what was your impedance setting ? What gain you said and what was your reference? Please help.
I posted the same content in duplicate. ( I don't know how this happen. I hope the admin could manage this thread;; )
@retiutut Thanks a lot!
@Rafia I used the Ultracortex Mark IV to collect the data on the first screenshot of this post. ( which shows 55 micro volt in all channels ) I replaced the reference ear clip. Then, I was able to see the various values on all channels.
There a video which shows the delay issues, 2020-08-21_18-23-31.
I used the EEG CAP and there weren't much noise and looks totally fine. I followed all instructions guided by OpenBCI and ask to the subjects to wash their hair before having experiments to make sure everything correct.
Things I've checked:
I took turns testing two cyton boards.
exchanged battery packs from 500mA 3.7v (When checked by tester, it was 4 volts) to four AA batteries (5.5V~6V)
Used Up-to-date OpenBCI_GUI
** I am very suspicious on batteries now.
After using four AA batteries, the delay frequency is similar, but the time has significantly decreased.
( Each battery was 1.4v, so total 5.6v was supplied to the board.)
Please check the image I attached. The experiment was conducted on September 9th, 2020.
** I am still not sure how this happened. Since I recruited 20 subjects are and the experiments are still on going. I will soon be able to share with numerical results how often this delay problem occurs.
@ianbhak I would not be worried about your screen shot above. One calculation is using actual time, the other how much data was saved to file. We have already removed the number at the top of the GUI and adjusted the calculation seen in the TimeSeries. Again, no worries, this is just a minor discrepancy for what is displayed on screen, not a reflection of the quality of the recording. For information on the quality of the recording, use the new Packet Loss widget.
Here is a work-in-progress preview of TimeSeries as of today (Sept 10, 2020):
You can see there are a number of UI/UX improvements coming to the new TimeSeries widget!
Thanks @ianbhak
Thanks a lot for your support!
@retiutut
@wjcroft I recently solved this issue completely by using a extension usb cable. I read a thread you wrote and put it into practice.(FYI)
The new version of OpenBCI helped a lot to check the quality of channel connections, but I still had a serious lagging issue while live streaming.
Once I put the dongle away from the mac or pc by using 3m usb extension cord, everything worked perfectly.
Thanks.