How to control a serial push button box

[Fuh]

Dear Sir or Madame,

I am relatively new in LabView and National Instruments, but am trying to capture the reaction time of a human participant.

A simple example of the tasks that I hope to accomplish is described as follows. I think I will first write a Labview program to present two pure tones to the listener (one at a time) , with one tone having a higher pitch than the other. That is, the pure tone acoustic sounds will be delivered to the listener's ears via a regular computer headphone set. After listening to the two tones, the participant's job is to discriminate which tone has a higher pitch and press a button accordingly. My question is related with the push-buttons... It is my understanding that the push-buttons can be:

          (1) software push-buttons that are displayed on a computer touch screen monitor,

          (2) physical push-buttons on a separate response box that is connected to a serial port on a PC, or

          (3) physical push-buttons on a separate response box that is connected to a NI hardware (an I/O control card, maybe !!??)

For some reason, it is my understanding that using the internal clock of a PC is not reliable, because of the multi-task nature of the Windows system. That is, either using a touch screen monitor or a serial port on a PC is not a good idea; because if I do that, I am using the internal clock of my computer, which can be interrupted by other programs running at the same time on the Windows system. That is, the multi-task nature of Windows system will basically make the reaction time inaccurate and unpredictable. It is also my understanding that, if I want a good precision of the reaction time (e.g., down to about maybe 1 or 5 msec!!??), I would need to use a separate clock that is solely designated for this task. Again, I am stretching out and trying to accomplish a task that is new to me, and I am not sure if I am correct... 

I currently have several NI I/O control cards in my lab. They are USB-6216 BNC, PCI-6221 (with a BNC-2090A connector block), DAQ wireless WLS-9215 BNC, and DAQ 6062E. For the purpose of this new task, I am more thinking about using the USB-6216 BNC or PCI-6221, if at all applicable. Does NI sell any push-button boxes and related devices? So I can use the clock inside of an I/O control card? Or do I need to purchase a new set of devices?

If anyone could advise me on what configuraitons or options would work the best for me to accomplish this task, I would greatly appreciate it.

Sincerely,

Fuh

[C-Dav]

Fuh,

