With LSL, the server side (also called LSL App) is responsible for:
- communication with the device
- streaming of data including metadata (channel names, types, …)
The LSL App should populate the assiociated StreamInfo with the correct metadata in the desc XML tree. But this is not an hard requirement and is not always the case.
The channel names I provided above correspond to the channel names populated by an in-house LSL App we have for our eego amplifiers. IIRC, it corresponds to the ‘default’ order as returned by ANT’s SDK. But anyway, there is no guarantee that a different LSL App will provide the channels in the same order and/or with the same names. I am not familiar with OpenVibe, thus I would dig in their documentation for answers.
Note however that ANT’s software (among the latest versions) support LSL natively and it should be the preferred way of using LSL with their amplifiers.
Finally, for the client side, you have pylsl or mne-lsl. If you use pylsl, make sure to use the dest_obj argument in the pulling functions to avoid tanking real-time performance through painful memory allocation. If you use mne-lsl, you don’t have to bother with memory allocation and an mne.Info will be automatically parsed from the provided stream metadata (although if the server is not providing anything, then this info will basically corresponds to channels of type misc with names [str(k) for k in range(n_channels)].
If you don’t find anything in OpenVibe or in the StreamInfo.desc XML tree, then the best solution to figure out the channel order is an hardware test. Assume the order I provided above (default of the SDK), dip the EEG cap in a saline solution, and touch contacts one by one with a real-time viewer showing the data. If the channels are numbered in your client, you could try to figure out if they match the pin layout as described in the cap manual; and then match the pin with the electrode name.
Mathieu