Sampling mouse input at predefined frequency

Support
1

Hi Chris,

I was wondering if it is possible to sample the mouse_x and mouse_y at a predefined frequency in mworks,(1kHz similar to eye_x and eye_y).

Thanks,
Eghbal

2

Hi Eghbal,

I was wondering if it is possible to sample the mouse_x and mouse_y at a predefined frequency in mworks,(1kHz similar to eye_x and eye_y).

You can achieve this using scheduled actions. See the attached example experiment for a demonstration.

A couple important points:

  • A repeats value of -999 means “repeat forever”.
  • The variable associated with the cancel parameter must be set to 1 before the experiment stops. Otherwise, the scheduled actions will continue indefinitely, even after the experiment is closed. (This is really a bug that needs to be fixed).

Cheers,
Chris

3

Attachment: mouse_input_1kHz.xml (3.11 KB)

4

Hi Chris,
Thanks for the code ,
I am looking at the time steps of mouse updates, and it is variable through the ranging from ~950 us to ~1050 us.Is this expected?
Thanks
Eghbal

5

Hi Eghbal,

I am looking at the time steps of mouse updates, and it is variable through the ranging from ~950 us to ~1050 us.Is this expected?

Yes, that seems reasonable. The waits between repetitions are software timed, so there’s going to be some variability in their durations. (This is opposed to, say, NIDAQ analog input, which is hardware timed, with each sample triggered by an onboard clock.)

Cheers,
Chris

6

Hi Chris,
Thanks,
Is it possible to reduce the variability if I go to lower sampling rate (~200Hz). Ideally, I want to have a fixed sampling interval for the variable.

Eghbal

7

Is it possible to reduce the variability if I go to lower sampling rate (~200Hz). Ideally, I want to have a fixed sampling interval for the variable.

No, that won’t make any difference. With software-timed waits on a non-realtime operating system like OS X, getting to within a few hundred microseconds of your target is the best you’re likely to do.

Chris

8

Hi Chris,

Sorry I had a quick question as I am trying to use the predefined sampling to update the cursor shown on the screen.
I noticed that if I add a frame list for the cursor display, the update in mouse position happens at a slower sample rate ~150Hz even though the update on mouse is at 1kHz.

Thanks,
Eghbal

9

Attachment: mouse_input_1kHz_eh.xml (3.75 KB)

10

Hi Eghbal,

By “update in mouse position”, do you mean changes to the mouse_x/mouse_y values, or changes in the position of the cursor on screen? I see that your cursor_dot stimulus is using raw_mouse_x/raw_mouse_y for its position, so its position will change only when the mouse actually moves.

Also, if the Schedule Actions that sets mouse_x/mouse_y falls behind schedule by more than 5ms, you should see warnings and/or errors in the server console. Have you noticed these? I don’t see any when I run your example.

Thanks,
Chris

11

Hey Chris,
Sorry about the confusion, I wanted to get a readout of mouse_x/mouse_y values, cursor updates correctly on the screen.
I don’t see the error too, but when I look at the data, there are multiple rows(around 7 samples) with the same position values, so the effective sampling frequency is about 150Hz. I have attached an example.

Thanks,
Eghbal

12

Attachments:

13

To close this out: Eghbal was hoping to increase the rate at which the mouse position was actually updated (with new position data) to 1kHz. However, MWorks’ mouse interface relies on mouse movement events delivered by the OS, and it can’t control the rate at which those events are sent. As an alternative, we might try getting the mouse input data at a lower level (e.g. the raw USB HID events), but that would be complicated and might not yield a better data resolution. I suggested that Eghbal consider using alternative, possibly custom-designed hardware for user input.