Trigger Port Timing

Post Reply
zajdeld
Posts: 10
Joined: Wed May 19, 2004 8:58 pm

Trigger Port Timing

Post by zajdeld »

We are having a little trouble with the reliability of triggering Biosemi with the parallel port on a PC. Does the Biosemi trigger hardware latch the trigger port signals synchronously with the acquisition hardware? Is there any chance Biosemi could be sampling the trigger port while the external trigger signals are in transition?

Coen
Site Admin
Posts: 1124
Joined: Fri Mar 26, 2004 7:00 pm
Location: Amsterdam, Netherlands
Contact:

Post by Coen »

The trigger lines are latched synchronous with the AD-box sampling, also see viewtopic.php?t=53

It is possible that the latching moment coincides with a level change. This may lead to false codes if you change multiple lines at the same moment. If this presents a problem in your application, you should use the sampling-clock output on pin 32 of the trigger port for synchronization of your trigger signals.

Best regards, Coen (BioSemi)

brroach
Posts: 11
Joined: Tue Feb 21, 2006 11:36 pm

Post by brroach »

We run scenarios where the start and finish of a recording block is triggered by our stimulus presentation computer. We use presentation, where the TTL pulse duration (pulse_width) can be specified. We use a 10ms pulse duration, which starts and stops the recording fine. However, when analyzing the data offline in brain vision analyzer, I see that the code I sent (128 to begin the recording) does not occur at the same latency as the start of the recording. How could that be possible?
Specifically, this is what we have:

Sampling rate: 1024Hz, SamplingInterval: 0.98ms
Type, Description, Position, Length, Channel
New Segment, , 1, 1, All
Comment, Start Epoch, 1, 1, All
Comment, DC mode, 1, 1, All
Comment, CMS in range, 1, 1, All
Comment, Imp. Check, 1, 1, All
Stimulus, S128, 110, 1, All

In my mind, it is impossible to have such a delay between the start of the file and my code that started the recording. Does activeView record a short buffer, and when you "unpause" the recording, it grabs as far back in the buffer as possible? In the above case, 110ms. OR does it get the recording going, but then writes the unpause code (128) as soon as it is done initializing the recording, which takes some variable amount of time. Files like the one described above produce clean ERP data, so I doubt this is a usb/trigger latency issue. I just need to know which time to trust as the time when that first code (128) is sent, and if I can trust the reported time, I need to know how/why the software is able to record the previous 110ms worth of data.

thanks,
Brian

Coen
Site Admin
Posts: 1124
Joined: Fri Mar 26, 2004 7:00 pm
Location: Amsterdam, Netherlands
Contact:

Post by Coen »

ActiView saves data in blocks of 1 second (BDF record length). A buffer of 1 second is continuously filled with data, and when the buffer is full, the data is streamed to disc (indicated by a flash of the "write" lamp in the right sidebar)

When the Pause button unlocked, ActiView saves the running 1 second buffer when it's end is reached. So, the amount of time you will see in the eventual BDF file between the begin of the epoch and the unlock-pause code may be anything between zero and 1 second.

When the Pause button is locked, ActiView does not save the running 1 second buffer anymore. Therefore, you should wait with locking the Pause button until at least 1 second after the last event of importance.

Latencies caused by the USB transfer and the Windows operating system only come into play when events on screen are used to decide on lock/unlock events of the Pause button controlled via the trigger port.

Best regards, Coen (BioSemi)

Post Reply