We also forward StopRun() functionality to the Halt() member to ensure appropriate halting of asynchronous activity:įinally, to make sure there exists an object of our ThumbWheelLogger class, we use the Extension macro at the top of its. Mirroring StartRun(), StopRun() disposes of the thumbwheel logging thread. If (OptionalParameter("LogThumbWheel") > 0)įrom the component's StartRun() member function, we instantiate the thumb wheel thread class declared above, thereby running its Execute() member in a new thread: " // record thumb wheel to state (boolean)",įrom the Preflight() member function, we check whether the thumb wheel is available: "Source:Log%20Input int LogThumbWheel= 1 0 0 1 " We will use the event interface to record the wheel's position into a state called ThumbWheelPos, writing Using the BCI2000 event interface, device state may be written into BCI2000 event states asynchronously. The ThumbWheelGetPos() function will return the wheel's current position, as an integer between zero and THUMB_WHEEL_MAX_POS. In order to connect to the thumb wheel, we call ThumbWheelInit(), receiving ThumbOK if everything is fine. Its header file, ThumbWheel.h, provides a C-style interface:Įnum Typically, it consists of a library (DLL), and an associated header file.įor the sake of this tutorial, we will assume that the device has the shape of thumb wheel, and has one continuous degree of freedom. The device API provides functions that allow to read, or manipulate, the state of the input device. Readers interested in input logging via OS events should read this tutorial first, and then proceed to the key logger component's source code for a non-polling example.Īn input logger component consists of a combination of a few existing software components, which are all provided by BCI2000 except the device API itself. Generally, relying on OS events to detect changes in device state is preferred over polling however, whether and how device state is available via OS events depends strongly on the device's driver software, and it is thus difficult to provide a valid example. In this tutorial, we will discuss how to implement input Logging for a device by polling its state in regular intervals. To support input logging with per-sample resolution, BCI2000 allows code to post so-called events asynchronously from a separate thread, which are time-stamped internally and matched against the current data block's time stamp in order to associate them with individual samples. Typically, BCI2000 data acquisition, signal processing, and application feedback code runs in a pipe synchronously, being called once per BCI2000 sample block, and cannot detect state changes in an input device more frequently than that. In BCI2000, input logging can be done with per-sample resolution.
0 Comments
Leave a Reply. |