-
Notifications
You must be signed in to change notification settings - Fork 3
/
Help.txt
85 lines (56 loc) · 5.06 KB
/
Help.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
========
SYNOPSIS
========
The SpikeGLX API accesses the SpikeGLX program via TCP/IP. On top of that, our message exchange protocol implements acknowledgement, validation and error reporting. SpikeGLX.exe and the API client can run on the same Windows machine or across a network.
The lowest latency is achieved with SpikeGLX.exe and Windows client using loopback address 127.0.0.1. Note that WSL2 allows Linux to run under Windows, but that is within a virtual machine that has a separate loopback address, so don't choose loopback for that configuration.
The API provides extensive control over a running SpikeGLX process: starting and stopping a run, setting parameters, fetching live data, calling the Par2 and SHA1 tools, and so on. Everything you need to integate SpikeGLX into your workflow.
The core technology is implemented in C++. All other languages are layered on top of the C++ core. C++ clients will have the lowest possible latency because native data types can be used throughout, which bypasses type conversion and extra data copying.
A session begins when an API client program creates a connection handle, which is then passed to all API functions. All subsequent network communication with the SpikeGLX server process is handled automatically within the DLL.
A connection handle is weakly stateful: merely keeping a handle to a network socket. A network connection cleans up after itself on the server side after 10 seconds of inactivity. By the way, if your script has paused longer than 10 seconds, and you reuse a handle that has timed out, the API will automatically reestablish a connection and the script will likely continue without problems. Note that reestablishing a connection (if needed) may take several tens of milliseconds. You can change the timeout value in the SpikeGLX Command Server Settings window.
The API should support multithreaded clients, as long as each thread or subprocess is using its own connection handle.
==========================================
C++ EXAMPLES (similar for other languages)
==========================================
void *hSglx = sglx_createHandle_std(); // create a connection handle
sglx_connect( hSglx ); // connect to SpikeGLX running on local machine
cppClient_sglx_get_keyvals g_kv; // container for getting params
sglx_getParams( g_kv, hSglx ); // optionally retrieve run params as (key, value) pairs
cppClient_sglx_set_keyvals s_kv; // container for setting params
s_kv.mstrstr["niMNChans1"] = "0:5";
s_kv.mstrstr["niDualDevMode"] = "false";
sglx_setParams( hSglx, s_kv ); // make changes
sglx_startRun( hSglx ); // start data acquisition run using last-set params
sglx_stopRun( hSglx ); // stop run
sglx_close( hSglx ); // release network resources
sglx_destroyHandle( hSglx ); // release memory resources
========
(js, ip)
========
The two integer values (js, ip) select a data stream.
js: stream type: {0=nidq, 1=obx, 2=imec-probe}.
ip: substream: {0=nidq (if js=0), 0+=which OneBox or imec probe}.
Examples (js, ip):
(0, 0) = nidq. // for nidq, ip is arbitrary but zero by convention
(1, 4) = obx4.
(2, 7) = imec7.
Note: ip has range [0..np-1], where, np is queried using GetStreamNP().
=======================
GetParams and SetParams
=======================
Manual Pre-validation
=====================
You'll find that several of the API functions to get or set run parameters complain if you haven't validated any parameters yet. Manual validation is something you need to do only once per launch of the SpikeGLX application, not once per run. To validate parameters, visit the Configure dialog in SpikeGLX and make choices for your experiment, then click either 'Run' or 'Verify|Save'. Either of these buttons apply a battery of self-consistency checks to your choices. The most recent set of Configuration settings that have passed all the sanity checks are saved in:
- 'SpikeGLX/_Configs/daq.ini'
- 'SpikeGLX/_Calibration/imec_probe_settings.ini'
- 'SpikeGLX/_Calibration/imec_onebox_settings.ini'.
The above ini files are used to initialize the Configure dialog each time you open it. Open the ini files in a text editor. You'll see several subgroups of settings. This is the best way to see the exact spelling, case, and value type of the items you can read and write via the API. Examples of accessing the subgroups:
- Group [DAQSettings]: GetParams()
- Group [DAQ_Imec_All]: GetParamsImecCommon()
- Group [SerialNumberToProbe]/SNjjj: GetParamsImecProbe()
- Group [SerialNumberToOneBox]/SNjjj: GetParamsOneBox()
Generally, follow this workflow:
(1) Launch SpikeGLX and make sure its Command Server is listening (you'll see a message to that effect in the Console/Log window).
(2) Open the Configure dialog to elect which hardware streams you want to run.
(3) Click 'Detect' and then 'Verify|Save'.
Now you are ready to run from a remote application.
(4) Typically you will need to adjust just a few settings from within your script.