Delayed event code

Hello,

I want to detect the timing when the signal from a sensor (digital input assigned to Button#1) stops, using my script written with Timing Script v2. When I split the sensor output into the NI board and the recording system and record the sensor-off timing from MonkeyLogic (I send an event code from MonkeyLogic to the recording system) and directly from the sensor, there is about 50 msec of delay between the termination of signal to the recording system and the reception of the event code from MonkeyLogic.

When I tested the same sensor-off timing gap using a script written with Timing Script v1, the gap between sensor-off timings from the two routes (via MonkeyLogic and direct input) was less than 1 msec. Therefore, I guess there is a problem with my way of detecting the sensor-off timing with the Timing Script v2.
Below is part of my script that monitors the sensor state and sends an error code if the “LooseHold” adapter does not return success in Scene1 and 3. The sensor-off timing is detected by combining “NotAdapter” and “WaitThenHold” adapters in Scene4. The break time used in Scene1 and 3 is 100 msec.

The time stamps for the successful termination of hk_off4 in Scene4 have about 50 msec delay relative to the direct sensor inputs, whereas the time stamps for the unsuccessful termination of Scene1 and 3 have about 150 msec delay relative to the direct sensor output (additional 100 msec may due to the break time).
Can anyone find the issue with my script?

Thank you!


%% Scene1: detect the home-key onset then check the home-key hold during the pre-instruction-delay
hk_cap1 = SingleButton(button_);
hk_cap1.Button = 1;
hk_hold1 = LooseHold(hk_cap1);
hk_hold1.HoldTime = pre_inst_delay;
hk_hold1.BreakTime = break_time;
chain1 = Sequential(hk_cap1);
chain1.add(hk_hold1);
chain1.EventMarker = [110,120];
scene1 = create_scene(chain1,tlocs);

%% Scene3: check the home-key hold during the post-instruction-delay
hk_cap3 = SingleButton(button_);
hk_cap3.Button = 1;
hk_hold3 = LooseHold(hk_cap3);
hk_hold3.HoldTime = pst_inst_delay;
hk_hold3.BreakTime = break_time;
chain3 = Concurrent(hk_hold3);
if robber_flag
tc3 = TimeCounter(robber);
tc3.Duration = pst_inst_delay;
chain3.add(tc3);
elseif distractor_flag
tc3 = TimeCounter(distractor);
tc3.Duration = pst_inst_delay;
chain3.add(tc3);
end
scene3 = create_scene(chain3,tlocs);

%% Scene4: check the mvt onset and target capture
hk_cap4 = SingleButton(button_);
hk_cap4.Button = 1;
nhk_cap4 = NotAdapter(hk_cap4);
hk_off4 = WaitThenHold(nhk_cap4);
hk_off4.WaitTime = max_reaction_time;
hk_off4.HoldTime = 0;

I already explained why it cannot be done with Timing Script v2 in the manual and my paper. Please take a look at them.
https://monkeylogic.nimh.nih.gov/docs_CreatingTask.html#RuntimeVersion2_Background
https://www.ncbi.nlm.nih.gov/pubmed/31071345

If you make your own adapter that monitors the signal change and sends the eventcode right away, the delay can be reduced but will still be 10 to 20 ms.

IMHO, there is no point of stamping this eventcode. Calculating the sensor-off time afterward from the recorded signal is easier and more accurate.

Hi Jaewon,

Thank you for checking my question and responding.
I've read those articles, but I might not have understood them correctly.

I thought the maximum delay between the real sensor output and the output through the MonkeyLogic task (with Timing Script v2) is one frame length of the screen (ex. 16.6 msec for a monitor with 60 Hz of refresh rate) if the computer is not too slow. Is this correct?

If yes, 60 msec of delay in the MonkeyLogic output in my system is about 3-4 frames of delay (I'm using a monitor with 60 Hz refresh rate), which is not consistent with the maximum delay in Timing Script v2.
When I plot the distribution of the delays, I can see a cluster centered around 60 msec with about 16 msec width.
I thought this 16 msec width depends on the refresh rate. But I don't know what makes an extra 43 msec of delay.
Is this delay due to my adapter chain that contains multiple adapters?

Regards,
momoyuki

To achieve the minimum delay between the sensor reading and the ML output in Timing Script v2, the analysis of the sensor data and the generation of the output must occur in the same scene, like the OnOffMarker example here.
https://monkeylogic.nimh.nih.gov/docs_RuntimeFunctions.html#OnOffMarker

If you connect the sensor to an analog channel (specifically, if TouchMode is not enabled), SingleButton may add a delay of up to 2 frames. See the Remarks of SingleButton.
https://monkeylogic.nimh.nih.gov/docs_RuntimeFunctions.html#SingleButton

You did not show how the eventcode was stamped when the sensor off was detected in Scene4. Depending on how you send the eventcode, a delay of 1 frame can be added.

What I think happened in your test is like this. The sensor went off in Frame #1. SingleButton waited for the signal to be stabilized until the end of Frame #2. WaitThenHold flagged the scene termination at the beginning of Frame #3. The scene stopped at the end of Frame #3. The eventcode was sent right away (e.g., by eventmarker()) and stamped at the beginning of Frame #4. Or it could be queued for the next frame (e.g., by idle()) and stamped at the beginning of Frame #5.

To get the best result, it is necessary to make your own adapter tailored for your purpose, as I mentioned above. With the existing adapters, the example in the OnOffMarker manual is closest to what you want. In the latest NIMH ML, the TouchMode of SingleButton is automatically enabled for digital input. Otherwise, you may need to set it manually. With the TouchMode enabled, OnOffMarker sends out the code at the beginning of Frame #2 and therefore the delay becomes less than 1 frame.

The number of adapters in the scene is not relevant to this.

Hi Jaewon,

Thank you for the helpful suggestions!

I tested the delay of event code using the "OnOffMarker" adapter and its example script before making a new adapter.
The delays from the sensor-on signal (direct input from the sensor) to the button#1-on event code (indirect input via MonkeyLogic) in our recording system are within one frame (left panel in the attached figure). But the delays from the sensor-off signal to the button#1-off event code are two frames (right panel in the attached figure).
Do you have any idea to shorten the delay for the sensor-off events?

Is your NIMH ML up to date? Please update it.