Response devices
Carlos
ixkackxi at gmail.com
Thu Dec 17 22:01:45 UTC 2009
Dave,
Thank you for your very detailed message. I will take a good look at
this and let you know what we find. It may be a bit before I get back
to you though since I will be leaving out of town this weekend for the
break.
Thanks again,
Carlos Faraco
University of Georgia
On Dec 14, 3:52 pm, David McFarlane <mcfar... at msu.edu> wrote:
> 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
>
> ...
>
> read more »
--
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