Streaming through GUI 4.2 LSL with timestamp problem

Hi everyone! Due to my issue (954) with GUI 5.0.3, described here, I need to downgrade my system to 4.2. However, there is another issue (775) already described here which further complicates my life. Because I use two LSL streams (EEG + markers from PsychoPy) intercepted by LabRecorder and saved as *.xdf file (to be further analyzed in EEGLab), synchronization is the key. Unfortunately, timestamps sent by GUI 4.2 are wrong (GUI 5 sends them properly). And here is my question: is there any chance to implement in GUI 4.2 the improvements (regarding timestamps of course) that you have made in GUI 5? Or maybe you have any other suggestions on how to solve this? Thanks in advance for (any) response.
Marcin

Comments

  • wjcroftwjcroft Mount Shasta, CA

    It appears the Github issue has been closed / resolved on GUI 5,

    https://github.com/OpenBCI/OpenBCI_GUI/issues/954

    Which somewhat implies that you no longer need to use GUI 4.2

    William

  • Thank you for prompt reply.
    Yes, it is closed but the problem remains. I think I have documented it quite thoroughly. According to R. Waltman it is not a GUI issue. It may be the firmware or hardware issue. However, how would you explain the differences between both GUIs? I can not rely on GUI 5. The recordings are total rubish. With GUI 4 on the other hand I can get decent data, except that timestamps are incorrect.
    Marcin

  • wjcroftwjcroft Mount Shasta, CA

    Mentioning Richard @retiutut. I'm not sure what the base problem is, but using the very very old GUI 4, is likely not the best solution.

  • Well, it seems the only solution for me at the moment.

  • wjcroftwjcroft Mount Shasta, CA

    I also note that on the Github issue thread, Richard mentions that his mods have been pushed to the GUI source tree. Richard, does that imply he can build a new GUI with your improvements?

  • retiututretiutut Louisiana, USA

    Let's keep this thread open here: https://github.com/OpenBCI/OpenBCI_GUI/issues/954

    I suggest trying to use BrainFlow Python binding with same commands/setup. Channels that have been turned off should NEVER bleed signal or show anything other than true 0. I think this is a hardware/firmware issue.

  • retiututretiutut Louisiana, USA

    Also, using the GUI to route full Time Series data is not advised. I would use BrainFlow Python + LSL for Python to stream to LabRecorder.

  • wjcroftwjcroft Mount Shasta, CA

    Do we now have a recommended Python source code for reading Brainflow and writing LSL? I thought Eva mentioned this.

  • It's a bit confusing. So, the option you provide in GUI is not advised?

  • I use openBCI mainly for educational purposes. Recording EEG data for further ERP analysis while viewing actual EEG/EOG/EMG signals, demonstrating how filters work etc. is quite important for me.

  • wjcroftwjcroft Mount Shasta, CA

    I just checked with Eva, her Brainflow to LSL Python program is still under development / testing. But... performing the test that Richard recommends would be a very short program: performing the channel setting commands, then reading back the status to see if the hardware is latching the settings requested.

  • OK, I'll try to do that tomorrow. So far I used this Python script, but I can try with Brainflow as well. However, what about the recordings performed under v4.2? They are consistent. I posted just one sample but I have made tens of such recordings. Doesn't that prove that the hardware is OK?

  • retiututretiutut Louisiana, USA

    I'm coding this now.....

  • wjcroftwjcroft Mount Shasta, CA

    @marles77, hi. Regarding the old (now deprecated) Cyton Python programs that read from the Cyton serial port, and write to an LSL stream: all of these are now 'obsolete' and will be replaced by the new program Eva is finishing. However, these programs likely still work to some extent. They just are not 'supported' or maintained. The newer, more recent program is this one:

    https://github.com/openbci-archive/pyOpenBCI

    I think the next most recent is this one,

    https://github.com/openbci-archive/OpenBCI_Python

    And the one you found, may be the oldest, and least desirable,

    https://github.com/openbci-archive/OpenBCI_LSL

    Eva's new Python program will replace the LSL streaming functionality of these. And use the newer Brainflow library interface. It should also handle both Cyton and Ganglion.

  • retiututretiutut Louisiana, USA

    I've taken what Eva has done and made a testable solution for all Cyton users.

    This is now available to the general public here: https://github.com/OpenBCI/OpenBCI_GUI/blob/development/Networking-Test-Kit/LSL/brainflow_lsl.py

  • @wjcroft I had some problems with that openbci_lsl due to an old pylsl library. I'll try the code sent by Richard, which seems the best option since it apparently gives some control over Cyton channels.

  • wjcroftwjcroft Mount Shasta, CA

    Richard @retiutut, fantastic!

  • @wjcroft William, can you please, take a look at the attached log file. I guess that this message came from the dongle when I tried to set multiple channels at once (using openbci_lsl because it gives full info after each command). My questions are: 1. Is this how GUI5 sends commands to the board through RFduino (I mean in packages)? 2. Is it possible that the dongle itself if somehow broken becasue it can not deal with these packages? When the commands for each channel were sent separately, it worked properly.


    % Failure: Board RFduino buffer overflowed. Soft reset command sent to Board.$$$g channel settings to default$$cess: Channel set for 13$$$OpenBCI V3 8-16 channel
    % On Board ADS1299 Device ID: 0x3E
    % On Daisy ADS1299 Device ID: 0x3E
    % LIS3DH Device ID: 0x33
    % Firmware: v3.1.2
    $$$


  • wjcroftwjcroft Mount Shasta, CA

    Marcin, hi.

    The radio link is provided by TWO RFduino's, one on the dongle, and the other on the Cyton mainboard. Additionally the dongle has an FTDI usb interface chip. All of these devices have buffering constraints, and cannot handle large continuous streams of commands. In terms of EEG data stream, that is done with fixed size radio packets, so those do not overflow.

    The previous suggestions by others, (on this and the Github issue), are to put timing delays between sending command strings. Some commands can be combined. But others like the channel settings, apparently need more separation. I think Python is capable of various resolution delay times. One second delay would certainly work, but may be more than you need. 500 or 200 milliseconds might work, if you have a function that provides that.

    William

  • Thanks for explanation. Yes, that's exactly what I'm going to do with that brainflow code. What concerns me is that you've failed to replicate this issue. I wonder how many users will have a similar problem in future. Thanks for your time and all the suggestions.
    Marcin

  • wjcroftwjcroft Mount Shasta, CA

    I wonder how many users will have a similar problem in future.

    Your channel setting requirements are quite unique, and no other users have reported problems with GUI 5.

  • wjcroftwjcroft Mount Shasta, CA

    I added a final comment on the Github issue, mentioning a possible workaround for marginal ADS1299 hardware, such as Marcin owns.

    https://github.com/OpenBCI/OpenBCI_GUI/issues/954

  • Thanks, that was a good summary. I added another comment there referring to what you had written.

  • wjcroftwjcroft Mount Shasta, CA

    Marcin, when did you purchase your Cyton? Through the OpenBCI Shop?

    If this is a recent purchase (within the last month or so), your other option is to request a replacement mainboard. (But continue to read below.) As you definitely have a 'sensitive' / marginal ADS1299 chip. Which is prone to being confused by rapid channel setting commands.

    On the other hand, my hunch is that there are likely other such ADS1299 chips like yours out in the field. Perhaps 10 or 20% (?) of the total Cyton boards in the field. So perhaps the best approach for both OpenBCI and you, is the simple mod suggested on the Github issue. It could be expensive if OpenBCI has to replace boards when more of these 'sensitive' marginal ADS1299 surface. We have not seen this reported in the past, because few customers are doing as much channel setting as you with GUI 5.

    Mentioning Richard @retiutut, Shirley @Shirley.

    William

  • That's right, I purchased my Cyton+Daisy together with eeg cap through the Openbci shop exactly on 13 July 2020. The order number was 8982. I checked if it worked after shipment, but I actually started to use it only ~2 months ago. These settings are important for me, because, as I have already mentioned, I teach students. So, we use EEG in different configurations.

  • marles77marles77 Poland
    edited March 20

    I've prepared a simple modification of that Brainflow code and I'm going to test it after the weekend. The adventage of this situation is that I learned a lot:) I reviewed all the firmware and the Brainflow package, and eventually know how this whole stuff works together. What I think would be useful in Brainflow is some kind of a listener to catch (asynchroniously?) prints from the board and radio. I suppose that this "buffer overflowed" message was sent each time I tried to change channels settings. That could probably help identify potential 'sensitive' boards.

  • wjcroftwjcroft Mount Shasta, CA

    I suppose that this "buffer overflowed" message was sent each time I tried to change channels settings. That could probably help identify potential 'sensitive' boards.

    Umm, there are two separate issues: the sensitive ADS1299 chips, and dongle buffer overloads, caused by sending too many commands at once. Adding a delay between channel setting commands should solve both. Not clear if Brainflow checks for command return values are worth the effort. Although I think any program sending Brainflow command sequences could check for results if really desired. Normally command sequences should never fail, if they are valid commands.

  • As you have already pointed out:

    The radio link is provided by TWO RFduino's, one on the dongle, and the other on the Cyton mainboard. Additionally the dongle has an FTDI usb interface chip. All of these devices have buffering constraints, and cannot handle large continuous streams of commands. In terms of EEG data stream, that is done with fixed size radio packets, so those do not overflow.

    I may be wrong, but as I understand, both Radios (dongle radio as Host and board radio as Device) use the same firmware and the difference is just their modes. However, some functions are specific either for Host or Device. Looking at these cpp libraries (assuming that these are PROD versions) it seems that the chain of events (in a discussed i.e. unfavorable scenario) is as follows:
    1. Host sends multiple strings to Device
    2. Device's buffer gets overflowed
    3. Device sends private message '0x04' (defined in OpenBCI_Radios_Definitions.h as ORPM_DEVICE_SERIAL_OVERFLOW) to Host
    4. Host prints out "Failure: Board RFduino buffer overflowed. Soft reset command sent to Board.$$$" - line 1840 in OpenBCI_Radios.cpp but the soft reset command (i.e. default settings) is not executed (this line is commeted out, and there is no trace of reset in GUI5 log files)
    5. Cyton board goes rogue and behaves in an unpredictable way (as documented in issue 954)
    Does this sound likely? Am I confusing something? From my point of view this is still the same issue and it all can be boiled down to the Device's buffer problem. The question remains, why this happens in some boards such as mine.

  • wjcroftwjcroft Mount Shasta, CA

    Issue 954 is a completely different issue, no connection to the dongle overflow situation. Issue 954 is due to YOUR marginal ADS1299 chip.

    Solution for both issues is to just put some delay after sending a command string. I stated this previously.

    The question remains, why this [marginal ADS1299] happens in some boards such as mine.

    TI likely does some testing at the factory, but does not hit all edge cases like this. It's not unusual that pushing the boundaries of what is considered 'normal' operation, may uncover glitches.

  • So basically, adding a short (0.1 sec) delay fixed the problem as you had said. Channels were set properly, signal was sent over LSL with no glitches, extra noise etc. However, I have one last question. I use Cyton with Daisy attached. Even if I send the command 'c' (with 0.5 sec delay) and receive the confirmation that Daisy is removed, the sampling rate is still only 125Hz. I send this particular config_board() before LSL initialization (and after board.prepare_session()), so srate should already be updated. Using 0 as board-id in params doesn't work either (noise at all channels). Is there any other way I can set a sample rate of 250Hz for the remaining 8 channels? It works in GUI, so I suppose it is possible.
    Marcin

Sign In or Register to comment.