1. Internet

CÓMO ADAPTAR TU EXPERIMENTO
AL E-PRIME BIOLÓGICO
Este manual es un sencillo complemento al “Biological Add-ons for Net Station,
User Manual”, que tiene como objetivo adaptar un experimento programado en el PC
mediante e-prime (version 1.0) para comunicarse con el Mac, el cual utiliza el software
de Net Station (version 3.0) que utilizamos para el registro de Potenciales Evocados.
Para cualquier aclaración, sugerencia o agradecimiento (se aceptan jamones, o
una cervecilla en su defecto), e-mail a: [email protected]
Granada, 8 de Abril de 2003
1. Adaptar las teclas de respuesta del teclado del ordenador a las de la “Caja de
Respuestas” (llamada SRBOX)
- Haz doble click en el icono del experimento (“E” azul) para abrir las propiedades
generales de tu experimento. Abre la pestaña “Devices” y añade (“Add”) el icono de
SRBOX.
- Doble click en SRBOX para ver sus propiedades. Lo normal es que tengas que cambiar
alguna de ellas, especialmente el número de puerto (“PORT”), si luego no funciona en tu
experimento. Las propiedades con las que funciona actualmente son:
Collection Mode: Presses Only (esta no influye en que funcione o no, la verdad).
Port: 2
Baud Rate: 19200
CPS: 800
Configuration: Standard
Emulate Device: (none)
Las teclas del SRBox son los números 1,2,3 y 4. Aquí en la sala del experimentador hay
otro dispositivo (5 teclas cuadradas, que es el que trae el e-prime) que también se puede
usar para probar directamente si funcionan las respuestas. Hay un programa de e-prime
llamado “Utilities” que te hace una presentación donde explica el Button Box, la llave
vocal...y que permite hacer un test para ver si funcionan estos aparatejos. Lo encontraras
en la ruta: C:\My Experiments\SRBOXTest.
- Cambia en la lista donde tengas el atributo [CorrectAnswer], las letras (ej. z, m) por los
números que elijas entre 1 y 4.
- Cambia en tu objeto encargado de recoger la respuesta (ej. ‘Target’) las opciones de
respuesta. Pestaña “Duration/Input”, en ‘Devices’ añade (Add) el SRBox. Actívalo y haz
click sobre el para cambiar las ‘Response Options’
NOTA 1 (MUY IMPORTANTE):
a) Desactiva el Keyboard, porque si no en los resultados luego no se te registra el
tiempo de reacción (siempre aparece un cero)
b) Asegúrate de que las propiedades que modificas cada vez, se refieren al Device
SRBOX (que aparezca marcado en azul) y no al Keyboard, ya que cuando abres
esta ventana, siempre aparecen las propiedades del Keyboard por defecto.
2
En la opción ‘Allowable’, si quieres puedes poner varios atributos seguidos. Por ejemplo:
[Xkey][Okey]. Esto significa que las únicas teclas de respuesta que funcionarán serán la
asignada para el estimulo ‘X’ y la asignada para el estimulo ‘O’. Así previenes que pulsen
otras teclas por confusión.
En la opción ‘Correct’, pondríamos [CorrectAnswer].
2 . Meter los iconos que permiten la comunicación entre el PC que ejecuta el
experimento y el Mac que registra los potenciales con el programa Net Station (el
Package es la version 1.0.6.7)
Los iconos representan rutinas, son códigos para efectuar dicha comunicación. Hay
comunicación a 3 niveles distintos a lo largo del experimento:
a) Al iniciar y acabar la sesión experimental
b) Al iniciar y acabar un bloque de ensayos
c) Al iniciar y acabar un ensayo
Para realizar estas comunicaciones, hay que insertar los siguientes iconos (ver User
Manual):
a) En el procedimiento “SessionProc”, insertar ‘NSInit’ y ‘NSUninit’ al principio
y al final, respectivamente.
b) En el procedimiento “BlockProc”, insertar ‘NSStartRecording’ y
‘NSStopRecording’ al principio y al final, respectivamente.
c) En el procedimiento “TrialProc”, insertar ‘NSTrialBegin’ y ‘NSTrialEnd’ al
principio y al final, respectivamente.
NOTA 2:
1) Puedes (debes) poner tantos iconos de ‘NSStartRecording’ (y su correspondiente de
stop) como procedimientos diferentes tengas. Este icono sirve para que el Mac no se tire
grabando mucho tiempo innecesario en momentos en los que no sucede nada
experimental (ej. instrucciones, descansos entre bloques). Por eso, se recomienda poner
las pantallas de instrucciones antes del icono ‘NSStartRecording’, y los descansos entre
bloques después del icono ‘NSStopRecording’.
2) Sin embargo, sólo debe de haber un icono ‘NSInit’ y otro ‘NSUninit’ para todo el
experimento.
3. Definir el tipo de información que queremos que el PC (que variables de nuestro
experimento) mande al Mac.
El objetivo es que en la fase de análisis de los potenciales, podamos relacionar
cada evento experimental (presentación de la cue, target, etc) con la actividad cerebral
que registramos y que suponemos que es generada por dichos eventos. También
queremos enviarle al Mac información sobre que condición experimental concreta
ocurrió en cada ensayo. Todo esto se consigue creando 2 ‘Listas’ (CellList y KeyList) y
un ‘InLine’ (NSSendTrialEvents) en el e-prime.
Las listas son objetos de e-prime que hay que colocar al final de la estructura
como elementos no referenciados (maletín ‘Unreferenced e-objects’). Estas listas
3
haremos que contengan atributos cuyos nombres (ej. CellNumber, KeyName, KeyID...)
son variables que ya están contempladas por el NetStation. Así, en estas listas asociamos
información que usa el e-prime (ej. los nombres de nuestros atributos –como [SOA] o
[Target]-, los tipos diferentes de condiciones experimentales que hemos creado en la
TrialList...) con información que entiende el NetStation.
El Inline contiene varias líneas de código que se encargan de enviar al NetStation
información sobre cada evento que ocurre dentro de un ensayo (ej. fijación, cue, target,
recogida y registro de la respuesta).
Veamos despacico cada uno de estos 3 elementos de información:
CellList
Insertamos un objeto ‘List’ en ‘Unreferenced e-objects’ y lo llamamos “CellList”.
Añadimos 2 atributos, que se llamen (forzosamente) “CellNumber” y CellLabel”
El CellNumber sirve para asignar un número que identifica cada “celda” con una
condición experimental. El resultado de los siguientes pasos es tener el atributo
CellNumber común a las listas TrialList y CellList.
a) Nos vamos a la TrialList y vemos cuantos tipos diferentes de ensayos hemos
programado (es decir, cuantas filas componen dicha tabla).
b) En la TrialList añadimos otro atributo que se llame igual que el de la CellList:
“CellNumber”.
c) Rellenamos las casillas con números del 1 al número de condiciones que tengas
d) Abrimos la CellList e introducimos en las casillas (debajo de la CellNumber)
los mismos números que utilizamos en c)
Por ejemplo, si en un experimento de Stroop tenemos 3 condiciones (congruente,
incongruente y neutro), en la TrialList tendremos 3 filas especificando cada tipo de
ensayo. Pues añadimos otra columna con el CellNumber, cuyas casillas las debemos
rellenar con números (1,2 y 3). Copiamos esta columna y la pegamos en la columna
CellNumber de la CellList.
NOTA 3: si tienes una lista diferente a la TrialList para presentar los ensayos de practica,
debes repetir estos pasos, pero utilizando otros números (por ej. homólogos) a los de las
condiciones experimentales. Por ejemplo, usa 10, 20 y 30 para que se correspondan con
1,2 y 3. Es decir:
A’) Nos vamos a la PracTrialList y vemos cuantos tipos diferentes de ensayos
hemos programado (es decir, cuantas filas componen dicha tabla).
B’) En la PracTrialList añadimos otro atributo que se llame igual: “CellNumber”.
C’) Rellenamos las casillas con números del 10 al numero de condiciones que
tengas (10,20 y 30)
D’) Abrimos la CellList y añadimos nuevas filas a las que ya teníamos de los
pasos a,b,c y d). Introducimos en las casillas (debajo de la CellNumber) los
mismos números que utilizamos en c’), es decir, 10, 20 y 30.
En resumen, la CellList debe recoger los CellNumber de los ensayos de practica (ej.
3 tipos de condiciones) y los CellNumber de los ensayos experimentales (ej. 3 tipos
de condiciones). Por ejemplo, 6 filas con los CellNumber 1, 2, 3, 10, 20, 30.
4
El CellLabel sirve para darle un nombre a cada condición experimental. No es
muy importante (aunque debemos rellenarlo) pero nos facilita identificar cada condición
experimental con un nombre mejor que con un numero (el CellNumber). Le ponemos un
nombre significativo (ej. “congruente, incongruente y neutro”). No tiene por que tener 4
caracteres. Esta información aparece al principio del registro en el NetStation: aparecen
como Eventos, donde se identifican todas las condiciones experimentales. Aparecería así:
‘CELL’: CONGRUENTE. (y al lado del icono de una llave –key-): ‘cel#’=1
‘CELL’: INCONGRUENTE. ‘cel#’=2
‘CELL’: NEUTRO. ‘cel#’=3
NOTA 4: esto depende de como hayas diseñado tu TrialList, pero es muy probable que la
CellList no nos de toda la información especifica de los eventos concretos que se
presentaron en cada ensayo particular. Siguiendo el ejemplo de Stroop, la CellList no
sirve para informarnos de que en el ensayo numero 127 se presento el target
“GAZPACHO” escrito en color violeta a un SOA de 500 ms. Para remediar esto, NO se
os ocurra introducir atributos (ej. [Target]) en las casillas del CellLabel. Para disponer de
esa información, se utiliza la famosa ‘KeyList’.
KeyList
Como se ha dicho en la Nota 4, esta lista sirve para que en NetStation también
tengamos la información específica de cada ensayo. Esta información se refiere a que
valores concretos (de todos los posibles especificados en la TrialList) adoptaron nuestras
variables (o atributos) en cada nuevo ensayo. Esta información ya la tenemos en el
archivo “.dat” que genera el e-prime, pero no nos sirve para hacer luego los análisis
posteriores en NetStation en función de dichas variables (ej. si queremos analizar los
potenciales en función del SOA, tenemos que saber, en el NetStation, que SOA tenia cada
ensayo). Por eso, es imprescindible también disponer de ella en el NetStation.
Insertamos un objeto ‘List’ en ‘Unreferenced e-objects’ y lo llamamos “KeyList”.
Añadimos 3 atributos, que se llamen (forzosamente) “KeyName”, “KeyID” y
“KeyDataType”.
KeyName: hay que poner el nombre del ATRIBUTO cuyo valor ira cambiando en
función del tipo de ensayo. Podemos insertar tantas filas como información de distintos
atributos queramos. Por ejemplo, 3 filas para saber que: ‘Cue’, ‘SOA’ y ‘Target’ se
presentaron.
NOTA 5: lo que hay que poner no es un objeto del procedimiento sino un atributo de la
TrialList. Esto puede ser confuso si p.ej. hemos utilizado el nombre ‘Target’ para
denominar el objeto que presenta el target y para denominar el atributo –o variable- en la
TrialList. No hay ningún problema con esto, solo que debemos saber que ahora nos
referimos al ‘Target’ como atributo, nunca como objeto.
5
KeyID: debe tener 4 caracteres. Es el nombre con el que el NetStation te
presentara la información de cada atributo. Para diferenciarlo de los ‘Tags’ (ver Task 12,
pag 25 del User Manual) podemos utilizar el símbolo “#” mientras que en los tags
usábamos el símbolo “+” al final. Ejemplo:
Atributo
Tag
KeyID
Cue
cue+
cue#
Target
tar+
tar#
NOTA 6 (todavía es pronto para entender completamente esta nota pero esta bien darle
una primera lectura. Mas adelante volveremos sobre ella): En el NetStation veras, en la
línea de eventos, una banderita gris con el nombre (tag) de cada evento ordenado en el
tiempo. Si colocas el puntero sobre uno de dichos eventos se abre una ventana con la
siguiente información: Nombre del evento (el tag que le pusieras), duración, tipo de
condición presentada (el CellNumber, ‘cel#’=1), número de observación de esa condición
(‘obs#’=3), que posición ocupa ese evento desde que comenzó el ensayo (‘pos#’=7) y el
‘argu’=0 que no se para que es.
Además, en el evento ‘TRSP’ aparecen, al lado de un icono que representa una
llave (key), los KeyID que le hayamos puesto en e-prime (‘SOA#’= 350, ‘tar#’ =
gazpacho). También aparecen en este evento datos sobre la respuesta registrada (rsp#,
eval, rtim, trl#), que se explican mas adelante.
KeyDataType: sirve para especificarle al NetStation que tipo de datos va a
manejar en relación con los atributos que hemos especificado en KeyName (creo que es
algo así como decirle si nuestra variable puede adoptar valores numéricos, alfanuméricos,
etc). En nuestro ejemplo, introduciríamos la palabra “TEXT”, ya que el atributo ‘Target’
adopta valores que son texto. Consejo: para curarnos en salud es mejor poner siempre
“TEXT” ya que este tipo sirve tanto para caracteres que son letras como números.
InLine: ‘NSSendTrialEvents’
Como este código se encarga de enviar al NetStation información sobre cuales
son los eventos que ocurren dentro de un ensayo (ej. fijación, cue, target, recogida y
registro de la respuesta), es lógico pensar que debemos de colocar este icono siempre
detrás de todos los eventos que nos interesa declarar que han ocurrido. En un
TrialProcedure no muy complicado (es decir, sin banderitas verdes –Labels- ni saltos –
jumps) este icono ira al final del ensayo pero justo antes del “NSTrialEnd”.
Veamos en este ejemplo las 3 partes de la estructura de este Inline (ver Task 11,
pag 22-24 del User Manual):
1)
NetStation_SendRespEvent c, Target
2)
NetStation_SendTrialEvent c, Fixation
NetStation_SendTrialEvent c, Cue
NetStation_SendTrialEvent c, Interval
NetStation_SendTrialEvent c, Target
6
NetStation_SendTrialEvent c, UntilResponse
NetStation_SendTrialEvent c, Feedback
3)
NetStation_SendTRSPEvent c, Target, KeyList
Las líneas de código que aparecen en 2) sirven para informar a NetStation de la
ocurrencia de esos eventos en cada ensayo (en la Nota 6 se explica cómo se ven en el
NetStation estos eventos que tu le mandas)
La línea de código que aparece en 1) sirve para mandar el evento “ha ocurrido una
respuesta” en relación con un objeto. En nuestro ejemplo, el objeto es el “Target”,
porque es el objeto que coge la respuesta (además, este objeto debe de coincidir con el
objeto sobre el que se da el Feedback, es decir, el “InputObjectName”). Por tanto, a nivel
general, después la coma “c,” hay que escribir el nombre del objeto que recoge la
respuesta. Este evento únicamente nos dice si hubo o no hubo respuesta y en que
momento ocurrió. Este evento es etiquetado por el NetStation con el tag “resp”. Si
movemos el puntero sobre el, veremos que no nos da información sobre si la respuesta
fue correcta o no: solo aparece ‘rsp+ =1’, que significa que si hubo respuesta (cuando no
hay respuesta, simplemente este evento no aparece en la línea de eventos).
La línea de código que aparece en 3) sirve para mandar la información de los
eventos especificos que ocurrieron en un ensayo. Después de la coma (“...c,) tenemos el
Target y el KeyList:
- Si solo escribimos Target, le mandamos la siguiente información en relación con
la respuesta que se dio al target: que tecla se pulso para responder, si la respuesta fue
correcta o no y el tiempo de reacción. Nuevamente, en general, después la coma hay
que escribir el nombre del objeto que recoge la respuesta.
En el NetStation, al apuntar sobre el evento “TRSP” nos aparecería dicha información de
esta manera:
rsp#: 1 (significa que la tecla que se pulso fue la tecla “1”)
eval: 0 (fue respuesta incorrecta)
rtim: 438 (TR en milisegundos)
trl#: 127 (el ensayo que se presento aleatoriamente en la posición 127)
- Si además añadimos Keylist, le mandamos toda la información concreta de cada
ensayo, en relación con los atributos (KeyName) que pusimos en la KeyList (en la Nota 6
se explica como se vería esta información en el NetStation).
NOTA 7 (IMPORTANTE):
- Cuidado con no utilizar en e-prime nombres que puedan ser usados por el NetStation, o
incluso por el propio lenguaje que usa el e-prime (Visual Basic). Ejemplos reales
(¡desgraciadamente!):
Utilice como Tag para mi objeto “Respuesta” la palabra “resp”. Recuerda que el
NetStation, en la línea de código que aparece en 1), manda el evento que lo etiqueta como
“resp”. Así, luego te encuentras 2 tipos de eventos distintos con el mismo nombre: se
arma el lío...
7
Para llamar a un objeto utilice la palabra “End”, que es un comando de Visual
Basic, así que daba error...
- La lista de eventos que se especifica en 2) (SendTrialEvent), SIEMPRE HA DE
SEGUIR LA MISMA UNICA SECUENCIA QUE REALMENTE OCURRE EN
NUESTRO EXPERIMENTO. Ejemplo real: en mi procedimiento utilice un Jump-Label
para registrar ensayos en que se producían anticipaciones de respuesta. Es decir, en el
mismo procedimiento podían ocurrir 2 cosas: que hubiera o que no hubiera anticipación,
de manera que la secuencia de eventos variaba según el participante se anticipara o no.
Sin embargo, mi lista de eventos solo contemplaba los eventos que ocurrían cuando no
había anticipaciones. Así, si en el experimento ocurría alguna anticipación, había una
descoordinación entre los eventos que espera el NetStation y los que realmente ocurrían.
Resultado: se le iba la cabeza y en la línea de eventos salían muchos eventos repetidos y
fuera del lugar que les correspondían (ej. aparecían 2 target simultáneamente: uno
procedente del ensayo tercero y otro del octavo). Se puede solucionar haciendo un Inline
para cada una de las posibilidades, y en cada Inline listas los eventos que son. Consejo:
cuanto mas sencillo puedas hacer tu procedimiento (¡o tu experimento entero!), menos
problemas tendrás en la vida.
4. Comprobar que la comunicación PC-Mac ha sido buena.
Abre el programa NetStation. Pincha en NewSession.
Selecciona “Experimental Control Template”.
El archivo se llamara “default subject” si no lo cambias y se grabara en la ruta:
DataAcquisition/Documents/NetStationUserData/Sessions.
BeginSession...
Cancela “Measuring Zeros” (hasta que no registres con red no lo necesitas, y ahora te
quita mucho tiempo)
¡FUNCIONA!
En la parte superior izquierda pincha el botón “Events” para abrir la línea de eventos
Ahora ejecuta tu programa en e-prime y observa como se van registrando los eventos en
la línea de eventos
Para ver si graba bien la información que le mando el PC, ‘Close Session’ (parte superior
derecha)
Abre tu archivo: pincha (Open) Select.Busca tu archivo en la ruta que se indicó arriba
¡Voila!
En la línea de eventos tienes todo lo que ocurrió en el experimento.
Una forma más sencilla de ver los datos es en la parte superior “Events”, elige
“ListEvents”. En realidad hay un icono para listar los eventos...te dejo que lo descubras...
Ahora es un buen momento de repasar en el Apartado 3 todo aquello que se decía del
NetStation y que no quedaba muy claro.
Una forma sencilla de contar el número de eventos de cada ídem es pinchar “Filter
Events”, en la ventana de “ListEvents”. Lo normal seria que tuvieras la misma frecuencia
para cada evento.
Eso es todo amigos. Mucha suerte, ánimo y ¡paciencia!
8