Hello,
I am using the LSL library in C++ to read data in real time from Active_V3. The connection is established correctly, samples appear to be pulled correctly and and triggers are also read correctly. Then only problem that I seem to have is the number of channels that are sent to LSL by Biosemi. No matter what I have set in my configuration file, I always read 73 (or more if I use sensors such as GSC) channels. Please, note that when I record the data, the number of channels saved is correct. In other words, if I use a configuration file set for 32 channels (+ 8 EX), I have 40 channels saved + trigger.
I am sure that I am missing out something here in the set-up of the TCP/IP in Biosemi, but I cannot figure out what I am doing wrong.
Thank you for your help.
Alex.
Number of channels streamead by Biosemi to Lab Streaming Layer
-
Coen
- Site Admin
- Posts: 1161
- Joined: Fri Mar 26, 2004 7:00 pm
- Location: Amsterdam, Netherlands
- Contact:
Re: Number of channels streamead by Biosemi to Lab Streaming Layer
That's the way it is currently programmed: all the channels (electrodes+connected sensors+triggers) are always streamed to LSL. In your case, you have 64+8 channels installed in the AD-box and no sensors connected, so 73 channels are streamed. The idea is that you can select a subset in the LSL receiving application.
The sample rate of the streamed channels depends on the "Decimate" selection in ActiView (and is therefore greyed out when a LSL client is connected).
For best real-time behavior (minimum backlog) use a relatively small ringbuffer size (32 Mbyte is about right for 73 channels), but don't go too small or you may experience ringbuffer overflow errors in some situations (e.g. resizing or dragging windows). Furthermore, you can optimize performance by using a small "Stride" value. Stride is set in the CFG (edit with NotePad), the default value is 128 kbyte. A smaller value means that the data is read from the ringbuffer in smaller steps. This reduces the backlog but increases processor load. A bit of trial-and-error is need to find the optimal value for a specific computer.
Please upgrade to ActiView 10.4 (https://www.biosemi.com/download/Latest ... iew104.zip). Older versions have a LSL bug that could lead to the generation of multiple LSL streams (sometimes on some computers), see viewtopic.php?p=4654 .
Best regards, Coen (BioSemi)
The sample rate of the streamed channels depends on the "Decimate" selection in ActiView (and is therefore greyed out when a LSL client is connected).
For best real-time behavior (minimum backlog) use a relatively small ringbuffer size (32 Mbyte is about right for 73 channels), but don't go too small or you may experience ringbuffer overflow errors in some situations (e.g. resizing or dragging windows). Furthermore, you can optimize performance by using a small "Stride" value. Stride is set in the CFG (edit with NotePad), the default value is 128 kbyte. A smaller value means that the data is read from the ringbuffer in smaller steps. This reduces the backlog but increases processor load. A bit of trial-and-error is need to find the optimal value for a specific computer.
Please upgrade to ActiView 10.4 (https://www.biosemi.com/download/Latest ... iew104.zip). Older versions have a LSL bug that could lead to the generation of multiple LSL streams (sometimes on some computers), see viewtopic.php?p=4654 .
Best regards, Coen (BioSemi)
Re: Number of channels streamead by Biosemi to Lab Streaming Layer
Thank you for the clarification, Cohen!!!
It appears to be a bit different from what I remember from the V2 (that is why I thought I was doing something wrong), where (as far as I remember) I could stream a subset of channels.
Everything else seems to be fine, including the SF, which I had already noticed that was changing based on the decimation factor (btw, nice to have that option, instead of having to use a screw driver to change the SF
).
Thank you for the advice about ringbuffer size. I will play around to choose the optimal set-up. And thank you for sending me ActiView 10.4 (I had ActiView 10.3)
I will circle back, if I have more questions.
As always, I very much appreciate your quick response and your help.
Best,
Alex.
It appears to be a bit different from what I remember from the V2 (that is why I thought I was doing something wrong), where (as far as I remember) I could stream a subset of channels.
Everything else seems to be fine, including the SF, which I had already noticed that was changing based on the decimation factor (btw, nice to have that option, instead of having to use a screw driver to change the SF
Thank you for the advice about ringbuffer size. I will play around to choose the optimal set-up. And thank you for sending me ActiView 10.4 (I had ActiView 10.3)
I will circle back, if I have more questions.
As always, I very much appreciate your quick response and your help.
Best,
Alex.
Re: Number of channels streamead by Biosemi to Lab Streaming Layer
Hello Cohen,
Everything works fine with streaming the data in real time from Biosemi. However, I need a clarification from you.
I understand that the system that I have is set-up for 64 sensors (+ 8 EXG + AUX + trigger line) and because of that Biosemi will always send out packages of data for 72 (+ AUX, if any is connected) + trigger line channels . I had assumed that regardless of the configuration file that I use (for 32 or 64 channels), the order of the channels streamed will always be the same. For instance, AF3 will always be stored in the third cell of the vector used to pull the data(inlet.pull_sample(sample), so sample[2]) with both configurations. But I am now noticing that I might be wrong. AF3 will be in the third cell (sample[2]) with a configuration file for 64 channels, but it will be in the second cell (sample[1]) with a configuration file for 32 channels.
In other words, with a configuration file for 32 channels, Biosemi will first stream the 32 channels that are effectively connected and then will stream the 32 that are not utilized. Comparing the waveforms that I plot with my code with what I see in Biosemi, it appears to be the case. Could you please confirm this?
Thank you.
Best,
Alex.
Everything works fine with streaming the data in real time from Biosemi. However, I need a clarification from you.
I understand that the system that I have is set-up for 64 sensors (+ 8 EXG + AUX + trigger line) and because of that Biosemi will always send out packages of data for 72 (+ AUX, if any is connected) + trigger line channels . I had assumed that regardless of the configuration file that I use (for 32 or 64 channels), the order of the channels streamed will always be the same. For instance, AF3 will always be stored in the third cell of the vector used to pull the data(inlet.pull_sample(sample), so sample[2]) with both configurations. But I am now noticing that I might be wrong. AF3 will be in the third cell (sample[2]) with a configuration file for 64 channels, but it will be in the second cell (sample[1]) with a configuration file for 32 channels.
In other words, with a configuration file for 32 channels, Biosemi will first stream the 32 channels that are effectively connected and then will stream the 32 that are not utilized. Comparing the waveforms that I plot with my code with what I see in Biosemi, it appears to be the case. Could you please confirm this?
Thank you.
Best,
Alex.
-
Coen
- Site Admin
- Posts: 1161
- Joined: Fri Mar 26, 2004 7:00 pm
- Location: Amsterdam, Netherlands
- Contact:
Re: Number of channels streamead by Biosemi to Lab Streaming Layer
Confirmed. The channels are always streamed in the same order (regardless of the channel labels and regardless of connected electrode sets), in your case channel 1 to channel 72. The CFG just determines which label is assigned to which channel.
Best regards, Coen (BioSemi)
Best regards, Coen (BioSemi)
Re: Number of channels streamead by Biosemi to Lab Streaming Layer
Great!!!
Thank you and have a great week-end
Alex.
Thank you and have a great week-end
Alex.