For testing a particular piece of software, I need a piece of software
(or hardware, actually) which will make a (windows) computer think
that the letter 't' has been pressed on the keyboard every x
seconds, where x is typically 2-4. The timing need not be
absolutely precise -- it can vary within about 100ms.

I'd like some direction on how to solve this problem.

(Background: this will be used for testing psychology experiment
software which expects to receive the letter 't' from a fMRI scanner
every few seconds.)

Hi, thank you for submitting your question to Answers.Google, I hope I
can provide the information you are seeking.

Physical solution

The Tricor Model 911 is an automated keyboard/membrane input testing
device which appears to meet your needs exactly.

http://www.tricor-systems.com/products/spec/prod911.htm

These are the basic specs:
Test keyboards, keypads, membranes, etc.
Test rates can exceed 2 keys per second
Test configurations are user-programmable
Large test area
High Reliability Construction
Adjustable Actuation Force

Although this is a device designed to test and record keyboard
responses, it appears to be perfectly capable of performing your
tests, simply ignore the features you don?t need.

Software solution

You can also have a programmer produce a relatively small program
which should meet your needs by simulating keyboard input. I can?t
provide any further help on this because you haven?t given any system
details.

For information on simulating keyboard input on a Windows system see:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/userinput/keyboardinput/aboutkeyboardinput.asp

Since you are using Windows then the MSDN (Microsoft Developer
Network) information is probably exactly what you need.

Remember, under the accessibilities options you can pull up an
onscreen keyboard which fully simulates standard keyboard input.

See the keybd_event function for more information:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/userinput/keyboardinput/keyboardinputreference/keyboardinputfunctions/keybd_event.asp

?Syntax
VOID keybd_event(      

    BYTE bVk,
    BYTE bScan,
    DWORD dwFlags,
    PTR dwExtraInfo
);
Parameters
bVk
[in] Specifies a virtual-key code. The code must be a value in the
range 1 to 254. For a complete list, see Virtual-Key Codes.
bScan
This parameter is not used. 
dwFlags
[in] Specifies various aspects of function operation. This parameter
can be one or more of the following values.
KEYEVENTF_EXTENDEDKEY
If specified, the scan code was preceded by a prefix byte having the
value 0xE0 (224).
KEYEVENTF_KEYUP
If specified, the key is being released. If not specified, the key is
being depressed.
dwExtraInfo
[in] Specifies an additional value associated with the key stroke.?


Also see:

http://mail.gnome.org/archives/gtk-app-devel-list/2004-February/msg00539.html


Google search term: automatic keyboard depress
also
Google search term: freeware keyboard input simulator

Thank you again for turning to Answers.Google for help.

---

Request for Answer Clarification by placain-ga on 14 Feb 2005 22:29 PST

The hardware solution seems like a bit of overkill... and costs
thousands; do you know of anything more in the low hundreds or even
below a hundred?

As for software - do you know perhaps of any preexisting software?

If not, I will rate as is.

---

Clarification of Answer by siliconsamurai-ga on 15 Feb 2005 05:10 PST

Well, you didn't specify price and what you are asking is essentially
another question for the same price.

There is freeware and other code which might do exactly what you want,
but which one would be best or would even work depends on a lot of
technical details about your program, your hardware, and exactly which
operating system you are using.

You can probably find something which might be adapted at
www.tucows.com or www.shareware.com (in the interests of full
disclosure, I do a lot of contract work for CNET but have absolutely
no connection with the shareware site.)

In dealing with software you need to be very careful not to introduce
some variable you aren't aware of so a mechanical solution would be
best. Otherwise you could end up with test results which are actually
meaningless because of some interaction between various pieces of code
in the system.

I still don't know what sort of budget you are working with but any
decent tinkerer should be able to produce a simple cam and motor
mechanism which would cause a weighted lever to strike the particular
key.

You essentially want a simple trip hammer which is a very old tool
design. The main problem would be raising the end quickly enough that
you don't generate a repeat signal but you can adjust keyboard
response in software.

I have no way to present a design in a plain-text format but I know I
could tinker one together in an hour or so and if you are at or near a
university you should be able to hire an engineering student to do
something similar for a very reasonable price. Speed can be varied
with a simple power control you can buy at a hardware store and the
shape of the cam would determine the way the key is depressed.

I doubt anyone actually sells such a device commercially because it
would not be economical and would be too crude to perform actuall
keyboard testing. Since that isn't your goal, if I were doing this and
didn't want to build it myself I would simply contact a local school
or even post a note in an engineering department bulletin board.

On a more commercial note there are machine shops and engineering
prototype businesses almost everywhere - your main problem will be
convincing them that you really want a quite crude device - they are
likely to over engineer any design.

In the same vein, a number of small companies design and build
specialty computer devices for the disabled but I don't know of any
which does exactly this and the cost of designing and building such a
device would be quite high compared to just finding a local student to
do it.