You are correct that LabVIEW on a Windows OS is not fully deterministic, and software timing accuracy is going to be relative to system timing.  That said, the sound generation portion of your code will most likely be software timed in some fashion, unless you create the sound signal in hardware (which wouldn't be the simplest task).  Entirely in software, you would be able to determine reaction time to within a handful of milliseconds, and the less you have running in the background during operation the less you would have to worry about the non-determinism of windows.  Integrating hardware would, in my opinion, be quite a bit more tricky, and you would still be stuck with Windows' software timing on the sound-generation side of the test.  The two methods I could suggest to accomplish your goal would be...

1. Software:

Read a sound file in software (or just generate a tone with native LabVIEW functions) and lay it over the headphones.  When the sound file is played, also use a tick counter function to grab a "start" time.  You could then have a button (touch screen, mouse click, or keyboard if you used an event structure to recognize key presses), and when the state of the button changed you could use another tick counter, subtract the difference from the first, and log that as the time-to-react.

2. Software/Hardware:

Again, read a sound file in software (or just generate a tone).  When the tone is generated, you could begin a counter task that uses one of the DAQ cards you have and beings to generate a digital pulse train (continuous series of high/low/high/low voltages).  Once the user pressed a physical button (which would have to send a pulse, mostly likely 5V), you would stop the pulse train generation.  You can then see how many pulses were generated until the user pressed the button, multiply that by the frequency of pulses, and determine how long it took for the user to respond.  This method may prevent some time delay on the response side and improve the overall accuracy, but would be much more involved in my opinion.

I put together a quick example for the software-only method to demonstrate.

[johnsold]

Fuh,

As you have questioned, the timing accuracy and latency working through the OS may be a problem.

One way around this is to record both the stimulus and the response with the DAQ device (such as the 6221).  

Tap into the signal going to the headphones and connect it to an AI channel (two channels if you are using stereo). Connect your hardware pushbuttons to other AI channels. Start the analog data acquisition before you trigger the sound generation. Read the acquisition after the maximum time you allow for a trial. Or read continuously if appropriate. Then you can determine the timing of the stimulus and the response with the accuracy and resolution of the 6221 analog sampling clock.  I did not look it up, but the clock is probably in the 100 ppm class. Your sampling rate needs to meet the Nyquist criterion for the highest audio frequency you are using and the minimum timing resolution you want. The PCI-6221 has a maximum sampling rate of 250 kS/s. If you have two audio channels at up to 20 kHz and two pushbutton channels, you could sample at 50 kHz to meet the Nyquist criterion and give you 20 us timing resolution.

This method is completely independent of any OS latencies and only requires a tap into the headphone circuit so it adds very little cost.

Lynn

[Fuh]

Dear Chris,

Thank you so much for your reply and and insightful suggestions. I greatly appreicate it. 

I have also tried to open the reaction time.vi that you wrote for me, but was unable to, because my LabVIEW is the 2009 version. Dear Chris, can you save the reaction time.vi as a 2009 version and post it on the discussion forum, so I can read it from the computer in my lab?  

I apologize for the hassle and any inconvenience I have created.

Sincerely, Sincerely,

Fuh 

[Fuh]

Dear Lynn,

This method is ingenious - recording both the stimulus signals and pushbutton responses at the same time. Just a couple of technical issues that I need further clarification, explanation, and help.

1. Tap into the signal going to the headphones and connect it to an AI channel: I think I can I simply use a T-connector to "Y" out the stimulus signal to an AI channel. Right?

2. Connect your hardware pushbuttons to other AI channels: 

• I am not an engineering person, and I don't know much about the circuit components inside a pushbutton. So, don't laugh at me...
• I assume that a simple physical pushbutton can be as simple as a switch. Right? That is, if the button is not pressed, it is an open circuit. However, when the button is pressed, it completes the circuit. And when the circuit is completed, the voltage reading from its corresponding AI channel will change dramatically.
• Obviously, the pushbutton can be designed the other way around. That is, when the button is not pressed, it is a complete circuit. When the button is pressed, the circuit gets interrupted.
• In either case, when the pushbutton is pressed, the voltage readings from the corresponding AI channels would change dramatically (either drop or increase significantly). And we can use that sudden change of voltage to calcuate reaction time.
• Also, how do I connect a hardware pushbutton to an AI channel? I assume a hardware pushbutton is going to function like a simple switch, which completes or interrrupts a circuit when the pushbutton is pressed. On this note, do I need to add a resistor in series with the pushbutton switch? Otherwise, when the circuit is completed, wouldn't it create a short circuit?

Again, don't laugh at me. I don't have enough engineering background, but I do want to solve this issue and conduct some reaction-time experiments for my research.

Thank you so much!

Sincerely,

Fuh

[johnsold]

Fuh,

1. Right.

2. Right. The pushbutton operates a switch. Right again, the switch can be open or closed in the unpressed position.  These are called Normally Open or Normally Closed.  There are more complex combinations available but it is not necessary to confuse the issue by going into all the messy details.

Typically the way to connect the buttons to an AI channel is to connect one terminal of the switch to ground and the other terminal to both the AI channel input terminal and to a resistor.  The other end of the resistor connects to a voltage source. A typical resistor value might be 1000 ohms, but it is not critical. Values much lower than that will start to draw a lot of current and low enough values act like a short circuit. Again you are right that without a resistor the switch would short out the voltage source.  Many DAQ devices have a +5 V output available and that is suitable and convenient.  Assuming a normally open switch the voltage at the AI will be 5 V when the button is NOT pressed and 0 V when it is pressed.  Switches can mechanically "bounce" so the contact may open and close several times over a period of a few milliseconds when the button is pressed or released.  Since you are looking at response timing, you can just look for the first transition after the stimulus and ignore the bounces.

Lynn

[C-Dav]

Fuh,

Not a problem, here it is.

Regards,

[Fuh]

Dear Chris,

Thank you so much for writing the program for me and saving it as the 2009 version. I greatly apreciate it. I just tried the software on my computer. It worked out great!!!

Thanks a lot!

Sincerely,

Fuh

[Fuh]

Dear Lynn,

I have been pondering about this wonderful idea during the past few days. I have also tried to look up in my DAQ manuals for my PCI 6221 and USB-6216 BNC - trying to figure out what I shall do to deliver a constant 5 V output from a DAQ card. Again, I don't have much engineering background. So, this question maybe very naive and stupid... When you mentioned that "many DAQ devices have a +5 V output available and that is suitable and convenient," did you mean the AO channels? Digital I/O channels? PFI channels? or something else? 

I have a little bit of experience working with AO channels, and I think I know how to deliver a constant 5 V output from an AO channel. However, I need the two AO channels (if at all possible) to deliver signals for acoustic stimulation to the human participant. So, in my case, the two AO channels are preferrably not to be used as a voltage source for the physical pushbuttons. However, if AO channels are the easiest way to produce a constant 5V output, it is totally fine. Please let me know. I will just have to work around my experimental protocol, spare out one AO channel, and use it as a voltage source for the response pushbuttons. On the other hand, if using the Digital I/O channels, PFI channels, or others are not super difficult, please  teach me on how to work with those channels. I am very eager to learn and adopt this technology in my research. 

Dear Lynn, if you could give me some further advice or a simple example LabVIEW code that would produce a steady 5 V output from a DAQ device, I would greatly appreciate it.

Sincerely, Sincerely,

Fuh

[C-Dav]

Fuh,

With regards to the +5V, there should be a pin dedicated to providing this voltage.  See pins 8 &14 in the pinout diagram below:

Hope that clarifies for you.

Regards,

[Fuh · Accepted solution]

That is wonderful! Thank you so much, Chris! Thank you so muh, Lynn!

NI Discussion Forum ROCKS!!!!

Fuh