I've been creating a C++ based application (not LabView) using the LabView_DLL.dll, as described here (www. biosemi. com/faq/make_own_acquisition_software.htm). Now I need my program to send trigger pulses on the parallel port to synchronize with the BioSemi EEG collection (ActiveTwo Mk2), and I'm struggling to come up with the best solution. I can't seem to find a previous topic on this, but if it already exists, please direct me thanks!

But here's some additional info and concerns that I have as well. I had initially hoped that I could use Windows API calls (e.g., CreateFile and WriteFile), as described in the comments here (msdn. microsoft. com/en-us/library/Aa363858), but discovered that there needs to be a handshake with the device that isn't performed by the BioSemi. Alternatively, certain pins can be hard-wired together to fake the handshake, as described in Method 1 of this LabView tutorial (digital. ni. com/public.nsf/allkb/B937AC4D8664E37886257206000551CB), but this is less desirable (for hopefully obvious reasons). I found a possible solution for Windows XP here (logix4u. net/Legacy_Ports/Parallel_Port/Inpout32.dll_for_Windows_98/2000/NT/XP.html), but it doesn't look like it will work on Windows 7, which we plan to upgrade to soon. Moreover, this document (digital. ni. com/public.nsf/allkb/E6415E8A8376F63D86256C46007592E8) seems to suggest that even LabView won't be able to write to the parallel port in Windows 7. But I've gotten the impression that people have working BioSemi systems here (with triggers) on Windows 7, and so I'm confused how they were obtained.

Ideally what I'd like is a solution that works for both Windows XP and Windows 7 (and beyond), hence why I started by looking in the Windows API. What do people recommend?

Thanks in advance for your help!

Michael

P.S. - Sorry for the unlinked and cryptic URLs, but with this, my first post, I was prevented from using a nicer format.

Thanks Coen! That seems like it'd be a great solution. Just one question. That page says about the latency "timing of the trigger inputs is accurate to the time period of a sample", but I understood USB communication to have inherent delays of up to 30 ms. Is this not the case with the USB_WRITE function in the BioSemi driver?

The output delay of the USB_WRITE function was measured to be as low as 2-3 ms. However, we recently found that there (sometimes ?) is a problem when sending more than approx 10 triggers per second. In this case, the extra (more than 10) triggers are ignored. We are looking into this, and try to find a solution soon. Until we have found a solution, wait approx 150 ms after sending a trigger before sending the next one, to ensure the 2-3 ms accuracy.

By the way, the input delay is adjustable in the latest version of the LabVIEW_DLL.dll (download form our website). Use the STRIDE functions to control the delay. Default is approx 50 ms, but with the STRIDE commands it can be adjusted down to the ms range. However, a shorter delay (smaller packages in the USB transfer) will increase processor load. Use the STRIDE commands to make the best trade-off between delay (optimize real-time behavior) and processor load for your application.

The cause of the delay was nothing more than a simple (stupid) bug in my LabVIEW code. The delay in sending triggers is actually in the ms range. It is no problem to reliably sent out 200-300 triggers per second. Sorry for the confusion.

Sorry, but I guess I wasn't clear. These output trigger pulses don't seem to get saved to the data stream in the ringbuffer. Is there a way to write to the input trigger pulses which are recorded on the sync line? Or are these output trigger pulses recorded somewhere? I basically need to "time stamp" events in my software in the EEG data, so that the two can be synchronized.

Just connect the trigger outputs with the trigger inputs at the USB trigger port (pin 1 to pin 17, pin 2 to pin 18,......., pin 15 to pin 31). Your output triggers will then appear in the trigger/status channel. With respect to timing accuracy, this method is actually much better than overwriting the trigger/status channel in the acquisition software.

Forgive me for being completely naive, but you are talking about actually connecting the pins on the rear panel of the optical receiver/usb interface with wires, correct? If I'm understanding correctly, there isn't a software solution without this hardware tweak.

I am having the same issues as the original poster. Do you know of a way to get the parallel port method working in Windows XP or Windows 7? I need all 16 trigger inputs, where 8 inputs will be coming from 1 PC, and the other 8 will be coming from a separate PC. This prohibits me from using the USB_WRITE method you've described here. Thanks for your help.