Showing results for 
Search instead for 
Did you mean: 

Is "key down" event with microsecond time resolution possible?

@lelox993 wrote:

I need a trigger for an academic work. In the psychophysical experiment the user must press the spacebar when feels a vibration.

Do you think that the button pression is not the right choose? Do you think that it can work in the milliseconds time order?

Is the entire chain of triggering the vibration (through some digital IO I guess) to the vibration actually starting (some motor with unbalanced weight that needs to startup) to the user reacting and moving to the keyboard and pressing the button even close to a single ms? I doubt it highly. Depending on the digial IO you are using that could already be more than a ms before the vibration actually gets triggered and more time before the vibration has reved up to speed that it is even noticable. Not to forget about human reaction time which certainly is not in the microsecond range either.


You may get a bit more accuracy by using a real DIO hardware to both trigger the vibration and reading in the user action but still, I would first make an analysis about what you try to measure.

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
Message 11 of 18

Thank you for the answer!

0 Kudos
Message 12 of 18

Let's get a few thimgs clear.


The ms timer value from the event data node represents the value requested from the ms timer when the Event is generated.   Period.  It has very limited time relationships to when the Event gets processed.  Improper code could delay the processing of an Event .... indefinitely.   Run that through a few languages and grab the jist.... enqueuing an Event has no definite relationship to the time an Event case exeutes other than that the Event must have been raised before the Event Case executed.  (NO Temporal anomalies allowed Sorry Star Trek fans and Dr. Hawking)


To "Test" reflexes of a subject that is interacting on human machine interactions.... well, we don't NEED sub millisecond timing for that.  Neurons don't fire that fast (unless you have a fictional "Spidey Sense")

0 Kudos
Message 13 of 18

Also note there will be a latency on the order of 10's of milliseconds to actually detect the key being pressed due to:

Debouncing circuitry

Keyboard Scan Rate

Keyboard Polling Rate by the OS



"It’s the questions that drive us.”
0 Kudos
Message 14 of 18


Don't mean to hijack, but ...

It is possible to use the event inspector as a debugging tool; however, the millisecond resolution on it stinks!! It is impossible to log events/states correctly with the millisecond timer, when recorded with other "happenings" in your program. However, the Trace Execution module can record events with microsecond resolution. It is "accurate" enough that events are in order. It would nice to know what the Trace Execution module is doing, if so, then we can get microsecond resolution.



0 Kudos
Message 15 of 18

Not likely! At least on Windows LabVIEW does not receive any timing from the OS for key events so the timestamp it generates is from the moment it processes the event as received from the OS event queue. Sure LabVIEW could query the high resolution timer as soon as it processes the event and provide that value but that would be not much better. By the time LabVIEW dequeues the event from the OS message queue, it has been stored some time in the queue already and such a timestamp would NOT be the time when the event was generated but only when the event was processed inside LabVIEW. It's not as much delayed as the event processing in the event structure but still enough to make us resolution totally useless.


The Execution Trace Tool uses high resolution timers and does that by enabling the timestamp recording in the actual function itself. All strategic functions in LabVIEW have an enter and leave processing in which they report the actual time and other specific features such as name and some parameters to the Execution Trace engine. LabVIEW for obvious resons can't change the Windows kernel to add such processing in there. Microsoft would not be happy if it tried that. And yes enabled Execution Traceing does have some runtime influence on the application performance for obvious reasons.

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
Message 16 of 18

And that even explains why the Event Inspection vi SHOULD be locked.


Dang I am glad that I work at a company that has smart people. 

0 Kudos
Message 17 of 18

This entire discussion is so silly. So the subject senses a vibration and needs to press the spacebar. So we have the response time of the sensory receptor, the nerve signal up to the brain, the processing in the brain, the nerve signal to the finger muscle, the activation of the muscle, the press of the space bar, the scanning of the keyboard by the computer, the triggering of the event, etc. and you want microsecond resolution???


All this will give you is a false sense of accuracy. If you ever write that up into a research paper, the peer reviewers will just laugh at you. 😄


And yes, as suggested, you can place a high resolution relative seconds in the event structure and get a false precision much better than milliseconds if you subtract it from the reading when the vibration was triggered. All this needs to be in a parallel loop in order not to interfere with the rest of the dataflow, whatever else the program is doing.


What you need to do is using a real button directly connected to an FPGA input. Now you have nearly unlimited resolution.


LabVIEW Champion. It all comes together in GCentral GCentral
Message 18 of 18