I hope you consider this a reasonable question based on the rather
limited amount of information you provided (e.g. there are a lot of
different versions of Windows, wired and wireless keyboards, PS2
keyboards, USB keyboards, etc.) and the actual question, which was
"I'd like some direction on how to solve this problem."

Again, thank you for turning to Google.Answers.

---

Clarification of Answer by siliconsamurai-ga on 17 Feb 2005 11:42 PST

Thank you for the rating and an additional thanks for the tip, much appreciated.

A Beautiful, elegant solution....

http://store.yque.com/a197.html

right out of homer simpson but it doesn't provide the repeatability or
accuracy required for a scientific experiment.

For example, how do you adjust the key press pressure or the timing?

DOH!

Something you may not have considered -
although commercial keyboard test devices are expensive, they may be
available used.

Consider setting up a search on eBay.

There is none available at this moment but that could change at any time.

There are tons of automation software tools out there, and I don't why
the GA didn't even attempt to suggest any.  They are very commonly
used to test software reliably.  And I agree that the hardware
solution is overkill.

Software automation tools:

Macro Scheduler: www.mjtnet.com

Mercury WinRunner: www.mercury.com/us/products/quality-center/functional-testing/winrunner/

AutoIt: www.autoitscript.com/autoit3/index.php

The last one is freeware.  As is this comment.  :)

The main reason I didn't recommend any specific automation software or
software in general and strongly recommended an actual mechanical
device is simply that I have been testing software for four decades
and the possible interaction between the program being tested and the
software used to test it would probably mean that even after software
testing you would need to perform an actual physical test to confirm
the results.

Back in my days writing reviews for Byte, I have seen far too many
poorly designed tests which resulted in software being shipped when it
wasn't really ready.

Another reason is that the precise nature of the software and the
testing being done wasn't specified, therefore only a mechanical
solution could be 100% accurate.

Running macros would change timing and memory usage, among other
things and, depending on the exact nature of the test, could skew
results.

Perhaps these factors aren't important but there is no way to be
certain without actually running both a software test and a mechanical
test and comparing the results.

siliconsamurai,

Testing software for over four decades?  And you can only come up with
a device designed to test and record keyboard responses?  What
mechanical method have you used in your 40 years of testing?  If your
experience and reasoning are true, I would have expected you to
provide tons of hardware solutions specifically made for testing
software.

I do software testing for a large company.  We do no mechanical
testing.  There are tons of software automation tools out there
suggesting that this is the preferred method to test software.

James, it was an $8 question and it wasn't a test designed to test
keyboard responses, it was a test designed to test software.

BTW, 40 years ago it was an IBM 1401 and my tests have been referenced
in Cambridge Scientific Abstracts so I don't need to apologize to you.

siliconsamurai,

First off, the dollar amount of the question is not an issue here.  If
it were more, would it really change anything?  Would people have put
in many more hours to find answers?

Secondly, I used the same words you used in your answer.  You said
yourself in your answer: "Although this is a device designed to test
and record keyboard
responses..."  I did not come with it myself.  Now you're disputing
your own answer!  How strange.

Lastly, I was seeking no apology from you (and I am still not).  And
referencing the highly acclaimed 40 year old technology still doesn't
show that mechanical testing is used in modern software development.

SiliconSamurai,

Sorry, I don't mean to take sides, but as a GA shouldn't your answer
have included the possibility of the automation software that
james_l_mar mentioned? It should be up to placain to decide which to
use...and as you stated, you feel that a mechanical solution is best.
However, you cannot be 100% certain that using AutoIt (which is free)
will not produce the results that placain is seeking. You even stated
"You can also have a programmer produce a relatively small program
which should meet your needs by simulating keyboard input." Would this
not have been the perfect place to mention the programs recommened by
james_l_mar?

LOL, shockandawe-ga, that was the most humorous solution by far. 

As for the solution, go with one of the software programs stated
above. You should have no problems such as "introduce some variable
you aren't aware of...you could end up with test results which are
actually
meaningless because of some interaction between various pieces of code
in the system". Otherwise, you would use no software (including device
drivers, such as mouse drivers, display drivers, etc.) on you computer
other than Windows. And software should be very accurate, down to +/-
1ms. Most high end macro programs have timing options.

Here's a complete program to do it, written in BBC BASIC:

      INPUT "Enter period (seconds): "period
      
      REPEAT
        SYS "Sleep", period*1000
        SYS "VkKeyScan", ASC"T" TO scan%
        SYS "keybd_event", scan%, 0, 0, 0
        SYS "keybd_event", scan%, 0, 2, 0
      UNTIL FALSE

Just copy-and-paste this program into the free version of BBC BASIC
for Windows and the job is done!  This is available for download from:

http://www.rtrussell.co.uk/products/bbcwin/download.html