losing ERP triggers with E-Prime

[Tony Zuccolotto]

Richard,

What is the minimum pulse width that is required by Neuroscan in order
for it to be recognized?

I agree that using Sleep is applicable only in certain types of
experiments.   I was mainly suggesting it as a debugging tool at the
moment to investigate what is going on.
  
The general model I would recommend for external signaling is to use the
OnsetSignalXxx commands on your objects to issue the initial signal
(this assures that the signal is sent at the OnsetTime of the stimulus.
Then, after you are sure the minimum pulse width time has elapsed, use a
WritePort call lower the signal.   This allows you to do other
processing independent of the pulse width.   If you just want the pulse
to lower when your stimulus is over then you can also typically use
OffsetSignalXxx to do this (assuming your actual stimulus duration
provides a sufficient pulse width for the external hardware).   If you
use the OnsetSignalXxx and OffsetSignalXxx approach you can use time
auditing to log OnsetTime and OffsetTime and the difference between
these two durations should be equivalent to the pulse width you are
presenting on any one trial.

As per the hardware settings/configuration issue, your logic below is
certainly valid & justified, but it is possible that other software
applications could be doing some other type of reconfiguring of the
parallel port behind the scenes that E-Prime doesn't do by default.   I
agree though that you would think this is not the underlying cause - I'm
just brainstorming on problems that people have had in the past.

An insufficient pulse width would seem to be the likely cause.  I would
expect that the WritePort calls are functioning accurately in general
given the tests we typically run at PST prior to software releases, e.g.
we have a standard test that we run on E-Prime using a range of machines
and Windows OSes which toggle a bit on the parallel port at 1ms
intervals and records this with external hardware for review.  We also
do this test at 2ms, 10ms, 100ms, 1000ms, 10000ms intervals, as well as
intervals that increase linearly (by 1ms, 2ms, 3ms), and intervals that
increase by prime numbers.   

All of these tests never miss a transition.  If an operating system
event takes control of the processor for a short amount of time at the
exact moment that the WritePort is being called the worst case is that
the trigger may be delayed somewhat, but it will still occur.  

Give these past results I would really like to identify what the
underlying cause is of what you are seeing.

What is the equivalent specification/pulse duration you are using in
Presentation?  

Thanks,
Tony

> -----Original Message-----
> From: Richard P. Heitz [mailto:gte016z at prism.gatech.edu]
> Sent: Monday, November 17, 2003 11:23 AM
> To: E-Prime Listserv
> Subject: losing ERP triggers with E-Prime
> 
> So, I tried using the sleep command.  If I do a sleep of 500, it fixes
the
> problem.  But, I also tried a sleep of 40 and 50 ms, and that didn't
fix
> it.
> Due to the nature of the stimulus durations, I really can't be using
any
> sleep commands.  In other words, my stimuli absolutely must be
appearing
> much faster than 500.
> 
> If I use the other suggestion,
> 
> >
> > TimerDuration = .03
> > StartTime = Timer
> >
> > do
> > WritePort &H0378, 1
> > Loop Until Timer > StartTime + TimerDuration
> 
> E-Prime will continually write the same numbers to the parallel port
until
> the loop is up, will it not?  This would cause an altogether different
> problem, because when I epoch events later, each instance of the
writeport
> code will be considered a separate trial.
> 
> Also, I do not think it is a configuration issue with the parallel
port,
> because other stimulus presenation programs do not have diffuclty
writing
> to
> the same port.
> --------------
> 
> Richard,
> 
> This would seem to be a good way to do this, but I would suggest using
> Clock.Read instead of Timer (e.g. Clock.Read uses E-Prime's real-time
> clock, but Timer just uses the system clock and is mainly there for
> backward compatibility of some early language features of
VisualBasic).
> 
> In theory though you should also just be able to do
>   WritePort &H0378, 1
> Sleep 100
> WritePort &H0378, 0
> 
> (Sleep is also implemented internally using the real-time clock).
> 
> Is there any chance this is perhaps a problem with the configuration
> mode of the parallel port in the BIOS?   What choices are listed for
> parallel port modes in your BIOS and what is the current setting that
> you are using?
> 
> Thanks,
> Tony
> 
> 
> > -----Original Message-----
> > From: Don.Rojas at UCHSC.edu [mailto:Don.Rojas at UCHSC.edu]
> > Sent: Friday, November 14, 2003 6:12 PM
> > To: eprime at mail.talkbank.org
> > Subject: RE: Losing ERP triggers with E-Prime
> >
> > Yes, it might be viable.  If you are using a Writeport command, you
> need
> > to leave whatever parallel port bits you are toggling on for a while
> > before writing zeros to the port to turn off the trigger.  How long
> the
> > trigger needs to be depends on your specific acquisition, but 30 to
50
> > ms is usually ok with our Neuroscan EEG acquisitions.  Try using an
> > in-line trigger sequence like this:
> >
> > TimerDuration = .03
> > StartTime = Timer
> >
> > do
> > WritePort &H0378, 1
> > Loop Until Timer > StartTime + TimerDuration
> >
> > WritePort &H0378, 0
> >
> >
> > -----Original Message-----
> > From: eprime at mail.talkbank.org [mailto:eprime at mail.talkbank.org] On
> > Behalf Of Richard P. Heitz
> > Sent: Friday, November 14, 2003 3:12 PM
> > To: E-Prime Listserv
> > Subject: Losing ERP triggers with E-Prime
> >
> > That makes sense, but unfortunately, I am not using pre-release, nor
> is
> > the
> > response period any where near the display stimuli (temporally, that
> > is).
> > To further explore the problem, I wrote a simple program in E-Prime
> > using
> > the writeport command and an identical program in Presentation.
> > Presentation lost no triggers whereas E-Prime lost 7%, again
randomly.
> > So,
> > I figure it has to be something about the way E-Prime is writing to
> the
> > parallel port.  Is my earlier speculation about a "pulse width" even
> > viable?
> >
> 
>
------------------------------------------------------------------------
--
> --
> ----------
> Richard P. Heitz, M.S.
> Attention and Working Memory Lab
> Georgia Institute of Technology, Atlanta Georgia 30332
> Email: gte016z at prism.gatech.edu
> Office: 350 J.S. Coon Building
> Web: http://psychology.gatech.edu/renglelab
>