External Sync and Aux Channels
Hello,
Back in 2017 or so, there was discussion on this thread regarding setting up an optical sensor to check the synchronization of software presenting stimuli to the EEG recording. I've got the TSL257 (though it's out of production, for those interested) and when I plug it into one of the digital ports (D11 - for some reason D12 and D13 seem to be pegged at 1 in my setup) I can get that pin to show as switching between 1 and 0 using the GUI. I based the pin choice on the puppies and kittens experiment here, except for the need to use D11 instead of D12 (pegged).
The problem is that I'm sending marker signals from PsychoPy that I want to compare with the readings from the optical sensor. The GUI will show the sensor, but won't integrate markers from PsychoPy. LabStreamingLayer will take the markers from PsychoPy, but I can't (so far) get it to recognize a digital pin. It does, however, accept the Aux channels.
In another thread from today, William suggested I could use the Aux channels for markers. I suspect that would work for my case, because then I could send all of PsychoPy's markers, the optical sensor's marker/voltage, and the EEG channels through LabStreamingLayer.
How do I get the optical sensory to send data to the AUX?
Many Thanks
Jamie
Comments
The Puppies / Kittens schematic is already sending the button / optosensor info, via the Aux channels. You can change which pins you use:
https://docs.openbci.com/Cyton/CytonSDK/#board-mode
Oh - okay. I didn't realize that D11 was sent to the AUX channels in digital mode. If I recall correctly, recent firmware (I'll have to check the version, but I'm pretty sure mine is current enough, as it's from 2020 or so) automatically sets the analog/digital mode depending on how things are wired into the board. I won't be able to check this stuff until Tuesday, but I'll do that first thing.
As always, thank you, William, for your phenomenal support!
Jamie
Mentioning @retiutut. Actually now I see that the P&K page,
https://docs.openbci.com/Examples/VideoExperiment/
Is MISSING the point to tell the user they must use the Digital Read widget before starting the run, to turn on that board mode, described here,
https://docs.openbci.com/Cyton/CytonSDK/#board-mode
re: "...If I recall correctly, recent firmware (I'll have to check the version, but I'm pretty sure mine is current enough, as it's from 2020 or so) automatically sets the analog/digital mode depending on how things are wired into the board..."
Actually, no. No auto-mode detection is done based on external wiring. However if you have the Cyton serial port open, you can send the SDK command that sets digital (or analog) board mode: "/3" for digital and "/2" for analog.
Hello again,
Thanks for your clarifications (and the mention in the other thread).
Okay - the plan is to try sending the D11 digital stream to the aux channels in the morning. As I understand it, I can do that by sending "/3" in the console window in which I'm running the openbci_lsl program (at the --> prompt, and with the board in a non-streaming state).
A question related to that is this: Will the board revert to its default state once things are powered down? Or do I need to manually revert that setting? The hidden-agenda question in that one is: If I foul stuff up while trying to send this, can I simply do the oft-recommended turn-it-off-then-turn-it-on solution? For example, if I forgot the /, then I think sending "3" will shut off Channel 3. I'm sure there's other stupid stuff I could do (but hopefully won't). Are there any things that WON'T be fixed by simply cycling the power?
Thanks
Jamie
Welp - it appears that the openbci_lsl can't send the /3 to the board. It responds to other commands (? and V, for example), but doesn't recognize /3 // or any variant thereof. The board firmware version is 3.something.something so I assume the issue is with the LSL. Is it possible to send /3 through some other mechanism either while lsl is connected or prior to having lsl connected and have the setting stick until I can connect the LSL? I tried looking through the GUI, but didn't see anything promising.
Jamie
Jamie, hi.
re: "/3" board mode command. Yes the board reverts to the default accelerometer Aux values upon power off. Power off/on resets everything to defaults. This is why I mentioned you on the other thread regarding re-flashing the firmware to default enable / startup in "/3" mode.
re: your LSL program
Some of these LSL related Python apps have been 'deprecated' by moving them over to the archives area. But they are probably easily tweaked / modified to send such commands.
https://github.com/orgs/openbci-archive/repositories?type=all
There is an LSL acquisition server for OpenBCI, built into the OpenViBE release. That might be another you could try. But I think it is written in C++, so less easily modifiable.
http://openvibe.inria.fr/acquisition-server/
https://www.google.com/search?as_q=openvibe+acquisition+server&as_sitesearch=openbci.com
William
oops. The OpenViBE AS for OpenBCI is ONLY OpenViBE, no LSL. I thought there was another Cyton LSL app besides OpenBCI_LSL, but I'm blanking on it at the moment. OpenViBE 'can' stream out LSL, FYI.
Hi William,
Thanks for the archive lead. I think I might be able to modify one of the lib files to achieve what I need. I'll update when/if I've made progress. Worst case scenario, I will have one of our IT-like people help me do the firmware modification you indicated as a temporary thing. Totally out of my range of experience (I've done software stuff for years, but nothing with an arduino), so it'll be a last resort.
regards
Jamie
Okay - so the code fix was relatively painless. The LSL software treats any command line entry starting with / as being a command to the LSL. So I just added
if ('M' == s[0]):
s = s[1:]
at line 285 of streamerlsl.py and used a code of "M/3". I chose M because it's not used according to the SDK description, and it's meant to stand for Mode.
However, upon starting the stream, I got many
Unexpected END_BYTE found <193> instead of <192>
errors before the stream halted. Frustrating.
I'm considering trying the BrainFlow library instead (I think I can just write the elements of that into my Python stimulus program?), but I'm not sure if that supports setting the board mode (I did some looking on the BrainFlow readthedocs site, but didn't find anything obvious). If I set the board mode using the LSL, would it stay in that mode if I stopped the LSL and picked up the board with the BrainFlow library? Or is there some simpler way. I looked for solutions to the END_BYTE problem on this forum, but mostly it seems that people get redirected to BrainFlow.
Thanks again for your help. Sorry to be a constant pain, but this is somewhat important to me and I can't seem to get past these roadblocks.
Jamie
re: END_BYTE warnings
I think these are because this repo was never updated for firmware changes that introduced different end bytes.
https://docs.openbci.com/Cyton/CytonDataFormat/#binary-format
Looks like an easy fix.
re: Brainflow vs LSL
Brainflow does have much better support on their Slack. Sign up on https://brainflow.org/
Yes Brainflow can send SDK command byte strings:
https://www.google.com/search?as_q=brainflow+config_board&as_sitesearch=openbci.com
re: does board mode 'stick'?
I think as long as you do not power cycle, the board mode maintains.
Best regards, William
James, I added an issue on the repo, in case anyone ever addresses this deficiency. Pointed back to your comment above.
https://github.com/openbci-archive/OpenBCI_LSL/issues/18