Response devices
David McFarlane
mcfarla9 at msu.edu
Mon Dec 14 20:52:14 UTC 2009
Oops, I meant to preface my little report with an explanation of how
to figure this stuff out for yourself (because, you know, you should
never take my word for any of this). I just put the SRBox through an
old terminal emulator that will show incoming characters as
hexadecimal. I used an old DOS shareware program called Terminal
Plus!, apparently still available for download (find it through Google).
-- David McFarlane, Professional Faultfinder
>Carlos,
>
>At 12/11/2009 04:53 PM Friday, you wrote:
> >David,
> >
> >Hi there, I am new to the group and see that you make your own boxes
> >to communicate with E-PRime.
>
>Just on that point, we have built very simple passive switch boxes
>that we connect either to a digital I/O port (i.e., the parallel
>printer port), or to the expansion connector on the SRBox. Although
>I know enough about the SRBox that in principle I could build one
>from scratch (no exotic circuitry in there), I have not yet gone to
>the trouble of doing anything like that.
>
>
> >We are currently in the process of converting some old IFIS response
> >pads to work directly with E-Prime, but are having difficulty
> >getting E-Prime to detect every button press and difficulty figuring
> >out what type of characters E-Prime is expecting. Since the SRBox
> >Device is usually set to emulate the keyboard I thought we could
> >have the bread board we currently have the pads connected to send
> >out the hex code associated with the main number keys on the
> >keyboard. This didn't work very well and sometimes buttons that were
> >wired differently elicited the same output.
> >
> >So my question is if you know what type of input E-Prime is
> >expecting from a device connected to the serial port?
>
>OK, now that I have considered your question... Again, to be
>accurate I have never used the Serial Device in E-Prime, so for that
>I would look at the SerialDevice topic in the online E-Basic Help
>(and take that with a huge grain of salt, I find a mistake
>practically every time I look in the E-Basic Help). But as far as I
>can tell that just reads raw bytes from any serial device, it is up
>to your particular device to determine what those bits mean and then
>up to your E-Prime script to decode them.
>
>But FWIW I will say a bit about what I know of the SRBox, which also
>uses the serial port (which is not the same as being an E-Prime
>Serial Device). OK, here is an excerpt from notes I made back in Aug
>2001, and never finished (but is much more detail than PST will ever
>give you)...
>
>-----------------------
>The SRBox communicates with the computer though a standard RS-232C
>serial interface (DCE?; no handshaking). The SRBox ignores all
>handshaking. Communication parameters are 9600 or 19200 bps (jumper
>selectable, default is 9600), 8 data bits, no parity, 1 stop
>bit. (At power on, sends &H7F)
>
>Using these parameters, the SRBox sends a steady stream of key data
>at a pace of 800 or 1600 Bps (jumper selectable, default is
>800). In total, three byte/communication rates are possible: 800
>Bps at 9600 bps (default), 800 Bps at 19200 bps, and 1600 Bps at
>19200 bps (1600 Bps is incomptible with 9600 bps communication
>rate). Note that at 800 Bps a byte is sent every 1.25 msec, while at
>1600 Bps a byte is sent every 0.625 msec.
>
>Each byte sent from the SRBox encodes the state of one bank of eight
>devices (see control inputs below). Bank one consists of the five
>built-in keys, the voice key, the refresh detector, and/or eight
>external devices through the expansion connector. Bank two consists
>of an additional eight external devices through the expansion
>connector, plus the voice key and the refresh detector. Data bytes
>are encoded according to the following table [this table does not
>show up well in plain text, but here it is anyway]:
>
>Bit # Bank 1 Function Bank 2 Function
>0 On-board Key 1, or external Key 1 (expansion connector pin
>#24) External Key 9 (pin #33)
>1 On-board Key 2, or external Key 2 (pin #25) External Key
>10 (A) (pin #34)
>2 On-board Key 3, or external Key 3 (pin #26) External Key
>11 (B) (pin #35)
>3 On-board Key 4, or external Key 4 (pin #27) External Key
>12 (C) (pin #36)
>4 On-board Key 5, or external Key 5 (pin #28) External Key
>13 (D) (pin #37)
>5 Voice Key, or external Key 6 (pin #29) [?Voice Key, or?]
>External Key 14 (E) (pin #38)
>6 Refresh Detector, or external Key 7 (pin #30) Refresh
>Detector, or External Key 15 (F) (pin #39)
>7 External Key 8 (pin #31) External Key 16 (G) (pin #40)
>
>The SRBox accepts input to control the state of built-in lamps and
>external devices, and to control its own operation. (Same
>communcation parameters as for output.) The lower five bits of an
>input byte control one of two banks of devices (see control bits
>below). The upper five bits control the operation of the
>SRBox. When sending a control byte to the SRBox, it is necessary to
>specify all three SRBox control bits. Note that there is no way to
>read these control bits from the SRBox. Thus, if you wish to change
>only one or two control bits, the program must itself store the prior
>state of all the control bits so that it can add back in the ones
>that are to remain unchanged.
>
>For both banks, bits 0-4 control lamps or devices 1-5, where 0
>deactivates the lamp or device, and 1 activates it. The control bits
>operate as follows [again, this table comes out better in my original
>Word document]:
>
>Bit # Bank 1 Function Bank 2 Function
>0 On-board Lamp 1, or external Lamp 1 (expansion connector pins
>#7 & 6) External Lamp 6 (9) (pins #9 & 8)
>1 On-board Lamp 2, or external Lamp 2 (pins #5 &
>4) External Lamp 7 (A) (pins #11 & 10)
>2 On-board Lamp 3, or external Lamp 3 (pins #3 &
>2) External Lamp 8 (B) (pins #13 & 12)
>3 On-board Lamp 4, or external Lamp 4 (pins #1 &
>21) External Lamp 9 (C) (pins #15 & 14)
>4 On-board Lamp 5, or external Lamp 5 (pins #22 &
>23) External Lamp 10 (D) (pins #17 & 16)
>5 Key Bank Select: 0 = bank 2, 1 = bank 1
>6 Lamp Bank Select: 0 = voice key threshold & bank 2, 1 = bank 1
>7 Transmit Data: 0 = Do not send data, 1 = Send data
>
>Examples [another table that will not come out well in text]:
>Control Code
>Binary Hex Dec Result
>0000 0001 01 1 Select key bank 2, stop data, set
>voice key threshold to 1, turn on lamp 6 (bank 2), turn off lamps 7-10
>0010 0000 20 32 Select key bank 1, stop data, set
>voice key threshold to 0, turn off lamps 6-10 (bank 2)
>0100 0001 41 65 Select key bank 2, stop data, turn on
>lamp 1, turn off lamps 2-5
>0110 0001 61 97 Select key bank 1, stop data, turn on
>lamp 1, turn off lamps 2-5
>1000 0000 80 128 Select key bank 2, send data, set
>voice key threshold to 0, turn off lamps 6-10 (bank 2)
>1010 0000 A0 160 Select key bank 1, send data, set
>voice key threshold to 0, turn off lamps 6-10 (bank 2)
>1101 1010 DA 218 Select key bank 2, send data, turn on
>lamps 2, 4, & 5, turn off lamps 1 & 3
>1110 1010 EA 234 Select key bank 1, send data, turn on
>lamps 2 & 4, turn off lamps 1, 3, & 5
>-----------------------
>
>
>Whew! Here is a shorter view for you: First, you might have to send
>something like &HE0 to start the SRBox sending data from key bank 1
>(the on-board keys) (and turn off the on-board lamps). At that point
>the SRBox will send a steady stream of bytes to the serial port, at
>the configured bps and communication rate (default 800 cps at 19200
>baud). Each bit encodes the state of one button, so, e.g., button 1
>sends &H01, button 2 &H02, button 3 &H04, etc.; and buttons 1 & 3
>simultaneously send &H05, etc. You may then decode the byte with
>If...Then, or masking unwanted bits with a bitwise And.
>
>As to "emulating the keyboard", clearly for that E-Prime
>transparently reads a byte from the SRBox, translates that into ASCII
>code for the appropriate numbers (e.g., button 1 becomes &H31, i.e.,
>"1"), and uses something like InputDevice.InsertResponse to insert
>that string into the KeyboardDevice queue for use there. I would
>rather start by using the device directly, and once I got that to
>work I might fiddle with getting emulation to work.
>
>OK, that's probably both more and less than you asked for, but there it is.
>
>-- David McFarlane, Professional Faultfinder
>
>
> >Thanks,
> >
> >Carlos Faraco
> >University of Georgia
> >
> >On Oct 29, 10:50 am, David McFarlane <mcfar... at msu.edu> wrote:
> > > Tobias,
> > >
> > > OK, this question clearly lies outside the domain of PST Web Support,
> > > so I will weigh in...
> > >
> > > >Of course, keyboards and mice don't look that professional
> > >
> > > Hmm, around here we use keyboards and mice extensively, but perhaps
> > > we are not that "professional" :). We also use the PST SRBox, and if
> > > you understand its operation then in principle you could use it with
> > > any platform that will accept a stream from a serial port. Beyond
> > > that, sometimes we (meaning I) build our own customresponseboxes
> > > and wire them up either through an SRBox, a commercial digital I/O
> > > board, or even the lowly parallel port -- I have some mechanical
> > > skills as well as electronic and technology skills, and that is my
> > > job here. Of course you should have a machine shop and an electronic
> > > shop as well as a skilled research technology professional at your
> > > own institution to help with that (perhaps you are that
> > > professional!). <rant> I really don't see how anyone can consider
> > > themselves to do serious science in this day & age without such
> > > assistance. </rant> In short, we just do whatever it takes to
> > get the data.
> > >
> > > Oh, Empirisoft also boasts a keyboard with millisecond latency
> > > specifically for psychology research, as well as a USB button box
> > > (puts them a bit ahead of PST there), but we have not tried any of
> > > these. Seehttp://www.empirisoft.com. And of course, some people
> > > use touch screens, but I have to let those folks speak up for themselves.
> > >
> > > Good question, I look forward to more responses.
> > >
> > > -- David McFarlane, Professional Faultfinder
>
>--
>
>You received this message because you are subscribed to the Google
>Groups "E-Prime" group.
>To post to this group, send email to e-prime at googlegroups.com.
>To unsubscribe from this group, send email to
>e-prime+unsubscribe at googlegroups.com.
>For more options, visit this group at
>http://groups.google.com/group/e-prime?hl=en.
--
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To post to this group, send email to e-prime at googlegroups.com.
To unsubscribe from this group, send email to e-prime+unsubscribe at googlegroups.com.
For more options, visit this group at http://groups.google.com/group/e-prime?hl=en.
More information about the Eprime
mailing list